Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane
updates
Extracted elements (29)
A DODAG Configuration option flag (bit 3) is used to signal the new RPI Option Type value network-wide rather than mandating an immediate cutover. This avoids a disruptive flag-day transition (analogous to the ARPANET IPv3-to-IPv4 cutover) by allowing nodes to learn which Option Type is in use before originating traffic.
External routes are advertised using Non-Storing mode DAO messages even inside a Storing mode network so that all packets to external targets flow through the root. This makes the arrangement transparent to intermediate 6LRs, and only the root and the injecting 6LR need to be upgraded to support this function.
The RPI Option Type is changed from 0x63 to 0x23 so that the two high-order action bits become '00' (skip and continue) instead of '01' (discard if unrecognized). This ensures that if an RPL Option leaks into the Internet, RFC 8200-compliant nodes silently skip it rather than dropping the packet, reducing the need for IPv6-in-IPv6 encapsulation on constrained devices.
The RPI was kept mandatory in all Non-Storing downward flows (removing the earlier proposed exception) because RFC 8138 can compress the RPI to three bytes or fewer, removing the bandwidth pressure that motivated the exception and improving compression code-path simplicity.
To avoid a 'flag day' caused by incompatibility between nodes using Option Type 0x63 and those using 0x23, it is suggested that RPL implementations accept both 0x63 and 0x23 when processing the RPL Option header. The DODAG Configuration flag allows incremental deployment.
A node decompressing the RPI-6LoRH compressed header (RFC 8138) MUST decompress using the RPI Option Type that is currently active — either 0x23 (new) or 0x63 (old) — as indicated by the DODAG Configuration option flag.
A node that forwards a packet containing an RPI MUST NOT modify the Option Type of the RPL Option. The Option Type value does not change en route per RFC 8200 Section 4.2.
Advertising external targets using Non-Storing mode DAO messaging, even in a Storing mode network, is RECOMMENDED. This keeps external routes out of the DODAG and routes all packets to external targets through the root, which terminates the IP-in-IP tunnel.
An intermediate router that needs to insert an extension header (e.g., RH3 or RPL Option) into a packet being routed MUST first encapsulate the packet in an additional outer IPv6 header; the new header is placed after the outer IP header. This upholds the IPv6 rule against on-the-fly header insertion.
An RH3 or RPL Option can only be removed by an intermediate router if it is placed in an encapsulating IPv6 header that is addressed to that intermediate router; when doing so, the entire encapsulating header must be removed.
For MOP value 7, a node MUST use the RPI 0x23 option; the DODAG Configuration Option Flags are unassigned for MOP=7 and are not used to signal the RPI type in that context.
If the 6LN is a RUL, the root that encapsulates a packet SHOULD terminate the IP-in-IP tunnel at the parent 6LR rather than all the way to the RUL, since it cannot be assumed that a RUL supports IP-in-IP decapsulation.
If the RPI 0x23 enable flag in the DODAG Configuration option is received with value 1, implementations MUST set the RPL Option Type to 0x23 when originating new packets. If the flag is zero (default), implementations remain compatible with RFC 6553 and originate with 0x63.
In Storing mode for RAL-to-RUL and RUL-to-RUL flows, the IPv6-in-IPv6 header MUST be used; it SHOULD be compressed as specified in RFC 8138 Section 7.
The 6LR that injected an external route MUST undo RFC 8138 compression on the packet before forwarding over that external route, because nodes reachable via external routes are not expected to support RFC 8138.
The DODAG root MUST force the SenderRank field in the RPI to zero before passing a packet out to the Internet, so that Internet nodes do not observe internal RPL Rank information.
The RPI (RPL Packet Information) MUST be present in every single RPL data packet traversing the LLN. It carries RPLInstanceID and Rank information used to detect routing loops and cannot be omitted.
The two high-order bits of the new RPI Option Type MUST be set to '00', and the third (chg) bit remains '1' to indicate mutable data en route; the rightmost five bits remain 0x03 (00011), giving a hex value of 0x23.
When encapsulating or decapsulating IPv6-in-IPv6 packets, RFC 6040 MUST be applied to map the setting of the ECN (Explicit Congestion Notification) field between inner and outer headers.
When forwarding packets, implementations SHOULD use the same value of RPI Type as was received, because the Option Type does not change en route. This allows incremental network upgrades and lets the DODAG root detect which nodes have been upgraded.
IPv6-in-IPv6 encapsulation is used throughout the RPL data plane to allow RPL artifacts (RPI, RH3) to be added or removed by intermediate routers without violating the IPv6 rule against on-the-fly header modification. The outer header is addressed either to the root (upward) or to the end host or 6LR parent of a RUL (downward).
The RPL Packet Information (RPI) is carried in the IPv6 Hop-by-Hop Options header (RPL Option, RFC 6553) and conveys the RPLInstanceID, SenderRank, and direction/flags to detect routing inconsistencies. RFC 8138 provides a compressed alternative encoding (RPI-6LoRH).
The RPL Source Route Header (RH3, RFC 6554) is an IPv6 Routing Header used exclusively in Non-Storing mode to carry the full downward path from root to destination. Intermediate 6LRs decrement Segments Left; the header is consumed (Segments Left = 0) at the last hop but left in place for the destination.
IANA changed MOP value 7 in the RPL Mode of Operation registry from its previous assignment to 'Reserved', reserving it for future expansion of the DODAG Configuration option flag space.
IANA updated the 'DODAG Configuration Option Flags' subregistry to apply only to MOP values 0–6, and assigned bit number 3 to 'RPI 0x23 enable' per this document. Flags for MOP value 7 are left unassigned for future expansion.
IANA updated the 'Option Type in RPL Option' entry to add hex value 0x23 (act=00, chg=1, rest=00011) as the new RPL Option Type. The previous value 0x63 remains registered under RFC 6553.
IPsec Authentication Header (AH) can be applied across the RPL Option and RH3 headers because both are marked mutable-but-recoverable; however, AH cannot protect the values that mutate en route (e.g., SenderRank, Segments Left).
Bit number 3 of the Flags field in the DODAG Configuration option is defined as 'RPI 0x23 enable'. When set, it signals to all DODAG members that they should originate RPL Options with the new 0x23 Option Type rather than the legacy 0x63 value.
The new RPI Option Type field is 0x23 (binary: act=00, chg=1, rest=00011). The previous value was 0x63 (act=01, chg=1, rest=00011). Both values occupy the single Option Type octet of the IPv6 Hop-by-Hop Options header RPL Option.