An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)
Extracted elements (26)
Processing Segments Left and the original datagram's IPv6 Hop Limit in the tunneled case is designed so that ICMPv6 Time Exceeded errors behave as they would on traditional IPv6 networks that forward datagrams without tunneling, preserving expected network diagnostic behavior.
The SRH enforces a strict source route policy (every IPv6 hop must be specified) and is confined to the RPL routing domain to address the security vulnerabilities that led to RH0 deprecation in RFC 5095. Loop detection per-packet is required despite significant processing overhead because it is necessary to mitigate the bandwidth exhaustion attacks that originally motivated RH0 deprecation.
The SRH introduces the CmprI, CmprE, and Pad fields to allow compaction of the Address[1..n] vector when all entries share a common prefix with the IPv6 Destination Address. This is a typical scenario in LLNs where routers in a routing domain share a common prefix, and compaction reduces consumption of scarce channel capacity.
When an SRH specifies only a subset of the path (source or destination outside the RPL domain), IPv6-in-IPv6 tunneling is used to place the SRH in the outer header. This ensures the inner datagram is delivered unmodified and that ICMPv6 errors generated by SRH processing are returned to the router that generated the SRH rather than the original packet source.
The SRH is specified for use strictly between RPL routers within the same RPL routing domain, defined as a collection of RPL routers under a single administration. RPL Border Routers MUST NOT allow datagrams carrying an SRH to enter or exit the RPL routing domain.
The SRH shares the same basic format as the Type 0 Routing header (RH0) from RFC 2460. When CmprI, CmprE, and Pad are all 0 (full IPv6 addresses), the only encoding difference between SRH and RH0 is the Routing Type field value (3 vs. 0).
Multicast addresses MUST NOT appear in an SRH or in the IPv6 Destination Address field of a datagram carrying an SRH.
RPL routers MUST drop datagrams destined to nodes outside the RPL routing domain if the outermost IPv6 header contains an SRH not generated by the forwarding router. Datagrams carrying an SRH MUST NOT be allowed to enter or exit a RPL routing domain.
The Reserved field in the SRH MUST be initialized to zero by the sender and MUST be ignored by the receiver.
The SRH MUST NOT specify a path that visits a node more than once. At minimum, the source MUST ensure that IPv6 addresses do not appear more than once and that the IPv6 Source and Destination addresses of the encapsulating datagram do not appear in the SRH.
To detect loops, a router MUST determine if the SRH includes multiple addresses assigned to any of its interfaces. If such addresses appear more than once separated by at least one address not assigned to that router, the router MUST drop the packet and SHOULD send an ICMPv6 Parameter Problem, Code 0, to the Source Address.
When CmprI and CmprE are both 0, the Pad field MUST carry a value of 0, as there are no unused octets requiring padding.
When forwarding an IPv6 datagram containing an SRH with a non-zero Segments Left value, if the IPv6 Destination Address is not on-link, a router MUST drop the datagram and SHOULD send an ICMPv6 Destination Unreachable (Type 1) message with Code 7 to the packet's Source Address.
When generating an SRH and the router is the source of the original packet and the destination is within the same RPL routing domain, the router SHOULD include the SRH directly within the original packet. Otherwise, the router MUST use IPv6-in-IPv6 tunneling (RFC 2473) and place the SRH in the tunnel header.
When generating ICMPv6 error messages in response to SRH processing errors, the rules in Section 2.4 of RFC 4443 MUST be observed, which includes ICMPv6 rate limiting.
When using IPv6-in-IPv6 tunneling, a RPL router generating an SRH MUST set Segments Left to less than the original datagram's IPv6 Hop Limit value upon forwarding. After generating the SRH, the router decrements the original datagram's IPv6 Hop Limit by the SRH Segments Left value.
CmprI is a 4-bit field indicating the number of prefix octets elided from each intermediate segment (Addresses[1..n-1]). CmprE is a 4-bit field indicating the number of prefix octets elided from the last segment (Address[n]). The elided prefix is taken from the IPv6 Destination Address of the packet carrying the SRH.
The Pad field (4-bit) indicates the number of unused octets used for padding after Address[n] at the end of the SRH, which may arise when CmprI or CmprE is non-zero. The Segments Left field is initialized by the originator to n, the total number of addresses in Addresses[1..n].
The Routing Type field is set to 3 to identify the RPL Source Routing Header variant. This distinguishes it from the Type 0 Routing header (RH0) defined in RFC 2460, which it otherwise shares a basic format with.
This document defines a new ICMPv6 Destination Unreachable Code: 7, assigned to 'Error in Source Routing Header' by IANA, used to signal that the IPv6 Destination Address is not on-link and the strict source route requirement cannot be satisfied.
This document defines a new IPv6 Routing Type value: 3, assigned to the 'RPL Source Route Header' by IANA.
ICMPv6 error message generation triggered by malformed SRH headers can be weaponized for denial-of-service attacks via back-to-back error-causing datagrams. Correct implementation of RFC 4443 Section 2.4 rate limiting on ICMPv6 provides the required protection.
The RPL message security mechanisms defined in RFC 6550 do not apply to the SRH. The SRH specification provides no confidentiality, integrity, or authenticity mechanisms to protect the header. Attacks analogous to those that led to RH0 deprecation (RFC 5095) — including filtering bypass, topology discovery, bandwidth exhaustion, and defeating anycast — can be mounted from within a RPL routing domain.
To mitigate bandwidth exhaustion attacks (the primary concern that deprecated RH0), RPL routers are required to check for loops in the SRH and drop datagrams containing them. Because the SRH is confined to the RPL routing domain, external attackers cannot exploit it; however, internal attackers remain a threat.
SRH processing algorithm: if Segments Left = 0, process next header. Otherwise compute n from (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1; if Segments Left > n, send ICMP Parameter Problem and discard; else decrement Segments Left, compute index i = n - Segments Left, check for multicast or loop, then swap IPv6 Destination with Address[i] and decrement Hop Limit before resubmitting to IPv6 module.
The RPL Source Routing Header (SRH) contains: Next Header (8-bit), Hdr Ext Len (8-bit, in 8-octet units excluding first 8 octets), Routing Type (8-bit, value 3), Segments Left (8-bit), CmprI (4-bit), CmprE (4-bit), Pad (4-bit), Reserved (20-bit), and a variable-length Addresses[1..n] vector where each element in [1..n-1] has size (16 - CmprI) octets and element [n] has size (16 - CmprE) octets.