RFC 9010
Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves
RFC 9010: Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves 🦋
- Series: Internet Engineering Task Force (IETF), Request for Comments: 9010
- Authors: P. Thubert, Ed. (Cisco Systems) and M. Richardson (Sandelman) 👩💻
- Category: Standards Track 🎀
- Date: April 2021 📅
- ISSN: 2070-1721
- Updates: RFCs 6550, 6775, and 8505 🔥
- Obsoletes: not listed in the title block
Abstract ✨
okay bestie, so this spec gives a host a way to get reachability across a network that uses RFC 6550 for its routing. The host runs a routing-agnostic interface built on IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery 💖 It also updates RFCs 6550, 6775, and 8505 🫶
Status of This Memo 📜
This is an Internet Standards Track document 🌸
This document is a product of the Internet Engineering Task Force (IETF). 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). You can find more about Internet Standards in Section 2 of RFC 7841 ✨
Info about the current status of this document, any errata, and how to send feedback on it lives at https://www.rfc-editor.org/info/rfc9010 💅
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 in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. 🫶
Table of Contents 🗺️
1. Introduction
2. Terminology
2.1. Requirements Language
2.2. Glossary
2.3. Related Documents
3. RPL External Routes and Data-Plane Artifacts
4. 6LoWPAN Neighbor Discovery
4.1. Address Registration per RFC 6775
4.2. Extended Address Registration per RFC 8505
4.2.1. R Flag
4.2.2. TID, "I" Field, and Opaque Field
4.2.3. Route Ownership Verifier
4.3. EDAR/EDAC per RFC 8505
4.3.1. Capability Indication Option per RFC 7400
5. Requirements for the RPL-Unaware Leaf
5.1. Support of 6LoWPAN ND
5.2. Support of IPv6 Encapsulation
5.3. Support of the Hop-by-Hop Header
5.4. Support of the Routing Header
6. Enhancements to RFC 6550
6.1. Updated RPL Target Option
6.2. Additional Flag in the RPL DODAG Configuration Option
6.3. Updated RPL Status
7. Enhancements to RFC 9009
8. Enhancements to RFCs 6775 and 8505
9. Protocol Operations for Unicast Addresses
9.1. General Flow
9.2. Detailed Operation
9.2.1. Perspective of the 6LN Acting as a RUL
9.2.2. Perspective of the 6LR Acting as a Border Router
9.2.3. Perspective of the RPL DODAG Root
9.2.4. Perspective of the 6LBR
10. Protocol Operations for Multicast Addresses
11. Security Considerations
12. IANA Considerations
12.1. Fixing the Address Registration Option Flags
12.2. Resizing the ARO Status Values
12.3. New RPL DODAG Configuration Option Flag
12.4. RPL Target Option Flags Registry
12.5. New Subregistry for RPL Non-Rejection Status Values
12.6. New Subregistry for RPL Rejection Status Values
13. References
13.1. Normative References
13.2. Informative References
Appendix A. Example Compression
Acknowledgments
Authors' Addresses1. Introduction ✨
so the whole design of Low-Power and Lossy Networks (LLNs) is basically about saving energy, because energy is the most constrained resource of all 🔋 Other constraints, like limited memory, duty cycling of LLN devices, and low-power lossy transmissions, all come from that main concern 💀
The IETF made RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks [RFC6550] to give routing services for IPv6 [RFC8200] inside those constraints 🌈 RPL is a distance-vector protocol. Compared to link-state protocols, it limits how much topological knowledge each node has to install and maintain, and it does not need convergence to avoid micro-loops 🧚
RPL allows a path stretch (see [RFC6687]) to save signaling and routing state in constrained networks 🍓 That means routing only happens along a Destination-Oriented Directed Acyclic Graph (DODAG) that's optimized to reach a root node, instead of along the shortest path between two peers, whatever that would even mean in a given LLN 🤷♀️ It trades the quality of peer-to-peer (P2P) paths for a way smaller amount of control traffic and routing state, which an any-to-any shortest-path protocol would need. Broken routes can also get fixed lazily and on demand, based on data-plane inconsistency discovery, so no energy is wasted proactively repairing paths nobody uses ⚡
For many nodes (though not all), the DODAG gives multiple forwarding options toward the root through so-called parents 👑 RPL installs routes proactively, but to handle fuzzy connectivity, where the physical topology can't be expected to settle down, it uses a lazy route maintenance operation that may only fix routes reactively, once actual traffic shows up 🙈 The result is that RPL provides reachability for most LLN nodes, most of the time, but it may not converge in the classical sense 💅
RPL can be deployed together with IPv6 Neighbor Discovery (ND) [RFC4861] [RFC4862] and IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) ND [RFC6775] [RFC8505] to keep reachability going inside a Non-Broadcast Multi-Access (NBMA) multi-link subnet 🦋
In that mode, IPv6 addresses get advertised individually as host routes 🌸 Some nodes act as routers and take part in forwarding, while others only receive or originate packets, acting as hosts in the data plane. Per the terminology of [RFC6550], an IPv6 host [RFC8504] that is reachable over the RPL network is called a "leaf" 🎀
Section 2 of [RFC9008] defines the terms "RPL leaf", "RPL-Aware Leaf" (RAL), and "RPL-Unaware Leaf" (RUL) 📚 A RPL leaf is a host attached to one or more RPL routers. It relies on those routers to forward its traffic across the RPL domain, but it doesn't forward traffic for other nodes. Unlike the RAL, the RUL doesn't participate in RPL. Instead it relies on its RPL router(s) to also inject the routes to its IPv6 addresses into the RPL domain 🫶
A RUL might be unable to participate because it's super energy constrained or code-space constrained, or because letting it inject routes into RPL would be unsafe 😭 Using 6LoWPAN ND instead of RPL as the host-to-router interface limits the surface of possible attacks by the RUL against the RPL domain 🔒 If all RULs and RPL-Aware Nodes (RANs) use 6LoWPAN ND for the neighbor discovery process, it's also possible to protect the address ownership of all nodes, including the RULs 👑
This document specifies how the router injects host routes into the RPL domain on behalf of the RUL 💖 Section 5 details how the RUL can use 6LoWPAN ND to get routing services from the router. In that model, the RUL is also a 6LoWPAN Node (6LN) and the RPL-aware router is also a 6LoWPAN Router (6LR). Using the 6LoWPAN ND Address Registration mechanism, the RUL signals that the router must inject a host route for the Registered Address ✨
------+---------
| Internet
|
+-----+
| | <------------- 6LBR / RPL DODAG Root
+-----+ ^
| |
o o o o | RPL
o o o o o o o o |
o o o o o o o o o o | +
o o o o o o o |
o o o o o o o o o | 6LoWPAN ND
o o o o o o |
o o o o v
o o o <------------- 6LR / RPL Border Router
^
| 6LoWPAN ND only
v
u <------------- 6LN / RPL-Unaware Leaf
Figure 1: Injecting Routes on Behalf of RULsThe RPL Non-Storing mode mechanism is used to extend the routing state with connectivity to the RULs, even when the DODAG is operated in Storing mode 🧩 The unicast packet-forwarding operation by the 6LR that serves a RUL is described in Section 4.1.1 of [RFC9008] 💫
Examples of possible RULs include severely energy-constrained sensors such as window smash sensors (alarm system) and kinetically powered light switches ⚡ Another application of this specification could be a smart grid network that controls appliances, like washing machines or the heating system, in the home 🏠 Appliances may not take part in the RPL protocol running in the smart grid network, but they can still interact with the smart grid for control and/or metering 🫧
This specification can be deployed incrementally in a network that implements [RFC9008] 🌱 Only the root and the 6LRs that connect the RULs need to be upgraded. The RPL routers on the path will only ever see unicast IPv6 traffic between the root and the 6LR 🦋
This document is organized as follows:
- Sections 3 and 4 present, in a non-normative fashion, the salient aspects of RPL and 6LoWPAN ND, respectively, that are leveraged in this specification to provide connectivity to a 6LN acting as a RUL across a RPL network. 🌸
- Section 5 lists the requirements that a RUL needs to match in order to be served by a RPL router that complies with this specification. 🎀
- Section 6 presents the changes made to [RFC6550]. A new behavior is introduced whereby the 6LR advertises the 6LN's addresses in a RPL Destination Advertisement Object (DAO) message based on the ND registration by the 6LN, and the RPL DODAG root performs the Extended Duplicate Address Request / Extended Duplicate Address Confirmation (EDAR/EDAC) exchange with the 6LoWPAN Border Router (6LBR) on behalf of the 6LR. Modifications are also introduced to some RPL options and to the RPL Status to make the protocols fit together. 🧚
- Section 7 presents the changes made to [RFC9009]. The use of the Destination Cleanup Object (DCO) message is extended to the Non-Storing RPL Mode of Operation (MOP) to report asynchronous issues from the root to the 6LR. 🔥
- Section 8 presents the changes made to [RFC6775] and [RFC8505]. The range of the Address Registration Option / Extended Address Registration Option (ARO/EARO) Status values is reduced to 64 values, and the remaining bits in the original status field are now reserved. 🌈
- Sections 9 and 10 present the operation of this specification for unicast and multicast flows, respectively, and Section 11 presents the associated security considerations. 🔐
2. Terminology 💖
2.1. Requirements Language
Okay bestie, so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are the ones that really matter in this doc 💅. They get read the BCP 14 way [RFC2119] [RFC8174], but only when they show up in all capitals, exactly like that 🔥. Lowercase versions are just regular words, so no stress 🌸.
2.2. Glossary
Here's the abbreviation list the doc uses, so you can keep up with all the acronyms 🧚. Anything that isn't here gets covered in section 2.3 💖.
6BBR: 6LoWPAN Backbone Router
6CIO: 6LoWPAN Capability Indication Option
6LBR: 6LoWPAN Border Router
6LN: 6LoWPAN Node (a low-power host or router)
6LoRH: 6LoWPAN Routing Header
6LoWPAN: IPv6 over Low-Power Wireless Personal Area Network
6LR: 6LoWPAN Router
AP-ND: Address-Protected Neighbor Discovery
ARO: Address Registration Option
DAC: Duplicate Address Confirmation
DAD: Duplicate Address Detection
DAO: Destination Advertisement Object (a RPL message)
DAR: Duplicate Address Request
DCO: Destination Cleanup Object (a RPL message)
DIO: DODAG Information Object (a RPL message)
DODAG: Destination-Oriented Directed Acyclic Graph
EARO: Extended Address Registration Option
EDAC: Extended Duplicate Address Confirmation
EDAR: Extended Duplicate Address Request
EUI: Extended Unique Identifier
LLN: Low-Power and Lossy Network
MLD: Multicast Listener Discovery
MOP: RPL Mode of Operation
NA: Neighbor Advertisement
NBMA: Non-Broadcast Multi-Access
NCE: Neighbor Cache Entry
ND: Neighbor Discovery
NS: Neighbor Solicitation
PIO: Prefix Information Option
RA: Router Advertisement
RAL: RPL-Aware Leaf
RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)
RH3: Routing Header for IPv6 (type 3)
ROVR: Registration Ownership Verifier
RPI: RPL Packet Information
RPL: Routing Protocol for Low-Power and Lossy Networks
RUL: RPL-Unaware Leaf
SAVI: Source Address Validation Improvement
SLAAC: Stateless Address Autoconfiguration
SRH: Source Routing Header
TID: Transaction ID (a sequence counter in the EARO)
TIO: Transit Information Option2.3. Related Documents
Terminology check ✨: the terms in this doc match, and build on, the ones in "Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102]. The classical 6LoWPAN abbreviations are in the glossary up in section 2.2 🦋. Other LLN terms live in "Terminology for Constrained-Node Networks" [RFC7228]. This spec uses "6LN" and "6LR" to mean the nodes that play the 6LN and 6LR roles in 6LoWPAN ND, and it doesn't expect those nodes to do other stuff like 6LoWPAN Header Compression [RFC6282] 🌈.
"RPL", "RPI", "RPL Instance" (indexed by a RPLInstanceID), "up", and "down" are all defined in "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550] 💜. The RPI is the abstract info that RPL says goes in data packets, for example as the RPL Option [RFC6553] inside the IPv6 Hop-By-Hop Header 🎀. People also use "RPI" to mean the RPL Option itself, which is super common 🙈. The DAO and DIO messages are also in [RFC6550], and the DCO message is defined in [RFC9009] ✨.
This doc uses "RUL", "RAN", and "RAL" the same way [RFC9008] does 🫶. A RAN is either a RAL or a RPL router. Unlike a RUL, a RAN handles the reachability of its own addresses and prefixes by injecting them into RPL itself 💅.
Here are the other docs you'll run into while reading this one 📚:
- Classical IPv6 ND: "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] and "IPv6 Stateless Address Autoconfiguration" [RFC4862].
- 6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606] and "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919], and
- 6LoWPAN ND: "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775], "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC8505], "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" [RFC8928], and "IPv6 Backbone Router" [RFC8929].
3. RPL External Routes and Data-Plane Artifacts ✨
Okay so RPL was originally made for stub networks 🌸, where the only border router is the RPL DODAG root (usually sitting with the 6LBR) and every node in the stub is RPL aware. But [RFC6550] was also built to be extended for external routes ("targets" in RPL speak) using the External ('E') flag in the Transit Information Option (TIO) 🦋. External targets let you reach destinations outside the RPL domain, which connect to the RPL domain through RPL border routers that aren't the root 🧚. Section 4.1 of [RFC9008] has a set of rules (summarized below) that you must follow when routing packets to and from an external destination 💅. A RUL is a special kind of external target that's also a host directly connected to the RPL domain 💖.
A 6LR acting as a border router for external routes advertises them using Non-Storing mode DAO messages, which get unicast straight to the root, even if the DODAG runs in Storing mode 🔥. Non-Storing mode routes aren't visible inside the RPL domain, so every packet gets routed through the root 🌈. The RPL DODAG root tunnels the data packets directly to the 6LR that advertised the external route, and that 6LR decapsulates and forwards the original (inner) packets 🎀.
The RPL Non-Storing MOP signaling and the IPv6-in-IPv6 encapsulated packets look like normal traffic to the intermediate routers 🫶. Support for external routes only affects the root and the 6LR. It can work with legacy intermediate routers, and it doesn't add to the state those routers have to keep 💜. A RUL is one example of a destination reachable through an external route that also happens to be a host route ✨.
RPL data packets usually carry a Hop-by-Hop Header with a RPL Option [RFC6553], which holds the RPI (the RPL Packet Information, as defined in Section 11.2 of [RFC6550]) 🍓. Unless the RUL already put a RPL Option in the outer header chain, packets to and from the RUL get wrapped in an IPv6-in-IPv6 tunnel between the root and the 6LR that serves the RUL (see Sections 7 and 8 of [RFC9008] for details) 🦋. If the packet from the RUL has an RPI, the 6LR acting as a RPL border router rewrites the RPI to show the selected RPL Instance and set the flags, but it doesn't need to encapsulate the packet (see Section 9.2.2) 💅.
In Non-Storing mode, packets going down the DODAG carry a Source Routing Header (SRH) 🌸. The IPv6-in-IPv6 encapsulation, the RPI, and the SRH together are called the "RPL artifacts" 👑, and they can be compressed using the method defined in [RFC8138] 🧚. Appendix A shows an example compressed format for a packet the root forwards to a RUL in a Storing mode DODAG 🎀.
The inner packet forwarded to the RUL might carry some RPL artifacts, like an RPI if the original packet was generated with one, and an SRH in a Non-Storing mode DODAG 🙈. [RFC9008] expects the RUL to support the basic IPv6 node requirements per [RFC8504] and, in particular, the mandates in Sections 4.2 and 4.4 of [RFC8200] 🫶. So the RUL is expected to ignore leftover RPL artifacts, either an SRH whose Segments Left is zero or a RPL Option in the Hop-by-Hop Header (which can be skipped when it isn't recognized; see Section 5.3 for details) 💜.
A RUL isn't expected to support the compression method in [RFC8138] 🌈. That's why the border router (the 6LR here) uncompresses the packet before forwarding it over an external route to a RUL [RFC9008] ✨.
4. 6LoWPAN Neighbor Discovery 🎀
This section goes through the 6LoWPAN ND mechanisms this spec builds on 🦋. It's a non-normative reference for you, bestie 💖. The full normative text is in [RFC6775], [RFC8505], and [RFC8928] 🧚.
4.1. Address Registration per RFC 6775
The classical IPv6 Neighbor Discovery (IPv6 ND) protocol [RFC4861] [RFC4862] was defined for serial links and transit media like Ethernet 🌸. It's a reactive protocol that leans heavily on multicast for Address Discovery (aka address lookup) and Duplicate Address Detection (DAD) 📡.
"Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775] adapts IPv6 ND so it works over energy-constrained LLNs 🔋. Its main jobs are to proactively set up the Neighbor Cache Entry (NCE) in the 6LR and to prevent address duplication 🛡️. To do that, [RFC6775] adds a unicast Address Registration mechanism, which cuts down on multicast messages compared to classical IPv6 ND 🦋.
[RFC6775] also introduces the Address Registration Option (ARO), which rides along in the unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the 6LoWPAN router (6LR) 💜. It also defines the Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC) messages between the 6LR and the 6LBR). In an LLN, the 6LBR is the central repository for all the Registered Addresses in its domain and the source of truth for uniqueness and ownership 👑.
4.2. Extended Address Registration per RFC 8505
"Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC8505] updates RFC 6775 with a generic Address Registration mechanism that can be used to access services like routing and ND proxy functions ✨. To do that, [RFC8505] defines the Extended Address Registration Option (EARO), shown in Figure 2 🌈:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EARO Format4.2.1. R Flag ✨
[RFC8505] introduces the R flag in the EARO. 💅 The Registering Node sets the R flag to tell the 6LR whether it should make sure the Registered Address is reachable. If the R flag is set to 0, the Registering Node handles reachability for the Registered Address by other means. In an RPL network, that means either it's a RAN that injects the route by itself, or it uses another RPL router for reachability services. 🌸
This document explains how the R flag gets used with RPL. 🦋 A RPL leaf that implements the 6LN functionality from [RFC8505] needs reachability services for an IPv6 address if and only if it sets the R flag to 1 in the NS(EARO) it uses to register the address with a 6LR that acts as a RPL border router. Once the RPL router gets that NS(EARO), it generates a DAO message for the Registered Address if and only if the R flag is 1. 👑
Section 9.2 covers the extra operations that happen when the R flag is set to 1 in an EARO, whether that EARO sits in an NS message or an NA message. ✨
4.2.2. TID, "I" Field, and Opaque Field 🦋
When the T flag is set to 1, the EARO has a sequence counter called the "Transaction ID" (TID). 🎀 The TID is needed to fill in the Path Sequence field in the RPL Transit Information Option (TIO). So supporting [RFC8505] on the RUL (not just [RFC6775]) is a prerequisite for this specification. Honestly, that's a huge deal, and Section 5.1 explains all of it. 💖
The EARO also carries an Opaque field, plus an associated "I" field that says what the Opaque field carries and how to use it. 🧚
Section 9.2.1 spells out how a RUL uses the "I" field and the Opaque field. 🍓
4.2.3. Route Ownership Verifier 👑
Section 5.3 of [RFC8505] brings in the Registration Ownership Verifier (ROVR) field, which can be anywhere from 64 to 256 bits long. 🌈 The ROVR takes the place of the 64-bit Extended Unique Identifier (EUI-64) in the ARO [RFC6775]. The EUI-64 was used to uniquely identify an Address Registration with the link-layer address of its owner, but it gave zero protection against spoofing. 🙈
"Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" [RFC8928] uses the ROVR field as a cryptographic proof of ownership. That stops a rogue third party from registering an address that someone already owns. 🔥 Thanks to the ROVR, the 6LR can block traffic that isn't sourced at an owned address. ✨
Plot twist: this specification doesn't cover how the protection from [RFC8928] could be extended for use in RPL. 💀 What it does do is add the ROVR to the DAO, so the root can build the proxied EDAR (see Section 6.1). That means nodes that know about the host route also know the ROVR associated with the Target Address. 🫶
4.3. EDAR/EDAC per RFC 8505 🌷
[RFC8505] updates the DAR/DAC messages into EDAR/EDAC messages so they can carry the ROVR field. 💜 The EDAR/EDAC exchange happens between the 6LR and the 6LBR. An NS(EARO) from a 6LN triggers it, and it's used to create, refresh, and delete the matching state in the 6LBR. 🦋
The exchange is protected by the retry mechanism in Section 8.2.6 of [RFC6775]. In an LLN, though, the default RetransTimer (RETRANS_TIMER) [RFC4861] of 1 second may not be enough, so a longer duration might be needed to cover the round-trip delay between the 6LR and the 6LBR. ⏳
Here's the vibe: RPL [RFC6550] sends a periodic DAO from the 6LN all the way up to the root. That keeps the routing state alive in the RPL network for the lifetime the DAO's source says. 🌊 So for each address, there are two keep-alive messages crossing the whole network: one going to the root and one going to the 6LBR. Lowkey a lot of traffic! 😭
This specification skips the periodic EDAR/EDAC exchange across the LLN. ✨ The 6LR turns the periodic NS(EARO) from the RUL into a DAO message to the root on every refresh. It only generates the EDAR on the first registration, for DAD, and the address has to pass DAD before it gets injected into RPL. 🧚 Then the root takes over: when a DAO arrives, the root proxies the EDAR exchange to refresh the state at the 6LBR on behalf of the 6LR. Figure 8 in Section 9.1 shows the whole thing. 🎀
4.3.1. Capability Indication Option per RFC 7400 🍓
"6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC7400] defines the 6LoWPAN Capability Indication Option (6CIO). The 6CIO lets a node show off its capabilities in Router Advertisement (RA) messages. 💅
[RFC8505] defines a bunch of bits in the 6CIO. The important ones are:
L:The node is a 6LR.E:The node is an IPv6 ND Registrar, meaning it supports registrations based on EARO.P:The node is a Routing Registrar, meaning it's an IPv6 ND Registrar that also provides reachability services for the Registered Address.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 1 | Reserved |D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: 6CIO Flags 🌈
A 6LR that provides reachability services for a RUL in an RPL network, as this document describes, includes a 6CIO in its RA messages. It sets the L, P, and E flags to 1, as [RFC8505] prescribes. Section 9.2 explains all of this. 🫶
5. Requirements for the RPL-Unaware Leaf 🦋
This document describes how RPL routing can be extended to reach a RUL. ✨ This section lays out the minimal RPL-independent functionality that the RUL needs to implement in order to get routing services for its addresses. 💖
5.1. Support of 6LoWPAN ND 🎀
To get routing services from a router that implements this specification, a RUL needs to implement [RFC8505] and set the "R" and "T" flags in the EARO to 1, as discussed in Sections 4.2.1 and 4.2.2 respectively. 👑 Section 9.2.1 defines new behaviors for the RUL. For example, if the R flag is set to 1 in an NS(EARO) and isn't echoed in the NA(EARO), that means route injection failed. 💀
The RUL is expected to request routing services from a router only if that router originates RA messages with a 6CIO that has the L, P, and E flags all set to 1, as discussed in Section 4.3.1, unless it's configured to do so. 🧚 It's suggested that the RUL also implement [RFC8928] to protect the ownership of its addresses. 🔥
A RUL that may attach to multiple 6LRs is expected to prefer the ones that provide routing services. 🌸 The RUL needs to register with every 6LR it wants routing services from. 🍓
Parallel Address Registrations to several 6LRs should be done in a rapid sequence, using the same EARO for the same address. Gaps between the Address Registrations will invalidate some of the routes until the Address Registration finally shows up on those routes. 😭
[RFC8505] introduces error Status values in the NA(EARO). These can arrive synchronously in response to an NS(EARO), or asynchronously. The RUL needs to support both cases, and it should refrain from using the address when the Status value indicates a rejection (see Section 6.3). 🙈
5.2. Support of IPv6 Encapsulation 🌊
Section 4.1.1 of [RFC9008] defines the rules for signaling an external destination (e.g., a RUL) and tunneling to its attachment router (designated as a 6LR). 🫧 To terminate the IPv6-in-IPv6 tunnel, the RUL, as an IPv6 host, would have to be able to decapsulate the tunneled packet. It would then either drop the encapsulated packet if it isn't the final destination, or pass it up to the upper layer for further processing. 🎀
As Section 4.1 of [RFC9008] indicates, [RFC8504] doesn't mandate this. The IPv6-in-IPv6 tunnel from the root is terminated at the parent 6LR instead. 💅 So a RUL doesn't need to support IPv6-in-IPv6 decapsulation. Yay, less work! 🥳
5.3. Support of the Hop-by-Hop Header 🧚
A RUL is expected to process an Option Type in a Hop-by-Hop Header as Section 4.2 of [RFC8200] prescribes. 🦋 An RPI with an Option Type of 0x23 [RFC9008] is therefore skipped when it isn't recognized. ✨
5.4. Support of the Routing Header 🌸
A RUL is expected to process an unknown Routing Header Type as Section 4.4 of [RFC8200] prescribes. 💖 This means the SRH, which has a Routing Type of 3 [RFC6554], gets ignored when Segments Left is zero. When Segments Left is non-zero, the RUL discards the packet and sends an ICMP Parameter Problem message with Code 0 to the packet's source address, pointing at the unrecognized Routing Type. 🙈
6. Enhancements to RFC 6550 👑
This document defines a new behavior where a 6LR injects DAO messages for unicast addresses (see Section 9) and multicast addresses (see Section 10) on behalf of leaves that aren't aware of RPL. 🌈 The RUL addresses are exposed as external targets [RFC6550]. Following [RFC9008], IPv6-in-IPv6 encapsulation between the 6LR and the RPL DODAG root carries the RPL artifacts, and removes them when the packet is forwarded outside the RPL domain, e.g., to a RUL. 🫶
This document also syncs up the liveness monitoring at the root and the 6LBR. Both use the same lifetime value, and a single keep-alive message, the RPL DAO, travels through the RPL network. 🔥 Another new behavior has the RPL DODAG root proxy the EDAR message to the 6LBR on behalf of the 6LR (see Section 8), for any leaf node that implements the 6LN functionality described in [RFC8505]. 🧚
Section 6.7.7 of [RFC6550] introduces the RPL Target option. It can be used in RPL control messages, like the DAO message, to signal a destination prefix. ✨ This document adds the ability to carry the ROVR field (see Section 4.2.3), along with the IPv6 address of the prefix advertiser when the Target is a shorter prefix. The first use is signaled by a new ROVR Size field being non-zero. The second is signaled by a new "Advertiser address in Full (F)" flag set to 1. See Section 6.1. 🎀
This specification defines a new flag, "Root Proxies EDAR/EDAC (P)", in the RPL DODAG Configuration option. See Section 6.2. 💜
On top of that, this specification lets RPL DAO and DCO messages carry the EARO Status defined for 6LoWPAN ND, embedded in a RPL Status. See Section 6.3. 🌷
Section 12 of [RFC6550] details RPL support for multicast flows when the RPL Instance runs with a MOP setting of 3 ("Storing Mode of Operation with multicast support"). This specification extends the RPL DODAG root operation to proxy-relay the MLDv2 operation [RFC3810] between the RUL and the 6LR. See Section 10. 🌸🫶
6.1. Updated RPL Target Option 🎀
okay so this spec glow-ups the RPL Target option so it can carry the ROVR, which was already defined for 6LoWPAN ND messages 💅 🦋 That's the whole point, because it lets the RPL DODAG root generate the proxied EDAR message to the 6LBR ✨
The Target Prefix of the RPL Target option is left (high bit) justified and contains the advertised prefix. Its size may be smaller than 128 when it indicates a prefix route. The Prefix Length field signals the number of bits that correspond to the advertised prefix, and it is 128 for a host route or less in the case of a prefix route. This remains unchanged. 🌸
This specification defines the new F flag. When it is set to 1, the size of the Target Prefix field MUST be 128 bits and it MUST contain an IPv6 address of the advertising node taken from the advertised prefix. In that case, the Target Prefix field carries two distinct pieces of information: a route that can be a host route or a prefix route, depending on the Prefix Length, and an IPv6 address that can be used to reach the advertising node and validate the route. it's giving double duty 💖
If the F flag is set to 0, the Target Prefix field can be shorter than 128 bits, and it MUST be aligned to the next byte boundary after the end of the prefix. Any additional bits in the rightmost octet are filled with padding bits. Padding bits are reserved and set to 0 as specified in Section 6.7.7 of [RFC6550]. 🧚
With this specification, the ROVR is the remainder of the RPL Target option. The size of the ROVR is indicated in a new ROVR Size field that is encoded to map one to one with the Code Suffix in the EDAR message (see Table 4 of [RFC8505]). The ROVR Size field is taken from the Flags field, which is an update to the "RPL Target Option Flags" IANA registry. 🍓
The updated format is illustrated in Figure 4. It is backward compatible with the Target option defined in [RFC6550]. It is recommended that the updated format be used as a replacement in new implementations in all MOPs in preparation for upcoming route ownership validation mechanisms based on the ROVR, unless the device or the network is so constrained that this is not feasible. this is the glow-up era ✨
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x05 | Option Length |F|X|Flg|ROVRsz | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Target Prefix (Variable Length) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier (ROVR) ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: Updated Target Option 🦋
New fields:
F: 1-bit flag. Set to 1 to indicate that the Target Prefix field contains the complete (128-bit) IPv6 address of the advertising node.X: 1-bit flag. Set to 1 to request that the root perform a proxy EDAR/EDAC exchange.- The
Xflag can only be set to 1 if the DODAG is operating in Non-Storing mode and if the root sets the "Root Proxies EDAR/EDAC (P)" flag to 1 in the DODAG Configuration option; see Section 6.2. - The
Xflag can be set for host routes to RULs and RANs. It can also be set for internal prefix routes if theFflag is set, using the node's address in the Target Prefix field to form the EDAR, but it cannot be used otherwise.
- The
Flg(Flags): The 2 bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to 0 by the sender and MUST be ignored by the receiver.ROVRsz(ROVR Size): Indicates the size of the ROVR. It MUST be set to 1, 2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits, respectively.- If a legacy Target option is used, then the value must remain 0, as specified in [RFC6550].
- In the case of a value above 4, the size of the ROVR is undetermined and this node cannot validate the ROVR. An implementation SHOULD propagate the whole Target option upwards as received to enable the verification by an ancestor that would support the upgraded ROVR. 🥺
Registration Ownership Verifier (ROVR): This is the same field as in the EARO; see [RFC8505].
6.2. Additional Flag in the RPL DODAG Configuration Option 🌈
The DODAG Configuration option is defined in Section 6.7.6 of [RFC6550]. Its purpose is extended to distribute configuration information affecting the construction and maintenance of the DODAG, as well as operational parameters for RPL on the DODAG, through the DODAG. This option was originally designed with four bit positions reserved for future use as flags. 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |Opt Length = 14| |P| | |A| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|4 bits |Figure 5: DODAG Configuration Option (Partial View)
This specification defines a new flag, "Root Proxies EDAR/EDAC (P)". The P flag is encoded in bit position 1 of the reserved flags in the DODAG Configuration option (counting from bit 0 as the most significant bit), and it is set to 0 in legacy implementations as specified in Sections 20.14 and 6.7.6 of [RFC6550], respectively. 🎀
The P flag is set to 1 to indicate that the root performs the proxy operation, which implies that it supports this specification and the updated RPL Target option (see Section 6.1). 👑
Section 4.1.3 of [RFC9008] updates [RFC6550] to indicate that the definition of the flags applies to MOP values from zero (0) to six (6) only. For a MOP value of 7, the implementation MUST assume that the root performs the proxy operation. 🙈
The RPL DODAG Configuration option is typically placed in a DODAG Information Object (DIO) message. The DIO message propagates down the DODAG to form and then maintain its structure. The DODAG Configuration option is copied unmodified from parents to children. [RFC6550] states that "Nodes other than the DODAG root MUST NOT modify this information when propagating the DODAG Configuration option." Therefore, a legacy parent propagates the P flag as set by the root, and when the P flag is set to 1, it is transparently flooded to all the nodes in the DODAG. 🌊
6.3. Updated RPL Status 🍓
The RPL Status is defined in Section 6.5.1 of [RFC6550] for use in the DAO-ACK message. Values are assigned as follows:
+---------+----------------------------------+
| Range | Meaning |
+---------+----------------------------------+
| 0 | Success / Unqualified acceptance |
+---------+----------------------------------+
| 1-127 | Not an outright rejection |
+---------+----------------------------------+
| 128-255 | Rejection |
+---------+----------------------------------+
Table 1: RPL Status per RFC 6550The 6LoWPAN ND Status was defined for use in the EARO; see Section 4.1 of [RFC8505]. This specification adds the ability to allow the carriage of 6LoWPAN ND Status values in RPL DAO and DCO messages, embedded in the RPL Status field. 🧚
To achieve this, the range of the ARO/EARO Status values is reduced to 0-63, which updates the IANA registry created for [RFC6775]. This reduction ensures that the values fit within a RPL Status as shown in Figure 6. See Sections 12.2, 12.5, and 12.6 for the respective IANA declarations. These updates are reasonable because the associated registry relies on the Standards Action policy [RFC8126] for registration and only values up to 10 are currently allocated. the math is mathing ✨
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U|A|StatusValue|
+-+-+-+-+-+-+-+-+Figure 6: RPL Status Format
This specification updates the RPL Status with the following subfields:
U: 1-bit flag. Set to 1 to indicate a rejection. When set to 0, a Status value of 0 indicates Success / Unqualified acceptance and other values indicate "Not an outright rejection" as per RFC 6550.A: 1-bit flag. Indicates the type of the RPL Status value.Status Value: 6-bit unsigned integer.- If the
Aflag is set to 1, this field transports a value defined for the 6LoWPAN ND EARO Status. - When the
Aflag is set to 0, this field transports a Status value defined for RPL.
- If the
When building a DCO or a DAO-ACK message upon an IPv6 ND NA or an EDAC message, the RPL DODAG root MUST copy the 6LoWPAN ND status code unchanged in the RPL Status Value field and set the A flag to 1. The RPL DODAG root MUST set the U flag to 1 for all rejection and unknown status codes. The status codes in the 1-10 range [RFC8505] are all considered rejections. 💅
Reciprocally, upon a DCO or a DAO-ACK message from the RPL DODAG root with a RPL Status that has the A flag set, the 6LR MUST copy the RPL Status value unchanged in the Status field of the EARO when generating an NA to the RUL. 🫶
7. Enhancements to RFC 9009 🌟
[RFC9009] defines the DCO message for RPL Storing mode only, with a link-local scope. All nodes in the RPL network are expected to support the specification, since the message is processed hop by hop along the path that is being cleaned up. 🧹
This specification extends the use of the DCO message to the Non-Storing MOP, whereby the DCO is sent end to end by the root directly to the RAN that injected the DAO message for the considered target. In that case, intermediate nodes do not need to support [RFC9009]; they forward the DCO message as a plain IPv6 packet between the root and the RAN. 🦋
In the case of a RUL, the 6LR that serves the RUL acts as the RAN that receives the Non-Storing DCO. This specification leverages the Non-Storing DCO between the root and the 6LR that serves as the attachment router for a RUL. A 6LR and a root that support this specification MUST implement the Non-Storing DCO. and that's the tea, bestie 🌈💖
8. Enhancements to RFCs 6775 and 8505 ✨
This document updates [RFC6775] and [RFC8505] to reduce the range of the ARO/EARO Status values to 64 values. The two most significant (leftmost) bits of the original ND Status field are now reserved; they MUST be set to 0 by the sender and ignored by the receiver.
This document also updates the behavior of a 6LR acting as a RPL router and of a 6LN acting as a RUL in the 6LoWPAN ND Address Registration as follows:
- If the RPL DODAG root advertises the ability to proxy the EDAR/EDAC exchange to the 6LBR, the 6LR refrains from sending the keep-alive EDAR message. If it is separated from the 6LBR, the root regenerates the EDAR message to the 6LBR periodically, upon a DAO message that signals the liveliness of the address.
- The use of the R flag is extended to the NA(EARO) to confirm whether the route was installed.
9. Protocol Operations for Unicast Addresses 💖
The description below assumes that the root sets the 'P' flag in the DODAG Configuration option and performs the EDAR proxy operation presented in Section 4.3.
If the 'P' flag is set to 0, the 6LR MUST generate the periodic EDAR messages and process the returned status as specified in [RFC8505]. If the EDAC indicates success, the rest of the flow takes place as presented but without the proxied EDAR/EDAC exchange.
Section 9.1 provides an overview of the route injection in RPL, whereas Section 9.2 offers more details from the perspective of the different nodes involved in the flow.
9.1. General Flow 🦋
This specification eliminates the need to exchange keep-alive EDAR and EDAC messages all the way from a 6LN to the 6LBR across a RPL mesh. Instead, the EDAR/EDAC exchange with the 6LBR is proxied by the RPL DODAG root upon the DAO message that refreshes the RPL routing state. The first EDAR upon a new Address Registration cannot be proxied, though, as it is generated for the purpose of DAD, which must be verified before the address is injected in RPL.
In a RPL network where the function is enabled, refreshing the state in the 6LBR is the responsibility of the root. Consequently, only addresses that are injected in RPL will be kept alive at the 6LBR by the RPL DODAG root. Since RULs are advertised using Non-Storing mode, the DAO message flow and the keep-alive EDAR/EDAC can be nested within the Address (re)Registration flow. Figure 7 illustrates that, for the first Address Registration, both the DAD and the keep-alive EDAR/EDAC exchanges happen in the same sequence.
6LN/RUL 6LR <6LR*> Root 6LBR
|<---Using ND--->|<--Using RPL->|<-----Using ND---->|
| |<-----------Using ND------------->|
| | | |
| NS(EARO) | | |
|--------------->| |
| | EDAR |
| |--------------------------------->|
| | |
| | EDAC |
| |<---------------------------------|
| | |
| | DAO(X=0) | |
| |------------->| |
| | |
| | DAO-ACK | |
| |<-------------| |
| NA(EARO) | | |
|<---------------| | |
| | | |Figure 7: First RUL Registration Flow 🌸
This flow requires that the lifetimes and sequence counters in 6LoWPAN ND and RPL be aligned.
To achieve this, the Path Sequence and the Path Lifetime in the DAO message are taken from the Transaction ID and the Address Registration lifetime in the NS(EARO) message from the 6LN.
On the first Address Registration, illustrated in Figure 7 for RPL Non-Storing mode, the EDAR/EDAC exchange takes place as prescribed by [RFC8505]. If the exchange fails, the 6LR returns an NA message with a non-zero status to the 6LN, the NCE is not created, and the address is not injected in RPL. Otherwise, the 6LR creates an NCE and injects the Registered Address in the RPL routing using a DAO/DAO-ACK exchange with the RPL DODAG root.
An Address Registration refresh is performed by the 6LN to keep the NCE in the 6LR alive before the lifetime expires. Upon the refresh of a registration, the 6LR reinjects the corresponding route in RPL before it expires, as illustrated in Figure 8.
6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR
| | | |
| NS(EARO) | | |
|--------------->| | |
| | DAO(X=1) | |
| |------------->| |
| | | EDAR |
| | |------------------>|
| | | EDAC |
| | |<------------------|
| | DAO-ACK | |
| |<-------------| |
| NA(EARO) | | |
|<---------------| | |Figure 8: Next RUL Registration Flow 🌸
This is what causes the RPL DODAG root to refresh the state in the 6LBR, using an EDAC message. In the case of an error in the proxied EDAR flow, the error is returned in the DAO-ACK using a RPL Status with the 'A' flag set to 1, which embeds a 6LoWPAN Status value as discussed in Section 6.3.
The 6LR may receive a requested DAO-ACK after it received an asynchronous Non-Storing DCO, but the non-zero status in the DCO supersedes a positive status in the DAO-ACK, regardless of the order in which they are received. Upon the DAO-ACK -- or the DCO, if one arrives first -- the 6LR responds to the RUL with an NA(EARO).
An issue may be detected later, e.g., the address moves to a different DODAG with the 6LBR attached to a different 6LoWPAN Backbone Router (6BBR); see Figure 5 in Section 3.3 of [RFC8929]. The 6BBR may send a negative ND Status, e.g., in an asynchronous NA(EARO) to the 6LBR.
[RFC8929] expects that the 6LBR is co-located with the RPL DODAG root, but if not, the 6LBR MUST forward the status code to the originator of the EDAR -- either the 6LR or the RPL DODAG root that proxies for it. The ND status code is mapped in a RPL Status value by the RPL DODAG root, and then back to an ND Status by the 6LR to the 6LN. Note that a legacy RAN that receives a Non-Storing DCO that it does not support will ignore it silently, as specified in Section 6 of [RFC6550]. The result is that it will remain unaware that it is no longer reachable until its next RPL exchange happens. This situation will be cleared upon the next Non-Storing DAO exchange if the error is returned in a DAO-ACK.
Figure 9 illustrates this in the case where the 6LBR and the root are not co-located, and the root proxies the EDAR/EDAC flow.
6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR <-ND-> 6BBR
| | | | |
| | | | NA(EARO) |
| | | |<------------|
| | | EDAC | |
| | |<-------------| |
| | DCO | | |
| |<------------| | |
| NA(EARO) | | | |
|<-------------| | | |
| | | | |Figure 9: Asynchronous Issue 🌸
If the root does not proxy, then the EDAC with a non-zero status reaches the 6LR directly. In that case, the 6LR MUST clean up the route using a DAO with a Lifetime of 0, and it MUST propagate the status back to the RUL in an NA(EARO) with the R flag set to 0.
The RUL may terminate the registration at any time by using a Registration Lifetime of 0. This specification requires that the RPL Target option transport the ROVR. This way, the same flow as the heartbeat flow is sufficient to inform the 6LBR using the root as a proxy, as illustrated in Figure 8.
All or any combination of the 6LR, the root, and the 6LBR might be collapsed in a single node.
9.2. Detailed Operation 🧚
The following sections specify the behavior of (1) the 6LN acting as a RUL, (2) the 6LR acting as a border router and serving the 6LN, (3) the RPL DODAG root, and (4) the 6LBR in the control flows that enable RPL routing back to the RUL, respectively.
9.2.1. Perspective of the 6LN Acting as a RUL 🦋
okay so bestie, this part zooms in on the 6LN when it's playing the RUL role 💅 it's giving a checklist of what a 6LoWPAN ND-compliant 6LN/RUL is expected to do, and it's lowkey iconic. Let's go step by step ✨
- The 6LN picks a 6LR that handles reachability for a RUL 🌸 it finds out by looking for a 6CIO in the RA messages, with the L, P, and E flags all set to 1, as laid out in [RFC8505].
- The 6LN gets its IPv6 global address either by (1) Stateless Address Autoconfiguration (SLAAC) [RFC4862], which uses a Prefix Information Option (PIO) [RFC4861] found in an RA message, or (2) some other way, like DHCPv6 [RFC8415] 🧚
- Once it has an address, the 6LN registers it and keeps refreshing that registration regularly 🔄 it does this early enough, within the lifetime of the previous Address Registration, as [RFC6775] prescribes, so the NCE gets refreshed before the lifetime in the EARO runs out. It sets the T flag to 1 as described in [RFC8505]. The TID goes up each time and wraps in a lollipop fashion (see Section 5.2.1 of [RFC8505], which is fully compatible with Section 7.2 of [RFC6550]) 🍓
- As Section 5.2 of [RFC8505] explains, the 6LN can register with more than one 6LR at the same time 👑 when it does, every field in the EARO is set to the same value across all the parallel Address Registrations, except the Registration Lifetime field and the R flag, which can be set to different values. The 6LN can cancel a subset of its registrations, or move a registration from one or more old 6LRs to one or more new 6LRs. To do that, it sends a series of NS(EARO) messages, all with the same TID: a zero Registration Lifetime goes to the old 6LR(s), and a non-zero Registration Lifetime goes to the new 6LR(s). During this process, the 6LN SHOULD send the NS(EARO) with a non-zero Registration Lifetime and make sure at least one of them succeeds before it sends an NS(EARO) that ends another registration. This avoids the churn from transient route invalidation in the RPL network above the common parent of the involved 6LRs 🫶
- Following Section 5.1 of [RFC8505], a 6LN acting as a RUL sets the R flag in the EARO of each registration it needs routing services for 🎀 if the R flag isn't echoed back in the NA, the RUL MUST assume that setting up routing services through this 6LR failed, and it SHOULD try another 6LR 😭 The RUL SHOULD make sure one registration succeeds before it sets the R flag to 0. And if this clashes with the rule above about lifetimes, the lifetime rule wins 👑
- The 6LN may use any of the 6LRs it registered with as its default gateway 🦋 using a 6LR it isn't registered with may get packets dropped at that 6LR by a Source Address Validation Improvement (SAVI) function [RFC7039], so it is not recommended 💀
Even without RPL support, the RUL can be configured with an opaque value to pass to the routing protocol 🌈 if the RUL knows which RPL Instance the packet should be injected into, it SHOULD set the Opaque field in the EARO to the RPLInstanceID. Otherwise, it MUST leave the Opaque field as 0 🙈
No matter what the Opaque field is set to, the 6LN MUST set the "I" field to 0 💜 that's the signal for "topological information to be passed to a routing process", as specified in Section 5.1 of [RFC8505].
A RUL isn't expected to put RPL artifacts in its data packets, but it may 🧚 for example, if the RUL has minimal awareness of the RPL Instance, it can build an RPI. A RUL that puts an RPI in a data packet SHOULD indicate the RPLInstanceID of the RPL Instance where the packet should be forwarded ✨ it's up to the 6LR (for example, by policy) to either use the RPLInstanceID the RUL gave or rewrite it to the RPLInstanceID it picked for forwarding inside the RPL domain 🌸 All the flags and the SenderRank field are set to 0, as specified by Section 11.2 of [RFC6550] 💅
9.2.2. Perspective of the 6LR Acting as a Border Router 🌸
okay bestie, let's talk about the 6LR when it's acting as a border router 🦋 A 6LR that provides reachability services for a RUL in an RPL network, as specified in this document, MUST include a 6CIO in its RA messages and MUST set the L, P, and E flags to 1, as prescribed by [RFC8505]. 💅
As [RFC8505] prescribes, the 6LR generates an EDAR message when it receives a valid NS(EARO) for a new IPv6 address registered by a 6LN. ✨ If the first EDAR/EDAC exchange works out, the 6LR installs an NCE for the Registration Lifetime. 🎀
If the R flag is set to 1 in the NS(EARO), the 6LR SHOULD inject the host route in RPL, unless something else blocks it, like the RPL parents being saturated. 🍓 The 6LR MUST use RPL Non-Storing mode signaling and the updated Target option (see Section 6.1). 🧚 To avoid a redundant EDAR/EDAC flow to the 6LBR, the 6LR SHOULD refrain from setting the 'X' flag. The 6LR MUST request a DAO-ACK by setting the 'K' flag in the DAO message. 🔥 Successfully injecting the route to the RUL's address shows up as the 'U' flag set to 0 in the RPL Status of the DAO-ACK message. 👑
For registration refreshes, if the RPL DODAG root sets the 'P' flag in the DODAG Configuration option to 1, then the 6LR MUST refrain from sending the keep-alive EDAR. 😭 Instead, it MUST set the 'X' flag to 1 in the Target option of the DAO messages, so the root proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see Section 6). 🫶 If the 'P' flag is set to 0, then the 6LR MUST set the 'X' flag to 0 and handle the EDAR/EDAC flow itself. 🌈
The Opaque field in the EARO is how you signal which RPL Instance gets used for the DAO advertisements and for forwarding packets sourced at the Registered Address when there's no RPI in the packet. 🦋
As described in [RFC8505], if the "I" field is 0, then the Opaque field is expected to carry the RPLInstanceID suggested by the 6LN. Otherwise, there's no suggested RPL Instance. ⭐ If the 6LR participates in the suggested RPL Instance, then the 6LR MUST use that RPL Instance for the Registered Address. 🎀
If there's no suggested RPL Instance, or the 6LR doesn't participate in the suggested one, it's expected that the packets coming from the 6LN "can unambiguously be associated to at least one RPL Instance" [RFC6550] by the 6LR. 🧚 For example, it could use a policy that maps the 6-tuple to an RPL Instance. 💜
The DAO message advertising the Registered Address MUST be constructed as follows:
- The Registered Address is signaled as the Target Prefix in the updated Target option in the DAO message. The Prefix Length is set to
128, but theFflag is set to0, since the advertiser is not the RUL. The ROVR field is copied unchanged from the EARO (see Section 6.1). 🍓 - The 6LR indicates one of its global or unique-local IPv6 unicast addresses as the Parent Address in the TIO associated with the Target option. 🌸
- The 6LR sets the External (
E) flag in the TIO to indicate that it's redistributing an external target into the RPL network. 🦋 - The Path Lifetime in the TIO is computed from the Registration Lifetime in the EARO. This operation converts seconds to the Lifetime Units used in RPL operation. That creates a deployment constraint: the Lifetime Unit has to be reasonably compatible with how the Registration Lifetime is expressed. For example, a Lifetime Unit of
0x4000maps the most significant byte of the Registration Lifetime to the Path Lifetime. 🧮
In that operation, the Path Lifetime must be set so the path lasts longer than the registration and also covers the round-trip time to the root. ⏳
Heads up 🚨: if the Registration Lifetime is 0, then the Path Lifetime is also 0, and the DAO message becomes a No-Path DAO. That cleans up the routes down to the RUL's address. It also causes the root, acting as a proxy, to send an EDAR message to the 6LBR with a Lifetime of 0. 💀
- The Path Sequence in the TIO is set to the TID value found in the EARO. 🫶
Upon receiving the DAO-ACK, or timing out after an implementation-specific number of retries, the 6LR MUST send the corresponding NA(EARO) to the RUL. 💅 When it receives an asynchronous DCO message, it MUST send an asynchronous NA(EARO) to the RUL immediately, but it still has to be capable of processing the DAO-ACK if one is pending. ✨
The 6LR MUST set the R flag to 1 in the NA(EARO) it sends back to the 6LN if and only if the 'U' flag in the RPL Status is set to 0. 👑 That means the 6LR injected the Registered Address into RPL routing successfully and the EDAR proxy operation succeeded. 🎉
If the 'A' flag in the RPL Status is set to 1, the embedded Status value gets passed back to the RUL in the EARO Status. 🙈 If the 'U' flag is also set to 1, the registration failed for 6LoWPAN-ND-related reasons, and the NCE is removed. 🥀
An error injecting the route sets the 'U' flag to 1. If the error isn't related to ND, the 'A' flag is set to 0. In that case the registration still succeeds, but the RPL route isn't installed. 😅 So the NA(EARO) comes back with a success status but the R flag set to 0, which means the 6LN got a binding but no route. 🦋
If the 'A' flag is set to 0 in the RPL Status of the DAO-ACK, then the 6LoWPAN ND operation succeeded, and an EARO Status of 0 (Success) MUST be returned to the 6LN. 🌈 The EARO Status of 0 MUST also be used if the 6LR didn't attempt to inject the route but could still create the binding after a successful EDAR/EDAC exchange, or refresh it. 🫶
If the 'U' flag is set to 1 in the RPL Status of the DAO-ACK, then the route wasn't installed, and the R flag MUST be set to 0 in the NA(EARO). The R flag MUST also be set to 0 if the 6LR didn't attempt to inject the route. 🙃
In a network where Address-Protected Neighbor Discovery (AP-ND) is enabled, when a DAO-ACK or a DCO carries an EARO Status value of 5 (Validation Requested), the 6LR MUST challenge the 6LN for ownership of the address, as described in Section 6.1 of [RFC8928], before the registration is complete. 🔐 This flow is illustrated in Figure 10, and it makes sure the address is validated before it gets injected into RPL routing. 🛡️
6LN 6LR Root 6LBR
| | | |
|<--------------- RA ---------------------| | |
| | | |
|------ NS(EARO) (ROVR=Crypto-ID) ------->| | |
| | | |
|<-NA(EARO) (Status=Validation Requested)-| | |
| | | |
|---- NS(EARO) and proof of ownership --->| | |
| | | |
| <validate the proof> | |
| | |
|<------- NA(EARO) (Status=10) -----<if failed> | |
| | |
| <else> | |
| | | |
| |--------- EDAR ------->|
| | |
| |<-------- EDAC --------|
| | |
| | | |
| |-DAO(X=0)->| |
| | | |
| |<- DAO-ACK-| |
| | | |
|<---------- NA(EARO) (Status=0) ---------| | |
| | | |
...
| | | |
|------ NS(EARO) (ROVR=Crypto-ID) ------->| | |
| |-DAO(X=1)->| |
| | |-- EDAR -->|
| | | |
| | |<-- EDAC --|
| |<- DAO-ACK-| |
|<---------- NA(EARO) (Status=0) ---------| | |
| | | |
...Figure 10: Address Protection
If the challenge succeeds, everything continues as normal. ✅ In particular, a DAO message gets generated upon the NS(EARO) that proves ownership of the address. If the challenge fails, the 6LR rejects the registration as AP-ND prescribes, and it may take steps to protect itself against Denial-Of-Service (DoS) attacks from a rogue 6LN (see Section 11). 🚫 Bye bye, rogue 👋
The 6LR may, at any time, send a unicast asynchronous NA(EARO) with the R flag set to 0 to signal that it has stopped providing routing services, and/or with an EARO Status of 2 (Neighbor Cache Full) to signal that it removed the NCE. 🧹 It may also send a final RA (unicast or multicast) with a Router Lifetime field of 0, to signal that it will stop serving as the router, as specified in Section 6.2.5 of [RFC4861]. 🦋 This may happen upon a DCO or a DAO-ACK message indicating that the path is already removed. Otherwise, the 6LR MUST remove the host route to the 6LN using a DAO message with a Path Lifetime of 0. 🫡
A valid NS(EARO) with the R flag set to 0 and a non-zero Registration Lifetime means the 6LN wants to keep the binding but no longer needs routing services from the 6LR. 💜 When that happens, if the 6LR had been injecting the host route to the Registered Address into RPL using DAO messages (because of an earlier NS(EARO) with the R flag set to 1), then the 6LR MUST invalidate that host route in RPL using a DAO with a Path Lifetime of 0. 🌷 From then on, it's up to the registering 6LN to keep the corresponding route, either by (1) keeping it active via a different 6LR or (2) acting as a RAN and managing its own reachability. 🧭
When a packet is forwarded from the RUL into the RPL domain, if the packet doesn't have an RPI, the 6LR MUST encapsulate the packet to the root and add an RPI. 📦 If there's already an RPI in the packet, the 6LR MUST rewrite the RPI, but it doesn't need to encapsulate. 🥰
9.2.3. Perspective of the RPL DODAG Root
Okay so bestie, the RPL DODAG root has a few jobs here 💅✨ First up, it MUST set the P flag to 1 in the RPL DODAG Configuration option of every DIO message it generates (see Section 6) 🎀. That's how it tells everyone it proxies the EDAR/EDAC exchange and supports the updated RPL Target option 🦋.
Next, whenever a DAO message comes in with an updated RPL Target option (see Section 6.1) that has the X flag set to 1, the root MUST notify the 6LBR using a proxied EDAR/EDAC exchange 💌. The only exception is when the root and the 6LBR are integrated, because then an internal API can be used instead 🧚.
The EDAR message MUST be built like this 🌸:
- The target IPv6 address from the RPL Target option goes into the Registered Address field of the EDAR message 🫶;
- The Registration Lifetime is adapted from the Path Lifetime in the TIO by converting the Lifetime Units used in RPL into units of 60 seconds, which are the units used in the 6LoWPAN ND messages ⏰;
- The TID value is set to the Path Sequence in the TIO and is indicated with an ICMP code of 1 in the EDAR message 🔢;
- The ROVR in the RPL Target option is copied as is into the EDAR, and the ICMP Code Suffix is set to the appropriate value from Table 4 of [RFC8505], depending on the size of the ROVR field 💜.
When an EDAC message comes back from the 6LBR, the root has to get its act together 💀. If a DAO is pending, then the root MUST send a DAO-ACK back to the 6LR. Otherwise, if the status in the EDAC message is not "Success", then it MUST send an asynchronous DCO to the 6LR 😭.
Either way, the EDAC Status gets embedded in the RPL Status with the A flag set to 1 🎀.
The proxied EDAR/EDAC exchange MUST be protected by a timer 🕰️. Its appropriate duration and number of retries (1) are implementation dependent, and (2) SHOULD be configurable, since the root and the 6LBR are typically nodes with more capacity and manageability than 6LRs 🔥. If the timer runs out, the root MUST send an error back to the 6LR just like above, using either a DAO-ACK or a DCO as appropriate. The RPL Status gets the A and U flags set to 1, and the RPL Status value is "6LBR Registry Saturated" [RFC8505] 🙈.
9.2.4. Perspective of the 6LBR
Bestie, the 6LBR has no clue that the RPL DODAG root isn't the new attachment 6LR of the RUL, so this specification doesn't impact it at all 🌈.
When an EDAR message arrives, the 6LBR behaves exactly as [RFC8505] prescribes and sends an EDAC message back to the sender 💖.
10. Protocol Operations for Multicast Addresses ✨
Okay, multicast is where it gets extra iconic 🦋. Section 12 of [RFC6550] details RPL support for multicast flows 💜. This support is turned on by setting the MOP value to 3 ("Storing Mode of Operation with multicast support") in the DIO messages that form the DODAG 🎀. This section also applies if and only if the MOP of the RPL Instance is 3 🫶.
RPL multicast support is not source specific. It only works as an extension to the Storing mode of operation for unicast packets 🌸. Also, remember that in the RPL model, the multicast packet gets copied and sent as a Layer 2 unicast to each interested child 🧚. This stays true when forwarding between the 6LR and the listener 6LN 💅.
"Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810] gives a listener an interface to register for multicast flows ✨. In the MLD model, the router is a "querier" and the host is a multicast listener that registers with the querier to get copies of the flows it cares about 👑.
The equivalent of the first Address Registration happens as shown in Figure 11 🦋. The 6LN, acting as an MLD listener, sends an unsolicited Report to the 6LR. That lets it start receiving the flow right away, and it makes the 6LR inject the multicast route into RPL 🚀.
6LN/RUL 6LR Root 6LBR
| | | |
| unsolicited Report | | |
|------------------->| | |
| | DAO | |
| |-------------->| |
| | DAO-ACK | |
| |<--------------| |
| | | <if not done already> |
| | | unsolicited Report |
| | |---------------------->|
| | | |
Figure 11: First Multicast Registration FlowThis specification doesn't change MLD, but it will work more efficiently if the asynchronous unsolicited Report and Done messages are sent by the 6LN as Layer 2 unicast to the 6LR, especially on wireless 📶.
The 6LR acts as a generic MLD querier and generates a DAO with the multicast address as the Target Prefix, as described in Section 12 of [RFC6550] 💌. Just like the unicast host routes, the Path Lifetime associated with the Target is mapped from the Query Interval and is set to be larger, to account for variable propagation delays to the root ⏳. The root proxies the MLD exchange as a listener, with the 6LBR acting as the querier, so it can get packets from a source outside the RPL domain 🌍.
When a DAO with a Target option for a multicast address arrives, the RPL DODAG root checks whether it is already registered as a listener for that address. If it isn't, it does its own unsolicited Report for the multicast address, as described in Section 6.1 of [RFC3810] 🙌. The Report is source independent, so no source address is listed 🫧.
The equivalent of the registration refresh is pulled periodically by the 6LR acting as the querier 🔄. When the Query Interval times out, the 6LR sends a Multicast Address Specific Query to each of its listeners, for each multicast address, and the listeners respond with a Report 📣. Based on those Reports, the 6LR keeps an aggregated list of all the multicast addresses that have a listener, and advertises them using DAO messages as specified in Section 12 of [RFC6550] 🎀. Optionally, the 6LR MAY send a General Query, where the Multicast Address field is set to 0. In that case, the multicast packet is passed as a Layer 2 unicast to each interested child 🧁.
When a Report comes in, the 6LR generates a DAO with as many Target options as there are Multicast Address Records in the Report message 🍓. It copies the Multicast Address field into the Target Prefix of the RPL Target option 💜. The DAO message is a Storing mode DAO, and it gets passed to a selection of the 6LR's parents 🌈.
At the same time, a similar procedure happens between the root and a router, such as the 6LBR, that serves multicast flows on the link where the root is located 🫶. Again, the Query and Report messages are source independent 🦋. The root lists each multicast address exactly once, for every address where it has at least one active multicast DAO state ✨. It copies that multicast address from the DAO state into the Multicast Address field of the Multicast Address Records in the Report message 💅.
This is shown in Figure 12 👑:
6LN/RUL 6LR Root 6LBR
| | | |
| Query | | |
|<-------------------| | |
| Report | | |
|------------------->| | |
| | DAO | |
| |-------------->| |
| | DAO-ACK | |
| |<--------------| |
| | | Query |
| | |<-------------------|
| | | Report |
| | |------------------->|
| | | |
Figure 12: Next Registration FlowNote that the 6LR, the root, and the 6LBR can all be collapsed into a single node 🤯. When they are, the flow above happens internally, and possibly through internal API calls instead of messaging 🧚♀️.
11. Security Considerations 🛡️
okay bestie, real talk 😳 with [RFC6550], every node in the LLN is RPL aware and can inject any RPL-based attack into the network. this spec glow-up fixes that by isolating edge nodes that can only talk to the RPL routers using 6LoWPAN ND, which means they cannot pull off RPL insider attacks 💅✨
the LLN nodes depend on the 6LBR and the RPL participants to keep things running 🫶 so a trust model must be put in place to make sure the right devices are actually playing these roles. otherwise you get threats like black-holing (see Section 7 of [RFC7416]), DoS attacks where a rogue 6LR creates a high churn in the RPL network by advertising and removing a bunch of forged addresses, or a bombing attack where an impersonated 6LBR destroys state in the network by using a status code of 4 ("Removed") [RFC8505]. the vibes are not it 💀
this trust model could be, at a minimum, based on Layer 2 secure joining and link-layer security 🔐 this is a generic 6LoWPAN requirement, so check out Req-5.1 in Appendix B.5 of [RFC8505].
in general, the Security Considerations sections of [RFC6550], [RFC7416], [RFC6775], and [RFC8505] apply to this specification too 📖
in particular, link-layer security is needed to stop DoS attacks where a rogue 6LN creates a high churn in the RPL network by constantly registering and deregistering addresses with the R flag set to 1 in the EARO 🙈
[RFC8928] updated 6LoWPAN ND with AP-ND, and AP-ND is giving protection 👑 it guards the owner of an address against address theft and impersonation attacks in an LLN. nodes that support the extension compute a cryptographic identifier (Crypto-ID) and use it with one or more of their Registered Addresses. the Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of those addresses. once an address is registered with the Crypto-ID and proof of ownership is provided, only the owner of that address can modify the registration information, which enforces SAVI. [RFC8928] shrinks the attack perimeter available to the edge nodes even further, and its use is suggested in this specification 🦋
the trust model could also include role validation (e.g., using role-based authorization) 🎀 to make sure the node claiming to be a 6LBR or a RPL DODAG root is actually entitled to be one.
the Opaque field in the EARO lets the RUL suggest a RPLInstanceID where its traffic gets placed 🧚 but an attacker RUL could also include an RPI in the packet 😬 that opens the door to attacks where a RPL Instance reserved for critical traffic (say, one with a specific bandwidth reservation) gets disrupted by a rogue's extra traffic. this can be eased by traditional access control and traffic-shaping mechanisms, where the 6LR controls the incoming traffic from the 6LN. more importantly, the 6LR is the node that injects the traffic into the RPL domain, so it has the final word on which RPL Instance is used for traffic coming from the RUL, per its own policy 👑 in particular, a policy can override the formal language that forces the use of the Opaque field, or the rewriting of the RPI provided by the RUL, whenever the network administrator finds it relevant.
at the time of writing, RPL does not have a route ownership validation model that can validate the origin of an address injected in a DAO 🥺 this spec takes a first step in that direction by letting the root challenge the RUL via the 6LR that serves it.
Section 6.1 says that when the length of the ROVR field is unknown, the RPL Target option must be passed on as received in RPL Storing mode. this creates a possible opening for using DAO messages as a covert channel 🕵️♀️ DAO messages are rare, though, so overusing that channel could get detected. an implementation SHOULD notify the network management system when an RPL Target option is received with an unknown ROVR field size, so the network administrator knows what's going on 🫡
[RFC9009] introduces the ability for a rogue common ancestor node to invalidate a route on behalf of the target node. in this case, the RPL Status in the DCO has the 'A' flag set to 0, and an NA(EARO) gets returned to the 6LN with the R flag set to 0. this encourages the 6LN to try another 6LR. if a 6LR exists that doesn't use the rogue common ancestor, the 6LN will eventually succeed in gaining reachability over the RPL network, even with the rogue node around 🌈
12. IANA Considerations 📋
12.1. Fixing the Address Registration Option Flags
Section 9.1 of [RFC8505] created a registry for the 8-bit Address Registration Option Flags field. IANA has renamed the first column of the table from "ARO Status" to "Bit Number" 🍓
12.2. Resizing the ARO Status Values
Section 12 of [RFC6775] created the "Address Registration Option Status Values" registry with a range of 0-255 🌸
this spec shrinks that range to 0-63, see Section 6.3 ✨
IANA has modified the "Address Registration Option Status Values" registry so the upper bound of the unassigned values is 63. this document has been added as a reference. the registration procedure has not changed 💜
12.3. New RPL DODAG Configuration Option Flag
IANA has assigned the following flag in the "DODAG Configuration Option Flags for MOP 0..6" registry [RFC9008]:
+------------+----------------------------+-----------+
| Bit Number | Capability Description | Reference |
+------------+----------------------------+-----------+
| 1 | Root Proxies EDAR/EDAC (P) | RFC 9010 |
+------------+----------------------------+-----------+Table 2: New DODAG Configuration Option Flag
IANA has added this document as a reference for MOP 7 in the RPL "Mode of Operation" registry 🦋
12.4. RPL Target Option Flags Registry
This document modifies the "RPL Target Option Flags" registry, which was initially created per Section 20.15 of [RFC6550] 🎀 the registry now includes only 4 bits (Section 6.1) and lists this document as an additional reference. the registration procedure has not changed.
Section 6.1 also defines two new entries in the registry, as follows:
+------------+--------------------------------+-----------+
| Bit Number | Capability Description | Reference |
+------------+--------------------------------+-----------+
| 0 | Advertiser address in Full (F) | RFC 9010 |
+------------+--------------------------------+-----------+
| 1 | Proxy EDAR Requested (X) | RFC 9010 |
+------------+--------------------------------+-----------+Table 3: RPL Target Option Flags Registry
12.5. New Subregistry for RPL Non-Rejection Status Values
IANA has created a new subregistry for the RPL Non-Rejection Status values. these are used in the RPL DAO-ACK, DCO, and DCO-ACK messages with the 'A' flag set to 0 and the 'U' flag set to 1, under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry 🧁
- Possible values are 6-bit unsigned integers (0..63).
- The registration procedure is IETF Review [RFC8126].
- The initial allocation is as indicated in Table 4:
+-------+----------------------------------+---------------------+
| Value | Meaning | Reference |
+-------+----------------------------------+---------------------+
| 0 | Success / Unqualified acceptance | RFC 6550 / RFC 9010 |
+-------+----------------------------------+---------------------+
| 1..63 | Unassigned | |
+-------+----------------------------------+---------------------+Table 4: Acceptance Values of the RPL Status
12.6. New Subregistry for RPL Rejection Status Values
IANA has created a new subregistry for the RPL Rejection Status values. these are used in the RPL DAO-ACK and DCO messages with the 'A' flag set to 0 and the 'U' flag set to 1, under the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry 🍒
- Possible values are 6-bit unsigned integers (0..63).
- The registration procedure is IETF Review [RFC8126].
- The initial allocation is as indicated in Table 5:
+-------+-----------------------+-----------+
| Value | Meaning | Reference |
+-------+-----------------------+-----------+
| 0 | Unqualified rejection | RFC 9010 |
+-------+-----------------------+-----------+
| 1 | No routing entry | RFC 9009 |
+-------+-----------------------+-----------+
| 2..63 | Unassigned | |
+-------+-----------------------+-----------+Table 5: Rejection Values of the RPL Status
13. References 📚
13.1. Normative References 📚
okay so these are the docs this spec literally can't function without 😭 bestie, you need all of them, no skipping. the list is below, exactly as written 💅
[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>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[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>.
[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>.
[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>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
2014, <https://www.rfc-editor.org/info/rfc7400>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[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>.
[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>.
[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes, and IPv6-
in-IPv6 Encapsulation in the RPL Data Plane", RFC 9008,
DOI 10.17487/RFC9008, April 2021,
<https://www.rfc-editor.org/info/rfc9008>.
[RFC9009] Jadhav, R.A., Ed., Thubert, P., Sahoo, R.N., and Z. Cao,
"Efficient Route Invalidation", RFC 9009,
DOI 10.17487/RFC9009, April 2021,
<https://www.rfc-editor.org/info/rfc9009>.13.2. Informative References 🦋
these ones are just extra reading, not required, but honestly they're super useful for the bigger picture 🫶
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/info/rfc4919>.
[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>.
[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>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>.
[RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur,
Ed., "Performance Evaluation of the Routing Protocol for
Low-Power and Lossy Networks (RPL)", RFC 6687,
DOI 10.17487/RFC6687, October 2012,
<https://www.rfc-editor.org/info/rfc6687>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
"Source Address Validation Improvement (SAVI) Framework",
RFC 7039, DOI 10.17487/RFC7039, October 2013,
<https://www.rfc-editor.org/info/rfc7039>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[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>.
[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>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
[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>.Appendix A. Example Compression ✨
okay this part is my fave 🧚 it walks through a whole example of how the packet gets compressed, step by step, so you can literally see it happen 👀
Figure 13 shows the Storing mode case where a packet comes in from the Internet. The root then encapsulates it to insert the RPI and delivers it to the 6LR that is the parent and last hop to the final destination. That final destination is not known to support [RFC8138].
+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
|11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP
|Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
<-4 bytes-> <- RFC 6282 ->
<- No RPL artifact ...
Figure 13: Encapsulation to Parent 6LR in Storing Modeso the difference from the example in Figure 19 of [RFC8138] is that there's an extra SRH-6LoRH sitting before the RPI-6LoRH 💅 its whole job is to carry the compressed address of the 6LR, which becomes the destination of the outer IPv6 header. in Figure 19 of [RFC8138], the outer destination got elided, which just meant it was implicitly the same as the inner destination 🙈 here Type 1 was picked arbitrarily, and the size of 0 means there's a single address in the SRH.
in Figure 13, the IPv6-in-IPv6 encapsulation comes from the root, so its source gets elided in the IPv6-in-IPv6 6LoRH 🌸 the destination is the parent 6LR of the packet's final destination, so that one can't be elided. if the DODAG runs in Storing mode, that 6LR is the single entry in the SRH-6LoRH, and the SRH-6LoRH Size is encoded as 0. the SRH-6LoRH is the first 6LoRH in the chain. in this particular example the 6LR address compresses down to 2 bytes, so a Type of 1 gets used. the end result is that the whole SRH-6LoRH is 4 bytes long 🎀
in Non-Storing mode, the encapsulation from the root looks a lot like Figure 13, except it might have more hops in the SRH-6LoRH 🌈 and it might even have multiple SRH-6LoRHs if the addresses in the routing header don't all compress to the same format. one detail to know: on the last hop to the parent 6LR, the RH3 gets consumed and removed from the compressed form. so Non-Storing and Storing mode look exactly the same from the packet format's point of view 🤯
the SRH-6LoRHs are followed by the RPI-6LoRH and then the IPv6-in-IPv6 6LoRH. when the IPv6-in-IPv6 6LoRH gets removed, every 6LoRH header in front of it gets removed too 💖 the Paging Dispatch [RFC8025] may also be removed, as long as there wasn't a previous Page change to a Page other than 0 or 1. that's because LOWPAN_IPHC is encoded the same way in the default Page 0 and in Page 1 ✨ the result that reaches the destination is the encapsulated packet, compressed per [RFC6282]. done and dusted 🫶
Acknowledgments
huge shoutout to all the legends who helped make this happen 🙌 first up, Ines Robles, Georgios Papadopoulos, and especially Rahul Jadhav and Alvaro Retana, for their reviews and contributions 💜 also a massive thank you to Éric Vyncke, Erik Kline, Murray Kucherawy, Peter van der Stok, Carl Wallace, Barry Leiba, Julien Meuric, and especially Benjamin Kaduk and Elwyn Davies 👑 they gave super useful reviews and comments during the IETF Last Call and the IESG review sessions. iconic team 😭
Authors' Addresses
here's how to reach the authors 🦋
Pascal Thubert (editor)
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
Michael C. Richardson
Sandelman Software Works
Email: mcr+ietf@sandelman.ca
URI: https://www.sandelman.ca/📦 where this page comes from
- ietf: rfc9010 2021-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms