Prefix Registration for IPv6 Neighbor Discovery
updates
- rfc-4861 — Neighbor Discovery for IP version 6 (IPv6)
- rfc-6550 — RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
- rfc-8505 — Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
- rfc-8928 — Address-Protected Neighbor Discovery for Low-Power and Lossy Networks
- rfc-9010 — Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves
Extracted elements (30)
In case of overlapping prefix registrations, the longest prefix match wins: if network policy allows overlapping registrations, routes are installed towards the node that registered with the longest matching prefix, all the way to /128. This allows a host and an aggregating router to both register their respective pieces without conflict.
Router Advertisement messages are intentionally not used for prefix advertisement by energy-constrained nodes, because RA would make the node appear as a router to peers and requires support for asynchronous multicast, violating the energy conservation principle of avoiding broadcasts to or from the node.
The EARO is used for prefix registration instead of the Route Information Option (RIO, RFC 4191) because the RIO is not designed to inject routes into routing protocols and lacks the R bit and ROVR equivalents needed for safe redistribution. An RA with RIO also cannot be trusted for safe injection into a routing protocol without the ownership verification that ROVR provides.
Devices may coexist with different levels of support (RFC 8505 only; RFC 8505 + RFC 9685; or this specification as well). A legacy 6LR that does not set the F flag in the 6CIO will cause an upgraded 6LN to skip prefix registration with that router, though the 6LN may register with other supporting 6LRs on the same link.
A node that implements this specification MUST also implement RFC 8505, as this specification does not introduce a new option but modifies existing RFC 8505 options and behaviors.
For prefix routes in RPL, the Path Sequence is used between and only between advertisements for the same Target and from the same origin (same ROVR value); only the freshest advertisement is retained. The RPL router that merges multiple advertisements for the same prefix MUST use and advertise the longest remaining lifetime across all origins.
If the 6LN owns at least one IPv6 address derived from the registered prefix with a non-zero interface ID, it MUST indicate one of those addresses in full in the Target Address field of the NS(EARO). Otherwise it MUST indicate the prefix padded with zeros in the Target Address field.
If the R flag is set in the EARO registration of one or more 6LNs for the same prefix, the 6LR MUST redistribute the prefix in the routing protocols it participates in (e.g., RPL), for the duration equal to the longest non-expired registration lifetime received for that prefix.
The 6LBR MUST ignore a duplicate status returned in the EDAC for prefix EDAR messages, because a legacy 6LBR may incorrectly flag a prefix registration as a duplicate address conflict.
The 6LN MAY set the R flag in the EARO to request prefix redistribution, but the 6LR MUST NOT reregister that prefix to yet another router unless loops are avoided, for example by following a tree structure.
The 6LR MUST maintain a registration state per tuple (IPv6 prefix, prefix length, ROVR) for all registered prefixes, and SHOULD notify the 6LBR via an EDAR message. In turn, the 6LBR MUST maintain a registration state per tuple (IPv6 prefix, ROVR).
The proxy (6LBR acting as ND proxy per RFC 8929) MUST use the P-Field as received in the EDAR or NS(EARO) message to generate the proxied NS(EARO), and MUST use the exact same prefix and prefix length as received for a prefix registration.
Unused bits in the EDAR/EDAC Prefix field MUST be padded with zeros by the sender, and the receiver MUST treat padding as zeroed and MUST overwrite any unused bits with zeros before using the prefix.
Upon a prefix registration with R flag set to 1 and P-Field set to 3 in the EARO, the 6LR MUST inject the prefix in RPL using a prefix RPL Target Option (RTO), and the P-Field in the RTO MUST be set to 3.
Upon receiving an NS(EARO) with the P-Field set to 3, the receiver MUST install a route to the indicated prefix via the source address of the NS(EARO) message.
When a 6LN uses an NS or NA message for a prefix registration, it MUST indicate the prefix length in the EARO (in the field that is used for Status in an NA response). This allows the receiver to distinguish a prefix registration from an address registration.
When P-Field is 3 and the EARO is included in an NS message, the Prefix Length field MUST contain a value in the inclusive range of 16 to 120. When included in an NA message, the field MUST carry a status value regardless of the P-Field setting.
When using AP-ND (RFC 8928) for prefix security, a keypair MUST be created and associated with the prefix before deployment, a ROVR MUST be generated from that keypair, and the keypair MUST be provisioned in each node that needs to register the prefix. The prefix and ROVR MUST be installed in the 6LBR at first registration or by an external mechanism such as IPAM or DHCPv6 snooping.
P-Field value 3 is defined to indicate that the Registered Address represents a unicast prefix rather than a single address. This value completes the 2-bit P-Field originally introduced in RFC 9685, which previously defined values 0 (unicast address), 1 (multicast address), and 2 (anycast address).
The 6CIO F flag (bit 16 in the 48-bit capability array) is a new 1-bit field indicating that the 6LR accepts IPv6 prefix registrations, will route traffic for matching addresses to registering 6LNs, and will redistribute the prefix if the R flag is set. The 6LN uses this capability bit to determine whether the 6LR supports prefix registration before attempting it.
The EARO F (Forwarding) flag is a 1-bit field repurposed from the most significant bit of the Status/Prefix Length byte in NS messages. When set to 1, it indicates the registering node expects routers to forward to the sender packets sourced from within the registered prefix (topologically correct ingress forwarding), as opposed to the sender owning and delivering to the prefix.
The EARO Prefix Length field is a 7-bit unsigned integer occupying bits 1–7 of what is the Status byte in NA messages; it carries the prefix length in NS messages when P-Field is 3. A value of 0 is interpreted as a truncated 128, meaning the registration is for an address rather than a prefix, preserving backward compatibility with RFC 8505.
The term 'Origin' is introduced to name the node that issued a prefix advertisement, either as an NS(EARO) or as a DAO(TIO, RTO). The ROVR field in the EARO identifies the origin and is used by routers to merge multiple advertisements for the same prefix while retaining per-origin freshness (Path Sequence) ordering.
The '6LoWPAN Capability Bits' registry in the ICMPv6 Parameters registry group is updated to assign bit 16 the description 'Registration for prefixes supported (F bit)'. A correction is also made to bit 9, fixing its description from '1' to 'AP-ND Enabled (A bit)'.
The 'P-Field Values' registry in the ICMPv6 Parameters registry group is updated to assign value 3 the meaning 'Registration for a Unicast Prefix'. This exhausts all values of the 2-bit P-Field defined by RFC 9685.
AP-ND (RFC 8928) can be extended to prefix registrations to prevent a rogue node from registering a prefix it does not own, by pre-associating a keypair and ROVR with the prefix and installing them in the 6LBR. Node-local autoconfigured keypairs from RFC 8928 cannot be reused for prefixes because multiple nodes may legitimately register the same prefix.
The link layer SHOULD be sufficiently protected to prevent rogue access; otherwise a rogue node with physical access to the network may inject packets and perform an attack from within. This inherits the security considerations of RFC 8505.
The EARO format for NS messages when P-Field is 3 repurposes the 8-bit Status byte: the MSB is the F flag and bits 1–7 carry the 7-bit Prefix Length. The remaining fields—Opaque, r/C/P/I/R/T flags, TID (8 bits), Registration Lifetime (16 bits), and variable-length ROVR—are unchanged from RFC 8505.
The EDAC (Extended Duplicate Address Confirmation) response to a prefix EDAR echoes the same 15-byte Prefix field and 1-byte r/Prefix-Length field, with a separate 8-bit Status field replacing the P-field/Reserved header word. The ROVR and other fields are carried identically to the corresponding EDAR.
The EDAR message with P=3 carries a 15-byte Prefix field (up to 120 bits, padded with zeros to fill 120 bits) followed by a 1-byte field whose MSB is a reserved 'r' bit and whose lower 7 bits are the Prefix Length. The prefix is appended after the ROVR field, replacing the 16-byte Registered Address used for unicast addresses.