Mailing List Archive

Hi,

Update for the archive:

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.

Bernhard

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
>

On Thu, Oct 20, 2016 at 11:16 PM, Bernhard Schmidt <berni@birkenwald.de>
wrote:

> 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.
>

Hmm. It seems that it would be useful to find out if the RFCs are at fault.
On the face of it this seems like a bug in the iPad's IPv6 stack - if the
NS came in with a TTL of 255 it seems reasonable to reply on-link. But it
does seem to be a bit of a grey area - I suppose you could argue that the
device shouldn't reply because the route back to the NS sender is not
directly-connected (though that seems like a weak argument).

If you remove the global address from the first-hop router, such that the
NSes always come from link-local addresses, do things work?

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

On 20 October 2016 at 15:16, Bernhard Schmidt <berni@birkenwald.de> wrote:
> Hi,
>
> Update for the archive:
>
> 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.
>

You seem to have hit a bug with the language of the RFCs. I suspect if
you set your router to source from link local it will also resolve it
without having to specify the global prefix as being on-link.

RFC4861 says:

11.2. The protocol reduces the exposure to the above threats in the
absence of authentication by ignoring ND packets received from
off-link senders.

However, they specify to use the hop limit to detect on-link rather
than source address which does raise some ambiguity - My
interpretation is that it is/was correct to accept an on-link ND
packet from an off-link source as per the original RFC.

RFC5942 however is there to clarify exactly this area and seems to
change that behaviour.

3. Host Behavior

The Prefix List is populated via the following means:
* Receipt of a valid Router Advertisement (RA) that specifies a
prefix with the L-bit set. Such a prefix is considered
on-link for a period specified in the Valid Lifetime and is
added to the Prefix List. (The link-local prefix is
effectively considered a permanent entry on the Prefix List.)
* Indication of an on-link prefix (which may be a /128) via
manual configuration, or some other yet-to-be-specified
configuration mechanism.

Under that interpretation I believe a ND packet sourced from an
address which has not been configured as on-link should be rejected.

That's from a quick search of the RFCs, I would not be surprised if
there was other stuff that was relevant as well.

Also, I am assuming the router is only sourcing NDs from global, and
the RAs are installing a link-local route? because that has a lot more
rules about it, including the interpretation above about what is on
link.

- Mike

On Fri, Oct 21, 2016 at 1:01 AM, Mike Jones <mike@mikejones.in> wrote:

> Under that interpretation I believe a ND packet sourced from an
> address which has not been configured as on-link should be rejected.
>

Actually, I think the IOS behaviour is wrong because it violates RFC 4861
section 7.2.3:

If the Source Address is not the unspecified
address and, on link layers that have addresses, the solicitation
includes a Source Link-Layer Address option, then the recipient
SHOULD create or update the Neighbor Cache entry for the IP Source
Address of the solicitation.
[...]
After any updates to the Neighbor Cache, the node sends a Neighbor
Advertisement response as described in the next section.

RFC 5942 takes care to clarify the behaviour after the change to the IPv6
subnet model:

Note that the Neighbor Cache is a
separate data structure referenced by the Destination Cache, but
entries in the Neighbor Cache are not necessarily in the
Destination Cache. It is quite possible (and intentional) that
entries be added to the Neighbor Cache for addresses that would
not be considered on-link as defined above. For example, upon
receipt of a valid NS, Section 7.2.3 of [RFC4861] states:

If an entry does not already exist, the node SHOULD create a
new one and set its reachability state to STALE as specified
in Section 7.3.3. If an entry already exists, and the cached
link-layer address differs from the one in the received Source
Link-Layer option, the cached address should be replaced by
the received address, and the entry's reachability state MUST
be set to STALE.

The intention of the above feature is to add an address to the
Neighbor Cache, even though it might not be considered on-link
per the Prefix List. [...] This causes no problems in practice, so
long as the
entry only exists in the Neighbor Cache and the address is not
considered to be on-link by the IP forwarding code (i.e., the
address is not added to the Prefix List and is not marked as
on-link in the Destination Cache).

So what should happen in this case is:

1. Router sends NS for host's global address from its global address.
2. Host creates or updates neighbour cache entry for router's global
address.
3. Host replies to NS.
4. The neighbour cache entry for the router's global IPv6 address
remains in the host's neighbour cache, but *is not used* for traffic
because the entry is not marked in the destination cache as being on-link.
(Only a redirect can do that.)