IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
updates
- rfc-4861 — Neighbor Discovery for IP version 6 (IPv6)
Extracted elements (16)
IPv6 on-link determination is separate from address assignment, unlike IPv4 where a netmask assigned with an address implicitly designates an on-link prefix. In IPv6, a host can have addresses without any related on-link prefixes, and on-link prefixes need not be related to any assigned addresses.
ND does not have a mechanism to explicitly signal that a destination is off-link. Instead, a destination is assumed off-link unless there is explicit on-link information. Redirect messages do not signal off-link; they only indicate a preferred next hop.
In access concentrator networks, some host OSes incorrectly invent a /64 on-link prefix when receiving a DHCPv6 address with no prefix length, causing them to attempt address resolution instead of forwarding to the default router. This prevents IPv6 connectivity since no host responds to the spurious resolution.
On hosts with multiple interfaces, ND processing must remain scoped to the link on which it was received. A host must not respond to an NS for an address assigned only to a different interface, and must send NA responses out the same link on which the NS arrived.
RFC 4861 (old version RFC 2461) previously caused a node to assume any destination was on-link when the Default Router List was empty. RFC 5942 corrects this: the host must instead send ICMPv6 Destination Unreachable. Implementations still following the RFC 2461 behavior will fail to send traffic in certain topologies.
RFC 5942 updates RFC 4861 by deprecating the two bullets from the 'on-link' definition in Section 2.1 of RFC 4861: (1) a Neighbor Advertisement is received for the address, and (2) any Neighbor Discovery message is received from the address. Neither constitutes valid evidence that an address is on-link.
If an RA advertises a prefix with the L-bit set and the Valid Lifetime later expires, the host MUST consider addresses of that prefix to be off-link and MUST update its Prefix List accordingly, as specified in RFC 4861 Section 6.3.4.
If the Default Router List is empty and there is no other source of on-link information, a host MUST NOT assume all destinations are on-link and MUST NOT perform address resolution for non-link-local addresses.
Receipt of an NS, NA, or RS message MUST NOT be used to modify the Prefix List. The Neighbor Cache may still be updated, but on-link status inferred solely from receiving these ND messages must not propagate to the Prefix List or Destination Cache.
The assignment of an IPv6 address — whether through SLAAC, DHCPv6, or manual configuration — MUST NOT implicitly cause a prefix derived from that address to be treated as on-link and added to the Prefix List. A host considers a prefix on-link only through explicit means.
When the Default Router List is empty and no on-link information exists, since address resolution cannot be performed for off-link destinations, the host should send an ICMPv6 Destination Unreachable indication rather than attempting on-link delivery.
A Redirect message can signal that an individual address is on-link: if the Target and Destination Address of the Redirect are identical, the Target Address is treated as on-link and the Destination Cache (not the Prefix List) is updated per RFC 4861 Section 8.
The conceptual sending algorithm maintains a Prefix List, Destination Cache, and Default Router List that together form the IP forwarding table for a host. The Neighbor Cache is a separate structure referenced by the Destination Cache; entries in the Neighbor Cache are not necessarily on-link.
The Prefix List is populated by receipt of a valid Router Advertisement with a prefix where the L-bit (on-link flag) is set in the Prefix Information Option (PIO), or via manual configuration. The link-local prefix is effectively a permanent Prefix List entry.
RFC 4861's prior definition of 'on-link' included two bullets — receiving an NA for an address or any ND message from an address — that could allow an on-link attacker to spoof addresses and cause a host to add remote addresses to its Neighbor Cache as on-link. This document deprecates both bullets. US-CERT VU#472363 tracks affected implementations.
While adding unvalidated addresses to the Neighbor Cache (as permitted by RFC 4861 Section 7.2.3 upon NS receipt) creates a potential for spoofing, this is harmless so long as the address is not also added to the Prefix List or marked on-link in the Destination Cache. The fix is to ensure NS/NA/RS receipt never modifies the Prefix List.