IETF RFC 5942
IPv6 Subnet Model: The Relationship between Links and Subnet Prefixes
Organization: | IETF |
Publication Date: | 1 July 2010 |
Status: | active |
Page Count: | 11 |
scope:
Introduction
IPv4 implementations typically associate a netmask with an address when an IPv4 address is assigned to an interface. That netmask together with the IPv4 address designates an on-link prefix. Nodes consider addresses covered by an on-link prefix to be directly attached to the same link as the sending node, i.e., they send traffic for such addresses directly rather than to a router. See Section 3.3.1 of [RFC1122]. Prior to the development of subnetting [RFC0950] and Classless Inter-Domain Routing (CIDR) [RFC4632], an address's netmask could be derived directly from the address simply by determining whether it was a Class A, B, or C address. Today, assigning an address to an interface also requires specifying a netmask to use. In the absence of specifying a specific netmask when assigning an address, some implementations would fall back to deriving the netmask from the class of the address.
The behavior of IPv6 as specified in Neighbor Discovery (ND) [RFC4861] is quite different. The on-link determination is separate from the address assignment. A host can have IPv6 addresses without any related on-link prefixes or can have on-link prefixes that are not related to any IPv6 addresses that are assigned to the host. Any assigned address on an interface should initially be considered as having no internal structure as shown in [RFC4291].
In IPv6, by default, a host treats only the link-local prefix as on-link.
The reception of a Prefix Information Option (PIO) with the L-bit set [RFC4861] and a non-zero valid lifetime creates (or updates) an entry in the Prefix List. All prefixes on a host's Prefix List (i.e., those prefixes that have not yet timed out) are considered to be on-link by that host.
The on-link definition in the Terminology section of [RFC4861], as modified by this document, defines the complete list of cases in which a host considers an address to be on-link. Individual address entries can be expired by the Neighbor Unreachability Detection mechanism.
IPv6 packets sent using the Conceptual Sending Algorithm as described in [RFC4861] only trigger address resolution for IPv6 addresses that the sender considers to be on-link. Packets to any other address are sent to a default router. If there is no default router, then the node should send an ICMPv6 Destination Unreachable indication as specified in [RFC4861] -- more details are provided in the "Host Behavior" and "Host Rules" sections of this document. (Note that [RFC4861] changed the behavior when the Default Router List is empty.
In the old version of Neighbor Discovery [RFC2461], if the Default Router List is empty, rather than sending the ICMPv6 Destination Unreachable indication, the [RFC2461] node assumed that the destination was on-link.) Note that ND is scoped to a single link. All Neighbor Solicitation (NS) responses are assumed to be sent out the same interface on which the corresponding query was received without using the Conceptual Sending Algorithm.
Failure of host implementations to correctly implement the IPv6 subnet model can result in lack of IPv6 connectivity. See the "Observed Incorrect Implementation Behavior" section for details.
This document deprecates the last two bullets from the definition of "on-link" in [RFC4861] to address security concerns arising from particular ND implementations.
Host behavior is clarified in the "Host Behavior" and "Host Rules" sections.
Document History
