RFC 6554
An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)
RFC 6554 💖 An IPv6 Routing Header for Source Routes with RPL
Okay bestie, this one is the Standards Track doc that gives RPL (the Routing Protocol for Low-Power and Lossy Networks) its own IPv6 Routing header for source routes. 🎀 It's RFC 6554, published March 2012, ISSN 2070-1721. The authors are J. Hui (Cisco Systems), JP. Vasseur (Cisco Systems), D. Culler (UC Berkeley), and V. Manral (Hewlett Packard Co.). ✨ The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅.
Abstract
okay so LLN routers can be super memory-limited, like they can only hold a handful of routes 😭 but sometimes you still NEED those routers to deliver packets to nodes inside the LLN 🥺. RPL can stash most (or all) of the routes on one router, the DAG root (Directed Acyclic Graph root), or on a few routers, and then forward IPv6 datagrams with source routing 🧚. That way the memory-starved routers don't need huge routing tables. This doc defines a brand new IPv6 Routing header type for delivering datagrams inside an RPL routing domain 🦋.
Status of This Memo
This is an Internet Standards Track document 🌸.
It's a product of the IETF (Internet Engineering Task Force), it reflects IETF community consensus, got public review, and was approved for publication by the IESG (Internet Engineering Steering Group). If you want more on Internet Standards, check Section 2 of RFC 5741 📚.
For the current status, errata, and where to send feedback, go to http://www.rfc-editor.org/info/rfc6554 💌.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 🔒.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc 📜. Code components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes 🫶.
Table of Contents
1. Introduction ....................................................2
1.1. Requirements Language ......................................3
2. Overview ........................................................3
3. Format of the RPL Routing Header ................................6
4. RPL Router Behavior .............................................8
4.1. Generating Source Routing Headers ..........................8
4.2. Processing Source Routing Headers ..........................9
5. Security Considerations ........................................11
5.1. Source Routing Attacks ....................................11
5.2. ICMPv6 Attacks ............................................12
6. IANA Considerations ............................................12
7. Acknowledgements ...............................................12
8. References .....................................................12
8.1. Normative References ......................................12
8.2. Informative References ....................................131. Introduction ✨
okay so RPL is a distance vector IPv6 routing protocol built for LLNs [RFC6550] 🌈. LLNs are usually short on resources: data rate, processing power, energy, and memory are all limited 🔋. Some LLN setups have routers whose memory only lets them keep a few default routes and nothing else. But you may still need those memory-limited routers to forward datagrams and keep every destination inside the LLN reachable 🥹.
To use paths that run through these memory-limited routers, RPL leans on source routing 💅. In one RPL deployment model, the more capable routers gather routing info and build paths to any destination in the RPL routing domain. What's missing is a source routing mechanism that IPv6 supports for actually delivering the datagrams 👑, and that's the gap this doc fills.
This document specifies the Source Routing Header (SRH) for use strictly between RPL routers in the same RPL routing domain 🎀. An RPL routing domain is a bunch of RPL routers under a single administration. Network management draws the domain boundaries by marking some links as exterior (inter-domain) links 🗺️.
1.1. Requirements Language 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶.
2. Overview 🌸
The SRH format is borrowed from the Type 0 Routing header (RH0) [RFC2460] 🦋. The SRH adds something new, though: it can compact the source route entries when they all share the same prefix as the IPv6 Destination Address of a packet carrying an SRH. That's super common in LLNs that use source routing ✨. Compaction saves scarce resources like channel capacity 🍓.
The SRH also processes things differently from RH0, and that's because RH0 got deprecated over security concerns [RFC5095] 😬. Here's how the SRH handles it:
- RPL routers enforce a strict source route policy. Every single IPv6 hop between the source and the destination of the source route has to be spelled out inside the SRH. The source route can also be just a subset of the path between the real source and destination, which gets covered more below 🧚.
- An SRH only gets used between RPL routers in one RPL routing domain. RPL Border Routers connect the RPL domain to other RPL domains and to IP domains running other routing protocols, and they don't let datagrams that already carry an SRH enter or leave the RPL routing domain 🚫.
- An RPL router drops any datagram that includes multiple addresses assigned to interfaces on that same router. That's how it avoids forwarding loops 🔁.
There are two cases that decide how an SRH gets included when an RPL router needs one to deliver a datagram to its destination 🌈.
- If the SRH spells out the complete path from source to destination, the router puts the SRH right in the datagram itself 💅.
- If the SRH only covers part of the path from source to destination, the router uses IPv6-in-IPv6 tunneling [RFC2473] and places the SRH in the outer IPv6 header. Tunneling makes sure the datagram gets delivered unmodified and that ICMP errors go back to the source of the SRH, not the source of the original datagram 🛸.
In an RPL network, Case 1 happens when both source and destination sit inside one RPL routing domain and a single SRH spells out the whole path from source to destination 🎀:
+--------------------+
| |
| (S) -------> (D) |
| |
+--------------------+
RPL Routing DomainIn that scenario, datagrams going from source, S, to destination, D, have this packet structure 💖:
+--------+---------+-------------//-+
| IPv6 | Source | IPv6 |
| Header | Routing | Payload |
| | Header | |
+--------+---------+-------------//-+S's address rides in the IPv6 header's Source Address field 🧚.
D's address is in the last entry of the SRH for every hop except the last one. On the last hop, D's address is in the IPv6 header's Destination Address field of the packet carrying the SRH 🦋.
In an RPL network, Case 2 happens for every datagram whose source and/or destination sits outside the RPL routing domain 🌏. Here are the layouts:
+-----------------+
| |
| (S) --------> (R) --------> (D)
| |
+-----------------+
RPL Routing Domain
+-----------------+
| |
(S) --------> (R) --------> (D) |
| |
+-----------------+
RPL Routing Domain
+-----------------+
| |
(S) --------> (R) ------------> (R) --------> (D)
| |
+-----------------+
RPL Routing DomainIn those scenarios, R can be a RPL Border Router (connecting to other routing domains) or a RPL Router (connecting to hosts) 💅. While the datagrams are inside the RPL routing domain, they look like this:
+--------+---------+--------+-------------//-+
| Outer | Source | Inner | IPv6 |
| IPv6 | Routing | IPv6 | Payload |
| Header | Routing | Header | Header |
+--------+---------+--------+-------------//-+
<--- Original Packet --->
<--- Tunneled Packet --->Heads up: the RPL router is the one that adds and removes the outer header (SRH included) 🫶.
Case 2 can also happen whenever an RPL router needs to insert a source route while forwarding a datagram 🍓. One RPL use case is to send all RPL traffic through a Border Router and let that Border Router use source routes to deliver datagrams to their final destinations 🧁. When the SRH goes in tunneled mode, the Border Router wraps the received datagram unmodified in IPv6-in-IPv6 and puts an SRH in the outer IPv6 header 🎀:
+-----------------+
| |
| (S) -------\ |
| \ |
| (LBR)
| / |
| (D) <------/ |
| |
+-----------------+
RPL Routing DomainIn that scenario, datagrams travel from S to D through the Low-Power and Lossy Network Border Router (LBR) 🌸. Between S and the LBR, the datagrams get routed along the DAG that RPL built, and they don't carry an SRH. The LBR wraps received datagrams unmodified in IPv6-in-IPv6, and the SRH rides in the outer IPv6 header 💜.
3. Format of the RPL Routing Header ✨
okay so bestie, here's the layout of the Source Routing Header 🎀 it's all neat little 32-bit rows, no cap:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Hdr Ext Len | Routing Type | Segments Left |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CmprI | CmprE | Pad | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Addresses[1..n] .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Now let's go field by field 💖
Next Headeris an 8-bit selector 🦋. It tells you what type of header comes right after the Routing header, and it uses the same values as the IPv6 Next Header field [RFC2460].Hdr Ext Lenis an 8-bit unsigned integer 🔢. It's the length of the Routing header in 8-octet units, not including the first 8 octets. Note that when Addresses[1..n] are compressed (i.e., value of CmprI or CmprE is not 0), Hdr Ext Len does not equal twice the number of Addresses. so don't assume it does, bestie 🙈Routing Typeis an 8-bit selector that identifies the particular Routing header variant. An SRH should set the Routing Type to 3 ✨Segments Leftis an 8-bit unsigned integer 💅. It's the number of route segments remaining, i.e., the number of explicitly listed intermediate nodes still to be visited before reaching the final destination. The originator of an SRH sets this field to n, the number of addresses contained in Addresses[1..n].CmprIis a 4-bit unsigned integer 🌸. It's the number of prefix octets from each segment, except than the last segment (i.e., segments 1 through n-1), that are elided. For example, an SRH carrying full IPv6 addresses in Addresses[1..n-1] sets CmprI to 0.CmprEis a 4-bit unsigned integer 🌈. It's the number of prefix octets from the last segment (i.e., segment n) that are elided. For example, an SRH carrying a full IPv6 address in Addresses[n] sets CmprE to 0.Padis a 4-bit unsigned integer 🧚. It's the number of octets used for padding after Address[n] at the end of the SRH.Reservedis unused, so it's giving "not my problem" 💀. It MUST be initialized to zero by the sender and MUST be ignored by the receiver.Address[1..n]is a vector of addresses, numbered 1 to n 🍓. Each vector element in [1..n-1] has size (16 - CmprI), and element [n] has size (16-CmprE). The originator of an SRH places the next (first) hop's IPv6 address in the IPv6 header's IPv6 Destination Address, and the second hop's IPv6 address as the first address in Address[1..n] (i.e., Address[1]).
The SRH shares the same basic format as the Type 0 Routing header [RFC2460] 👑. When carrying full IPv6 addresses, the CmprI, CmprE, and Pad fields are set to 0, and the only difference between the SRH and Type 0 encodings is the value of the Routing Type field. Lowkey iconic, right?
Here's the main reason the compression stuff exists ✨. A common network configuration for a RPL routing domain is that all routers within it share a common prefix. So the SRH introduces the CmprI, CmprE, and Pad fields to allow compaction of the Address[1..n] vector when all entries share the same prefix as the IPv6 Destination Address field of the packet carrying the SRH. The CmprI and CmprE fields indicate the number of prefix octets shared with the IPv6 Destination Address of the packet carrying the SRH. The shared prefix octets are not carried within the Routing header, and each entry in Address[1..n-1] has size (16 - CmprI) octets while Address[n] has size (16 - CmprE) octets. When CmprI or CmprE is non-zero, there may exist unused octets between the last entry, Address[n], and the end of the Routing header. The Pad field indicates the number of those unused octets used for padding. Note that when CmprI and CmprE are both 0, Pad MUST carry a value of 0 🫶
Some rules to keep you out of trouble 🙈
The SRH MUST NOT specify a path that visits a node more than once. When generating an SRH, the source may not know the mapping between IPv6 addresses and nodes. Minimally, 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.
Also, multicast addresses MUST NOT appear in an SRH or in the IPv6 Destination Address field of a datagram carrying an SRH. Not on my watch 😭
4. RPL Router Behavior 🔥
4.1. Generating Source Routing Headers
okay so, to deliver an IPv6 datagram to its destination, a router may need to generate a new SRH and specify a strict source route 🧚. When the router is the source of the original packet and the destination is known to be 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 [RFC2473] and place the SRH in the tunnel header. Using IPv6-in-IPv6 tunneling ensures that the delivered datagram remains unmodified and that ICMPv6 errors generated by an SRH are sent back to the router that generated the SRH 💜
Now the Hop Limit part is a whole vibe 🦋. When using IPv6-in-IPv6 tunneling, in order to respect the IPv6 Hop Limit value of the original datagram, a RPL router generating an SRH MUST set the Segments Left to less than the original datagram's IPv6 Hop Limit value upon forwarding. In the case that the source route is longer than the original datagram's IPv6 Hop Limit, only the initial hops (determined by the original datagram's IPv6 Hop Limit) should be included in the SRH. If the RPL router is not the source of the original datagram, the original datagram's IPv6 Hop Limit field is decremented before generating the SRH. After generating the SRH, the RPL router decrements the original datagram's IPv6 Hop Limit value by the SRH Segments Left value. Processing the Segments Left and original datagram's IPv6 Hop Limit fields in this way ensures that ICMPv6 Time Exceeded errors occur as would be expected on more traditional IPv6 networks that forward datagrams without tunneling 🌸
Last but not least, fragmentation 🌈. To avoid fragmentation, it is desirable to employ MTU sizes that allow for the header expansion (i.e., at least 1280 + 40 (outer IP header) + SRH_MAX_SIZE), where SRH_MAX_SIZE is the maximum path length for a given RPL network. To take advantage of this, however, the communicating endpoints need to be aware of the MTU along the path (i.e., through Path MTU Discovery). Unfortunately, the larger MTU size may not be available on all links (e.g., 1280 octets on IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) links). However, it is expected that much of the traffic on these types of networks consists of much smaller messages than the MTU, so performance degradation through fragmentation would be limited. Honestly, that's a glow-up for the little guys 🥹
4.2. Processing Source Routing Headers ✨
okay so the routing header isn't even looked at until the packet reaches the node in the Destination Address field of the IPv6 header 🦋 As specified in [RFC2460], that node dispatches on the Next Header field of the header right before it, and that's what wakes up the Routing header module 💖
The SRH is basically meant to be super similar to the Type 0 Routing header from [RFC2460] 🎀 Once the routing header is handled and the IPv6 datagram goes back to the IPv6 module, the IPv6 Destination Address holds the next hop's address. It's giving hop-by-hop vibes ✨
Now the important part 😭 When a router forwards an IPv6 datagram that has an SRH with a non-zero Segments Left value, and the IPv6 Destination Address is not on-link, it MUST drop the datagram and SHOULD send an ICMP Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set to 7 to the packet's Source Address. That code means the IPv6 Destination Address isn't on-link, so the router can't satisfy the strict source route requirement 💀 When generating ICMPv6 error messages, the rules in Section 2.4 of [RFC4443] MUST be observed 🙈
To catch loops in the SRH, a router MUST determine if the SRH includes multiple addresses assigned to any interface on that router. If those addresses show up more than once and are separated by at least one address that isn't assigned to that router, the router MUST drop the packet and SHOULD send an ICMP Parameter Problem, Code 0, to the Source Address. Okay, the loop check adds a lot of per-packet processing overhead, but it's needed to mitigate the bandwidth exhaustion attacks that led to RH0 getting deprecated [RFC5095] 🧚
Here's the algorithm for processing an SRH 🌈
if Segments Left = 0 {
proceed to process the next header in the packet, whose type is
identified by the Next Header field in the Routing header
}
else {
compute n, the number of addresses in the Routing header, by
n = (((Hdr Ext Len * 8) - Pad - (16 - CmprE)) / (16 - CmprI)) + 1
if Segments Left is greater than n {
send an ICMP Parameter Problem, Code 0, message to the Source
Address, pointing to the Segments Left field, and discard the
packet
}
else {
decrement Segments Left by 1
compute i, the index of the next address to be visited in
the address vector, by subtracting Segments Left from n
if Address[i] or the IPv6 Destination Address is multicast {
discard the packet
}
else if 2 or more entries in Address[1..n] are assigned to
local interface and are separated by at least one
address not assigned to local interface {
send an ICMP Parameter Problem (Code 0) and discard the
packet
}
else {
swap the IPv6 Destination Address and Address[i]
if the IPv6 Hop Limit is less than or equal to 1 {
send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard the
packet
}
else {
decrement the Hop Limit by 1
resubmit the packet to the IPv6 module for transmission
to the new destination
}
}
}
}RPL routers are responsible for making sure an SRH only gets used between RPL routers, so here's how that goes 💅
- For datagrams destined to a RPL router, the router processes the packet in the usual way. For example, if the SRH was included using tunneled mode and the RPL router is the tunnel endpoint, the router removes the outer IPv6 header and the SRH at the same time 🎀
- Datagrams destined elsewhere within the same RPL routing domain are forwarded to the correct interface 🦋
- Datagrams destined to nodes outside the RPL routing domain are dropped if the outermost IPv6 header contains an SRH that wasn't generated by the RPL router forwarding the datagram 🚫
5. Security Considerations 🔥
5.1. Source Routing Attacks
Okay, this section is serious bestie 😭 The RPL message security mechanisms defined in [RFC6550] do not apply to the RPL Source Route Header. This specification doesn't give the SRH any confidentiality, integrity, or authenticity protection at all 🔒
[RFC5095] deprecates the Type 0 Routing header because of a bunch of significant attacks that are covered in that document. They include bypassing filtering devices, reaching otherwise unreachable Internet systems, network topology discovery, bandwidth exhaustion, and defeating anycast 💀
Since this document says the SRH is only for use within a RPL routing domain, those attacks can't be launched from outside a RPL routing domain 🛡️ As specified in this document, RPL routers MUST drop datagrams entering or exiting a RPL routing domain that contain an SRH in the IPv6 Extension headers.
Those attacks can still be launched from inside a RPL routing domain though 😬 To mitigate bandwidth exhaustion attacks, this specification asks RPL routers to check for loops in the SRH and drop datagrams that contain them. Attacks like bypassing filtering devices and reaching otherwise unreachable Internet systems aren't as relevant in mesh networks, because the topologies are, by their very nature, highly dynamic 🌸 The RPL routing protocol is designed to provide reachability to all devices within a RPL routing domain, and it may use routes that traverse any number of devices in any order.
Even so, these attacks and others (for example, defeating anycast and routing topology discovery) can still happen within a RPL routing domain when you use this specification 👑
5.2. ICMPv6 Attacks
Generating ICMPv6 error messages can be abused for denial-of-service attacks, by sending an error-causing SRH in back-to-back datagrams 💔 An implementation that correctly follows Section 2.4 of [RFC4443] would be protected by the ICMPv6 rate-limiting mechanism 🛡️
6. IANA Considerations 🌈
This document defines a new IPv6 Routing Type, the "RPL Source Route Header", and IANA has assigned it number 3 🦋
This document also defines a new ICMPv6 Destination Unreachable Code, "Error in Source Routing Header", and IANA has assigned it number 7 ✨
7. Acknowledgements 🫶
The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen Farrell, Richard Kelsey, Suresh Krishnan, Erik Nordmark, Pascal Thubert, Sean Turner, and Tim Winter for their comments and suggestions that helped shape this document 💜
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007.8.2. Informative References
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, March 2012.Authors' Addresses 💌
Jonathan W. Hui
Cisco Systems
170 West Tasman Drive
San Jose, California 95134
USA
Phone: +408 424 1547
EMail: jonhui@cisco.com
JP. Vasseur
Cisco Systems
11, Rue Camille Desmoulins
Issy Les Moulineaux 92782
France
EMail: jpv@cisco.com
David E. Culler
UC Berkeley
465 Soda Hall
Berkeley, California 94720
USA
Phone: +510 643 7572
EMail: culler@cs.berkeley.edu
Vishwas Manral
Hewlett Packard Co.
19111 Pruneridge Ave.
Cupertino, California 95014
USA
EMail: vishwas.manral@hp.com📦 where this page comes from
- ietf: rfc6554 2012-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms