RFC 9008
Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane
RFC 9008: Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane 🎀
okay bestie, this one is a 2021 Standards Track doc from the IETF, published in April 2021 with ISSN 2070-1721 🌸. It's written by M.I. Robles (UTN-FRM/Aalto), M. Richardson (SSW), and P. Thubert (Cisco), and it updates RFC 6550, RFC 6553, and RFC 8138 💅. It doesn't list anything it obsoletes, so it's just here to level up the existing RPL stuff, no cap ✨.
Abstract 🦋
okay so this doc takes a look at the different data flows in Low-Power and Lossy Networks (LLN) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is the thing setting up the routing 🧚. It lists every case where the RPL Packet Information (RPI) Option Type (RFC 6553), the RPL Source Route Header (RFC 6554), and IPv6-in-IPv6 encapsulation are needed in the data plane 🔥. That breakdown is the foundation for designing efficient compression of these headers, and it's giving main character energy ✨.
The doc also makes some changes. It updates RFC 6553 by changing the RPI Option Type. It updates RFC 6550 by defining a flag in the DODAG Information Object (DIO) Configuration option that signals this change 🌈. And it updates RFC 8138 so the new Option Type gets considered when the RPL Option is decompressed 🫶.
Status of This Memo 📜
this is an Internet Standards Track document 💜.
it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🌸. it went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). if you want more on Internet Standards, check out Section 2 of RFC 7841 🧚.
for the current status of this document, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9008 🎀.
Copyright Notice 🌈
Copyright (c) 2021 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 (https://trustee.ietf.org/license-info) as they stand on the publication date. please read these carefully, because they spell out your rights and restrictions for this document 📜. any Code Components pulled out of this document have to 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
1.1. Overview
2. Terminology and Requirements Language
3. RPL Overview
4. Updates to RFC 6550, RFC 6553, and RFC 8138
4.1. Updates to RFC 6550
4.1.1. Advertising External Routes with Non-Storing Mode
Signaling
4.1.2. Configuration Options and Mode of Operation
4.1.3. Indicating the New RPI in the DODAG Configuration
Option Flag
4.2. Updates to RFC 6553: Indicating the New RPI Option Type
4.3. Updates to RFC 8138: Indicating the Way to Decompress with
the New RPI Option Type
5. Reference Topology
6. Use Cases
7. Storing Mode
7.1. Storing Mode: Interaction between Leaf and Root
7.1.1. SM: Example of Flow from RAL to Root
7.1.2. SM: Example of Flow from Root to RAL
7.1.3. SM: Example of Flow from Root to RUL
7.1.4. SM: Example of Flow from RUL to Root
7.2. SM: Interaction between Leaf and Internet
7.2.1. SM: Example of Flow from RAL to Internet
7.2.2. SM: Example of Flow from Internet to RAL
7.2.3. SM: Example of Flow from RUL to Internet
7.2.4. SM: Example of Flow from Internet to RUL
7.3. SM: Interaction between Leaf and Leaf
7.3.1. SM: Example of Flow from RAL to RAL
7.3.2. SM: Example of Flow from RAL to RUL
7.3.3. SM: Example of Flow from RUL to RAL
7.3.4. SM: Example of Flow from RUL to RUL
8. Non-Storing Mode
8.1. Non-Storing Mode: Interaction between Leaf and Root
8.1.1. Non-SM: Example of Flow from RAL to Root
8.1.2. Non-SM: Example of Flow from Root to RAL
8.1.3. Non-SM: Example of Flow from Root to RUL
8.1.4. Non-SM: Example of Flow from RUL to Root
8.2. Non-Storing Mode: Interaction between Leaf and Internet
8.2.1. Non-SM: Example of Flow from RAL to Internet
8.2.2. Non-SM: Example of Flow from Internet to RAL
8.2.3. Non-SM: Example of Flow from RUL to Internet
8.2.4. Non-SM: Example of Flow from Internet to RUL
8.3. Non-SM: Interaction between Leaves
8.3.1. Non-SM: Example of Flow from RAL to RAL
8.3.2. Non-SM: Example of Flow from RAL to RUL
8.3.3. Non-SM: Example of Flow from RUL to RAL
8.3.4. Non-SM: Example of Flow from RUL to RUL
9. Operational Considerations of Supporting RULs
10. Operational Considerations of Introducing 0x23
11. IANA Considerations
11.1. Option Type in RPL Option
11.2. Change to the "DODAG Configuration Option Flags"
Subregistry
11.3. Change MOP Value 7 to Reserved
12. Security Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgments
Authors' Addresses1. Introduction ✨
RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) [RFC6550] is a routing protocol built for constrained networks 🧚. [RFC6553] defines the RPL Option, which rides inside the IPv6 Hop-by-Hop Options header 🦋. It carries the RPLInstanceID so routers can quickly spot inconsistencies (loops) in the routing topology 🔥. People usually call the RPL Option the RPL Packet Information (RPI), but technically the RPI is the routing information defined in [RFC6550] that gets carried inside the RPL Option 💅. RFC 6554 [RFC6554] defines the "RPL Source Route Header" (RH3), an IPv6 extension header used to deliver datagrams within an RPL routing domain, especially in Non-Storing mode 💖.
these are all called RPL artifacts, and they show up on basically all the data plane traffic in RPL-routed networks 🌸. They usually don't appear on the RPL control plane at all, which is mostly hop-by-hop traffic. (The one exception is Destination Advertisement Object (DAO) messages in Non-Storing mode 🙈.)
the tricky part: when multi-vendor interoperability gets tested, and when people try to compress as many of these artifacts as possible, it becomes super clear that implementers don't agree on when an artifact is necessary, when it can be safely left out, or when it can be removed 💀.
the ROLL (Routing Over Low power and Lossy networks) Working Group looked at how the IPv6 rules [RFC2460] apply to both Storing and Non-Storing use of RPL 🌈. the result was 24 data-plane use cases, and this doc spells all of them out so there's zero ambiguity 🔥. while this was being processed, new rules were published as [RFC8200], and this document got updated to reflect the normative changes in that document 🫶.
this document updates [RFC6553] by changing the value of the Option Type of the RPL Option, so that routers compliant with [RFC8200] ignore this option when they don't recognize it 👑.
the Routing Header Dispatch for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPAN) (6LoRH) [RFC8138] defines a way to compress RPL Option information and Routing Header type 3 (RH3) [RFC6554], plus an efficient IPv6-in-IPv6 technique 🦋.
most of the use cases in here need IPv6-in-IPv6 packet encapsulation 💜. when you encapsulate and decapsulate packets, [RFC6040] MUST be applied to map the setting of the explicit congestion notification (ECN) field between the inner and outer headers 🎀. [TUNNELS] is also recommended reading, since it explains how IP tunnels relate to existing protocol layers and the challenges that come with supporting IP tunneling 🧚.
unconstrained uses of RPL are out of scope for this doc, and applicability statements for those uses may give different advice, e.g., [ACP] 🌸.
1.1. Overview 💅
here's how the rest of the doc is laid out 🍓. Section 2 covers the terminology used. Section 3 gives an RPL overview. Section 4 describes the updates to RFC 6553, RFC 6550, and RFC 8138. Section 5 provides the reference topology used for the use cases. Section 6 describes the use cases included. Section 7 covers the Storing mode cases, and Section 8 covers the Non-Storing mode cases 🦋. Section 9 talks about the operational considerations of supporting RPL-unaware leaves. Section 10 covers the operational considerations for the proposed change to the RPI Option Type. Section 11 is the IANA considerations, and Section 12 goes over the security aspects 🫶✨.
2. Terminology and Requirements Language ✨
Okay bestie, time for the vocab 🎀 The BCP 14 key words are the ones that get capital letters: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL". They only count as real requirement words when they show up in ALL CAPS like that, and then they mean what BCP 14 [RFC2119] [RFC8174] says they mean. No cap, that's the whole deal 💅
Some of the terms come from [RFC7102], so you get LLN, RPL, RPL domain, and ROLL from there 🦋
Consumed: A Routing Header is consumed when its Segments Left field is zero. That tells you the destination in the IPv6 header is the final destination of the packet, and the hops in the Routing Header have already been traversed 🌸
RPL Leaf: An IPv6 host that's attached to an RPL router and gets its connectivity through a RPL Destination-Oriented Directed Acyclic Graph (DODAG). As an IPv6 node, a RPL leaf is expected to ignore a consumed Routing Header. As an IPv6 host, it's expected to ignore a Hop-by-Hop Options header too. So a RPL leaf can still correctly receive a packet with RPL artifacts 🧚 On the flip side, a RPL leaf is not expected to generate RPL artifacts or to support IP-in-IP encapsulation. To keep things simple, this document just says "leaf" when it means a RPL leaf 🫶
RPL Packet Information (RPI): This is the information [RFC6550] defines abstractly to be placed in IP packets. The term is commonly used, this document included, to mean the RPL Option [RFC6553] that carries that abstract info in an IPv6 Hop-by-Hop Options header. [RFC8138] gives an alternate, more compressed format for the same abstract information 🍓
RPL-Aware Node (RAN): A device that implements RPL. Heads up that the device can be inside the LLN or outside it 🌈
RPL-Aware Leaf (RAL): An RPL-aware node that's also an RPL leaf ⭐
RPL-Unaware Node: A device that doesn't implement RPL, so it's RPL unaware. This device can also be found inside the LLN 🙈
RPL-Unaware Leaf (RUL): An RPL-unaware node that's also an RPL leaf 💜
6LoWPAN Node (6LN): [RFC6775] defines it like this: "A 6LoWPAN node is any host or router participating in a LoWPAN. This term is used when referring to situations in which either a host or router can play the role described." In this document, a 6LN acts as a leaf 🌸
6LoWPAN Router (6LR): [RFC6775] defines it like this: "An intermediate router in the LoWPAN that is able to send and receive Router Advertisements (RAs) and Router Solicitations (RSs) as well as forward and route IPv6 packets. 6LoWPAN routers are present only in route-over topologies."
6LoWPAN Border Router (6LBR): [RFC6775] defines it like this: "A border router located at the junction of separate 6LoWPAN networks or between a 6LoWPAN network and another IP network. There may be one or more 6LBRs at the 6LoWPAN network boundary. A 6LBR is the responsible authority for IPv6 prefix propagation for the 6LoWPAN network it is serving. An isolated LoWPAN also contains a 6LBR in the network, which provides the prefix(es) for the isolated network." 👑
Flag Day: A flag day happens when a network gets reconfigured in a way that nodes running the older configuration can't talk to nodes running the new one. The classic example is when the ARPANET switched from IP version 3 to IP version 4 on January 1, 1983 [RFC0801]. In the context of this document, switching from RPI Option Type (0x63) to Option Type (0x23) is a disruptive changeover 😭 To cut down how long that changeover takes, Section 4.1.3 gives a mechanism so nodes can be upgraded incrementally 🔥
Non-Storing Mode (Non-SM): An RPL mode of operation where the RPL-aware nodes send information to the root about their parents. That means the root knows the topology. Because the root knows the topology, the intermediate 6LRs don't keep routing state, and source routing is needed 🦋
Storing Mode (SM): An RPL mode of operation where RPL-aware nodes (6LRs) keep routing state for their children, so source routing isn't needed 🌈
Note: Due to lack of space in some tables, we refer to IPv6-in-IPv6 as IP6-IP6.
3. RPL Overview 🧚
Here's the big picture: RPL defines the RPL control message (the control plane), which is an ICMPv6 message [RFC4443] with a Type of 155. DIS (DODAG Information Solicitation), DIO (DODAG Information Object), and DAO (Destination Advertisement Object) messages are all RPL control messages, they just have different Code values 💖 A RPL stack looks like Figure 1:
+--------------+
| Upper Layers |
| |
+--------------+
| RPL |
| |
+--------------+
| ICMPv6 |
| |
+--------------+
| IPv6 |
| |
+--------------+
| 6LoWPAN |
| |
+--------------+
| PHY-MAC |
| |
+--------------+
Figure 1: RPL StackRPL supports two modes of Downward internal traffic. In Storing mode (SM) it's fully stateful, and in Non-Storing mode (non-SM) it's fully source routed ✨ An RPL Instance is either fully Storing or fully Non-Storing. A mix of fully Storing and Non-Storing nodes in one RPL Instance isn't supported by the current specifications at the time this document was written, so no mixing 🙅♀️ External routes get advertised with non-SM messaging even in an SM network, see Section 4.1.1 🫶
4. Updates to RFC 6550, RFC 6553, and RFC 8138 🌸
4.1. Updates to RFC 6550 💅
4.1.1. Advertising External Routes with Non-Storing Mode Signaling 🦋
Section 6.7.8 of [RFC6550] introduces the 'E' flag. It gets set to show that the 6LR generating the DAO is redistributing external targets into the RPL network. An external target is a target learned through an alternate protocol. For example, that could be a route to a prefix outside the RPL domain that's still reachable through a 6LR 🌍 Since it's outside the RPL domain, a node reached via an external target can't be guaranteed to ignore the RPL artifacts, and it can't be expected to process the compression [RFC8138] defines correctly. So the RPL artifacts should be wrapped in an IP-in-IP encapsulation that the 6LR removes, and any leftover compression should get expanded by the 6LR before it forwards the packet outside the RPL domain 😭
This specification updates [RFC6550] to say that advertising external targets with Non-Storing mode DAO messaging, even in a Storing mode network, is RECOMMENDED. This way, external routes aren't advertised within the DODAG, and every packet to an external target reaches the root like normal Non-Storing mode traffic 💖 The Non-Storing mode DAO tells the root the address of the 6LR that injects the external route. The root then uses IP-in-IP encapsulation to that 6LR, which ends the IP-in-IP tunnel and forwards the original packet outside the RPL domain, free of RPL artifacts ✨
Going the other direction, for traffic coming from an external target into the LLN, the parent (6LR) that injects the traffic always encapsulates to the root. This whole operation is transparent to intermediate routers, which only see traffic between the 6LR and the root. Only the root and the 6LRs that inject external routes need to be upgraded to add this function to the network 🎀
A RUL is a special case of external target, when the target is actually a host and it's known to support a consumed Routing Header and to ignore a Hop-by-Hop Options header as [RFC8200] prescribes 🧚 The target may have been learned through an external routing protocol, or it may have been registered to the 6LR using [RFC8505] 🍓
To enable IP-in-IP all the way down to a 6LN, it helps if the 6LN supports decapsulating IP-in-IP. But [RFC8504] doesn't assume that 🙈 If the 6LN is a RUL, the root that encapsulates a packet SHOULD terminate the tunnel at a parent 6LR. The root MAY encapsulate all the way to the RUL if it knows the RUL supports IP-in-IP decapsulation and the artifacts in the outer header chain 🌈
A node reachable over an external route isn't expected to support [RFC8138]. Whether or not a decapsulation took place, and even when the 6LR is delivering the packet to a RUL, the 6LR that injected an external route MUST undo the [RFC8138] compression on the packet before forwarding it over that external route 🚨
4.1.2. Configuration Options and Mode of Operation 🎀
Section 6.7.6 of [RFC6550] describes the DODAG Configuration option as containing a series of flags in the first octet of the payload 🧚
Anticipating future work to revise RPL related to how the LLN and DODAG are configured, this document renames the IANA "DODAG Configuration Option Flags" subregistry so that it applies only to Mode of Operation (MOP) values zero (0) through six (6). The flags for MOP value seven (7) are left unassigned 👑 The MOP is described in [RFC6550], Section 6.3.1 📖
In addition, this document reserves MOP value 7 for future expansion 🦋
See Sections 11.2 and 11.3 💖
4.1.3. Indicating the New RPI in the DODAG Configuration Option Flag
Okay so, to avoid a flag day 😭 (that's when new nodes using the RPI Option Type 0x23 and old nodes using 0x63 can't interoperate), this section defines a flag in the DODAG Configuration option that tells everyone when the new RPI Option Type is safe to use 💅. The flag indicates which Option Type value the network is using for the RPL Option, so when a node joins a network, it already knows what to use 🫶. RPL-capable nodes can then tell whether it's safe to use 0x23 when creating a new RPL Option ✨. One rule here is a must: a node that forwards a packet with an RPI MUST NOT modify the Option Type of the RPL Option 🙅♀️.
This is done with a DODAG Configuration option flag called "RPI 0x23 enable", which spreads through the network 🌸. Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base Object, and the flag is only defined for MOP values between 0 and 6 🎀.
For a MOP value of 7, a node MUST use the RPI 0x23 option 💜.
As [RFC6550] says, the DODAG Configuration option lives in DIO messages 📨. It distributes configuration info that is mostly static and doesn't change within the DODAG 🧚. The DODAG root configures this info and spreads it through the DODAG using the DODAG Configuration option, and nodes other than the root don't modify it when they pass it along 🍓.
Right now, [RFC6550] says the unused bits "MUST be initialized to zero by the sender and MUST be ignored by the receiver." 🙈 If the flag is received with a value of zero (the default), new nodes stay compatible with RFC 6553 and keep originating traffic with the old RPI Option Type value (0x63) 💅. If the flag is received with a value of 1, then the value for the RPL Option MUST be set to 0x23 ✨.
Bit number three of the Flags field in the DODAG Configuration option is used as shown in Table 1 (this is the same as Table 36 in Section 11, repeated here for convenience) 🦋:
+============+=================+===============+
| Bit number | Description | Reference |
+============+=================+===============+
| 3 | RPI 0x23 enable | This document |
+------------+-----------------+---------------+
Table 1: DODAG Configuration Option Flag to
Indicate the RPI Flag DayIn the case of a reboot, the node (6LN or 6LR) doesn't remember the RPI Option Type (so it doesn't know whether the flag is set) 🥲. That means it won't trigger DIO messages until it receives a DIO message that tells it which RPI value to use. If the network supports this feature, the node will use the value 0x23 🌈.
4.2. Updates to RFC 6553: Indicating the New RPI Option Type
Here's why this change is needed 👑. It lets an IPv6 packet travel from a RPL-aware leaf to a RPL-unaware node over the Internet (see Section 7.2.1) without needing IPv6-in-IPv6 encapsulation 🚀.
Section 6 of [RFC6553] says, as Table 2 shows, that in the Option Type field of the RPL Option, the two high-order bits must be set to '01' and the third bit must be '1' 📋. The first two bits mean the IPv6 node has to discard the packet if it doesn't recognize the Option Type. The third bit means the Option Data may change in route. The remaining bits are the Option Type itself 🧩.
+===========+===================+=============+===========+
| Hex Value | Binary Value | Description | Reference |
| +=====+=====+=======+ | |
| | act | chg | rest | | |
+===========+=====+=====+=======+=============+===========+
| 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] |
+-----------+-----+-----+-------+-------------+-----------+
Table 2: Option Type in RPL OptionThis document shows that the source can't always know for sure whether a packet will stay inside the RPL domain or leave it 🤔.
When [RFC6553] was published, leaking a Hop-by-Hop Options header in the outer IPv6 header chain could potentially affect core routers in the Internet 😬. So back then, it was decided to encapsulate any packet with an RPL Option using IPv6-in-IPv6 in every case where it was unclear whether the packet would stay within the RPL domain. In the rare case where a packet still leaked, the Option Type would make the first Internet router that doesn't recognize the option drop the packet, which protects the rest of the network 🛡️.
Even with [RFC8138], where the IPv6-in-IPv6 header is compressed, this approach adds extra bytes to a packet. That means more energy and bandwidth used, a higher chance of loss, and possibly fragmentation at the 6LoWPAN level 📉. It all hits the daily operation of constrained devices, for a case that generally doesn't happen and wouldn't heavily affect the core anyway 🥺.
The intention was, and still is, that a Hop-by-Hop Options header with an RPL Option should stay confined within the RPL domain 🏠. But this specification changes that behavior to reduce the dependency on IPv6-in-IPv6 and protect constrained devices 💖. Section 4 of [RFC8200] clarifies how routers in the Internet behave: "it is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so."
So when it's unclear where a packet is going, it's better for the source not to encapsulate, even though the packet may leave the RPL domain on its way to its destination ✈️. In that case, the packet should reach its destination and should not be discarded by the first node that doesn't recognize the RPL Option 🎯. But with the current Option Type value, a node in the Internet that is configured to process the Hop-by-Hop Options header will drop the packet if it finds an Option Type with the first two bits set to 01 and it conforms to [RFC8200] 😤. Host systems should do the same, no matter how they're configured 💀.
So this document updates the Option Type of the RPL Option [RFC6553] and names it the RPI Option Type for simplicity (Table 3) 🌟. The two high-order bits MUST be set to '00', and the third bit must be '1'. The first two bits mean the IPv6 node MUST skip over this option and continue processing the header ([RFC8200], Section 4.2) if it doesn't recognize the Option Type. The third bit stays set to show the Option Data may change en route. The rightmost five bits stay at 0x3 (00011). This makes sure a packet that leaves the RPL domain of an LLN (or leaves the LLN entirely) won't be discarded when it has the RPL Option 🦋.
With the new Option Type, if an IPv6 (intermediate) node that is RPL unaware receives a packet with an RPL Option, it should ignore the Hop-by-Hop RPL Option (skip over it and keep processing the header) 🫧. This matters for the case we mentioned earlier, where traffic flows from a RAL to the Internet (see Section 7.2.1) 🌐.
This is a significant update to [RFC6553] 🔥.
+===========+===================+=============+===============+
| Hex Value | Binary Value | Description | Reference |
| +=====+=====+=======+ | |
| | act | chg | rest | | |
+===========+=====+=====+=======+=============+===============+
| 0x23 | 00 | 1 | 00011 | RPL Option | This document |
+-----------+-----+-----+-------+-------------+---------------+
Table 3: Revised Option Type in RPL OptionWithout the signaling described below, this change would break interoperation (a flag day) for existing networks that currently use 0x63 as the RPI Option Type value 😱. Networks like that won't understand a move to 0x23. It is suggested that RPL implementations accept both 0x63 and 0x23 when processing the header 🤝.
When forwarding packets, implementations SHOULD use the same RPI Type value that was received 🔁. This is required because the RPI Option Type does not change en route ([RFC8200], Section 4.2) 🧷. It lets the network be upgraded bit by bit, and it lets the DODAG root know which parts of the network have been upgraded 📈.
When originating new packets, implementations should have an option to choose which value to originate with. This option is controlled by the DODAG Configuration option (Section 4.1.3) 🎛️.
Changing the RPI Option Type from 0x63 to 0x23 makes all nodes that comply with Section 4.2 of [RFC8200] tolerant of RPL artifacts 🥰. There's no longer any need to remove the artifacts when sending traffic to the Internet 🙌. This change also clarifies when to use IPv6-in-IPv6 headers and how to address them: the Hop-by-Hop Options header containing the RPI MUST always be added when 6LRs originate packets (without IPv6-in-IPv6 headers), and IPv6-in-IPv6 headers MUST always be added when a 6LR finds that it needs to insert a Hop-by-Hop Options header containing the RPL Option. The IPv6-in-IPv6 header is addressed to the RPL root on the way up, and to the end host on the way down ⬆️⬇️.
In the Non-Storing case, dealing with RPL-unaware leaf nodes is much easier, because the 6LBR (DODAG root) has complete knowledge of the connectivity of all DODAG nodes, and all traffic flows through the root node 👑.
The 6LBR can recognize RPL-unaware leaf nodes because it receives a DAO about that node from the 6LR directly above it 🕵️♀️.
The Non-Storing mode case doesn't require the Type change from 0x63 to 0x23, because the root can always create the right packet 🙃. The Type change doesn't adversely affect the Non-Storing case (see Section 4.1.3) ✅.
4.3. Updates to RFC 8138: Indicating the Way to Decompress with the New RPI Option Type ✨
okay so this change is literally required 💅 so that the RPL Option with the new Option Type of 0x23 can be decompressed at all 🦋
The RPI-6LoRH header gives us a compressed form of the RPL RPI, see [RFC8138], Section 6 🌸 A node that is decompressing this header MUST decompress using the RPI Option Type that is currently active, which means picking between 0x23 (new) and 0x63 (old) 🎀 The node figures out which one to use from the presence of the flag in the DODAG Configuration option defined in Section 4.1.3, so it's giving detective energy 🕵️♀️ For example, if the network is in 0x23 mode (by DIO option), then it should be decompressed to 0x23 ✨
Section 7 of [RFC8138] explains how to compress the IPv6-in-IPv6 header 🧚
There are potentially significant advantages to having a single code path that always processes IPv6-in-IPv6 headers with no conditional branches 💜 no if-else spiral, just vibes 🫶
In Storing mode, the cases where the flow goes from RAL to RUL and from RUL to RUL include compressing both the IPv6-in-IPv6 and RPI headers 😭 The IPv6-in-IPv6 header MUST be used in this case, and it SHOULD be compressed as specified in [RFC8138], Section 7. Figure 2 shows the Storing mode case where the packet comes in from the Internet, and then the root encapsulates it to insert the RPI. In that example, the leaf is not known to support RFC 8138, so the packet is encapsulated to the 6LR that is the parent and the last hop to the final destination 🍓
+-+ ... -+-+ ... +-+- ... -+-+- +-+-+-+ ... +-+-+ ... -+++ ... +-...
|11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP
|Page 1 |Type1 S=0| 6LoRH |6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+-+ ... +-+- ... -+-+-.+-+-+-+-+ ... +-+-+ ... -+ ... +-...
<-4bytes-> <- RFC 6282 ->
No RPL artifact
Figure 2: RPI Inserted by the Root in Storing ModeIn Figure 2, the source of the IPv6-in-IPv6 encapsulation is the root, so it gets elided in the IP-in-IP 6LoRH 🌈 The destination is the parent 6LR of the inner packet's destination, so it can't be elided 🙈 It sits as the single entry in a Source Route Header 6LoRH (SRH-6LoRH), as the first 6LoRH. There's only one entry, so the SRH-6LoRH Size is zero 💖 In that example the Type is 1, so the 6LR address gets compressed to two bytes, which makes the total length of the SRH-6LoRH four bytes 🔥 Then come the RPI-6LoRH and the IP-in-IP 6LoRH. When the IP-in-IP 6LoRH is removed, all the router headers in front of it get removed too 👑 The Paging Dispatch [RFC8025] may also be removed if there was no earlier Page change to a Page other than 0 or 1, since LOWPAN_IPHC is encoded the same way in the default Page 0 and in Page 1 ✨ The resulting packet to the destination is the inner packet compressed with [RFC6282] 🫶
5. Reference Topology 🗺️
A RPL network in general is made up of a 6LBR, a Backbone Router (6BBR), a 6LR, and a 6LN as a leaf, all logically organized in a DODAG structure 🌸
Figure 3 shows the reference RPL topology for this document. The nodes are labeled with letters so they can be referred to in later sections 🦋 In the figure, 6LR is a full router node. The 6LN is a RPL-aware router or host (as a leaf). To keep things simple, it's assumed that the 6LBR has direct access to the Internet and is the root of the DODAG, so the 6BBR isn't in the figure 💅
The 6LN leaves marked as RAL (F, H, and I) are RPL nodes with no children hosts 🧚
The leaves marked as RUL (G and J) are devices that don't speak RPL at all (RPL unaware). They use Router Advertisements, 6LoWPAN Duplicate Address Request and Duplicate Address Confirmation (DAR/DAC), and 6LoWPAN Neighbor Discovery (ND) only to take part in the network [RFC8505] 🍓 In this document, leaves G and J are also called a RUL 🎀
The 6LBR (A) in the figure is the root of the Global DODAG 👑
+------------+
| INTERNET ----------+
| | |
+------------+ |
|
|
|
A |
+-------+
|6LBR |
+-----------|(root) |-------+
| +-------+ |
| |
| |
| |
| |
| B |C
+---|---+ +---|---+
| 6LR | | 6LR |
+---------| |--+ +--- ---+
| +-------+ | | +-------+ |
| | | |
| | | |
| | | |
| | | |
| D | E | |
+-|-----+ +---|---+ | |
| 6LR | | 6LR | | |
| | +------ | | |
+---|---+ | +---|---+ | |
| | | | |
| | +--+ | |
| | | | |
| | | | |
| | | I | J |
F | | G | H | |
+-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+
| RAL | | RUL | | RAL | | RAL | | RUL |
| 6LN | | 6LN | | 6LN | | 6LN | | 6LN |
+-------+ +-------+ +------+ +-------+ +-------+
Figure 3: A Reference RPL Topology6. Use Cases 🧚
In the data plane, a combination of RFC 6553, RFC 6554, and IPv6-in-IPv6 encapsulation is going to be analyzed for a bunch of representative traffic flows 💖
The use cases describe communication in these cases:
- Between RPL-aware nodes with the root (6LBR)
- Between RPL-aware nodes with the Internet
- Between RUL nodes within the LLN (e.g., see Section 7.1.4)
- Inside of the LLN when the final destination address resides outside of the LLN (e.g., see Section 7.2.3)
The use cases are as follows:
Interaction between leaf and root:
- RAL to root
- root to RAL
- RUL to root
- root to RUL
Interaction between leaf and Internet:
- RAL to Internet
- Internet to RAL
- RUL to Internet
- Internet to RUL
Interaction between leaves:
- RAL to RAL
- RAL to RUL
- RUL to RAL
- RUL to RUL
This document is consistent with the rule that a header cannot be inserted or removed on the fly inside an IPv6 packet that is being routed. This is a fundamental precept of the IPv6 architecture, as outlined in [RFC8200] 🔥
As the Rank information in the RPI artifact changes at each hop, it will typically be zero when it arrives at the DODAG root. The DODAG root MUST force it to zero when passing the packet out to the Internet. That means the Internet won't see any SenderRank information 🫶
Even though it's legal to leave the RPI artifact in place, an intermediate router that needs to add an extension header (e.g., RH3 or RPL Option) MUST still encapsulate the packet in an (additional) outer IP header. The new header is placed after this new outer IP header 🦋
A corollary is that an intermediate router can remove an RH3 or RPL Option only if it sits in an encapsulating IPv6 header that is addressed to this intermediate router. When it does that, the whole encapsulating header has to be removed. (A replacement may be added.) 🌈
Both the RPL Option and the RH3 headers can be modified in very specific ways by routers on the path of the packet, without needing to add and remove an encapsulating header 🍓 Both headers were designed with this modification in mind. The RPL RH3 and the RPL Option are both marked mutable but recoverable. So an IPsec Authentication Header (AH) can be applied across these headers, but it can't secure the values that mutate 🧚
The RPI MUST be present in every single RPL data packet 👑
Before [RFC8138], there was a lot of interest in making an exception to this rule and removing the RPI for Downward flows in Non-Storing mode. That exception would have covered a very small number of cases and caused big interoperability challenges, while also adding a lot of work in the code and tests 🙈 Being able to compress the RPI down to three bytes or less takes away most of the pressure to optimize this any further ✨
Throughout the following subsections, the examples are described in more detail in the first subsections and more concisely in the later ones 💅
The use cases are delineated based on the following IPV6 and RPL mandates:
- The RPI has to be in every packet that traverses the LLN.
- Because of the above requirement, packets from the Internet have to be encapsulated.
- A header cannot be inserted or removed on the fly inside an IPv6 packet that is being routed.
- Extension headers may not be added or removed except by the sender or the receiver.
- RPI and RH3 headers may be modified by routers on the path of the packet without the need to add and remove an encapsulating header.
- An RH3 or RPL Option can only be removed by an intermediate router if it is placed in an encapsulating IPv6 header, which is addressed to the intermediate router.
- The Non-Storing mode requires downstream encapsulation by the root for RH3.
The use cases are delineated based on the following assumptions:
- This document assumes that the LLN is using the no-drop RPI Option Type (0x23).
- Each IPv6 node (including Internet routers) obeys [RFC8200], so that the 0x23 RPI Option Type can be safely inserted.
- All 6LRs obey [RFC8200].
- The RPI is ignored at the IPv6 destination (dst) node (RUL).
- In the use cases, we assume that the RAL supports IP-in-IP encapsulation.
- In the use cases, we don't assume that the RUL supports IP-in-IP encapsulation.
- For traffic leaving a RUL, if the RUL adds an opaque RPI, then the 6LR as a RPL Border Router SHOULD rewrite the RPI to indicate the selected Instance and set the flags.
- The description for RALs applies to RAN in general.
- Unconstrained uses of RPL are not in scope of this document.
- Compression is based on [RFC8138].
- The flow label [RFC6437] is not needed in RPL.
7. Storing Mode ✨
Storing mode (SM) is the fully stateful one 💖 The sender can figure out if the destination is inside the LLN by checking whether the destination address is matched by the DIO's Prefix Information Option (PIO) 🎀
Okay so, Table 4 is the big cheat sheet 📋 It shows which headers each scenario needs, and whether an IPv6-in-IPv6 header has to be added and who it gets addressed to. The possible destinations are:
- the final destination (the RAL node that is the target (tgt)),
- the "root", or
- the 6LR parent of a RUL.
If no IPv6-in-IPv6 header is needed, the column says "No" and the destination is N/A (Not Applicable) 🙈 If one is needed, the column shows "must" 🔥
The RPI is needed in every single case, because it's how inconsistencies (loops) in the routing topology get caught 🕵️♀️ The RH3 is usually not needed, since it isn't used in Storing mode. But there's one scenario (root to RUL in SM) where the RH3 can point at the RUL, so it's giving main character energy 👑 (Table 8).
The leaf can be a router 6LR or a host, and both get indicated as 6LN 🧚 The root refers to the 6LBR (see Figure 3).
+=====================+==========+==============+==================+
| Interaction between | Use Case | IPv6-in-IPv6 | IPv6-in-IPv6 dst |
+=====================+==========+==============+==================+
| Leaf - Root | RAL to | No | N/A |
| | root | | |
| +----------+--------------+------------------+
| | root to | No | N/A |
| | RAL | | |
| +----------+--------------+------------------+
| | root to | must | 6LR |
| | RUL | | |
| +----------+--------------+------------------+
| | RUL to | must | root |
| | root | | |
+=====================+----------+--------------+------------------+
| Leaf - Internet | RAL to | may | root |
| | Int | | |
| +----------+--------------+------------------+
| | Int to | must | RAL (tgt) |
| | RAL | | |
| +----------+--------------+------------------+
| | RUL to | must | root |
| | Int | | |
| +----------+--------------+------------------+
| | Int to | must | 6LR |
| | RUL | | |
+=====================+----------+--------------+------------------+
| Leaf - Leaf | RAL to | No | N/A |
| | RAL | | |
| +----------+--------------+------------------+
| | RAL to | No(up) | N/A |
| | RUL +--------------+------------------+
| | | must(down) | 6LR |
| +----------+--------------+------------------+
| | RUL to | must(up) | root |
| | RAL +--------------+------------------+
| | | must(down) | RAL |
| +----------+--------------+------------------+
| | RUL to | must(up) | root |
| | RUL +--------------+------------------+
| | | must(down) | 6LR |
+=====================+----------+--------------+------------------+
Table 4: IPv6-in-IPv6 Encapsulation in Storing Mode7.1. Storing Mode: Interaction between Leaf and Root
This section walks through the communication flow in Storing mode (SM) between these pairs:
- RAL to root
- root to RAL
- RUL to root
- root to RUL
7.1.1. SM: Example of Flow from RAL to Root
In Storing mode, RPI [RFC6553] is used to carry the RPLInstanceID and Rank information 🦋
The flow here looks like this:
RAL (6LN) --> 6LR_i --> root (6LBR)For example, a communication flow could be:
Node F (6LN) --> Node D (6LR_i) --> Node B (6LR_i) --> Node A root (6LBR)The RAL (Node F) inserts the RPI and sends the packet to the 6LR (Node D), which decrements the Rank in the RPI and sends the packet up ⬆️ When the packet reaches the 6LBR (Node A), the RPI is removed and the packet gets processed ✨
No IPv6-in-IPv6 header is required 🙌
The RPI can be removed by the 6LBR because the packet is addressed to the 6LBR. The RAL has to know it's talking to the 6LBR to use this scenario, and it can know the 6LBR's address because it knows the root's address through the DODAGID in the DIO messages 🫶
Table 5 summarizes which headers are needed for this use case:
+===================+=========+=======+==========+
| Header | RAL src | 6LR_i | 6LBR dst |
+===================+=========+=======+==========+
| Added headers | RPI | -- | -- |
+===================+---------+-------+----------+
| Modified headers | -- | RPI | -- |
+===================+---------+-------+----------+
| Removed headers | -- | -- | RPI |
+===================+---------+-------+----------+
| Untouched headers | -- | -- | -- |
+===================+---------+-------+----------+
Table 5: SM: Summary of the Use of Headers
from RAL to Root7.1.2. SM: Example of Flow from Root to RAL
In this case, the flow looks like this:
root (6LBR) --> 6LR_i --> RAL (6LN)For example, a communication flow could be:
Node A root (6LBR) --> Node B (6LR_i) --> Node D (6LR_i) --> Node F (6LN)Here, the 6LBR inserts the RPI and sends the packet down 🍓 The 6LR increments the Rank in the RPI (it looks at the RPLInstanceID to find the right forwarding table). Then the packet gets processed in the RAL, and the RPI is removed 💅
No IPv6-in-IPv6 header is required.
Table 6 summarizes which headers are needed for this use case:
+===================+==========+=======+=========+
| Header | 6LBR src | 6LR_i | RAL dst |
+===================+==========+=======+=========+
| Added headers | RPI | -- | -- |
+===================+----------+-------+---------+
| Modified headers | -- | RPI | -- |
+===================+----------+-------+---------+
| Removed headers | -- | -- | RPI |
+===================+----------+-------+---------+
| Untouched headers | -- | -- | -- |
+===================+----------+-------+---------+
Table 6: SM: Summary of the Use of Headers
from Root to RAL7.1.3. SM: Example of Flow from Root to RUL
In this case, the flow looks like this:
root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)For example, a communication flow could be:
Node A (6LBR) --> Node B (6LR_i) --> Node E (6LR_n) --> Node G (RUL)6LR_i (Node B) stands for the intermediate routers from the source (6LBR) to the destination (RUL), where 1 <= i <= n, and n is the total number of routers (6LR) the packet goes through, from the 6LBR (Node A) to the RUL (Node G) 🗺️
The 6LBR encapsulates the packet in an IPv6-in-IPv6 header and prepends an RPI. The IPv6-in-IPv6 header is addressed to the 6LR parent of the RUL (6LR_n). That 6LR parent removes the header and sends the packet on to the RUL 📦
Table 7 summarizes which headers are needed for this use case:
+==================+===============+=========+=========+=========+
| Header | 6LBR src | 6LR_i | 6LR_n | RUL dst |
+==================+===============+=========+=========+=========+
| Added headers | IP6-IP6 (RPI) | -- | -- | -- |
+==================+---------------+---------+---------+---------+
| Modified headers | -- | RPI | -- | -- |
+==================+---------------+---------+---------+---------+
| Removed headers | -- | -- | IP6-IP6 | -- |
| | | | (RPI) | |
+==================+---------------+---------+---------+---------+
| Untouched | -- | IP6-IP6 | -- | -- |
| headers | | | | |
+==================+---------------+---------+---------+---------+
Table 7: SM: Summary of the Use of Headers from Root to RULIP-in-IP encapsulation may be avoided for root-to-RUL communication 🪄 In SM, it can be replaced by a loose RH3 header that indicates the RUL. In that case, the packet is routed to the 6LR as a normal SM operation, then the 6LR forwards it to the RUL based on the RH3, and the RUL ignores both the consumed RH3 and the RPI, just like in Non-Storing mode 🌸
Table 8 summarizes which headers are needed for this scenario:
+===========+======+==============+===============+================+
| Header | 6LBR | 6LR_i | 6LR_n | RUL dst |
| | src | i=(1,..,n-1) | | |
+===========+======+==============+===============+================+
| Added | RPI, | -- | -- | -- |
| headers | RH3 | | | |
+===========+------+--------------+---------------+----------------+
| Modified | -- | RPI | RPI, | -- |
| headers | | | RH3(consumed) | |
+===========+------+--------------+---------------+----------------+
| Removed | -- | -- | -- | -- |
| headers | | | | |
+===========+------+--------------+---------------+----------------+
| Untouched | -- | RH3 | -- | RPI, RH3 (both |
| headers | | | | ignored) |
+===========+------+--------------+---------------+----------------+
Table 8: SM: Summary of the Use of Headers from Root to RUL without
Encapsulation7.1.4. SM: Example of Flow from RUL to Root 🦋
okay so this one is the RUL (the IPv6 source node) sending stuff up to the root 💖
The flow looks like this:
RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR)
For example, a communication flow could be: Node G (RUL) --> Node E (6LR_1) --> Node B (6LR_i) --> Node A root (6LBR) 🌸
6LR_i stands for the intermediate routers between the source (RUL) and the destination (6LBR), where 1 <= i <= n and n is the total number of routers (6LR) the packet goes through, from the RUL to the 6LBR ✨
So when the packet lands from the RUL (Node G) at 6LR_1 (Node E), 6LR_1 wraps it in an IPv6-in-IPv6 header with an RPI 🎀 That outer header is addressed to the root (Node A). The root takes the header off and then processes the packet 👑
Here's Table 9, which shows the headers you need for this use case where the IPv6-in-IPv6 header is addressed to the root (Node A) 💅
+==================+=========+===============+=========+==========+
| Header | RUL src | 6LR_1 | 6LR_i | 6LBR dst |
+==================+=========+===============+=========+==========+
| Added headers | -- | IP6-IP6 (RPI) | -- | -- |
+==================+---------+---------------+---------+----------+
| Modified headers | -- | -- | RPI | -- |
+==================+---------+---------------+---------+----------+
| Removed headers | -- | -- | -- | IP6-IP6 |
| | | | | (RPI) |
+==================+---------+---------------+---------+----------+
| Untouched | -- | -- | IP6-IP6 | -- |
| headers | | | | |
+==================+---------+---------------+---------+----------+
Table 9: SM: Summary of the Use of Headers from RUL to Root7.2. SM: Interaction between Leaf and Internet 🌈
this section walks through the Storing mode (SM) flows between these pairs:
- RAL to Internet
- Internet to RAL
- RUL to Internet
- Internet to RUL
7.2.1. SM: Example of Flow from RAL to Internet 🧚
the flow here is:
RAL (6LN) --> 6LR_i --> root (6LBR) --> Internet
For example, the communication flow could be: Node F (RAL) --> Node D (6LR_i) --> Node B (6LR_i) --> Node A root (6LBR) --> Internet 💖
6LR_i is the intermediate routers from the source (RAL) to the root (6LBR), where 1 <= i <= n and n is the total number of routers (6LR) the packet goes through, from the RAL to the 6LBR ✨
RPL information from RFC 6553 can go out to the Internet, and it'll be ignored by nodes that haven't been set up to be RPL aware. No IPv6-in-IPv6 header is needed for that 🫶
BUT the RAL can also pop the RPI inside an IPv6-in-IPv6 header going to the root. Then the root removes the RPI and sends the packet on to the Internet 🔥
Note: In this use case, a leaf node is used, but this use case can also be applicable to any RPL-aware node type (e.g., 6LR).
Table 10 covers the headers you need when there's no encapsulation. Heads up: the RPI gets modified by the 6LBR so the SenderRank is set to zero, unless it's already zero 🙈 Table 11 covers the headers you need when encapsulation to the root happens 💅
+===================+=========+=======+======+===============+
| Header | RAL src | 6LR_i | 6LBR | Internet dst |
+===================+=========+=======+======+===============+
| Added headers | RPI | -- | -- | -- |
+===================+---------+-------+------+---------------+
| Modified headers | -- | RPI | RPI | -- |
+===================+---------+-------+------+---------------+
| Removed headers | -- | -- | -- | -- |
+===================+---------+-------+------+---------------+
| Untouched headers | -- | -- | -- | RPI (Ignored) |
+===================+---------+-------+------+---------------+
Table 10: SM: Summary of the Use of Headers from RAL to
Internet with No Encapsulation
+===============+===============+=========+=========+==============+
| Header | RAL src | 6LR_i | 6LBR | Internet dst |
+===============+===============+=========+=========+==============+
| Added headers | IP6-IP6 (RPI) | -- | -- | -- |
+===============+---------------+---------+---------+--------------+
| Modified | -- | RPI | -- | -- |
| headers | | | | |
+===============+---------------+---------+---------+--------------+
| Removed | -- | -- | IP6-IP6 | -- |
| headers | | | (RPI) | |
+===============+---------------+---------+---------+--------------+
| Untouched | -- | IP6-IP6 | -- | -- |
| headers | | | | |
+===============+---------------+---------+---------+--------------+
Table 11: SM: Summary of the Use of Headers from RAL to Internet
with Encapsulation to the Root (6LBR)7.2.2. SM: Example of Flow from Internet to RAL 🌸
the flow here is:
Internet --> root (6LBR) --> 6LR_i --> RAL (6LN)
For example, a communication flow could be: Internet --> Node A root (6LBR) --> Node B (6LR_1) --> Node D (6LR_n) --> Node F (RAL) 🦋
When a packet comes in from the Internet to the 6LBR, the RPI gets added in an outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination address set to the RAL), and it's sent on to the 6LR, which modifies the Rank in the RPI. Once the packet reaches the RAL, it gets decapsulated, which removes the RPI before the packet is processed 🎀
Table 12 covers the headers you need for this use case 💖
+==================+==============+===============+=======+=========+
| Header | Internet src | 6LBR | 6LR_i | RAL dst |
+==================+==============+===============+=======+=========+
| Added headers | -- | IP6-IP6 (RPI) | -- | -- |
+==================+--------------+---------------+-------+---------+
| Modified | -- | -- | RPI | -- |
| headers | | | | |
+==================+--------------+---------------+-------+---------+
| Removed | -- | -- | -- | IP6-IP6 |
| headers | | | | (RPI) |
+==================+--------------+---------------+-------+---------+
| Untouched | -- | -- | -- | -- |
| headers | | | | |
+==================+--------------+---------------+-------+---------+
Table 12: SM: Summary of the Use of Headers from Internet to RAL7.2.3. SM: Example of Flow from RUL to Internet 🫧
the flow here is:
RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) --> Internet
For example, a communication flow could be: Node G (RUL) --> Node E (6LR_1) --> Node B (6lR_i) --> Node A root (6LBR) --> Internet ✨
Node 6LR_1 (i=1) adds an IPv6-in-IPv6 (RPI) header addressed to the root, so the root can remove the RPI before passing the packet upwards 💅 At the intermediate 6LR, the Rank in the RPI gets modified 🌈
The originating node will ideally leave the IPv6 flow label as zero, so the packet can be better compressed through the LLN 🧚 The 6LBR will set the flow label of the packet to a non-zero value when sending to the Internet. For details, check [RFC6437] 🔥
Table 13 covers the headers you need for this use case 💜
+===========+==========+=========+============+=========+==========+
| Header | IPv6 src | 6LR_1 | 6LR_i | 6LBR | Internet |
| | (RUL) | | i=(2,..,n) | | dst |
+===========+==========+=========+============+=========+==========+
| Added | -- | IP6-IP6 | -- | -- | -- |
| headers | | (RPI) | | | |
+===========+----------+---------+------------+---------+----------+
| Modified | -- | -- | RPI | -- | -- |
| headers | | | | | |
+===========+----------+---------+------------+---------+----------+
| Removed | -- | -- | -- | IP6-IP6 | -- |
| headers | | | | (RPI) | |
+===========+----------+---------+------------+---------+----------+
| Untouched | -- | -- | -- | -- | -- |
| headers | | | | | |
+===========+----------+---------+------------+---------+----------+
Table 13: SM: Summary of the Use of Headers from RUL to Internet7.2.4. SM: Example of Flow from Internet to RUL 🍓
the flow here is:
Internet --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)
For example, a communication flow could be: Internet --> Node A root (6LBR) --> Node B (6LR_i) --> Node E (6LR_n) --> Node G (RUL) 💖
The 6LBR has to add an RPI within an IPv6-in-IPv6 header. That IPv6-in-IPv6 encapsulating header is addressed to the 6LR parent of the RUL 🎀
More details on this are in [RFC9010], which specifies RPL routing for a 6LN acting as a plain host and being unaware of RPL 🦋
The 6LBR may set the flow label on the inner IPv6-in-IPv6 header to zero to help with compression [RFC8138] [RFC6437] ✨
Table 14 covers the headers you need for this use case 🌷
+===========+==============+=========+==============+=========+=====+
| Header | Internet | 6LBR | 6LR_i | 6LR_n | RUL |
| | src | | i=(1,..,n-1) | | dst |
+===========+==============+=========+==============+=========+=====+
| Added | -- | IP6-IP6 | -- | -- | -- |
| headers | | (RPI) | | | |
+===========+--------------+---------+--------------+---------+-----+
| Modified | -- | -- | RPI | -- | -- |
| headers | | | | | |
+===========+--------------+---------+--------------+---------+-----+
| Removed | -- | -- | -- | IP6-IP6 | -- |
| headers | | | | (RPI) | |
+===========+--------------+---------+--------------+---------+-----+
| Untouched | -- | -- | -- | -- | -- |
| headers | | | | | |
+===========+--------------+---------+--------------+---------+-----+
Table 14: SM: Summary of the Use of Headers from Internet to RUL7.3. SM: Interaction between Leaf and Leaf 🧸
this section describes the Storing mode (SM) flows between these pairs:
- RAL to RAL
- RAL to RUL
- RUL to RAL
- RUL to RUL
7.3.1. SM: Example of Flow from RAL to RAL ✨
Okay so [RFC6550] (that's RPL, bestie 🌸) has this super simple one-hop shortcut for both Storing and Non-Storing networks. A node may send a packet destined to a one-hop neighbor directly to that node. Iconic, right? See Section 9 of [RFC6550] for the details 💅
When the nodes are not directly connected, the flow in Storing mode looks like this 🦋
RAL src (6LN) --> 6LR_ia --> common parent (6LR_x) --> 6LR_id --> RAL
dst (6LN)Here's an example so you can picture it 🧚
Node F (RAL src) --> Node D (6LR_ia) --> Node B (6LR_x) --> Node E (6LR_id) --> Node H (RAL dst)So 6LR_ia (Node D) is the set of intermediate routers from the source up to the common parent 6LR_x (Node B). The index runs 1 <= ia <= n, where n is the total number of routers (6LR) the packet goes through, from the RAL (Node F) to the common parent 6LR_x (Node B) 🌈
Then 6LR_id (Node E) is the set of intermediate routers from the common parent 6LR_x (Node B) down to the destination RAL (Node H). Here the index runs 1 <= id <= m, where m is the total number of routers (6LR) the packet goes through, from the common parent (6LR_x) to the destination RAL (Node H) 💖
Now the important bit 👑 It is assumed that the two nodes are in the same RPL domain (they share the same DODAG root). At the common parent (Node B), the direction flag ('O' flag) of the RPI gets changed, from decreasing ranks to increasing ranks. Plot twist: the 6LR nodes update the RPI, but no node needs to add or remove it, so no IPv6-in-IPv6 headers are necessary. No extra wrapping, no drama 🫶
Table 15 sums up which headers are needed for this use case 📋
+===========+=========+========+===============+========+=====+
| Header | RAL src | 6LR_ia | 6LR_x (common | 6LR_id | RAL |
| | | | parent) | | dst |
+===========+=========+========+===============+========+=====+
| Added | RPI | -- | -- | -- | -- |
| headers | | | | | |
+===========+---------+--------+---------------+--------+-----+
| Modified | -- | RPI | RPI | RPI | -- |
| headers | | | | | |
+===========+---------+--------+---------------+--------+-----+
| Removed | -- | -- | -- | -- | RPI |
| headers | | | | | |
+===========+---------+--------+---------------+--------+-----+
| Untouched | -- | -- | -- | -- | -- |
| headers | | | | | |
+===========+---------+--------+---------------+--------+-----+
Table 15: SM: Summary of the Use of Headers from RAL to RAL7.3.2. SM: Example of Flow from RAL to RUL 🦋
Okay, this one's a little more involved, so buckle up 🎀 In this case the flow is:
RAL src (6LN) --> 6LR_ia --> common parent (6LBR, the root) -->
6LR_id --> RUL (IPv6 dst node)Example time 🧚
Node F (RAL) --> Node D --> Node B --> Node A --> Node B --> Node E --> Node G (RUL)6LR_ia is the set of intermediate routers from the source (RAL) up to the common parent (the root), with 1 <= ia <= n, where n is the total number of routers (6LR) the packet goes through, from the RAL to the root 🌸
6LR_id (Node E) is the set of intermediate routers from the root (Node B) down to the destination RUL (Node G). In this case 1 <= id <= m, where m is the total number of routers (6LR) the packet goes through, from the root down to the destination RUL ✨
Here's the tea ☕ The packet from the RAL goes to the 6LBR because the route to the RUL is not injected into the RPL SM. So the RAL inserts an RPI (RPI1) addressed to the root (6LBR). The root does not remove the RPI1, because the root cannot remove an RPI if there is no encapsulation 🙈 Instead, the root inserts an IPv6-in-IPv6 encapsulation carrying an RPI2 and sends it to the 6LR parent of the RUL. That parent removes the encapsulation and RPI2 before passing the packet to the RUL 🫶
Table 16 summarizes which headers are needed for this use case 📋
+===========+=====+========+=========+========+=========+===========+
| Header | RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL dst |
| | src | | | | | |
+===========+=====+========+=========+========+=========+===========+
| Added | RPI1| -- | IP6-IP6 | -- | -- | -- |
| headers | | | (RPI2) | | | |
+===========+-----+--------+---------+--------+---------+-----------+
| Modified | -- | RPI1 | -- | RPI2 | -- | -- |
| headers | | | | | | |
+===========+-----+--------+---------+--------+---------+-----------+
| Removed | -- | -- | -- | -- | IP6-IP6 | -- |
| headers | | | | | (RPI2) | |
+===========+-----+--------+---------+--------+---------+-----------+
| Untouched | -- | -- | RPI1 | RPI1 | RPI1 | RPI1 |
| headers | | | | | | (ignored) |
+===========+-----+--------+---------+--------+---------+-----------+
Table 16: SM: Summary of the Use of Headers from RAL to RUL7.3.3. SM: Example of Flow from RUL to RAL 💜
Flipping it around 🔄 In this case the flow is:
RUL (IPv6 src node) --> 6LR_ia --> 6LBR --> 6LR_id --> RAL dst (6LN)Example 🧚
Node G (RUL) --> Node E --> Node B --> Node A --> Node B --> Node D --> Node F (RAL)6LR_ia (Node E) is the set of intermediate routers from the source (RUL, Node G) up to the root (Node A), with 1 <= ia <= n, where n is the total number of routers (6LR) the packet goes through, from the source to the root 🌈
6LR_id is the set of intermediate routers from the root (Node A) down to the destination RAL (Node F). Here 1 <= id <= m, where m is the total number of routers (6LR) the packet goes through, from the root to the destination RAL 💖
The 6LR_1 (Node E) receives the packet from the RUL (Node G) and inserts the RPI (RPI1) inside an IPv6-in-IPv6 header aimed at the root. The root removes that outer header, RPI1 and all, and inserts a fresh RPI (RPI2) addressed to the destination RAL (Node F) 👑
Table 17 summarizes which headers are needed for this use case 📋
+===========+=====+=========+========+=========+========+=========+
| Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL dst |
| | src | | | | | |
+===========+=====+=========+========+=========+========+=========+
| Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- |
| headers | | (RPI1) | | (RPI2) | | |
+===========+-----+---------+--------+---------+--------+---------+
| Modified | -- | -- | RPI1 | -- | RPI2 | -- |
| headers | | | | | | |
+===========+-----+---------+--------+---------+--------+---------+
| Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 |
| headers | | | | (RPI1) | | (RPI2) |
+===========+-----+---------+--------+---------+--------+---------+
| Untouched | -- | -- | -- | -- | -- | -- |
| headers | | | | | | |
+===========+-----+---------+--------+---------+--------+---------+
Table 17: SM: Summary of the Use of Headers from RUL to RAL7.3.4. SM: Example of Flow from RUL to RUL 🌈
Last one, and it's a whole vibe 💅 In this case the flow is:
RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> 6LBR --> 6LR_id --> RUL
(IPv6 dst node)Example 🧚
Node G (RUL src) --> Node E --> Node B --> Node A (root) --> Node C --> Node J (RUL dst)The internal nodes 6LR_ia (e.g., Node E or Node B) are the intermediate routers from the RUL source (Node G) up to the root (6LBR, Node A). Here 1 <= ia <= n, where n is the total number of routers (6LR) the packet goes through, from the RUL to the root. 6LR_1 applies when ia=1 🌸
6LR_id (Node C) is the set of intermediate routers from the root (Node A) down to the destination RUL (Node J). In this case 1 <= id <= m, where m is the total number of routers (6LR) the packet goes through, from the root to the destination RUL 🦋
The 6LR_1 (Node E) receives the packet from the RUL (Node G) and adds the RPI (RPI1) in an IPv6-in-IPv6 encapsulation directed to the root. The root removes the outer header, including RPI1, and inserts a new RPI (RPI2) addressed to the 6LR parent of the RUL ✨
Table 18 summarizes which headers are needed for this use case 📋
+===========+===+=========+========+=========+========+=========+===+
| Header |RUL| 6LR_1 | 6LR_ia | 6LBR | 6LR_id | 6LR_n |RUL|
| |src| | | | | |dst|
+===========+===+=========+========+=========+========+=========+===+
| Added | --| IP6-IP6 | -- | IP6-IP6 | -- | -- | --|
| headers | | (RPI1) | | (RPI1) | | | |
+===========+---+---------+--------+---------+--------+---------+---+
| Modified | --| -- | RPI1 | -- | RPI2 | -- | --|
| headers | | | | | | | |
+===========+---+---------+--------+---------+--------+---------+---+
| Removed | --| -- | -- | IP6-IP6 | -- | IP6-IP6 | --|
| headers | | | | (RPI1) | | (RPI2) | |
+===========+---+---------+--------+---------+--------+---------+---+
| Untouched | --| -- | -- | -- | -- | -- | --|
| headers | | | | | | | |
+===========+---+---------+--------+---------+--------+---------+---+
Table 18: SM: Summary of the Use of Headers from RUL to RUL8. Non-Storing Mode ✨
okay bestie, Non-Storing mode (Non-SM) is the fully source routed one 🦋 The 6LBR (DODAG root) knows the connectivity of every DODAG node and every traffic flow goes through the root 👑 So nobody else has to know that RPL-unaware nodes exist. Only the 6LBR has to step in if compensation is needed for RPL-unaware receivers. the root really is doing everything, iconic 💅
Table 19 is your cheat sheet for which headers show up in each scenario and when the RPI, RH3, and IPv6-in-IPv6 header get inserted 📋 The last column is the target destination of the IPv6-in-IPv6 header: 6LN (written as "RAL"), 6LR (the parent of a RUL), or the root. If no IPv6-in-IPv6 header is needed, that column says "No" 🙈 RPL doesn't expect the RPI to ever be left out, because it's needed for routing, quality of service, and compression, so this spec expects an RPI to always be present ✨ Quick decoder: "may(up)" means the IPv6-in-IPv6 header may be necessary in the Upward direction, "must(up)" means it must be there in the Upward direction, and "must(down)" means it must be there in the Downward direction 🌸
The leaf can be a router (6LR) or a host, and both get labelled 6LN (Figure 3) 🧚 In Table 19, the (1) marks a 6TiSCH case [RFC8180], where the RPI might still be needed so the RPLInstanceID is available for priority and channel selection at each hop 🍓
+=============+========+=====+=====+==============+==========+
| Interaction | Use | RPI | RH3 | IPv6-in-IPv6 | IP-in-IP |
| between | Case | | | | dst |
+=============+========+=====+=====+==============+==========+
| Leaf - Root | RAL to | Yes | No | No | No |
| | root | | | | |
| +--------+-----+-----+--------------+----------+
| | root | Yes | Yes | No | No |
| | to RAL | | | | |
| +--------+-----+-----+--------------+----------+
| | root | Yes | Yes | No | 6LR |
| | to RUL | (1) | | | |
| +--------+-----+-----+--------------+----------+
| | RUL to | Yes | No | must | root |
| | root | | | | |
+=============+--------+-----+-----+--------------+----------+
| Leaf - | RAL to | Yes | No | may(up) | root |
| Internet | Int | | | | |
| +--------+-----+-----+--------------+----------+
| | Int to | Yes | Yes | must | RAL |
| | RAL | | | | |
| +--------+-----+-----+--------------+----------+
| | RUL to | Yes | No | must | root |
| | Int | | | | |
| +--------+-----+-----+--------------+----------+
| | Int to | Yes | Yes | must | 6LR |
| | RUL | | | | |
+=============+--------+-----+-----+--------------+----------+
| Leaf - Leaf | RAL to | Yes | Yes | may(up) | root |
| | RAL | | +--------------+----------+
| | | | | must(down) | RAL |
| +--------+-----+-----+--------------+----------+
| | RAL to | Yes | Yes | may(up) | root |
| | RUL | | +--------------+----------+
| | | | | must(down) | 6LR |
| +--------+-----+-----+--------------+----------+
| | RUL to | Yes | Yes | must(up) | root |
| | RAL | | +--------------+----------+
| | | | | must(down) | RAL |
| +--------+-----+-----+--------------+----------+
| | RUL to | Yes | Yes | must(up) | root |
| | RUL | | +--------------+----------+
| | | | | must(down) | 6LR |
+=============+--------+-----+-----+--------------+----------+
Table 19: Headers Needed in Non-Storing Mode: RPI, RH3,
IPv6-in-IPv6 Encapsulation8.1. Non-Storing Mode: Interaction between Leaf and Root 🌈
this section walks through the communication flows in Non-SM between these four pairs 👯♀️
- RAL to root
- root to RAL
- RUL to root
- root to RUL
8.1.1. Non-SM: Example of Flow from RAL to Root 🚀
in Non-Storing mode the leaf uses default routing to send traffic up to the root 🙌 The RPI must be included, because it carries the Rank information that's used to avoid and/or detect loops 🔁
RAL (6LN) --> 6LR_i --> root(6LBR)
for example, a flow could look like Node F --> Node D --> Node B --> Node A (root) 🦋
6LR_i stands for the intermediate routers between the source and the destination. Here 1 <= i <= n, where n is the total number of routers (6LR) the packet passes through, going from the source (RAL) to the destination (6LBR) 🧭
this is the same situation as Storing mode, so no plot twist here 💖
Table 20 shows which headers are needed for this use case 📋
+===================+=========+=======+==========+
| Header | RAL src | 6LR_i | 6LBR dst |
+===================+=========+=======+==========+
| Added headers | RPI | -- | -- |
+===================+---------+-------+----------+
| Modified headers | -- | RPI | -- |
+===================+---------+-------+----------+
| Removed headers | -- | -- | RPI |
+===================+---------+-------+----------+
| Untouched headers | -- | -- | -- |
+===================+---------+-------+----------+
Table 20: Non-SM: Summary of the Use of
Headers from RAL to Root8.1.2. Non-SM: Example of Flow from Root to RAL 👑
in this case the flow goes:
root (6LBR) --> 6LR_i --> RAL (6LN)
for example, a flow could look like Node A (root) --> Node B --> Node D --> Node F ✨
6LR_i again means the intermediate routers from source to destination, where 1 <= i <= n and n is the total number of routers (6LR) the packet goes through, from the source (6LBR) to the destination (RAL) 🌸
the 6LBR inserts an RH3 and an RPI 💅 No IPv6-in-IPv6 header is necessary, because the traffic starts at a RPL-aware node, the 6LBR. The destination is known to be RPL-aware too, since in Non-Storing mode the root knows the whole topology 🧠
Table 21 shows which headers are needed here 📋
+===================+==========+==========+==========+
| Header | 6LBR src | 6LR_i | RAL dst |
+===================+==========+==========+==========+
| Added headers | RPI, RH3 | -- | -- |
+===================+----------+----------+----------+
| Modified headers | -- | RPI, RH3 | -- |
+===================+----------+----------+----------+
| Removed headers | -- | -- | RPI, RH3 |
+===================+----------+----------+----------+
| Untouched headers | -- | -- | -- |
+===================+----------+----------+----------+
Table 21: Non-SM: Summary of the Use of Headers
from Root to RAL8.1.3. Non-SM: Example of Flow from Root to RUL 🦋
in this case the flow goes:
root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)
for example, a flow could look like Node A (root) --> Node B --> Node E --> Node G (RUL) 🧚
6LR_i is the intermediate routers from source to destination again, with 1 <= i <= n, where n is the total number of routers (6LR) the packet goes through, from the source (6LBR) to the destination (RUL) 💜
so the 6LBR adds the RH3. Each intermediate 6LR (6LR_1 and so on) modifies it, and it's fully consumed at the last 6LR (6LR_n) but left in place 🌈 When the RPI gets added, the RUL doesn't understand it, so it just ignores it (per [RFC8200]). That means no encapsulation is needed 🙈
Table 22 shows which headers are needed for this use case 📋
+===========+======+==============+===============+================+
| Header | 6LBR | 6LR_i | 6LR_n | RUL dst |
| | src | i=(1,..,n-1) | | |
+===========+======+==============+===============+================+
| Added | RPI, | -- | -- | -- |
| headers | RH3 | | | |
+===========+------+--------------+---------------+----------------+
| Modified | -- | RPI, RH3 | RPI, | -- |
| headers | | | RH3(consumed) | |
+===========+------+--------------+---------------+----------------+
| Removed | -- | -- | -- | -- |
| headers | | | | |
+===========+------+--------------+---------------+----------------+
| Untouched | -- | -- | -- | RPI, RH3 (both |
| headers | | | | ignored) |
+===========+------+--------------+---------------+----------------+
Table 22: Non-SM: Summary of the Use of Headers from Root to RUL8.1.4. Non-SM: Example of Flow from RUL to Root 🌸
okay so this one is a whole relay race 🏃♀️💨 the flow goes:
RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) dstfor example: Node G --> Node E --> Node B --> Node A (root) 🧚
6LR_i is just the group of middle routers between the source and the destination. 1 <= i <= n, where n is the total number of routers (6LR) the packet goes through, from the source (RUL) to the destination (6LBR). 6LR_1 (i=1) is the first router, the one that receives the packets straight from the RUL 💅
here's the tea: the RPI gets added by the first 6LR (6LR_1, which is Node E), wrapped in an IPv6-in-IPv6 header, and then the later 6LRs in the flow can modify it. at the end, the root consumes the RPI and the whole packet. iconic 👑
Table 23 shows which headers are needed for this use case 📋
+===============+=========+==============+=======+==============+
| Header | RUL src | 6LR_1 | 6LR_i | 6LBR dst |
+===============+=========+==============+=======+==============+
| Added headers | -- | IPv6-in-IPv6 | -- | -- |
| | | (RPI) | | |
+===============+---------+--------------+-------+--------------+
| Modified | -- | -- | RPI | -- |
| headers | | | | |
+===============+---------+--------------+-------+--------------+
| Removed | -- | -- | -- | IPv6-in-IPv6 |
| headers | | | | (RPI) |
+===============+---------+--------------+-------+--------------+
| Untouched | -- | -- | -- | -- |
| headers | | | | |
+===============+---------+--------------+-------+--------------+
Table 23: Non-SM: Summary of the Use of Headers from RUL to Root8.2. Non-Storing Mode: Interaction between Leaf and Internet 🌍
this section is about Non-Storing mode (Non-SM) and the flows between:
- RAL to Internet
- Internet to RAL
- RUL to Internet
- Internet to RUL
we're going to walk through all four, bestie 🫶
8.2.1. Non-SM: Example of Flow from RAL to Internet ✨
the flow looks like this:
RAL (6LN) src --> 6LR_i --> root (6LBR) --> Internet dstfor example: Node F (RAL) --> Node D --> Node B --> Node A --> Internet. so, the RAL knows about the RPL domain, and when the destination is not in the RAL's RPL domain, the packet may be encapsulated to the root 🦋
6LR_i is again the intermediate routers from source to destination, with 1 <= i <= n, where n is the total number of routers (6LR) the packet goes through, from the source (RAL) to the 6LBR.
ngl the encapsulation from the RAL to the root is optional 💖 the simplest version is when the RPI just travels all the way to the Internet (see Table 24), and the Internet is going to ignore it. no drama 🙈
the IPv6 flow label should be set to zero to help with compression [RFC8138], and then the 6LBR will set it to a non-zero value when it's sending toward the Internet [RFC6437] 🎀
Table 24 summarizes the headers needed when no encapsulation is used, and Table 25 summarizes the headers needed when encapsulation to the root is used 📋
+===================+=========+=======+======+===============+
| Header | RAL src | 6LR_i | 6LBR | Internet dst |
+===================+=========+=======+======+===============+
| Added headers | RPI | -- | -- | -- |
+===================+---------+-------+------+---------------+
| Modified headers | -- | RPI | RPI | -- |
+===================+---------+-------+------+---------------+
| Removed headers | -- | -- | -- | -- |
+===================+---------+-------+------+---------------+
| Untouched headers | -- | -- | -- | RPI (Ignored) |
+===================+---------+-------+------+---------------+
Table 24: Non-SM: Summary of the Use of Headers from RAL
to Internet with No Encapsulation +===========+===============+=======+==============+==============+
| Header | RAL src | 6LR_i | 6LBR | Internet dst |
+===========+===============+=======+==============+==============+
| Added | IP6v6-in-IPv6 | -- | -- | -- |
| headers | (RPI) | | | |
+===========+---------------+-------+--------------+--------------+
| Modified | -- | RPI | -- | -- |
| headers | | | | |
+===========+---------------+-------+--------------+--------------+
| Removed | -- | -- | IPv6-in-IPv6 | -- |
| headers | | | (RPI) | |
+===========+---------------+-------+--------------+--------------+
| Untouched | -- | -- | -- | -- |
| headers | | | | |
+===========+---------------+-------+--------------+--------------+
Table 25: Non-SM: Summary of the Use of Headers from RAL to
Internet with Encapsulation to the Root8.2.2. Non-SM: Example of Flow from Internet to RAL 🧚♀️
the flow goes:
Internet --> root (6LBR) --> 6LR_i --> RAL dst (6LN)for example: Internet --> Node A (root) --> Node B --> Node D --> Node F (RAL) 💫
6LR_i is the intermediate routers from source to destination, with 1 <= i <= n, where n is the total number of routers (6LR) the packet goes through, from the 6LBR to the destination (RAL).
okay so here's the important bit: the 6LBR must add an RH3 header 🚨 and because the 6LBR knows the path and address of the target node, it can address the IPv6-in-IPv6 header to that node. the 6LBR will also zero the flow label on entry to help with compression [RFC8138] 🌈
Table 26 shows the headers needed for this use case 📋
+===========+==========+==============+==============+==============+
| Header | Internet | 6LBR | 6LR_i | RAL dst |
| | src | | | |
+===========+==========+==============+==============+==============+
| Added | -- | IPv6-in-IPv6 | -- | -- |
| headers | | (RH3, RPI) | | |
+===========+----------+--------------+--------------+--------------+
| Modified | -- | -- | IPv6-in-IPv6 | -- |
| headers | | | (RH3, RPI) | |
+===========+----------+--------------+--------------+--------------+
| Removed | -- | -- | -- | IPv6-in-IPv6 |
| headers | | | | (RH3, RPI) |
+===========+----------+--------------+--------------+--------------+
| Untouched | -- | -- | -- | -- |
| headers | | | | |
+===========+----------+--------------+--------------+--------------+
Table 26: Non-SM: Summary of the Use of Headers from Internet to RAL8.2.3. Non-SM: Example of Flow from RUL to Internet 🌟
the flow goes:
RUL (IPv6 src node) --> 6LR_1 --> 6LR_i --> root (6LBR) --> Internet
dstfor example: Node G --> Node E --> Node B --> Node A --> Internet 🍓
6LR_i is the intermediate routers from the source to the destination, with 1 <= i <= n, where n is the total number of routers (6LRs) the packet goes through, from the source (RUL) to the 6LBR, e.g., 6LR_1 (i=1).
in this case the flow label is recommended to be zero in the RUL. then, since the RUL parent adds RPL headers in the RUL packet, the first 6LR (6LR_1) adds an RPI inside a new IPv6-in-IPv6 header 🦋 that outer header gets addressed to the root. this case is identical to the Storing mode case (see Section 7.2.3), so if you've already met that one, you're basically a pro now 💅
Table 27 summarizes the headers needed for this use case 📋
+===========+=========+=========+============+=========+==========+
| Header | RUL src | 6LR_1 | 6LR_i | 6LBR | Internet |
| | | | i=(2,..,n) | | dst |
+===========+=========+=========+============+=========+==========+
| Added | -- | IP6-IP6 | -- | -- | -- |
| headers | | (RPI) | | | |
+===========+---------+---------+------------+---------+----------+
| Modified | -- | -- | RPI | -- | -- |
| headers | | | | | |
+===========+---------+---------+------------+---------+----------+
| Removed | -- | -- | -- | IP6-IP6 | -- |
| headers | | | | (RPI) | |
+===========+---------+---------+------------+---------+----------+
| Untouched | -- | -- | -- | -- | -- |
| headers | | | | | |
+===========+---------+---------+------------+---------+----------+
Table 27: Non-SM: Summary of the Use of Headers from RUL to
Internet8.2.4. Non-SM: Example of Flow from Internet to RUL 🦋
okay so this one is the Internet sending to a RUL (a non-RPL node) 🫶 The flow goes like this:
Internet src --> root (6LBR) --> 6LR_i --> RUL (IPv6 dst node)
so a communication flow could be: Internet --> Node A (root) --> Node B --> Node E --> Node G ✨
6LR_i stands for the intermediate routers from the source to the destination, and 1 <= i <= n, where n is the total number of routers (6LR) that the packet goes through, from the 6LBR to the RUL. 💜
The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. It knows the path, and it can tell the final node isn't an RPL-capable node because it got the connectivity DAO from the nearest 6LR 👀 So the 6LBR can make the IPv6-in-IPv6 header's destination be the last 6LR. The 6LBR will set the flow label to zero when it enters, so compression works nicely [RFC8138] 🎀
Table 28 sums up which headers you need for this use case 🍓
+===========+==========+============+============+============+=====+
| Header | Internet | 6LBR | 6LR_i | 6LR_n | RUL |
| | src | | | | dst |
+===========+==========+============+============+============+=====+
| Added | -- | IP6-IP6 | -- | -- | -- |
| headers | | (RH3, RPI) | | | |
+===========+----------+------------+------------+------------+-----+
| Modified | -- | -- | IP6-IP6 | -- | -- |
| headers | | | (RH3, RPI) | | |
+===========+----------+------------+------------+------------+-----+
| Removed | -- | -- | -- | IP6-IP6 | -- |
| headers | | | | (RH3, | |
| | | | | RPI) | |
+===========+----------+------------+------------+------------+-----+
| Untouched | -- | -- | -- | -- | -- |
| headers | | | | | |
+===========+----------+------------+------------+------------+-----+Table 28: Non-SM: Summary of the Use of Headers from Internet to RUL
8.3. Non-SM: Interaction between Leaves 🌸
This section walks through the communication flow in Non-Storing mode (Non-SM) between the following:
- RAL to RAL
- RAL to RUL
- RUL to RAL
- RUL to RUL
8.3.1. Non-SM: Example of Flow from RAL to RAL ✨
okay this one is RAL to RAL, and the flow is:
RAL src --> 6LR_ia --> root (6LBR) --> 6LR_id --> RAL dst
so a communication flow could be: Node F (RAL src) --> Node D --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL dst) 🧚
6LR_ia stands for the intermediate routers from the source to the root, and 1 <= ia <= n, where n is the total number of routers (6LR) that the packet goes through, from the RAL to the root. 💅
6LR_id stands for the intermediate routers from the root to the destination, and 1 <= id <= m, where m is the total number of the intermediate routers (6LR). 🌈
This case only involves nodes in the same RPL domain 🏠 The originating node adds an RPI to the original packet and sends it Upward ⬆️
The originating node may put the RPI (RPI1) into an IPv6-in-IPv6 header addressed to the root, so the 6LBR can remove that header. If it doesn't, then the RPI1 gets forwarded down from the root in the inner header to no avail 😭
The 6LBR needs to insert an RH3 header, which means it has to add an IPv6-in-IPv6 header. It removes the RPI (RPI1), since it was sitting in an IPv6-in-IPv6 header addressed to it. Otherwise, there may be an RPI buried inside the inner IP header, which should be ignored 🙈 The root inserts an RPI (RPI2) alongside the RH3 🫶
Networks that use the RPL point-to-point extension [RFC6997] are basically Non-Storing DODAGs, so they fall into this scenario or the scenario given in Section 8.1.2, with the originating node acting as a 6LBR. 👑
Table 29 sums up which headers you need for this use case when encapsulation to the root takes place 🎀
Table 30 sums up which headers you need for this use case when there's no encapsulation to the root 💖 Quick heads up: in the Modified headers row, going up through each 6LR_ia only the RPI1 changes. Going down, in each 6LR_id the IPv6 header gets swapped with the RH3, so both change along with the RPI2 🦋
+===========+=========+========+===============+=========+=========+
| Header | RAL src | 6LR_ia | 6LBR | 6LR_id | RAL dst |
+===========+=========+========+===============+=========+=========+
| Added | IP6-IP6 | -- | IP6-IP6 (RH3 | -- | -- |
| headers | (RPI1) | | -> RAL, RPI2) | | |
+===========+---------+--------+---------------+---------+---------+
| Modified | -- | RPI1 | -- | IP6-IP6 | -- |
| headers | | | | (RH3, | |
| | | | | RPI2) | |
+===========+---------+--------+---------------+---------+---------+
| Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 |
| headers | | | (RPI1) | | (RH3, |
| | | | | | RPI2) |
+===========+---------+--------+---------------+---------+---------+
| Untouched | -- | -- | -- | -- | -- |
| headers | | | | | |
+===========+---------+--------+---------------+---------+---------+Table 29: Non-SM: Summary of the Use of Headers from RAL to RAL with Encapsulation to the Root
+===========+======+========+=============+=============+===========+
| Header | RAL | 6LR_ia | 6LBR | 6LR_id | RAL dst |
| | src | | | | |
+===========+======+========+=============+=============+===========+
| Added | RPI1 | -- | IP6-IP6 | -- | -- |
| headers | | | (RH3, RPI2) | | |
+===========+------+--------+-------------+-------------+-----------+
| Modified | -- | RPI1 | -- | IP6-IP6 | -- |
| headers | | | | (RH3, | |
| | | | | RPI2) | |
+===========+------+--------+-------------+-------------+-----------+
| Removed | -- | -- | -- | -- | IP6-IP6 |
| headers | | | | | (RH3, |
| | | | | | RPI2) |
+===========+------+--------+-------------+-------------+-----------+
| Untouched | -- | -- | RPI1 | RPI1 | RPI1 |
| headers | | | | | (Ignored) |
+===========+------+--------+-------------+-------------+-----------+Table 30: Non-SM: Summary of the Use of Headers from RAL to RAL without Encapsulation to the Root
8.3.2. Non-SM: Example of Flow from RAL to RUL 💅
okay so this one is RAL to RUL, and the flow goes:
RAL --> 6LR_ia --> root (6LBR) --> 6LR_id --> RUL (IPv6 dst node)
a communication flow could be: Node F (RAL) --> Node D --> Node B --> Node A (root) --> Node B --> Node E --> Node G (RUL) 🌸
6LR_ia stands for the intermediate routers from the source to the root, and 1 <= ia <= n, where n is the total number of intermediate routers (6LR) 🍓
6LR_id stands for the intermediate routers from the root to the destination, and 1 <= id <= m, where m is the total number of the intermediate routers (6LRs) 💜
Same as the last case, the RAL (6LN) may insert an RPI (RPI1) header, which must be in an IPv6-in-IPv6 header addressed to the root so the 6LBR can remove this RPI. Then the 6LBR inserts an RH3 inside a new IPv6-in-IPv6 header addressed to the last 6LR_id (6LR_id = m), along with inserting RPI2 ✨
If the originating node doesn't put the RPI (RPI1) into an IPv6-in-IPv6 header addressed to the root, then the RPI1 gets forwarded down from the root in the inner header to no avail 😭
Table 31 sums up which headers you need for this use case when encapsulation to the root takes place. Table 32 sums up which headers you need for this use case when no encapsulation to the root takes place 🎀
+===========+=========+========+=========+=========+=========+=====+
| Header | RAL src | 6LR_ia | 6LBR | 6LR_id | 6LR_m | RUL |
| | | | | | | dst |
+===========+=========+========+=========+=========+=========+=====+
| Added | IP6-IP6 | -- | IP6-IP6 | -- | -- | -- |
| headers | (RPI1) | | (RH3, | | | |
| | | | RPI2) | | | |
+===========+---------+--------+---------+---------+---------+-----+
| Modified | -- | RPI1 | -- | IP6-IP6 | -- | -- |
| headers | | | | (RH3, | | |
| | | | | RPI2) | | |
+===========+---------+--------+---------+---------+---------+-----+
| Removed | -- | -- | IP6-IP6 | -- | IP6-IP6 | -- |
| headers | | | (RPI1) | | (RH3, | |
| | | | | | RPI2) | |
+===========+---------+--------+---------+---------+---------+-----+
| Untouched | -- | -- | -- | -- | -- | -- |
| headers | | | | | | |
+===========+---------+--------+---------+---------+---------+-----+Table 31: Non-SM: Summary of the Use of Headers from RAL to RUL with Encapsulation to the Root
+===========+====+========+=========+=========+=========+===========+
| Header |RAL | 6LR_ia | 6LBR | 6LR_id | 6LR_n | RUL dst |
| |src | | | | | |
+===========+====+========+=========+=========+=========+===========+
| Added |RPI1| -- | IP6-IP6 | -- | -- | -- |
| headers | | | (RH3, | | | |
| | | | RPI2) | | | |
+===========+----+--------+---------+---------+---------+-----------+
| Modified | -- | RPI1 | -- | IP6-IP6 | -- | -- |
| headers | | | | (RH3, | | |
| | | | | RPI2) | | |
+===========+----+--------+---------+---------+---------+-----------+
| Removed | -- | -- | -- | -- | IP6-IP6 | -- |
| headers | | | | | (RH3, | |
| | | | | | RPI2) | |
+===========+----+--------+---------+---------+---------+-----------+
| Untouched | -- | -- | RPI1 | RPI1 | RPI1 | RPI1 |
| headers | | | | | | (ignored) |
+===========+----+--------+---------+---------+---------+-----------+Table 32: Non-SM: Summary of the Use of Headers from RAL to RUL without Encapsulation to the Root
8.3.3. Non-SM: Example of Flow from RUL to RAL
Okay so this is the flow where the source is a RUL and the destination is a RAL, and it's giving full detour through the root 🫶✨ No cap, the path goes:
RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id --> RAL dst (6LN)
bestie, here's a little example so it clicks 💖: Node G (RUL) --> Node E --> Node B --> Node A (root) --> Node B --> Node E --> Node H (RAL)
Now the letters. 6LR_ia is the intermediate routers from the source up to the root, where 1 <= ia <= n and n is the total number of intermediate routers (6LR) 🌸. 6LR_id is the intermediate routers from the root down to the destination, where 1 <= id <= m and m is the total number of intermediate routers (6LR) 🧚.
So here's the lowkey important bit 👑: the RPI (RPI1) gets added by the first 6LR (6LR_1) inside an IPv6-in-IPv6 header addressed to the root. Then the 6LBR removes that RPI and adds its own IPv6-in-IPv6 header containing an RH3 header and an RPI (RPI2) 🎀. Iconic layering, honestly 😭.
Table 33 is the cheat sheet for which headers get added, modified, removed, or left alone for this use case 💅:
+===========+=====+=========+========+=========+=========+=========+
| Header | RUL | 6LR_1 | 6LR_ia | 6LBR | 6LR_id | RAL dst |
| | src | | | | | |
+===========+=====+=========+========+=========+=========+=========+
| Added | -- | IP6-IP6 | -- | IP6-IP6 | -- | -- |
| headers | | (RPI1) | | (RH3, | | |
| | | | | RPI2) | | |
+===========+-----+---------+--------+---------+---------+---------+
| Modified | -- | -- | RPI1 | -- | IP6-IP6 | -- |
| headers | | | | | (RH3, | |
| | | | | | RPI2) | |
+===========+-----+---------+--------+---------+---------+---------+
| Removed | -- | -- | -- | IP6-IP6 | -- | IP6-IP6 |
| headers | | | | (RPI1) | | (RH3, |
| | | | | | | RPI2) |
+===========+-----+---------+--------+---------+---------+---------+
| Untouched | -- | -- | -- | -- | -- | -- |
| headers | | | | | | |
+===========+-----+---------+--------+---------+---------+---------+Table 33: Non-SM: Summary of the Use of Headers from RUL to RAL
8.3.4. Non-SM: Example of Flow from RUL to RUL
Next up is RUL to RUL, and ngl it's basically the combo of the last two cases 🦋. The path is:
RUL (IPv6 src node) --> 6LR_1 --> 6LR_ia --> root (6LBR) --> 6LR_id --> RUL (IPv6 dst node)
Example time 🍓: Node G --> Node E --> Node B --> Node A (root) --> Node C --> Node J
Same deal with the letters. 6LR_ia is the intermediate routers from the source to the root, with 1 <= ia <= n, where n is the total number of intermediate routers (6LR) 💜. 6LR_id is the intermediate routers from the root to the destination, with 1 <= id <= m, where m is the total number of intermediate routers (6LR) 🌈.
Table 34 has the header breakdown for this one 🫶:
+===========+===+=========+=======+=========+=========+=========+===+
| Header |RUL| 6LR_1 | 6LR_ia| 6LBR | 6LR_id | 6LR_m |RUL|
| |src| | | | | |dst|
+===========+===+=========+=======+=========+=========+=========+===+
| Added | --| IP6-IP6 | -- | IP6-IP6 | -- | -- | --|
| headers | | (RPI1) | | (RH3, | | | |
| | | | | RPI2) | | | |
+===========+---+---------+-------+---------+---------+---------+---+
| Modified | --| -- | RPI1 | -- | IP6-IP6 | -- | --|
| headers | | | | | (RH3, | | |
| | | | | | RPI2) | | |
+===========+---+---------+-------+---------+---------+---------+---+
| Removed | --| -- | -- | IP6-IP6 | -- | IP6-IP6 | --|
| headers | | | | (RPI1) | | (RH3, | |
| | | | | | | RPI2) | |
+===========+---+---------+-------+---------+---------+---------+---+
| Untouched | --| -- | -- | -- | -- | -- | --|
| headers | | | | | | | |
+===========+---+---------+-------+---------+---------+---------+---+Table 34: Non-SM: Summary of the Use of Headers from RUL to RUL
9. Operational Considerations of Supporting RULs 🌷
Okay, real talk, roughly half the situations in this document involve leaf ("host") nodes that do not speak RPL 😭. Those leaves split into two groups: ones that drop a packet that has RPI or RH3 headers, and ones that keep right on processing a packet that has RPI and/or RH3 headers 💀.
[RFC8200] brings in new rules suggesting that nodes which haven't been explicitly configured to examine Hop-by-Hop Options headers should ignore those headers and keep processing the packet ✨. Still, and even with the switch from 0x63 to 0x23, there may be nodes that predate RFC 8200 or are simply intolerant 🙈. Those nodes will drop packets that still have RPL artifacts in them. In general, such nodes cannot be easily supported in RPL LLNs 🥲.
There are some specific cases where it's possible to remove the RPL artifacts before forwarding the packet to the leaf host 🎀. The critical thing is that the artifacts were inserted by the RPL root inside an IPv6-in-IPv6 header, and that the header is addressed to the 6LR immediately prior to the leaf node. In that case, when the IPv6-in-IPv6 header is removed, the artifacts can be removed too 💅.
The above case happens whenever traffic originates from outside the LLN (the "Internet" cases above) and Non-Storing mode is used 🌍. In Non-Storing mode, the RPL root knows the exact topology (since it must create the RH3 header), so it knows which 6LR is prior to the leaf 🧚. For example, in Figure 3, Node E is the 6LR prior to leaf Node G, or Node C is the 6LR prior to leaf Node J 💜.
Traffic originating from the RPL root (like when the data collection system is co-located on the RPL root) does not require an IPv6-in-IPv6 header (in Storing or Non-Storing mode). The packet originates at the root, so the root can insert the RPI and RH3 headers directly into the packet as it's formed 🦋. That packet is slightly smaller, but it can only be sent to nodes (whether RPL aware or not) that will tolerate the RPL artifacts 🫧.
An operator that ends up with a high amount of traffic from the RPL root to RPL-unaware leaves will have to do IPv6-in-IPv6 encapsulation if the leaf isn't tolerant of the RPL artifacts 🌸. Otherwise, such an operator could omit this unnecessary header if it was certain of the properties of the leaf ✨.
As the Storing mode cannot know the final path of the traffic, intolerant leaf nodes (which drop packets with RPL artifacts) cannot be supported 😭🫶.
10. Operational Considerations of Introducing 0x23
This section describes the operational considerations of introducing the new RPI Option Type of 0x23 🌈.
During bootstrapping, the node receives the DIO with the information of RPI Option Type, indicating the new RPI in the DODAG Configuration option flag. The DODAG root is in charge of configuring the current network with the new value, through DIO messages, and determining when all the nodes have been set with the new value 👑. The DODAG should change to a new DODAG version. If a node reboots, it doesn't remember the RPI Option Type, so the DIO is sent with a flag indicating the new RPI Option Type 🔥.
The DODAG Configuration option is contained in a RPL DIO message, which carries a unique Destination Advertisement Trigger Sequence Number (DTSN) counter. The leaf nodes respond to this message with DAO messages containing the same DTSN. This is normal RPL routing, so the RPL root knows when the updated DODAG Configuration option has been seen by all nodes 🧚♀️.
Before the migration happens, all the RPL-aware nodes should support both values 🎀. The migration procedure is triggered when the DIO is sent with the flag indicating the new RPI Option Type. Basically, it stays at 0x63 until it's sure the network can handle 0x23, and then it abruptly changes to 0x23 💅. The 0x23 RPI Option allows sending packets to non-RPL nodes. Non-RPL nodes should ignore the option and keep processing the packets 🌷.
As mentioned previously, indicating the new RPI in the DODAG Configuration option flag is a way to avoid the flag day (abrupt changeover) in a network using 0x63 as the RPI Option Type value. It is suggested that RPL implementations accept both 0x63 and 0x23 RPI Option Type values when processing the header, to enable interoperability 🫶.
11. IANA Considerations 📋
11.1. Option Type in RPL Option
This document updates the registration made in the "Destination Options and Hop-by-Hop Options" subregistry [RFC6553] from 0x63 to 0x23, as shown in Table 35 💖.
+===========+===================+==============+===============+
| Hex Value | Binary Value | Description | Reference |
| +=====+=====+=======+ | |
| | act | chg | rest | | |
+===========+=====+=====+=======+==============+===============+
| 0x23 | 00 | 1 | 00011 | RPL Option | This document |
+-----------+-----+-----+-------+--------------+---------------+
| 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553], |
| | | | | (DEPRECATED) | this document |
+-----------+-----+-----+-------+--------------+---------------+
Table 35: Option Type in RPL OptionThe "DODAG Configuration Option Flags for MOP 0..6" subregistry is updated as follows (Table 36) 🌟:
+============+========================+===============+
| Bit Number | Capability Description | Reference |
+============+========================+===============+
| 3 | RPI 0x23 enable | This document |
+------------+------------------------+---------------+
Table 36: DODAG Configuration Option Flag to
Indicate the RPI Flag Day11.2. Change to the "DODAG Configuration Option Flags" Subregistry
IANA has changed the name of the "DODAG Configuration Option Flags" subregistry to "DODAG Configuration Option Flags for MOP 0..6" 🦋.
The subregistry references this document for this change.
11.3. Change MOP Value 7 to Reserved
IANA has changed the registration status of value 7 in the "Mode of Operation" subregistry from Unassigned to Reserved. This change is in support of future work 🧁.
This document is listed as a reference for this entry in the subregistry.
12. Security Considerations 🔐✨
okay bestie, security is where things get serious, so let's go 💅. first up, the security stuff from [RFC6553] and [RFC6554] still applies when your packets are inside the RPL Domain 🫶
the IPv6-in-IPv6 thing in this doc is way more limited than the general version in [RFC2473] 🎀 but here's the tea: every node in the LLN being willing to decapsulate and forward packets could get exploited by nodes that want to hide where an attack actually came from 😭
ngl a typical LLN is a pretty bad place to launch an attack from, since the networks are super slow and the nodes usually have really low duty cycles 🐢 BUT if you've got enough nodes, an LLN can still do real damage, especially if it's targeting another LLN 💀 and some RPL setups use big backbone, ISP-scale gear [ACP] with multiple 100 Gb/s interfaces, so it's giving "not a joke" energy 🔥
blocking or carefully filtering IPv6-in-IPv6 traffic coming into the LLN (like we said above) makes sure any attack has to start from compromised nodes inside the LLN 🛡️ and doing network ingress filtering [BCP38] on egress traffic at the RPL root will both alert the operator that something's up AND drop the attack traffic 🚨 the RPL network is usually numbered from one single prefix, which RPL assigns itself, so [BCP38] is just one prefix comparison and should be trivial to set up automatically ✨ easy win, periodt 💖
there are scenarios where IPv6-in-IPv6 traffic should get through the RPL root 🚪 like when a new pledge is talking to the Join Registrar/Coordinator (JRC) while using [BRSKI] and [ZEROTOUCH-JOIN] 🧚 the RPL root should do careful filtering here, and this only happens when the Join Coordinator is not sitting inside the RPL root 🌸
with all those precautions in place, an IPv6-in-IPv6 attack can only come from one node inside the LLN going after another node inside the LLN 👀 that attack could honestly just be done directly, no tunnel needed 🙄 it only makes sense if the source addresses are fake, or if the goal is to amplify return traffic 📈 it could also be done with forged source addresses and zero IPv6-in-IPv6 headers, and if the attack needs two-way communication then IPv6-in-IPv6 gives it no extra advantage 🤷♀️
whenever someone proposes IPv6-in-IPv6 headers, security worries pop up immediately 😬 [RFC2473] (Section 9) suggested securing the tunnel entry and exit points by securing the IPv6 path between them, but that's not practical for RPL networks 🙅♀️ [RFC5406] gives guidance on what additional details you'd need to "Use IPsec" 📚 ESP would stop source address forgeries, sure, but to use it with [RFC8138], compression has to happen before encryption, because the [RFC8138] compression is lossy 🗜️ once something's encrypted there's no redundancy left to compress 🔒 those are minor issues tho. the big one is establishing enough trust that Internet Key Exchange Protocol Version 2 (IKEv2) could even be used 🔑 that would need a certificate system on every single node, including any Internet nodes that might ever need to talk to the LLN, so using IPsec in the general case means you need a global PKI 🌍 mood: a lot 😩
it gets worse, bestie 📉 in the general case, IPsec tunnels protecting the IPv6-in-IPv6 headers would scale with the square of the number of nodes 💀 that's a LOT of resources for constrained nodes on a constrained network 🪫 and honestly the IPsec tunnels would only be giving you BCP38-like origin authentication 🙃 like, IPsec gives the tunnel exit a transitive guarantee that the tunnel entry did network ingress filtering [BCP38] on the traffic going in 🎀 just doing origin filtering per BCP 38 at the entry and exit of the LLN gets you a similar level of security without all the scaling and trust headaches of IPv6 tunnels, as discussed in [RFC2473] ✨ so yeah, IPsec is not recommended. 🚫
an LLN that has hostile nodes inside it still won't be protected against impersonation within the LLN by entry/exit filtering 😤
the RH3 header usage described here can be abused in similar ways 🕵️♀️ an external attacker could build a packet with an RH3 that isn't fully consumed, then encapsulate it to hide that RH3 from intermediate nodes and disguise where the traffic came from 🎭 so the attacker's RH3 won't be seen by the network until it reaches the destination, which is the node that decapsulates it 👀 as Section 4.2 of [RFC6554] says, RPL routers are responsible for making sure an SRH is only used between RPL routers 🧱 so if there's an RH3 that isn't fully consumed in the encapsulated packet, the node that decapsulates it MUST make sure the outer packet originated in the RPL domain, and drop the packet if it didn't 🚫
also, as Section 2 of [RFC6554] puts it, RPL Border Routers "do not allow datagrams carrying an SRH header to enter or exit a RPL routing domain." 📖 this sentence has to be read as being about packets that are not fully consumed 🤓 a consumed (inert) RH3 header could totally be sitting in a packet that flows from one LLN, crosses the Internet, and enters another LLN 🌐 per the discussion in this document, those headers don't need to be removed 🫧 there's no case described here where an RH3 gets inserted in a Non-Storing network on traffic leaving the LLN, but this document shouldn't rule out that kind of future innovation 🔮
Quick recap, periodt: a packet that crosses the border of the RPL domain MAY carry an RH3, and if it does, that RH3 MUST be fully consumed. 🎀
now the RPI 🧚 if it's allowed to enter the LLN, an attacker could use it to change the priority of a packet by picking a different RPLInstanceID, maybe one with a higher energy cost, for example ⚡ it could also be that not every node is reachable using the default RPLInstanceID, and a change of RPLInstanceID would let an attacker get around that filtering 🚧 just like the RH3, an RPI is supposed to be inserted by the RPL root on traffic entering the LLN, and that happens by first inserting an IPv6-in-IPv6 header 📦 so the attacker's RPI won't be seen by the network 🫥 once the packet reaches the destination node, the RPI has no further meaning and just gets skipped, and a second RPI doesn't mean anything to the end node either, since the packet's already been identified as being at its final destination 🏁
for traffic leaving a RUL, if the RUL adds an uninitialized RPI (say, with a value of zero), then the 6LR as an RPL Border Router SHOULD rewrite the RPI to show the selected Instance and set the flags 🛠️ this is done to avoid two situations 🙈 first, the leaf is an external router that passes along a packet it didn't generate, carrying an unrelated RPI 📮 second, the leaf is an attacker or is misconfigured and tries to inject traffic into a protected Instance 🚨 this also applies when the leaf knows about the RPL Instance and passes along a correct RPI; in that case the 6LR needs a configuration that lets that leaf inject into that instance 🔐
the RH3 and RPIs could also be abused by an attacker inside the network to route packets in sneaky ways that might dodge observation 🥷 this usage looks consistent with normal operation of [RFC6997], so it can't be restricted at all 🙌 this is a feature, not a bug, bestie 💜
[RFC7416] covers a bunch of other threats to LLNs that aren't directly tied to IPv6-in-IPv6 headers, and this document doesn't change that analysis 📋
nodes inside the LLN can use the IPv6-in-IPv6 mechanism to attack another part of the LLN while disguising where the attack came from 🎭 it can even be abused to make an attack look like it's coming from outside the LLN, and unless someone counters it, this could be used to launch a DDoS attack on nodes elsewhere on the Internet 😱 see [DDOS-KREBS] for real-world examples of this already happening 📰
if an attack comes from inside the LLN, it can be eased with SAVI (Source Address Validation Improvement) using [RFC8505] together with [RFC8928] 🛡️ the attacker won't be able to send traffic with an address that isn't registered, and the registration process checks for topological correctness 🗺️ also, there's Layer 2 authentication in most cases, so that's a bonus 🫶 if an attack comes from outside the LLN, IPv6-in-IPv6 can be used to hide inner routing headers, but by design the RH3 can typically only address nodes inside the LLN 🏠 so an RH3 with a CmprI less than 8 should be considered an attack (see Section 3 of [RFC6554]) 🚩
nodes outside the LLN would need to push IPv6-in-IPv6 traffic through the RPL root to pull off this attack 🚪 to counter it, the RPL root SHOULD either restrict ingress of IPv6-in-IPv6 packets (the simpler solution), or it SHOULD walk the IP header extension chain until it can inspect the upper-layer payload, as described in [RFC7045] 🧐 in particular, the RPL root SHOULD do network ingress filtering [BCP38] on the source addresses of all IP headers it examines, in both directions 🔁
Note, bestie: there are some situations where a prefix spreads across multiple LLNs through mechanisms like the one described in [RFC8929] 🌿 in that case, network ingress filtering [BCP38] has to take this into account, either by exchanging detailed routing information on each LLN, or by moving the network ingress filtering [BCP38] further towards the Internet, so the details of the multiple LLNs don't matter 🌈
13. References 📚
13.1. Normative References
Okay bestie, these are the must-read docs 💅 Everything here is required reading, no cap. Each one is listed with its full details so you can track it down.
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
<https://rfc-editor.org/info/bcp38>
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion
Notification", RFC 6040, DOI 10.17487/RFC6040, November
2010, <https://www.rfc-editor.org/info/rfc6040>.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc6550>.
[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,
<https://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,
<https://www.rfc-editor.org/info/rfc6554>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013,
<https://www.rfc-editor.org/info/rfc7045>.
[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,
<https://www.rfc-editor.org/info/rfc8025>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.13.2. Informative References
These ones are the extra reading 🦋 Super useful for context, but you don't strictly need them to get the main spec.
[ACP] Eckert, T., Behringer, M. H., and S. Bjarnason, "An
Autonomic Control Plane (ACP)", Work in Progress,
Internet-Draft, draft-ietf-anima-autonomic-control-plane-
30, 30 October 2020, <https://tools.ietf.org/html/draft-
ietf-anima-autonomic-control-plane-30>.
[BRSKI] Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M.
H., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", Work in Progress, Internet-
Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11
November 2020, <https://tools.ietf.org/html/draft-ietf-
anima-bootstrapping-keyinfra-45>.
[DDOS-KREBS]
Goodin, D., "Record-breaking DDoS reportedly delivered by
>145k hacked cameras", September 2016,
<https://arstechnica.com/information-technology/2016/09/
botnet-of-145k-cameras-reportedly-deliver-internets-
biggest-ddos-ever/>.
[RFC0801] Postel, J., "NCP/TCP transition plan", RFC 801,
DOI 10.17487/RFC0801, November 1981,
<https://www.rfc-editor.org/info/rfc801>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006,
<https://www.rfc-editor.org/info/rfc4443>.
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec
Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406,
February 2009, <https://www.rfc-editor.org/info/rfc5406>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<https://www.rfc-editor.org/info/rfc6437>.
[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,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013,
<https://www.rfc-editor.org/info/rfc6997>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>.
[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
May 2017, <https://www.rfc-editor.org/info/rfc8180>.
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.
[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
"Address-Protected Neighbor Discovery for Low-Power and
Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
2020, <https://www.rfc-editor.org/info/rfc8928>.
[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
"IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
November 2020, <https://www.rfc-editor.org/info/rfc8929>.
[RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL
(Routing Protocol for Low-Power and Lossy Networks)
Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/rfc/rfc9010>.
[TUNNELS] Touch, J. and M. Townsley, "IP Tunnels in the Internet
Architecture", Work in Progress, Internet-Draft, draft-
ietf-intarea-tunnels-10, 12 September 2019,
<https://tools.ietf.org/html/draft-ietf-intarea-tunnels-
10>.
[ZEROTOUCH-JOIN]
Richardson, M., "6tisch Zero-Touch Secure Join protocol",
Work in Progress, Internet-Draft, draft-ietf-6tisch-
dtsecurity-zerotouch-join-04, 8 July 2019,
<https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-
zerotouch-join-04>.Acknowledgments 🫶
This work happened thanks to the grant from the StandICT.eu project, so a big thank you to them 🌸
A special BIG thanks to C. M. Heard for helping with Section 4. A lot of the editing in that section is based on his comments, and that's so iconic of him 👑
The authors also want to shout out everyone who reviewed, gave feedback, and commented (listed alphabetically): Dominique Barthel, Robert Cragie, Ralph Droms, Simon Duquennoy, Cenk Guendogan, Rahul Jadhav, Benjamin Kaduk, Matthias Kovatsch, Gustavo Mercado, Subramanian Moonesamy, Marcela Orbiscay, Cristian Perez, Charlie Perkins, Alvaro Retana, Peter van der Stok, Xavier Vilajosana, Éric Vyncke, and Thomas Watteyne. Y'all are the real MVPs 💖
Authors' Addresses 🦋
Maria Ines Robles
Universidad Tecno. Nac.(UTN)-FRM, Argentina /Aalto University Finland
Coronel Rodríguez 273
M5500 Mendoza
Provincia de Mendoza
Argentina
Email: mariainesrobles@gmail.com
Michael C. Richardson
Sandelman Software Works
470 Dawson Avenue
Ottawa ON K1Z 5V7
Canada
Email: mcr+ietf@sandelman.ca
URI: http://www.sandelman.ca/mcr/
Pascal Thubert
Cisco Systems, Inc
Building D
45 Allee des Ormes - BP1200
06254 MOUGINS - Sophia Antipolis
France
Phone: +33 497 23 26 34
Email: pthubert@cisco.com📦 where this page comes from
- ietf: rfc9008 2021-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms