IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header
updated by
- rfc-9008 — Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane
- rfc-9035 — A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header
- rfc-9914 — Root-Initiated Routing State in the Routing Protocol for Low-Power and Lossy Networks (RPL)
Extracted elements (31)
SRH-6LoRH entries are permanently removed as they are consumed rather than preserved as in standard IPv6 Routing Headers. Smaller frames reduce energy expenditure and improve transmission success on lossy LLN media. Reversing an RH is not useful in current RPL specifications, L2 security protects the path better than an Authentication Header, and RFC 2460 discourages RH reversal without authentication.
The RPI-6LoRH is designated Critical rather than Elective because a non-RPL router that skips it and forwards the packet could reinject it into the wrong RPL Instance, forming routing loops. Dropping the packet on unrecognized Critical headers prevents this failure mode at the cost of requiring homogeneous deployment.
The RPL Option (RFC 6553) in a Hop-by-Hop header consumes 8 bytes per packet, yet the actual RPI payload is only 19 bits. On IEEE 802.15.4 with a 127-byte frame limit, this overhead can force fragmentation. The RPI-6LoRH reduces the per-packet cost to as few as 3 bytes (I=1, K=1), directly addressing 6TiSCH bandwidth and battery constraints.
This specification intentionally omits backward-compatibility mechanisms between nodes supporting 6LoRH compression and those that do not. Targeting simple constrained implementations, it assumes a homogeneous network. Mismatch situations are administrative errors (wrong device or misconfiguration) handled by management alerts, not in-band protocol negotiation.
This specification places the inner IP header as the first header compressed by LOWPAN_IPHC (RFC 6282), keeping the inner packet encoded identically whether or not it is IP-in-IP encapsulated. This preserves existing implementations and achieves better compression than variable per-hop compression because the outer encapsulation endpoint is typically the DODAG root, enabling consistent stateful compression.
If a non-RPL router receives a packet with an SRH-6LoRH or RPI-6LoRH header, it indicates a routing or configuration error. Both headers are Critical, so the non-RPL router will drop the packet rather than forward it. Forwarding would risk forming loops (RPI case) or violating strict source-route constraints (SRH case). Deployments must ensure 6LoRH-compressed packets only traverse RPL routers.
A 6LoRH header MUST always be placed after any Fragmentation Header and/or Mesh Header (RFC 4944) and MUST always be placed before the LOWPAN_IPHC (RFC 6282). It MUST only appear in a zone where the Page 1 context is active (i.e., after a Page 1 Paging Dispatch byte and before any subsequent Paging Dispatch).
All addresses within a single SRH-6LoRH header MUST be compressed to the same length (same Type). To represent hops requiring different compression levels, multiple consecutive SRH-6LoRH headers MUST be used.
For a Local RPL Instance, the address of the DODAG root MUST be explicit — either provided by device configuration or signaled in the packet as the source or destination address. For a Global Instance, the RPLInstanceID in the RPI is sufficient to identify the DODAG root from a local context table.
In strict source routing, the first entry of the first SRH-6LoRH MUST match an address of the router receiving the packet. If the router is not the current segment endpoint, it MUST drop the packet.
It is REQUIRED that in the compressed form, source route addresses be encoded in path order and that compressed SRH headers be placed before the compressed RPI. This ordering enables routers to consume SRH entries as the packet progresses down the LLN without ambiguity.
The Compression Reference for SRH-6LoRH entries MUST be determined in priority order: (1) by explicit configuration (address or 6LoWPAN Context ID), (2) the LOWPAN_IPHC source address when no IP-in-IP encapsulation is present, (3) the Encapsulator Address from IP-in-IP-6LoRH when provided, or (4) the implicitly known DODAG root address.
The encapsulating router that compresses a packet using this specification MUST also place an RPI in the packet when the DODAG cannot be identified without it — specifically when there is more than one DODAG in the network. The RPI must be present even when an SRH header is also placed in the packet.
The IP-in-IP-6LoRH Hop Limit field MUST be at least 1; when it reaches 0 the packet is dropped per RFC 2460. The minimum valid Length of an IP-in-IP-6LoRH header is therefore 1 (Hop Limit only, Encapsulator Address elided).
The RPI SHOULD NOT be omitted for packets going down the RPL graph in Non-Storing mode, even though some implementations do so. The RPI-6LoRH carries the RPLInstanceID needed to identify the DODAG root address used as the compression reference for SRH-6LoRH entries.
To disambiguate headers belonging to inner versus outer IP chains in nested IP-in-IP encapsulations, it is REQUIRED that the compressed IP-in-IP header (IP-in-IP-6LoRH) be placed last in the encoded 6LoRH chain. Headers following the last IP-in-IP-6LoRH are interpreted as belonging to the inner IPv6 header when decompressing.
Upon reception, if the first SRH-6LoRH entry matches one of the router's own addresses, the router MUST consume (pop) that entry before forwarding. Consumed entries are permanently removed and cannot be recovered, unlike standard IPv6 Routing Headers.
Address coalescence expands a compressed IPv6 address by overriding the N rightmost bytes of a reference address with the N-byte compressed value. The reference address may itself be compressed, but MUST be of equal or greater length than the address being coalesced. Type 4 SRH-6LoRH entries (16 bytes) are a complete override with no reference needed.
The 6LoWPAN Routing Header (6LoRH) is a new dispatch type operating in 6LoWPAN Page 1 (Dispatch byte 11110001) using bit pattern 10xxxxxx. It is expressed as a Type-Length-Value (TLV) field in two forms: Elective (101xxxxx, may be skipped if not understood) and Critical (100xxxxx, must not be ignored), each with a separate IANA Type registry.
The Compression Reference for the first address in an SRH header is the source of the encapsulating IPv6 packet (typically the DODAG root in Non-Storing RPL). For each subsequent SRH entry, the reference is the fully expanded address of the preceding entry. An abstract context table indexed by Global RPLInstanceID provides the root address.
The SenderRank field in the RPI can be compressed to 1 byte by eliding the least significant octet when MinHopRankIncrease is a multiple of 256 (the RPL default of DEFAULT_MIN_HOP_RANK_INCREASE = 256 per RFC 6552 makes this the common case). The K flag in RPI-6LoRH signals whether this compression is applied.
IANA creates the 'Critical 6LoWPAN Routing Header Type' registry with 256 values (0–255), assigned via RFC Required. Initial assignments: Types 0–4 for SRH-6LoRH (compressed source routing at increasing address sizes from 1 to 16 bytes), and Type 5 for RPI-6LoRH (compressed RPL Packet Information).
IANA creates the 'Elective 6LoWPAN Routing Header Type' registry with 256 values (0–255), assigned via RFC Required. Initial assignment: Type 6 for IP-in-IP-6LoRH (compressed IP-in-IP encapsulation outer header).
This document reserves two dispatch bit-pattern ranges within 6LoWPAN Dispatch Page 1: 10 1xxxxx (32 values) for Elective 6LoWPAN Routing Headers and 10 0xxxxx (32 values) for Critical 6LoWPAN Routing Headers.
The security considerations of RFC 4944, RFC 6282, and RFC 6553 apply. Using the compressed 6LoRH format is logically equivalent to the full in-line format and is believed not to introduce new threats versus RFC 6550, 6553, and 6554. Although consumed SRH entries are stripped, a node can still detect loops in the remaining path; if the attacker is not part of the loop, a node at the loop's start can detect and remove it.
When a router pops the first SRH-6LoRH entry, four cases apply: (1) Size ≥ 1 — remove first entry, decrement Size; (2) Size = 0, no subsequent SRH-6LoRH — remove the entire header; (3) Size = 0, next SRH-6LoRH Type ≥ current Type — remove current header; (4) Size = 0, next SRH-6LoRH Type < current Type — remove first entry of next header and coalesce it with the current first entry. If no SRH-6LoRH remain, the node is the last router on the source route path.
The Critical 6LoRH (6LoRHC) uses a 2-byte base header: bits 10 0 followed by a 5-bit Type-Specific Extension (TSE) field and an 8-bit Type field. Length is implied by the Type/TSE rather than explicitly encoded in bytes; a node MUST silently discard packets with an unrecognized Critical 6LoRH Type.
The Elective 6LoRH (6LoRHE) uses a 2-byte base header: bits 10 1 followed by a 5-bit Length field (bytes of payload excluding the base 2 bytes) and an 8-bit Type field. A node may ignore and skip a 6LoRHE whose Type is unrecognized, forwarding it unchanged.
The IP-in-IP-6LoRH header (Elective, Type 6) encodes a compressed outer IPv6 header. The 5-bit Length field indicates bytes beyond the 2-byte base: Length=1 means Hop Limit only (Encapsulator Address elided, implying the DODAG root); Length>1 includes a compressed Encapsulator Address of (Length−1) bytes coalesced against the root address.
The RPI-6LoRH header (Critical, Type 5) encodes RPL Packet Information compactly. Byte 1 (TSE): bits O, R, F (from RFC 6553), I (set = RPLInstanceID elided, implying Global Instance 0), and K (set = SenderRank compressed to 1 byte with LSB elided). Followed by optional RPLInstanceID (1 byte if I=0) then SenderRank (1 byte if K=1, else 2 bytes). Minimum encoding (I=1, K=1) is 3 bytes versus 8 bytes for RFC 6553.
The SRH-6LoRH header (Critical, Types 0–4) encodes a compressed source routing list. The 5-bit TSE field is used as Size (hops minus 1, maximum 32), followed by N compressed hop addresses. Type 0 compresses addresses to 1 byte; Type 1 to 2 bytes; Type 2 to 4 bytes; Type 3 to 8 bytes; Type 4 to 16 bytes (uncompressed). Total header length = 2 + address_length × (Size + 1).