As far as I am aware RS messages only need to be sent out when a device first joins a network once it is on the network it shouldn't have to send out any additional RS messages unless it detects changes on the network.

Indeed powering off the IPad and powering it back on does indeed cause an RS message to be sent as does switching the network the Ipad is using.

TBH IPv6 on the IOS is not the best it can be.  It's happy eyballs solution means that browsers will use the IPv4 address rather than the IPv6 address, apple could seriously do with overhauling this.

Ravenstar68

unfortunately I have found my Samsung Galaxy S4 seems to do the same on two different IPv6 router platforms.  

And the RS would as you say be used every time a network is joined, my point is that when the iPad sleeps its wireless (and the GS4 apparently as well), things on the network can change.

For instance, a prefix can be deprecated (lifetime = 0) if it changes, which can happen on a dynamic link such as PPPoE, or renumbering a network etc.

As well, in my case even if the prefix does not change, and the devices sleep longer than the preferred/maximum prefix lifetimes, therefore when they wake from sleep the prefix is actually no longer to be considered valid since they have not gotten any RAs in the interim to reset their lifetime counters.  Yet for some reason, the devices wait patiently for a RA to re-enable the IPv6 stack instead of asking the network if a router/prefix is available.  This is what I find as a strange implementation 

apparently it pings when it is idle only when it is on  a charger.  The iPhones do this as well.  v4/v6 pings therefore work when the devices are plugged in 

I will test without chargers and run packet captures to check for router sollicitations when they are woken.  Perhaps the iPhones do the same.  In any case, I never noticed before since my previous router would send RAs every 30 seconds, this one has a much longer time between RAs and I am noting this strange behaviour.  Other OSs I use do not seem to have moments where the prefix is unusable...

I think the ipad still pings on v4 when idle, and in the unlock screen the wifi bars are already there contrary to the iphones.

I know for a fact using wireshark i see no RS sent by the ipad when it is unlocked.   I will have to test with wireshark what the iphones do but they have a valid prefix faster than i can open the ip6info app to check, contrary to the ipad that has no valid prefix until an unsollicited RA is sent by the router, which can take minutes

I have an iPad mini and it has an annoying behaviour.  I would like to know if it is specific to my setup or if it is iOS6.1.2 that is misbehaving.

Essentially, I am running an Openwrt router using 6relayd for SLAAC/RA.  It seems to work fine for XP/Windows7/Android JB 4.1/Ubuntu, however my iPad will not keep its prefix active when I pick it up after a period of it being idle.

