IOS 10 (?) and IPv6-only WLAN

[Jen Linkova]

On Thu, Oct 20, 2016 at 4:16 PM, Bernhard Schmidt <berni at birkenwald.de> 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