The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams
updated by
- rfc-9008 — Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane
- rfc-9685 — Listener Subscription for IPv6 Neighbor Discovery Multicast and Anycast Addresses
- rfc-9914 — Root-Initiated Routing State in the Routing Protocol for Low-Power and Lossy Networks (RPL)
Extracted elements (25)
IPv6-in-IPv6 tunneling is mandated for attaching a RPL Option to packets not originated by the forwarding router so that the original packet remains unmodified and ICMPv6 errors are returned to the RPL Option source rather than the original packet source.
RPL employs a slow proactive Trickle-based beaconing process for steady-state topology maintenance and a fast reactive process (temporarily increasing beacon rate) only when inconsistencies are detected via data-path verification, conserving energy and channel capacity in constrained LLN environments.
RPL uses data-path verification (embedding routing state in each forwarded datagram) rather than frequent control-plane beaconing to detect and resolve topology inconsistencies. This bounds control traffic relative to data traffic — there is no need to fix routing issues in the absence of data traffic.
A datagram that already includes an RPL Source Route Header (RFC 6554) does not need to carry the RPL Option, because both the source and intermediate routers guarantee that the SRH is loop-free.
The RPL Option is only for use between RPL routers participating in the same RPL Instance. Routers are responsible for stripping the option before delivering packets outside the RPL domain.
To avoid fragmentation due to tunnel header expansion, deployments should employ MTU sizes of at least 1280 + 40 (outer IP header) + RPL_OPTION_MAX_SIZE bytes. On 6LoWPAN links limited to 1280 octets this may not be achievable, but most LLN traffic is much smaller than the MTU, limiting performance impact.
A RPL device MUST skip over any unrecognized sub-TLVs and attempt to process any additional sub-TLVs that may appear after them. The action taken by any sub-TLV MUST be specified by the RFC of the protocol that defines it.
Before IPv6 decapsulation of a received IPv6-in-IPv6 packet, the RPL router MUST process the RPL Option if one exists. After decapsulation, if the router must forward the original packet to another RPL router, it MUST re-encapsulate the packet using IPv6-in-IPv6 tunneling with the RPL Option.
Datagrams destined to nodes outside the RPL Instance MUST be dropped if the outermost IPv6 header contains a RPL Option not generated by the RPL router forwarding the datagram, preventing the option from escaping the RPL domain.
Datagrams sent between RPL routers MUST include a RPL Option or RPL Source Route Header (RFC 6554) and MAY include both. A datagram with a Source Routing Header need not include the RPL Option since the SRH already guarantees loop freedom.
Fields within the RPL Option that do not change hop-by-hop MUST remain the same as those received from the prior tunnel when the option is re-inserted after re-encapsulation.
Nodes that do not understand Option Type 0x63 on a received packet MUST discard the packet, as mandated by the '01' high-order bits of the Option Type per RFC 2460.
When the router is the source of the original packet and the destination is known to be within the same RPL Instance, it SHOULD include the RPL Option directly within the original packet. Otherwise, routers MUST use IPv6-in-IPv6 tunneling and place the RPL Option in the tunnel header.
RPLInstanceID is an 8-bit field identifying the RPL Instance as defined in RFC 6550 Section 11.2. It allows routers to associate the datagram with the correct DAG topology.
SenderRank is a 16-bit field as defined in RFC 6550 Section 11.2, encoding the rank of the router that last processed and forwarded the packet. It is used by downstream routers to detect DAG inconsistencies.
The Down 'O' flag is a 1-bit field as defined in RFC 6550 Section 11.2, indicating the direction of packet forwarding (downward in the DAG). Processing SHALL follow RFC 6550 Section 11.2 rules.
The Forwarding-Error 'F' flag is a 1-bit field as defined in RFC 6550 Section 11.2, indicating that a child router could not deliver the datagram and is returning it to try a different path. Processing SHALL follow RFC 6550 Section 11.2 rules.
The Option Type field is set to 0x63. The two high-order bits '01' instruct nodes that do not understand the option to discard the packet; the third bit '1' indicates that Option Data may change en route.
The Rank-Error 'R' flag is a 1-bit field as defined in RFC 6550 Section 11.2, indicating detection of a rank-order inconsistency along the forwarding path. Processing SHALL follow RFC 6550 Section 11.2 rules.
IANA assigned value 0x63 (binary: act=01, chg=1, rest=00011) in the Destination Options and Hop-by-Hop Options registry for the RPL Option. The encoding mandates packet discard on non-recognition and permits en-route data mutation.
IANA created the RPL-option-TLV registry for sub-TLVs carried within the RPL Option header. The 8-bit type field ranges 0–255; new codes may be allocated only by IETF Review (RFC 5226). No sub-TLVs are defined in this document.
An attacker can manipulate the Down 'O' flag and SenderRank field to falsely signal a DAG inconsistency, causing targeted RPL routers to reset their Trickle timers and flood the network with DIO messages. Implementations MAY rate-limit such resets to no more than MAX_RPL_OPTION_RANK_ERRORS (recommended: 20) per hour.
In Storing mode, an attacker can set the Forwarding-Error 'F' flag to cause RPL routers to discard valid Downward routing state, disrupting downward traffic delivery. Implementations MAY rate-limit such discards to no more than MAX_RPL_OPTION_FORWARD_ERRORS (recommended: 20) per hour. Non-Storing mode is immune since only the LBR holds Downward state.
The RPL message security mechanisms defined in RFC 6550 do not apply to the RPL Option. The option operates without the authentication or encryption protections available at the RPL control-plane layer.
The RPL Option is carried in an IPv6 Hop-by-Hop Options header immediately following the IPv6 header, with alignment requirement 2n. It contains: Option Type (0x63, 8-bit), Opt Data Len (8-bit), flags byte (O, R, F bits), RPLInstanceID (8-bit), SenderRank (16-bit), followed by optional sub-TLVs.