The RAs being sent by 6relayd are with lifetime 7200s, and I see regular RAs on the wire coming from the wrt device.  I installed a app on the iPad called ip6config, which allows me to see the prefixes configured on the various interfaces, the one I am interested in being the WiFi.  Upon powerup, the iPad will properly configure itself a prefix and IPv6 works fine.  However, if I am to let it sleep for more than 7200s, (or idle, because I don't think it is sleeping, just the screen is off), the RAs sent between the time I last used it and the time I pick it up are ignored.  This causes the WiFi to no longer have a valid IPv6 prefix when I unlock the device.

What is worse, it doesn't send any RS to the network, and will remain without a working prefix until the wrt sends out a RA.  Once the iPad sees the RA, the prefix is re-enabled and voila, IPv6 works again.

I have 3 iPhones on this LAN that do not seem to do this, however the difference with these devices is that they seem to shut off WiFi when they are idle for a certain amount of time, so I believe they are sending a RS when they reconnect to the wifi when I unlock them, contrary to the iPad which is always connected to the AP.

Anyone with a non 3G/4G iPad care to comment on their observations with regards to prefix lifetimes on the devices?

many would argue that 6to4 in itself is broken 

RFC 1918 addresses should not be routed, no idea what broken OS/software would use a RFC1918 6to4 derived address, but you might as well just filter them at your network boundary.  2001:db8::/32 as well 

I had this problem when using STA mode; with WDS mode on OpenWRT it works.  Are you sure you are using WDS and not STA mode?  Post your config for the remote bridge and I will compare it with my working config later tonight.  I use WDS+OpenWRT and IPv6 works with radvd.

and WDS will only halve your throughput if you are connecting wireless to a WDS bridge acting as an AP as well as a bridge.  Since you are connecting to the WDS#2 over a wired connection, you will not halve your throughput. 

this works?  HE is giving free 6RD service?!  I don't see how this works since they are assigning space out of 2001:470::/32 for their tunnelbrokering service, and an entire /32 is required to cover IPv4 address space.

IPv4MaskLen=32 means there is only one IPv4 address in the 6rd domain; 6rd with IPv4MaskLen=32 is 6in4.

I know what it is.  But what I am saying is that to do 6RD, you need to dedicate a /32 in order to do so.  They are offerring tunnelbroker services in 2001:470::/32, therefore they cannot be also using that prefix for 6RD.

I am curious, what are the specs and OS/build of that router?!

woops....wrong general forum  

it can be used now for the ping test in the certification?! 

well the most notable one is that in theory, hosts that enable AAAA will not leave it on only for 24 hours.  The plan is to leave them on permanently, thus the "launch".

It seems facebook has started to publish AAAA on non-"whitelisted" DNS servers -

Code:

dig -t AAAA @4.2.2.2 www.facebook.com

; <<>> DiG 9.3.2 <<>> -t AAAA @4.2.2.2 www.facebook.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15385
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.facebook.com.              IN      AAAA

;; ANSWER SECTION:
www.facebook.com.       96      IN      AAAA    2a03:2880:10:8f01:face:b00c:0:25

;; Query time: 15 msec
;; SERVER: 4.2.2.2#53(4.2.2.2)
;; WHEN: Mon May 21 23:10:15 2012
;; MSG SIZE  rcvd: 62

good to see considering it was "supposed" to re-occur only on June 6th.  Maybe they need some news to spur investment in their stock  

I wish I could explain the innards of client STA vs WDS mode.  I am not an expert in that regard.  I am just saying from experience that I went half-crazy trying to get RAs and ND working correctly on bridged client mode, and ended up giving up and moving to WDS which I had stayed away from for stupid reasons.  It works perfectly with multiple bridges in my network, I have both D-LINK and Linksys/Cisco APs and they all happily use WDS and all my nodes have IPv6.

it doesn't work since the ARP-NAT that is done by Openwrt to allow traffic in client mode is designed for IPv4 only.  Run a wireshark capture and you will see that most of the ICMPv6 traffic is broken/missing.  WDS is the only way.  This is not a openwrt-specific problem, Virtualbox, VMware and others all clearly state that in order to use IPv6 over bridged interfaces, they have to be wired.

WDS however allows it.  Why not use WDS?!

if you are using anything other than WDS, you cannot use IPv6 unless you are in routed mode.

http://wiki.openwrt.org/doc/howto/clientmode#bridged.client.mode.issues

your options are;

1) use WDS
2) set up routed client mode

I think this is the same reason that Virtualbox hosts will work wired but not wireless on the host OS.

[::ffff:12.122.2.53]

just as a followup to this, I have read that IPv4 mapped addresses in traceroutes are caused by MPLS routers in the path that do not have IPv6 native stacks.

AT&T would share the Cogent "incompetence", likely for the same reasons;

traceroute6 www.ietf.org
traceroute to www.ietf.org (2001:1890:123a::1:1e), 30 hops max, 80 byte packets
 1  cconnv6.cconn.info (2605:2a00:ffff:fffd::1)  3.812 ms  6.499 ms  7.446 ms
 2  v6.hautevitesse.net (2605:2a00:ffff:ffff::1)  4.545 ms  4.667 ms  4.783 ms
 3  2001:550:2:16::9 (2001:550:2:16::9)  4.072 ms  4.165 ms  4.285 ms
 4  2001:1890:1fff:105:192:205:36:77 (2001:1890:1fff:105:192:205:36:77)  11.845 ms 2001:550:3::2ce (2001:550:3::2ce)  57.363 ms 2001:1890:1fff:105:192:205:36:77 (2001:1890:1fff:105:192:205:36:77)  12.125 ms
 5  n54ny21crs.ipv6.att.net (2001:1890:ff:ffff:12:122:80:226)  86.448 ms  86.486 ms  84.474 ms
 6  cgcil22crs.ipv6.att.net (2001:1890:ff:ffff:12:122:1:2)  84.736 ms  84.832 ms  84.868 ms
7  cr1.cgcil.ip.att.net (::ffff:12.122.2.53)  86.010 ms  86.177 ms  86.343 ms
8  sffca21crs.ipv6.att.net (2001:1890:ff:ffff:12:122:4:121)  83.847 ms  84.078 ms  83.707 ms
9  cr81.sj2ca.ip.att.net (::ffff:12.122.1.118)  108.979 ms  108.959 ms  107.975 ms
10  sj2ca401me3.ipv6.att.net (2001:1890:ff:ffff:12:122:126:238)  81.250 ms  81.250 ms  81.379 ms
11  2001:1890:c00:3a00::11fb:8591 (2001:1890:c00:3a00::11fb:8591)  82.225 ms  81.968 ms  82.298 ms