RFC 8138
IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header
IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header 🦋
okay bestie, let's meet the crew 🫶 this is RFC 8138 🎀, published in April 2017 and filed as a Standards Track document, which means it's an actual Internet standard and not just a vibe. ✨ It's part of the IETF stream and its ISSN is 2070-1721 💜
the author squad is P. Thubert, Ed. from Cisco 💅, C. Bormann from Uni Bremen TZI 🌈, L. Toutain from IMT Atlantique 🧚, and R. Cragie from ARM ⭐. the header doesn't list any documents this one obsoletes or updates, so it's standing on its own 👑
Abstract 🌸
okay so this spec introduces a brand new 6LoWPAN dispatch type 🔥 for route-over topologies. it's built to cover the needs of RPL data packet compression first, which is the Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC 6550) 💖. using this dispatch type, it defines a way to compress the RPL Option (RFC 6553) info and Routing Header type 3 (RFC 6554) 🦋, plus an efficient IP-in-IP technique ✨, and it's extensible for more applications later 💅
Status of This Memo 🎀
this is an Internet Standards Track document 💜
it's a product of the Internet Engineering Task Force (IETF) 🌈. it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 👑. more info on Internet Standards lives in Section 2 of RFC 7841 🧚
for the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc8138 🫶
Copyright Notice 💖
Copyright (c) 2017 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) in effect on the date of publication 📜. please read these docs carefully, because they spell out your rights and restrictions for this document 🙈. code components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 💀
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Using the Page Dispatch . . . . . . . . . . . . . . . . . . . 7
3.1. New Routing Header Dispatch (6LoRH) . . . . . . . . . . . 7
3.2. Placement of 6LoRH Headers . . . . . . . . . . . . . . . 8
3.2.1. Relative to Non-6LoRH Headers . . . . . . . . . . . . 8
3.2.2. Relative to Other 6LoRH Headers . . . . . . . . . . . 8
4. 6LoWPAN Routing Header General Format . . . . . . . . . . . . 9
4.1. Elective Format . . . . . . . . . . . . . . . . . . . . . 10
4.2. Critical Format . . . . . . . . . . . . . . . . . . . . . 10
4.3. Compressing Addresses . . . . . . . . . . . . . . . . . . 11
4.3.1. Coalescence . . . . . . . . . . . . . . . . . . . . . 11
4.3.2. DODAG Root Address Determination . . . . . . . . . . 12
5. The SRH-6LoRH Header . . . . . . . . . . . . . . . . . . . . 13
5.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. SRH-6LoRH General Operation . . . . . . . . . . . . . . . 14
5.2.1. Uncompressed SRH Operation . . . . . . . . . . . . . 14
5.2.2. 6LoRH-Compressed SRH Operation . . . . . . . . . . . 15
5.2.3. Inner LOWPAN_IPHC Compression . . . . . . . . . . . . 15
5.3. The Design Point of Popping Entries . . . . . . . . . . . 16
5.4. Compression Reference for SRH-6LoRH Header Entries . . . 17
5.5. Popping Headers . . . . . . . . . . . . . . . . . . . . . 18
5.6. Forwarding . . . . . . . . . . . . . . . . . . . . . . . 19
6. The RPL Packet Information 6LoRH (RPI-6LoRH) . . . . . . . . 19
6.1. Compressing the RPLInstanceID . . . . . . . . . . . . . . 21
6.2. Compressing the SenderRank . . . . . . . . . . . . . . . 21
6.3. The Overall RPI-6LoRH Encoding . . . . . . . . . . . . . 21
7. The IP-in-IP 6LoRH Header . . . . . . . . . . . . . . . . . . 24
8. Management Considerations . . . . . . . . . . . . . . . . . . 26
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10.1. Reserving Space in 6LoWPAN Dispatch Page 1 . . . . . . . 27
10.2. New Critical 6LoWPAN Routing Header Type Registry . . . 28
10.3. New Elective 6LoWPAN Routing Header Type Registry . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 29
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 31
A.1. Examples Compressing the RPI . . . . . . . . . . . . . . 31
A.2. Example of a Downward Packet in Non-Storing Mode . . . . 32
A.3. Example of SRH-6LoRH Life Cycle . . . . . . . . . . . . . 34
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 371. Introduction ✨
Okay bestie, LLNs (Low-Power and Lossy Networks) are all about saving energy 🔋, and that's the number one priority. The other limits, like memory and duty cycling, mostly come from that. Energy usually comes from batteries that are supposed to last for years, or it's scavenged from the environment in tiny amounts. So any protocol meant for LLNs must be designed with saving energy as a strict requirement 💅.
Limiting how much data you send is one way to save energy 🌸. A lot of LLN standards cap the frame size way below the IPv6 Maximum Transmission Unit (MTU) of 1280 bytes. An LLN using the classic Physical Layer (PHY) of IEEE 802.15.4 [IEEE.802.15.4] is limited to 127 bytes per frame 😭. Compressing IPv6 packets over IEEE 802.15.4 is the reason "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks" [RFC6282] got written 🎀.
Route-over techniques for routing inside an LLN are still being developed, and they're giving innovation 🦋. They usually need extra information in the packet for loop prevention, flow identification, source routing info, and more.
For security reasons, and so ICMPv6 errors (see "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" [RFC4443]) can be sent back to the source, an original packet must not be tampered with. Any information that has to be inserted in or removed from an IPv6 packet must go in an extra IP-in-IP encapsulation 🙅.
This happens when a router on the path adds the extra routing info, like the root of a mesh instead of the source node, using the Non-Storing mode of "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550]. It also happens when some routing info needs to be removed from a packet that flows outside the LLN 🌈.
"When to use RFC 6553, RFC 6554 and IPv6-in-IPv6" [RPL-INFO] goes through the different cases where IPv6 headers from the RPL Option for Carrying RPL Information in Data-Plane Datagrams [RFC6553], the Header for Source Routes with RPL [RFC6554], and IPv6-in-IPv6 encapsulation get inserted or removed in LLNs running RPL 🧚.
When using RFC 6282 [RFC6282], the outer IP header of an IP-in-IP encapsulation can be compressed down to 2 octets with stateless compression, or down to 3 octets with stateful compression when context information must be added ✨.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 1 | 1 | TF |NH | HLIM |CID|SAC| SAM | M |DAC| DAM |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 1: LOWPAN_IPHC Base Encoding (RFC 6282)Stateless compression of an IPv6 address can only happen if the address can be deduced from the Media Access Control (MAC) addresses. That means the IP endpoint is also the MAC-layer endpoint 🤔. That's usually not the case in an RPL network, which is generally a multi-hop route-over (aka operated at Layer 3) network. The good news is a better compression is possible that doesn't need variable compressions depending on the hop in the mesh 🍓. It works because the outer encapsulation is usually between the source (or destination) of the inner packet and the root.
Also, the inner IP header can only be compressed by RFC 6282 [RFC6282] if all the fields before it are compressed too. This specification makes the inner IP header the first header to be compressed by RFC 6282 [RFC6282], and it keeps the inner packet encoded the same way whether or not it's encapsulated. That means existing implementations are preserved 💜.
RPL [RFC6550] is designed to optimize routing in constrained LLNs. As part of that, RPL requires the addition of RPL Packet Information (RPI) in every packet, as defined in Section 11.2 of RFC 6550 [RFC6550] 🎀.
"The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams" [RFC6553] spells out how the RPI can be placed in an RPL Option (RPL-OPT) that sits in an IPv6 Hop-by-Hop header 🦋.
That representation takes a total of 8 bytes, but in most cases the actual RPI payload only needs 19 bits 🙈. The Hop-by-Hop header must not flow outside the RPL domain, so it has to be inserted in packets entering the domain and removed from packets leaving it. In both cases, this involves an IP-in-IP encapsulation.
Also, in the Non-Storing Mode of Operation (MOP), RPL requires a Source Routing Header (SRH) in all packets that are routed down an RPL graph 🌸. For that, "An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)" [RFC6554] defines the type 3 Routing Header for IPv6 (RH3).
------+--------- ^
| Internet |
| | Native IPv6
+-----+ |
| | Border Router (RPL Root) + | +
| | | | |
+-----+ | | | tunneled
| | | | using
o o o o | | | IPv6-in-
o o o o o o o o o | | | IPv6 and
o o o o o o o o o o | | | RPL SRH
o o o o o o o o o | | |
o o o o o o o o | | |
o o o o + v +
LLN
Figure 2: IP-in-IP Encapsulation within the LLNWith Non-Storing RPL, even if the source is a node in the same LLN, the packet must first travel up the graph to the root so the root can insert the SRH and send it down the graph 🧗. Whether the packet started inside the LLN or outside it, and whether or not it stays within the LLN, as long as the source of the packet isn't the root itself, the source-routing operation also implies an IP-in-IP encapsulation at the root so it can insert the SRH 💅.
"An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4" [IPv6-ARCH] specifies how IPv6 operates over the mode described in "Using IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the Internet of Things (IoT): Problem Statement" [RFC7554]. The architecture requires both RPL and the 6lo adaptation layer over IEEE 802.15.4. Since 6TiSCH inherits the frame size limits from the MAC layer, it can't afford to spend 8 bytes per packet on the RPI, which is why 6LoWPAN header compression of the RPI is required 😭.
An extensible compression technique is required that simplifies IP-in-IP encapsulation when it's needed and optimally compresses the existing routing artifacts found in RPL LLNs ✨.
This specification extends the 6lo adaptation layer framework ([RFC4944] [RFC6282]) so it can carry routing information for route-over networks based on RPL 🌈. It includes the formats necessary for RPL, and it's extensible for additional formats too 🧚.
2. Terminology 📝
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 💖.
This document uses the terms from, and stays consistent with, "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102] and RPL [RFC6550] 🫶.
The terms "route-over" and "mesh-under" are defined in RFC 6775 [RFC6775] 🦋.
Other terms used in LLNs can be found in "Terminology for Constrained-Node Networks" [RFC7228] 🌸.
The term "byte" is used in its now customary sense, as a synonym for "octet" 💜.
3. Using the Page Dispatch 🎀
"IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch" [RFC8025] extends the 6lo adaptation layer framework ([RFC4944] [RFC6282]) by introducing a concept of "context" in the 6LoWPAN parser. A context is identified by a Page number, and the specification defines 16 Pages 🌈.
This document operates within Page 1, which is indicated by a dispatch value of binary 11110001 ✨.
3.1. New Routing Header Dispatch (6LoRH) 🧚
This specification introduces a new 6LoWPAN Routing Header (6LoRH) to carry IPv6 routing information 💅. The 6LoRH may contain source routing information, like a compressed form of SRH, as well as other kinds of routing information, like the RPI and IP-in-IP encapsulation 🍓.
The 6LoRH is expressed in a 6LoWPAN packet as a Type-Length-Value (TLV) field, which is extensible for future use 🦋.
It is expected that a router that does not recognize the 6LoRH general format detailed in Section 4 will drop the packet when a 6LoRH is present 😭.
This specification uses the bit pattern 10xxxxxx in Page 1 for the new 6LoRH Dispatch. Section 4 describes how RPL artifacts in data packets can be compressed as 6LoRH headers 💖.
3.2. Placement of 6LoRH Headers 🌸
3.2.1. Relative to Non-6LoRH Headers 🎀
In a zone of a packet where Page 1 is active (that is, once the Page 1 Paging Dispatch is parsed, and until another Paging Dispatch is parsed as described in the 6LoWPAN Paging Dispatch specification [RFC8025]), the parsing of the packet MUST follow this specification if the 6LoRH Bit Pattern (see Section 3.1) is found 👑.
With this specification, the 6LoRH Dispatch is only defined in Page 1, so it MUST be placed in the packet in a zone where the Page 1 context is active 💅.
Because a 6LoRH header requires a Page 1 context, it MUST always be placed after any Fragmentation Header and/or Mesh Header as defined in RFC 4944 [RFC4944] 🧗.
A 6LoRH header MUST always be placed before the LOWPAN_IPHC as defined in RFC 6282 [RFC6282]. It's designed so that placing or removing a header encoded with 6LoRH doesn't modify the part of the packet encoded with LOWPAN_IPHC, whether or not there's an IP-in-IP encapsulation. For instance, the final destination of the packet is always the one in the LOWPAN_IPHC, whether or not there is a Routing Header 🫶✨.
3.2.2. Relative to Other 6LoRH Headers ✨
okay bestie, so the "Internet Protocol, Version 6 (IPv6) Specification" [RFC2460] says headers come in chains. Each chain starts with an IPv6 header and ends at either another IPv6 header (that's IP-in-IP 🪆) or an Upper-Layer Protocol (ULP) header. When you strip an outer header, the whole chain goes with it 💀. And when a router inserts new headers, it usually chains them up and wraps everything in IP-in-IP. iconic behavior 💅
Now, with this spec, the chains MUST be compressed in the same order they show up in the uncompressed packet 🔥. So if there's more than one nested IP-in-IP, the first encapsulation (with its whole chain) gets encoded first 👑.
If a packet has a Source Route or a Hop-by-Hop (HbH) Options Header [RFC2460] after the inner IPv6 header (so, no IP-in-IP at all), those headers go in 6LoRH form right before the 6LOWPAN_IPHC that stands in for the IPv6 header (see Section 3.2.1). But if the packet gets encapsulated and extra SRH or HbH headers get added, lining up the 6LoRH headers next to each other can get messy, because it's not clear which header belongs to which chain in the uncompressed form 🙈.
To untangle that, it is REQUIRED that the compressed IP-in-IP header goes last in the encoded chain. So the 6LoRH headers after the last compressed IP-in-IP header get inserted after the IPv6 header that was encoded with 6LOWPAN_IPHC when the packet is decompressed 🦋.
Then there's the SRH and RPI order. The design point here is that SRH entries get used up as the packet moves down the LLN (see Section 5.3). To make that easier in the compressed form, it is REQUIRED that the addresses along the source route path are encoded in path order, and that the compressed SRH goes before the compressed RPI 🌸.
4. 6LoWPAN Routing Header General Format 🎀
The 6LoRH uses the Dispatch Value Bit Pattern of 10xxxxxx in Page 1 💜.
The Dispatch Value Bit Pattern splits into two forms of 6LoRH:
- Elective (6LoRHE), which may be skipped if not understood
- Critical (6LoRHC), which may not be ignored
For each form, a Type field encodes the type of 6LoRH.
Heads up: each form has its own registry for the Type field. That means a value defined for one form could be redefined in the future for the other form 👀.
4.1. Elective Format 🌸
The 6LoRHE uses the Dispatch Value Bit Pattern of 101xxxxx. A 6LoRHE may be ignored and skipped in parsing. If it's ignored, the 6LoRHE gets forwarded with no change inside the LLN ✨.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
<-- Length -->
Figure 3: Elective 6LoWPAN Routing HeaderLength: Length of the 6LoRHE expressed in bytes, excluding the first 2 bytes. This lets a node skip a 6LoRHE header it doesn't support and/or can't parse, for instance, if theTypeisn't recognized 🙃.Type: Type of the 6LoRHE
4.2. Critical Format 💜
The 6LoRHC uses the Dispatch Value Bit Pattern of 100xxxxx.
A node that does not support the 6LoRHC Type MUST silently discard the packet 😭.
Note: A situation where a node receives a message with a Critical 6LoWPAN Routing Header that it does not understand should not occur and is an administrative error, see Section 8.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|0| TSE | Type | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
<-- Length implied by Type/TSE -->
Figure 4: Critical 6LoWPAN Routing HeaderType-Specific Extension (TSE): The meaning depends on theType, which must be known in all of the nodes. How the TSE is read depends on theTypefield that follows. For instance, it may be used to carry control bits, the number of elements in an array, or the length of the rest of the 6LoRHC expressed in a unit other than bytes 🧚.Type: Type of the 6LoRHC
4.3. Compressing Addresses 🦋
The general technique used in this document to compress an address is to first find a reference that has a long prefix match with that address, then elide the matching piece. To rebuild the compressed address, the receiving node does the coalescence process described in Section 4.3.1 🧩.
One possible reference is the root of the RPL Destination-Oriented Directed Acyclic Graph (DODAG) being traversed. 6LoRH uses it as the reference for compressing an outer IP header in an IP-in-IP encapsulation. If the root is the source of the packet, this lets you fully elide the source address in the compressed IP header 🤯. If the root isn't the encapsulator, the Encapsulator Address can still be compressed using the root as the reference. How the root's address gets determined is covered in Section 4.3.2.
Once the source address of the packet is determined, it becomes the reference for compressing the addresses in compressed SRH headers that sit inside the IP-in-IP encapsulation in the uncompressed form 💖.
4.3.1. Coalescence ✨
An IPv6 compressed address gets coalesced with a reference address by overriding the N rightmost bytes of the reference address with the compressed address, where N is the length of the compressed address, as indicated by the Type of the SRH-6LoRH header in Figure 7.
The reference address MAY be a compressed address as well. In that case, it MUST be compressed in a form that is of an equal or greater length than the address being coalesced.
A compressed address is expanded by coalescing it with a reference address. In the particular case of a Type 4 SRH-6LoRH, the address is expressed in full and the coalescence is a complete override, as illustrated in Figure 5 🎀.
RRRRRRRRRRRRRRRRRRR A reference address, which may be
compressed or not
CCCCCCC A compressed address, which may be
shorter or the same as the reference
RRRRRRRRRRRRCCCCCCC A coalesced address, which may be the
same compression as the reference
Figure 5: Coalescing Addresses4.3.2. DODAG Root Address Determination 💖
Stateful address compression needs some state installed in the devices to store the compression information that gets elided from the packet. That state lives in an abstract context table, and some form of index in the packet is used to pull the compression information out of that table 📇.
With RFC 6282 [RFC6282], the state is given to the stack by the 6LoWPAN Neighbor Discovery Protocol (NDP) [RFC6775]. NDP exchanges the context through the 6LoWPAN Context Option in Router Advertisement (RA) messages. In the compressed form of the packet, the context can be signaled in a Context Identifier Extension.
With this spec, the compression information is provided to the stack by RPL, and RPL exchanges it through the DODAGID field in the DAG Information Object (DIO) messages, as described in more detail below. In the compressed form of the packet, the context can be signaled by the RPLInstanceID in the RPI 🌈.
With RPL [RFC6550], the address of the DODAG root is known from the DODAGID field of the DIO messages. For a Global Instance, the RPLInstanceID that is present in the RPI is enough info to identify the DODAG this node participates in and its associated root. But for a Local Instance, the address of the root MUST be explicit, either in some device configuration or signaled in the packet, as the source or the destination address, respectively.
When implicit, the address of the DODAG root MUST be determined as follows:
- If the whole network is a single DODAG, then the root can be well-known and doesn't need to be signaled in the packets. But since RPL doesn't expose that property, it can only be known through a configuration applied to all nodes 🙌.
- Else, the router that encapsulates the packet and compresses it with this specification MUST also place an RPI in the packet, as prescribed by RPL, to enable identification of the DODAG. The RPI must be present even when the router also places an SRH header in the packet.
It is expected that the RPL implementation maintains an abstract context table, indexed by Global RPLInstanceID, that provides the address of the root of the DODAG this node participates in for that particular RPL Instance 🫶.
5. The SRH-6LoRH Header 🌈
5.1. Encoding 💖
okay so the SRH-6LoRH is the compressed glow-up of the SRH from [RFC6554]. Its whole job is to give RPL routers a compact way to carry that source route 🦋
One or more SRH-6LoRH header(s) MAY be placed in a 6LoWPAN packet.
If a non-RPL router gets a packet carrying an SRH-6LoRH header, that's a routing or configuration error (see Section 8) 🙈
And the move for that non-RPL router is to drop the packet, not skip the header and forward it anyway. Nobody gets to be a main character here 💀
The Dispatch Value Bit Pattern for the SRH-6LoRH header marks it as Critical. Routers that understand the 6LoRH general format from Section 4 can't ignore a 6LoRH header of this type. If they don't recognize it, they drop the packet 🔥
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+
|1|0|0| Size |6LoRH Type 0..4| Hop1 | Hop2 | | HopN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- -+- -+ ... +- -+ Where N = Size + 1
Figure 6: The SRH-6LoRHThe 6LoRH Type tells you the compression level used for that header ✨
The fields after the 6LoRH Type are compressed addresses for the consecutive hops, listed from first hop to last hop 🌸
All the addresses in a given SRH-6LoRH header MUST be compressed in an identical fashion, so the Length of the compressed form is the same for every one of them 💅
To get different degrees of compression, multiple consecutive SRH-6LoRH headers MUST be used 🎀
Type 0 means the address is squished down to one byte, and Type 4 means the full address sits in the SRH-6LoRH with no compression at all. Here's the full list of Types and their compression levels, Figure 7 style 💜
+-----------+----------------------+
| 6LoRH | Length of compressed |
| Type | IPv6 address (bytes) |
+-----------+----------------------+
| 0 | 1 |
| 1 | 2 |
| 2 | 4 |
| 3 | 8 |
| 4 | 16 |
+-----------+----------------------+ Figure 7: The SRH-6LoRH TypesFor an SRH-6LoRH header, the TSE field gets used as a Size, which encodes the number of hops minus 1. So a Size of 0 means one hop, and the maximum you can encode is 32 hops. (If you need to express more than 32 hops, you can chain a sequence of SRH-6LoRH elements together 🧚) That means the Length, in bytes, of an SRH-6LoRH header is:
2 + Length_of_compressed_IPv6_address * (Size + 1)5.2. SRH-6LoRH General Operation 🦋
5.2.1. Uncompressed SRH Operation ✨
In the uncompressed form, when the root generates or forwards a packet in Non-Storing mode, it needs to include a Source Routing Header [RFC6554] to signal a strict source route path to a final destination down the DODAG 🌈
All the hops along the path, except the first one, get encoded in order in the SRH. The last entry in the SRH is the final destination. The destination in the IPv6 header is the first hop along the source route path. The intermediate hops do a swap, and the Segments Left field tells you which entry in the Routing Header [RFC2460] is active right now 🔥
The current destination of the packet is the end of the current segment, and it's always shown in the destination address of the IPv6 header 👑
5.2.2. 6LoRH-Compressed SRH Operation 💅
Here the SRH-6LoRH behaves differently. There's no swap. A forwarding router that matches the first entry in the first SRH-6LoRH effectively consumes that entry when it forwards the packet. So a compressed source-routed packet gets smaller as it travels, and the routing info gets lost along the way 😭 That also means an SRH encoded with 6LoRH can't be recovered and can't be protected.
When compressed with this specification, all the remaining hops MUST be encoded in order in one or more consecutive SRH-6LoRH headers. Whether or not an SRH-6LoRH header is there, the address of the final destination is always shown in the LOWPAN_IPHC along the whole path. Examples are in Appendix A 🎀
For a compressed source-routed packet, the current destination (the end of the current segment) is shown in the first entry of the first SRH-6LoRH. In strict source routing, that entry MUST match an address of the router that receives the packet 💜
The last entry in the last SRH-6LoRH is the last router on the way to the final destination in the LLN. That router can be the final destination itself, if it's desirable to carry a whole IP-in-IP encapsulation all the way there. Otherwise, it's the RPL parent of the final destination, or a router acting as a 6LoWPAN Router (6LR) [RFC6775] for the destination host, advertising that host as an external route to RPL 🌸
If the SRH-6LoRH header sits inside an IP-in-IP encapsulation, the last router removes the whole chain of headers. Otherwise, it removes just the SRH-6LoRH header 🫶
5.2.3. Inner LOWPAN_IPHC Compression 🧚
6LoWPAN ND [RFC6282] is built to support more than one IPv6 address per node and per Interface Identifier (IID). An IID is typically derived from a MAC address, which helps optimize the LOWPAN_IPHC compression ✨
Link-local addresses get compressed with stateless address compression (S/DAC=0). The other addresses come from different prefixes, and they can be compressed with stateful address compression based on a context (S/DAC=1) 🦋
Stateless compression only works for the specific link-local prefix, not for the prefix in an encapsulating header. And with stateful compression, the compression reference lives in a context, not in an encapsulating header 🙈
So with IP-in-IP encapsulation, an inner source (respectively destination) IP address can only be compressed in a LOWPAN_IPHC based on the encapsulating IP header if stateful (context-based) compression is used. The compression only operates if the IID in the source (respectively destination) IP address matches in the outer and inner headers, which usually means they point at the same node. This is encoded as S/DAC = 1 and S/AM=11. It must be noted that the outer destination address used to compress the inner destination address is the last entry in the last SRH-6LoRH header 🔥
5.3. The Design Point of Popping Entries 💅
To save energy and boost the odds of successful transmission over lossy media, this specification is designed so that the SRH entries which have already been used get removed from the packet 🌈 This is a bit of a plot twist compared to the usual IPv6 world, where Routing Headers are mutable but recoverable.
With this specification, the packet can be expanded at any hop into a valid IPv6 packet, including an SRH, and then compressed back again. But the decompressed packet along the way won't carry all the consumed addresses it would have carried if it had been forwarded in uncompressed form 😭
Here's what's noted about all this:
- Keeping the whole RH in an IPv6 header is valuable because the receiver can reverse it and use the symmetrical path on the way back.
- Reversing a Routing Header is generally not a good idea. The RH may have been used to steer away from the shortest path for some reason that only applies on the way in (segment routing).
- There's no use in reversing an RH in the present RPL specifications.
- Point-to-Point (P2P) RPL reverses a path that was learned reactively as part of the protocol operation, which is probably a cleaner way than a reversed echo on the data path.
- Reversing a header is discouraged (by RFC 2460 [RFC2460]) for Redirected Header Option (RHO) unless it is authenticated, which requires an Authentication Header (AH). There is no definition of an AH operation for SRH, and there's no indication that the need exists in LLNs.
- AH doesn't protect the RH on the way. AH is a validation at the receiver with the sole value of letting the receiver reverse it.
- An RPL domain is usually protected by L2 security, which secures both RPL itself and the RH in the packets at every hop. That's better security than what AH provides 🫶
In summary, the benefit of saving energy and lowering the chances of loss by sending smaller frames over the LLN is seen as overwhelming compared to the value of possibly reversing the header 👑
5.4. Compression Reference for SRH-6LoRH Header Entries 🌸
To optimize how IP addresses in the SRH headers get compressed, this specification requires that the 6LoWPAN layer identifies an address to use as a reference for the compression 🧚
With this specification, the Compression Reference for the first address found in an SRH header is the source of the IPv6 packet. After that, the reference for each subsequent entry is the address of its predecessor once it's uncompressed ✨
With RPL [RFC6550], an SRH header may only be present in Non-Storing mode, and it may only be placed in the packet by the root of the DODAG, which must be the source of the resulting IPv6 packet [RFC2460]. In this case, the address used as the Compression Reference is the address of the root 🦋
The Compression Reference MUST be determined as follows:
- The reference address may be obtained by configuration. The configuration may indicate either the address in full or the identifier of a 6LoWPAN Context that carries the address [RFC6775], for instance one of the 16 Context Identifiers used in
LOWPAN_IPHC[RFC6282]. - Else, if there is no IP-in-IP encapsulation, the source address in the IPv6 header that is compressed with
LOWPAN_IPHCis the reference for the compression. - Else, if the IP-in-IP compression specified in this document is used and the Encapsulator Address is provided, then the Encapsulator Address is the reference.
- Else, meaning the IP-in-IP compression specified in this document is used and the encapsulator is implicitly the root, the address of the root is the reference 💖
5.5. Popping Headers 🎀
okay so bestie, here's the deal ✨ when a packet lands on a router, the router checks whether the address in the first entry of the first SRH-6LoRH is one of its own addresses 👀 if it is, the router MUST consume that entry before forwarding 💅 and "popping" is basically taking things off a stack, where the stack is really just the sequence of entries sitting in consecutive SRH-6LoRH headers 🥞
popping one entry is a recursive thing 🌀 it goes like this:
- if the Size of the current SRH-6LoRH header is 1 or more (so there are at least 2 entries in the header), the router removes the first entry and decrements the Size by 1 💖
- if the Size of the current SRH-6LoRH header is 0 (so there's only 1 entry in the header) and there is no subsequent SRH-6LoRH after this, then the current SRH-6LoRH is removed 🧚
- if the Size of the current SRH-6LoRH header is 0 and there IS a subsequent SRH-6LoRH, and the Type of that subsequent SRH-6LoRH is equal to or greater than the Type of the current one (meaning the same or less compression, giving the same or larger compressed forms), then the current SRH-6LoRH is removed 🦋
- if the Size of the current SRH-6LoRH header is 0 and there is a subsequent SRH-6LoRH, and the Type of the subsequent one is less than the Type of the current one, the first entry of the subsequent SRH-6LoRH is removed and coalesced with the first entry of the current SRH-6LoRH 🌈
at the end of all that, if there are no more SRH-6LoRH in the packet, then the processing node is the last router along the source route path 👑
the example for all this lives in Appendix A.3 🍓
5.6. Forwarding 🦋
when a router receives a packet with an SRH-6LoRH, it figures out the IPv6 address of the current segment endpoint 🧚
if strict source routing is enforced and this router is NOT the segment endpoint for the packet, then this router MUST drop the packet 💀 no exceptions bestie
if this router IS the current segment endpoint, then it pops its address as described in Section 5.5 and keeps on processing the packet 💅
if there's still an SRH-6LoRH, the router determines the new segment endpoint and routes the packet towards that endpoint 🌸
otherwise, the router uses the destination in the inner IP header to forward or accept the packet 🫶
the segment endpoint of a packet MUST be determined like this 🔥:
- first, the router determines the Compression Reference as discussed in Section 4.3.1 ✨
- then the router coalesces the Compression Reference with the first entry of the first SRH-6LoRH header, as discussed in Section 5.4 💖 and if the SRH-6LoRH header is Type 4, then the coalescence is a full override 🎀
since the Compression Reference is an uncompressed address, the coalesced IPv6 address is also expressed in the full 128 bits 🌈
6. The RPL Packet Information 6LoRH (RPI-6LoRH) 🌸
okay this section is about RPL, and it's giving "important info alert" 🚨 Section 11.2 of the RPL document [RFC6550] specifies the RPL Packet Information (RPI) as a set of fields that RPL routers place in IP packets so they can identify the RPL Instance, detect anomalies, and trigger corrective actions 🔍
the SenderRank is the scalar metric computed by a specialized Objective Function (like the one described in RFC 6552 [RFC6552]) that tells you the Rank of the sender, and it gets modified at each hop 🦋 the SenderRank field is used to validate that the packet is progressing in the expected direction, either upwards or downwards, along the DODAG 🧭
RPL defines "The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams" [RFC6553] to transport the RPI 🎁 it rides in an IPv6 Hop-by-Hop Options Header [RFC2460], and it typically eats 8 bytes per packet 😭
with RFC 6553 [RFC6553], the RPL Option is encoded as 6 octets, and it MUST be placed in a Hop-by-Hop header that adds two more octets, for a total of 8 octets 💅 to keep the header's range limited to just the RPL domain, the Hop-by-Hop header MUST be added to (or removed from) packets that cross the border of the RPL domain 🧱
the 8-byte overhead is detrimental to LLN operation, especially for bandwidth and battery 🔋 those bytes can make a containing frame grow above maximum frame size, which leads to Layer 2 or 6LoWPAN [RFC4944] fragmentation, and that means even more energy spent plus the issues discussed in "LLN Fragment Forwarding and Recovery" [FORWARD-FRAG] 💀
there's also an extra cost in some cases, where you need an IP-in-IP encapsulation to carry the Hop-by-Hop header 🪆 this is needed when the router inserting the Hop-by-Hop header is not the source of the packet, so an error can be returned to that router 🙈 it's also the case when a packet originated by a RPL node has to be stripped of the Hop-by-Hop header before it's routed outside the RPL domain 🌍
so this specification defines an IP-in-IP-6LoRH header in Section 7 🎀 but heads up: removing a 6LoRH header does not require manipulating the packet in the LOWPAN_IPHC, so if the source address in the LOWPAN_IPHC is the node that inserted the IP-in-IP-6LoRH header, then that situation alone does NOT mandate an IP-in-IP-6LoRH header 🫶
Note: some implementations leave out the RPI for packets going down the RPL graph in Non-Storing mode, even though RPL says the RPI should be placed in the packet. With this specification, the RPI is important for indicating the RPLInstanceID, so the RPI SHOULD NOT be omitted. ⚠️
so an RPL packet may carry only an RPI-6LoRH header and no IP-in-IP-6LoRH header 🧚 in that case, the source and destination of the packet are specified by the LOWPAN_IPHC 💖
just like RFC 6553 [RFC6553], the fields in the RPI include an 'O', an 'R', and an 'F' bit, an 8-bit RPLInstanceID (with some internal structure), and a 16-bit SenderRank 🌈
the rest of this section defines the RPI-6LoRH header, which is a Critical 6LoWPAN Routing Header designed to transport the RPI in 6LoWPAN LLNs 🦋
6.1. Compressing the RPLInstanceID 🍓
RPL Instances are discussed in Section 5 of the RPL specification [RFC6550] 📚 a bunch of simple use cases don't need more than one RPL Instance, and in those cases the RPL Instance is expected to be the Global Instance 0 ✨ a global RPLInstanceID is encoded in an RPLInstanceID field like so:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0| ID | Global RPLInstanceID in 0..127
+-+-+-+-+-+-+-+-+
Figure 8: RPLInstanceID Field Format for Global Instancesfor the particular case of the Global Instance 0, the RPLInstanceID field is all zeros 🥰 this specification lets the compressor elide an RPLInstanceID field that's all zeros, and it defines an I flag that, when set, signals that the field is elided 🫧
6.2. Compressing the SenderRank 💜
the SenderRank is the result of the DAGRank operation on the Rank of the sender 🧮 here, the DAGRank operation is defined in Section 3.5.1 of the RPL specification [RFC6550] as:
DAGRank(rank) = floor(rank/MinHopRankIncrease)if MinHopRankIncrease is set to a multiple of 256, the least significant eight bits of the SenderRank will be all zeroes 🤯 so by eliding those, the SenderRank can be compressed into a single byte 🗜️ this idea is used in RFC 6550 [RFC6550], which defines DEFAULT_MIN_HOP_RANK_INCREASE as 256, and in RFC 6552 [RFC6552], which defaults MinHopRankIncrease to DEFAULT_MIN_HOP_RANK_INCREASE 👑
this specification allows the SenderRank to be encoded as either 1 or 2 bytes, and it defines a K flag that, when set, signals that a single byte is used 🎀
6.3. The Overall RPI-6LoRH Encoding 🎀
okay so the RPI-6LoRH header is the compressed version of the RPL RPI 🦋 Routers that need to forward a packet with one are expected to be RPL routers that support this spec ✨
if a non-RPL router gets a packet with an RPI-6LoRH header, that's a routing or configuration error (see Section 8) 💀
the desired reaction for that non-RPL router is to drop the packet, not skip the header and forward it on, because that could end up forming loops by reinjecting the packet into the wrong RPL Instance 🙈 nobody wants that chaos
the Dispatch Value Bit Pattern for the SRH-6LoRH header says it's Critical. Routers that understand the 6LoRH general format from Section 4 cannot ignore a 6LoRH header of this type, and they'll drop the packet if it's unknown to them 🔥
since the RPI-6LoRH is a Critical header, the TSE field doesn't need to be a length in bytes. Instead, the field is fully reused for control bits that encode the O, R, and F flags from the RPI, plus the I and K flags that indicate the compression format 💅
the RPI-6LoRH is Type 5 🌈
the RPI-6LoRH header is immediately followed by the RPLInstanceID field (unless that field is fully elided), and then the SenderRank, which is either compressed into one byte or fully in-lined as 2 bytes. The I and K flags in the RPI-6LoRH header indicate whether the RPLInstanceID is elided and/or the SenderRank is compressed. Depending on those bits, the Length of the RPI-6LoRH may vary as described hereafter 🧚
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+
|1|0|0|O|R|F|I|K| 6LoRH Type=5 | Compressed fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... -+-+-+
Figure 9: The Generic RPI-6LoRH FormatO, R, and F bits: The O, R, and F bits are defined in Section 11.2 of RFC 6550 [RFC6550].
I flag: If it is set, the RPLInstanceID is elided and the RPLInstanceID is the Global RPLInstanceID 0. If it is not set, the octet immediately following the Type field contains the RPLInstanceID as specified in Section 5.1 of RFC 6550 [RFC6550].
K flag: If it is set, the SenderRank is compressed into 1 octet, with the least significant octet elided. If it is not set, the SenderRank is fully inlined as 2 octets.
in Figure 10, the RPLInstanceID is the Global RPLInstanceID 0, and the MinHopRankIncrease is a multiple of 256, so the least significant byte is all zeros and can be elided 🍓
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|O|R|F|1|1| 6LoRH Type=5 | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I=1, K=1
Figure 10: The Most Compressed RPI-6LoRHin Figure 11, the RPLInstanceID is the Global RPLInstanceID 0, but both bytes of the SenderRank are significant, so it cannot be compressed 💜
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|O|R|F|1|0| 6LoRH Type=5 | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I=1, K=0
Figure 11: Eliding the RPLInstanceIDin Figure 12, the RPLInstanceID is not the Global RPLInstanceID 0, and the MinHopRankIncrease is a multiple of 256 ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|O|R|F|0|1| 6LoRH Type=5 | RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I=0, K=1
Figure 12: Compressing SenderRankin Figure 13, the RPLInstanceID is not the Global RPLInstanceID 0, and both bytes of the SenderRank are significant 🌸
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1|0|0|O|R|F|0|0| 6LoRH Type=5 | RPLInstanceID | Sender-...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...-Rank |
+-+-+-+-+-+-+-+-+
I=0, K=0
Figure 13: The Least Compressed Form of RPI-6LoRH7. The IP-in-IP 6LoRH Header ✨
the IP-in-IP 6LoRH (IP-in-IP-6LoRH) header is an Elective 6LoWPAN Routing Header that provides a compressed form for the encapsulating IPv6 Header in the case of an IP-in-IP encapsulation 🦋
an IP-in-IP encapsulation is used to insert a field, such as a Routing Header or an RPI, at a router that is not the source of the packet. To send an error back regarding the inserted field, the address of the router that performs the insertion must be provided 🫶
the encapsulation can also let the last router before the Destination remove a field such as the RPI. But this can be done in compressed form by removing the RPI-6LoRH, so an IP-in-IP-6LoRH encapsulation is not required for that sole purpose 💅
the Dispatch Value Bit Pattern for the SRH-6LoRH header says it's Elective. This field is not Critical for routing, since it doesn't indicate the destination of the packet (that's encoded either in an SRH-6LoRH header or in the inner IP header). A 6LoRH header of this type can be skipped if it isn't understood (per Section 4), and the 6LoRH header indicates the Length in bytes 🧚
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
|1|0|1| Length | 6LoRH Type 6 | Hop Limit | Encaps. Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+
Figure 14: The IP-in-IP-6LoRHThe Length of an IP-in-IP-6LoRH header is expressed in bytes and MUST be at least 1, to indicate a Hop Limit (HL) that is decremented at each hop. When the HL reaches 0, the packet is dropped per RFC 2460 [RFC2460] 🙈
if the Length of an IP-in-IP-6LoRH header is exactly 1, then the Encapsulator Address is elided, which means that the encapsulator is a well-known router, for instance the root in a RPL graph 👑
the most efficient compression of an IP-in-IP encapsulation that can be achieved with this specification is obtained when an endpoint of the packet is the root of the RPL DODAG associated with the RPL Instance used to forward the packet, and the root address is known implicitly rather than signaled explicitly in the data packets 🌈
if the Length of an IP-in-IP-6LoRH header is greater than 1, then an Encapsulator Address is placed in a compressed form after the Hop Limit field. The value of the Length indicates which compression is performed on the Encapsulator Address. For instance, a Length of 3 indicates that the Encapsulator Address is compressed to 2 bytes. The reference for the compression is the address of the root of the DODAG. The way the address of the root is determined is discussed in Section 4.3.2 ⭐
with RPL, the destination address in the IP-in-IP header is implicitly the root in the RPL graph for packets going upwards. In Storing mode, it is the destination address in the LOWPAN_IPHC for packets going downwards. In Non-Storing mode, there is no implicit value for packets going downwards 🍓
if the implicit value is correct, the destination IP address of the IP-in-IP encapsulation can be elided. Otherwise, the destination IP address of the IP-in-IP header is transported in an SRH-6LoRH header as the first entry of the first of these headers 💖
if the final destination of the packet is a leaf that does not support this specification, then the chain of 6LoRH headers must be stripped by the RPL/6LR router to which the leaf is attached. In that example, the destination IP address of the IP-in-IP header cannot be elided 😭
in the special case where a 6LoRH header is used to route 6LoWPAN fragments, the destination address is not accessible in the LOWPAN_IPHC on all fragments, and it can be elided only for the first fragment and for packets going upwards 🦋
8. Management Considerations 🎀
Okay so, it's totally possible to decompress a packet at any hop 🙈, but this spec is really optimized so the packet stays compressed the whole way through 🦋. It makes the most sense to deploy homogeneous networks, where every node uses the compression technique in here, or none do 💅.
This spec aims for a simple implementation that runs on constrained nodes, so it really does expect a homogeneous network 🫶. Because of that, it doesn't give you a way to figure out how much support the next hops have at forwarding time 🥺.
If an extension to this spec ever adds a method like that, forwarding nodes could compress or decompress the RPL artifacts as needed, which would enable backward compatibility between nodes that support this spec and nodes that don't 🌈.
So basically, this spec does not try to make backward compatibility happen. It also doesn't require any extra code to swap error messages around and fix mismatches automatically 💀.
When a packet is expected to carry a 6LoRH header but doesn't, the node that spots the issue is expected to send an ICMPv6 error message to the root ✨. It should be sent at an adapted rate-limitation, with type 4 (the "Parameter Problem" one) and code 0 (meaning "Unrecognized Next Header field encountered") 💖. The relevant portion of the received packet should be embedded, and the offset in it where the 6LoRH header was expected should be pointed out 🧚.
When a packet is received with a 6LoRH header that isn't recognized, the node that catches it is expected to send an ICMPv6 error message to the root too 🔥. It should be sent at an adapted rate-limitation, with type 4 (again "Parameter Problem") and code 1 (meaning "Unrecognized Next Header type encountered") 🍓. The relevant portion of the received packet should be embedded, and the offset where the 6LoRH header was expected should be pointed out 💜.
In both cases, the node SHOULD NOT place a 6LoRH header as defined in this specification in the resulting message 🙅♀️. Instead, the node should either omit the RPI or place it uncompressed after the IPv6 header ✨.
Also, in both cases, an alternate management method may be preferred to tell the network administrator there's a configuration error 📣.
Keeping the network homogeneous is either a deployment issue (only deploy devices with the same capability) or a management issue (configure all devices to either use or not use a certain level of this compression technique and its future additions) 👑.
Especially, a node receiving a message with a Critical 6LoWPAN Routing Header it doesn't understand is an administrative error. It means the wrong device got placed in a network, or the device is misconfigured 😭.
When a mismatch situation is detected, it is expected that the device raises some management alert about the issue, e.g., that it has to drop a packet with a Critical 6LoRH 🚨.
9. Security Considerations 🔐
Bestie, this part is serious, so read it carefully 🫢. The security considerations of RFC 4944 [RFC4944], RFC 6282 [RFC6282], and RFC 6553 [RFC6553] apply 💅.
Using a compressed format instead of the full in-line format is logically equivalent, and it's believed not to open a new threat compared to RFC 6550 [RFC6550], RFC 6553 [RFC6553], and RFC 6554 [RFC6554] 🧠. Even though intermediate hops are removed from the SRH header as they get consumed, a node may still identify whether the rest of the source-routed path includes a loop or not (see the "Security" section of RFC 6554) 👀. It must be noted that if the attacker is not part of the loop, then there is always a node at the beginning of the loop that can detect it and remove it 🛡️.
10. IANA Considerations 📋
10.1. Reserving Space in 6LoWPAN Dispatch Page 1
This specification reserves Dispatch Value Bit Patterns within the 6LoWPAN Dispatch Page 1 like this 🎀:
10 1xxxxx: for Elective 6LoWPAN Routing Headers
10 0xxxxx: for Critical 6LoWPAN Routing HeadersAlso, this document creates two IANA registries: one for the Critical 6LoWPAN Routing Header Type and one for the Elective 6LoWPAN Routing Header Type. Each has 256 possible values, from 0 to 255, as described below 🌸. Future assignments are made by IANA using the "RFC Required" procedure [RFC5226] 🦋.
10.2. New Critical 6LoWPAN Routing Header Type Registry
This document creates an IANA registry titled "Critical 6LoWPAN Routing Header Type" and assigns the following values 💖:
0-4: SRH-6LoRH [RFC8138]
5: RPI-6LoRH [RFC8138]10.3. New Elective 6LoWPAN Routing Header Type Registry
This document creates an IANA registry titled "Elective 6LoWPAN Routing Header Type" and assigns the following value ✨:
6: IP-in-IP-6LoRH [RFC8138]11. References 📚
11.1. Normative References
Here are the normative references, every single one 🫶:
[IEEE.802.15.4]
IEEE, "IEEE Standard for Low-Rate Wireless Networks",
IEEE 802.15.4-2015, DOI 10.1109/IEEESTD.2016.7460875,
<http://ieeexplore.ieee.org/document/7460875/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443,
DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>.
[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,
DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing
Protocol for Low-Power and Lossy Networks (RPL)",
RFC 6552, DOI 10.17487/RFC6552, March 2012,
<http://www.rfc-editor.org/info/rfc6552>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012,
<http://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012,
<http://www.rfc-editor.org/info/rfc6554>.
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
RFC 8025, DOI 10.17487/RFC8025, November 2016,
<http://www.rfc-editor.org/info/rfc8025>.11.2. Informative References
And these are the informative ones, for extra reading 🌈:
[FORWARD-FRAG]
Thubert, P., Ed. and J. Hui, "LLN Fragment Forwarding and
Recovery", Work in Progress, draft-thubert-6lo-forwarding-
fragments-05, April 2017.
[IPv6-ARCH]
Thubert, P., Ed., "An Architecture for IPv6 over the TSCH
mode of IEEE 802.15.4", Work in Progress,
draft-ietf-6tisch-architecture-11, January 2017.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<http://www.rfc-editor.org/info/rfc7228>.
[RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
Internet of Things (IoT): Problem Statement", RFC 7554,
DOI 10.17487/RFC7554, May 2015,
<http://www.rfc-editor.org/info/rfc7554>.
[RPL-INFO] Robles, M., Richardson, M., and P. Thubert, "When to use
RFC 6553, 6554 and IPv6-in-IPv6", Work in Progress,
draft-ietf-roll-useofrplinfo-14, April 2017.Appendix A. Examples 🧚
A.1. Examples Compressing the RPI ✨
Okay, bestie, let's see the RPI get squished down with 6LoRH 🎀. Figure 15 shows a classical packet in Storing mode in all directions, plus Non-Storing mode for a packet going up the DODAG along the default route to the root 🌸. In this example, a fragmentation process happens per RFC 4944 [RFC4944], and the fragment headers have to sit in Page 0 before we switch over to Page 1 💅
+- ... -+- ... -+-+ ... -+- ... +-+-+ ... -+-+-+-+-+-+-+-+-+-+...
|Frag type|Frag hdr |11110001| RPI- |IP-in-IP| LOWPAN_IPHC | ...
|RFC 4944 |RFC 4944 | Page 1 | 6LoRH | 6LoRH | |
+- ... -+- ... -+-+ ... -+- ... +-+-+ ... -+-+-+-+-+-+-+-+-+-+...
<- RFC 6282 ->
No RPL artifact
+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
|Frag type|Frag hdr |
|RFC 4944 |RFC 4944 | Payload (cont)
+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...
|Frag type|Frag hdr |
|RFC 4944 |RFC 4944 | Payload (cont)
+- ... -+- ... -+-+ ... -+-+ ... -+- ... +-+-+-+-+-+-+-+-+-+-+...Figure 15: Example Compressed Packet with RPI
In Storing mode, if the packet stays inside the RPL domain, we can skip the IP-in-IP encapsulation 🦋. Then only the RPI gets compressed with a 6LoRH. Figure 16 shows that for a non-fragmented ICMP packet 🧚
+- ... -+-+- ... -+-+-+-+ ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+...
|11110001| RPI-6LoRH | NH = 0 | NH = 58 | ICMP message ...
|Page 1 | Type 5 | 6LOWPAN_IPHC | (ICMP) | (no compression)
+- ... -+-+- ... -+-+-+-+ ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+...
<- RFC 6282 ->
No RPL artifactFigure 16: Example ICMP Packet with RPI in Storing Mode
Figure 16 is logically the same as the uncompressed format in Figure 17 🌈
+-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...
| IPv6 Header | Hop-by-Hop | RPI in | ICMP message ...
| NH = 58 | Header | RPL Option |
+-+-+-+- ... -+-+-+-+ ... -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+...Figure 17: Uncompressed ICMP Packet with RPI
For a UDP packet, the transport header can be compressed with 6LoWPAN HC [RFC6282], as Figure 18 shows 🍓
+-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+...
|11110001| RPI- | NH=1 |11110CPP| Compressed | UDP
|Page 1 | 6LoRH | LOWPAN_IPHC | UDP | UDP header | Payload
+-+ ... -+-+-...-+-+- ... -+-+-+-+ ... -+-+-+ ... -+-+-+-+-+...
<- RFC 6282 ->
No RPL artifactFigure 18: Uncompressed ICMP Packet with RPI
If a packet comes in from the Internet in Storing mode, the root is supposed to encapsulate it to insert the RPI 🔥. The result looks like Figure 19:
+-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+...
|11110001| RPI- | IP-in-IP | NH=1 |11110CPP| Compressed | UDP
|Page 1 | 6LoRH | 6LoRH | LOWPAN_IPHC | UDP | UDP header | Payld
+-+ ... -+-+-...-+-+-- ... -+-+-+-+- ... -+-+ ... -+-+-+ ... -+-+-+...
<- RFC 6282 ->
No RPL artifactFigure 19: RPI Inserted by the Root in Storing Mode
A.2. Example of a Downward Packet in Non-Storing Mode 🌷
Figure 20 is a classical packet in Non-Storing mode going down the DODAG along a source-routed path from the root 🦋. Say we've got four forwarding hops to reach a destination. In the uncompressed form, when the root generates the packet, the last 3 hops get encoded in a Routing Header Type 3 (SRH), and the first hop is the packet's destination. Each intermediate hop does a swap, and the hop count tells you which hop is currently active, as defined in RFC 2460 [RFC2460] and RFC 6554 [RFC6554] 💜
When compressed with this specification, the 4 hops get encoded in SRH-6LoRH when the root generates the packet, and the final destination stays in the LOWPAN_IPHC 🎀. There's no swap this time. The forwarding node that matches the first entry just consumes it when forwarding. So the encoded packet gets smaller, and the hop information is lost 😭
If the last hop in an SRH-6LoRH isn't the final destination, it removes the SRH-6LoRH before forwarding 💅
In the example in Figure 20, all addresses in the DODAG come from the same /112 prefix, and the last 2 octets hold an identifier such as an IEEE 802.15.4 short address ✨. So every address can compress down to 2 octets, using the root address as the reference. There's one SRH_6LoRH header with three compressed addresses in this example:
+-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
|11110001|SRH-6LoRH| RPI- | IP-in-IP | NH=1 |11110CPP| UDP | UDP
|Page 1 |Type1 S=2| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+-+ ... +-+- ... -+-+-- ... -+-+-+ ... +-+-+ ... -+ ... +-...
<-8bytes-> <- RFC 6282 ->
No RPL artifactFigure 20: Example Compressed Packet with SRH
You might notice the RPI is still there 🧚. That's because the root's address, which is the source of the IP-in-IP header, gets elided and inferred from the RPLInstanceID in the RPI. Once it's found from local context, that address is used as a Compression Reference to expand the addresses in the SRH-6LoRH 💖
With the RPL specifications available at the time of writing, the root is the only node that may put an SRH in an IP packet. When the root forwards a packet it didn't generate, it has to encapsulate that packet with IP-in-IP 🌈
But if the root generates the packet toward a node in its DODAG, it should skip the extra IP-in-IP, as Figure 21 shows 🫶
+- ... -+-+-+ ... +-+-+-+ ... -+-+-+-+-+-+-+-++-+- ... -+-+-+-+-+...
|11110001| SRH-6LoRH | NH=1 | 11110CPP | Compressed | UDP
|Page 1 | Type1 S=3 | LOWPAN_IPHC| LOWPAN-NHC| UDP header | Payload
+- ... -+-+-+ ... +-+-+-+ ... -+-+-+-+-+-+-+-++-+- ... -+-+-+-+-+...
<- RFC 6282 ->Figure 21: Compressed SRH 4*2bytes Entries Sourced by Root
Note: the RPI isn't represented here, even though RPL [RFC6550] generally expects it 🙈. In this case, the Compression Reference for the SRH-6LoRH is the source address in the LOWPAN_IPHC. The routing is strict along the source route path, so the RPI doesn't seem absolutely necessary 🤷♀️
In Figure 21, all the nodes along the source route path share the same /112 prefix. That's typical of IPv6 addresses derived from an IEEE802.15.4 short address, as long as every node shares the same PAN-ID 🍓. In that case, a Type 1 SRH-6LoRH header can be used for encoding. The IPv6 address of the root is taken as the reference, and only the last 2 octets of each intermediate hop's address get encoded. The Size of 3 means 4 hops, which makes the SRH-6LoRH 10 bytes long 🎀
A.3. Example of SRH-6LoRH Life Cycle 🦋
This section walks through the operation specified in Section 5.6, forwarding a packet with a compressed SRH along an A->B->C->D source route path 💅. At each hop, we see the popping of addresses in action ✨
Packet as received by node A
----------------------------
Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA AAAA
Type 1 SRH-6LoRH Size = 0 BBBB
Type 2 SRH-6LoRH Size = 1 CCCC CCCC
DDDD DDDD
Step 1: Popping BBBB, the first entry of the next SRH-6LoRH
Step 2: If larger value (2 vs. 1), the SRH-6LoRH is removed
Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA AAAA
Type 2 SRH-6LoRH Size = 1 CCCC CCCC
DDDD DDDD
Step 3: Recursion ended; coalescing BBBB with the first entry
Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA BBBB
Step 4: Routing based on next segment endpoint to BFigure 22: Processing at Node A
Packet as received by node B
----------------------------
Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA BBBB
Type 2 SRH-6LoRH Size = 1 CCCC CCCC
DDDD DDDD
Step 1: Popping CCCC CCCC, the first entry of the next SRH-6LoRH
Step 2: Removing the first entry and decrementing the Size (by 1)
Type 3 SRH-6LoRH Size = 0 AAAA AAAA AAAA BBBB
Type 2 SRH-6LoRH Size = 0 DDDD DDDD
Step 3: Recursion ended; coalescing CCCC CCCC with the first entry
Type 3 SRH-6LoRH Size = 0 AAAA AAAA CCCC CCCC
Step 4: Routing based on next segment endpoint to CFigure 23: Processing at Node B
Packet as received by node C
----------------------------
Type 3 SRH-6LoRH Size = 0 AAAA AAAA CCCC CCCC
Type 2 SRH-6LoRH Size = 0 DDDD DDDD
Step 1: Popping DDDD DDDD, the first entry of the next SRH-6LoRH
Step 2: The SRH-6LoRH is removed
Type 3 SRH-6LoRH Size = 0 AAAA AAAA CCCC CCCC
Step 3: Recursion ended; coalescing DDDD DDDDD with the first entry
Type 3 SRH-6LoRH Size = 0 AAAA AAAA DDDD DDDD
Step 4: Routing based on next segment endpoint to DFigure 24: Processing at Node C
Packet as received by node D
----------------------------
Type 3 SRH-6LoRH Size = 0 AAAA AAAA DDDD DDDD
Step 1: The SRH-6LoRH is removed
Step 2: No more header; routing based on inner IP headerFigure 25: Processing at Node D
Acknowledgements 🫶
The authors want to thank Tom Phinney, Thomas Watteyne, Tengfei Chang, Martin Turon, James Woodyatt, Samita Chakrabarti, Jonathan Hui, Gabriel Montenegro, and Ralph Droms for their constructive reviews of the design in the 6lo working group 👑. The wider discussion pulled in people from the 6MAN, 6TiSCH, and ROLL WGs, so thank you all 💜. Special thanks to Michael Richardson and Ines Robles (the Chairs of the ROLL WG), Brian Haberman (the Internet Area AD), and Alvaro Retana and Adrian Farrel (Routing Area ADs) for driving this complicated effort across working groups and areas 🌈
Authors' Addresses 🎀
Pascal Thubert (editor)
Cisco Systems
Building D - Regus
45 Allee des Ormes
BP1200
MOUGINS - Sophia Antipolis 06254
France
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
Bremen D-28359
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Laurent Toutain
IMT Atlantique
2 rue de la Chataigneraie
CS 17607
Cesson-Sevigne Cedex 35576
France
Email: Laurent.Toutain@IMT-Atlantique.fr
Robert Cragie
ARM Ltd.
110 Fulbourn Road
Cambridge CB1 9NJ
United Kingdom
Email: robert.cragie@arm.com📦 where this page comes from
- ietf: rfc8138 2017-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms