RFC 9009
Efficient Route Invalidation
RFC 9009: Efficient Route Invalidation 💖
Okay bestie, here's the title block. This is RFC 9009, and it's titled Efficient Route Invalidation 🦋 It's a Standards Track document from the IETF, dated April 2021, with ISSN 2070-1721. The editor is R.A. Jadhav (Huawei), with P. Thubert (Cisco), and R.N. Sahoo and Z. Cao (Huawei) as co-authors. The header doesn't list any RFCs it obsoletes or updates, so it doesn't replace or amend anything. Main-character debut, no cap 👑
Abstract ✨
So the vibe here is that NPDAO messaging, the thing from RFC 6550 that lets a node say "hey, delete my old route," has some real problems 😭 This doc walks through what those problems are and what an optimized route invalidation scheme would need to do. Then it introduces a brand-new proactive route invalidation message called the "Destination Cleanup Object" (DCO) that checks all those boxes. It's giving upgrade 💅
Status of This Memo
This is an Internet Standards Track document 🌸
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🫶
For the current status, any errata, and where to send feedback, go to https://www.rfc-editor.org/info/rfc9009 ✨
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document 🙈 Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come without warranty, as described in the Simplified BSD License.
Table of Contents 🧚
1. Introduction
1.1. Requirements Language and Terminology
1.2. RPL NPDAO Messaging
1.3. Why Is NPDAO Messaging Important?
2. Problems with the RPL NPDAO Messaging
2.1. Lost NPDAO Due to Link Break to the Previous Parent
2.2. Invalidating Routes of Dependent Nodes
2.3. Possible Route Downtime Caused by Asynchronous Operation of
the NPDAO and DAO
3. Requirements for NPDAO Optimization
3.1. Req. #1: Remove Messaging Dependency on the Link to the
Previous Parent
3.2. Req. #2: Route Invalidation for Dependent Nodes at the
Parent Switching Node
3.3. Req. #3: Route Invalidation Should Not Impact Data Traffic
4. Changes to RPL Signaling
4.1. Change in RPL Route Invalidation Semantics
4.2. Transit Information Option Changes
4.3. Destination Cleanup Object (DCO)
4.3.1. Secure DCO
4.3.2. DCO Options
4.3.3. Path Sequence in the DCO
4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK)
4.3.5. Secure DCO-ACK
4.4. DCO Base Rules
4.5. Unsolicited DCO
4.6. Other Considerations
4.6.1. Invalidation of Dependent Nodes
4.6.2. NPDAO and DCO in the Same Network
4.6.3. Considerations for DCO Retries
4.6.4. DCO with Multiple Preferred Parents
5. IANA Considerations
5.1. New Registry for the Destination Cleanup Object (DCO) Flags
5.2. New Registry for the Destination Cleanup Object (DCO)
Acknowledgment Flags
5.3. RPL Rejection Status Values
6. Security Considerations
7. Normative References
Appendix A. Example Messaging
A.1. Example DCO Messaging
A.2. Example DCO Messaging with Multiple Preferred Parents
Acknowledgments
Authors' Addresses1. Introduction ✨
So RPL (the Routing Protocol for Low-Power and Lossy Networks) from [RFC6550] is a proactive, distance-vector routing scheme 💅 It has an optional messaging feature called DAO (Destination Advertisement Object) messages, which the 6LBR (6LoWPAN Border Router) and 6LR (6LoWPAN Router) can use to learn a route toward downstream nodes. (6LoWPAN is short for "IPv6 over Low-Power Wireless Personal Area Network" 🫶) In Storing mode, DAO messages create routing entries on every intermediate 6LR, starting at a node's parent and going all the way up to the 6LBR.
RPL also lets you use No-Path DAO (NPDAO) messages to invalidate a routing path for a given target, which frees up the resources that path was using 🧹 An NPDAO is just a DAO message with a route lifetime of zero. It starts at the target node and always travels upstream toward the 6LBR. This document explains the problems with using NPDAO messaging in [RFC6550] and talks through what an optimized route invalidation scheme needs. Then it specifies a new proactive route invalidation message, the "Destination Cleanup Object" (DCO), which meets those requirements. Iconic work 👑
This document only covers RPL's Storing Mode of Operation (MOP). Non-Storing MOP doesn't need an NPDAO for route invalidation, because 6LRs don't keep routing entries in that mode 🌈
1.1. Requirements Language and 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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💜
To follow this spec, you need to be familiar with all the terms and concepts from "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550] 🎀 Here are the key terms, bestie:
- Low-Power and Lossy Network (LLN): A network where both the routers and their links are constrained. LLN routers usually have limits on processing power, memory, and energy (battery power). Their links have high loss rates, low data rates, and instability 😭
- 6LoWPAN Router (6LR): An intermediate router that can send and receive Router Advertisements (RAs) and Router Solicitations (RSs), and also forward and route IPv6 packets 🦋
- Directed Acyclic Graph (DAG): A directed graph where every edge is oriented so that no cycles exist 🌸
- Destination-Oriented DAG (DODAG): A DAG rooted at a single destination, meaning a single DAG root with no outgoing edges 👑
- 6LoWPAN Border Router (6LBR): A border router that is a DODAG root and the edge node for traffic flowing in and out of the 6LoWPAN ✨
- Destination Advertisement Object (DAO): DAO messaging lets downstream routes to the nodes get set up 🧚
- DODAG Information Object (DIO): DIO messaging lets upstream routes to the 6LBR get set up. DIO messaging is initiated at the DAO root 🍓
- Common ancestor node: A 6LR/6LBR node that is the first common node between two paths of a target node 💖
- No-Path DAO (NPDAO): A DAO message with a target that has a lifetime of 0. It's used for route invalidation 🧹
- Destination Cleanup Object (DCO): A new RPL control message code defined by this document. DCO messaging improves proactive route invalidation in RPL 💅
- Regular DAO: A DAO message with a non-zero lifetime. Routing adjacencies get created or updated based on this message 🫶
- Target node: The node switching its parent, whose routing adjacencies get updated (created or removed) 🌈
1.2. RPL NPDAO Messaging
RPL uses NPDAO messaging in Storing mode so a node that changes its routing adjacencies can invalidate the previous route. This matters because nodes along the old path need to release any resources they're holding for the target node, like the routing entry 🙈
Throughout this document, we'll keep coming back to the topology in Figure 1 🦋
(6LBR)
|
|
|
(A)
/ \
/ \
/ \
(G) (H)
| |
| |
| |
(B) (C)
\ ;
\ ;
\ ;
(D)
/ \
/ \
/ \
(E) (F)
Figure 1: Sample TopologyNode D is connected through its preferred parent, B. D also has an alternate path via C toward the 6LBR. Node A is the common ancestor for D on the paths through B-G and C-H. When D switches from B to C, RPL lets it send an NPDAO to B and a regular DAO to C 💖
1.3. Why Is NPDAO Messaging Important?
LLN nodes are usually pretty resource-constrained. Memory is limited, and routing entry records are one of the main things eating up dynamic memory on the nodes 😭 Route invalidation helps 6LR nodes figure out which routing entries they can toss, so the limited resources get used better. That's why an efficient route invalidation mechanism is so necessary 💅
Also, a single parent switch can cause a whole "subtree" to move from one parent to another. So route invalidation has to happen on behalf of the subtree, not just the switching node 🌸 In the example above, when Node D switches its parent, route updates need to happen in the routing table entries of C, H, A, G, and B for destinations D, E, and F. Without efficient route invalidation, a 6LR might end up holding a ton of stale route entries 🗑️
2. Problems with the RPL NPDAO Messaging ✨
2.1. Lost NPDAO Due to Link Break to the Previous Parent
When a node switches its parent, it sends the NPDAO to its previous parent and a regular DAO to its new parent. If the node switches because of a transient or permanent failure on the parent link or the parent node, the NPDAO might never reach the parent 😭 Bestie, that's a whole problem.
2.2. Invalidating Routes of Dependent Nodes
RPL doesn't specify how route invalidation should work for dependent nodes in the subDAG of the switching node. The result is stale routing entries for those dependent nodes 🙈 The only way a 6LR could invalidate those route entries is by waiting for the route lifetime to expire, and in LLNs that lifetime can be really long ⏳
In the example topology, when Node D switches its parent, D sends an NPDAO for its own sake. The dependent child nodes E and F don't generate any NPDAO along the previous path through D to B and G. So B and G end up with stale entries for E and F 💀
2.3. Possible Route Downtime Caused by Asynchronous Operation of the NPDAO and DAO
okay so this one is a whole plot twist 😭🫶 A switching node might send out an NPDAO and a DAO through two different paths at basically the same time 🦋 Now the NPDAO can wipe out the old route 🗑️, but the regular DAO riding the new path can get lost on the way 💀 And then boom, route downtime, and downward traffic to that switching node just… stops 🙈 Not it.
Picture the example topology 🌸 Node D is switching from parent B over to parent C. The NPDAO goes out via the previous route and invalidates it, but there's literally no way to tell whether the new DAO actually updated the route entries on the new path yet 😩 Chaotic, I know.
3. Requirements for NPDAO Optimization ✨
3.1. Req. #1: Remove Messaging Dependency on the Link to the Previous Parent 🧚
okay so when the switching node sends the NPDAO to the previous parent, the link to that parent is prone to failure 💔 (that's literally why the node decided to switch in the first place 😭). So it is required that the route invalidation does NOT depend on that previous link, since it's the flaky one 🙅♀️ Here, "the previous link" means the link between the node and its previous parent, the one it's currently disassociating from 🎀
3.2. Req. #2: Route Invalidation for Dependent Nodes at the Parent Switching Node 💅
It SHOULD be possible to do route invalidation for dependent nodes rooted at the switching node 🌈
3.3. Req. #3: Route Invalidation Should Not Impact Data Traffic 💜
While the NPDAO and DAO messages are being sent, the NPDAO can successfully invalidate the previous path while the newly sent DAO gets lost (new path not set up successfully) 😱 That means downstream unreachability to the node switching paths, which is giving main character disaster 💀 So it is desirable that the route invalidation is synchronized with the DAO to avoid the risk of route downtime ✨
4. Changes to RPL Signaling 🦋
4.1. Change in RPL Route Invalidation Semantics 👑
Okay so, as Section 1.2 described, the NPDAO starts at the node changing to a new parent and travels upstream toward the root 🌳 To fix the problems from Section 2, this document adds a new proactive route invalidation message called the "Destination Cleanup Object" (DCO) 🧹 It starts at a common ancestor node and flows downstream along the old path 🌊 The common ancestor generates a DCO when it removes a next hop to a target. For example, it might do this as a delayed response to getting a regular DAO from another child node with a Path Sequence for the target that is the same or newer. In that case, the DCO transmission gets canceled 🙅♀️
The 6LRs along the DCO's path take route invalidation action based on the DCO info, then send another DCO with the same info downstream to the next hop(s) 💖 This is basically how DAOs get handled on intermediate 6LRs in the Storing MOP [RFC6550] 🧚 Just like the DAO in the Storing MOP, the DCO uses link-local unicast source and destination IPv6 addresses 🌸 The difference is that the DAO always goes upstream, but the DCO always goes downstream ⬇️
In Figure 1, when child Node D decides to switch from parent B to parent C, it sends a regular DAO to Node C 📨 The DAO has reachability info with D's address as the target and an incremented Path Sequence 🔢 Node C updates its routing table based on that info, then generates another DAO with the same reachability info and forwards it to H 💅 Node H follows the same procedure as Node C and forwards it to Node A 🫶 When Node A gets the regular DAO, it notices it already has a routing table entry for Node D's Target Address. But the next-hop info for reaching Node D has changed, meaning D decided to change paths 👀 So Node A, which is the common ancestor for Node D along the two paths (previous and new), can generate a DCO that goes downward over the old path to the target 🎯 Node A still handles normal DAO forwarding to the 6LBR, as required by [RFC6550] 💜
4.2. Transit Information Option Changes 🎀
Every RPL message is split into base message fields and additional options, as described in Section 6 of [RFC6550] 🍓 The base fields apply to the message as a whole, and options get appended to add message-specific or use-case-specific attributes ✨ For example, a DAO message can have one or more "RPL Target" options saying the reachability info is for those targets 🌈 A Transit Information option can also be associated with a set of RPL Target options 🦋
This document changes the Transit Information option so it contains the "Invalidate previous route" (I) flag 🚩 The 'I' flag tells the common ancestor node to generate a DCO on behalf of the target node, with a RPL Status of 195, which indicates the address has moved 📦 The 'I' flag is carried in the Transit Information option, which augments the reachability info for a given set of one or more RPL Targets 💅 A Transit Information option with the 'I' flag set SHOULD be carried in the DAO message when route invalidation is sought for the corresponding target or targets 🙌
The value 195 represents the 'U' and 'A' bits in RPL Status, set as per Figure 6 of [RFC9010], with the lower 6 bits set to the 6LoWPAN Neighbor Discovery (ND) Extended Address Registration Option (EARO) Status value of 3 indicating 'Moved' as per Table 1 of [RFC8505] 🧠
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|I| Flags | Path Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Updated Transit Information Option (New 'I' Flag Added)I (Invalidate previous route) flag: The 'I' flag is set by the target node to tell the common ancestor node that it wants to invalidate any previous route between the two paths 🥹
[RFC6550] lets the parent address be sent in the Transit Information option, depending on the MOP 🤓 With the Storing MOP, the field is usually not needed 🙈 For a DCO, the Parent Address field MUST NOT be included 🚫
When a common ancestor node gets a DAO message with a Transit Information option that has the 'I' flag set, and as a delayed response it removes a routing adjacency to the target in that option, it SHOULD generate a DCO message to the next hop associated with that adjacency 💫 The 'I' flag is meant to give the target node control over its own route invalidation, acting as a signal to request DCO generation 👑
4.3. Destination Cleanup Object (DCO) 🧹
A new ICMPv6 RPL control message code is defined by this specification and is called the "Destination Cleanup Object" (DCO) 🎀 It's used for proactive cleanup of state and routing info held on behalf of the target node by 6LRs ✨ The DCO always traverses downstream and cleans up route info and other state info tied to the given target 🌊 The format of the DCO message is shown in Figure 3 🦋
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 | RPL Status | DCOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID (optional) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)...
+-+-+-+-+-+-+-+-+
Figure 3: DCO Base ObjectRPLInstanceID: 8-bit field indicating the topology instance associated with the DODAG, as learned from the DIO 🌸
K: The 'K' flag means the recipient of a DCO message is expected to send a DCO-ACK back 🙏 If the DCO-ACK still isn't received after setting the 'K' flag, an implementation MAY retry the DCO later ⏰ The number of retries is implementation and deployment dependent, and is expected to be kept similar to the number of DAO retries [RFC6550] 🔁 Section 4.6.3 specifies the considerations for DCO retries 📋 A node that receives a DCO message without the 'K' flag set MAY respond with a DCO-ACK, especially to report an error condition 🚨 An example error condition is the node sending the DCO-ACK not finding a routing entry for the indicated target 🙃 When the sender doesn't set the 'K' flag, it means the sender doesn't expect a response, so the sender SHOULD NOT retry the DCO 🫠
D: The 'D' flag means the DODAGID field is present 🆔 This flag MUST be set when a local RPLInstanceID is used 💯
Flags: The 6 bits left unused in the Flags field are reserved for future use 🔮 These bits MUST be initialized to zero by the sender and MUST be ignored by the receiver 🙌
RPL Status: As defined in [RFC6550] and updated in [RFC9010] 📜 The root or common parent that generates a DCO is authoritative for setting the status info, and the info stays unchanged as it propagates down the DODAG 🌳 This document does not specify any differentiated action based on the RPL Status 🤷♀️
DCOSequence: 8-bit field incremented at each unique DCO message from a node, and echoed in the DCO-ACK message 🔢 The initial DCOSequence can be chosen randomly by the node 🎲 Section 4.4 explains how the DCOSequence is handled 📖
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG 🆔✨ This field MUST be present when the 'D' flag is set and MUST NOT be present if the 'D' flag is not set 🙅♀️ The DODAGID is used when a local RPLInstanceID is in use, to identify the DODAGID associated with that RPLInstanceID 💕
4.3.1. Secure DCO 🔐
A Secure DCO message follows the format shown in [RFC6550], Figure 7, where the base message format is the DCO message shown in Figure 3 of this document 🫶
4.3.2. DCO Options 🎁
The DCO message MUST carry at least one RPL Target and the Transit Information option, and it MAY carry other valid options 💖 This specification allows the DCO message to carry the following options:
0x00 Pad1
0x01 PadN
0x05 RPL Target
0x06 Transit Information
0x09 RPL Target DescriptorSection 6.7 of [RFC6550] defines all of the above-mentioned options 📚 The DCO carries an RPL Target option and an associated Transit Information option with a lifetime of 0x00000000 to indicate a loss of reachability to that target 💀✨
4.3.3. Path Sequence in the DCO ✨
okay so a DCO carries a Transit Information option for every path it's wiping out 🧹. The Path Sequence counter in that option is how everyone figures out how fresh the DCO is compared to the newest info the 6LRs on that path have 🕵️♀️. If a common parent makes the DCO because of a DAO, the Transit Information option in the DCO MUST use the Path Sequence from the newest Transit Information option that the common parent got for that target 💅. Now if a 6LR further down gets a DCO whose Path Sequence is NOT newer than what it already knows from a DAO's Transit Information option, that 6LR MUST NOT remove its current routing state, and it MUST NOT pass the DCO along any path where it isn't newer 🙅♀️. If the DCO is newer, the 6LR may keep a temporary state so that a DAO showing up later with an older sequence number gets ignored 🎀. And a DAO whose Transit Information option is as new as or newer than the DCO's wins 🏆. That means the path in the DAO gets installed and the DAO gets propagated. When a DCO is passed on because of a DCO from an upstream parent, the Path Sequence MUST be copied from the DCO that came in 📋.
4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) 💌
The DCO-ACK message SHOULD be sent as a unicast packet by a DCO recipient in response to a unicast DCO message with the 'K' flag set 🫶. If the 'K' flag isn't set, the receiver of the DCO message MAY still send a DCO-ACK, especially to report an error condition 🚨. Here's what the DCO-ACK message looks like (see Figure 4) 👀:
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| Flags | DCOSequence | DCO-ACK Status|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ DODAGID (optional) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: DCO-ACK Base ObjectLet's break down each field 🧁:
- RPLInstanceID: an 8-bit field for the topology instance tied to the DODAG, as learned from the DIO 🌸.
- D: the 'D' flag says the DODAGID field is there. This flag MUST be set when a local RPLInstanceID is used 🔑.
- Flags: a 7-bit unused field. The sender MUST initialize it to zero, and the receiver MUST ignore it 🫧.
- DCOSequence: an 8-bit field. It gets copied from the DCOSequence in the DCO message it's answering 🔁.
- DCO-ACK Status: this one shows how things completed. It's based on Figure 6 of [RFC9010], which defines the RPL Status Format. A StatusValue of 0 with the 'U' bit set to 0 means Success / Unqualified acceptance, per Figure 6 of [RFC9010] 🎉. A StatusValue of 1 with the 'U' bit set to 1 means 'No routing entry', as defined in Section 5.3 of this document 🫠.
- DODAGID (optional): a 128-bit unsigned integer set by a DODAG root that uniquely identifies a DODAG 🌈. It MUST be present when the 'D' flag is set and MUST NOT be present when the 'D' flag is not set. It's used when a local RPLInstanceID is in use, so the DODAGID tied to that RPLInstanceID can be identified 💜.
4.3.5. Secure DCO-ACK 🔐
A Secure DCO-ACK message follows the format shown in [RFC6550], Figure 7, where the base message format is the DCO-ACK message shown in Figure 4 of this document 🦋.
4.4. DCO Base Rules 📜
- If a node sends a DCO message with newer or different information than the prior DCO message transmission, it MUST increment the DCOSequence field by at least one. A DCO message transmission that is identical to the prior DCO message transmission MAY increment the DCOSequence field. The DCOSequence counter follows the sequence counter operation as defined in Section 7.2 of [RFC6550] 🔢.
- The RPLInstanceID and DODAGID fields of a DCO message MUST have the same values as those contained in the DAO message in response to which the DCO is generated on the common ancestor node 🪞.
- A node MAY set the 'K' flag in a unicast DCO message to solicit a unicast DCO-ACK in response, in order to confirm the attempt 🤞.
- A node receiving a unicast DCO message with the 'K' flag set SHOULD respond with a DCO-ACK. A node receiving a DCO message without the 'K' flag set MAY respond with a DCO-ACK, especially to report an error condition 💬.
- A node receiving a unicast DCO message MUST verify the stored Path Sequence in context to the given target. If the stored Path Sequence is as new as or newer than the Path Sequence received in the DCO, then the DCO MUST be dropped 🗑️.
- A node that sets the 'K' flag in a unicast DCO message but does not receive a DCO-ACK in response MAY reschedule the DCO message transmission for another attempt, up until an implementation-specific number of retries 🔁✨.
- A node receiving a unicast DCO message with its own address in the RPL Target option MUST strip off that Target option. If this Target option is the only one in the DCO message, then the DCO message MUST be dropped 🫣.
The scope of DCOSequence values is unique to the node that generates them 🏠.
4.5. Unsolicited DCO 🦋
A 6LR may generate an unsolicited DCO to unilaterally clean up the path on behalf of the target entry 🧹. The 6LR has all the state information it needs, namely the Target Address and the Path Sequence, in its routing table 📒. The conditions under which a 6LR may generate an unsolicited DCO are beyond the scope of this document, but possible reasons could be as follows 🤷♀️:
- On route expiry of an entry, a 6LR may decide to graciously clean up the entry by initiating a DCO 👋.
- A 6LR needs to entertain higher-priority entries in case the routing table is full, thus resulting in eviction of an existing routing entry. In this case, the eviction can be handled graciously by using a DCO 🫧.
A DCO that is generated asynchronously to a DAO message and is meant to discard all state along the path regardless of the Path Sequence MUST use a Path Sequence value of 240 (see Section 7.2 of [RFC6550]) 🔢. This value lets the DCO win against any established DAO path, but lose against a DAO path that is being installed ⚔️. Note that if an ancestor starts a unilateral path cleanup on an established path using a DCO with a Path Sequence value of 240, the DCO will eventually reach the target node, which will then be informed of the path invalidation 📣.
4.6. Other Considerations 🌷
4.6.1. Invalidation of Dependent Nodes 🌿
The RPL specification [RFC6550] does not provide a mechanism for route invalidation for dependent nodes 🙈. This document allows the invalidation of dependent nodes. Dependent nodes will generate their respective DAOs to update their paths, and the previous route invalidation for those nodes should work in a manner similar to what is described for a switching node 🔄. The dependent node may set the 'I' flag in the Transit Information option as part of a regular DAO, so as to request invalidation of the previous route from the common ancestor node 🙋♀️.
Dependent nodes don't get any indication about whether any of their parents have decided to switch their parent. So for route invalidation, the dependent nodes may choose to always set the 'I' flag in all their DAO messages' Transit Information options. Setting the 'I' flag isn't counterproductive even if there is no previous route to be invalidated 💅.
4.6.2. NPDAO and DCO in the Same Network 🧚
The NPDAO mechanism provided in [RFC6550] can still be used in the same network where a DCO is used 🫶. NPDAO messaging can be used, for example, on route lifetime expiry of the target, or when the node simply decides to gracefully terminate the RPL session on graceful node shutdown 🕯️. Also, a deployment can have a mix of nodes supporting the DCO and the existing NPDAO mechanism. It's also possible that the same node supports both NPDAO and DCO signaling for route invalidation 💜.
Section 9.8 of [RFC6550] states, "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." This document introduces an alternative and more optimized way to perform route invalidation, but it also allows existing NPDAO messaging to work 🌸. So an implementation has two choices when a route invalidation is to be initiated 🍓:
- Use an NPDAO to invalidate the previous route, and send a regular DAO on the new path.
- Send a regular DAO on the new path with the 'I' flag set in the Transit Information option, such that the common ancestor node initiates the DCO message downstream to invalidate the previous route ✨.
This document recommends using option 2, for the reasons specified in Section 3 of this document 🏆.
This document assumes that all the 6LRs in the network support this specification. If there are 6LR nodes that do not support this document that are in the path of the DCO message transmission, then the route invalidation for the corresponding targets (targets that are in the DCO message) may not work or may work partially 😬. Alternatively, a node could generate an NPDAO if it does not receive a DCO with itself as the target within a specified time limit. The specified time limit is deployment specific and depends upon the maximum depth of the network and per-hop average latency ⏱️. Note that sending an NPDAO and a DCO for the same operation would not result in unwanted side effects, because the acceptability of an NPDAO or a DCO depends upon the Path Sequence freshness 🫶✨.
4.6.3. Considerations for DCO Retries ✨
okay so a sender can retry a DCO if it sets the K flag and doesn't get a DCO-ACK back 🔁. the retry timing can depend on the max depth of the network and the average per-hop latency 🦋. depending on the deployment, that could range from 2 seconds to 120 seconds 💅. if the latency limits aren't known, an implementation MUST NOT retry more than once in 3 seconds and MUST NOT retry more than three times. no cap, those are the safe limits when you're in the dark 😭.
the number of retries can also be set based on how critical the route invalidation is for the deployment, plus the link-layer retry configuration 🎀. for networks that only do Multi-Point to Point (MP2P) and Point-to-Multipoint (P2MP) flows, like Advanced Metering Infrastructure (AMI) and telemetry apps 📊, the 6LRs may not be very keen to invalidate routes unless they're highly memory constrained 🧠. but for home and building automation networks that may have lots of P2P traffic 🏠, the 6LRs might be keen to invalidate efficiently, because it can also impact forwarding efficiency 🚀.
4.6.4. DCO with Multiple Preferred Parents 🌸
[RFC6550] lets a node select multiple preferred parents for route establishment 🌳. Section 9.2.1 of [RFC6550] specifies, "All DAOs generated at the same time for the same target MUST be sent with the same Path Sequence in the Transit Information." that MUST is the big rule here 👑. later, when route invalidation has to start, an NPDAO can be used. it can be initiated with an updated Path Sequence to all the parent nodes the route is being invalidated through; see [RFC6550].
with a DCO, the target node itself doesn't start the route invalidation. that's left to the common ancestor node 🫶. when a common ancestor node discovers an updated DAO from a new next hop, it starts a DCO. it's recommended that an implementation start a DCO after a time period (DelayDCO), so the common ancestor node may receive updated DAOs from all possible next hops first 🧚. this helps cut down on DCO control overhead, since the common ancestor can wait for updated DAOs from every possible direction before starting a DCO for route invalidation. after the timeout, the DCO needs to be generated for all the next hops where route invalidation needs to be done ⏰.
this document recommends a DelayDCO timer value of 1 second 💖. that's inspired by the default DelayDAO timer value of 1 second [RFC6550]. the hypothesis here is that DAOs from all possible parent sets would reach the common ancestor within this time period ✨.
it's still possible that a DCO gets generated before all the updated DAOs from all the paths are received 😬. in that case, the ancestor node would start the invalidation procedure for the paths where the updated DAO hasn't been received. the DCO generated in this case would start invalidating the segments along those paths where updated DAOs weren't received 🛤️. but once the DAO reaches these segments, the routing state would be updated along those segments. this should not lead to any inconsistent routing states ✅.
note that there's no requirement for synchronization between a DCO and DAOs 🙅. the DelayDCO timer simply makes sure DCO control overhead can be reduced, and it's only needed when the network contains nodes using multiple preferred parents 💜.
5. IANA Considerations 🦋
IANA has allocated codes for the DCO and DCO-ACK messages from the "RPL Control Codes" registry 📋.
+======+===========================================+===============+
| Code | Description | Reference |
+======+===========================================+===============+
| 0x07 | Destination Cleanup Object | This document |
+------+-------------------------------------------+---------------+
| 0x08 | Destination Cleanup Object Acknowledgment | This document |
+------+-------------------------------------------+---------------+
| 0x87 | Secure Destination Cleanup Object | This document |
+------+-------------------------------------------+---------------+
| 0x88 | Secure Destination Cleanup Object | This document |
| | Acknowledgment | |
+------+-------------------------------------------+---------------+
Table 1: New Codes for DCO and DCO-ACK MessagesIANA has allocated bit 1 from the "Transit Information Option Flags" registry for the 'I' flag (Invalidate previous route; see Section 4.2) 🎯.
5.1. New Registry for the Destination Cleanup Object (DCO) Flags 🎀
IANA has created a registry for the 8-bit Destination Cleanup Object (DCO) Flags field. The "Destination Cleanup Object (DCO) Flags" registry is located in the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry 🗂️.
New bit numbers may be allocated only by IETF Review [RFC8126]. Each bit is tracked with the following 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 | DCO-ACK request (K) | This document |
+------------+------------------------------+---------------+
| 1 | DODAGID field is present (D) | This document |
+------------+------------------------------+---------------+
Table 2: DCO Base Flags5.2. New Registry for the Destination Cleanup Object (DCO) Acknowledgment Flags 💫
IANA has created a registry for the 8-bit Destination Cleanup Object (DCO) Acknowledgment Flags field. The "Destination Cleanup Object (DCO) Acknowledgment Flags" registry is located in the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry 🗂️.
New bit numbers may be allocated only by IETF Review [RFC8126]. Each bit is tracked with the following 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 |
+------------+------------------------------+---------------+
Table 3: DCO-ACK Base Flag5.3. RPL Rejection Status Values 🚦
This document adds a new status value to the "RPL Rejection Status" subregistry initially created per Section 12.6 of [RFC9010] 📝.
+=======+==================+===============+
| Value | Meaning | Reference |
+=======+==================+===============+
| 1 | No routing entry | This document |
+-------+------------------+---------------+
Table 4: Rejection Value of the RPL Status6. Security Considerations 💀
okay bestie, this part is serious, so let's go 🫣. this document introduces the ability for a common ancestor node to invalidate a route on behalf of the target node. the common ancestor node could be directed to do so by the target node, using the 'I' flag in a DCO's Transit Information option. however, the common ancestor node is in a position to unilaterally initiate the route invalidation, since it possesses all the required state information, namely, the Target Address and the corresponding Path Sequence. thus, a rogue common ancestor node could initiate such an invalidation and impact the traffic to the target node 🚨.
the DCO carries an RPL Status value, which is informative. new Status values may be created over time, and a node will ignore an unknown Status value. this enables the RPL Status field to be used as a cover channel. but the channel only works once, since the message destroys its own medium, i.e., the existing route that it is removing 🫥.
this document also introduces an 'I' flag, which is set by the target node and used by the ancestor node to initiate a DCO if the ancestor sees an update in the routing adjacency. however, this flag could be spoofed by a malicious 6LR in the path and can cause invalidation of an existing active path. note that invalidation will work only if the Path Sequence condition is also met for the target for which the invalidation is attempted. having said that, such a malicious 6LR may spoof a DAO on behalf of the (sub) child with the 'I' flag set and can cause route invalidation on behalf of the (sub) child node 👀. note that by using existing mechanisms offered by [RFC6550], a malicious 6LR might also spoof a DAO with a lifetime of zero or otherwise cause denial of service by dropping traffic entirely, so the new mechanism described in this document does not present a substantially increased risk of disruption 🙄.
this document assumes that the security mechanisms as defined in [RFC6550] are followed, which means that the common ancestor node and all the 6LRs are part of the RPL network because they have the required credentials 🔐. a non-secure RPL network needs to take into consideration the risks highlighted in this section as well as those highlighted in [RFC6550] ⚠️.
all RPL messages support a secure version of messages. this allows integrity protection using either a Message Authentication Code (MAC) or a signature. optionally, secured RPL messages also have encryption protection for confidentiality 🔒.
this document adds new messages (DCO and DCO-ACK) that are syntactically similar to existing RPL messages such as DAO and DAO-ACK. secure versions of DCO and DCO-ACK messages are added in a way that is similar to the technique used for other RPL messages (such as DAO and DAO-ACK) 🧩.
RPL supports three security modes, as mentioned in Section 10.1 of [RFC6550] 🛡️:
- Unsecured: In this mode, it is expected that the RPL control messages are secured by other security mechanisms, such as link-layer security. In this mode, the RPL control messages, including DCO and DCO-ACK messages, do not have Security sections. Also note that unsecured mode does not imply that all messages are sent without any protection.
- Preinstalled: In this mode, RPL uses secure messages. Thus, secure versions of DCO and DCO-ACK messages MUST be used in this mode. 🔑
- Authenticated: In this mode, RPL uses secure messages. Thus, secure versions of DCO and DCO-ACK messages MUST be used in this mode. 🪪
7. Normative References ✨
Okay bestie, here's the reading list the whole spec leans on 📚 Every one of these is a must-read if you want the rest of the doc to make sense 💅
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. 📖 - [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. 🌸 RPL is the whole world this doc lives in, so this one is non-negotiable. - [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. 🧚 - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>. 🎀 This one's the reason capital letters actually mean something in these docs, iykyk. - [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. 🦋 - [RFC9010] Thubert, P., Ed. and M. Richardson, "Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves", RFC 9010, DOI 10.17487/RFC9010, April 2021,
<https://www.rfc-editor.org/info/rfc9010>. 💜
Appendix A. Example Messaging 🧚
A.1. Example DCO Messaging
Let's walk through a real-life glow-up, because this example is giving main character energy 🦋 Node D (Figure 1) is switching its parent from B to C. We're assuming D already has its own route through Node B-G-A-6LBR using pathseq=x 🌈
Quick decoder ring for the example: it only shows the parameters you actually need to follow the story. tgt is the Target option, and its value is the address of the target node. pathseq is the Path Sequence value carried in the Transit Information option. I_flag is the 'I' flag in that same Transit Information option. Here's how it plays out 💅
- Node D switches its parent from Node B to Node C. 🔀
- D sends a regular
DAO(tgt=D,pathseq=x+1,I_flag=1)along the updated path to C. 📨 - C checks for a routing entry on behalf of D. It can't find one, so it makes a brand new routing entry and passes the reachability info for target D up to H in a
DAO(tgt=D,pathseq=x+1,I_flag=1). 🫶 - H does the same thing as C. It looks for a routing entry on behalf of D, comes up empty, creates a new one, and forwards the reachability info for target D to A in a
DAO(tgt=D,pathseq=x+1,I_flag=1). 🍓 - Node A gets the
DAO(tgt=D,pathseq=x+1,I_flag=1)and checks for a routing entry on behalf of D. It finds one, but the next hop for target D is different now (it's Node G). A checks the I_flag and generates aDCO(tgt=D,pathseq=x+1)for the previous next hop for target D, which is G. Then A updates its routing entry and forwards the reachability info for target D upstream usingDAO(tgt=D,pathseq=x+1,I_flag=1). ✨ - Node G receives the
DCO(tgt=D,pathseq=x+1). It checks whether the received Path Sequence is later than the stored one. If it is, G invalidates the routing entry for target D and forwards the (un)reachability info downstream to B in aDCO(tgt=D,pathseq=x+1). 🥀 - B does the same kind of thing. It processes the
DCO(tgt=D,pathseq=x+1)by invalidating the routing entry for target D, then forwards the (un)reachability info downstream to D. 🌙 - D ignores the
DCO(tgt=D,pathseq=x+1)because the target is D itself. Lol, it's literally talking about itself 🙈 - The DCO's propagation stops at any node that has no routing information associated with the target. And if there's cached routing information and the cached Path Sequence is higher than the value in the DCO, the DCO gets dropped 🛑
A.2. Example DCO Messaging with Multiple Preferred Parents
Okay this one is so good 😭 As shown in Figure 5, node (N41) picks multiple preferred parents, (N32) and (N33). Here's the topology, then the play-by-play 👑
(6LBR)
|
|
|
(N11)
/ \
/ \
/ \
(N21) (N22)
/ / \
/ / \
/ / \
(N31) (N32) (N33)
: | /
: | /
: | /
(N41)
Figure 5: Sample Topology 2- (N41) sends a
DAO(tgt=N41,PS=x,I_flag=1)to (N32) and (N33). Here, 'I_flag' is the Invalidation flag, and 'PS' is the Path Sequence in the Transit Information option. 🔍 - (N32) sends the
DAO(tgt=N41,PS=x,I_flag=1)to (N22), and (N33) also sends the same DAO to (N22). Now (N22) knows about multiple routes to the same destination (N41) through multiple next hops. The DAOs can show up at (N22) in any order, with the I_flag set. The implementation should use the DelayDCO timer to wait before it starts the DCO. If (N22) gets an updated DAO from all of the paths, the DCO doesn't need to happen in this case. So the routing table at N22 should contain(Dst,NextHop,PS): { (N41,N32,x), (N41,N33,x) }. 🧠 - (N22) sends the
DAO(tgt=N41,PS=x,I_flag=1)to (N11). 📤 - (N11) sends the
DAO(tgt=N41,PS=x,I_flag=1)to (6LBR), and just like that, the complete path is established 🎉 - (N41) decides to change its preferred parent set from
{ N32, N33 }to{ N31, N32 }. Plot twist 🌀 - (N41) sends the
DAO(tgt=N41,PS=x+1,I_flag=1)to (N32), and also sends the same DAO to (N31). 💌 - (N32) sends the
DAO(tgt=N41,PS=x+1,I_flag=1)to (N22). Now (N22) has multiple routes to destination (N41). It notices a new Path Sequence for Target=N41 and waits for a predetermined time period (the DelayDCO time period) before it invalidates the other route,{ (N41),(N33),x }. Once that time is up, (N22) sendsDCO(tgt=N41,PS=x+1)to (N33). It also sends the regularDAO(tgt=N41,PS=x+1,I_flag=1)to (N11). ⏳ - (N33) receives the
DCO(tgt=N41,PS=x+1). That Path Sequence is the latest, so it invalidates the entry for the target (N41). Then it sendsDCO(tgt=N41,PS=x+1)on to (N41). (N41) sees that it's the target and drops the DCO. Bye bye 👋 - Picking up from Step 6, (N31) receives the
DAO(tgt=N41,PS=x+1,I_flag=1). It creates a routing entry and sends theDAO(tgt=N41,PS=x+1,I_flag=1)to (N21). Similarly, (N21) gets the DAO and then sendsDAO(tgt=N41,PS=x+1,I_flag=1)to (N11). 🦋 - (N11) receives the
DAO(tgt=N41,PS=x+1,I_flag=1)from (N21). Since it has multiple routes to (N41), it waits for the DelayDCO timer. (N41) will also get theDAO(tgt=N41,PS=x+1,I_flag=1)from (N22) via Step 7. So (N11) has received the regularDAO(tgt=N41,PS=x+1,I_flag=1)from all paths, and it does not start the DCO. Teamwork makes the dream work 🫶 - (N11) forwards the
DAO(tgt=N41,PS=x+1,I_flag=1)to (6LBR), and the full path is established 💖
Acknowledgments 🌸
Huge thanks to Alvaro Retana, Cenk Gundogan, Simon Duquennoy, Georgios Papadopoulos, and Peter van der Stok for their review and comments 🙌 Alvaro Retana especially helped shape this document's final version with critical review comments, so he deserves extra hearts 💜
Authors' Addresses 🎀
Here are the humans who made this happen, with their contact details exactly as they were written 💖
Rahul Arvind Jadhav (editor)
Huawei
Whitefield
Kundalahalli Village
Bangalore 560037
Karnataka
India
Phone: +91-080-49160700
Email: rahul.ietf@gmail.com
Pascal Thubert
Cisco Systems, Inc.
Building D
45 Allee des Ormes - BP1200
06254 MOUGINS - Sophia Antipolis
France
Phone: +33-497-23-26-34
Email: pthubert@cisco.com
Rabi Narayan Sahoo
Huawei
Whitefield
Kundalahalli Village
Bangalore 560037
Karnataka
India
Phone: +91-080-49160700
Email: rabinarayans0828@gmail.com
Zhen Cao
Huawei
W Chang'an Ave
Beijing
China
Email: zhencao.ietf@gmail.com📦 where this page comes from
- ietf: rfc9009 2021-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms