Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves
updated by
- rfc-9685 — Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses
- rfc-9926 — Prefix Registration for IPv6 Neighbor Discovery
updates
Extracted elements (33)
External routes for RULs use Non-Storing mode DAO messages unicast directly to the root even when the DODAG operates in Storing mode. This means Non-Storing mode signaling and IPv6-in-IPv6 encapsulation appear as plain traffic to intermediate routers, requiring no state changes in legacy intermediate nodes.
RPL-Unaware Leaves (RULs) use 6LoWPAN ND rather than RPL as the host-to-router interface to limit the attack surface: a RUL cannot perform RPL insider attacks, and address ownership can be protected for all nodes including RULs. Energy or code-space constraints may also prevent RUL participation in RPL.
The specification avoids periodic EDAR/EDAC keep-alive messages traversing the full LLN by having the RPL DODAG root proxy the EDAR/EDAC exchange to the 6LBR upon each DAO refresh. Only the first registration requires a direct EDAR from the 6LR to the 6LBR, since DAD must be verified before the address is injected into RPL.
A RUL must ignore RPL artifacts left in forwarded packets: it skips an SRH (Routing Type 3) when Segments Left is zero, and skips an unrecognized RPL Option (Option Type 0x23) in the Hop-by-Hop Header per RFC 8200. When Segments Left is non-zero, the RUL discards the packet and sends an ICMP Parameter Problem.
RULs are not required to support IPv6-in-IPv6 decapsulation; the IPv6-in-IPv6 tunnel from the root is terminated at the parent 6LR, which decapsulates and forwards the inner packet to the RUL. This is consistent with RFC 8504 basic IPv6 host requirements.
This specification can be deployed incrementally in a network implementing RFC 9008: only the root and the 6LRs connecting RULs need upgrading. Legacy intermediate RPL routers only see plain IPv6 traffic between the root and the 6LR.
A 6LR and a root that support this specification MUST implement the Non-Storing DCO (from RFC 9009), extending its use to Non-Storing MOP for end-to-end signaling between the root and the 6LR.
A 6LR providing reachability services for a RUL MUST include a 6CIO in its RA messages with the L, P, and E flags set to 1.
A RPL DODAG root MUST set the P flag to 1 in the DODAG Configuration option of DIO messages to signal that it proxies the EDAR/EDAC exchange and supports the updated RPL Target option.
A RUL MUST implement RFC 8505 and set both the R flag and T flag in the EARO to 1 to obtain routing services from an RPL router complying with this specification.
A RUL that fails to have the R flag echoed in the NA MUST assume that routing service establishment via that 6LR failed and SHOULD attempt to use another 6LR. The RUL SHOULD ensure one registration succeeds before setting R=0.
If the 6LBR is not co-located with the RPL DODAG root, the 6LBR MUST forward the ND status code to the originator of the EDAR (either the 6LR or the proxying root).
If the RPL DODAG root sets the P flag to 1 in the DODAG Configuration option, the 6LR MUST refrain from sending keep-alive EDAR messages and MUST set the X flag to 1 in the Target option of DAO messages to request proxy EDAR/EDAC by the root. If P=0, the 6LR MUST set X=0 and handle the EDAR/EDAC flow itself.
The 6LN MUST set the I field to 0 in the EARO to signal topological information to be passed to a routing process, regardless of whether the Opaque field is set.
The 6LR MUST set the R flag to 1 in the NA(EARO) returned to the 6LN if and only if the U flag in the RPL Status is 0, indicating successful route injection. If the U flag is 1, the R flag MUST be set to 0.
The two most significant bits of the ARO/EARO Status field MUST be set to 0 by the sender and ignored by the receiver; the range of valid ARO/EARO Status values is reduced from 0–255 to 0–63.
Upon reception of a DAO with an updated Target option where the X flag is 1, the root MUST notify the 6LBR via a proxied EDAR/EDAC exchange. Upon receiving an EDAC, if a DAO is pending the root MUST send a DAO-ACK; otherwise, if the EDAC status is not Success, it MUST send an asynchronous DCO to the 6LR.
When the R flag is set to 1 in an NS(EARO), the 6LR SHOULD inject the host route in RPL using Non-Storing mode signaling and the updated Target option. The 6LR MUST request a DAO-ACK by setting the K flag in the DAO message.
When the ROVRsz field value is above 4 (size undetermined), an implementation SHOULD propagate the whole Target option upward as received to enable verification by an ancestor that supports the upgraded ROVR.
A RPL-Unaware Leaf (RUL) is a 6LN host that does not participate in RPL and relies on its attachment 6LR to inject host routes for its IPv6 addresses into the RPL domain via DAO messages. The RUL uses 6LoWPAN ND (RFC 8505) with the R flag set to request reachability services.
IANA created a 'DODAG Configuration Option Flags for MOP 0..6' entry assigning bit 1 to 'Root Proxies EDAR/EDAC (P)' per RFC 9010. For MOP 7, implementations MUST assume the root performs the proxy operation.
The 'Address Registration Option Status Values' registry (created by RFC 6775) is updated to reduce the valid range from 0–255 to 0–63. The two most significant bits of the original 8-bit field are now reserved.
The 'RPL Target Option Flags' registry is updated to 4 bits (from RFC 6550), with bit 0 assigned to 'Advertiser address in Full (F)' and bit 1 assigned to 'Proxy EDAR Requested (X)', both per RFC 9010.
Two new IANA subregistries are created under the RPL registry: 'RPL Non-Rejection Status Values' (A=0, U=0; 6-bit values 0–63; value 0 = Success) and 'RPL Rejection Status Values' (A=0, U=1; 6-bit values 0–63; value 0 = Unqualified rejection, value 1 = No routing entry). Registration procedure: IETF Review.
A rogue 6LN can cause high churn in the RPL network by constantly registering and deregistering addresses with the R flag set to 1, constituting a DoS attack. Link-layer security and SAVI enforcement at the 6LR are needed to mitigate this. AP-ND (RFC 8928) is suggested to protect address ownership.
Using 6LoWPAN ND as the RUL-to-router interface isolates edge nodes from RPL insider attacks. Compared to RFC 6550 where every node can inject RPL-based attacks, RULs can only interact with 6LRs via 6LoWPAN ND, significantly reducing the attack surface.
When the ROVR field length in a Target option is unknown, the implementation must pass the option upward unchanged, creating a potential covert channel via DAO messages. Implementations SHOULD notify the network management system when an unknown ROVR size is received.
Asynchronous error handling: 6BBR detects address conflict and sends NA(EARO) to 6LBR → 6LBR sends EDAC to root → root sends DCO to 6LR → 6LR sends NA(EARO) with R=0 to 6LN. The RUL then attempts re-registration with a different 6LR.
First RUL registration: 6LN sends NS(EARO) → 6LR sends EDAR to 6LBR → 6LBR returns EDAC → 6LR sends DAO(X=0) to root → root sends DAO-ACK → 6LR returns NA(EARO) to 6LN. On refresh: NS(EARO) → DAO(X=1) to root → root proxies EDAR/EDAC to 6LBR → DAO-ACK → NA(EARO).
The 6LoWPAN Capability Indication Option (6CIO) carries flags including L (node is a 6LR), E (supports EARO-based registration), P (Routing Registrar providing reachability services), D, B, and G, all in a 32-bit option. A 6LR serving RULs must set L, P, and E to 1.
The Extended Address Registration Option (EARO) carries a Type, Length, Status (8 bits), Opaque (8 bits), 4-bit reserved, I (2 bits), R (1 bit), T (1 bit) flags, TID (8 bits), Registration Lifetime (16 bits), and a variable-length ROVR (64–256 bits). The R flag signals whether the 6LR must ensure reachability; T flag enables the TID sequence counter.
The RPL Status field is restructured as: U (1 bit, rejection indicator), A (1 bit, type of status value), StatusValue (6-bit unsigned integer). When A=1 the StatusValue carries a 6LoWPAN ND EARO Status code; when A=0 it carries an RPL status code.
The updated RPL Target Option (Type=0x05) adds F (1 bit, full 128-bit advertiser address), X (1 bit, proxy EDAR requested), Flg (2 reserved bits), ROVRsz (4 bits, ROVR size 64–256 bits encoded as 1–4), Prefix Length (8 bits), variable Target Prefix, and optional ROVR field. The format is backward compatible with RFC 6550.