Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses
updates
- rfc-4861 — Neighbor Discovery for IP version 6 (IPv6)
- rfc-6550 — RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
- rfc-6553 — The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams
- rfc-8505 — Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
- rfc-9010 — Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves
Extracted elements (34)
A new RPL MOP 5 (Non-Storing multicast with ingress replication) is introduced rather than extending MOP 3 because MOP 3 requires Storing Mode for both unicast and multicast, which is impractical for typical LLN deployments that use Non-Storing MOP 1 for unicast. The ingress replication approach at the Root avoids requiring Storing mode state in intermediate routers.
MLDv2 was not used for multicast listener subscription in LLNs because MLD relies on multicasting queries to all nodes, which forces nodes to remain awake and wastes energy in duty-cycling low-power networks. Extending RFC 8505's unicast registration mechanism to multicast/anycast allows 6LNs to control when they update their subscription state during their own wake time.
The Consistent Uptime Option (CUO) is introduced instead of relying solely on the 'Registration Refresh Request' NA because routers need a way to detect whether their own state may have been lost (reboot) and to communicate this proactively to dependent nodes, particularly since node reboots are otherwise silent in RFC 8505.
The P-Field value 3 (prefix registration) is reserved but not processed in 6LoWPAN ND because RPL already advertises prefixes by treating unicast addresses as /128 prefixes, while 6LoWPAN ND does not; a future separate document (draft-ietf-6lo-prefix-registration) is expected to define this behavior.
A legacy 6LN will not subscribe multicast addresses and will experience the same service as before. A legacy 6LR that does not set the X flag in the 6CIO will cause an upgraded 6LN to refrain from subscribing multicast or anycast addresses to that router.
Deploying RPL MOP 5 requires creating a new RPL Instance and migrating nodes; it cannot be applied to a live network in-place. In brown-field deployments with legacy devices, it is RECOMMENDED to deploy one RPL Instance (typically MOP 1) for unicast alongside a separate instance with the multicast MOP.
RFC 8505 is a prerequisite; a node that implements this specification MUST also implement RFC 8505. Similarly, a 6LR implementing the RPL extensions of this specification MUST also implement RFC 9010.
A 6LN MUST subscribe all IPv6 anycast addresses it supports using NS(EARO) with the P-Field set to 2 in the EARO.
A 6LN MUST subscribe all IPv6 multicast addresses it listens to using NS(EARO) with the P-Field set to 1, with the sole exception of ff02::1 (all-nodes link-scope multicast address), which is implicitly registered by all nodes.
A router wishing to refresh its state (e.g., upon reboot) SHOULD send an asynchronous NA(EARO) with the new 'Registration Refresh Request' status value; the multicast NA(EARO) MUST be sent to the all-nodes link-scope multicast address ff02::1 with the Target set to the link-local address previously exposed for registrations.
If the P-Field value is inconsistent with the Registered Address (e.g., P-Field=1 for a non-multicast address or P-Field!=1 for a multicast address), the NS(EARO) or EDAR message MUST be dropped.
In MOP 3, an RTO received with a multicast target and P-Field set to 0 MUST be considered as multicast and MUST be processed as if the P-Field is set to 1, for backward compatibility with legacy nodes.
The 6LR MUST ignore a duplicate status in the EDAC for anycast and multicast addresses, since a legacy 6LBR may incorrectly report duplicate registration for these address types.
The 6LR MUST maintain a subscription state per tuple (IPv6 address, ROVR) for both anycast and multicast types of addresses. The 6LBR MUST likewise maintain a subscription state per tuple (IPv6 address, ROVR) for both address types.
The RPL router that merges multiple anycast or multicast advertisements MUST use and advertise the longest remaining lifetime across all origins. When the lifetime expires, it sends a no-path DAO using the same ROVR value.
The TID MUST be incremented each time a 'Registration Refresh Request' NA(EARO) is reissued. The receiver 6LN MUST process one and only one of a series of such messages with comparable and increasing TID values (absolute difference less than SEQUENCE_WINDOW).
When a P-Field value of 3 is received in an EARO or EDAR, the message MUST be dropped; the receiving node MAY reply with a status of 12 'Invalid Registration' or remain silent. When received in an RTO, the value MUST be ignored and the message processed normally.
When forwarding anycast packets Down the RPL DODAG, a RPL router MUST copy and forward to one and only one of the children that advertised the anycast address in their DAO messages.
When RFC 8928 is used to protect anycast or multicast address subscriptions, a key pair MUST be associated with the address before deployment, a ROVR MUST be generated from that key pair, and the key pair MUST be provisioned in each subscribing node.
A new 'X flag' (bit 8) is defined for the 6LoWPAN Capability Indication Option (6CIO) to indicate that the 6LR accepts unicast, multicast, and anycast address registrations per this specification and will ensure routing for addresses with R flag set.
RPL MOP 5 is defined as 'Non-Storing Mode of Operation with ingress replication multicast support', where the RPL Root performs ingress replication by transmitting one copy of each multicast packet to each 6LR that is transit for the multicast target using source-routing headers.
The Registered Address Type Indicator (RATInd) is a new 2-bit P-Field used in the EARO, EDAR, and RPL Target Option (RTO) to signal whether a registered address is unicast (0), multicast (1), anycast (2), or reserved for prefix registration (3).
Two new ARO Status values are introduced: 11 'Registration Refresh Request' (sent in asynchronous NA(EARO) to request re-registration of all previously registered addresses) and 12 'Invalid Registration' (generic error for inconsistent EARO content).
A new 'EDAR Message Flags' registry is created under ICMPv6 Parameters with IETF Review or IESG Approval procedure. Bits 0–1 assigned as P-Field; bits 2–7 unassigned.
A new 'P-Field Values' registry is created under ICMPv6 Parameters with Standards Action registration procedure. Initial values: 0=Unicast, 1=Multicast, 2=Anycast, 3=Unassigned.
The 'Address Registration Option Flags' registry is updated to assign bits 2–3 as the P-Field per RFC 9685 Section 14.1. The 'RPL Target Option Flags' registry is similarly updated to assign bits 2–3 as the P-Field.
The 'Address Registration Option Status Values' registry gains value 11 'Registration Refresh Request' and value 12 'Invalid Registration'. The 'IPv6 Neighbor Discovery Option Formats' registry gains Type 42 'Consistent Uptime Option'.
The 'Mode of Operation' RPL registry gains value 5: 'Non-Storing Mode of Operation with ingress replication multicast support'. The '6LoWPAN Capability Bits' registry gains bit 8: 'X flag: Registration for Unicast, Multicast, and Anycast Addresses Supported'.
The link layer SHOULD be sufficiently protected to prevent rogue access. Using RFC 8505 ND-based subscription (instead of RPL DAO injection) for multicast/anycast provides a better security posture because nodes not trusted to inject RPL messages can be forbidden from participating as RPL-Aware Nodes while still obtaining multicast/anycast delivery via ND operations as RPL-Unaware Leaves.
This specification enables tracking the origin of multicast subscriptions inside the RPL network via the ROVR field in the EARO, representing a first step toward Route Ownership Validation (ROV) in RPL. RFC 8928 can protect anycast and multicast subscriptions if the ROVR values are pre-provisioned in the 6LBR.
The Consistent Uptime Option (CUO, ND Option Type 42) is a new 8-byte IPv6 ND option encoding: Type (8-bit), Length=1 (8-bit), Uptime Exponent (6-bit), Uptime Mantissa (10-bit), S flag (1-bit sleep indicator), U flag (1-bit Peer NSSI validity), 6-bit Reserved flags, NSSI (12-bit), and Peer NSSI (12-bit).
The Extended Address Registration Option (EARO) is updated to add a 2-bit P-Field at bit positions 2–3 (counting 0 to 7 in network order) in the flags byte, with 2 bits of Rsv (MUST be 0) at positions 0–1. The existing I, R, T flags and TID/Registration Lifetime/ROVR fields are unchanged.
The Extended Duplicate Address Request (EDAR) message repurposes the previously reserved Status field as a Flags field, placing the 2-bit P-Field at bit positions 0–1 and 6-bit Reserved (MUST be 0) at positions 2–7. The remaining TID, Registration Lifetime, ROVR, and Registered Address fields are unchanged.
The RPL Target Option (RTO) gains a 2-bit P-Field at bit positions 2–3 in the flags byte (based on Figure 4 of RFC 9010), with Type=0x05, followed by Target Prefix and ROVR fields. The F and X flags at positions 0–1 are unchanged.