On Thu, Oct 20, 2016 at 4:16 PM, Bernhard Schmidt <[email protected]> wrote: > After several people mailed me that this setup should be working I > tested a bit further. It turned out that most of the time (not always) > the iPad was not answering Neighbor Solicitations sent from the router. > Since our WLAN solution (Alcatel =~ Aruba) does some fancy things with > Multicast in general and particularly IPv6 neighbor solicitations I > wasn't sure whether the Wireless setup was faulty. > > Someone sent me a very nice link on how to debug this (essentially run > tcpdump on the iPad, see > https://developer.apple.com/library/content/qa/qa1176/_index.html). > > Running this revealed that the iPad did indeed receive the Neighbor > Solicitation but completely ignored it. See > > https://syncandshare.lrz.de/dl/fiX5fNH2Ccmp5nJhEbqhMRDn/ios-ipv6.pcapng > https://syncandshare.lrz.de/dl/fi7EYUXNX8df9gtZfCbiSXEp/ios-ipv6.txt > > This seems to be caused by our special setup not setting the on-link > flag in the RA (since the wireless clients can't talk to each other > anyway they are supposed to send all traffic to the router). I assume > this triggers some sort of spoofing protection on the iPad, since the > source address of the NS is global and (according to the routing table) > not on-link. > > I'm not sure who is at fault here (the RFC editors, me, Cisco or Apple), > but changing to the more standard on-link=1 RA fixed the issue for us.
Yes, it looks like combination of two factors: - your router is sending NSes from GUA, not link-local address (it is allowed behavior. My router, however, use link-local address as a source to send NSes to the solicited node mcast address); - iOS device iOS device gets NS from an address which is non on-link so it does not put that address into neighbor cache and does not respond to it. (As per https://tools.ietf.org/html/rfc5942#page-9 , ND messages from an address do not indicate that that address is on-link (as it used to be as per RFC4861). So an address (the router GUA in this case) is not on-link, it probably (?? can not find a quote to prove it) means it should not be placed in the neighbor cache. However it breaks a legitimate network setup... If such interpretation of rfc5942 is correct (isn't it too strict?) then the only solution I see is to make routers sending ND packets from LLA always.. One of the possible solution could be making routers > On 13.10.2016 10:45, Bernhard Schmidt wrote: >> Hi, >> >> for a couple of years now we have been running an IPv6-only eduroam on >> Campus for testing purposes. We use the following setup >> >> - VLAN terminated on Cisco N7k >> - wireless clients can't talk to each other >> - no IPv4 at all on the network (blocked by Wireless ACLs) >> - /64 SLAAC, on-link flag in RA not set >> - O-bit set in RA (stateless DHCPv6) >> - DHCPv6 relay to ISC DHCP, handing out a dedicated DNS64 resolver >> - DNS64 resolver on BIND 9.9, with our own network specific NAT64 prefix >> (not 64:ff9b::/96) >> - NAT64 gateway with Tayga on Linux >> >> The setup works quite well Linux, Windows (as well as NAT64/DNS64 >> without 464XLAT works). It doesn't work on Android due to lack of DHCPv6 >> of course. I think I had tested it with IOS 9.something and it worked >> there as well. >> >> Today we've received a report that IOS 10 devices cannot use it. I tried >> myself with an iPad running IOS 10.0.2 and I'm unable to use it either. >> >> - device does not show any errors about internet connectivity >> - device configures two IPv6 addresses and router from RA >> - device receives DNS64 nameserver from stateless DHCPv6 >> - device eventually configures an autoconf IPv4 address (169.254.x.x) >> without a gateway >> - I see A/AAAA DNS queries to the DNS64 server >> - neither IPv4 nor IPv6 nor dualstacked websites work, the browser just >> times out. I cannot see any network activity of the device (but it's >> hard to tell, since I'm currently at home) >> >> I don't have an older iOS device to crosscheck. >> >> Does anyone have any ideas what could be wrong? >> >> Bernhard >> > -- SY, Jen Linkova aka Furry
