IOS 10 (?) and IPv6-only WLAN
lorenzo at google.com
Tue Oct 25 06:32:43 CEST 2016
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
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
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
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...
More information about the ipv6-ops