RFC 6550
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks
RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks 🦋
Series: Request for Comments: 6550 🎀 Category: Standards Track ✨ ISSN: 2070-1721 Date: March 2012 📅 Editors: T. Winter, Ed.; P. Thubert, Ed. (Cisco Systems) 💖
The author crew is giving main character energy: A. Brandt (Sigma Designs), J. Hui (Arch Rock Corporation), R. Kelsey (Ember Corporation), P. Levis (Stanford University), K. Pister (Dust Networks), R. Struik (Struik Security Consultancy), JP. Vasseur (Cisco Systems), and R. Alexander (Cooper Power Systems). 🫶
The title block doesn't list any Obsoletes or Updates lines, so this one isn't replacing or patching another RFC, at least according to this header. 🌸
Abstract 🧚
Okay so, Low-Power and Lossy Networks (LLNs) are a class of network where both the routers AND their interconnects are constrained 😭. LLN routers usually have limited processing power, memory, and energy (aka battery power 🔋). Their links have high loss rates, low data rates, and they're kind of unstable, honestly. An LLN can be anywhere from a few dozen routers to thousands of them. 💀
LLNs support three kinds of traffic: point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN toward a central control point). ✨
This document specifies the IPv6 Routing Protocol for Low-Power and Lossy Networks (RPL) 👑. RPL is the mechanism that handles multipoint-to-point traffic (devices → central control point) AND point-to-multipoint traffic (central control point → devices). Point-to-point traffic is also supported, so RPL really does it all 💅.
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 it was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741. 📚
Info about the current status of this document, any errata, and how to give feedback on it can be found at http://www.rfc-editor.org/info/rfc6550. 🔍
Copyright Notice 🔐
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🫶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date this document was published. Please read these documents carefully, because they explain your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License. ⚖️
Table of Contents 📖
1. Introduction ....................................................8
1.1. Design Principles ..........................................8
1.2. Expectations of Link-Layer Type ...........................10
2. Terminology ....................................................10
3. Protocol Overview ..............................................13
3.1. Topologies ................................................13
3.1.1. Constructing Topologies ............................13
3.1.2. RPL Identifiers ....................................14
3.1.3. Instances, DODAGs, and DODAG Versions ..............14
3.2. Upward Routes and DODAG Construction ......................16
3.2.1. Objective Function (OF) ............................17
3.2.2. DODAG Repair .......................................17
3.2.3. Security ...........................................17
3.2.4. Grounded and Floating DODAGs .......................18
3.2.5. Local DODAGs .......................................18
3.2.6. Administrative Preference ..........................18
3.2.7. Data-Path Validation and Loop Detection ............18
3.2.8. Distributed Algorithm Operation ....................19
3.3. Downward Routes and Destination Advertisement .............19
3.4. Local DODAGs Route Discovery ..............................20
3.5. Rank Properties ...........................................20
3.5.1. Rank Comparison (DAGRank()) ........................21
3.5.2. Rank Relationships .................................22
3.6. Routing Metrics and Constraints Used by RPL ...............23
3.7. Loop Avoidance ............................................24
3.7.1. Greediness and Instability .........................24
3.7.2. DODAG Loops ........................................26
3.7.3. DAO Loops ..........................................27
4. Traffic Flows Supported by RPL .................................27
4.1. Multipoint-to-Point Traffic ...............................27
4.2. Point-to-Multipoint Traffic ...............................27
4.3. Point-to-Point Traffic ....................................27
5. RPL Instance ...................................................28
5.1. RPL Instance ID ...........................................29
6. ICMPv6 RPL Control Message .....................................30
6.1. RPL Security Fields .......................................32
6.2. DODAG Information Solicitation (DIS) ......................38
6.2.1. Format of the DIS Base Object ......................38
6.2.2. Secure DIS .........................................38
6.2.3. DIS Options ........................................38
6.3. DODAG Information Object (DIO) ............................38
6.3.1. Format of the DIO Base Object ......................39
6.3.2. Secure DIO .........................................41
6.3.3. DIO Options ........................................41
6.4. Destination Advertisement Object (DAO) ....................41
6.4.1. Format of the DAO Base Object ......................42
6.4.2. Secure DAO .........................................43
6.4.3. DAO Options ........................................43
6.5. Destination Advertisement Object Acknowledgement
(DAO-ACK) .................................................43
6.5.1. Format of the DAO-ACK Base Object ..................44
6.5.2. Secure DAO-ACK .....................................45
6.5.3. DAO-ACK Options ....................................45
6.6. Consistency Check (CC) ....................................45
6.6.1. Format of the CC Base Object .......................46
6.6.2. CC Options .........................................47
6.7. RPL Control Message Options ...............................47
6.7.1. RPL Control Message Option Generic Format ..........47
6.7.2. Pad1 ...............................................48
6.7.3. PadN ...............................................48
6.7.4. DAG Metric Container ...............................49
6.7.5. Route Information ..................................50
6.7.6. DODAG Configuration ................................52
6.7.7. RPL Target .........................................54
6.7.8. Transit Information ................................55
6.7.9. Solicited Information ..............................58
6.7.10. Prefix Information ................................59
6.7.11. RPL Target Descriptor .............................63
7. Sequence Counters ..............................................63
7.1. Sequence Counter Overview .................................63
7.2. Sequence Counter Operation ................................64
8. Upward Routes ..................................................66
8.1. DIO Base Rules ............................................67
8.2. Upward Route Discovery and Maintenance ....................67
8.2.1. Neighbors and Parents within a DODAG Version .......67
8.2.2. Neighbors and Parents across DODAG Versions ........68
8.2.3. DIO Message Communication ..........................73
8.3. DIO Transmission ..........................................74
8.3.1. Trickle Parameters .................................75
8.4. DODAG Selection ...........................................75
8.5. Operation as a Leaf Node ..................................75
8.6. Administrative Rank .......................................76
9. Downward Routes ................................................77
9.1. Destination Advertisement Parents .........................77
9.2. Downward Route Discovery and Maintenance ..................78
9.2.1. Maintenance of Path Sequence .......................79
9.2.2. Generation of DAO Messages .........................79
9.3. DAO Base Rules ............................................80
9.4. Structure of DAO Messages .................................80
9.5. DAO Transmission Scheduling ...............................83
9.6. Triggering DAO Messages ...................................83
9.7. Non-Storing Mode ..........................................84
9.8. Storing Mode ..............................................85
9.9. Path Control ..............................................861. Introduction ✨
okay bestie, let's set the scene 🎀 Low-power and Lossy Networks (LLNs) are mostly made of constrained nodes, which means they have limited processing power, limited memory, and sometimes limited energy too (especially when they're battery operated or energy scavenging) 🔋. These routers are hooked together by lossy links that usually only support low data rates. They're kind of unstable, with relatively low packet delivery rates 💀.
Another vibe check: the traffic patterns aren't simply point-to-point. In a lot of cases it's point-to-multipoint or multipoint-to-point 🦋. And these networks may potentially have up to thousands of nodes 😭. So yeah, these characteristics give routing a unique set of challenges 🫶. The IETF ROLL working group defined application-specific routing requirements for an LLN routing protocol, specified in [RFC5867], [RFC5826], [RFC5673], and [RFC5548] 🧚.
This document specifies the IPv6 Routing Protocol for LLNs (RPL) ✨. Note that even though RPL was specified according to the requirements in those aforementioned requirement documents, its use is in no way limited to those applications 💅🌈.
1.1. Design Principles 🎀
okay so RPL was built to meet the requirements spelled out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. it's giving checklist energy 💅
A network can run multiple instances of RPL at the same time. Each instance might be serving different, and potentially antagonistic, constraints or performance criteria. This document only explains how a single instance operates ✨
To be useful across a wide range of LLN application domains, RPL separates packet processing and forwarding from the routing optimization objective. Those objectives can be stuff like minimizing energy, minimizing latency, or satisfying constraints. This document describes the mode of operation of RPL. Other companion documents specify routing Objective Functions, and an RPL implementation will include the Objective Function(s) an application needs 🦋
RPL operations need bidirectional links, and in some LLN scenarios those links can be asymmetric 👀 So the reachability of a router has to be verified before it can be used as a parent. RPL expects an external mechanism to kick in during the parent selection phase to check link properties and neighbor reachability. Neighbor Unreachability Detection (NUD) is one such mechanism, but there are alternatives too, including Bidirectional Forwarding Detection (BFD) [RFC5881] and hints from lower layers through Layer 2 (L2) triggers like [RFC5184]. Overall, a detection mechanism that reacts to traffic is favored, since that keeps the cost of monitoring links that aren't being used down 🌸
RPL also expects an external mechanism to access and transport some control information, called the "RPL Packet Information", in data packets. The RPL Packet Information is defined in Section 11.2, and it's what lets a data packet be associated with a RPL Instance and lets the RPL routing states get validated. The RPL option [RFC6553] is an example of such a mechanism. The mechanism is required for all packets except when strict source routing is used (that's packets going Downward in Non-Storing mode, as detailed further in Section 9). Strict source routing naturally prevents endless loops, so it doesn't need the RPL Packet Information at all 🔥 Future companion specifications may propose other ways to carry the RPL Packet Information in IPv6 packets, and may extend it to support additional features ✨
RPL provides a mechanism to disseminate information over the dynamically formed network topology. This is what lets nodes run with minimal configuration and operate mostly autonomously 🧚 The dissemination uses Trickle [RFC6206] to optimize things, as described in Section 8.3.
In some applications, RPL assembles topologies of routers that each own independent prefixes. Those prefixes may or may not be aggregatable, depending on where the routers came from. A prefix owned by a router is advertised as on-link 💜
RPL also introduces the ability to bind a subnet together with a common prefix and route within that subnet. A source can inject information about the subnet for RPL to disseminate, and that source is authoritative for the subnet. Since many LLN links have non-transitive properties, a common prefix that RPL disseminates over the subnet must not be advertised as on-link. Lowkey important, so don't skip it 🙈
In particular, RPL may disseminate IPv6 Neighbor Discovery (ND) information such as the [RFC4861] Prefix Information Option (PIO) and the [RFC4191] Route Information Option (RIO). That ND information keeps all its original semantics for router to host, with limited extensions for router to router. It is not to be confused with routing advertisements, and it is never to be directly redistributed in another routing protocol 🚫 A RPL node often combines host and router behaviors. As a host, it processes the options as specified in [RFC4191], [RFC4861], [RFC4862], and [RFC6275]. As a router, the RPL node may advertise the information from the options as required for the specific link, for instance in an ND Router Advertisement (RA) message. The exact operation is out of scope, though, so that's a plot twist for another day 🎬
A set of companion documents will provide further guidance in the form of applicability statements. These specify a set of operating points for the Building Automation, Home Automation, Industrial, and Urban application scenarios 🌈
1.2. Expectations of Link-Layer Type 🦋
So, in compliance with the layered architecture of IP, RPL doesn't rely on any particular features of a specific link-layer technology. Main character behavior 👑 It's designed to operate over a variety of link layers, including ones that are constrained, potentially lossy, or typically used with highly constrained host or router devices. Examples include, but aren't limited to, low-power wireless or PLC (Power Line Communication) technologies ⚡
Implementers may find [RFC3819] a useful reference when designing a link-layer interface between RPL and a particular link-layer technology 🧠
2. Terminology ✨
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
Okay so, this doc also uses terms from [ROLL-TERMS], and adds a bunch of its own. Let's get into it 🧚
- DAG: Directed Acyclic Graph. A directed graph where every edge is oriented so that no cycles exist. All edges sit on paths that point toward and end at one or more root nodes. 🌸
- DAG root: A DAG root is a node in the DAG that has no outgoing edge. Since the graph is acyclic, every DAG has to have at least one DAG root, and every path ends at a DAG root. 💖
- Destination-Oriented DAG (DODAG): A DAG rooted at a single destination, meaning one DAG root (the DODAG root) with no outgoing edges. 🎀
- DODAG root: The DAG root of a DODAG. It can act as a border router for the DODAG. In particular, it may aggregate routes in the DODAG and may redistribute DODAG routes into other routing protocols. 👑
- Virtual DODAG root: This is what you get when two or more RPL routers, for instance 6LoWPAN Border Routers (6LBRs), team up to sync DODAG state and act as if they're one single DODAG root (with multiple interfaces) as far as the LLN is concerned. The coordination most likely happens between powered devices over a reliable transit link, and the details of that scheme are out of scope for this spec (they'll be defined in future companion specs). 🫶
- Up: Up means the direction from leaf nodes toward DODAG roots, following DODAG edges. This follows the usual graph and depth-first-search terminology, where vertices further from the root are "deeper" or "down" and vertices closer to the root are "shallower" or "up". 🦋
- Down: Down means the direction from DODAG roots toward leaf nodes, the reverse of DODAG edges. Same graph vibes as Up: further from the root is "deeper" or "down", closer is "shallower" or "up". 🦋
- Rank: A node's Rank defines its individual position relative to other nodes with respect to a DODAG root. Rank strictly increases in the Down direction and strictly decreases in the Up direction. How Rank gets computed depends on the DAG's Objective Function (OF). Rank may track a simple topological distance, may be calculated from link metrics, and may consider other properties such as constraints. 📈
- Objective Function (OF): An OF defines how routing metrics, optimization objectives, and related functions get used to compute Rank. The OF also dictates how parents in the DODAG are selected, which means it shapes how the DODAG forms. ✨
- Objective Code Point (OCP): An OCP is an identifier that says which Objective Function the DODAG uses. 🔢
- RPLInstanceID: A RPLInstanceID is a unique identifier within a network. DODAGs with the same RPLInstanceID share the same Objective Function. 🆔
- RPL Instance: A RPL Instance is a set of one or more DODAGs that share a RPLInstanceID. A RPL node can belong to at most one DODAG in a RPL Instance. Each RPL Instance runs independently of the others. This document describes operation within a single RPL Instance. 🌈
- DODAGID: A DODAGID is the identifier of a DODAG root. It's unique within the scope of a RPL Instance in the LLN. The tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG. 🪪
- DODAG Version: A DODAG Version is one specific iteration ("Version") of a DODAG with a given DODAGID. 🌷
- DODAGVersionNumber: A DODAGVersionNumber is a sequential counter that the root increments to form a new Version of a DODAG. A DODAG Version is uniquely identified by the (RPLInstanceID, DODAGID, DODAGVersionNumber) tuple. 🔁
- Goal: The Goal is an application-specific goal defined outside the scope of RPL. Any node that roots a DODAG needs to know about this Goal so it can decide whether the Goal can be satisfied. A typical Goal is to build the DODAG according to a specific Objective Function and keep connectivity to a set of hosts. For example, you might use an OF that minimizes a metric and stays connected to a specific database host where the collected data gets stored. 🎯
- Grounded: A DODAG is grounded when the DODAG root can satisfy the Goal. 🌍
- Floating: A DODAG is floating if it isn't grounded. A floating DODAG isn't expected to have the properties needed to satisfy the Goal. It may, however, still provide connectivity to other nodes within the DODAG. 🎈
- DODAG parent: A parent of a node within a DODAG is one of the immediate successors of that node on a path toward the DODAG root. A DODAG parent's Rank is lower than the node's. (See Section 3.5.1). 👨👧
- Sub-DODAG: The sub-DODAG of a node is the set of other nodes whose paths to the DODAG root pass through that node. Nodes in the sub-DODAG of a node have a greater Rank than that node. (See Section 3.5.1). 🌳
- Local DODAG: Local DODAGs contain one and only one root node. That single root can allocate and manage a RPL Instance, identified by a local RPLInstanceID, without coordinating with other nodes. This is usually done to optimize routes to a destination within the LLN. (See Section 5). 🏠
- Global DODAG: A Global DODAG uses a global RPLInstanceID that may be coordinated among several other nodes. (See Section 5). 🌐
Quick abbreviation cheat sheet 📝
- DIO: DODAG Information Object (see Section 6.3)
- DAO: Destination Advertisement Object (see Section 6.4)
- DIS: DODAG Information Solicitation (see Section 6.2)
- CC: Consistency Check (see Section 6.6)
As they form networks, LLN devices often mix the roles of host and router compared to traditional IP networks. In this document, "host" means an LLN device that can generate but does not forward RPL traffic. "Router" means an LLN device that can forward as well as generate RPL traffic. "Node" means any RPL device, whether it's a host or a router. 🤝
3. Protocol Overview 🗺️
The aim of this section is to describe RPL in the spirit of [RFC4101]. Protocol details can be found in further sections. 💅
3.1. Topologies
This section describes the basic RPL topologies that may be formed, and the rules that build them, i.e., the rules governing DODAG formation. 🏗️
3.1.1. Constructing Topologies
LLNs, like Radio Networks, don't usually have predefined topologies, such as the ones imposed by point-to-point wires. So RPL has to discover links and then select peers sparingly. 📡
In many cases, because Layer 2 ranges overlap only partially, RPL forms non-transitive / Non-Broadcast Multi-Access (NBMA) network topologies, and it computes routes on top of them. 🕸️
RPL routes are optimized for traffic to or from one or more roots that act as sinks for the topology. So RPL organizes a topology as a Directed Acyclic Graph (DAG) that's partitioned into one or more Destination Oriented DAGs (DODAGs), with one DODAG per sink. If the DAG has multiple roots, the roots are expected to be federated by a common backbone, such as a transit link. 🦴
3.1.2. RPL Identifiers
RPL uses four values to identify and maintain a topology. 🔑
- The first is a RPLInstanceID. A RPLInstanceID identifies a set of one or more Destination Oriented DAGs (DODAGs). A network may have multiple RPLInstanceIDs, each defining an independent set of DODAGs that may be optimized for different Objective Functions (OFs) and/or applications. The set of DODAGs identified by a RPLInstanceID is called a RPL Instance. All DODAGs in the same RPL Instance use the same OF. 🌟
- The second is a DODAGID. The scope of a DODAGID is a RPL Instance. The combination of RPLInstanceID and DODAGID uniquely identifies a single DODAG in the network. A RPL Instance may have multiple DODAGs, each with a unique DODAGID. 🪪
- The third is a DODAGVersionNumber. The scope of a DODAGVersionNumber is a DODAG. A DODAG is sometimes reconstructed from the DODAG root by incrementing the DODAGVersionNumber. The combination of RPLInstanceID, DODAGID, and DODAGVersionNumber uniquely identifies a DODAG Version. 🔄
- The fourth is Rank. The scope of Rank is a DODAG Version. Rank establishes a partial order over a DODAG Version, defining individual node positions with respect to the DODAG root. 📊
3.1.3. Instances, DODAGs, and DODAG Versions 🦋
okay so a RPL Instance can hold one or more DODAG roots 🌸 It can give routes to certain destination prefixes, reachable through those roots or through alternate paths inside the DODAG 💅 The roots might run totally independently, or they can coordinate over a network that isn't necessarily as constrained as an LLN 🫶
A RPL Instance can look like any of these:
- a single DODAG with a single root ✨
- For example, a DODAG optimized to minimize latency, rooted at a single centralized lighting controller in a Home Automation application 💡
- multiple uncoordinated DODAGs with independent roots (differing DODAGIDs) 🌈
- For example, multiple data collection points in an urban data collection application that don't have suitable connectivity to coordinate with each other, or that use the formation of multiple DODAGs as a means to dynamically and autonomously partition the network 🧚
- a single DODAG with a virtual root that coordinates LLN sinks (with the same DODAGID) over a backbone network 👑
- For example, multiple border routers operating with a reliable transit link, e.g., in support of an IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) application, that are capable of acting as logically equivalent interfaces to the sink of the same DODAG 🍓
- a combination of the above, as suited to some application scenario 💜
Each RPL packet is associated with a particular RPLInstanceID (see Section 11.2) and, therefore, RPL Instance (Section 5). Provisioning, or automatically discovering, a mapping between a RPLInstanceID and a type or service of application traffic is out of scope for this specification. That stuff is going to be defined in future companion specifications 🙈
Figure 1 shows an example of a RPL Instance with three DODAGs, and DODAG roots R1, R2, and R3. Each of these DODAG roots advertises the same RPLInstanceID. The lines show connectivity between parents and children 🌸
Figure 2 shows how a DODAGVersionNumber increment leads to a new DODAG Version. This one is a DODAGVersionNumber increment that results in a different DODAG topology. Heads up, though: a new DODAG Version doesn't always mean a different DODAG topology 👀 To accommodate certain topology changes, you do need a new DODAG Version, as described later in this specification ✨
In the following examples, the DODAG structures are drawn as tree-like for simplicity. The DODAG structure allows each node to have multiple parents when the connectivity supports it, so just keep that in mind 🫶
+----------------------------------------------------------------+
| |
| +--------------+ |
| | | |
| | (R1) | (R2) (R3) |
| | / \ | /| \ / | \ |
| | / \ | / | \ / | \ |
| | (A) (B) | (C) | (D) ... (F) (G) (H) |
| | /|\ |\ | / | / |\ |\ | | |
| | : : : : : | : (E) : : : `: : |
| | | / \ |
| +--------------+ : : |
| DODAG |
| |
+----------------------------------------------------------------+
RPL Instance
Figure 1: RPL Instance
+----------------+ +----------------+
| | | |
| (R1) | | (R1) |
| / \ | | / |
| / \ | | / |
| (A) (B) | \ | (A) |
| /|\ / |\ | ------\ | /|\ |
| : : (C) : : | \ | : : (C) |
| | / | \ |
| | ------/ | \ |
| | / | (B) |
| | | |\ |
| | | : : |
| | | |
+----------------+ +----------------+
Version N Version N+1
Figure 2: DODAG Version3.2. Upward Routes and DODAG Construction 🌊
RPL sets up routes Up towards DODAG roots, forming a DODAG that's optimized according to an Objective Function (OF) ✨ RPL nodes build and keep these DODAGs going with DODAG Information Object (DIO) messages 💖
3.2.1. Objective Function (OF) 🎯
The Objective Function (OF) is how RPL nodes pick and optimize routes within a RPL Instance 💅 The OF is identified by an Objective Code Point (OCP) inside the DIO Configuration option. An OF defines how nodes translate one or more metrics and constraints (which are themselves defined in [RFC6551]) into a value called Rank. Rank roughly approximates how far a node is from a DODAG root 📏 An OF also defines how nodes select parents. For more details, check out Section 14, [RFC6551], [RFC6552], and related companion specifications 🤓
3.2.2. DODAG Repair 🔧
A DODAG root starts a global repair operation by incrementing the DODAGVersionNumber. That kicks off a new DODAG Version 🦋 Nodes in the new DODAG Version can pick a new position whose Rank isn't constrained by their Rank in the old DODAG Version. Main character glow-up energy 👑
RPL also supports mechanisms for local repair within the DODAG Version. The DIO message specifies the necessary parameters, which are configured from and controlled by policy at the DODAG root 🫶
3.2.3. Security 🔐
RPL supports message confidentiality and integrity 🛡️ It's designed so link-layer mechanisms can be used when they're available and appropriate, but when they aren't, RPL can use its own mechanisms ✨ RPL has three basic security modes.
In the first one, called "unsecured", RPL control messages get sent without any extra security mechanisms. Unsecured mode does not mean the RPL network is insecure, though. It could be using other security primitives (e.g., link-layer security) to meet application security requirements 🙌
The second one, called "preinstalled", is where nodes joining a RPL Instance have preinstalled keys that let them process and generate secured RPL messages 🔑
The third mode is called "authenticated". In authenticated mode, nodes have preinstalled keys just like in preinstalled mode, but that preinstalled key can only be used to join a RPL Instance as a leaf. Joining an authenticated RPL Instance as a router means you have to get a key from an authentication authority. How that key gets obtained is out of scope for this specification 🚫 Also, this specification alone does not give a RPL implementation enough detail to operate securely in authenticated mode. For an implementation to operate securely in authenticated mode, a future companion specification needs to detail how a node obtains or requests the authentication material (e.g., key, certificate) and figure out where that material should come from. See also Section 10.3 💀
3.2.4. Grounded and Floating DODAGs 🌈
DODAGs can be grounded or floating, and the DODAG root advertises which one it is ✨ A grounded DODAG offers connectivity to hosts that are required for satisfying the application-defined goal. A floating DODAG isn't expected to satisfy the goal; in most cases, it just provides routes to nodes within the DODAG. Floating DODAGs may be used, for example, to preserve interconnectivity during repair 🧚
3.2.5. Local DODAGs 📍
RPL nodes can optimize routes to a destination within an LLN by forming a Local DODAG whose DODAG root is the desired destination 🎯 Unlike global DAGs, which can consist of multiple DODAGs, local DAGs have one and only one DODAG and therefore one DODAG root. Local DODAGs can be constructed on demand 💅
3.2.6. Administrative Preference 👑
An implementation or deployment may specify that some DODAG roots should be used over others through an administrative preference. Administrative preference is a way to control traffic and engineer DODAG formation so it better supports application requirements or needs 🫶
3.2.7. Data-Path Validation and Loop Detection 🔁
The low-power and lossy nature of LLNs is why RPL uses on-demand loop detection using data packets 🔋 Data traffic can be infrequent, and keeping a routing topology constantly up to date with the physical topology can waste energy 😭 Typical LLNs have variations in physical connectivity that are transient and innocuous to traffic, but that would be costly to track closely from the control plane. Transient and infrequent changes in connectivity need not be addressed by RPL until there's data to send. This part of RPL's design draws from existing, highly used LLN protocols, as well as extensive experimental and deployment evidence on how well it works ✨
The RPL Packet Information that gets carried with data packets includes the Rank of the transmitter. An inconsistency between the routing decision for a packet (Upward or Downward) and the Rank relationship between the two nodes indicates a possible loop. When a node receives such a packet, it institutes a local repair operation 🚨
For example, if a node receives a packet flagged as moving in the Upward direction, and that packet records that the transmitter has a lower (lesser) Rank than the receiving node, then the receiving node can conclude that the packet hasn't progressed in the Upward direction and that the DODAG is inconsistent. Not the DODAG being inconsistent 😤
3.2.8. Distributed Algorithm Operation 🧠
Here's a high-level overview of the distributed algorithm that constructs the DODAG 💖
- Some nodes are configured to be DODAG roots, with associated DODAG configurations 👑
- Nodes advertise their presence, affiliation with a DODAG, routing cost, and related metrics by sending link-local multicast DIO messages to all-RPL-nodes 📣
- Nodes listen for DIOs and use their information to join a new DODAG (thus, selecting DODAG parents), or to maintain an existing DODAG, according to the specified Objective Function and Rank of their neighbors 👂
- Nodes provision routing table entries, for the destinations specified by the DIO message, via their DODAG parents in the DODAG Version. Nodes that decide to join a DODAG can provision one or more DODAG parents as the next hop for the default route and a number of other external routes for the associated instance 🗺️
3.3. Downward Routes and Destination Advertisement ✨
okay bestie, so RPL uses Destination Advertisement Object (DAO) messages to set up Downward routes 🌸. DAO messages are an optional feature for apps that need point-to-multipoint (P2MP) or point-to-point (P2P) traffic 💅. RPL supports two modes of Downward traffic: Storing (fully stateful) or Non-Storing (fully source routed), so peep Section 9 🦋. Any given RPL Instance is either storing or non-storing. In both cases, P2P packets travel Up toward a DODAG root and then Down to the final destination (unless the destination is on the Upward route) 🫶. In the Non-Storing case, the packet goes all the way to a DODAG root before it heads Down. In the Storing case, the packet may get directed Down toward the destination by a common ancestor of the source and the destination before it even reaches a DODAG root 😭.
As of writing this spec, no implementation is expected to support both Storing and Non-Storing modes of operation 💜. Most implementations are expected to support either no Downward routes, Non-Storing mode only, or Storing mode only. Other modes of operation, like a hybrid mix of Storing and Non-Storing mode, are out of scope for this spec and may be described in other companion specifications 🍓.
This spec describes a basic mode of operation in support of P2P traffic. More optimized P2P solutions may be described in companion specifications, so keep an eye out 🧚.
3.4. Local DODAGs Route Discovery 🌈
Optionally, an RPL network can support on-demand discovery of DODAGs to specific destinations within an LLN 🔍. These Local DODAGs act slightly differently than Global DODAGs. They are uniquely defined by the combination of DODAGID and RPLInstanceID, and the RPLInstanceID is what tells you whether a DODAG is a Local DODAG ✨.
3.5. Rank Properties 👑
The Rank of a node is a scalar representation of where that node sits within a DODAG Version 📍. Rank is used to avoid and detect loops, so it has to show off certain properties 💅. The exact calculation of Rank is left to the Objective Function. Even though the specific computation is left to the OF, Rank must implement generic properties no matter which Objective Function you use, because main character energy means it works everywhere 🎀.
Specifically, the Rank of the nodes must monotonically decrease as you follow the DODAG Version toward the DODAG destination. So Rank can be thought of as a scalar representation of a node's location, or its radius, within a DODAG Version 🌸.
How the Objective Function computes Rank is out of scope for this spec. That computation may depend on things like parents, link metrics, node metrics, and the node's configuration and policies. See Section 14 for more info 🧚.
Rank is not a path cost, although its value can be derived from and influenced by path metrics. Rank has its own properties, and they aren't necessarily the same as those of every metric:
- Type: The Rank is an abstract numeric value.
- Function: The Rank is the expression of a relative position within a DODAG Version with regard to neighbors. It is not necessarily a good indication or a proper expression of a distance or a path cost to the root 🙈.
- Stability: The stability of Rank determines the stability of the routing topology. Some dampening or filtering is RECOMMENDED to keep the topology stable, so Rank doesn't necessarily change as fast as some link or node metrics would. A new DODAG Version would be a good opportunity to reconcile the discrepancies that might form over time between metrics and Ranks within a DODAG Version 🫶.
- Properties: Rank is incremented in a strictly monotonic fashion, and it can be used to validate a progression from or towards the root. A metric, like bandwidth or jitter, doesn't necessarily have this property 💀.
- Abstract: Rank doesn't have a physical unit. Instead it has a range of increment per hop, and the Objective Function decides how each increment gets assigned 🌈.
The Rank value feeds into DODAG parent selection, following the RPL loop-avoidance strategy. Once a parent has been added and a Rank value for the node within the DODAG has been advertised, the node's further options for DODAG parent selection and movement within the DODAG get restricted, all in the name of loop avoidance 🔒.
3.5.1. Rank Comparison (DAGRank()) 🔢
Rank may be thought of as a fixed-point number, where the position of the radix point between the integer part and the fractional part is determined by MinHopRankIncrease. MinHopRankIncrease is the minimum increase in Rank between a node and any of its DODAG parents. A DODAG root provisions MinHopRankIncrease. It creates a trade-off between hop cost precision and the maximum number of hops a network can support. A very large MinHopRankIncrease, for example, lets you characterize a given hop's effect on Rank super precisely, but it can't support many hops 🍓.
When an Objective Function computes Rank, it operates on the entire (i.e., 16-bit) Rank quantity. When Rank is compared, e.g., for determining parent relationships or loop detection, the integer portion of the Rank is what gets used. The integer portion is computed by the DAGRank() macro as follows, where floor(x) is the function that evaluates to the greatest integer less than or equal to x 🧮:
DAGRank(rank) = floor(rank/MinHopRankIncrease)For example, if a 16-bit Rank quantity is decimal 27 and MinHopRankIncrease is decimal 16, then DAGRank(27) = floor(1.6875) = 1. The integer part of the Rank is 1 and the fractional part is 11/16 ✨.
Following the conventions in this document, using the macro DAGRank(node) may be interpreted as DAGRank(node.rank), where node.rank is the Rank value as maintained by the node 💖.
A Node A has a Rank less than the Rank of a Node B if DAGRank(A) is less than DAGRank(B).
A Node A has a Rank equal to the Rank of a Node B if DAGRank(A) is equal to DAGRank(B).
A Node A has a Rank greater than the Rank of a Node B if DAGRank(A) is greater than DAGRank(B).
3.5.2. Rank Relationships 💞
Rank computations keep the following properties for any nodes M and N that are neighbors in the LLN 🫧:
DAGRank(M) is less than DAGRank(N): Here, M is closer to the DODAG root than N. Node M can safely be a DODAG parent for Node N without risk of creating a loop 🙌. Also, for a Node N, every parent in the DODAG parent set has to have a Rank less than DAGRank(N). Put another way, the Rank presented by a Node N MUST be greater than that presented by any of its parents 👑.
DAGRank(M) equals DAGRank(N): Here, the positions of M and N within the DODAG, and with respect to the DODAG root, are similar or identical. Routing through a node with equal Rank may cause a routing loop (i.e., if that node chooses to route through a node with equal Rank as well) 😬.
DAGRank(M) is greater than DAGRank(N): Here, M is farther from the DODAG root than N. Node M may actually be in the sub-DODAG of Node N. If Node N selects Node M as its DODAG parent, there is a risk of creating a loop 🚨.
As an example, Rank could be computed so that it closely tracks ETX (expected transmission count, a fairly common routing metric used in LLNs and defined in [RFC6551]) when the metric an Objective Function minimizes is ETX. It could also track latency, or be computed in a more complicated way as appropriate to the Objective Function being used within the DODAG 🦋.
3.6. Routing Metrics and Constraints Used by RPL 📊
Routing metrics are used by routing protocols to compute shortest paths. Interior Gateway Protocols (IGPs) such as IS-IS ([RFC5120]) and OSPF ([RFC4915]) use static link metrics. Such link metrics can simply reflect the bandwidth, or they can be computed according to a polynomial function of several metrics defining different link characteristics. Some routing protocols support more than one metric, but in the vast majority of cases one metric is used per (sub-)topology. Less often, a second metric may be used as a tiebreaker in the presence of Equal Cost Multiple Paths (ECMPs). Optimizing multiple metrics is known as an NP-complete problem, and it's sometimes handled by a centralized path computation engine 🧠.
In contrast, LLNs do require support for both static and dynamic metrics. Furthermore, both link and node metrics are required. In the case of RPL, it is virtually impossible to define one metric, or even a composite metric, that will satisfy all use cases 🥲.
RPL also supports constraint-based routing, where constraints may be applied to both links and nodes. If a link or a node doesn't satisfy a required constraint, it gets "pruned" from the candidate neighbor set, which leads to a constrained shortest path ✂️.
An Objective Function specifies the objectives used to compute the (constrained) path. Nodes are configured to support a set of metrics and constraints, and they select their parents in the DODAG according to the metrics and constraints advertised in DIO messages 🎯. Upstream and Downstream metrics may be merged or advertised separately, depending on the OF and the metrics. When they're advertised separately, the set of DIO parents can end up different from the set of DAO parents (a DAO parent is a node to which unicast DAO messages are sent). Still, all of them are DODAG parents under the rules for Rank computation 🫶.
The Objective Function is decoupled from the routing metrics and constraints used by RPL. The OF dictates things like DODAG parent selection, load balancing, and so on, while the set of metrics and/or constraints, which determines the preferred path, is based on the information carried within the DAG container option in DIO messages 💅.
The set of supported link/node constraints and metrics is specified in [RFC6551] 📘.
Example 1 and Example 2 look like this:
Example 1: Shortest path: path offering the shortest end-to-end
delay.
Example 2: Shortest Constrained path: the path that does not traverse
any battery-operated node and that optimizes the path
reliability.3.7. Loop Avoidance 🔁
RPL tries to avoid creating loops when undergoing topology changes. It also includes Rank-based data-path validation mechanisms for detecting loops when they do happen (see Section 11 for more details) 🕵️♀️. In practice, this means RPL guarantees neither loop-free path selection nor tight delay convergence times. What it can do is detect and repair a loop as soon as it gets used. RPL uses this loop detection to make sure packets keep making forward progress within the DODAG Version, and to trigger repairs when they're needed 🌸.
3.7.1. Greediness and Instability
Okay bestie, so a node is greedy if it tries to move deeper (increase its Rank) inside the DODAG Version just to grow its parent set or to score better on some other metric 👀. Once a node has joined a DODAG Version, RPL says no to certain behaviors, greediness very much included, so the DODAG Version doesn't get unstable 🫶.
Suppose a node is willing to receive and process a DIO message from a node in its own sub-DODAG, or more generally from a node deeper than itself. Now a feedback loop is possible 😬, where two or more nodes keep trying to move around the DODAG Version while optimizing against each other. In some cases this ends in instability. That's why RPL only allows a node to process DIO messages from deeper nodes as some form of local repair. This creates an "event horizon" 🌌, which means a node can't be pushed past a certain limit into instability by nodes that might be in its own sub-DODAG.
3.7.1.1. Example: Greedy Parent Selection and Instability
(A) (A) (A)
|\ |\ |\
| `-----. | `-----. | `-----.
| \ | \ | \
(B) (C) (B) \ | (C)
\ | | /
`-----. | | .-----'
\| |/
(C) (B)
-1- -2- -3-
Figure 3: Greedy DODAG Parent SelectionFigure 3 shows one DODAG in three different setups 🧩. There's a usable link between (B) and (C) in all three. In Figure 3-1, Node (A) is a DODAG parent for Nodes (B) and (C). In Figure 3-2, Node (A) is still a DODAG parent for Nodes (B) and (C), and Node (B) is also a DODAG parent for Node (C). In Figure 3-3, Node (A) is a DODAG parent for Nodes (B) and (C), and Node (C) is also a DODAG parent for Node (B).
If a RPL node is too greedy, meaning it tries to optimize for extra parents beyond its most preferred ones, an instability can happen 💀. Look at the DODAG in Figure 3-1. Nodes (B) and (C) may most prefer Node (A) as a DODAG parent, but let's check what happens when they're operating under the greedy condition and trying to optimize for two parents.
- Let Figure 3-1 be the initial condition.
- Suppose Node (C) first leaves the DODAG and rejoins at a lower Rank, taking both Nodes (A) and (B) as DODAG parents, as shown in Figure 3-2. Now Node (C) is deeper than both Nodes (A) and (B), and Node (C) is happy with two DODAG parents.
- Suppose Node (B), in its greediness, is willing to receive and process a DIO message from Node (C) (against the rules of RPL), and then Node (B) leaves the DODAG and rejoins at a lower Rank, taking both Nodes (A) and (C) as DODAG parents. Now Node (B) is deeper than both Nodes (A) and (C) and is satisfied with two DAG parents.
- Then, Node (C), because it is also greedy, will leave and rejoin deeper, to again get two parents and have a lower Rank than both of them.
- Next, Node (B) will again leave and rejoin deeper, to again get two parents.
- Again, Node (C) leaves and rejoins deeper.
- The process will repeat, and the DODAG will oscillate between Figure 3-2 and Figure 3-3 until the nodes count to infinity and restart the cycle again 🔁.
- This cycle can be averted through mechanisms in RPL:
- Nodes (B) and (C) stay at a Rank sufficient to attach to their most preferred parent (A) and don't go for any deeper (worse) alternate parents (Nodes are not greedy).
- Nodes (B) and (C) do not process DIO messages from nodes deeper than themselves (because such nodes are possibly in their own sub-DODAGs).
These mechanisms are further described in Section 8.2.2.4 🙌.
3.7.2. DODAG Loops
A DODAG loop may occur when a node detaches from the DODAG and reattaches to a device in its prior sub-DODAG 🌀. This can especially happen when DIO messages are missed. Strict use of the DODAGVersionNumber can eliminate this type of loop, but this type of loop may possibly still be encountered when using some local repair mechanisms.
For example, consider the local repair mechanism that lets a node detach from the DODAG, advertise a Rank of INFINITE_RANK (to poison its routes / inform its sub-DODAG), and then reattach to the DODAG. In some of these cases, the node may reattach to its own prior sub-DODAG and cause a DODAG loop, because the poisoning may fail if the INFINITE_RANK advertisements get lost in the LLN environment 📉. (In that case, the Rank-based data-path validation mechanisms would eventually detect the loop and trigger its correction ✅.)
3.7.3. DAO Loops
A DAO loop may occur when the parent has a route installed after receiving and processing a DAO message from a child, but the child has since cleaned up the related DAO state 🫠. This loop happens when a No-Path (a DAO message that invalidates a previously announced prefix, see Section 6.4.3) gets missed, and it persists until all the state has been cleaned up. RPL includes an optional mechanism to acknowledge DAO messages, which may soften the impact of a single missed DAO message. RPL also includes loop detection mechanisms that reduce the impact of DAO loops and trigger their repair (see Section 11.2.2.3) 💪.
4. Traffic Flows Supported by RPL ✨
RPL supports three basic traffic flows: multipoint-to-point (MP2P), point-to-multipoint (P2MP), and point-to-point (P2P) 🦋.
4.1. Multipoint-to-Point Traffic
Multipoint-to-point (MP2P) is a dominant traffic flow in many LLN applications ([RFC5867], [RFC5826], [RFC5673], and [RFC5548]) 📥. The destinations of MP2P flows are designated nodes with some application significance, such as ones that provide connectivity to the larger Internet or a core private IP network 🌐. RPL supports MP2P traffic by letting MP2P destinations be reached via DODAG roots 👑.
4.2. Point-to-Multipoint Traffic
Point-to-multipoint (P2MP) is a traffic pattern required by several LLN applications ([RFC5867], [RFC5826], [RFC5673], and [RFC5548]) 📤. RPL supports P2MP traffic with a destination advertisement mechanism that sets up Down routes toward destinations (prefixes, addresses, or multicast groups), going away from the roots 🌳. Destination advertisements can update routing tables as the underlying DODAG topology changes 🔄.
4.3. Point-to-Point Traffic
RPL DODAGs give point-to-point (P2P) traffic a basic structure 🧸. For an RPL network to support P2P traffic, a root must be able to route packets to a destination. Nodes in the network may also have routing tables to destinations. A packet flows toward a root until it reaches an ancestor that has a known route to the destination 🎯. As pointed out later in this document, in the most constrained case (when nodes cannot store routes), that common ancestor may be the DODAG root. In other cases, it may be a node closer to both the source and the destination.
RPL also supports the case where a P2P destination is a 'one-hop' neighbor 💕.
RPL neither specifies nor precludes additional mechanisms for computing and installing potentially more optimal routes to support arbitrary P2P traffic 🤷♀️.
5. RPL Instance 🎀
Within a given LLN, there may be multiple, logically independent RPL Instances 🧩. An RPL node may belong to multiple RPL Instances, and it may act as a router in some and as a leaf in others. This document describes how a single instance behaves.
There are two types of RPL Instances: Local and Global 💜. RPL divides the RPLInstanceID space between Global and Local instances to allow for both coordinated and unilateral allocation of RPLInstanceIDs. Global RPL Instances are coordinated, have one or more DODAGs, and are typically long-lived. Local RPL Instances are always a single DODAG whose singular root owns the corresponding DODAGID and allocates the local RPLInstanceID unilaterally. Local RPL Instances can be used, for example, for constructing DODAGs in support of a future on-demand routing solution 🔮. The mode of operation of Local RPL Instances is out of scope for this specification and may be described in other companion specifications.
The definition and provisioning of RPL Instances are out of scope for this specification 🙅♀️. Guidelines may be application and implementation specific, and they are expected to be elaborated in future companion specifications. Those operations are expected to be such that data packets coming from outside the RPL network can unambiguously be associated with at least one RPL Instance, and can be safely routed over any instance that would match the packet 📦.
Control and data packets within the RPL network are tagged to unambiguously identify which RPL Instance they are a part of 🏷️.
Every RPL control message has an RPLInstanceID field 🪪. Some RPL control messages, when referring to a local RPLInstanceID as defined below, may also include a DODAGID.
Data packets that flow within the RPL network expose the RPLInstanceID as part of the RPL Packet Information that RPL requires, as further described in Section 11.2 💅. For data packets coming from outside the RPL network, the ingress router determines the RPLInstanceID and places it into the resulting packet that it injects into the RPL network 🚪.
5.1. RPL Instance ID ✨
Okay bestie, so a global RPLInstanceID MUST be unique to the whole LLN 💖 The way to hand these out and set them up is out of scope for this spec, so we're leaving that alone 🙈 A whole network can have up to 128 Global instances 🌈 Local instances always hang out with a DODAGID (sometimes it's given directly, sometimes it's implied), and each DODAGID can support up to 64 Local instances 🫶 The node that owns the DODAGID handles its Local instances, and nobody has to coordinate with anyone else. Iconic independence 💅
A global RPLInstanceID lives in an RPLInstanceID field like this:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|0| ID | Global RPLInstanceID in 0..127
+-+-+-+-+-+-+-+-+Figure 4: RPLInstanceID Field Format for Global Instances
A local RPLInstanceID gets autoconfigured by the node that owns the DODAGID 🦋 It MUST be unique for that DODAGID. The DODAGID used to set it up MUST be a reachable IPv6 address of the node, and that address MUST be used as an endpoint of all communications within that Local instance. Main character energy for that IPv6 address 👑
A local RPLInstanceID is encoded in an RPLInstanceID field like so:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|1|D| ID | Local RPLInstanceID in 0..63
+-+-+-+-+-+-+-+-+Figure 5: RPLInstanceID Field Format for Local Instances
The 'D' flag in a local RPLInstanceID is always set to 0 in RPL control messages 🌸 It only matters in data packets, where it tells you whether the DODAGID is the source or the destination. If 'D' is set to 1, then the destination address of the IPv6 packet MUST be the DODAGID. If 'D' is cleared, then the source address of the IPv6 packet MUST be the DODAGID. It's giving very precise bit energy 🧚
Let's say Node A is the DODAG root of a Local RPL Instance and has allocated a local RPLInstanceID 💜 By definition, all traffic in that Local RPL Instance either starts at Node A or ends at Node A. So the DODAGID is Node A's reachable IPv6 address, and every packet carries that address as either its source or its destination. That means the local RPLInstanceID can say the DODAGID is the source or the destination just by setting the 'D' flag the right way. Periodt 🍓
6. ICMPv6 RPL Control Message 🎀
Here's the RPL control message, which is a brand-new ICMPv6 message [RFC4443] 💅 Each one is identified by a code, and it's made of a base (whose shape depends on the code) plus a bunch of optional extras.
Most RPL control messages only care about their own link 🔗 The one exception is DAO and DAO-ACK messages in Non-Storing mode. Those get exchanged over a unicast address across multiple hops, so they use global or unique-local addresses for both the source and destination. For everything else, the source is a link-local address, and the destination is either the all-RPL-nodes multicast address or a link-local unicast address of the destination. That all-RPL-nodes multicast address is brand new, with the value ff02::1a ✨
Following [RFC4443], the RPL Control Message is an ICMPv6 header followed by a message body. The body has a message base and possibly some options, as shown in Figure 6 🦋
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Base .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Option(s) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: RPL Control Message
The RPL control message is an ICMPv6 information message with a Type of 155 🌟
The Code field tells you which type of RPL control message you're looking at. This document defines codes for these RPL control message types (see Section 20.2)):
0x00: DODAG Information Solicitation (Section 6.2)0x01: DODAG Information Object (Section 6.3)0x02: Destination Advertisement Object (Section 6.4)0x03: Destination Advertisement Object Acknowledgment (Section 6.5)0x80: Secure DODAG Information Solicitation (Section 6.2.2)0x81: Secure DODAG Information Object (Section 6.3.2)0x82: Secure Destination Advertisement Object (Section 6.4.2)0x83: Secure Destination Advertisement Object Acknowledgment (Section 6.5.2)0x8A: Consistency Check (Section 6.6)
If a node gets a RPL control message with a Code field it doesn't recognise 💀 it MUST discard the message without any further processing, it MAY raise a management alert, and it MUST NOT send any messages in response. Ghosted, no reply 🙅
The checksum is computed as specified in [RFC4443]. It's set to zero for the RPL security operations below, and it gets computed once the rest of the RPL message, including the security fields, is all set 🔐
The high order bit (0x80) of the code tells you whether the RPL message has security enabled. Secure RPL messages have a format that supports confidentiality and integrity, as shown in Figure 7 🛡️
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 | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Security .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Base .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Option(s) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: Secure RPL Control Message
The rest of this section walks through the currently defined RPL control message Base formats, and then the currently defined RPL Control Message options 💖
6.1. RPL Security Fields ✨
okay so every RPL message has a secure version 🔐 and the secure ones give you integrity and replay protection, plus optional confidentiality and delay protection 💖 Because security covers the base message and the options, the security info sits between the checksum and the base in secured messages, just like in Figure 8 🎀
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved | Algorithm |KIM|Resvd| LVL | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Identifier .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Security Sectionthe way the security stuff works is kinda layered 🧁 MACs and signatures cover the whole unsecured ICMPv6 RPL control message, including every field in the Security section, but with the ICMPv6 checksum temporarily set to zero 🙈 Encryption then covers the secured RPL ICMPv6 message from the first byte after the Security section all the way to the last byte of the packet 🔒 The security transformation gives you a secured ICMPv6 RPL message once the cryptographic fields (MAC, signature, etc.) are added in. In other words, the transformation itself (like the Signature and/or Algorithm in use) is what tells you how to fold those cryptographic fields into the secured packet 💅 The Security section doesn't actually carry those cryptographic fields itself. And you'll find more on using the Security section in Sections 19 and 10 🦋
Counter is Time (T): If the counter's Time flag is set, then the Counter field is a timestamp ⏰ If the flag is cleared, the counter is an incrementing counter ✨ Section 10.5 has all the deets on the 'T' flag and Counter field 🌸
Reserved: this is a 7-bit unused field 🫧 The field MUST be initialized to zero by the sender and MUST be ignored by the receiver 🤍
Security Algorithm (Algorithm): The Security Algorithm field tells everyone which encryption, MAC, and signature scheme the network is using 👑 These are the supported values:
+-----------+-------------------+------------------------+
| Algorithm | Encryption/MAC | Signature |
+-----------+-------------------+------------------------+
| 0 | CCM with AES-128 | RSA with SHA-256 |
| 1-255 | Unassigned | Unassigned |
+-----------+-------------------+------------------------+
Figure 9: Security Algorithm (Algorithm) EncodingSection 10.9 goes deeper on the algorithms 🧚
Key Identifier Mode (KIM): this is a 2-bit field that tells you whether the key used for packet protection is determined implicitly or explicitly, and it also shows which representation of the Key Identifier field you're looking at 🎀 You pick one of the values from this table:
+------+-----+-----------------------------+------------+
| Mode | KIM | Meaning | Key |
| | | | Identifier |
| | | | Length |
| | | | (octets) |
+------+-----+-----------------------------+------------+
| 0 | 00 | Group key used. | 1 |
| | | Key determined by Key Index | |
| | | field. | |
| | | | |
| | | Key Source is not present. | |
| | | Key Index is present. | |
+------+-----+-----------------------------+------------+
| 1 | 01 | Per-pair key used. | 0 |
| | | Key determined by source | |
| | | and destination of packet. | |
| | | | |
| | | Key Source is not present. | |
| | | Key Index is not present. | |
+------+-----+-----------------------------+------------+
| 2 | 10 | Group key used. | 9 |
| | | Key determined by Key Index | |
| | | and Key Source Identifier. | |
| | | | |
| | | Key Source is present. | |
| | | Key Index is present. | |
+------+-----+-----------------------------+------------+
| 3 | 11 | Node's signature key used. | 0/9 |
| | | If packet is encrypted, |
| | | it uses a group key, Key | |
| | | Index and Key Source | |
| | | specify key. | |
| | | | |
| | | Key Source may be present. | |
| | | Key Index may be present. | |
+------+-----+-----------------------------+------------+
Figure 10: Key Identifier Mode (KIM) EncodingIn Mode 3 (KIM=11), whether the Key Source and Key Identifier show up depends on the Security Level (LVL) below 🧩 If the Security Level says there's encryption, those fields are there. If it says there's no encryption, they're not 💀
Resvd: this is another 3-bit unused field 🌈 The field MUST be initialized to zero by the sender and MUST be ignored by the receiver 🫶
Security Level (LVL): This is a 3-bit field that says what packet protection you're getting 🛡️ It can change from packet to packet, and it gives you different levels of data authenticity and, optionally, data confidentiality 💜 The KIM field tells you whether signatures are used and what the Level field means. Heads up that the assigned Security Level values aren't necessarily ordered, so a higher LVL doesn't automatically mean more security 😭 Here's how it's set:
+---------------------------+
| KIM=0,1,2 |
+-------+--------------------+------+
| LVL | Attributes | MAC |
| | | Len |
+-------+--------------------+------+
| 0 | MAC-32 | 4 |
| 1 | ENC-MAC-32 | 4 |
| 2 | MAC-64 | 8 |
| 3 | ENC-MAC-64 | 8 |
| 4-7 | Unassigned | N/A |
+-------+--------------------+------+
+---------------------+
| KIM=3 |
+-------+---------------+-----+
| LVL | Attributes | Sig |
| | | Len |
+-------+---------------+-----+
| 0 | Sign-3072 | 384 |
| 1 | ENC-Sign-3072 | 384 |
| 2 | Sign-2048 | 256 |
| 3 | ENC-Sign-2048 | 256 |
| 4-7 | Unassigned | N/A |
+-------+---------------+-----+
Figure 11: Security Level (LVL) EncodingThe MAC attribute means the message has a MAC of the length shown ✨ ENC means the message is encrypted 🔐 Sign means the message has a signature of the specified length 🖋️
Flags: this is an 8-bit unused field that's reserved for flags 🎈 The field MUST be initialized to zero by the sender and MUST be ignored by the receiver 💗
Counter: The Counter field holds the non-repeating 4-octet value used to build the cryptographic mechanism that does the packet protection, and it's what lets you get semantic security 🧁 See Section 10.9.1 🦋
Key Identifier: This one tells you which key protected the packet 🗝️ It covers a bunch of granularity levels, like peer-to-peer keys, group keys, and signature keys. It's shaped by the Key Identifier Mode field and laid out like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Source .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Key Index .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Key IdentifierKey Source: The Key Source field, when it's there, tells you the logical identifier of whoever originated a group key 👑 When it's present, it's 8 bytes long 🌸
Key Index: The Key Index field, when it's there, lets you tell apart different keys that come from the same originator 🔑 Each key originator has to make sure that the actively used keys it issues have distinct key indices, and that every key index is unequal to 0x00 🫧 The value 0x00 is reserved for a preinstalled, shared key 🌟 When it's present, this field is 1 byte long 🍓
Okay, bestie, this is a big one: the unassigned bits of the Security section are reserved. They MUST be set to zero on transmission and MUST be ignored on reception 🚨
6.2. DODAG Information Solicitation (DIS)
the DODAG Information Solicitation (DIS) message is a way to ask for a DODAG Information Object from an RPL node 🙋♀️ It's kinda like a Router Solicitation from IPv6 Neighbor Discovery, so a node can use DIS to poke around its neighborhood and look for nearby DODAGs 🧚 Section 8.3 explains how nodes respond to a DIS 💅
6.2.1. Format of the DIS Base Object ✨
okay so the DIS base object is literally the simplest message in the whole RPL family, bestie 💅 it's just a flags byte, a reserved byte, and then optional options hanging off the end 🎀
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Option(s)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: The DIS Base Object
Flags is an 8-bit field that's unused and reserved for flags. The sender MUST initialize it to zero, and the receiver MUST ignore it 🙈
Reserved is another 8-bit unused field. Same deal: the sender MUST set it to zero, and the receiver MUST ignore it 🌸
Any unassigned bits in the DIS Base are reserved too. They MUST be set to zero on transmission and MUST be ignored on reception. Ngl, this is giving "don't touch what you don't understand" energy and I'm here for it 🫶
6.2.2. Secure DIS
A Secure DIS message follows the format in Figure 7, where the base format is the DIS message shown in Figure 13. So it's the same main character, just with the security fit on top 🔐✨
6.2.3. DIS Options
The DIS message MAY carry valid options. So options are totally optional, no pressure 🦋
This specification allows the DIS message to carry these options:
0x00 Pad1
0x01 PadN
0x07 Solicited Information6.3. DODAG Information Object (DIO) 👑
okay the DODAG Information Object is the big popular one, iykyk 💖 It carries the info that lets a node discover an RPL Instance, learn its configuration parameters, pick a DODAG parent set, and keep the DODAG maintained. It's basically the whole group chat update in one message 💬
6.3.1. Format of the DIO Base Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |Version Number | Rank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|G|0| MOP | Prf | DTSN | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+Figure 14: The DIO Base Object
Grounded (G): the Grounded 'G' flag tells you whether the advertised DODAG can satisfy the application-defined goal. If the flag is set, the DODAG is grounded. If it's cleared, the DODAG is floating 🌈
Mode of Operation (MOP): this field identifies the mode of operation of the RPL Instance, as administratively provisioned at and distributed by the DODAG root. Every node who joins the DODAG must be able to honor the MOP in order to fully participate as a router. Otherwise, it has to join only as a leaf. The MOP is encoded like this:
+-----+-----------------------------------------------------+
| MOP | Description |
+-----+-----------------------------------------------------+
| 0 | No Downward routes maintained by RPL |
| 1 | Non-Storing Mode of Operation |
| 2 | Storing Mode of Operation with no multicast support |
| 3 | Storing Mode of Operation with multicast support |
| | |
| | All other values are unassigned |
+-----+-----------------------------------------------------+A value of 0 means destination advertisement messages are disabled, and the DODAG only maintains Upward routes. Basically no Downward routes for you 🙃
Figure 15: Mode of Operation (MOP) Encoding
DODAGPreference (Prf): a 3-bit unsigned integer that defines how preferable the root of this DODAG is compared to other DODAG roots within the instance. DAGPreference ranges from 0x00 (least preferred) to 0x07 (most preferred). The default is 0, which is least preferred. Section 8.2 describes how DAGPreference affects DIO processing 👀
Version Number: an 8-bit unsigned integer set by the DODAG root to the DODAGVersionNumber. Section 8.2 describes the rules for DODAGVersionNumbers and how they affect DIO processing. Version drama is real 💅
Rank: a 16-bit unsigned integer indicating the DODAG Rank of the node sending the DIO message. Section 8.2 describes how Rank is set and how it affects DIO processing 🧚
RPLInstanceID: an 8-bit field set by the DODAG root that indicates which RPL Instance the DODAG is part of 🌸
Destination Advertisement Trigger Sequence Number (DTSN): an 8-bit unsigned integer set by the node issuing the DIO message. The DTSN flag is used as part of the procedure to maintain Downward routes. The details are in Section 9 ✨
Flags: an 8-bit unused field reserved for flags. The sender MUST initialize it to zero, and the receiver MUST ignore it 🙈
Reserved: an 8-bit unused field. The sender MUST initialize it to zero, and the receiver MUST ignore it 🍓
DODAGID: a 128-bit IPv6 address set by a DODAG root that uniquely identifies a DODAG. The DODAGID MUST be a routable IPv6 address belonging to the DODAG root. No fake addresses allowed, periodt 💜
Any unassigned bits in the DIO Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception 🦋
6.3.2. Secure DIO
A Secure DIO message follows the format in Figure 7, where the base format is the DIO message shown in Figure 14. Same vibe as the Secure DIS, just with the DIO outfit on 🔐
6.3.3. DIO Options
The DIO message MAY carry valid options. Totally optional, so no stress 🌈
This specification allows the DIO message to carry these options:
0x00 Pad1
0x01 PadN
0x02 DAG Metric Container
0x03 Routing Information
0x04 DODAG Configuration
0x08 Prefix Information6.4. Destination Advertisement Object (DAO) 📣
The Destination Advertisement Object (DAO) is how destination info gets propagated Upward along the DODAG. In Storing mode, the child unicasts the DAO message to its selected parent(s). In Non-Storing mode, the DAO message is unicast to the DODAG root. The DAO message may optionally, upon explicit request or error, be acknowledged by its destination with a Destination Advertisement Acknowledgement (DAO-ACK) message sent back to the DAO's sender 💌
6.4.1. Format of the DAO Base Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |K|D| Flags | Reserved | DAOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID* +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+The '*' means the DODAGID isn't always present, as described below 👀
Figure 16: The DAO Base Object
RPLInstanceID: an 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO 🌸
K: the 'K' flag indicates that the recipient is expected to send a DAO-ACK back. (See Section 9.3.) Ack please 🫶
D: the 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used. No skipping it, bestie 💅
Flags: the 6 bits left unused in the Flags field are reserved for flags. The sender MUST initialize the field to zero, and the receiver MUST ignore it 🙈
Reserved: an 8-bit unused field. The sender MUST initialize it to zero, and the receiver MUST ignore it 🍓
DAOSequence: incremented at each unique DAO message from a node, and echoed in the DAO-ACK message 🔁
DODAGID (optional): a 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field is only present when the 'D' flag is set. It's typically only present when a local RPLInstanceID is in use, so you can identify the DODAGID associated with that RPLInstanceID. When a global RPLInstanceID is in use, this field need not be present 🧚
Any unassigned bits in the DAO Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception 🦋
6.4.2. Secure DAO
A Secure DAO message follows the format in Figure 7, where the base format is the DAO message shown in Figure 16. Same security fit, new base 🔐✨
6.4.3. DAO Options
The DAO message MAY carry valid options. Optional but iconic 👑
This specification allows the DAO message to carry these options:
0x00 Pad1
0x01 PadN
0x05 RPL Target
0x06 Transit Information
0x09 RPL Target DescriptorA special case of the DAO message, called a No-Path, is used in Storing mode to clear Downward routing state that was provisioned through DAO operation. The No-Path carries a Target option and an associated Transit Information option with a lifetime of 0x00000000, which signals a loss of reachability to that Target. That's the "unfollow" of RPL 💀
6.5. Destination Advertisement Object Acknowledgement (DAO-ACK) 🫶
The DAO-ACK message is sent as a unicast packet by a DAO recipient (a DAO parent or DODAG root) in response to a unicast DAO message. It's the "got it, thanks" reply, and it's lowkey so important 💖
6.5.1. Format of the DAO-ACK Base Object ✨
okay bestie, this is the DAO-ACK Base Object 💌 It's the reply that says "got your DAO, we're good" (or, sometimes, "nah, find someone else" 💀). Here's the layout:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |D| Reserved | DAOSequence | Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID* +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
The '*' denotes that the DODAGID is not always present, as described
below.
Figure 17: The DAO ACK Base ObjectThe * on DODAGID means it isn't always there, so read on 👀
RPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO.D: The 'D' flag indicates that the DODAGID field is present. This would typically only be set when a local RPLInstanceID is used.Reserved: The 7-bit field, reserved for flags.DAOSequence: Incremented at each DAO message from a node, and echoed in the DAO-ACK by the recipient. The DAOSequence is used to correlate a DAO message and a DAO ACK message and is not to be confused with the Transit Information option Path Sequence that is associated to a given Target Down the DODAG. (don't mix these two up, they're totally different vibes 🙅♀️)Status: Indicates the completion. Status 0 is defined as unqualified acceptance in this specification. The remaining status values are reserved as rejection codes. No rejection status codes are defined in this specification, although status codes SHOULD be allocated according to the following guidelines in future specifications:
0: Unqualified acceptance (i.e., the node receiving the
DAO-ACK is not rejected).
1-127: Not an outright rejection; the node sending the DAO-ACK
is willing to act as a parent, but the receiving node is
suggested to find and use an alternate parent instead.
127-255: Rejection; the node sending the DAO-ACK is unwilling to
act as a parent.DODAGID(optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG. This field is only present when the 'D' flag is set. Typically, this field is only present when a local RPLInstanceID is in use in order to identify the DODAGID that is associated with the RPLInstanceID. When a global RPLInstanceID is in use, this field need not be present.
Unassigned bits of the DAO-ACK Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. 🫶
6.5.2. Secure DAO-ACK 🔐
A Secure DAO-ACK message follows the format in Figure 7, where the base format is the DAO-ACK message shown in Figure 17.
6.5.3. DAO-ACK Options
This specification does not define any options to be carried by the DAO-ACK message. So no options here, bestie 🤷♀️
6.6. Consistency Check (CC) 🕵️♀️
The CC message is used to check secure message counters and issue challenge-responses. A CC message MUST be sent as a secured RPL message. No skipping the security step, periodt 🔒
6.6.1. Format of the CC Base Object
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |R| Flags | CC Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 18: The CC Base ObjectRPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO.R: The 'R' flag indicates whether the CC message is a response. A message with the 'R' flag cleared is a request; a message with the 'R' flag set is a response. (cleared = request, set = response, easy peasy ✨)Flags: The 7 bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.CC Nonce: 16-bit unsigned integer set by a CC request. The corresponding CC response includes the same CC nonce value as the request.DODAGID: 128-bit field, contains the identifier of the DODAG root.Destination Counter: 32-bit unsigned integer value indicating the sender's estimate of the destination's current security counter value. If the sender does not have an estimate, it SHOULD set the Destination Counter field to zero.
Unassigned bits of the CC Base are reserved. They MUST be set to zero on transmission and MUST be ignored on reception.
The Destination Counter value allows new or recovered nodes to resynchronize through CC message exchanges. This is important to ensure that a Counter value is not repeated for a given security key even in the event of devices recovering from a failure that created a loss of Counter state. For example, where a CC request or other RPL message is received with an initialized counter within the message Security section, the provision of the Incoming Counter within the CC response message allows the requesting node to reset its Outgoing Counter to a value greater than the last value received by the responding node; the Incoming Counter will also be updated from the received CC response. 🔄 Basically, nodes that just woke up from a crash get to catch up without repeating counter values. Iconic recovery arc 😭
6.6.2. CC Options
This specification allows for the CC message to carry the following options:
0x00 Pad1
0x01 PadN6.7. RPL Control Message Options 🎀
6.7.1. RPL Control Message Option Generic Format
RPL Control Message options all follow this format:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Option Type | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 19: RPL Option Generic FormatOption Type: 8-bit identifier of the type of option. The Option Type values are assigned by IANA (see Section 20.4.)Option Length: 8-bit unsigned integer, representing the length in octets of the option, not including the Option Type and Length fields.Option Data: A variable length field that contains data specific to the option.
When processing a RPL message containing an option for which the Option Type value is not recognized by the receiver, the receiver MUST silently ignore the unrecognized option and continue to process the following option, correctly handling any remaining options in the message. Unknown option? Ignore it and keep vibing 🫠
RPL message options may have alignment requirements. Following the convention in IPv6, options with alignment requirements are aligned in a packet such that multi-octet values within the Option Data field of each option fall on natural boundaries (i.e., fields of width n octets are placed at an integer multiple of n octets from the start of the header, for n = 1, 2, 4, or 8). 📏
6.7.2. Pad1
The Pad1 option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC messages, and its format is as follows:
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Type = 0x00 |
+-+-+-+-+-+-+-+-+
Figure 20: Format of the Pad1 OptionThe Pad1 option is used to insert a single octet of padding into the message to enable options alignment. If more than one octet of padding is required, the PadN option should be used rather than multiple Pad1 options.
NOTE! The format of the Pad1 option is a special case -- it has neither Option Length nor Option Data fields. 💅
6.7.3. PadN
The PadN option MAY be present in DIS, DIO, DAO, DAO-ACK, and CC messages, and its format is as follows:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Type = 0x01 | Option Length | 0x00 Padding...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 21: Format of the Pad N OptionThe PadN option is used to insert two or more octets of padding into the message to enable options alignment. PadN option data MUST be ignored by the receiver.
Option Type: 0x01Option Length: For N octets of padding, where 2 <= N <= 7, the Option Length field contains the value N-2. An Option Length of 0 indicates a total padding of 2 octets. An Option Length of 5 indicates a total padding of 7 octets, which is the maximum padding size allowed with the PadN option.Option Data: For N (N > 1) octets of padding, the Option Data consists of N-2 zero-valued octets.
6.7.4. DAG Metric Container 📊
The DAG Metric Container option MAY be present in DIO or DAO messages, and its format is as follows:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
| Type = 0x02 | Option Length | Metric Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - -
Figure 22: Format of the DAG Metric Container OptionThe DAG Metric Container is used to report metrics along the DODAG. The DAG Metric Container may contain a number of discrete node, link, and aggregate path metrics and constraints specified in [RFC6551] as chosen by the implementer.
The DAG Metric Container MAY appear more than once in the same RPL control message, for example, to accommodate a use case where the Metric Data is longer than 256 bytes. More information is in [RFC6551].
The processing and propagation of the DAG Metric Container is governed by implementation specific policy functions. 🧠
Option Type: 0x02Option Length: The Option Length field contains the length in octets of the Metric Data.Metric Data: The order, content, and coding of the DAG Metric Container data is as specified in [RFC6551].
6.7.5. Route Information ✨
okay bestie, the Route Information Option (RIO) MAY be present in DIO messages 🦋 and it carries the same info as the IPv6 Neighbor Discovery (ND) RIO defined in [RFC4191]. the root of a DODAG is the authority on setting that info, and it stays unchanged as it gets passed down the DODAG 🌸 A RPL router can trivially turn it back into an ND option and put it in its own RAs, so a node attached to that router ends up using the DODAG whose root has the best preference for a packet's destination 💅 On top of the normal ND semantics, an Objective Function can also use this info to favor a DODAG whose root is most preferred for a specific destination 🔥 The format is tweaked a little (Type, Length, Prefix) so it can ride along as a RPL option:
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 = 0x03 | Option Length | Prefix Length |Resvd|Prf|Resvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Route Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Prefix (Variable Length) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 23: Format of the Route Information Option
the RIO is how you say "hey, you can reach this destination prefix through the DODAG root" 🧚
if a RPL control message needs to cover more than one destination, the RIO can be repeated 🍓
[RFC4191] should be consulted as the authoritative reference for the RIO. the field descriptions are copied here just for convenience 💖
- Option Type:
0x03 - Option Length: Variable, length of the option in octets excluding the Type and Length fields. Note that this length is expressed in units of single octets, unlike in IPv6 ND.
- Prefix Length: 8-bit unsigned integer. The number of leading bits in the prefix that are valid. The value ranges from 0 to 128. The Prefix field has the number of bytes inferred from the Option Length field, that must be at least the Prefix Length. Note that in RPL, this means that the Prefix field may have lengths other than 0, 8, or 16.
- Prf: 2-bit signed integer. The Route Preference indicates whether to prefer the router associated with this prefix over others, when multiple identical prefixes (for different routers) have been received. If the Reserved (10) value is received, the RIO MUST be ignored. Per [RFC4191], the Reserved (10) value MUST NOT be sent. ([RFC4191] restricts the Preference to just three values to reinforce that it is not a metric.) 🙈
- Resvd: Two 3-bit unused fields. They MUST be initialized to zero by the sender and MUST be ignored by the receiver.
- Route Lifetime: 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for route determination. A value of all one bits (
0xFFFFFFFF) represents infinity. - Prefix: Variable-length field containing an IP address or a prefix of an IPv6 address. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be initialized to zero by the sender and ignored by the receiver. Note that in RPL, this field may have lengths other than 0, 8, or 16.
Unassigned bits of the RIO are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. no cap, that's the rule 🫶
6.7.6. DODAG Configuration 🎀
the DODAG Configuration option MAY be present in DIO messages, and it looks like this:
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| Flags |A| PCS | DIOIntDoubl. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DIOIntMin. | DIORedun. | MaxRankIncrease |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MinHopRankIncrease | OCP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Def. Lifetime | Lifetime Unit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 24: Format of the DODAG Configuration Option
this option is how the config info for DODAG Operation gets spread through the DODAG 🌈
the info here is pretty static and doesn't change within the DODAG, so it doesn't need to be in every DIO 😌 it's set at the DODAG root and then distributed down the DODAG with this option. Nodes other than the DODAG root MUST NOT modify this info when propagating the DODAG Configuration option. This option MAY be included occasionally by the DODAG root (as determined by the DODAG root), and MUST be included in response to a unicast request, e.g. a unicast DODAG Information Solicitation (DIS) message. ✨
- Option Type:
0x04 - Option Length:
14 - Flags: The 4-bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
- Authentication Enabled (A): 1-bit flag describing the security mode of the network. The bit describes whether a node must authenticate with a key authority before joining the network as a router. If the DIO is not a secure DIO, the 'A' bit MUST be zero. 🔐
- Path Control Size (PCS): 3-bit unsigned integer used to configure the number of bits that may be allocated to the Path Control field (see Section 9.9). Note that when PCS is consulted to determine the width of the Path Control field, a value of 1 is added, i.e., a PCS value of 0 results in 1 active bit in the Path Control field. The default value of PCS is
DEFAULT_PATH_CONTROL_SIZE. - DIOIntervalDoublings: 8-bit unsigned integer used to configure Imax of the DIO Trickle timer (see Section 8.3.1). The default value of DIOIntervalDoublings is
DEFAULT_DIO_INTERVAL_DOUBLINGS. - DIOIntervalMin: 8-bit unsigned integer used to configure Imin of the DIO Trickle timer (see Section 8.3.1). The default value of DIOIntervalMin is
DEFAULT_DIO_INTERVAL_MIN. - DIORedundancyConstant: 8-bit unsigned integer used to configure k of the DIO Trickle timer (see Section 8.3.1). The default value of DIORedundancyConstant is
DEFAULT_DIO_REDUNDANCY_CONSTANT. - MaxRankIncrease: 16-bit unsigned integer used to configure DAGMaxRankIncrease, the allowable increase in Rank in support of local repair. If DAGMaxRankIncrease is 0, then this mechanism is disabled.
- MinHopRankIncrease: 16-bit unsigned integer used to configure MinHopRankIncrease as described in Section 3.5.1. The default value of MinHopRankInc is
DEFAULT_MIN_HOP_RANK_INCREASE. - Objective Code Point (OCP): 16-bit unsigned integer. The OCP field identifies the OF and is managed by the IANA. 🧩
- Reserved: 7-bit unused field. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
- Default Lifetime: 8-bit unsigned integer. This is the lifetime that is used as default for all RPL routes. It is expressed in units of Lifetime Units, e.g., the default lifetime in seconds is (Default Lifetime) * (Lifetime Unit).
- Lifetime Unit: 16-bit unsigned integer. Provides the unit in seconds that is used to express route lifetimes in RPL. For very stable networks, it can be hours to days. ⏳
6.7.7. RPL Target 🦋
the RPL Target option MAY be present in DAO messages, and it's formatted like this:
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 | Flags | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Target Prefix (Variable Length) |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 25: Format of the RPL Target Option
the RPL Target option is for pointing at a Target IPv6 address, prefix, or multicast group that's reachable or queried along the DODAG 🎯 in a DAO, it says "this target is reachable" 💜
a RPL Target option MAY optionally be paired with a RPL Target Descriptor option (Figure 30) that qualifies the target. 🌸
a set of one or more Transit Information options (Section 6.7.8) MAY directly follow a set of one or more Target options in a DAO message (where each Target option MAY be paired with a RPL Target Descriptor option as above). how Target options and Transit Information options show up together in the DAO message is explained more in Section 9.4 📖
the RPL Target option may be repeated as necessary to indicate multiple targets 🍓
- Option Type:
0x05 - Option Length: Variable, length of the option in octets excluding the Type and Length fields.
- Flags: 8-bit unused field reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver.
- Prefix Length: 8-bit unsigned integer. Number of valid leading bits in the IPv6 Prefix.
- Target Prefix: Variable-length field identifying an IPv6 destination address, prefix, or multicast group. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length (if any) are reserved and MUST be set to zero on transmission and MUST be ignored on receipt. 💅
6.7.8. Transit Information 🦋
okay bestie, the Transit Information option MAY be present in DAO messages 💖 and it's giving very structured, so here's the layout:
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 = 0x06 | Option Length |E| Flags | Path Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ +
| |
+ Parent Address* +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The '*' denotes that the DODAG Parent Address subfield is not always
present, as described below.
Figure 26: Format of the Transit Information Optionngl the * is doing a lot here 🙈 it just means the DODAG Parent Address subfield doesn't always show up, and I'll explain when below. 🌸
Okay so the Transit Information option is how a node says what the attributes are for a path to one or more destinations ✨ The destinations get listed by one or more Target options that sit right before the Transit Information option(s). Iconic pairing, honestly. 👑
Now the main purpose: a node can use it to tell an ancestor who's collecting DODAG routing information about its DODAG parents 🧚 usually so that ancestor can build source routes. In the Non-Storing mode of operation, that ancestor is the DODAG root, and this option rides inside the DAO message. In the Storing mode of operation, the DODAG Parent Address subfield isn't needed at all, because the DAO message goes straight to the parent 💅 The option length is what tells you whether the DODAG Parent Address subfield is there or not. Main character energy for the length field 💜
A non-storing node with more than one DAO parent MAY include a Transit Information option for each DAO parent as part of the non-storing destination advertisement operation 🎀 It can also spread the bits in the Path Control field across different groups of DAO parents, which is a way to signal preference among parents. That preference may influence how the DODAG root picks between alternate parents/paths when it builds Downward routes. Lowkey a power move 😭
One or more Transit Information options MUST be preceded by one or more RPL Target options. 🔥 So the RPL Target option is the child node, and the Transit Information option(s) list the DODAG parents. How Target options and Transit Information options fit together in the DAO message is covered in Section 9.4, so go check that out 🌈
A typical non-storing node uses multiple Transit Information options and sends the DAO message it builds straight to the root 🚀 A typical storing node uses one Transit Information option with no parent field, and sends the DAO message to one or multiple parents, with some extra adjustments for Path Control (more on that later) 🍓
Here's an example so it clicks. In a Non-Storing mode of operation, let Tgt(T) be a Target option for a Target T, and let Trnst(P) be a Transit Information option that contains a parent address P. Say a non-storing Node N advertises its self-owned targets N1 and N2, and has parents P1, P2, and P3. The DAO message would be expected to contain the sequence ((Tgt(N1), Tgt(N2)), (Trnst(P1), Trnst(P2), Trnst(P3))), meaning the group of Target options {N1, N2} gets described by the Transit Information options as having the parents {P1, P2, P3}. The non-storing node then addresses that DAO message directly to the DODAG root, and forwards it through one of the DODAG parents: P1, P2, or P3. Bestie, that's a whole vibe 🦋
Now the fields, one by one:
Option Type: 0x06🎀Option Length: Variable, depending on whether or not the DODAG Parent Address subfield is present. ✨- External (E): 1-bit flag. The 'E' flag is set to indicate that the parent router redistributes external targets into the RPL network. An external Target is a Target that has been learned through an alternate protocol. The external targets are listed in the Target options that immediately precede the Transit Information option. An external Target is not expected to support RPL messages and options. 🫶
- Flags: The 7 bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. 💜
- Path Control: 8-bit bit field. The Path Control field limits the number of DAO parents to which a DAO message advertising connectivity to a specific destination may be sent, and it also gives some indication of relative preference. The limit provides some bound on overall DAO message fan-out in the LLN. The assignment and ordering of the bits in the Path Control also communicate preference. Not all of these bits may be enabled according to the PCS in the DODAG Configuration. The Path Control field is split into four subfields of two bits each: PC1, PC2, PC3, and PC4, as shown in Figure 27. The subfields are ordered by preference, with PC1 the most preferred and PC4 the least. Within a subfield, there is no order of preference. By grouping the parents (as in ECMP) and ordering them, the parents can be tied to specific bits in the Path Control field in a way that communicates preference. 👑
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|PC1|PC2|PC3|PC4|
+-+-+-+-+-+-+-+-+
Figure 27: Path Control Preference Subfield Encoding- Path Sequence: 8-bit unsigned integer. When an RPL Target option is issued by the node that owns the Target prefix (i.e., in a DAO message), that node sets the Path Sequence and increments it each time it issues an RPL Target option with updated information. 🧚
- Path Lifetime: 8-bit unsigned integer. The length of time in Lifetime Units (obtained from the Configuration option) that the prefix is valid for route determination. The period starts when a new Path Sequence is seen. A value of all one bits (
0xFF) represents infinity. A value of all zero bits (0x00) indicates a loss of reachability. A DAO message that contains a Transit Information option with a Path Lifetime of0x00for a Target is referred to as a No-Path (for that Target) in this document. 💀 - Parent Address (optional): IPv6 address of the DODAG parent of the node originally issuing the Transit Information option. This field may not be present, depending on the DODAG Mode of Operation (Storing or Non-Storing), and it is indicated by the Transit Information option length. 🌸
Unassigned bits of the Transit Information option are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. 🫶
6.7.9. Solicited Information 🧚
okay so the Solicited Information option MAY be present in DIS messages 💅 and here's its format:
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 = 0x07 |Opt Length = 19| RPLInstanceID |V|I|D| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version Number |
+-+-+-+-+-+-+-+-+
Figure 28: Format of the Solicited Information OptionThe Solicited Information option is how a node asks for DIO messages from a subset of its neighbors 🦋 It can include a bunch of predicate criteria that the receiving node has to match. The requester uses this to limit replies from "non-interesting" nodes, which is honestly so smart 🙈 These predicates decide whether a node resets its DIO Trickle timer, as described in Section 8.3.
The option has flags that say which predicates a node should check before deciding to reset its Trickle timer. A node resets its Trickle timer when all predicates are true. If a flag is set, the RPL node MUST check the associated predicate. If a flag is cleared, the RPL node MUST NOT check the associated predicate. (If a flag is cleared, the RPL node assumes that the associated predicate is true.) 🔥
Option Type: 0x07🎀Option Length: 19✨- V: The 'V' flag is the Version predicate. The Version predicate is true if the receiver's DODAGVersionNumber matches the requested Version Number. If the 'V' flag is cleared, the Version field is not valid, and the Version field MUST be set to zero on transmission and ignored upon receipt. 💜
- I: The 'I' flag is the InstanceID predicate. The InstanceID predicate is true when the RPL node's current RPLInstanceID matches the requested RPLInstanceID. If the 'I' flag is cleared, the RPLInstanceID field is not valid, and the RPLInstanceID field MUST be set to zero on transmission and ignored upon receipt. 👑
- D: The 'D' flag is the DODAGID predicate. The DODAGID predicate is true if the RPL node's parent set has the same DODAGID as the DODAGID field. If the 'D' flag is cleared, the DODAGID field is not valid, and the DODAGID field MUST be set to zero on transmission and ignored upon receipt. 🌈
- Flags: The 5 bits remaining unused in the Flags field are reserved for flags. The field MUST be initialized to zero by the sender and MUST be ignored by the receiver. 🫶
- Version Number: 8-bit unsigned integer containing the value of DODAGVersionNumber that is being solicited when valid. 🧚
- RPLInstanceID: 8-bit unsigned integer containing the RPLInstanceID that is being solicited when valid. 🍓
- DODAGID: 128-bit unsigned integer containing the DODAGID that is being solicited when valid. 🌸
Unassigned bits of the Solicited Information option are reserved. They MUST be set to zero on transmission and MUST be ignored on reception. 💖
6.7.10. Prefix Information 🎀
okay so the Prefix Information Option (PIO) MAY be present in DIO messages 💅 and carries the info that the IPv6 ND Prefix Information option defines in [RFC4861], [RFC4862], and [RFC6275], for RPL nodes and IPv6 hosts to use. a RPL node may use it for Stateless Address Autoconfiguration (SLAAC) from a prefix its parent advertised, as specified in [RFC4862], and it can advertise its own address as specified in [RFC6275]. the root of a DODAG is the authority for setting this info 👑. the info gets passed down the DODAG unchanged, except a RPL router may overwrite the Interface ID if the 'R' flag is set to show its full address in the PIO. the option format is modified (Type, Length, Prefix) so it can ride along as a RPL option 🧚
If the only thing a received PIO in a DIO is supposed to do is give the receiving node the global address of the parent, then the sender resets the 'A' and 'L' bits and sets the 'R' bit 🦋. when that's received, RPL won't autoconfigure an address or a connected route from the prefix [RFC4862]. and like always, when the 'L' bit isn't set, the RPL node MAY include the prefix in PIOs it sends to its children 🌸
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 = 0x08 |Opt Length = 30| Prefix Length |L|A|R|Reserved1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 29: Format of the Prefix Information Option ✨
the PIO can be used to hand out the prefix that's in use inside the DODAG, e.g., for address autoconfiguration 💖
[RFC4861] and [RFC6275] are the real authoritative references for the PIO 📚. the field descriptions are copied here just for convenience:
- Option Type:
0x08 - Option Length:
30. heads up, this length is counted in single octets, unlike in IPv6 ND 🙈 - Prefix Length: 8-bit unsigned integer. the number of leading bits in the Prefix field that are valid. the value goes from 0 to 128. this field gives the info needed for on-link determination (when combined with the 'L' flag in the PIO). it also helps with address autoconfiguration as specified in [RFC4862], which may have more restrictions on prefix length 💅
- L: 1-bit on-link flag. when set, it means this prefix can be used for on-link determination. when not set, the advertisement says nothing about whether the prefix is on-link or off-link. so if the 'L' flag isn't set, a RPL node MUST NOT conclude that an address derived from the prefix is off-link. it MUST NOT update a previous indication that the address is on-link. a RPL node acting as a router MUST NOT propagate a PIO with the 'L' flag set. a RPL node acting as a router MAY propagate a PIO with the 'L' flag not set 🔥
- A: 1-bit autonomous address-configuration flag. when set, it means this prefix can be used for stateless address configuration as specified in [RFC4862]. when both protocols (ND RAs and RPL DIOs) carry PIOs on the same link, a RPL node can use either one for SLAAC. it's also possible to make either protocol ineligible for SLAAC by forcing the 'A' flag to 0 for PIOs carried in that protocol 🌈
- R: 1-bit router address flag. when set, the Prefix field holds a complete IPv6 address assigned to the sending router that can be used as parent in a target option. the prefix is the first prefix length bits of the Prefix field. the router IPv6 address has the same scope and follows the same lifetime values as the advertised prefix. this use of the Prefix field works with its use in advertising the prefix itself, since Prefix Advertisement only uses the leading bits. so reading this flag bit doesn't depend on the processing needed for the on-link (L) and autonomous address-configuration (A) flag bits 🦋
- Reserved1: 5-bit unused field. it MUST be initialized to zero by the sender and MUST be ignored by the receiver 🫶
- Valid Lifetime: 32-bit unsigned integer. the length of time in seconds (counted from when the packet is sent) that the prefix is valid for on-link determination. all one bits (0xFFFFFFFF) means infinity. the Valid Lifetime is also used by [RFC4862] ⏳
- Preferred Lifetime: 32-bit unsigned integer. the length of time in seconds (counted from when the packet is sent) that addresses generated from the prefix via stateless address autoconfiguration stay preferred [RFC4862]. all one bits (0xFFFFFFFF) means infinity. see [RFC4862]. also, the value of this field MUST NOT exceed the Valid Lifetime field, so you don't end up preferring addresses that have already expired 💀
- Reserved2: this field is unused. it MUST be initialized to zero by the sender and MUST be ignored by the receiver 🍓
- Prefix: an IPv6 address or a prefix of an IPv6 address. the Prefix Length field says how many leading bits are valid. the bits after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. a router SHOULD NOT send a prefix option for the link-local prefix, and a host SHOULD ignore such a prefix option. a non-storing node SHOULD hold off on advertising a prefix until it owns an address of that prefix. then it SHOULD advertise its full address in this field, with the 'R' flag set. the children of a node that advertises a full address with the 'R' flag set can then use that address to figure out the DODAG Parent Address subfield of the Transit Information option 🧚
Unassigned bits of the PIO are reserved. they MUST be set to zero on transmission and MUST be ignored on reception 🌸
6.7.11. RPL Target Descriptor 💜
the RPL Target option MAY be immediately followed by one opaque descriptor that qualifies that specific target ✨
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 = 0x09 |Opt Length = 4 | Descriptor
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Descriptor (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 30: Format of the RPL Target Descriptor Option 🦋
the RPL Target Descriptor option qualifies a target, which people sometimes call "tagging" 🏷️
there can be at most one descriptor per target. the node that injects the Target into the RPL network sets the descriptor. routers that propagate the Target Up the DODAG in DAO messages MUST copy it but MUST NOT modify it 🫶
- Option Type:
0x09 - Option Length:
4 - Descriptor: 32-bit unsigned integer. Opaque.
7. Sequence Counters 🔢
this section explains the general scheme for bootstrapping and running sequence counters in RPL, like the DODAGVersionNumber in the DIO message, the DAOSequence in the DAO message, and the Path Sequence in the Transit Information option 💖
7.1. Sequence Counter Overview ✨
this spec uses three different sequence numbers to check the freshness and synchronization of protocol info 🧠
- DODAGVersionNumber: this counter is in the DIO Base to show the Version of the DODAG being formed. the root increments it monotonically each time it decides to form a new Version of the DODAG, so it can revalidate integrity and allow a global repair to happen 👑. it's passed down the DODAG unchanged as routers join the new DODAG Version. it's globally significant in a DODAG and shows which Version of the DODAG a router is running in. an older (lesser) value means the originating router hasn't moved to the new DODAG Version, and it can't be used as a parent once the receiving node has moved to the newer one 🚫
- DAOSequence: this counter is in the DAO Base to match a DAO message with a DAO ACK message. it's locally significant to the node that issues a DAO message, since that node uses it to notice a lost DAO message and enable retries 🔁
- Path Sequence: this counter is in the Transit Information option in a DAO message. its job is to tell apart a movement where a newer route replaces a stale one from a route redundancy case where several routes exist in parallel for the same target 🛤️. the Path Sequence is globally significant in a DODAG and shows how fresh the route to the associated target is. an older (lesser) value from an originating router means that router has stale routing state, so it shouldn't be considered anymore as a potential next hop for the target 💀. the Path Sequence is computed by the node advertising the target (the Target itself, or a router advertising a Target on behalf of a host), and it stays unchanged as the DAO content travels toward the root through parent routers. if a host doesn't pass a counter to its router, the router is in charge of computing the Path Sequence on behalf of the host, and the host can only register with one router for that purpose 🙈. if a DAO message containing the same Target goes to multiple parents at a given point in time for route redundancy, the Path Sequence is the same in all of those DAO messages for that same target 🌈
7.2. Sequence Counter Operation 💖
okay so RPL splits its sequence counters up in a "lollipop" way [Perlman83] 🍭. Values from 128 and up form a linear run that signals a restart and bootstraps the counter, and values 127 and under form a circular sequence space of size 128, same vibe as [RFC1982] ✨. There's also a whole thing about how the mode changes when you go from the linear part into the circular part 🫶. And when you're in the circular part, if two sequence numbers are too far apart, they just aren't comparable. We'll get into that below 💅.
bestie, there's a comparison window called SEQUENCE_WINDOW = 16 🎀. It's set from 2^N, with N defined as 4 in this spec.
For a given sequence counter, here's the tea 🍓:
- The sequence counter SHOULD be initialized to an implementation defined value, which is 128 or greater prior to use. A recommended value is
240(256 - SEQUENCE_WINDOW) 🌸. - When a sequence counter increment would cause the sequence counter to increment beyond its maximum value, the sequence counter MUST wrap back to zero. When incrementing a sequence counter greater than or equal to 128, the maximum value is
255. When incrementing a sequence counter less than 128, the maximum value is127🔄. - When comparing two sequence counters, the following rules MUST be applied 👑:
- When a first sequence counter A is in the interval
[128..255]and a second sequence counter B is in[0..127]:- If
(256 + B - A)is less than or equal toSEQUENCE_WINDOW, then B is greater than A, A is less than B, and the two are not equal. - If
(256 + B - A)is greater thanSEQUENCE_WINDOW, then A is greater than B, B is less than A, and the two are not equal.
- If
- When a first sequence counter A is in the interval
For example, if A is 240, and B is 5, then (256 + 5 - 240) is 21. 21 is greater than SEQUENCE_WINDOW (16), so 240 is greater than 5 🙈. As another example, if A is 250 and B is 5, then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW (16), so 250 is less than 5 💀.
- In the case where both sequence counters to be compared are less than or equal to
127, and in the case where both sequence counters to be compared are greater than or equal to128:- If the absolute magnitude of difference between the two sequence counters is less than or equal to
SEQUENCE_WINDOW, then a comparison as described in [RFC1982] is used to determine the relationships greater than, less than, and equal ✨. - If the absolute magnitude of difference of the two sequence counters is greater than
SEQUENCE_WINDOW, then a desynchronization has occurred and the two sequence numbers are not comparable 😭.
- If the absolute magnitude of difference between the two sequence counters is less than or equal to
- If two sequence numbers are determined not to be comparable, i.e., the results of the comparison are not defined, then a node should consider the comparison as if it has evaluated in such a way so as to give precedence to the sequence number that has most recently been observed to increment. Failing this, the node should consider the comparison as if it has evaluated in such a way so as to minimize the resulting changes to its own state 🦋.
8. Upward Routes ✨
This section is all about how RPL discovers and maintains Upward routes 🧚. It covers DODAG Information Objects (DIOs), the messages used to discover and maintain these routes, and how RPL generates and responds to them. It also describes DODAG Information Solicitation (DIS) messages, which are used to trigger DIO transmissions 📣.
As mentioned in Section 3.2.8, nodes that decide to join a DODAG MUST provision at least one DODAG parent as a default route for the associated instance 💖. This default route lets a packet get forwarded Upward until it hits a common ancestor, and from there it gets routed Downward to the destination 🌈. If the destination isn't in the DODAG, the DODAG root may be able to forward the packet using connectivity to the outside of the DODAG. If it can't forward the packet outside, then the DODAG root has to drop it 😤.
A DIO message can also carry explicit routing information 🎀:
DODAGID: The DODAGID is a Global or Unique Local IPv6 address of the root. A node that joins a DODAG SHOULD provision a host route via a DODAG parent to the address used by the root as the DODAGID 🌟.- RIO Prefix: The root MAY place one or more Route Information options in a DIO message. The RIO is used to advertise an external route that is reachable via the root, associated with a preference, as presented in Section 6.7.5, which incorporates the RIO from [RFC4191] 🛰️. It's interpreted as a capability of the root, not a routing advertisement. It MUST NOT be redistributed in another routing protocol, though it SHOULD be used by an ingress RPL router to select a DODAG when a packet is injected in a RPL domain from a node attached to that RPL router 🙅♀️. An Objective Function MAY use the routes advertised in RIO, or the preference for those routes, in order to favor one DODAG over another for the same instance 👑.
8.1. DIO Base Rules 🍓
- For the following DIO Base fields, a node that is not a DODAG root MUST advertise the same values as its preferred DODAG parent (defined in Section 8.2.1). In this way, these values propagate Down the DODAG unchanged and get advertised by every node that has a route to that DODAG root 🔁. These fields are as follows:
- Grounded (G)
- Mode of Operation (MOP)
- DAGPreference (Prf)
- Version
- RPLInstanceID
- DODAGID
- A node MAY update the following fields at each hop 🦋:
- Rank
- DTSN
- The DODAGID field each root sets MUST be unique within the RPL Instance, and MUST be a routable IPv6 address belonging to the root 🔐.
8.2. Upward Route Discovery and Maintenance 🌸
Upward route discovery lets a node join a DODAG by finding neighbors that are members of the DODAG of interest and identifying a set of parents 🧭. The exact policies for selecting neighbors and parents are implementation dependent and driven by the OF. This section specifies the set of rules those policies must follow for interoperability 🫶.
8.2.1. Neighbors and Parents within a DODAG Version 💅
RPL's Upward route discovery algorithms and processing work in terms of three logical sets of link-local nodes ✨. First, the candidate neighbor set is a subset of the nodes that can be reached via link-local multicast. How this set gets selected is implementation and OF dependent. Second, the parent set is a restricted subset of the candidate neighbor set. Finally, the preferred parent is a member of the parent set that is the preferred next hop in Upward routes. Conceptually, the preferred parent is a single parent, although it may be a set of multiple parents if those parents are equally preferred and have identical Rank 👑.
More precisely 🎀:
- The DODAG parent set MUST be a subset of the candidate neighbor set.
- A DODAG root MUST have a DODAG parent set of size zero.
- A node that is not a DODAG root MAY maintain a DODAG parent set of size greater than or equal to one.
- A node's preferred DODAG parent MUST be a member of its DODAG parent set.
- A node's Rank MUST be greater than all elements of its DODAG parent set.
- When Neighbor Unreachability Detection (NUD) [RFC4861], or an equivalent mechanism, determines that a neighbor is no longer reachable, a RPL node MUST NOT consider this node in the candidate neighbor set when calculating and advertising routes, until it determines that it is again reachable. Routes through an unreachable neighbor MUST be removed from the routing table 🚫.
These rules make sure there's a consistent partial order on nodes within the DODAG 🌈. As long as node Ranks don't change, following the above rules makes sure that every node's route to a DODAG root is loop-free, since Rank decreases on each hop to the root 📉.
The OF can guide candidate neighbor set and parent set selection, as discussed in [RFC6552] 🧚♀️.
8.2.2. Neighbors and Parents across DODAG Versions 🦋
The above rules govern a single DODAG Version 💖. The rules in this section define how RPL operates when there are multiple DODAG Versions ✨.
8.2.2.1. DODAG Version ✨
okay so a DODAG Version is pinned down by the tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) 🦋. here are the rules, bestie:
- The tuple
(RPLInstanceID, DODAGID, DODAGVersionNumber)uniquely defines a DODAG Version. Every element of a node's DODAG parent set, as conveyed by the last heard DIO message from each DODAG parent, MUST belong to the same DODAG Version 💖. Elements of a node's candidate neighbor set MAY belong to different DODAG Versions 🌈. - A node is a member of a DODAG Version if every element of its DODAG parent set belongs to that DODAG Version, or if that node is the root of the corresponding DODAG 👑.
- A node MUST NOT send DIOs for DODAG Versions of which it is not a member 🙅♀️.
- DODAG roots MAY increment the DODAGVersionNumber that they advertise and thus move to a new DODAG Version 🚀. When a DODAG root increments its DODAGVersionNumber, it MUST follow the conventions of Serial Number Arithmetic as described in Section 7. Events triggering the increment of the DODAGVersionNumber are described later in this section and in Section 18 ✨.
- Within a given DODAG, a node that is not a root MUST NOT advertise a DODAGVersionNumber higher than the highest DODAGVersionNumber it has heard. Higher is defined as the greater-than operator in Section 7 💅.
- Once a node has advertised a DODAG Version by sending a DIO, it MUST NOT be a member of a previous DODAG Version of the same DODAG (i.e., with the same RPLInstanceID, the same DODAGID, and a lower DODAGVersionNumber). Lower is defined as the less-than operator in Section 7 🫶.
When the DODAG parent set becomes empty on a node that is not a root (i.e., the last parent has been removed, causing the node no longer to be associated with that DODAG), then the DODAG information should not be suppressed until after the expiration of an implementation-specific local timer ⏳. During the interval prior to suppression of the "old" DODAG state, the node will be able to observe if the DODAGVersionNumber has been incremented should any new parents appear 👀. This will help protect against the possibility of loops that may occur if that node were to inadvertently rejoin the old DODAG Version in its own prior sub-DODAG 🌀.
As the DODAGVersionNumber is incremented, a new DODAG Version spreads outward from the DODAG root 🌸. A parent that advertises the new DODAGVersionNumber cannot belong to the sub-DODAG of a node advertising an older DODAGVersionNumber. Therefore, a node can safely add a parent of any Rank with a newer DODAGVersionNumber without forming a loop 🧚.
Let's do an example, because this one is kinda wild 🙈. Suppose a node has left a DODAG with DODAGVersionNumber N. Suppose that node had a sub-DODAG and did attempt to poison that sub-DODAG by advertising a Rank of INFINITE_RANK, but those advertisements may have become lost in the LLN. Then, if the node did observe a candidate neighbor advertising a position in that original DODAG at DODAGVersionNumber N, that candidate neighbor could possibly have been in the node's former sub-DODAG, and there is a possible case where adding that candidate neighbor as a parent could cause a loop 😱. In this case, if that candidate neighbor is observed to advertise a DODAGVersionNumber N+1, then that candidate neighbor is certain to be safe, since it is certain not to be in that original node's sub-DODAG, as it has been able to increment the DODAGVersionNumber by hearing from the DODAG root while that original node was detached 🥹. For this reason, it is useful for the detached node to remember the original DODAG information, including the DODAGVersionNumber N 🧠.
Exactly when a DODAG root increments the DODAGVersionNumber is implementation dependent and out of scope for this specification 🤷♀️. Examples include incrementing the DODAGVersionNumber periodically, upon administrative intervention, or on application-level detection of lost connectivity or DODAG inefficiency 🔧.
After a node transitions to and advertises a new DODAG Version, the rules above make it unable to advertise the previous DODAG Version (prior DODAGVersionNumber) once it has committed to advertising the new DODAG Version 🦋. no going back, babe 💀.
8.2.2.2. DODAG Roots 👑
- A DODAG root without possibility to satisfy the application-defined goal MUST NOT set the
Groundedbit 🚫. - A DODAG root MUST advertise a Rank of
ROOT_RANK👑. - A node whose DODAG parent set is empty MAY become the DODAG root of a floating DODAG 🎈. It MAY also set its
DAGPreferencesuch that it is less preferred 🥀.
In a deployment that uses non-LLN links to federate a number of LLN roots, it is possible to run RPL over those non-RPL links and use one router as a "backbone root" 🌉. The backbone root is the virtual root of the DODAG and exposes a Rank of BASE_RANK over the backbone. All the LLN roots that are parented to that backbone root, including the backbone root if it also serves as the LLN root itself, expose a Rank of ROOT_RANK to the LLN 🌈. These virtual roots are part of the same DODAG and advertise the same DODAGID. They coordinate DODAGVersionNumbers and other DODAG parameters with the virtual root over the backbone 🤝. The method of coordination is out of scope for this specification (to be defined in future companion specifications) 🔮.
8.2.2.3. DODAG Selection 🎯
The Objective Function and the set of advertised routing metrics and constraints of a DAG determine how a node selects its neighbor set, parent set, and preferred parents 💅. This selection implicitly also determines the DODAG within a DAG. Such selection can include administrative preference (Prf) as well as metrics or other considerations 📊.
If a node has the option to join a more preferred DODAG while still meeting other optimization objectives, then the node will generally seek to join the more preferred DODAG as determined by the OF ✨. All else being equal, it is left to the implementation to determine which DODAG is most preferred (since, as a reminder, a node must only join one DODAG per RPL Instance) 💭.
8.2.2.4. Rank and Movement within a DODAG Version 🏃♀️
- A node MUST NOT advertise a Rank less than or equal to any member of its parent set within the DODAG Version 🙅♀️.
- A node MAY advertise a Rank lower than its prior advertisement within the DODAG Version 📉.
- Let L be the lowest Rank within a DODAG Version that a given node has advertised. Within the same DODAG Version, that node MUST NOT advertise an effective Rank higher than L +
DAGMaxRankIncrease.INFINITE_RANKis an exception to this rule: a node MAY advertise anINFINITE_RANKwithin a DODAG Version without restriction ♾️. If a node's Rank were to be higher than allowed by L +DAGMaxRankIncrease, when it advertises Rank, it MUST advertise its Rank asINFINITE_RANK🫠. - A node MAY, at any time, choose to join a different DODAG within a RPL Instance. Such a join has no Rank restrictions, unless that different DODAG is a DODAG Version of which this node has previously been a member; in which case, the rule of the previous bullet (3) must be observed. Until a node transmits a DIO indicating its new DODAG membership, it MUST forward packets along the previous DODAG 📦.
- A node MAY, at any time after hearing the next DODAGVersionNumber advertised from suitable DODAG parents, choose to migrate to the next DODAG Version within the DODAG 🦋.
Conceptually, an implementation is maintaining a DODAG parent set within the DODAG Version 🧠. Movement entails changes to the DODAG parent set. Moving Up does not present the risk to create a loop, but moving Down might, so that operation is subject to additional constraints ⚠️.
When a node migrates to the next DODAG Version, the DODAG parent set needs to be rebuilt for the new Version 🔁. An implementation could defer to migrate for some reasonable amount of time, to see if some other neighbors with potentially better metrics but higher Rank announce themselves ⏰. Similarly, when a node jumps into a new DODAG, it needs to construct a new DODAG parent set for this new DODAG 🧩.
If a node needs to move Down a DODAG that it is attached to, increasing its Rank, then it MAY poison its routes and delay before moving as described in Section 8.2.2.5 🧪.
A node is allowed to join any DODAG Version that it has never been a prior member of without any restrictions 🌷. But if the node has been a prior member of the DODAG Version, then it must continue to observe the rule that it may not advertise a Rank higher than L+DAGMaxRankIncrease at any point in the life of the DODAG Version. This rule must be observed so as not to create a loophole that would allow the node to effectively increment its Rank all the way to INFINITE_RANK, which may have impact on other nodes and create a resource-wasting count-to-infinity scenario 🙅♀️💀.
8.2.2.5. Poisoning 🧪
- A node poisons routes by advertising a Rank of
INFINITE_RANK☠️. - A node MUST NOT have any nodes with a Rank of
INFINITE_RANKin its parent set 🚫.
Although an implementation may advertise INFINITE_RANK for the purposes of poisoning, doing so is not the same as setting Rank to INFINITE_RANK 🙃. For example, a node may continue to send data packets whose RPL Packet Information includes a Rank that is not INFINITE_RANK, yet still advertise INFINITE_RANK in its DIOs 📨.
When a (former) parent is observed to advertise a Rank of INFINITE_RANK, that (former) parent has detached from the DODAG and is no longer able to act as a parent, nor is there any way that another node may be considered to have a Rank greater-than INFINITE_RANK 💔. Therefore, that (former) parent cannot act as a parent any longer and is removed from the parent set 👋.
8.2.2.6. Detaching 🦋
- A node unable to stay connected to a DODAG within a given DODAG Version, i.e., that cannot retain non-empty parent set without violating the rules of this specification, MAY detach from this DODAG Version 🫧. A node that detaches becomes the root of its own floating DODAG and SHOULD immediately advertise this new situation in a DIO as an alternate to poisoning 📣.
8.2.2.7. Following a Parent 🐣
- If a node receives a DIO from one of its DODAG parents, indicating that the parent has left the DODAG, that node SHOULD stay in its current DODAG through an alternative DODAG parent, if possible. It MAY follow the leaving parent 🫂.
A DODAG parent may have moved, migrated to the next DODAG Version, or jumped to a different DODAG 🚪. A node ought to give some preference to remaining in the current DODAG, if possible via an alternate parent, but ought to follow the parent if there are no other options 💜.
8.2.3. DIO Message Communication 📬
When a DIO message is received, the receiving node must first determine whether or not the DIO message should be accepted for further processing, and subsequently present the DIO message for further processing if eligible 👀.
- If the DIO message is malformed, then the DIO message is not eligible for further processing and a node MUST silently discard it. (See Section 18 for error logging.) 🗑️
- If the sender of the DIO message is a member of the candidate neighbor set and the DIO message is not malformed, the node MUST process the DIO 🫶.
8.2.3.1. DIO Message Processing ✨
okay so as DIO messages roll in from candidate neighbors, those neighbors can get promoted to DODAG parents 👑 by following the DODAG discovery rules in Section 8.2 💅. when a node drops a neighbor into the DODAG parent set, the node becomes attached to the DODAG through that new DODAG parent node 🦋
the most preferred parent should be used to restrict which other nodes may become DODAG parents 🙈 it's basically the gatekeeper bestie. some nodes in the DODAG parent set may be of a Rank less than or equal to the most preferred DODAG parent. (ngl this can happen when an energy-constrained device sits at a lesser Rank but should be avoided per an optimization objective, so you end up with a more preferred parent at a greater Rank 🔋)
8.3. DIO Transmission 🎀
RPL nodes transmit DIOs using a Trickle timer [RFC6206] 💖. a DIO from a sender with a lesser DAGRank that causes no changes to the recipient's parent set, preferred parent, or Rank SHOULD be considered consistent with respect to the Trickle timer 🫶
the following packets and events MUST be considered inconsistencies with respect to the Trickle timer, and cause the Trickle timer to reset 🔥
- When a node detects an inconsistency when forwarding a packet, as detailed in Section 11.2.
- When a node receives a multicast DIS message without a Solicited Information option, unless a DIS flag restricts this behavior.
- When a node receives a multicast DIS with a Solicited Information option and the node matches all of the predicates in the Solicited Information option, unless a DIS flag restricts this behavior.
- When a node joins a new DODAG Version (e.g., by updating its DODAGVersionNumber, joining a new RPL Instance, etc.).
note that this list is not exhaustive, and an implementation MAY consider other messages or events to be inconsistencies 🌈
a node SHOULD NOT reset its DIO Trickle timer in response to unicast DIS messages 🙅♀️. when a node receives a unicast DIS without a Solicited Information option, it MUST unicast a DIO to the sender in response. this DIO MUST include a DODAG Configuration option ✨
when a node receives a unicast DIS message with a Solicited Information option and matches the predicates of that Solicited Information option, it MUST unicast a DIO to the sender in response. this unicast DIO MUST include a DODAG Configuration option. thus, a node MAY transmit a unicast DIS message to a potential DODAG parent in order to probe for DODAG Configuration and other parameters 🕵️♀️💜
8.3.1. Trickle Parameters 💜
the configuration parameters of the Trickle timer are specified as follows:
Imin: learned from the DIO message as (2^DIOIntervalMin) ms. the default value of DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN.Imax: learned from the DIO message as DIOIntervalDoublings. the default value of DIOIntervalDoublings is DEFAULT_DIO_INTERVAL_DOUBLINGS.k: learned from the DIO message as DIORedundancyConstant. the default value of DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT. in RPL, whenkhas the value of0x00, this is to be treated as a redundancy constant of infinity in RPL, i.e., Trickle never suppresses messages 🧚
8.4. DODAG Selection 🍓
the DODAG selection is implementation and OF dependent 🤷♀️. in order to limit erratic movements, and all metrics being equal, nodes SHOULD keep their previous selection. also, nodes SHOULD provide a means to filter out a parent whose availability is detected as fluctuating, at least when more stable choices are available 💅
when connection to a grounded DODAG is not possible or preferable for security or other reasons, scattered DODAGs MAY aggregate as much as possible into larger DODAGs in order to allow connectivity within the LLN 🌸
a node SHOULD verify that bidirectional connectivity and adequate link quality is available with a candidate neighbor before it considers that candidate as a DODAG parent. no skipping this step, bestie 🙈
8.5. Operation as a Leaf Node 🍃
in some cases, a RPL node may attach to a DODAG as a leaf node only 🌷. one example of such a case is when a node does not understand or does not support (policy) the RPL Instance's OF or advertised metric/constraint. as specified in Section 18.6, related to policy function, the node may either join the DODAG as a leaf node or may not join the DODAG. as mentioned in Section 18.5, it is then recommended to log a fault 📝
a leaf node does not extend DODAG connectivity 🙅♀️; however, in some cases, the leaf node may still need to transmit DIOs on occasion, in particular, when the leaf node may not have always been acting as a leaf node and an inconsistency is detected.
a node operating as a leaf node must obey the following rules:
- It MUST NOT transmit DIOs containing the DAG Metric Container.
- Its DIOs MUST advertise a DAGRank of
INFINITE_RANK. - It MAY suppress DIO transmission, unless the DIO transmission has been triggered due to detection of inconsistency when a packet is being forwarded or in response to a unicast DIS message, in which case the DIO transmission MUST NOT be suppressed.
- It MAY transmit unicast DAOs as described in Section 9.2.
- It MAY transmit multicast DAOs to the '1 hop' neighborhood as described in Section 9.10.
a particular case that requires a leaf node to send a DIO is if that leaf node was a prior member of another DODAG and another node forwards a message assuming the old topology, triggering an inconsistency 😭. the leaf node needs to transmit a DIO in order to repair the inconsistency.
note that due to the lossy nature of LLNs, even though the leaf node may have optimistically poisoned its routes by advertising a Rank of INFINITE_RANK in the old DODAG prior to becoming a leaf node, that advertisement may have become lost, and a leaf node must be capable to send a DIO later in order to repair the inconsistency 🥺
in the general case, the leaf node MUST NOT advertise itself as a router (i.e., send DIOs) 🚫💅
8.6. Administrative Rank 👑
in some cases, it might be beneficial to adjust the Rank advertised by a node beyond that computed by the OF based on some implementation-specific policy and properties of the node 🧠. for example, a node that has a limited battery should be a leaf unless there is no other choice, and may then augment the Rank computation specified by the OF in order to expose an exaggerated Rank 🔋💀
9. Downward Routes 🦋
this section describes how RPL discovers and maintains Downward routes ✨. RPL constructs and maintains Downward routes with Destination Advertisement Object (DAO) messages. Downward routes support P2MP flows, from the DODAG roots toward the leaves. Downward routes also support P2P flows: P2P messages can flow toward a DODAG root (or a common ancestor) through an Upward route, then away from the DODAG root to a destination through a Downward route 🌈
this specification describes the two modes a RPL Instance may choose from for maintaining Downward routes. in the first mode, called "Storing", nodes store Downward routing tables for their sub-DODAG. each hop on a Downward route in a storing network examines its routing table to decide on the next hop. in the second mode, called "Non-Storing", nodes do not store Downward routing tables. Downward packets are routed with source routes populated by a DODAG root [RFC6554] 🧭
RPL allows a simple one-hop P2P optimization for both storing and non-storing networks. a node may send a P2P packet destined to a one-hop neighbor directly to that node 💖
9.1. Destination Advertisement Parents 🎀
to establish Downward routes, RPL nodes send DAO messages Upward. the next-hop destinations of these DAO messages are called "DAO parents". the collection of a node's DAO parents is called the "DAO parent set" 🫶
- A node MAY send DAO messages using the all-RPL-nodes multicast address, which is an optimization to provision one-hop routing. The
'K'bit MUST be cleared on transmission of the multicast DAO. - A node's DAO parent set MUST be a subset of its DODAG parent set.
- In Storing mode operation, a node MUST NOT address unicast DAO messages to nodes that are not DAO parents.
- In Storing mode operation, the IPv6 source and destination addresses of a DAO message MUST be link-local addresses.
- In Non-Storing mode operation, a node MUST NOT address unicast DAO messages to nodes that are not DODAG roots.
- In Non-Storing mode operation, the IPv6 source and destination addresses of a DAO message MUST be a unique-local or a global address.
the selection of DAO parents is implementation and Objective Function specific 🌟
9.2. Downward Route Discovery and Maintenance 🌸
Destination Advertisement may be configured to be entirely disabled, or operate in either a Storing or Non-Storing mode, as reported in the MOP in the DIO message 📡
- All nodes who join a DODAG MUST abide by the MOP setting from the root. Nodes that do not have the capability to fully participate as a router, e.g., that do not match the advertised MOP, MAY join the DODAG as a leaf.
- If the MOP is 0, indicating no Downward routing, nodes MUST NOT transmit DAO messages and MAY ignore DAO messages.
- In Non-Storing mode, the DODAG root SHOULD store source routing table entries for destinations learned from DAOs. The DODAG root MUST be able to generate source routes for those destinations learned from DAOs that were stored.
- In Storing mode, all non-root, non-leaf nodes MUST store routing table entries for destinations learned from DAOs.
a DODAG can have one of several possible modes of operation, as defined by the MOP field 🧩. either it does not support Downward routes, it supports Downward routes through source routing from DODAG roots, or it supports Downward routes through in-network routing tables.
when Downward routes are supported through source routing from DODAG roots, it is generally expected that the DODAG root has stored the source routing information learned from DAOs in order to construct the source routes. if the DODAG root fails to store some information, then some destinations may be unreachable 😬
when Downward routes are supported through in-network routing tables, the multicast operation defined in this specification may or may not be supported, also as indicated by the MOP field 🤔
when Downward routes are supported through in-network routing tables, as described in this specification, it is expected that nodes acting as routers have been provisioned sufficiently to hold the required routing table state. if a node acting as a router is unable to hold the full routing table state, then the routing state is not complete, messages may be dropped as a consequence, and a fault may be logged (Section 18.5). future extensions to RPL may elaborate on refined actions/behaviors to manage this case 🛠️
as of the writing of this specification, RPL does not support mixed-mode operation, where some nodes source route and other store routing tables: future extensions to RPL may support this mode of operation 🌈💅
9.2.1. Maintenance of Path Sequence ✨
okay so every Target a node owns is that node's job 💅. It has to keep emitting DAO messages so the Downward routes actually get set up, and the Target+Transit info in those DAOs then travels Up the DODAG 🦋. The Path Sequence counter in the Transit information option is basically the freshness stamp 🎀. It tells everyone which Downward routing info is newer, so stale stuff can get replaced, as described in Section 7.
For a Target that a node owns, that node MUST increment the Path Sequence counter and generate a new DAO message when:
- the Path Lifetime is to be updated (e.g., a refresh or a no-Path).
- the DODAG Parent Address subfield list is to be changed.
For a Target that a node owns, that node MAY increment the Path Sequence counter and generate a new DAO message now and then to refresh the Downward routing info. In Storing mode, the node sends one of these to each of its DAO parents so multipath can happen 🌈. All DAOs generated at the same time for the same Target MUST be sent with the same Path Sequence in the Transit Information.
9.2.2. Generation of DAO Messages 🫶
A node might send DAOs when it receives DAOs, when its DAO parent set changes, or because of some other event like a related prefix lifetime expiring ⏳. When it comes to receiving DAOs, the big question is whether the DAO is "new" or actually has new info 👀. In Non-Storing mode, every DAO a node receives counts as "new". In Storing mode, a DAO is "new" if any of these is true for a Target it contains:
- it has a newer Path Sequence number,
- it has additional Path Control bits, or
- it is a No-Path DAO message that removes the last Downward route to a prefix.
A node that gets a DAO from its sub-DODAG MAY skip scheduling a DAO transmission if that DAO isn't new 😌.
9.3. DAO Base Rules 🎀
- If a node sends a DAO message with newer or different information than the prior DAO message transmission, it MUST increment the
DAOSequencefield by at least one. A DAO message transmission that is identical to the prior one MAY increment theDAOSequencefield. - The
RPLInstanceIDandDODAGIDfields of a DAO message MUST be the same value as the members of the node's parent set and the DIOs it transmits. - A node MAY set the
'K'flag in a unicast DAO message to solicit a unicast DAO-ACK in response in order to confirm the attempt. - A node receiving a unicast DAO message with the
'K'flag set SHOULD respond with a DAO-ACK. A node receiving a DAO message without the'K'flag set MAY respond with a DAO-ACK, especially to report an error condition. - A node that sets the
'K'flag in a unicast DAO message but does not receive a DAO-ACK in response MAY reschedule the DAO message transmission for another attempt, up until an implementation-specific number of retries. - Nodes SHOULD ignore DAOs without newer sequence numbers and MUST NOT process them further.
Unlike the Version field of a DIO, which is incremented only by a DODAG root and repeated unchanged by other nodes, DAOSequence values are unique to each node 🔢. The sequence number space for unicast and multicast DAO messages can be either the same or distinct. It is RECOMMENDED to use the same sequence number space ✨.
9.4. Structure of DAO Messages 🧩
DAOs follow a common structure in both storing and non-storing networks. In the most general form, a DAO message may include several groups of options, where each group consists of one or more Target options followed by one or more Transit Information options.
The entire group of Transit Information options applies to the entire group of Target options. Later sections describe further details for each mode of operation 💖.
- RPL nodes MUST include one or more RPL Target options in each DAO message they transmit. One RPL Target option MUST have a prefix that includes the node's IPv6 address if that node needs the DODAG to provision Downward routes to that node. The RPL Target option MAY be immediately followed by an opaque RPL Target Descriptor option that qualifies it.
- When a node updates the information in a Transit Information option for a Target option that covers one of its addresses, it MUST increment the Path Sequence number in that Transit Information option. The Path Sequence number MAY be incremented occasionally to cause a refresh to the Downward routes.
- One or more RPL Target options in a unicast DAO message MUST be followed by one or more Transit Information options. All the transit options apply to all the Target options that immediately precede them.
- Multicast DAOs MUST NOT include the DODAG Parent Address subfield in Transit Information options.
- A node that receives and processes a DAO message containing information for a specific Target, and that has prior information for that Target, MUST use the Path Sequence number in the Transit Information option associated with that Target to figure out whether the DAO message contains updated information per Section 7.
- If a node receives a DAO message that doesn't follow the above rules, it MUST discard the DAO message without further processing 🚫.
In Non-Storing mode, the root builds a strict source routing header, hop-by-hop, by recursively looking up one-hop info that ties a Target (address or prefix) and a transit address together 🗺️. Sometimes, when a child address is derived from a prefix that is owned and advertised by a parent, the root can infer that parent-child relationship to build the source routing header. In all other cases, the root needs to be told about the transit-Target relationship from a reachable target, so it can later build the routing header recursively 🔥. An address that is advertised as a Target in a DAO message MUST be collocated in the same router, or reachable on-link by the router that owns the address indicated in the associated Transit Information. The following extra rules keep the end-to-end source route path continuous:
- The address of a parent used in the transit option MUST be taken from a PIO from that parent with the
'R'flag set. The'R'flag in a PIO indicates that the prefix field actually contains the full parent address, but the child SHOULD NOT assume that the parent address is on-link. - A PIO with an
'A'flag set indicates that the RPL child node may use the prefix to autoconfigure an address. A parent that advertises a prefix in a PIO with the'A'flag set MUST ensure that the address or the whole prefix in the PIO is reachable from the root by advertising it as a DAO target. If the parent also sets the'L'flag indicating that the prefix is on-link, then it MUST advertise the whole prefix as Target in a DAO message. If the'L'flag is cleared and the'R'flag is set, indicating that the parent provides its own address in the PIO, then the parent MUST advertise that address as a DAO target. - An address that is advertised as Target in a DAO message MUST be collocated in the same router or reachable on-link by the router that owns the address that is indicated in the associated Transit Information.
- In order to enable an optimum compression of the routing header, the parent SHOULD set the
'R'flag in all PIOs with the'A'flag set and the'L'flag cleared, and the child SHOULD prefer to use as transit the address of the parent that is found in the PIO that is used to autoconfigure the address that is advertised as Target in the DAO message. - A router might have targets that are not known to be on-link for a parent, either because they are addresses located on an alternate interface or because they belong to nodes that are external to RPL, for instance connected hosts 🏠. In order to inject such a Target into the RPL network, the router MUST advertise itself as the DODAG Parent Address subfield in the Transit Information option for that target, using an address that is on-link for that node's DAO parent. If the Target belongs to an external node, then the router MUST set the External
'E'flag in the Transit Information.
A child node that has autoconfigured an address from a parent PIO with the 'L' flag set does not need to advertise that address as a DAO Target, since the parent ensures that the whole prefix is already reachable from the root 🙌. However, if the 'L' flag is not set, then it is necessary, in Non-Storing mode, for the child node to inform the root of the parent-child relationship, using a reachable address of the parent, so as to enable the recursive construction of the routing header. This is done by associating an address of the parent as transit with the address of the child as Target in a DAO message 💜.
9.5. DAO Transmission Scheduling ⏰
Because DAOs flow Upward, receiving a unicast DAO can trigger sending a unicast DAO to a DAO parent ⬆️.
- On receiving a unicast DAO message with updated information, such as containing a Transit Information option with a new Path Sequence, a node SHOULD send a DAO. It SHOULD NOT send this DAO message immediately. It SHOULD delay sending the DAO message in order to aggregate DAO information from other nodes for which it is a DAO parent.
- A node SHOULD delay sending a DAO message with a timer (
DelayDAO). Receiving a DAO message starts theDelayDAOtimer. DAO messages received while theDelayDAOtimer is active do not reset the timer. When theDelayDAOtimer expires, the node sends a DAO. - When a node adds a node to its DAO parent set, it SHOULD schedule a DAO message transmission.
DelayDAO's value and calculation is implementation dependent. A default value of DEFAULT_DAO_DELAY is defined in this specification 🧁.
9.6. Triggering DAO Messages 🔔
okay so nodes can literally ring the bell for their whole sub-DODAG and tell everyone to send DAOs 📣 Each node keeps a DAO Trigger Sequence Number (DTSN), and it shares that number through DIO messages 💖
- If a node hears one of its DAO parents increment its DTSN, the node MUST schedule a DAO message transmission using rules in Sections 9.3 and 9.5. 🫶
- In Non-Storing mode, if a node hears one of its DAO parents increment its DTSN, the node MUST increment its own DTSN. 🌈
In a Storing mode of operation, as part of routine routing table updates and maintenance, a storing node MAY increment DTSN in order to reliably trigger a set of DAO updates from its immediate children. 🧚 It's giving "gentle nudge" energy, not "everybody panic" energy 💅
In a Storing mode of operation, it is not necessary to trigger DAO updates from the entire sub-DODAG, since that state information will propagate hop-by-hop Up the DODAG. Like, the info already travels up the chain one hop at a time, so no need to bother the whole family 🦋
In a Non-Storing mode of operation, a DTSN increment will also cause the immediate children of a node to increment their DTSN in turn, triggering a set of DAO updates from the entire sub-DODAG. Typically, in a Non-Storing mode of operation, only the root would independently increment the DTSN when a DAO refresh is needed but a global repair (such as by incrementing DODAGVersionNumber) is not desired. Typically, in a Non-Storing mode of operation, all non-root nodes would increment their DTSN only when their parent(s) are observed to do so. The root is the only one who gets to start the drama on its own here 👑
In general, a node may trigger DAO updates according to implementation-specific logic, such as based on the detection of a Downward route inconsistency or occasionally based upon an internal timer. ⏰ Basically, you do you, bestie, as long as the logic is yours 🎀
In a storing network, selecting a proper DelayDAO for triggered DAOs can greatly reduce the number of DAOs transmitted. The trigger flows Down the DODAG; in the best case, the DAOs flow Up the DODAG such that leaves send DAOs first, with each node sending a DAO message only once. Such a scheduling could be approximated by setting DelayDAO inversely proportional to Rank. Note that this suggestion is intended as an optimization to allow efficient aggregation (it is not required for correct operation in the general case). ✨ Lowkey a major glow-up for efficiency, but it's a suggestion, not a rule 🌸
9.7. Non-Storing Mode 🦋
In Non-Storing mode, RPL routes messages Downward using IP source routing. The following rule applies to nodes that are in Non-Storing mode. Storing mode has a separate set of rules, described in Section 9.8. 🍓
- The DODAG Parent Address subfield of a Transit Information option MUST contain one or more addresses. All of these addresses MUST be addresses of DAO parents of the sender. 💜
- DAOs are sent directly to the root along a default route installed as part of the parent selection. 🚀
- When a node removes a node from its DAO parent set, it MAY generate a new DAO message with an updated Transit Information option. 🫧
In Non-Storing mode, a node uses DAOs to report its DAO parents to the DODAG root. The DODAG root can piece together a Downward route to a node by using DAO parent sets from each node in the route. The Path Sequence information may be used to detect stale DAO information. The purpose of this per-hop route calculation is to minimize traffic when DAO parents change. If nodes reported complete source routes, then on a DAO parent change, the entire sub-DODAG would have to send new DAOs to the DODAG root. Therefore, in Non-Storing mode, a node can send a single DAO, although it might choose to send more than one DAO message to each of multiple DAO parents. 🧩 Honestly the root doing the detective work is so iconic 🕵️♀️
Nodes pack DAOs by sending a single DAO message with multiple RPL Target options. Each RPL Target option has its own, immediately following, Transit Information options. 📦💅
9.8. Storing Mode 🌷
In Storing mode, RPL routes messages Downward by the IPv6 destination address. The following rules apply to nodes that are in Storing mode: 🌊
- The DODAG Parent Address subfield of a Transmit Information option MUST be empty. 🙈
- On receiving a unicast DAO, a node MUST compute if the DAO would change the set of prefixes that the node itself advertises. This computation SHOULD include consultation of the Path Sequence information in the Transit Information options associated with the DAO, to determine if the DAO message contains newer information that supersedes the information already stored at the node. If so, the node MUST generate a new DAO message and transmit it, following the rules in Section 9.5. Such a change includes receiving a No-Path DAO. 🔍
- When a node generates a new DAO, it SHOULD unicast it to each of its DAO parents. It MUST NOT unicast the DAO message to nodes that are not DAO parents. 💌
- When a node removes a node from its DAO parent set, it SHOULD send a No-Path DAO message (Section 6.4.3) to that removed DAO parent to invalidate the existing route. 🧹
- If messages to an advertised Downward address suffer from a forwarding error, Neighbor Unreachable Detection (NUD), or similar failure, a node MAY mark the address as unreachable and generate an appropriate No-Path DAO. 🥀
DAOs advertise to which destination addresses and prefixes a node has routes. Unlike in Non-Storing mode, these DAOs do not communicate information about the routes themselves: that information is stored within the network and is implicit from the IPv6 source address. When a storing node generates a DAO, it uses the stored state of DAOs it has received to produce a set of RPL Target options and their associated Transmit Information options. 🗂️
Because this information is stored within each node's routing tables, in Storing mode, DAOs are communicated directly to DAO parents, who store this information. 🫶
9.9. Path Control 🎀
A DAO message from a node contains one or more Target options. Each Target option specifies either a prefix advertised by the node, a prefix of addresses reachable outside the LLN, the address of a destination in the node's sub-DODAG, or a multicast group to which a node in the sub-DODAG is listening. The Path Control field of the Transit Information option allows nodes to request or allow for multiple Downward routes. A node constructs the Path Control field of a Transit Information option as follows: 🌈
- The bit width of the Path Control field MUST be equal to the value (PCS + 1), where PCS is specified in the control field of the DODAG Configuration option. Bits greater than or equal to the value (PCS + 1) MUST be cleared on transmission and MUST be ignored on reception. Bits below that value are considered "active" bits. 📏
- The node MUST logically construct groupings of its DAO parents while populating the Path Control field, where each group consists of DAO parents of equal preference. Those groups MUST then be ordered according to preference, which allows for a logical mapping of DAO parents onto Path Control subfields (see Figure 27). Groups MAY be repeated in order to extend over the entire bit width of the patch control field, but the order, including repeated groups, MUST be retained so that preference is properly communicated. 🗺️
- For a RPL Target option describing a node's own address or a prefix outside the LLN, at least one active bit of the Path Control field MUST be set. More active bits of the Path Control field MAY be set. ⭐
- If a node receives multiple DAOs with the same RPL Target option, it MUST bitwise-OR the Path Control fields it receives. This aggregated bitwise-OR represents the number of Downward routes the prefix requests. 🧮
- When a node sends a DAO message to one of its DAO parents, it MUST select one or more of the bits that are set active in the subfield that is mapped to the group containing that DAO parent from the aggregated Path Control field. A given bit can only be presented as active to one parent. The DAO message it transmits to its parent MUST have these active bits set and all other active bits cleared. 🍰
- For the RPL Target option and DAOSequence number, the DAOs a node sends to different DAO parents MUST have disjoint sets of active Path Control bits. A node MUST NOT set the same active bit on DAOs to two different DAO parents. 🚫
- Path Control bits SHOULD be allocated according to the preference mapping of DAO parents onto Path Control subfields, such that the active Path Control bits, or groupings of bits, that belong to a particular Path Control subfield are allocated to DAO parents within the group that was mapped to that subfield. 💫
- In a Non-Storing mode of operation, a node MAY pass DAOs through without performing any further processing on the Path Control field. 🌸
- A node MUST NOT unicast a DAO message that has no active bits in the Path Control field set. It is possible that, for a given Target option, a node does not have enough aggregate Path Control bits to send a DAO message containing that Target to each of its DAO parents, in which case those least preferred DAO Parents may not get a DAO message for that Target. 🥲
The Path Control field allows a node to bound how many Downward routes will be generated to it. It sets a number of bits in the Path Control field equal to the maximum number of Downward routes it prefers. At most, each bit is sent to one DAO parent; clusters of bits can be sent to a single DAO parent for it to divide among its own DAO parents. 🧁
A node that provisions a DAO route for a Target that has an associated Path Control field SHOULD use the content of that Path Control field in order to determine an order of preference among multiple alternative DAO routes for that Target. The Path Control field assignment is derived from preference (of the DAO parents), as determined on the basis of this node's best knowledge of the "end-to-end" aggregated metrics in the Downward direction as per the Objective Function. In Non-Storing mode the root can determine the Downward route by aggregating the information from each received DAO, which includes the Path Control indications of preferred DAO parents. 👑✨
9.9.1. Path Control Example 🧚
Okay so bestie, picture this 🌸 we've got an LLN running in Storing mode, and a Node N with four parents: P1, P2, P3, and P4. N also has three children in its sub-DODAG: C1, C2, and C3. Let PCS be 7, which means there are 8 active bits in the Path Control field: 11111111b ✨
The Path Control field gets split into four subfields: PC1 (11000000b), PC2 (00110000b), PC3 (00001100b), and PC4 (00000011b). Those four represent four different levels of preference (see Figure 27) 💅 N groups {P1, P2} as equal to each other AND the most preferred group overall. {P3} is less preferred than {P1, P2} but more preferred than {P4}. Then N does its mapping like this:
{P1, P2} -> PC1 (11000000b) in the Path Control field
{P3} -> PC2 (00110000b) in the Path Control field
{P4} -> PC3 (00001100b) in the Path Control field
{P4} -> PC4 (00000011b) in the Path Control fieldNotice that {P4} got repeated so the whole Path Control field gets full coverage 🫶
- C1 sends a DAO containing Target T with Path Control
10000000b. N stores10000000bas the Path Control field for C1 and Target T 💌 - C2 sends a DAO containing Target T with Path Control
00010000b. N stores00010000bas the Path Control field for C1 and Target T. - C3 sends a DAO containing Target T with Path Control
00001100b. N stores00001100bas the Path Control field for C1 and Target T. - Later on, N generates a DAO for Target T 🔥 It builds an aggregate Path Control field by ORing together the contribution from each child that sent a DAO for Target T. So the aggregate ends up with the active bits
10011100b. - N then spreads the aggregate Path Control bits across its parents P1, P2, P3, and P4 to prepare the DAO messages.
- P1 and P2 are eligible for the most preferred subfield (
11000000b), and the bits there are10000000bin the aggregate. N has to set that bit for only one of the two parents. Here P1 gets it, so P1's DAO has Path Control10000000b. There are no bits left for P2, so P2 would have00000000b, and a DAO can't be generated for P2 since there are no active bits 🥲 - The second-most preferred subfield (
00110000b) has active bits00010000b. N mapped P3 to this subfield, so N may allocate the active bit to P3, and then it builds a DAO for P3 containing Target T with Path Control00010000b. - The third-most preferred subfield (
00001100b) has active bits00001100b. N mapped P4 to this subfield, so N may allocate both bits to P4, and it builds a DAO for P4 containing Target T with Path Control00001100b. - The least preferred subfield (
00000011b) has no active bits. If there had been any, those bits would have been added to the Path Control field of the DAO built for P4. - Filling up the DAO messages for P1, P2, P3, and P4 with other targets (not T) works the same way, using the aggregate Path Control fields collected for those targets ✨
9.10. Multicast Destination Advertisement Messages 📣
Okay, this one is a special case of DAO operation, and it's totally different from unicast DAO operation. It's multicast DAO operation, and it can be used to fill up '1-hop' routing table entries 💜
- A node MAY multicast a DAO message to the link-local scope all-RPL-nodes multicast address.
- A multicast DAO message MUST be used only to advertise information about the node itself. That means prefixes directly connected to or owned by the node, like a multicast group the node is subscribed to or a global address the node owns 🎀
- A multicast DAO message MUST NOT be used to relay connectivity information the node learned from another node (for example, through a unicast DAO) 🙅
- A node MUST NOT perform any other DAO-related processing on a received multicast DAO message. In particular, a node MUST NOT perform the actions of a DAO parent when it receives a multicast DAO.
- Bonus: the multicast DAO may be used to enable direct P2P communication, so the packets don't need the DODAG to relay them 🦋
10. Security Mechanisms 🔐
This section is all about how secure RPL messages get generated and processed. The high-order bit of the RPL message code tells you whether or not an RPL message is secure. On top of secure versions of the basic control messages (DIS, DIO, DAO, and DAO-ACK), RPL has a few messages that only matter in networks with security turned on 🌈
Implementation complexity and size are a huge deal for LLNs. That means it could be economically or physically impossible to fit sophisticated security stuff into an RPL implementation. Plus, lots of deployments can use link-layer or other security mechanisms to meet their security needs without using RPL security at all 🙈
So, the security features in this document are OPTIONAL to implement. An implementation MAY support a subset of the described security features (even the empty set). For example, it could support integrity and confidentiality but not signatures. An implementation SHOULD clearly specify which security mechanisms it supports, and it is RECOMMENDED that implementers carefully think about their security requirements and what security mechanisms their network has available 🧐
10.1. Security Overview 🛡️
RPL supports three security modes:
- Unsecured. In this mode, RPL uses the basic DIS, DIO, DAO, and DAO-ACK messages, which don't have Security sections. Since a network could be using other security mechanisms, like link-layer security, unsecured mode doesn't mean every message is sent with zero protection 🤷♀️
- Preinstalled. In this mode, RPL uses secure messages. To join an RPL Instance, a node must have a preinstalled key. Nodes use that key to provide message confidentiality, integrity, and authenticity. With this preinstalled key, a node may join the RPL network as either a host or a router 💖
- Authenticated. In this mode, RPL also uses secure messages. To join an RPL Instance, a node must have a preinstalled key, and nodes use it to provide message confidentiality, integrity, and authenticity. With that preinstalled key, a node may join the network as a host only. To join as a router, a node must get a second key from a key authority. The key authority can check that the requester is allowed to be a router before handing over the second key 👑 Authenticated mode can't be supported by symmetric algorithms. As of writing this spec, RPL only supports symmetric algorithms, so authenticated mode is there for the benefit of potential future cryptographic primitives. See Section 10.3.
Whether or not an RPL Instance uses unsecured mode is signaled by whether it uses secure RPL messages. Whether a secured network uses preinstalled or authenticated mode is signaled by the 'A' bit of the DAG Configuration option ✨
This spec uses CCM (Counter with CBC-MAC, which is short for Cipher Block Chaining - Message Authentication Code) as the cryptographic basis for RPL security [RFC3610]. In this spec, CCM uses AES-128 as its underlying cryptographic algorithm. There are bits reserved in the Security section so other algorithms can be specified in the future 🔮
All secured RPL messages have either a MAC or a signature. Secured RPL messages can optionally also have encryption protection for confidentiality. Secured RPL message formats support both integrated encryption/authentication schemes (like CCM) and schemes that encrypt and authenticate packets separately 🫶
10.2. Joining a Secure Network 🚪
RPL security assumes that a node wanting to join a secured network has been pre-configured with a shared key for talking to its neighbors and the RPL root. To join a secure RPL network, a node either listens for secure DIOs or triggers them by sending a secure DIS. On top of the DIO/DIS rules in Section 8, secure DIO and DIS messages have these rules:
- If sent, this initial secure DIS MUST set the Key Identifier Mode field to 0 (00) and MUST set the Security Level field to 1 (001). The key used MUST be the pre-configured group key (Key Index
0x00). - When a node resets its Trickle timer in response to a secure DIS (Section 8.3), the next DIO it transmits MUST be a secure DIO with the same security configuration as the secure DIS. If a node gets multiple secure DIS messages before it transmits a DIO, the secure DIO MUST have the same security configuration as the last DIS it's responding to.
- When a node sends a DIO in response to a unicast secure DIS (Section 8.3), the DIO MUST be a secure DIO.
These rules let a node join a secured RPL Instance using the pre-configured shared key. Once a node has joined the DODAG with that shared key, the 'A' bit of the Configuration option decides what it's allowed to do. If the 'A' bit of the Configuration option is cleared, nodes can use this preinstalled shared key to exchange messages normally, meaning they can issue DIOs, DAOs, and so on 🙌
If the 'A' bit of the Configuration option is set and the RPL Instance is operating in authenticated mode:
- A node MUST NOT advertise a Rank besides INFINITE_RANK in secure DIOs secured with Key Index
0x00. When a processing node receives DIO messages secured with Key Index0x00, it MUST consider the advertised Rank to be INFINITE_RANK. Any other value results in the message being discarded 🚫 - Secure DAOs using Key Index
0x00MUST NOT have an RPL Target option with a prefix other than the node's address. If a node receives a secured DAO using the preinstalled shared key where the RPL Target option doesn't match the IPv6 source address, it MUST discard that secured DAO without any further processing 💀
Put together, these rules mean that in RPL Instances where the 'A' bit is set and Key Index 0x00 is in use, a node can join the RPL Instance as a host but not as a router. To get a key that lets it act as a router, a node has to talk to a key authority 🧚
10.3. Installing Keys 🗝️
Authenticated mode needs a would-be router to dynamically install new keys once it has joined the network as a host. After joining as a host, the node uses standard IP messaging to talk to an authorization server, which can hand out new keys.
The protocol for getting those keys is out of scope for this spec and will be worked out in future specifications. That elaboration is required for RPL to operate securely in authenticated mode 🥹
10.4. Consistency Checks 🔐
okay so RPL nodes send these things called Consistency Check (CC) messages 💅 and their whole job is to protect against replay attacks (the worst 😭) and keep counters in sync 🔄
- If a node receives a unicast CC message with the
'R'bit cleared, and it is a member of or is in the process of joining the associated DODAG, it SHOULD respond with a unicast CC message to the sender. This response MUST have the'R'bit set, and it MUST have the same CC nonce,RPLInstanceID, andDODAGIDfields as the message it received. 🎀 - If a node receives a multicast CC message, it MUST discard the message with no further processing. 🙅♀️
Consistency Check messages let nodes do a challenge-response to check a node's current counter value 🧐 Because the CC nonce is made by the challenger, an adversary replaying messages is unlikely to be able to produce a correct response 💀 And the counter in the Consistency Check response lets the challenger validate the counters it hears 🫶
10.5. Counters ⏰
okay counters, the simplest version is just an unsigned integer that a node bumps up by one or more on each secured RPL transmission ✨ The counter MAY represent a timestamp too, and if it does, these rules apply 👑
- The timestamp MUST be at least six octets long. 📏
- The timestamp MUST be in 1024 Hz (binary millisecond) granularity. ⏱️
- The timestamp start time MUST be January 1, 1970, 12:00:00AM UTC. 🗓️
- If the counter represents a timestamp, the counter value MUST be a value computed as follows. Let
Tbe the timestamp,Sbe the start time of the key in use, andEbe the end time of the key in use. BothSandEare represented using the same three rules as the timestamp described above. IfE > T < S, then the counter is invalid and a node MUST NOT generate a packet. Otherwise, the counter value is equal toT-S. 🧮💅 - If the counter represents such a timestamp, a node MAY set the
'T'flag of the Security section of secured RPL packets. 🚩 - If the Counter field does not present such a timestamp, then a node MUST NOT set the
'T'flag. 🙈 - If a node does not have a local timestamp that satisfies the above requirements, it MUST ignore the
'T'flag. 🫠
If a node supports these timestamps and gets a message with the 'T' flag set, it MAY apply the temporal check on the received message described in Section 10.7.1 ✨ If a node gets a message without the 'T' flag set, it MUST NOT apply this temporal check 🚫 And a node's security policy MAY, for application reasons, include rejecting all messages without the 'T' flag set 🌸
The 'T' flag is there because lots of LLNs today already keep global time synchronization at sub-millisecond granularity for security, application, and other reasons 🤯 Letting RPL use that existing stuff when it's around makes solutions to some security problems, like delay protection, way simpler 🦋
10.6. Transmission of Outgoing Packets 📤
okay so, given an outgoing RPL control packet and the security protection it needs, this section explains how RPL builds the secured packet to send 💌 It also covers the order of the crypto operations that give the protection 🔐
The security protection requirement and the level of security for an outgoing RPL packet shall be determined by the node's security policy database 💼 How that database is set up for outgoing packet processing is implementation specific 🛠️
When secured RPL messages are going out, an RPL node MUST set the Security section (T, Sec, KIM, and LVL) in the outgoing RPL packet so it describes the protection level and security settings being applied (see Section 6.1) 💖 The Security subfield bit of the RPL Message Code field MUST be set to show it's a secure RPL message 🔒
The counter value used when building the AES-128 CCM nonce (Figure 31) to secure the outgoing packet MUST be an increment of the last counter sent to that particular destination address ⬆️
If security policy says delay protection applies, the Timestamp counter used to build the CCM nonce for the outgoing packet MUST be incremented according to the rules in Section 10.5 ⏰ When a Timestamp counter is applied (the 'T' flag is set), the locally maintained Timestamp counter MUST be included as part of the transmitted secured RPL message 🎀
The cryptographic algorithm used to secure the outgoing packet shall be specified by the node's security policy database, and it MUST be indicated in the value of the Sec field set within the outgoing message 🧁
The security policy for the outgoing packet shall decide the KIM and the Key Identifier that says which security key gets used for the crypto packet processing, including the optional use of signature keys (see Section 6.1) 🗝️ The security policy will also specify the algorithm (Algorithm) and the level of protection (Level), either as authentication or as authentication and encryption, plus any potential use of signatures that shall apply to the outgoing packet ✨
When encryption is applied, a node MUST replace the original packet payload with that payload encrypted using the security protection, key, and CCM nonce specified in the Security section of the packet 🤫
All secured RPL messages include integrity protection 🛡️ As part of the security algorithm processing, a node derives either a MAC or a signature, and that MUST be included as part of the outgoing secured RPL packet 🫶
10.7. Reception of Incoming Packets 📥
this section is all about how a secured RPL packet gets received and processed 👀 Given an incoming secured RPL packet where the Security subfield bit of the RPL Message Code field is set, this section explains how RPL makes an unencrypted version of the packet and checks its integrity 💅
The receiver uses the RPL security control fields to work out what packet security processing it needs 🔍 If the security level for the message type and originator is unknown, or it doesn't meet locally maintained security policies, a node MUST discard the packet without further processing, MAY raise a management alert, and MUST NOT send any messages in response 🚨 These policies can include security levels, keys used, source identifiers, or the lack of timestamp-based counters (as shown by the 'T' flag) 🙃 How the security policy database gets configured for incoming packet processing is out of scope for this specification (it could be defined through DIO Configuration or through out-of-band administrative router configuration, for example) 🧚
When the message Security Level (LVL) shows an encrypted RPL message, the node uses the key information identified through the KIM field and the CCM nonce as input to the message payload decryption processing 🗝️ The CCM nonce shall be derived from the message Counter field and other received and locally maintained information (see Section 10.9.1) ✨ The plaintext message contents shall be obtained by invoking the inverse cryptographic mode of operation specified by the Sec field of the received packet 🌈
The receiver shall use the CCM nonce and the identified key information to check the integrity of the incoming packet 🔎 If the integrity check fails against the received MAC, a node MUST discard the packet 🗑️
If the received message has an initialized (zero value) counter value and the receiver has an incoming counter currently maintained for the message's originator, the receiver MUST start a counter resynchronization by sending a Consistency Check response message (see Section 6.6) to the message source 🔄 The Consistency Check response message shall be protected with the current full outgoing counter maintained for that particular node address 🛡️ That outgoing counter gets included in the security section of the message, while the incoming counter gets included in the Consistency Check message payload 💌
Based on the specified security policy, a node MAY apply replay protection for a received RPL message 🪞 The replay check SHOULD be done before the received packet gets authenticated 🙌 The counter, as taken from the incoming packet, shall be compared against the watermark of the incoming counter maintained for the given origination node address 📊 If the received message counter value is non-zero and less than the maintained incoming counter watermark, a potential packet replay is indicated and the node MUST discard the incoming packet 🚫
If delay protection is part of the incoming packet security policy checks, the Timestamp counter is used to validate how timely the received RPL message is ⏳ If the incoming message Timestamp counter value shows a transmission time earlier than the locally maintained transmission time counter for the originator address, a replay violation is indicated and the node MUST discard the incoming packet 💥 If the received Timestamp counter value shows a transmission time earlier than the Current time less the acceptable packet delay, a delay violation is indicated and the node MUST discard the incoming packet 😭
Once a message has been decrypted (where that applies) and has passed its integrity check, replay check, and optionally its delay-protection checks, the node can update its local security information, like the source's expected counter value for replay comparison 📝
A node MUST NOT update its security information when it gets a message that fails security policy checks or any other applied integrity, replay, or delay checks 🙅♀️✨
10.7.1. Timestamp Key Checks ⌚
if the 'T' flag of a message is set and a node has a local timestamp that follows the requirements in Section 10.5, then the node MAY check the temporal consistency of the message 🧠 It works out the transmit time of the message by adding the counter value to the start time of the associated key ➕ If that transmit time is past the end time of the key, the node MAY discard the message without further processing 🗑️ And if the transmit time is too far in the past or future compared to the local time on the receiver, it MAY discard the message without further processing 🕰️💀
10.8. Coverage of Integrity and Confidentiality ✨
okay so for a RPL ICMPv6 message, the entire packet is in scope for RPL security 🔐 no cap, every byte counts 💅
MACs and signatures get calculated over the entire unsecured IPv6 packet 🧁 when computing them, the mutable IPv6 fields are treated as filled with zeroes, following the rules in Section 3.3.3.1 of [RFC4302] (IPsec Authenticated Header) 🦋 and the MAC and signature calculations happen before any compression that lower layers might apply 🫶
when a RPL ICMPv6 message is encrypted, the encryption starts at the first byte after the Security section and keeps going to the last byte of the packet 🌸 the IPv6 header, the ICMPv6 header, and the RPL message up to the end of the Security section stay unencrypted, bc they're needed to correctly decrypt the packet 🔓 it's giving teamwork 🤝
for example, a node sending a message with LVL=1, KIM=0, and Algorithm=0 uses the CCM algorithm [RFC3610] to create a packet with attributes ENC-MAC-32 💜 it encrypts the packet and appends a 32-bit MAC ✨ the block cipher key is determined by the Key Index 🗝️ the CCM nonce is computed as described in Section 10.9.1 🎀 the message to authenticate and encrypt is the RPL message starting at the first byte after the Security section and ending with the last byte of the packet 🍓 and the additional authentication data starts with the beginning of the IPv6 header and ends with the last byte of the RPL Security section 🌈 iconic layering, honestly 👑
10.9. Cryptographic Mode of Operation 🎀
the cryptographic mode of operation described in this specification (Algorithm = 0) is based on CCM and the block-cipher AES-128 [RFC3610] 🔥 this mode is widely supported by existing implementations, so it's a safe pick 🫶 CCM mode requires a nonce (CCM nonce) 🧚
10.9.1. CCM Nonce 💖
a RPL node constructs a CCM nonce like this 👇
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Source Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|KIM|Resvd| LVL |
+-+-+-+-+-+-+-+-+
Figure 31: CCM Noncehere's the breakdown, it's lowkey simple 🧸
Source Identifier: 8 bytes 🪪 it's set to the logical identifier of the originator of the protected packet 💌Counter: 4 bytes 🔢 it's set to the (uncompressed) value of the corresponding field in the Security option of the RPL control message 📨Key Identifier Mode (KIM): 2 bits 🎫 it's set to the value of the corresponding field in the Security option of the RPL control message 💫Security Level (LVL): 3 bits 📶 it's set to the value of the corresponding field in the Security option of the RPL control message ⭐
the unassigned bits of the CCM nonce are reserved 🙈 they MUST be set to zero when constructing the CCM nonce, no exceptions bestie 🚫
all fields of the CCM nonce are represented in most significant octet and most significant bit first order 🧠
10.9.2. Signatures ✍️
if the KIM indicates the use of signatures (a value of 3), then a node appends a signature to the data payload of the packet 💖 the Security Level (LVL) field describes the length of this signature 📏 the signature scheme in RPL for Security Mode 3 is an instantiation of the RSA algorithm (RSASSA-PSS) as defined in Section 8.1 of [RFC3447] 🦋 as the public key, it uses the pair (n,e), where n is a 2048-bit or 3072-bit RSA modulus and where e=2^{16}+1 🌸 it uses CCM mode [RFC3610] as the encryption scheme with M=0 (as a stream-cipher) 🌊
note that although [RFC3610] disallows CCM mode with M=0, RPL explicitly allows CCM mode with M=0 when it's used in conjunction with a signature, because the signature provides sufficient data authentication 🫶 so the CCM mode with M=0 is specified as in [RFC3610], but where the M' field in Section 2.2 MUST be set to 0 💅 it uses the SHA-256 hash function specified in Section 6.2 of [FIPS180] 🔐 and it uses the message encoding rules of Section 8.1 of [RFC3447] 📜
let 'a' be a concatenation of a 6-byte representation of counter and the message header 🧩 the packet payload is the right-concatenation of packet data 'm' and the signature 's' 🎁 this signature scheme is invoked with the right-concatenation of the message parts a and m, whereas signature verification is invoked with the right-concatenation of the message parts a and m and with signature s 🔄
RSA signatures of this form provide sufficient protection for RPL networks 💪 if alternative signature schemes that produce more concise signatures are needed, that's out of scope for this specification and may be the subject of a future specification 🔮
an implementation that supports RSA signing with either 2048-bit or 3072-bit signatures SHOULD support verification of both 2048-bit and 3072-bit RSA signatures 🌈 this is in consideration of providing an upgrade path for a RPL deployment, so future-you says thanks 🫶
11. Packet Forwarding and Loop Avoidance/Detection 🦋
11.1. Suggestions for Packet Forwarding 🧭
this document specifies a routing protocol 📡 these non-normative suggestions are here to help design a forwarding implementation by showing how one could work with RPL 🛠️
when forwarding a packet to a destination, precedence goes to selecting a next-hop successor like this 👇
- this specification only covers how a successor is selected from the DODAG Version that matches the RPLInstanceID marked in the IPv6 header of the packet being forwarded 🎯 routing outside the instance can be done as long as additional rules are put in place, such as strict ordering of instances and routing protocols to protect against loops 🔁 such rules may be defined in a separate document 📄
- if a local administrative preference favors a route learned from a different routing protocol than RPL, then use that successor 👑
- if the packet header specifies a source route by including an RH4 header as specified in [RFC6554], then use that route 🗺️ if the node fails to forward the packet with that specified source route, then that packet should be dropped 💀 the node MAY log an error 📝 the node may send an ICMPv6 error in Source Routing Header message to the source of the packet (see Section 20.18) 📬
- if there's an entry in the routing table matching the destination that has been learned from a multicast destination advertisement (e.g., the destination is a one-hop neighbor), then use that successor 🏠
- if there's an entry in the routing table matching the destination that has been learned from a unicast destination advertisement (e.g., the destination is located Down the sub-DODAG), then use that successor ⬇️ if there are DAO Path Control bits associated with multiple successors, then consult the Path Control bits to order the successors by preference when choosing 🎚️ if, for a given DAO Path Control bit, multiple successors are recorded as having asserted that bit, precedence should be given to the successor who most recently asserted that bit ⏰
- if there's a DODAG Version offering a route to a prefix matching the destination, then select one of those DODAG parents as a successor according to the OF and routing metrics 📊
- any other as-yet-unattempted DODAG parent may be chosen for the next attempt to forward a unicast packet when no better match exists 🔄
- finally, the packet is dropped 😭 ICMP Destination Unreachable MAY be invoked (an inconsistency is detected) 🚨
Hop Limit MUST be decremented when forwarding per [RFC2460] ⏳
note that the chosen successor MUST NOT be the neighbor that was the predecessor of the packet (split horizon) 🙅♀️ the only exception is when it's intended for the packet to change from an Upward to a Downward direction, as determined by the routing table of the node making the change, such as switching from DIO routes to DAO routes as the destination is neared, so it can keep traveling toward the destination 🎀
11.2. Loop Avoidance and Detection 🔁
RPL loop avoidance mechanisms are kept simple and designed to minimize churn and state 🧘♀️ loops can form for a number of reasons, e.g., control packet loss 📉 RPL includes a reactive loop detection technique that protects against meltdown and triggers repair of broken paths 🛠️
RPL loop detection uses RPL Packet Information that's carried within the data packets 📦 it relies on an external mechanism such as [RFC6553], which places the RPL Packet Information in an IPv6 Hop-by-Hop option header 🎟️
the content of RPL Packet Information is defined like this 👇
Down 'O': 1-bit flag indicating whether the packet is expected to progress Up or Down 🧭 a router sets the 'O' flag when the packet is expected to progress Down (using DAO routes), and clears it when forwarding toward the DODAG root (to a node with a lower Rank) ⬆️⬇️ a host or RPL leaf node MUST set the 'O' flag to 0 🙅♀️Rank-Error 'R': 1-bit flag indicating whether a Rank error was detected 🚩 a Rank error is detected when there is a mismatch in the relative Ranks and the direction as indicated in the 'O' bit 📐 a host or RPL leaf node MUST set the 'R' bit to 0 🫧Forwarding-Error 'F': 1-bit flag indicating that this node cannot forward the packet further towards the destination 🧱 the 'F' bit might be set by a child node that does not have a route to the destination for a packet with the Down 'O' bit set 👶 a host or RPL leaf node MUST set the 'F' bit to 0 🌷RPLInstanceID: 8-bit field indicating the DODAG instance along which the packet is sent 🆔SenderRank: 16-bit field set to zero by the source and to DAGRank(rank) by a router that forwards inside the RPL network 🏷️
11.2.1. Source Node Operation 🚀
if the source is aware of the RPLInstanceID that is preferred for the packet, then it MUST set the RPLInstanceID field associated with the packet accordingly 🎯 otherwise, it MUST set it to the RPL_DEFAULT_INSTANCE 💖
11.2.2. Router Operation 🌸
11.2.2.1. Instance Forwarding 🦋
okay so the source attaches an RPLInstanceID to the packet 🎀 and this RPLInstanceID MUST match the RPL Instance that the packet gets placed onto by any node, be it a host or a router. It's part of the RPL Packet Information, so it's giving "tag the packet and don't lose the tag" 💅
A RPL router that forwards a packet in the RPL network MUST check if the packet includes the RPL Packet Information. If it doesn't, the RPL router MUST insert it. And if the router is an ingress router (the one bringing the packet into the RPL network), it MUST set the RPLInstanceID field in the RPL Packet Information. How that router decides which RPLInstanceID to map to is out of scope for this spec and left for a future one 🧚
A router that forwards a packet outside the RPL network MUST remove the RPL Packet Information. Bye bye, tag 👋
When a router gets a packet that specifies a given RPLInstanceID, and the node can forward it along the DODAG tied to that instance, then the router MUST do so and leave the RPLInstanceID value unchanged. No switcheroos allowed 🙅♀️
If any node can't forward a packet along the DODAG associated with the RPLInstanceID, then the node SHOULD discard the packet and send an ICMP error message. ngl this one is a whole vibe 💀
11.2.2.2. DAG Inconsistency Loop Detection 🔥
So the DODAG is inconsistent when a packet's direction doesn't match the Rank relationship. A receiver catches an inconsistency if it gets a packet with either of these:
- the
'O'bit set (to Down) from a node of a higher Rank. - the
'O'bit cleared (for Up) from a node of a lower Rank.
Now, when the DODAG root bumps the DODAGVersionNumber, a temporary Rank discontinuity can form between the next DODAG Version and the prior one 🌈 This happens especially if nodes are adjusting their Rank in the next DODAG Version and putting off their migration into it. A router that's still a member of the prior DODAG Version might choose to forward a packet to a (future) parent that's already in the next DODAG Version. In some cases, that can make the parent detect an inconsistency, because the Rank-ordering in the prior DODAG Version isn't necessarily the same as in the next one. The packet might then look like it isn't making forward progress 😭 If the sending router knows the chosen successor has already joined the next DODAG Version, then the sending router MUST update the SenderRank to INFINITE_RANK as it forwards the packets across the discontinuity into the next DODAG Version. That way, you avoid a false detection of Rank inconsistency. Iconic behaviour ✨
One inconsistency along the path isn't treated as a critical error, and the packet can keep going. BUT a second detection along the path of the same packet should not occur, and the packet MUST be dropped 🙈
All of this is controlled by the Rank-Error bit on the packet. When an inconsistency is detected on a packet, if the Rank-Error bit wasn't set, then it gets set. If it was already set, the packet MUST be discarded and the Trickle timer MUST be reset. Periodt 💜
11.2.2.3. DAO Inconsistency Detection and Recovery 🌸
DAO inconsistency loop recovery is a mechanism that only applies to the Storing mode of operation.
In Non-Storing mode, packets are source routed to the destination, so DAO inconsistencies aren't fixed locally. Instead, an ICMP error with a new code, "Error in Source Routing Header", gets sent back to the root. That message has the same format as the "Destination Unreachable Message" from [RFC4443]. The part of the invoking packet that goes back in the ICMP message should record at least up to the routing header, and the routing header should be consumed by this node, so the destination in the IPv6 header is the next hop this node couldn't reach 🧭
A DAO inconsistency happens when a router has a Downward route that it learned from a DAO message via a child, but that Downward route isn't valid anymore in the child. For example, the related state in the child has been cleaned up. With DAO inconsistency loop recovery, a packet can be used to recursively explore and clean up the obsolete DAO states along a sub-DODAG. Detective energy 🕵️♀️
Generally speaking, a packet that goes Down should never go Up again. If DAO inconsistency loop recovery is applied, then the router SHOULD send the packet back to the parent that passed it to it, with the Forwarding-Error 'F' bit set and the 'O' bit left untouched. Otherwise, the router MUST silently discard the packet 🤫
When a node receives a packet with a Forwarding-Error bit set, the node MUST remove the routing states that caused forwarding to that neighbor, clear the Forwarding-Error bit, and attempt to send the packet again. The packet may be sent to an alternate neighbor after an user-configurable implementation-specific timer expires. If that alternate neighbor still has an inconsistent DAO state via this node, the process recurses: this node sets the Forwarding-Error 'F' bit, and the routing state in the alternate neighbor gets cleaned up as well 🔁
12. Multicast Operation ✨
This section describes a multicast routing operation over an IPv6 RPL network, and specifically how unicast DAOs can be used to relay group registrations. The same DODAG construct can be used to forward both unicast and multicast traffic 🦋 This section is limited to describing how group registrations may be exchanged and how the forwarding infrastructure operates. It does NOT give a full description of multicast within an LLN. In particular, it doesn't cover generating DODAGs specifically targeted at multicast, or the details of operating RPL for multicast -- that's the subject of further specifications 📚
The multicast group registration uses DAO messages that are identical to unicast ones, except for the type of address that gets transported. The main difference is that multicast traffic going down is copied to all the children that have registered with the multicast group, whereas unicast traffic is passed to one child only 🌈
Nodes that support the RPL Storing mode of operation SHOULD also support multicast DAO operations, as described below. Nodes that only support the Non-Storing mode of operation are not expected to support this section 🍓
The multicast operation is controlled by the MOP field in the DIO.
- If the
MOPfield requires multicast support, then a node that joins the RPL network as a router must operate as described in this section for multicast signaling and forwarding within the RPL network. A node that doesn't support the multicast operation required by theMOPfield can only join as a leaf. - If the
MOPfield does not require multicast support, then multicast is handled some other way that's out of scope for this spec. (Examples might include a series of unicast copies or limited-scope flooding.)
A router might choose to pass a listener registration DAO message to its preferred parent only. In that case, multicast packets coming back might get lost for all of its sub-DODAGs if the transmission fails over that link 😬 Alternatively, the router might choose to copy the message to additional parents, the same way it would for DAO messages advertising unicast destinations. In that case, there might be duplicates, and the router will need to prune them 🧹
So, multicast routing states get installed in each router on the way from the listeners to the DODAG root. This lets the root copy a multicast packet to all of its children routers that issued a DAO message including a Target option for that multicast group. 🎯
For a multicast packet sourced from inside the DODAG, the packet is passed to the preferred parents, and if that fails, then to the alternates in the DODAG. The packet is also copied to all the registered children, except for the one that passed the packet. Finally, if there's a listener in the external infrastructure, the DODAG root has to further propagate the packet into that infrastructure 🌐
Basically, the DODAG root acts as an automatic proxy Rendezvous Point for the RPL network, and as the source towards the non-RPL domain for all multicast flows started in the RPL domain. So, whether or not the root is actually attached to a non-RPL domain, and whether the DODAG is grounded or floating, the root can serve inner multicast streams at all times 👑
13. Maintenance of Routing Adjacency 🧚
Choosing successors, either along the default paths Up the DODAG or along the paths learned from destination advertisements Down the DODAG, leads to the formation of routing adjacencies. Those adjacencies need maintenance 🔧
In IGPs, such as OSPF [RFC4915] or IS-IS [RFC5120], maintaining a routing adjacency involves keepalive mechanisms (Hellos) or other protocols, such as Bidirectional Forwarding Detection (BFD) [RFC5881] and the MANET Neighborhood Discovery Protocol (NHDP) [RFC6130]. Unfortunately, that kind of proactive approach is often not desirable in constrained environments. It would lead to excessive control traffic compared to the data traffic, which hurts both link loads and node resources 😩
RPL, by contrast, does not define any keepalive mechanisms to detect routing adjacency failures. This is because in many cases such a mechanism would be too expensive in terms of bandwidth and, even more importantly, energy. A battery-operated device couldn't afford to send periodic keepalives 🔋 Still, RPL requires an external mechanism to detect that a neighbor is no longer reachable. Ideally, that mechanism is reactive to traffic, so it minimizes the overhead of maintaining the routing adjacency and focuses on links that are actually being used 💖
Example reactive mechanisms that can be used include:
- The Neighbor Unreachability Detection [RFC4861] mechanism.
- Layer 2 triggers [RFC5184], derived from events such as association states and L2 acknowledgements.
14. Guidelines for Objective Functions 🎀
An Objective Function (OF), in conjunction with routing metrics and constraints, allows a node to select a DODAG to join, plus a number of peers in that DODAG to use as parents. The OF is used to compute an ordered list of parents. It's also responsible for computing the Rank of the device within the DODAG Version 📊
The Objective Function is indicated in the DIO message using an Objective Code Point (OCP), and the OCP indicates the method that must be used to construct the DODAG. The Objective Code Points are specified in [RFC6552] and related companion specifications ⭐
14.1. Objective Function Behavior ✨
okay so most Objective Functions (OFs) follow the same basic routine at a node, and it's giving very predictable 💅
- The parent selection gets triggered every time an event says that potential next-hop information was updated 🔄. That could be when a DIO message comes in, a timer elapses, all the DODAG parents are unavailable, or a trigger says a candidate neighbor's state changed.
- An OF scans all the interfaces on the node 👀. There's usually only one interface in most application scenarios, but there might be several, and an interface might be configured as usable or not usable for RPL operation. An interface can also get a preference, or it can be dynamically learned to be better than another through some heuristics. Those heuristics might depend on the link layer and are out of scope for this specification 🙈. An interface might or might not match a required criterion for an OF, like a degree of security. So some interfaces might get completely excluded from the computation, for example if they can't satisfy some advertised constraints, while others might be more or less preferred.
- An OF scans all the candidate neighbors on the possible interfaces to check whether they can act as a router for a DODAG 🔍. There might be lots of them, and a candidate neighbor might need to pass some validation tests before it can be used. Some link layers need experience with a router's activity before they'll enable that router as a next hop, so that's a whole thing too.
- An OF computes the Rank of a node for comparison by adding, to the Rank of the candidate, a value that represents the relative locations of the node and the candidate in the DODAG Version 🧠.
- The increase in Rank must be at least
MinHopRankIncrease. - To keep loop avoidance and metric optimization in alignment, the increase in Rank should reflect any increase in the metric value. For example, with a purely additive metric like ETX, the increase in Rank can be made proportional to the increase in the metric 📈.
- Candidate neighbors that would cause the Rank of the node to increase are not considered for parent selection 🚫.
- The increase in Rank must be at least
- Candidate neighbors that advertise an OF that's incompatible with the set of OFs specified by the policy functions get ignored 🙅♀️.
- As it scans all the candidate neighbors, the OF keeps the current best parent and compares its capabilities with the current candidate neighbor 🥇. The OF defines a number of tests that are critical to reach the objective. A test between the routers determines an order relation.
- If the routers are equal for that relation, then the next test is attempted between the routers.
- Else, the best of the two routers becomes the current best parent, and the scan continues with the next candidate neighbor.
- Some OFs may include a test to compare the Ranks that would result if the node joined either router.
- When the scan is complete, the preferred parent is elected, and the node's Rank is computed as the preferred parent Rank plus the step in Rank with that parent 🎉.
- Other rounds of scans might be necessary to elect alternate parents. In the next rounds:
- Candidate neighbors that are not in the same DODAG are ignored.
- Candidate neighbors that are of greater Rank than the node are ignored.
- Candidate neighbors of an equal Rank to the node are ignored for parent selection.
- Candidate neighbors of a lesser Rank than the node are preferred 💜.
15. Suggestions for Interoperation with Neighbor Discovery 🧚
okay so this specification directly borrows the Prefix Information Option (PIO) and the Route Information Option (RIO) from IPv6 ND 🎀. It's envisioned that, as future specs build on this base, there may be more reasons to leverage parts of IPv6 ND. This section gives some suggestions for those future specs.
First and foremost, RPL is a routing protocol 🛣️. You should take great care to preserve architecture when mapping functionalities between RPL and ND. RPL is for routing only. That said, there may be persuading technical reasons to allow sharing options between RPL and IPv6 ND in a particular implementation or deployment.
In general, the following guidelines apply:
- RPL Type codes must be allocated from the RPL Control Message Options registry.
- RPL Length fields must be expressed in units of single octets, as opposed to ND Length fields, which are expressed in units of 8 octets 📏.
- RPL options are generally not required to be aligned to 8-octet boundaries.
- When mapping or transposing an IPv6 ND option for redistribution as a RPL option, any padding octets should be removed when possible. For example, the Prefix Length field in the PIO is sufficient to describe the length of the Prefix field. When mapping or transposing a RPL option for redistribution as an IPv6 ND option, any such padding octets should be restored. This procedure must be unambiguous 🔐.
16. Summary of Requirements for Interoperable Implementations 💖
this section is the cheat sheet 📝. It summarizes basic interoperability and points to the normative text for RPL implementations running in one of three major modes. Implementations are expected to support either no Downward routes, Non-Storing mode only, or Storing mode only. A fourth mode, operating as a leaf, is also possible 🍃.
Implementations that conform to this specification may contain different subsets of capabilities, depending on the application scenario. It's important for the implementer to support a level of interoperability that's consistent with what the application scenario requires. To this end, further guidance may be provided beyond this specification (for example, as applicability statements), and it's understood that in some cases that further guidance may override portions of this specification 🫶.
16.1. Common Requirements 🌸
in a general case, the greatest level of interoperability may be achieved when all of the nodes in an RPL LLN are cooperating to use the same MOP, OF, metrics, and constraints, and are thus able to act as RPL routers 👑. When a node isn't capable of being a RPL router, it may be possible to interoperate in a more limited way as a RPL leaf.
All RPL implementations need to support the use of RPL Packet Information transported within data packets (Section 11.2). One such mechanism is described in [RFC6553].
RPL implementations will need to support the use of Neighbor Unreachability Detection (NUD), or an equivalent mechanism, to maintain the reachability of neighboring RPL nodes (Section 8.2.1). Alternate mechanisms may be optimized to the constrained capabilities of the implementation, such as hints from the link layer 🔗.
This specification provides means to obtain a PIO and thus form an IPv6 address. When that mechanism is used, it may be necessary to perform address resolution and duplicate address detection through an external process, such as IPv6 ND [RFC4861] or 6LoWPAN ND [6LOWPAN-ND] 🧩.
16.2. Operation as a RPL Leaf Node (Only) 🍓
- An implementation of a leaf node (only) does not ever participate as a RPL router. Interoperable implementations of leaf nodes behave as summarized in Section 8.5 🙈.
- Support of a particular MOP encoding is not required, although if the leaf node sends DAO messages to set up Downward routes, the leaf node should do so in a manner consistent with the mode of operation indicated by the MOP.
- Support of a particular OF is not required.
- In summary, a leaf node does not generally issue DIO messages, but it may issue DAO and DIS messages. A leaf node accepts DIO messages, though it generally ignores DAO and DIS messages 🍵.
16.3. Operation as a RPL Router 👩💻
If further guidance is not available, then a RPL router implementation MUST at least support the metric-less OF0 [RFC6552] 🧁.
For consistent operation, a RPL router implementation needs to support the MOP in use by the DODAG.
All RPL routers will need to implement Trickle [RFC6206] ⚡.
16.3.1. Support for Upward Routes (Only) ⬆️
An implementation of a RPL router that supports only Upward routes supports the following:
- Upward routes (Section 8)
- MOP encoding 0 (Section 20.3)
- In summary, DIO and DIS messages are issued, and DAO messages are not issued. DIO and DIS messages are accepted, and DAO messages are ignored.
16.3.2. Support for Upward Routes and Downward Routes in Non-Storing Mode 🦋
An implementation of a RPL router that supports Upward routes and Downward routes in Non-Storing mode supports the following:
- Upward routes (Section 8)
- Downward routes (Non-Storing) (Section 9)
- MOP encoding 1 (Section 20.3)
- Source-routed Downward traffic ([RFC6554])
- In summary, DIO and DIS messages are issued, and DAO messages are issued to the DODAG root. DIO and DIS messages are accepted, and DAO messages are ignored by nodes other than DODAG roots. Multicast is not supported through the means described in this specification, though it may be supported through some alternate means 📡.
16.3.3. Support for Upward Routes and Downward Routes in Storing Mode 🌈
An implementation of a RPL router that supports Upward routes and Downward routes in Storing mode supports the following:
- Upward routes (Section 8)
- Downward routes (Storing) (Section 9)
- MOP encoding 2 (Section 20.3)
- In summary, DIO, DIS, and DAO messages are issued. DIO, DIS, and DAO messages are accepted. Multicast is not supported through the means described in this specification, though it may be supported through some alternate means 💜.
16.3.3.1. Optional Support for Basic Multicast Scheme 🌟
A Storing mode implementation may be enhanced with basic multicast support through the following additions:
- Basic Multicast Support (Section 12)
- MOP encoding 3 (Section 20.3)
16.4. Items for Future Specification 🔮
A number of items are left to future specification, including but not limited to the following:
- How to attach a non-RPL node, such as an IPv6 host, for example to consistently distribute at least PIO material to the attached node 🖥️.
- How to obtain authentication material in support of authenticated mode, if authenticated mode is used (Section 10.3).
- Details of operation over multiple simultaneous instances.
- Advanced configuration mechanisms, such as the provisioning of RPLInstanceIDs, parameterization of Objective Functions, and parameters to control security. (It is expected that such mechanisms might extend the DIO as a means to disseminate information across the DODAG 📣.)
17. RPL Constants and Variables ✨
okay so this section is basically RPL's cheat sheet 🎀 Here's the summary of its constants and variables, bestie:
BASE_RANK🌸: the Rank for a virtual root that might be used to coordinate multiple roots.BASE_RANKhas a value of0.ROOT_RANK👑: the Rank for a DODAG root.ROOT_RANKhas a value ofMinHopRankIncrease(as advertised by the DODAG root), such thatDAGRank(ROOT_RANK)is1.INFINITE_RANK💀: the constant maximum for the Rank.INFINITE_RANKhas a value of0xFFFF.RPL_DEFAULT_INSTANCE🦋: theRPLInstanceIDthat this protocol uses for a node without any overriding policy.RPL_DEFAULT_INSTANCEhas a value of0.DEFAULT_PATH_CONTROL_SIZE🧚: the default value used to configurePCSin the DODAG Configuration option, which dictates the number of significant bits in the Path Control field of the Transit Information option.DEFAULT_PATH_CONTROL_SIZEhas a value of0. This is the simplest case, limiting the fan-out to1and limiting a node to send a DAO message to only one parent. so minimal, so iconic 💅DEFAULT_DIO_INTERVAL_MIN⭐: the default value used to configureIminfor the DIO Trickle timer.DEFAULT_DIO_INTERVAL_MINhas a value of3. This configuration results inIminof 8 ms.DEFAULT_DIO_INTERVAL_DOUBLINGS🌈: the default value used to configureImaxfor the DIO Trickle timer.DEFAULT_DIO_INTERVAL_DOUBLINGShas a value of20. This configuration results in a maximum interval of 2.3 hours.DEFAULT_DIO_REDUNDANCY_CONSTANT🫶: the default value used to configurekfor the DIO Trickle timer.DEFAULT_DIO_REDUNDANCY_CONSTANThas a value of10. This is a conservative value for the Trickle suppression mechanism.DEFAULT_MIN_HOP_RANK_INCREASE🍓: the default value ofMinHopRankIncrease.DEFAULT_MIN_HOP_RANK_INCREASEhas a value of256. This configuration results in an 8-bit wide integer part of Rank.DEFAULT_DAO_DELAY⏰: the default value for the DelayDAO Timer.DEFAULT_DAO_DELAYhas a value of 1 second. See Section 9.5.
Now the timers, which are the real main characters 🔥
- DIO Timer 💜: there is one instance per DODAG that a node is a member of. Expiry triggers DIO message transmission. It's a Trickle timer with a variable interval in
[0, DIOIntervalMin..2^DIOIntervalDoublings]. See Section 8.3.1. - DAG Version Increment Timer 🌸: up to one instance per DODAG where the node is acting as DODAG root. It may not be supported in all implementations. Expiry triggers an increment of
DODAGVersionNumber, which causes a new series of updated DIO messages to be sent. The interval should be chosen to suit the propagation time of the DODAG and the application requirements (for example, response time versus overhead). - DelayDAO Timer 🦋: up to one timer per DAO parent (the subset of DODAG parents chosen to receive destination advertisements) per DODAG. Expiry triggers sending of a DAO message to the DAO parent. See Section 9.5.
- RemoveTimer 🧚: up to one timer per DAO entry per neighbor (that is, those neighbors that have given DAO messages to this node as a DODAG parent). Expiry may trigger No-Path advertisements or immediately deallocate the DAO entry if there are no DAO parents. the cleanup crew is always on duty 🧹
18. Manageability Considerations 🎀
This section is all about making RPL easy to manage, and how it'll be run in an LLN. The scope here covers five big vibes: configuration, monitoring, fault management, accounting, and performance of the protocol, all in light of the recommendations in [RFC5706].
18.1. Introduction 💖
Most of the existing IETF management standards are MIB modules (data models based on the Structure of Management Information (SMI)) for monitoring and managing networking devices.
For a number of protocols, the IETF community has used the IETF Standard Management Framework. That includes the Simple Network Management Protocol [RFC3410], the Structure of Management Information [RFC2578], and MIB data models for managing new protocols.
As [RFC5706] points out, the common policy for operation and management has expanded into something more open. It's now about a set of tools and management protocols, rather than relying strictly on one protocol such as SNMP. the evolution is giving growth 🌱
In 2003, the Internet Architecture Board (IAB) held a workshop on Network Management [RFC3535]. It discussed the strengths and weaknesses of some IETF network management protocols and compared them to operational needs, especially configuration.
One issue discussed was how user-unfriendly the binary format of SNMP [RFC3410] is. For LLNs, it's worth noting that, at the time of writing, the CoRE working group is actively working on resource management of devices in LLNs. Still, this section gives important guidance on how RPL should be deployed, operated, and managed. 🙌
As [RFC5706] says:
A management information model should include a discussion of what is manageable, which aspects of the protocol need to be configured, what types of operations are allowed, what protocol-specific events might occur, which events can be counted, and for which events an operator should be notified.
These aspects are discussed in detail in the following sections. 📝
RPL will run on a variety of devices. Their memory might be anywhere from a few kilobytes to several hundreds of kilobytes, or even megabytes. When memory is highly constrained, it may not be possible to satisfy every requirement in this section. Still, it's worth listing all of them exhaustively, and implementers will then decide which of these requirements can be satisfied with the resources on the device. 💅
18.2. Configuration Management 🧚
This section talks about configuration management and lists the protocol parameters that configuration management applies to.
Some of the RPL parameters are optional. The configuration requirements only apply to the options that are used. ✨
18.2.1. Initialization Mode 🦋
"Architectural Principles of the Internet" [RFC1958], Section 3.8, says: "Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually". This is especially true in LLNs, where the number of devices may be large and manual configuration is infeasible. RPL was designed with this in mind: the DODAG root provides a number of parameters to the devices that join the DODAG. That avoids cumbersome configuration on the routers and potential sources of misconfiguration (for example, Trickle timer values). Still, there are additional RPL parameters that an RPL implementation should allow to be configured, and this section covers them. 🫶
18.2.1.1. DIS Mode of Operation upon Boot-Up 🌈
When a node is first powered up:
- The node may decide to stay silent. It waits to receive DIO messages from a DODAG of interest (advertising a supported OF and metrics/constraints) and doesn't send any multicast DIO messages until it has joined a DODAG.
- The node may decide to send one or more DIS messages (optionally requesting DIO for a specific DODAG) as an initial probe for nearby DODAGs. If no DIO messages come back in reply after some configurable period of time, the node may decide to root a floating DODAG and start sending multicast DIO messages.
An RPL implementation SHOULD allow configuring the preferred mode of operation listed above, along with the required parameters (in the second mode: the number of DIS messages and the related timer). 🍓
18.2.2. DIO and DAO Base Message and Options Configuration 💜
RPL specifies a number of protocol parameters, since it's meant for a huge spectrum of applications. That said, a lot of care went into limiting how many of these parameters have to be configured on each RPL router. Instead, a number of default values can be used, and when needed, the DODAG root can provide these parameters, which allows for dynamic parameter setting. 🌸
An RPL implementation SHOULD allow configuring the following routing protocol parameters. As mentioned above, a large set of parameters is configured on the DODAG root. 👑
18.2.3. Protocol Parameters to Be Configured on Every Router in the LLN 🎀
An RPL implementation MUST allow configuring the following RPL parameters:
RPLInstanceID[DIO message, in DIO Base message]. Although theRPLInstanceIDmust be configured on the DODAG root, it must also be configured as a policy on every node, so the node can decide whether or not to join a particular DODAG. Note that a secondRPLInstanceIDcan be configured on the node, should it become root of a floating DODAG. 🧚- List of supported Objective Code Points (OCPs). 🦋
- List of supported metrics: [RFC6551] specifies a number of metrics and constraints used for DODAG formation. Thus, an RPL implementation should allow configuring the list of metrics that a node can accept and understand. If a DIO is received with a metric and/or constraint that is not understood or supported, as specified in Section 8.5, the node would join as a leaf node. 📊
- Prefix Information, along with the valid and preferred lifetime and the
LandAflags [DIO message, Prefix Information Option]. An RPL implementation SHOULD allow configuring whether the Prefix Information option must be carried with the DIO message to distribute the Prefix Information for autoconfiguration. In that case, the RPL implementation MUST allow the list of prefixes to be advertised in the PIO, along with the corresponding flags. 🌈 - Solicited Information [DIS message, in Solicited Information option]. An RPL implementation SHOULD allow configuring when such messages should be sent and under which circumstances, along with the value of the
RPLInstanceIDand theV/I/Dflags. ⭐ Kflag: when a node should set theKflag in a DAO message [DAO message, in DAO Base message]. 🫶- MOP (Mode of Operation) [DIO message, in DIO Base message]. 🍓
- Route Information (and preference) [DIO message, in Route Information option]. 💅
okay bestie, we're picking up mid-vibe so let's go 💅✨
18.2.4. Protocol Parameters to Be Configured on Every Non-DODAG-Root Router in the LLN 🌸
okay so first things first, a RPL implementation MUST allow configuring the Target prefix 🎀 (that's the one in the DAO message, inside the RPL Target option). no cap, non-negotiable.
Now, sometimes a node wants to mark a Target as special so it gets extra-special processing, like prioritization or whatever 👑. The rules for that processing are out of scope for this spec, so we're not going there. But when it is used, a RPL implementation SHOULD allow configuring the Target Descriptor on a per-Target basis (think access lists, periodt 🧚).
Next up: a node whose DODAG parent set is empty can become the DODAG root of a floating DODAG 🦋. It can also set its DAGPreference so it's less preferred, which is giving very "I'll be the backup, no pressure" energy 💀. So a RPL implementation MUST allow configuring the set of actions this node should start in that situation:
o Start its own (floating) DODAG: the new DODAGID must be configured in addition to its DAGPreference. 💖
o Poison the broken path (see procedure in Section 8.2.2.5). 🙈
o Trigger a local repair. 🔥
18.2.5. Parameters to Be Configured on the DODAG Root 👑
okay so there are a few parameters that only get configured on the DODAG root, and then it advertises them in options inside DIO messages. main character behavior, iykyk 🌈
As Section 8.3 explains, a RPL implementation uses Trickle timers to control when DIO messages get sent 🦋. How Trickle behaves is set by a bunch of configurable parameters, and those MUST be configurable, and then the DODAG root advertises them along the DODAG in DIO messages. no notes 💅
o DIOIntervalDoublings [DIO message, in DODAG Configuration option]
o DIOIntervalMin [DIO message, in DODAG Configuration option]
o DIORedundancyConstant [DIO message, in DODAG Configuration option]
Also, a RPL implementation SHOULD allow configuring this set too 🫶:
o Path Control Size [DIO message, in DODAG Configuration option]
o MinHopRankIncrease [DIO message, in DODAG Configuration option]
o The DODAGPreference field [DIO message, DIO Base object]
o DODAGID [DIO message, in DIO Base option] and [DAO message, when the 'D' flag of the DAO message is set]
DAG root behavior 🌸: sometimes a node doesn't want to be a floating DODAG root forever if it can't join a grounded DODAG. like, a battery-operated node probably doesn't want to be a floating root for a long time 🔋💀. So a RPL implementation MAY support configuring whether or not a node could act as a floating DODAG root for a configured period of time. ✨
DAG Version Number Increment 🎀: a RPL implementation MAY allow, through configuration at the DODAG root, refreshing the DODAG states by updating the DODAGVersionNumber. And a RPL implementation SHOULD allow configuring whether periodic or event-triggered mechanisms are used by the DODAG root to control DODAGVersionNumber changes (which triggers a global repair, see Section 3.2.2) 🔥.
18.2.6. Configuration of RPL Parameters Related to DAO-Based Mechanisms 🧚
so DAO messages are optional, and they're used in DODAGs that need Downward routing 🍓. This section is all about the DAO-related parameters and gives some recommendations on setting them up 💜.
As Section 9.5 says, it's recommended to delay sending DAO messages to DAO parents so you have a better shot at route aggregation 🦋. So when a node gets a DAO message, it SHOULD start a DelayDAO timer. The default is DEFAULT_DAO_DELAY, and a RPL implementation MAY allow configuring the DelayDAO timer. ⭐
In Storing mode, a storing node MAY increment DTSN to reliably trigger a set of DAO updates from its immediate children, as part of routine routing table updates and maintenance 🌈. A RPL implementation MAY allow configuring a set of rules for what triggers a DTSN increment (manual or event-based) 🎀.
When a DAO entry times out or gets invalidated, a node SHOULD make a reasonable attempt to report a No-Path to each DAO parent 🙈. That number of attempts MAY be configurable. 💅
An implementation SHOULD support rate-limiting the sending of DAO messages, and the related parameters MAY be configurable. 🫶
18.2.7. Configuration of RPL Parameters Related to Security Mechanisms 🔐
As Section 10 describes, the security features in this document are OPTIONAL to implement 🥹, and an implementation may support a subset (including the empty set) of them. no pressure, bestie 💜.
So an implementation that supports the security features MAY conceptually implement a security policy database 🧚. To support the security mechanisms, a RPL implementation SHOULD allow configuring a subset of the following parameters:
o Security Modes accepted [Unsecured mode, Preinstalled mode, Authenticated mode]
o KIM values accepted [Secure RPL control messages, in Security section]
o Level values accepted [Secure RPL control messages, in Security section]
o Algorithm values accepted [Secure RPL control messages, in Security section]
o Key material in support of Authenticated or Preinstalled key modes.
Also, a RPL implementation SHOULD allow configuring a DODAG root with a subset of these 🔑:
o Level values advertised [Secure DIO message, in Security section]
o KIM value advertised [Secure DIO message, in Security section]
o Algorithm value advertised [Secure DIO message, in Security section]
18.2.8. Default Values 🎀
this document specifies default values for these RPL variables:
DEFAULT_PATH_CONTROL_SIZE
DEFAULT_DIO_INTERVAL_MIN
DEFAULT_DIO_INTERVAL_DOUBLINGS
DEFAULT_DIO_REDUNDANCY_CONSTANT
DEFAULT_MIN_HOP_RANK_INCREASE
DEFAULT_DAO_DELAYit's recommended to specify default values in protocols, BUT as [RFC5706] talks about, defaults can make less and less sense over time 🙃. RPL is expected to run in a bunch of contexts where stuff like the number of nodes and the link and node types can vary a LOT 🌍. So these defaults will probably change with context and as tech evolves. And LLN hardware and link layers have been evolving dramatically over the past few years, and they're expected to keep changing a ton in the coming years 🚀✨.
The proposed values aren't based on extensive best current practices, and they're considered to be conservative 🧸.
18.3. Monitoring of RPL Operation 👀
several RPL parameters SHOULD be monitored to check that the routing protocol and the network itself are working right 💖. This section lists the monitoring parameters that matter.
18.3.1. Monitoring a DODAG Parameters 📊
A RPL implementation SHOULD provide information about these parameters:
o DODAG Version number [DIO message, in DIO Base message]
o Status of the 'G' flag [DIO message, in DIO Base message]
o Status of the MOP field [DIO message, in DIO Base message]
o Value of the DTSN [DIO message, in DIO Base message]
o Value of the Rank [DIO message, in DIO Base message]
o DAOSequence: Incremented at each unique DAO message, echoed in the DAO-ACK message [DAO and DAO-ACK messages]
o Route Information [DIO message, Route Information Option] (list of IPv6 prefixes per parent along with lifetime and preference]
o Trickle parameters:
* DIOIntervalDoublings [DIO message, in DODAG Configuration option]
* DIOIntervalMin [DIO message, in DODAG Configuration option]
* DIORedundancyConstant [DIO message, in DODAG Configuration option]
o Path Control Size [DIO message, in DODAG Configuration option]
o MinHopRankIncrease [DIO message, in DODAG Configuration option]
Values that may be monitored only on the DODAG root:
o Transit Information [DAO, Transit Information option]: A RPL implementation SHOULD allow configuring whether the set of received Transit Information options should be displayed on the DODAG root. In this case, the RPL database of received Transit Information should also contain the Path Sequence, Path Control, Path Lifetime, and Parent Address. 🗺️
18.3.2. Monitoring a DODAG Inconsistencies and Loop Detection 🕵️♀️
detecting DODAG inconsistencies is a HUGE deal in RPL networks 😭, so it's recommended that a RPL implementation provides appropriate monitoring tools. A RPL implementation SHOULD provide a counter that reports the number of times the node has detected an inconsistency with respect to a DODAG parent, e.g., if the DODAGID has changed 🚨.
when possible, more granular info about inconsistency detection SHOULD be provided. A RPL implementation MAY provide counters reporting the number of the following inconsistencies:
o Packets received with 'O' bit set (to Down) from a node with a higher Rank
o Packets received with 'O' bit cleared (to Up) from a node with a lower Rank
o Number of packets with the 'F' bit set
o Number of packets with the 'R' bit set
18.4. Monitoring of the RPL Data Structures 🗂️
18.4.1. Candidate Neighbor Data Structure 👯
okay so a node in the candidate neighbor list is one that was discovered the same way and qualifies to potentially become a parent (with high enough local confidence) ✨. A RPL implementation SHOULD provide a way to monitor the candidate neighbor list with some metric that reflects local confidence (how stable the neighbors are), measured by some metrics 📈.
A RPL implementation MAY provide a counter that reports how many times a candidate neighbor has been ignored, in case the number of candidate neighbors goes over the maximum authorized value 🙃.
18.4.2. Destination-Oriented Directed Acyclic Graph (DODAG) Table 🌳
for each DODAG, a RPL implementation is expected to keep track of these DODAG table values 📋:
o RPLInstanceID
o DODAGID
o DODAGVersionNumber
o Rank
o Objective Code Point
o A set of DODAG parents
o A set of prefixes offered Upward along the DODAG
o Trickle timers used to govern the sending of DIO messages for the DODAG
o List of DAO parents
o DTSN
o Node status (router versus leaf)
A RPL implementation SHOULD allow for monitoring the set of parameters listed above. 💖
18.4.3. Routing Table and DAO Routing Entries ✨
okay so a RPL implementation keeps track of a bunch of info about the DODAG and the DAO entries (the stuff storing nodes need to remember) 💅. For a non-storing node it's pretty minimal: the routing table is basically just a set of DODAG parents plus the DODAG characteristics we covered above. Storing nodes take it up a notch and add routing entries on top 🌸.
A RPL implementation SHOULD allow for the following parameters to be monitored:
- Next Hop (DODAG parent)
- Next Hop Interface
- Path metrics value for each DODAG parent
A DAO Routing Table entry conceptually contains the following elements (for storing nodes only) 🧚:
- Advertising Neighbor Information
- IPv6 address
- Interface ID to which DAO parents has this entry been reported
- Retry counter
- Logical equivalent of DAO Content:
- DAO-Sequence
- Path Sequence
- DAO Lifetime
- DAO Path Control
- Destination Prefix (or address or Mcast Group)
A RPL implementation SHOULD provide information about the state of each DAO Routing Table entry states 🦋.
18.5. Fault Management 🚨
Fault management is a critical component 😭. It's how you troubleshoot, check that the protocol is actually doing its thing, and plan your network. It's also a key piece of network performance monitoring 📊. A RPL implementation SHOULD allow the provision of the following information related to fault managements:
- Memory overflow along with the cause (e.g., routing tables overflow, etc.)
- Number of times a packet could not be sent to a DODAG parent flagged as valid
- Number of times a packet has been received for which the router did not have a corresponding RPLInstanceID
- Number of times a local repair procedure was triggered
- Number of times a global repair was triggered by the DODAG root
- Number of received malformed messages
- Number of seconds with packets to forward and no next hop (DODAG parent)
- Number of seconds without next hop (DODAG parent)
- Number of times a node has joined a DODAG as a leaf because it received a DIO with a metric/constraint that was not understood and it was configured to join as a leaf node in this case (see Section 18.6)
It is RECOMMENDED to report faults via at least error log messages 📝. Other protocols may be used to report such faults 🌈.
18.6. Policy 👑
Policy rules let a RPL implementation decide whether a node is allowed to join a particular DODAG that a neighbor advertises in DIO messages 🎀.
This document only covers operation within a single DODAG. A DODAG is identified by the tuple (RPLInstanceID, DODAGID). As mentioned above, DIO messages also advertise other DODAG characteristics, like the routing metrics and constraints used to build the DODAG and the Objective Function in use (specified by OCP) 🍓.
The first policy rules are the conditions a RPL node has to meet before it can join a DODAG:
- RPLInstanceID
- List of supported routing metrics and constraints
- Objective Function (OCP values)
A RPL implementation MUST allow configuring these parameters and SHOULD specify whether the node must simply ignore the DIO if the advertised DODAG is not compliant with the local policy or whether the node should join as the leaf node if only the list of supported routing metrics and constraints, and the OF is not supported 🙈. Additionally, a RPL implementation SHOULD allow for the addition of the DODAGID as part of the policy 💜.
A RPL implementation SHOULD allow configuring the set of acceptable or preferred Objective Functions (OFs) referenced by their Objective Code Points (OCPs) for a node to join a DODAG. It should also define what happens if none of a node's candidate neighbors advertise one of the configured allowable Objective Functions, or if the advertised metrics/constraint is not understood/supported. Two actions are possible in that case:
- The node joins the DODAG as a leaf node as specified in Section 8.5.
- The node does not join the DODAG.
A node in an LLN can learn routing information from different routing protocols, RPL included 🌍. In that case it's useful to control, through administrative preference, which route wins. An implementation SHOULD allow for the specification of an administrative preference for the routing protocol from which the route was learned 👑.
Internal Data Structures: some RPL implementations may limit the size of the candidate neighbor list to keep memory usage bounded. When that happens, some otherwise viable candidate neighbors may not be considered and simply get dropped from the candidate neighbor list 💀.
A RPL implementation MAY provide an indicator on the size of the candidate neighbor list 🔥.
18.7. Fault Isolation 🧯
It is RECOMMENDED to quarantine neighbors that start emitting malformed messages at unacceptable rates 🚫.
18.8. Impact on Other Protocols 🌷
RPL has very limited impact on other protocols 🫶. When a router needs more than one routing protocol, like an LBR does, the device is expected to support routing redistribution between those protocols so the two routing domains can reach each other 🌉. Such redistribution SHOULD be governed by the use of user configurable policy 📜.
As for network traffic, RPL is built to keep control traffic low, thanks to things like Trickle timers (Section 8.3) ⏲️. So the impact of RPL on other protocols should be extremely limited ✨.
18.9. Performance Management 📈
Performance management is always important, and RPL is no exception 💅. The IP Performance Monitoring (IPPM) working group has specified several metrics of interest. Honestly though, they're hardly practical for LLNs, since monitoring them costs a lot of device resources and bandwidth 😭. RPL implementations MAY still support some of these, and these other parameters are worth tracking:
- Number of repairs and time to repair in seconds (average, variance)
- Number of times and time period during which a devices could not forward a packet because of a lack of a reachable neighbor in its routing table
- Monitoring of resources consumption by RPL in terms of bandwidth and required memory
- Number of RPL control messages sent and received
18.10. Diagnostics 🔍
Sometimes a node needs to go into "verbose" mode so you can get better diagnostics 🎀. A RPL implementation SHOULD provide the ability to place a node in and out of verbose mode so you can grab that extra diagnostic info 🦋.
19. Security Considerations 🔐
19.1. Overview 🔐
okay bestie, listen 👂 from a security point of view, RPL networks are literally no different from any other network 💀. They're open to passive eavesdropping and, potentially, even active tampering, because you don't need physical access to a wire to take part in the conversation. Ad hoc networks are already a lot, and their cost goals make things even harder, which honestly makes these some of the most difficult environments to secure 😭. The devices are cheap with limited computing power, storage, and battery, so we can't always assume they have a trusted computing base or a high-quality random number generator 🥺.
Communications can't count on a fixed infrastructure being online 📡, and devices might have short-term relationships with each other even if they've never talked before 🦋. These limits might seriously narrow down which cryptographic algorithms and protocols you can use, and they shape the whole security architecture, because setting up and keeping trust between devices needs to be handled with care 🫶. Battery life and cost also put tight limits on how much security overhead these networks can handle, which is way less of a worry on higher-bandwidth networks 🔋. Most of these security architecture pieces can live at higher layers, so they may be considered out of scope for this specification ✨. Still, special care needs to be taken with the interfaces to those higher layers, so don't skip that part 👀.
The security mechanisms in this standard are based on symmetric-key and public-key cryptography, and they use keys that get provided by higher-layer processes 🔑. Setting up and maintaining those keys is out of scope for this specification. The mechanisms assume a secure implementation of cryptographic operations, plus secure and authentic storage of keying material 💜.
The security mechanisms specified provide particular combinations of the following security services 💅:
- Data confidentiality: Assurance that transmitted information is only disclosed to parties for which it is intended. 🤫
- Data authenticity: Assurance of the source of transmitted information (and, hereby, that information was not modified in transit). 🪪
- Replay protection: Assurance that a duplicate of transmitted information is detected. 🔁
- Timeliness (delay protection): Assurance that transmitted information was received in a timely manner. ⏰
The actual protection can be adapted on a per-packet basis 🎀. It allows for varying levels of data authenticity (so you can keep the security overhead in transmitted packets down where that's needed) and for optional data confidentiality 🌸. When nontrivial protection is required, replay protection is always provided 🔥.
Replay protection works through a non-repeating value (CCM nonce) used in the packet protection process, plus storage of some status information (the originating device and the CCM nonce counter last received from that device) ✨. That's how it can tell whether this particular CCM nonce value was already used by the originating device 🕵️♀️. On top of that, so-called delay protection is provided among devices that have a loosely synchronized clock on board ⏳. The acceptable time delay can be adapted on a per-packet basis, so it can handle varying latencies, which helps with longer latencies in packets sent over a multi-hop communication path 🦋.
Cryptographic protection may use a key shared between two peer devices (link key) or a key shared among a group of devices (group key) 🗝️. That gives you some flexibility and application-specific trade-offs between key storage and key maintenance costs versus the cryptographic protection you get 🧮. If a group key is used for peer-to-peer communication, protection is provided only against outsider devices, and not against potential malicious devices inside the key-sharing group 😱.
Data authenticity may be provided using symmetric-key-based or public-key-based techniques 💖. With public-key-based techniques (via signatures), you can corroborate evidence of the unique originator of transmitted information 🖋️. With symmetric-key-based techniques, data authenticity is only provided relative to devices in a key-sharing group 👯. So public-key-based authentication may be useful in scenarios that need more fine-grained authentication than symmetric-key-based techniques alone can give, such as group communications (broadcast, multicast) or scenarios that require non-repudiation 🌈.
20. IANA Considerations 📋
20.1. RPL Control Message
The RPL control message is an ICMP information message type that is to be used to carry DODAG Information Objects, DODAG Information Solicitations, and Destination Advertisement Objects in support of RPL operation 💌.
IANA has defined an ICMPv6 Type Number Registry 📚. The type value for the RPL control message is 155 🎀.
20.2. New Registry for RPL Control Codes
IANA has created a registry, RPL Control Codes, for the Code field of the ICMPv6 RPL control message 🗂️.
New codes may be allocated only by an IETF Review 🔍. Each code is tracked with the following qualities:
- Code
- Description
- Defining RFC
The following codes are currently defined ✨:
+------+----------------------------------------------+-------------+
| Code | Description | Reference |
+------+----------------------------------------------+-------------+
| 0x00 | DODAG Information Solicitation | This |
| | | document |
| | | |
| 0x01 | DODAG Information Object | This |
| | | document |
| | | |
| 0x02 | Destination Advertisement Object | This |
| | | document |
| | | |
| 0x03 | Destination Advertisement Object | This |
| | Acknowledgment | document |
| | | |
| 0x80 | Secure DODAG Information Solicitation | This |
| | | document |
| | | |
| 0x81 | Secure DODAG Information Object | This |
| | | document |
| | | |
| 0x82 | Secure Destination Advertisement Object | This |
| | | document |
| | | |
| 0x83 | Secure Destination Advertisement Object | This |
| | Acknowledgment | document |
| | | |
| 0x8A | Consistency Check | This |
| | | document |
+------+----------------------------------------------+-------------+
RPL Control Codes20.3. New Registry for the Mode of Operation (MOP)
IANA has created a registry for the 3-bit Mode of Operation (MOP), which is contained in the DIO Base 🧩.
New values may be allocated only by an IETF Review 🔍. Each value is tracked with the following qualities:
- Mode of Operation Value
- Capability description
- Defining RFC
Four values are currently defined 💅:
+----------+------------------------------------------+-------------+
| MOP | Description | Reference |
| value | | |
+----------+------------------------------------------+-------------+
| 0 | No Downward routes maintained by RPL | This |
| | | document |
| | | |
| 1 | Non-Storing Mode of Operation | This |
| | | document |
| | | |
| 2 | Storing Mode of Operation with no | This |
| | multicast support | document |
| | | |
| 3 | Storing Mode of Operation with multicast | This |
| | support | document |
+----------+------------------------------------------+-------------+
DIO Mode of OperationThe rest of the range, decimal 4 to 7, is currently unassigned 🤷♀️.
20.4. RPL Control Message Options
IANA has created a registry for the RPL Control Message Options 🧾.
New values may be allocated only by an IETF Review 🔍. Each value is tracked with the following qualities:
- Value
- Meaning
- Defining RFC
+-------+-----------------------+---------------+
| Value | Meaning | Reference |
+-------+-----------------------+---------------+
| 0x00 | Pad1 | This document |
| | | |
| 0x01 | PadN | This document |
| | | |
| 0x02 | DAG Metric Container | This Document |
| | | |
| 0x03 | Routing Information | This Document |
| | | |
| 0x04 | DODAG Configuration | This Document |
| | | |
| 0x05 | RPL Target | This Document |
| | | |
| 0x06 | Transit Information | This Document |
| | | |
| 0x07 | Solicited Information | This Document |
| | | |
| 0x08 | Prefix Information | This Document |
| | | |
| 0x09 | Target Descriptor | This Document |
+-------+-----------------------+---------------+
RPL Control Message Options20.5. Objective Code Point (OCP) Registry 🎯
IANA has created a registry to manage the codespace of the Objective Code Point (OCP) field 🗃️.
No OCPs are defined in this specification 🙅♀️.
New codes may be allocated only by an IETF Review 🔍. Each code is tracked with the following qualities:
- Code
- Description
- Defining RFC
20.6. New Registry for the Security Section Algorithm ✨
okay so IANA made a registry for the 8-bit Algorithm field in the Security section 🔐
New values can only be allocated through an IETF Review. Each value gets tracked with these qualities:
- Value
- Encryption/MAC
- Signature
- Defining RFC
Right now there's just one value defined, and it's giving main character 💅
+-------+------------------+------------------+---------------+
| Value | Encryption/MAC | Signature | Reference |
+-------+------------------+------------------+---------------+
| 0 | CCM with AES-128 | RSA with SHA-256 | This document |
+-------+------------------+------------------+---------------+
Security Section Algorithm20.7. New Registry for the Security Section Flags 🚩
IANA made a registry for the 8-bit Security Section Flags field. It's giving organized 🗂️
New bit numbers can only be allocated through an IETF Review. Each bit gets tracked with these qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
Nothing is defined for the Security Section Flags field yet, so no bit is currently defined for it 🫶
20.8. New Registry for Per-KIM Security Levels 🎀
IANA made one registry for the 3-bit Security Level (LVL) field, per allocated KIM value. This is so cute 🥹
For a given KIM value, new levels can only be allocated through an IETF Review. Each level gets tracked with these qualities:
- Level
- KIM value
- Description
- Defining RFC
These are the levels per KIM value that are currently defined. Every single one points to Figure 11 in this document, which is very iconic 🦋
+-------+-----------+---------------+---------------+
| Level | KIM value | Description | Reference |
+-------+-----------+---------------+---------------+
| 0 | 0 | See Figure 11 | This document |
| | | | |
| 1 | 0 | See Figure 11 | This document |
| | | | |
| 2 | 0 | See Figure 11 | This document |
| | | | |
| 3 | 0 | See Figure 11 | This document |
| | | | |
| 0 | 1 | See Figure 11 | This document |
| | | | |
| 1 | 1 | See Figure 11 | This document |
| | | | |
| 2 | 1 | See Figure 11 | This document |
| | | | |
| 3 | 1 | See Figure 11 | This document |
| | | | |
| 0 | 2 | See Figure 11 | This document |
| | | | |
| 1 | 2 | See Figure 11 | This document |
| | | | |
| 2 | 2 | See Figure 11 | This document |
| | | | |
| 3 | 2 | See Figure 11 | This document |
| | | | |
| 0 | 3 | See Figure 11 | This document |
| | | | |
| 1 | 3 | See Figure 11 | This document |
| | | | |
| 2 | 3 | See Figure 11 | This document |
| | | | |
| 3 | 3 | See Figure 11 | This document |
+-------+-----------+---------------+---------------+
Per-KIM Security Levels20.9. New Registry for DODAG Informational Solicitation (DIS) Flags 🌸
IANA made a registry for the DIS (DODAG Informational Solicitation) Flags field. Love a good registry 📋
New bit numbers can only be allocated through an IETF Review. Each bit gets tracked with these qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
No bit is currently defined for the DIS (DODAG Informational Solicitation) Flags field 🙈
20.10. New Registry for the DODAG Information Object (DIO) Flags 🍓
IANA made a registry for the 8-bit DODAG Information Object (DIO) Flags field ✨
New bit numbers can only be allocated through an IETF Review. Each bit gets tracked with these qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
No bit is currently defined for the DIS (DODAG Informational Solicitation) Flags. The doc says DIS here, not DIO, so that's the wording to go with 🤷♀️
20.11. New Registry for the Destination Advertisement Object (DAO) Flags 🦋
IANA made a registry for the 8-bit Destination Advertisement Object (DAO) Flags field. Okay, the name is long, but the vibe is still immaculate 💜
New bit numbers can only be allocated through an IETF Review. Each bit gets tracked with these qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
The following bits are currently defined:
+------------+------------------------------+---------------+
| Bit number | Description | Reference |
+------------+------------------------------+---------------+
| 0 | DAO-ACK request (K) | This document |
| | | |
| 1 | DODAGID field is present (D) | This document |
+------------+------------------------------+---------------+
DAO Base Flags20.12. New Registry for the Destination Advertisement Object (DAO) Acknowledgement Flags 🫧
IANA made a registry for the 8-bit Destination Advertisement Object (DAO) Acknowledgement Flags field. Long name, still slay 💖
New bit numbers can only be allocated through an IETF Review. Each bit gets tracked with these qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
The following bit is currently defined:
+------------+------------------------------+---------------+
| Bit number | Description | Reference |
+------------+------------------------------+---------------+
| 0 | DODAGID field is present (D) | This document |
+------------+------------------------------+---------------+
DAO-ACK Base Flags20.13. New Registry for the Consistency Check (CC) Flags 🔍
IANA made a registry for the 8-bit Consistency Check (CC) Flags field. Checking things is my love language 🥰
New bit numbers can only be allocated through an IETF Review. Each bit gets tracked with these qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
The following bit is currently defined:
+------------+-----------------+---------------+
| Bit number | Description | Reference |
+------------+-----------------+---------------+
| 0 | CC Response (R) | This document |
+------------+-----------------+---------------+
Consistency Check Base Flags20.14. New Registry for the DODAG Configuration Option Flags ⚙️
IANA made a registry for the 8-bit DODAG Configuration Option Flags field. Config goals 🎯
New bit numbers can only be allocated through an IETF Review. Each bit gets tracked with these qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
The following bits are currently defined:
+------------+----------------------------+---------------+
| Bit number | Description | Reference |
+------------+----------------------------+---------------+
| 4 | Authentication Enabled (A) | This document |
| 5-7 | Path Control Size (PCS) | This document |
+------------+----------------------------+---------------+
DODAG Configuration Option Flags20.15. New Registry for the RPL Target Option Flags 🎯
IANA made a registry for the 8-bit RPL Target Option Flags field. Target locked 🔒
New bit numbers can only be allocated through an IETF Review. Each bit gets tracked with these qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
No bit is currently defined for the RPL Target Option Flags 🌙
20.16. New Registry for the Transit Information Option Flags 🚌
IANA made a registry for the 8-bit Transit Information Option (TIO) Flags field 🫶
New bit numbers can only be allocated through an IETF Review. Each bit gets tracked with these qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
The following bits are currently defined:
+------------+--------------+---------------+
| Bit number | Description | Reference |
+------------+--------------+---------------+
| 0 | External (E) | This document |
+------------+--------------+---------------+
Transit Information Option Flags20.17. New Registry for the Solicited Information Option Flags 🧃
IANA made a registry for the 8-bit Solicited Information Option (SIO) Flags field 💅
New bit numbers can only be allocated through an IETF Review. Each bit gets tracked with these qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
The following bits are currently defined:
+------------+--------------------------------+---------------+
| Bit number | Description | Reference |
+------------+--------------------------------+---------------+
| 0 | Version Predicate match (V) | This document |
| | | |
| 1 | InstanceID Predicate match (I) | This document |
| | | |
| 2 | DODAGID Predicate match (D) | This document |
+------------+--------------------------------+---------------+
Solicited Information Option Flags20.18. ICMPv6: Error in Source Routing Header 🚨
okay so in some cases RPL sends back an ICMPv6 error message when a message can't be delivered the way its source routing header says it should. That ICMPv6 error message is "Error in Source Routing Header" 😭
IANA defined an ICMPv6 "Code" Fields Registry for ICMPv6 Message Types. ICMPv6 Message Type 1 describes "Destination Unreachable" codes. The "Error in Source Routing Header" code is has been allocated from the ICMPv6 Code Fields Registry for ICMPv6 Message Type 1, with a code value of 7 🧚
20.19. Link-Local Scope Multicast Address 📣
The rules for assigning new IPv6 multicast addresses are defined in [RFC3307]. This specification requires the allocation of a new permanent multicast address with a link-local scope for RPL nodes called all-RPL-nodes, with a value of ff02::1a 🌈
21. Acknowledgements 🎀
okay so the authors wanna give a shoutout to everyone who reviewed, gave feedback, and dropped comments 🫶 bestie, the list is literally huge. Emmanuel Baccelli, Dominique Barthel, Yusuf Bashir, Yoav Ben-Yehezkel, Phoebus Chen, Quynh Dang, Mischa Dohler, Mathilde Durvy, Joakim Eriksson, Omprakash Gnawali, Manhar Goindi, Mukul Goyal, Ulrich Herberg, Anders Jagd, JeongGil (John) Ko, Ajay Kumar, Quentin Lampin, Jerry Martocci, Matteo Paris, Alexandru Petrescu, Joseph Reddy, Michael Richardson, Don Sturek, Joydeep Tripathi, and Nicolas Tsiftes 😭✨
They also thank the ROLL Chairs, David Culler and JP. Vasseur, plus Area Director Adrian Farrel, for the guidance and input 👑
Then there's the prior crew who helped shape RPL's design thinking: Robert Assimiti, Mischa Dohler, Julien Abeille, Ryuji Wakikawa, Teco Boot, Patrick Wetterwald, Bryan Mclaughlin, Carlos J. Bernardos, Thomas Watteyne, Zach Shelby, Caroline Bontoux, Marco Molteni, Billy Moon, Jim Bound, Yanick Pouffary, Henning Rogge, and Arsalan Tavakoli 🌸
The RPL security design (Section 10, Section 19, and bits scattered elsewhere) is mostly the work of the Security Design Team: Tzeta Tsao, Roger Alexander, Dave Ward, Philip Levis, Kris Pister, Rene Struik, and Adrian Farrel. Security team, you're literally the reason this is safe 🔥🔐
And finally, thanks to Jari Arkko and Ralph Droms for their super attentive reviews, especially on interoperability and how RPL plays with other IETF specs 💅
22. Contributors 🧚
Stephen Dawson-Haggerty is the contributor listed here. Here's the info, exactly as it appears:
Stephen Dawson-Haggerty
UC Berkeley
Soda Hall
Berkeley, CA 94720
USA
EMail: stevedh@cs.berkeley.edu23. References 📚
23.1. Normative References 💜
These are the must-read ones, the references the spec leans on hard:
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version
6 (IPv6) Specification", RFC 2460, December 1998.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences
and More-Specific Routes", RFC 4191, November 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J.
Ko, "The Trickle Algorithm", RFC 6206, March 2011.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, July 2011.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean,
N., and D. Barthel, "Routing Metrics Used for Path
Calculation in Low-Power and Lossy Networks", RFC 6551,
March 2012.
[RFC6552] Thubert, P., Ed., "Objective Function Zero for the
Routing Protocol for Low-Power and Lossy Networks
(RPL)", RFC 6552, March 2012.
[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,
March 2012.
[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, March 2012.23.2. Informative References 🦋
These are the nice-to-know ones, the background reading that gives you the full picture:
[6LOWPAN-ND] Shelby, Z., Ed., Chakrabarti, S., and E. Nordmark,
"Neighbor Discovery Optimization for Low Power and
Lossy Networks (6LoWPAN)", Work in Progress,
October 2011.
[FIPS180] National Institute of Standards and Technology, "FIPS
Pub 180-3, Secure Hash Standard (SHS)", US Department
of Commerce , February 2008,
<http://www.nist.gov/itl/upload/fips180-3_final.pdf>.
[Perlman83] Perlman, R., "Fault-Tolerant Broadcast of Routing
Information", North-Holland Computer Networks,
Vol.7: p. 395-405, December 1983.
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic",
RFC 1982, August 1996.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J.
Schoenwaelder, Ed., "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578,
April 1999.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for
Internet-Standard Management Framework", RFC 3410,
December 2002.
[RFC3535] Schoenwaelder, J., "Overview of the 2002 IAB Network
Management Workshop", RFC 3535, May 2003.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter
with CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and
L. Wood, "Advice for Internet Subnetwork Designers",
BCP 89, RFC 3819, July 2004.
[RFC4101] Rescorla, E. and IAB, "Writing Protocol Models",
RFC 4101, June 2005.
[RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF",
RFC 4915, June 2007.
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
February 2008.
[RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K.
Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3
(L3)-Driven Fast Handover", RFC 5184, May 2008.
[RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel,
"Routing Requirements for Urban Low-Power and Lossy
Networks", RFC 5548, May 2009.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 2009.
[RFC5706] Harrington, D., "Guidelines for Considering Operations
and Management of New Protocols and Protocol
Extensions", RFC 5706, November 2009.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
"Building Automation Routing Requirements in Low-Power
and Lossy Networks", RFC 5867, June 2010.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection (BFD) for IPv4 and IPv6 (Single Hop)",
RFC 5881, June 2010.
[RFC6130] Clausen, T., Dearlove, C., and J. Dean, "Mobile Ad Hoc
Network (MANET) Neighborhood Discovery Protocol
(NHDP)", RFC 6130, April 2011.
[ROLL-TERMS] Vasseur, J., "Terminology in Low power And Lossy
Networks", Work in Progress, September 2011.Appendix A. Example Operation 🍓
This appendix is all about examples showing how addressing info and prefixes get spread around with RPL. The examples show info moving through PIOs and RIOs, plus DIO and DAO messages in action 🌈
Heads up: this appendix is not normative. The exact details of an RPL addressing plan and autoconfiguration can vary between implementations. RPL just provides the vehicle for passing info around, and other mechanisms can build on top of that 🚌
Also, if an implementation uses a different address autoconfiguration scheme, RPL nodes might be configured not to set the 'A' flag in PIO options. The PIO can still be used to distribute prefix and addressing information, though 💅
A.1. Example Operation in Storing Mode with Node-Owned Prefixes 🌸
Okay, so Figure 32 shows the logical addressing setup for a simple RPL network running in Storing mode. Each node (A, B, C, and D) owns its own prefix and makes it available for address autoconfiguration by on-link devices. This gets signaled by setting the 'A' flag and the 'L' flag in the PIO of the DIO messages. Node A owns A::/64, Node B owns B::/64, and so on. Node B autoconfigures an on-link address with respect to Node A, which is A::B. Nodes C and D autoconfigure on-link addresses from Node B's prefix, giving B::C and B::D respectively. Nodes can also choose to set the 'R' flag and publish their address in the Prefix field of the PIO, so that's an option too ✨
+-------------+
| Root |
| |
| Node A |
| |
| A::A |
+------+------+
|
|
|
+------+------+
| A::B |
| |
| Node B |
| |
| B::B |
+------+------+
|
|
.--------------+--------------.
/ \
/ \
+------+------+ +------+------+
| B::C | | B::D |
| | | |
| Node C | | Node D |
| | | |
| C::C | | D::D |
+-------------+ +-------------+
Figure 32: Storing Mode with Node-Owned PrefixesA.1.1. DIO Messages and PIO
Okay so Node A 💖 will send DIO messages with a PIO like this:
'A' flag: Set
'L' flag: Set
'R' flag: Clear
Prefix Length: 64
Prefix: A::Node B 🦋 will send DIO messages with a PIO like this:
'A' flag: Set
'L' flag: Set
'R' flag: Set
Prefix Length: 64
Prefix: B::BNode C 🌸 will send DIO messages with a PIO like this:
'A' flag: Set
'L' flag: Set
'R' flag: Clear
Prefix Length: 64
Prefix: C::Node D 🧚 will send DIO messages with a PIO like this:
'A' flag: Set
'L' flag: Set
'R' flag: Set
Prefix Length: 64
Prefix: D::DA.1.2. DAO Messages
Node B will send DAO messages to Node A with these targets 💅:
Target B::/64Target C::/64Target D::/64
Node C will send DAO messages to Node B with this target ✨:
Target C::/64
Node D will send DAO messages to Node B with this target 🫶:
Target D::/64
A.1.3. Routing Information Base
Node A is gonna conceptually collect this into its Routing Information Base (RIB) 👑:
A::/64 connectedB::/64 via B's link localC::/64 via B's link localD::/64 via B's link local
Node B will conceptually collect this into its RIB 🔥:
::/0 via A's link localB::/64 connectedC::/64 via C's link localD::/64 via D's link local
Node C will conceptually collect this into its RIB 🍓:
::/0 via B's link localC::/64 connected
Node D will conceptually collect this into its RIB 🌈:
::/0 via B's link localD::/64 connected
A.2. Example Operation in Storing Mode with Subnet-Wide Prefix
Figure 33 shows the logical addressing setup for a simple RPL network in Storing mode, and it's giving main character energy 🎀. The root Node A sources a prefix that every node uses for address autoconfiguration across the entire RPL subnet. (This is conveyed by setting the 'A' flag and clearing the 'L' flag in the PIO of the DIO messages.) Nodes A, B, C, and D all autoconfigure to the prefix A::/64. Nodes have the option of setting the 'R' flag and publishing their address within the Prefix field of the PIO 💜.
+-------------+
| Root |
| |
| Node A |
| A::A |
| |
+------+------+
|
|
|
+------+------+
| |
| Node B |
| A::B |
| |
+------+------+
|
|
.--------------+--------------.
/ \
/ \
+------+------+ +------+------+
| | | |
| Node C | | Node D |
| A::C | | A::D |
| | | |
+-------------+ +-------------+
Figure 33: Storing Mode with Subnet-Wide PrefixA.2.1. DIO Messages and PIO
Node A, for example, will send DIO messages with a PIO like this 💖:
'A' flag: Set
'L' flag: Clear
'R' flag: Clear
Prefix Length: 64
Prefix: A::Node B, for example, will send DIO messages with a PIO like this 🦋:
'A' flag: Set
'L' flag: Clear
'R' flag: Set
Prefix Length: 64
Prefix: A::BNode C, for example, will send DIO messages with a PIO like this 🌸:
'A' flag: Set
'L' flag: Clear
'R' flag: Clear
Prefix Length: 64
Prefix: A::Node D, for example, will send DIO messages with a PIO like this 🧚:
'A' flag: Set
'L' flag: Clear
'R' flag: Set
Prefix Length: 64
Prefix: A::DA.2.2. DAO Messages
Node B will send DAO messages to Node A with these targets 💅:
Target A::B/128Target A::C/128Target A::D/128
Node C will send DAO messages to Node B with this target ✨:
Target A::C/128
Node D will send DAO messages to Node B with this target 🫶:
Target A::D/128
A.2.3. Routing Information Base
Node A is gonna conceptually collect this into its RIB 👑:
A::A/128 connectedA::B/128 via B's link localA::C/128 via B's link localA::D/128 via B's link local
Node B will conceptually collect this into its RIB 🔥:
::/0 via A's link localA::B/128 connectedA::C/128 via C's link localA::D/128 via D's link local
Node C will conceptually collect this into its RIB 🍓:
::/0 via B's link localA::C/128 connected
Node D will conceptually collect this into its RIB 🌈:
::/0 via B's link localA::D/128 connected
A.3. Example Operation in Non-Storing Mode with Node-Owned Prefixes
Figure 34 shows the logical addressing setup for a simple RPL network in Non-Storing mode, and each node basically runs its own show 👑. Node A, Node B, Node C, and Node D each own their own prefix and make it available for address autoconfiguration by on-link devices. (This is conveyed by setting the 'A' flag and the 'L' flag in the PIO of the DIO messages.) Node A owns the prefix A::/64, Node B owns B::/64, and so on. Node B autoconfigures an on-link address with respect to Node A, A::B. Nodes C and D similarly autoconfigure on-link addresses from Node B's prefix, B::C and B::D, respectively. Nodes have the option of setting the 'R' flag and publishing their address within the Prefix field of the PIO 🎀.
+-------------+
| Root |
| |
| Node A |
| |
| A::A |
+------+------+
|
|
|
+------+------+
| A::B |
| |
| Node B |
| |
| B::B |
+------+------+
|
|
.--------------+--------------.
/ \
/ \
+------+------+ +------+------+
| B::C | | B::D |
| | | |
| Node C | | Node D |
| | | |
| C::C | | D::D |
+-------------+ +-------------+
Figure 34: Non-Storing Mode with Node-Owned PrefixesA.3.1. DIO Messages and PIO
The PIO contained in the DIO messages in the Non-Storing mode with node-owned prefixes can be considered to be identical to those in the Storing mode with node-owned prefixes case (Appendix A.1.1) 🫶.
A.3.2. DAO Messages
Node B will send DAO messages to Node A with this information 💅:
Target B::/64, Transit A::B
Node C will send DAO messages to Node A with this information ✨:
Target C::/64, Transit B::C
Node D will send DAO messages to Node A with this information 🦋:
Target D::/64, Transit B::D
A.3.3. Routing Information Base
Node A will conceptually collect this into its RIB 👑. Note that Node A has enough information to construct source routes by doing recursive lookups into the RIB 🧠:
A::/64 connectedB::/64 via A::BC::/64 via B::CD::/64 via B::D
Node B will conceptually collect this into its RIB 🔥:
::/0 via A's link localB::/64 connected
Node C will conceptually collect this into its RIB 🍓:
::/0 via B's link localC::/64 connected
Node D will conceptually collect this into its RIB 🌈:
::/0 via B's link localD::/64 connected
A.4. Example Operation in Non-Storing Mode with Subnet-Wide Prefix
Figure 35 shows the logical addressing setup for a simple RPL network in Non-Storing mode 💜. The root Node A sources a prefix that every node uses for address autoconfiguration across the entire RPL subnet. (This is conveyed by setting the 'A' flag and clearing the 'L' flag in the PIO of the DIO messages.) Nodes A, B, C, and D all autoconfigure to the prefix A::/64. Nodes must set the 'R' flag and publish their address within the Prefix field of the PIO, so their children know which address to use in the transit option ⭐.
+-------------+
| Root |
| |
| Node A |
| A::A |
| |
+------+------+
|
|
|
+------+------+
| |
| Node B |
| A::B |
| |
+------+------+
|
|
.--------------+--------------.
/ \
/ \
+------+------+ +------+------+
| | | |
| Node C | | Node D |
| A::C | | A::D |
| | | |
+-------------+ +-------------+
Figure 35: Non-Storing Mode with Subnet-Wide PrefixA.4.1. DIO Messages and PIO 💖
Okay, so Node A is the one sending DIO messages with a PIO, and its settings look like this 🎀:
'A' flag: Set
'L' flag: Clear
'R' flag: Set
Prefix Length: 64
Prefix: A::ANode B does the same thing, just with its own prefix ✨
'A' flag: Set
'L' flag: Clear
'R' flag: Set
Prefix Length: 64
Prefix: A::BNode C is giving the same vibe, with its own prefix 🦋
'A' flag: Set
'L' flag: Clear
'R' flag: Set
Prefix Length: 64
Prefix: A::CAnd Node D, same energy, with its own prefix 🌸
'A' flag: Set
'L' flag: Clear
'R' flag: Set
Prefix Length: 64
Prefix: A::DA.4.2. DAO Messages 🧚
Node B sends DAO messages to Node A with this info 💅
Target A::B/128, Transit A::A
Node C sends DAO messages to Node A too, and its info is 🫶
Target A::C/128, Transit A::B
Node D sends DAO messages to Node A as well 🍓
Target A::D/128, Transit A::B
A.4.3. Routing Information Base 👑
Node A is going to quietly collect all of this into its RIB ✨ Lowkey the best part is that Node A has enough info to build source routes just by doing recursive lookups into the RIB. Iconic, honestly 😭
A::A/128 connectedA::B/128 via A::AA::C/128 via A::BA::D/128 via A::B
Node B collects these into its RIB 🌈
::/0 via A's link localA::B/128 connected
Node C collects these into its RIB 💜
::/0 via B's link localA::C/128 connected
Node D collects these into its RIB 🌸
::/0 via B's link localA::D/128 connected
A.5. Example with External Prefixes ✨
Okay, picture this simple network from Figure 36 🦋 We've got a bunch of routers in a RPL network: a DODAG root, plus Nodes A, Y, and Z. The DODAG root and Node Z can also reach different external network domains, meaning domains outside the RPL network. Those external networks could be RPL networks too, or something totally different 🧚
RPL Network +-------------------+
RPL::/64 | |
| External |
[RPL::Root] (Root)----------+ Prefix |
| | EXT_1::/64 |
| | |
| +-------------------+
[RPL::A] (A)
:
:
:
[RPL::Y] (Y)
| +-------------------+
| | |
| | External |
[RPL::Z] (Z)------------+ Prefix |
: | EXT_2::/64 |
: | |
: +-------------------+
Figure 36: Simple Network ExampleSo here's the deal 💅 The DODAG root hands out a prefix to the RPL subnet for address autoconfiguration. The whole RPL subnet uses that same prefix, RPL::/64, for autoconfig. Other implementations could totally go with more complex or hybrid schemes though, so don't lock yourself in 🎀
The DODAG root has a connection to an external prefix, EXT_1::/64 (external with respect to that RPL network). It might have learned about that connection through explicit configuration, or through IPv6 ND on a non-RPL interface, for example. The DODAG root is set up to announce info about its connection to that prefix 🌈
Node Z is also connected to an external prefix, EXT_2::/64, and it has a sub-DODAG hanging underneath it 🫶
- The DODAG root adds a RIO to its DIO messages, and that RIO carries the external prefix EXT_1::/64. Other nodes in the DODAG can repeat this info in their own DIO messages, so reachability to EXT_1::/64 gets passed down the DODAG 🌸
- Node Z can advertise reachability to the Target network EXT_2::/64 by sending DAO messages that use EXT_2::/64 as the Target in the Target option, with Node Z itself as the parent in the Transit Information option. (In Storing mode, that Transit Information option doesn't need to contain Node Z's address.) A non-storing root then learns about the 1-hop link (Node Z -- EXT_2::/64), which it can use to build source routes 🍓 Node Z can also tell the nodes in its sub-DODAG about EXT_2::/64 by sending DIO messages with a PIO, where the 'A' flag is cleared 💜
Authors' Addresses 🎀
Meet the squad! ✨ Here are the authors and their contact details 🫶
Tim Winter (editor)
EMail: wintert@acm.orgPascal Thubert (editor)
Cisco Systems
Village d'Entreprises Green Side
400, Avenue de Roumanille
Batiment T3
Biot - Sophia Antipolis 06410
France
Phone: +33 497 23 26 34
EMail: pthubert@cisco.comAnders Brandt
Sigma Designs
Emdrupvej 26A, 1.
Copenhagen DK-2100
Denmark
EMail: abr@sdesigns.dkJonathan W. Hui
Arch Rock Corporation
501 2nd St., Suite 410
San Francisco, CA 94107
USA
EMail: jhui@archrock.comRichard Kelsey
Ember Corporation
Boston, MA
USA
Phone: +1 617 951 1225
EMail: kelsey@ember.comPhilip Levis
Stanford University
358 Gates Hall, Stanford University
Stanford, CA 94305-9030
USA
EMail: pal@cs.stanford.eduKris Pister
Dust Networks
30695 Huntwood Ave.
Hayward, CA 94544
USA
EMail: kpister@dustnetworks.comRene Struik
Struik Security Consultancy
EMail: rstruik.ext@gmail.comJP. Vasseur
Cisco Systems
11, Rue Camille Desmoulins
Issy Les Moulineaux 92782
France
EMail: jpv@cisco.comRoger K. Alexander
Cooper Power Systems
20201 Century Blvd., Suite 250
Germantown, MD 20874
USA
Phone: +1 240 454 9817
EMail: roger.alexander@cooperindustries.com📦 where this page comes from
- ietf: rfc6550 2012-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms