IOS 10 (?) and IPv6-only WLAN

[Lorenzo Colitti]

On Fri, Oct 21, 2016 at 1:01 AM, Mike Jones <mike at 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20161025/fea6deeb/attachment.html