IOS 10 (?) and IPv6-only WLAN

[Mike Jones]

On 20 October 2016 at 15:16, Bernhard Schmidt <berni at 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