rfc9914v2.txt   rfc9914.txt 
Internet Engineering Task Force (IETF) P. Thubert, Ed. Internet Engineering Task Force (IETF) P. Thubert, Ed.
Request for Comments: 9914 Independent Request for Comments: 9914 Independent
Updates: 6550, 6553, 8138 R.A. Jadhav Updates: 6550, 6553, 8138 R.A. Jadhav
Category: Standards Track AccuKnox Category: Standards Track AccuKnox
ISSN: 2070-1721 M. Richardson ISSN: 2070-1721 M. Richardson
Sandelman Sandelman
February 2026 March 2026
Root-Initiated Routing State in the Routing Protocol for Low-Power and Root-Initiated Routing State in the Routing Protocol for Low-Power and
Lossy Networks (RPL) Lossy Networks (RPL)
Abstract Abstract
The Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC The Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC
6550) enables data packet routing along a Destination-Oriented 6550) enables data packet routing along a Destination-Oriented
Directed Acyclic Graph (DODAG). However, the default route Directed Acyclic Graph (DODAG). However, the default route
establishment mechanism relies on hop-by-hop forwarding along the establishment mechanism relies on hop-by-hop forwarding along the
skipping to change at line 103 skipping to change at line 103
4.1.2. Projected DAO-ACK 4.1.2. Projected DAO-ACK
4.1.3. Via Information Option 4.1.3. Via Information Option
4.1.4. Sibling Information Option 4.1.4. Sibling Information Option
4.1.5. P-DAO Request 4.1.5. P-DAO Request
4.1.6. Amending the RPI 4.1.6. Amending the RPI
4.1.7. Additional Flag in the RPL DODAG Configuration Option 4.1.7. Additional Flag in the RPL DODAG Configuration Option
4.2. Extending RFC 6553 4.2. Extending RFC 6553
4.3. Extending RFC 8138 4.3. Extending RFC 8138
5. New RPL Control Messages and Options 5. New RPL Control Messages and Options
5.1. New P-DAO Request Control Message 5.1. New P-DAO Request Control Message
5.2. New PDR-ACK Control Message 5.2. New PDAOAck Control Message
5.3. Via Information Options 5.3. Via Information Options
5.4. Sibling Information Option 5.4. Sibling Information Option
6. Root-Initiated Routing State 6. Root-Initiated Routing State
6.1. RPL Network Setup 6.1. RPL Network Setup
6.2. Requesting a Track 6.2. Requesting a Track
6.3. Identifying a Track 6.3. Identifying a Track
6.4. Installing a Track 6.4. Installing a Track
6.4.1. Signaling a Projected Route 6.4.1. Signaling a Projected Route
6.4.2. Installing a Track Segment with a Storing Mode P-Route 6.4.2. Installing a Track Segment with a Storing Mode P-Route
6.4.3. Installing a Protection Path with a Non-Storing Mode 6.4.3. Installing a Protection Path with a Non-Storing Mode
skipping to change at line 135 skipping to change at line 135
9. Backwards Compatibility 9. Backwards Compatibility
10. Security Considerations 10. Security Considerations
11. IANA Considerations 11. IANA Considerations
11.1. RPL DODAG Configuration Option Flag 11.1. RPL DODAG Configuration Option Flag
11.2. Elective 6LoWPAN Routing Header Type 11.2. Elective 6LoWPAN Routing Header Type
11.3. Critical 6LoWPAN Routing Header Type 11.3. Critical 6LoWPAN Routing Header Type
11.4. Registry for RPL Option Flags 11.4. Registry for RPL Option Flags
11.5. RPL Control Codes 11.5. RPL Control Codes
11.6. RPL Control Message Options 11.6. RPL Control Message Options
11.7. Registry for Projected DAO Request Flags 11.7. Registry for Projected DAO Request Flags
11.8. Registry for PDR-ACK Flags 11.8. Registry for PDAOAck Flags
11.9. Registry for PDR-ACK Acceptance Status Values 11.9. Registry for PDAOAck Acceptance Status Values
11.10. Registry for PDR-ACK Rejection Status Values 11.10. Registry for PDAOAck Rejection Status Values
11.11. Registry for Via Information Options Flags 11.11. Registry for Via Information Options Flags
11.12. Registry for Sibling Information Option Flags 11.12. Registry for Sibling Information Option Flags
11.13. Destination Advertisement Object Flag 11.13. Destination Advertisement Object Flag
11.14. Destination Advertisement Object Acknowledgment Flag 11.14. Destination Advertisement Object Acknowledgment Flag
11.15. ICMPv6 Error Code 11.15. ICMPv6 Error Code
11.16. RPL Rejection Status Values 11.16. RPL Rejection Status Values
12. References 12. References
12.1. Normative References 12.1. Normative References
12.2. Informative References 12.2. Informative References
Acknowledgments Acknowledgments
skipping to change at line 274 skipping to change at line 274
Track is the Root of the DODAG, whereas the egress is the Root of the Track is the Root of the DODAG, whereas the egress is the Root of the
reversed DODAG. From the RAW perspective, single-ended DODAGs are reversed DODAG. From the RAW perspective, single-ended DODAGs are
special Tracks that only have forward links, and that can be special Tracks that only have forward links, and that can be
leveraged to provide protection services by defining destination- leveraged to provide protection services by defining destination-
oriented protection paths within the DODAG. oriented protection paths within the DODAG.
2.3. Glossary 2.3. Glossary
This document often uses the following abbreviations: This document often uses the following abbreviations:
6LR: 6LoWPAN Router (e.g., a RPL router in an LLN)
6LoRH: 6LoWPAN Routing Header 6LoRH: 6LoWPAN Routing Header
ARQ: Automatic Repeat Request (in other words, retries) 6LR: 6LoWPAN Router (e.g., a RPL router in an LLN)
FEC: Forward Error Correction
HARQ: Hybrid Automatic Repeat Request (combines FEC and ARQ) ARQ: Automatic Repeat Request (in other words, retries)
CMO: Control Message Option CMO: Control Message Option
DAO: Destination Advertisement Object
DAG: Directed Acyclic Graph DAG: Directed Acyclic Graph
DAO: Destination Advertisement Object
DIO: DODAG Information Object DIO: DODAG Information Object
DODAG: Destination-Oriented Directed Acyclic Graph. A DAG with DODAG: Destination-Oriented Directed Acyclic Graph. A DAG with
only one vertex (i.e., node) that has no outgoing edge only one vertex (i.e., node) that has no outgoing edge
(i.e., link). (i.e., link).
FEC: Forward Error Correction
GUA: Global Unicast Address GUA: Global Unicast Address
HARQ: Hybrid Automatic Repeat Request (combines FEC and ARQ)
LLN: Low-Power and Lossy Network LLN: Low-Power and Lossy Network
MOP: Mode of Operation MOP: Mode of Operation
NSM-VIO: Non-Storing Mode Via Information Option. Source-routed
VIO used in Non-Storing Mode P-DAO messages.
P-DAO: Projected DAO P-DAO: Projected DAO
P-Route: Projected Route P-Route: Projected Route
PDR: P-DAO Request
PCE: Path Computation Element PCE: Path Computation Element
PLR: Point of Local Repair PDAOReq: P-DAO Request
RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf) PLR: Point of Local Repair
RAL: RPL-Aware Leaf RAL: RPL-Aware Leaf
RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)
RH: Routing Header RH: Routing Header
RIB: Routing Information Base (i.e., the routing table) RIB: Routing Information Base (i.e., the routing table)
RPI: RPL Packet Information RPI: RPL Packet Information
RPL: Routing Protocol for Low-Power and Lossy Networks RPL: Routing Protocol for Low-Power and Lossy Networks
RTO: RPL Target Option RTO: RPL Target Option
RUL: RPL-Unaware Leaf RUL: RPL-Unaware Leaf
SIO: Sibling Information Option SIO: Sibling Information Option
ULA: Unique Local Address
NSM-VIO: Non-Storing Mode Via Information Option. Source-routed
VIO used in Non-Storing Mode P-DAO messages.
SLO: Service Level Objective SLO: Service Level Objective
SM-VIO: Storing Mode Via Information Option. Strict VIO used in
Storing Mode P-DAO messages.
SRH: Source Routing Header (i.e., IPv6 RH type 3); see SRH: Source Routing Header (i.e., IPv6 RH type 3); see
Section 2.4.5.7.2. Section 2.4.5.7.2.
SRH-6LoRH: Source Routing Header 6LoRH. A compressed form of SRH SRH-6LoRH: Source Routing Header 6LoRH. A compressed form of SRH
defined in "IPv6 over Low-Power Wireless Personal Area defined in "IPv6 over Low-Power Wireless Personal Area
Network (6LoWPAN) Routing Header" [RFC8138]. Network (6LoWPAN) Routing Header" [RFC8138].
TIO: Transit Information Option TIO: Transit Information Option
SM-VIO: Storing Mode Via Information Option. Strict VIO used in ULA: Unique Local Address
Storing Mode P-DAO messages.
VIO: Via Information Option. It can be an SM-VIO or NSM-VIO. VIO: Via Information Option. It can be an SM-VIO or NSM-VIO.
2.4. Domain Terms 2.4. Domain Terms
This specification uses the terminology defined in the sections that This specification uses the terminology defined in the sections that
follow. follow.
2.4.1. Projected Route 2.4.1. Projected Route
skipping to change at line 1889 skipping to change at line 1889
4.1. Extending RFC 6550 4.1. Extending RFC 6550
This specification Extends RPL [RPL] to enable the Root to install This specification Extends RPL [RPL] to enable the Root to install
forward routes inside a main DODAG that is operated as Non-Storing forward routes inside a main DODAG that is operated as Non-Storing
Mode. The Root issues a P-DAO message (see Section 4.1.1) to the Mode. The Root issues a P-DAO message (see Section 4.1.1) to the
Track ingress; the P-DAO message contains a new VIO that installs a Track ingress; the P-DAO message contains a new VIO that installs a
strict or a loose sequence of hops to form a Track segment or a strict or a loose sequence of hops to form a Track segment or a
protection path, respectively. protection path, respectively.
The P-DAO Request (PDR) is a new message detailed in Section 5.1. As The P-DAO Request (PDAOReq) is a new message detailed in Section 5.1.
per Section 6 of [RPL], if a node receives this message and it does As per Section 6 of [RPL], if a node receives this message and it
not understand this new code, it discards the message. When the Root does not understand this new code, it discards the message. When the
initiates communication to a node that it has not communicated with Root initiates communication to a node that it has not communicated
before and that it has not ascertained to implement this with before and that it has not ascertained to implement this
specification (by means such as capabilities), then the Root SHOULD specification (by means such as capabilities), then the Root SHOULD
request a PDR-ACK. request a PDAOAck.
A PDR message enables a Track ingress to request the Track from the A PDAOReq message enables a Track ingress to request the Track from
Root. The resulting Track is also a DODAG for which the Track the Root. The resulting Track is also a DODAG for which the Track
ingress is the Root, and the owner is the address that serves as the ingress is the Root, and the owner is the address that serves as the
DODAGID and is authoritative for the associated namespace from which DODAGID and is authoritative for the associated namespace from which
the TrackID is selected. In the context of this specification, the the TrackID is selected. In the context of this specification, the
installed route appears as a more-specific route to the Track installed route appears as a more-specific route to the Track
Targets, and the Track ingress forwards the packets toward the Targets, and the Track ingress forwards the packets toward the
Targets via the Track using normal longest match IP forwarding. Targets via the Track using normal longest match IP forwarding.
To ensure that the PDR and P-DAO messages can flow at most times, it To ensure that the PDAOReq and P-DAO messages can flow at most times,
is RECOMMENDED that the nodes involved in a Track maintain multiple it is RECOMMENDED that the nodes involved in a Track maintain
parents in the main DODAG, advertise them all to the Root, and use multiple parents in the main DODAG, advertise them all to the Root,
them in turn to retry similar packets. It is also RECOMMENDED that and use them in turn to retry similar packets. It is also
the Root uses diverse source route paths to retry similar messages to RECOMMENDED that the Root uses diverse source route paths to retry
the nodes in the Track. similar messages to the nodes in the Track.
4.1.1. Projected DAO 4.1.1. Projected DAO
Section 6 of [RPL] introduces the RPL Control Message Options (CMOs), Section 6 of [RPL] introduces the RPL Control Message Options (CMOs),
including the RPL Target Option (RTO) and Transit Information Option including the RPL Target Option (RTO) and Transit Information Option
(TIO), which can be placed in RPL messages such as the DAO. A DAO (TIO), which can be placed in RPL messages such as the DAO. A DAO
message signals routing information to one or more Targets indicated message signals routing information to one or more Targets indicated
in the RTOs and provides one and only one via-node in the TIO, with in the RTOs and provides one and only one via-node in the TIO, with
the via-node being the tunnel endpoint to reach the targets. the via-node being the tunnel endpoint to reach the targets.
skipping to change at line 2092 skipping to change at line 2092
| 2. The multicast DAO may be used to enable direct and indirect | 2. The multicast DAO may be used to enable direct and indirect
| (via a common neighbor) P2P communication without needing the | (via a common neighbor) P2P communication without needing the
| DODAG to relay the packets. The multicast DAO exposes the | DODAG to relay the packets. The multicast DAO exposes the
| sender's addresses as Targets in RTOs and the sender's | sender's addresses as Targets in RTOs and the sender's
| neighbors addresses as siblings in SIOs; this tells the | neighbors addresses as siblings in SIOs; this tells the
| sender's neighbors that the sender is willing to act as a | sender's neighbors that the sender is willing to act as a
| relay between those of its neighbors that are too far apart. | relay between those of its neighbors that are too far apart.
4.1.5. P-DAO Request 4.1.5. P-DAO Request
The set of RPL Control Messages is Extended to include the PDR and The set of RPL Control Messages is Extended to include the PDAOReq
P-DAO Request Acknowledgement (PDR-ACK). These two new RPL Control and P-DAO Request Acknowledgement (PDAOAck). These two new RPL
Messages enable a RAN to request the establishment of a Track between Control Messages enable a RAN to request the establishment of a Track
itself (as the Track ingress Node) and a Track egress. The node between itself (as the Track ingress Node) and a Track egress. The
makes its request by sending a new PDR message to the Root. The Root node makes its request by sending a new PDAOReq message to the Root.
confirms with a new PDR-ACK message back to the requester RAN; see The Root confirms with a new PDAOAck message back to the requester
Section 5.1 for more. RAN; see Section 5.1 for more.
4.1.6. Amending the RPI 4.1.6. Amending the RPI
Sending a packet within a RPL Local Instance requires the presence of Sending a packet within a RPL Local Instance requires the presence of
the abstract RPI described in Section 11.2 of [RPL] in the outer IPv6 the abstract RPI described in Section 11.2 of [RPL] in the outer IPv6
header chain (see [RFC9008]). The RPI carries a Local RPLInstanceID header chain (see [RFC9008]). The RPI carries a Local RPLInstanceID
that, in association with either the source or the destination that, in association with either the source or the destination
address in the IPv6 header, indicates the RPL Instance that the address in the IPv6 header, indicates the RPL Instance that the
packet follows. packet follows.
skipping to change at line 2147 skipping to change at line 2147
Figure 10: DODAG Configuration Option (Partial View) Figure 10: DODAG Configuration Option (Partial View)
This specification Amends [RPL] to define the new "Projected Routes This specification Amends [RPL] to define the new "Projected Routes
Support" (D) flag. The 'D' flag is encoded in bit position 0 of the Support" (D) flag. The 'D' flag is encoded in bit position 0 of the
reserved Flags in the DODAG Configuration option (this is the most reserved Flags in the DODAG Configuration option (this is the most
significant bit). It is set to 0 in legacy implementations as significant bit). It is set to 0 in legacy implementations as
specified respectively in Sections 20.14 and 6.7.6 of [RPL]. specified respectively in Sections 20.14 and 6.7.6 of [RPL].
The 'D' flag is set to 1 to indicate that this specification is The 'D' flag is set to 1 to indicate that this specification is
enabled in the network and that the Root will install the requested enabled in the network and that the Root will install the requested
Tracks when feasible upon receiving a PDR message. Tracks when feasible upon receiving a PDAOReq message.
Section 4.1.2 of [RFC9008] Amends [RPL] to indicate that the Section 4.1.2 of [RFC9008] Amends [RPL] to indicate that the
definition of the Flags applies to MOP values from zero (0) to six definition of the Flags applies to MOP values from zero (0) to six
(6) only. For a MOP value of 7, the implementation MUST consider (6) only. For a MOP value of 7, the implementation MUST consider
that the Root accepts PDR messages and will install P-Routes. that the Root accepts PDAOReq messages and will install P-Routes.
The RPL DODAG Configuration option is typically placed in a DIO The RPL DODAG Configuration option is typically placed in a DIO
message. The DIO message propagates down the DODAG to form and then message. The DIO message propagates down the DODAG to form and then
maintain its structure. The DODAG Configuration option is copied maintain its structure. The DODAG Configuration option is copied
unmodified from parents to children. unmodified from parents to children.
[RPL] states that: [RPL] states that:
| Nodes other than the DODAG root MUST NOT modify this information | Nodes other than the DODAG root MUST NOT modify this information
| when propagating the DODAG Configuration option. | when propagating the DODAG Configuration option.
skipping to change at line 2273 skipping to change at line 2273
RPLInstanceID field signals the TrackID; see Sections 3.4 and 6.3. RPLInstanceID field signals the TrackID; see Sections 3.4 and 6.3.
Section 6.8 details how a Track ingress leverages the P-RPI-6LoRH Section 6.8 details how a Track ingress leverages the P-RPI-6LoRH
header as part of the encapsulation of a packet to place it into a header as part of the encapsulation of a packet to place it into a
Track. Track.
5. New RPL Control Messages and Options 5. New RPL Control Messages and Options
5.1. New P-DAO Request Control Message 5.1. New P-DAO Request Control Message
The PDR message is sent by a node in the main DODAG to the Root. It The PDAOReq message is sent by a node in the main DODAG to the Root.
is a request to establish or refresh a Track where the node sending It is a request to establish or refresh a Track where the node
the PDR is the Track ingress, and it signals whether or not an sending the PDAOReq is the Track ingress, and it signals whether or
acknowledgment called PDR-ACK is requested. A positive PDR-ACK not an acknowledgment called PDAOAck is requested. A positive
indicates that the Track was built and that the Root commits to PDAOAck indicates that the Track was built and that the Root commits
maintaining the Track for the negotiated lifetime. to maintaining the Track for the negotiated lifetime.
The main Root MAY indicate to the Track ingress that the Track was The main Root MAY indicate to the Track ingress that the Track was
terminated before its time; to do so, it MUST use an asynchronous terminated before its time; to do so, it MUST use an asynchronous
PDR-ACK with a negative status. A status of "Transient Failure" (see PDAOAck with a negative status. A status of "Transient Failure" (see
Section 11.10) is an indication that the PDR may be retried after a Section 11.10) is an indication that the PDAOReq may be retried after
reasonable time that depends on the deployment. Other negative a reasonable time that depends on the deployment. Other negative
status values indicate a permanent error; the attempt must be status values indicate a permanent error; the attempt must be
abandoned until a corrective action is taken at the application layer abandoned until a corrective action is taken at the application layer
or through network management. or through network management.
The Track ingress to be of the requested Track is indicated in the The Track ingress to be of the requested Track is indicated in the
source IPv6 address of the PDR, and the TrackID is indicated in the source IPv6 address of the PDAOReq, and the TrackID is indicated in
message itself. At least one RPL Target Option MUST be present in the message itself. At least one RPL Target Option MUST be present
the message. If more than one RPL Target Option is present, the Root in the message. If more than one RPL Target Option is present, the
will provide a Track that reaches the first listed Target and a Root will provide a Track that reaches the first listed Target and a
subset of the other Targets; the details of the subset selection are subset of the other Targets; the details of the subset selection are
out of scope. The RTO signals the Track egress (see more in out of scope. The RTO signals the Track egress (see more in
Section 6.2). Section 6.2).
The RPL Control Code for the PDR is 0x09. The format of the PDR Base The RPL Control Code for the PDAOReq is 0x09. The format of the
Object is as follows: PDAOReq Base Object is as follows:
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID |K|R| Flags | ReqLifetime | PDRSequence | | TrackID |K|R| Flags | ReqLifetime |PDAOReqSequence|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 13: New P-DAO Request Format Figure 13: New P-DAO Request Format
TrackID: 8-bit field. In the context of this specification, the TrackID: 8-bit field. In the context of this specification, the
TrackID field signals the RPLInstanceID of the DODAG formed by the TrackID field signals the RPLInstanceID of the DODAG formed by the
Track; see Sections 3.4 and 6.3. To allocate a new Track, the Track; see Sections 3.4 and 6.3. To allocate a new Track, the
ingress Node must provide a value that is not in use at this time. ingress Node must provide a value that is not in use at this time.
K: The 'K' flag is set to indicate that the recipient is expected to K: The 'K' flag is set to indicate that the recipient is expected to
send a PDR-ACK back. send a PDAOAck back.
R: The 'R' flag is set to request a Complex Track for redundancy. R: The 'R' flag is set to request a Complex Track for redundancy.
Flags: Reserved. The Flags field MUST be initialized to zero by the Flags: Reserved. The Flags field MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
ReqLifetime: 8-bit unsigned integer. The requested lifetime for the ReqLifetime: 8-bit unsigned integer. The requested lifetime for the
Track expressed in Lifetime Units (obtained from the DODAG Track expressed in Lifetime Units (obtained from the DODAG
Configuration option). The value of 255 (0xFF) represents Configuration option). The value of 255 (0xFF) represents
infinity (never time out). infinity (never time out).
A PDR with a fresher PDRSequence refreshes the lifetime, and a A PDAOReq with a fresher PDAOReqSequence refreshes the lifetime,
PDRLifetime of 0 indicates that the Track MUST be destroyed, e.g., and a ReqLifetime of 0 indicates that the Track MUST be destroyed,
when the application that requested the Track terminates. e.g., when the application that requested the Track terminates.
PDRSequence: 8-bit wrapping sequence number, obeying the operation PDAOReqSequence: 8-bit wrapping sequence number, obeying the
in Section 7.2 of [RPL]. The PDRSequence is used to correlate a operation in Section 7.2 of [RPL]. The PDAOReqSequence is used to
PDR-ACK message with the PDR message that triggered it. It is correlate a PDAOAck message with the PDAOReq message that
incremented at each PDR message and echoed in the PDR-ACK by the triggered it. It is incremented at each PDAOReq message and
Root. echoed in the PDAOAck by the Root.
5.2. New PDR-ACK Control Message 5.2. New PDAOAck Control Message
The new PDR-ACK is sent as a response to a PDR message with the 'K' The new PDAOAck is sent as a response to a PDAOReq message with the
flag set. The RPL Control Code for the PDR-ACK is 0x0A. Its format 'K' flag set. The RPL Control Code for the PDAOAck is 0x0A. Its
is as follows: format is as follows:
0 1 2 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TrackID | Flags | Track Lifetime| PDRSequence | | TrackID | Flags | Track Lifetime|PDAOReqSequence|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDR-ACK Status| Reserved | | PDAOAck Status| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
Figure 14: New PDR-ACK Control Message Format Figure 14: New PDAOAck Control Message Format
TrackID: Set to the TrackID indicated in the TrackID field of the TrackID: Set to the TrackID indicated in the TrackID field of the
PDR messages that this replies to. PDAOReq messages that this replies to.
Flags: Reserved. The Flags field MUST be initialized to zero by the Flags: Reserved. The Flags field MUST be initialized to zero by the
sender and MUST be ignored by the receiver. sender and MUST be ignored by the receiver.
Track Lifetime: Indicates the remaining lifetime for the Track, Track Lifetime: Indicates the remaining lifetime for the Track,
expressed in Lifetime Units. The value of 255 (0xFF) represents expressed in Lifetime Units. The value of 255 (0xFF) represents
infinity. The value of zero (0x00) indicates that the Track was infinity. The value of zero (0x00) indicates that the Track was
destroyed or not created. destroyed or not created.
PDRSequence: 8-bit wrapping sequence number. It is incremented at PDAOReqSequence: 8-bit wrapping sequence number. It is incremented
each PDR message and echoed in the PDR-ACK. at each PDAOReq message and echoed in the PDAOAck.
PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK PDAOAck Status: 8-bit field indicating the completion. The PDAOAck
Status is substructured as indicated in Figure 15: Status is substructured as indicated in Figure 15:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|R| Value | |E|R| Value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 15: PDR-ACK Status Format Figure 15: PDAOAck Status Format
E: 1-bit flag. Set to indicate a rejection. When not set, a E: 1-bit flag. Set to indicate a rejection. When not set, a
Value field that is set to 0 indicates Success/Unqualified Value field that is set to 0 indicates Success/Unqualified
Acceptance, and other values indicate "not an outright Acceptance, and other values indicate "not an outright
rejection". rejection".
R: 1-bit flag. Reserved; MUST be set to 0 by the sender and MUST R: 1-bit flag. Reserved; MUST be set to 0 by the sender and MUST
be ignored by the receiver. be ignored by the receiver.
Status Value: 6-bit unsigned integer. Values depend on the Status Value: 6-bit unsigned integer. Values depend on the
skipping to change at line 2653 skipping to change at line 2653
defined for the RPL domain. defined for the RPL domain.
Though fragmentation is possible in a 6LoWPAN LLN, e.g., using Though fragmentation is possible in a 6LoWPAN LLN, e.g., using
[6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to define [6LoWPAN], [RFC8930], and/or [RFC8931], it is RECOMMENDED to define
an MTU that is larger than 1280 between the RPL routers that form the an MTU that is larger than 1280 between the RPL routers that form the
main DODAG to allow for the necessary header additions, while still main DODAG to allow for the necessary header additions, while still
exposing 1280 to the 6LoWPAN endpoint stacks. exposing 1280 to the 6LoWPAN endpoint stacks.
6.2. Requesting a Track 6.2. Requesting a Track
This specification introduces the PDR message, which is used by an This specification introduces the PDAOReq message, which is used by
LLN node to request the formation of a new Track for which the LLN an LLN node to request the formation of a new Track for which the LLN
node is the ingress. Note that the namespace for the TrackID is node is the ingress. Note that the namespace for the TrackID is
owned by the ingress node, and in the absence of a PDR, there must be owned by the ingress node, and in the absence of a PDAOReq, there
some procedure for the Root to assign TrackIDs in that namespace must be some procedure for the Root to assign TrackIDs in that
while avoiding collisions (see more in Section 6.3). namespace while avoiding collisions (see more in Section 6.3).
The PDR signals the desired TrackID and the duration for which the The PDAOReq signals the desired TrackID and the duration for which
Track should be established. Upon a PDR, the Root MAY install the the Track should be established. Upon a PDAOReq, the Root MAY
Track as requested, in which case it answers with a PDR-ACK install the Track as requested, in which case it answers with a
indicating the granted Track Lifetime. All the segments MUST be of PDAOAck indicating the granted Track Lifetime. All the segments MUST
the same mode, either Storing or Non-Storing. All the segments MUST be of the same mode, either Storing or Non-Storing. All the segments
be created with the same TrackID and the same DODAGID signaled in the MUST be created with the same TrackID and the same DODAGID signaled
P-DAO. in the P-DAO.
The Root designs the Track as it sees fit and updates/changes the The Root designs the Track as it sees fit and updates/changes the
segments over time to serve the Track as needed. Note that there is segments over time to serve the Track as needed. Note that there is
no protocol element to notify the requesting Track ingress when no protocol element to notify the requesting Track ingress when
changes happen deeper down the Track, so they are transparent to the changes happen deeper down the Track, so they are transparent to the
Track ingress. If the main Root cannot maintain an expected service Track ingress. If the main Root cannot maintain an expected service
level, then it needs to tear down the Track completely. The Segment level, then it needs to tear down the Track completely. The Segment
Lifetime in the P-DAO messages does not need to be aligned to the Lifetime in the P-DAO messages does not need to be aligned to the
Requested Lifetime in the PDR or between P-DAO messages for different Requested Lifetime in the PDAOReq or between P-DAO messages for
segments. For example, the Root may use shorter lifetimes for the different segments. For example, the Root may use shorter lifetimes
segments and renew them or change them during the lifetime of the for the segments and renew them or change them during the lifetime of
Track. All the components (protection paths and segments) of a Track the Track. All the components (protection paths and segments) of a
MUST be destroyed (or have their lifetime elapsed) before the TrackID Track MUST be destroyed (or have their lifetime elapsed) before the
can be reused. TrackID can be reused.
When the Track Lifetime is relatively close to elapse -- meaning in When the Track Lifetime is relatively close to elapse -- meaning in
the order of the trip time from the node to the Root -- the the order of the trip time from the node to the Root -- the
requesting node SHOULD resend a PDR using the TrackID in the PDR-ACK requesting node SHOULD resend a PDAOReq using the TrackID in the
to extend the lifetime of the Track; otherwise, the Track will time PDAOAck to extend the lifetime of the Track; otherwise, the Track
out, and the Root will tear down the whole structure. will time out, and the Root will tear down the whole structure.
If the Track fails and cannot be restored, the Root notifies the If the Track fails and cannot be restored, the Root notifies the
requesting node asynchronously with a PDR-ACK with a Track Lifetime requesting node asynchronously with a PDAOAck with a Track Lifetime
of 0, indicating that the Track has failed, and a PDR-ACK Status, of 0, indicating that the Track has failed, and a PDAOAck Status,
indicating the reason of the fault. indicating the reason of the fault.
6.3. Identifying a Track 6.3. Identifying a Track
RPL defines the concept of an Instance to signal an individual RPL defines the concept of an Instance to signal an individual
routing topology, and multiple topologies can coexist in the same routing topology, and multiple topologies can coexist in the same
network. The RPLInstanceID is tagged in the RPI of every packet to network. The RPLInstanceID is tagged in the RPI of every packet to
signal which topology the packet actually follows. signal which topology the packet actually follows.
This specification leverages the RPL Instance model as follows: This specification leverages the RPL Instance model as follows:
skipping to change at line 2742 skipping to change at line 2742
used in an RPI, the source address of the IPv6 packet signals the used in an RPI, the source address of the IPv6 packet signals the
DODAGID. DODAGID.
The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID) The P-DAO Base Object MUST indicate the tuple (DODAGID, TrackID)
that identifies the Track as shown in Figure 8, and the P-RouteID that identifies the Track as shown in Figure 8, and the P-RouteID
that identifies the P-Route MUST be signaled in the VIO as shown that identifies the P-Route MUST be signaled in the VIO as shown
in Figure 16. in Figure 16.
The Track ingress is the Root of the DODAGID formed by the Local The Track ingress is the Root of the DODAGID formed by the Local
RPL Instance. It owns the namespace of its TrackIDs, so it can RPL Instance. It owns the namespace of its TrackIDs, so it can
pick any unused value to request a new Track with a PDR. In a pick any unused value to request a new Track with a PDAOReq. In a
particular deployment where PDRs are not used, a portion of the particular deployment where PDAOReqs are not used, a portion of
namespace can be administratively delegated to the main Root, the namespace can be administratively delegated to the main Root,
meaning that the main Root is authoritative for assigning the meaning that the main Root is authoritative for assigning the
TrackIDs for the Tracks it creates. TrackIDs for the Tracks it creates.
With this specification, the main Root is aware of all the active With this specification, the main Root is aware of all the active
Tracks, so it can also pick any unused value to form Tracks Tracks, so it can also pick any unused value to form Tracks
without a PDR. To avoid a collision of the main Root and the without a PDAOReq. To avoid a collision of the main Root and the
Track ingress picking the same value at the same time, it is Track ingress picking the same value at the same time, it is
RECOMMENDED that the Track ingress starts allocating the ID value RECOMMENDED that the Track ingress starts allocating the ID value
of the Local RPLInstanceID (see Section 5.1 of [RPL]) used as of the Local RPLInstanceID (see Section 5.1 of [RPL]) used as
TrackIDs with the value 0 incrementing, while the Root starts with TrackIDs with the value 0 incrementing, while the Root starts with
63 decrementing. 63 decrementing.
6.4. Installing a Track 6.4. Installing a Track
A path can be installed by a single P-Route that signals the sequence A path can be installed by a single P-Route that signals the sequence
of consecutive nodes either in Storing Mode as a single-segment Track of consecutive nodes either in Storing Mode as a single-segment Track
skipping to change at line 3630 skipping to change at line 3630
When applied to radio LLNs such as IEEE Std 802.15.4, the lower-layer When applied to radio LLNs such as IEEE Std 802.15.4, the lower-layer
frame protection can be leveraged with an appropriate join protocol. frame protection can be leveraged with an appropriate join protocol.
The 6TiSCH Constrained Join Protocol (CoJP) [RFC9031] uses the RPL The 6TiSCH Constrained Join Protocol (CoJP) [RFC9031] uses the RPL
Root as 6LBR. The join protocol could be extended to provide Root as 6LBR. The join protocol could be extended to provide
additional key material for pledges to 6LBR communication when additional key material for pledges to 6LBR communication when
additional end-to-end security is desired beyond the hop-by-hop additional end-to-end security is desired beyond the hop-by-hop
security from the lower layer. security from the lower layer.
With this specification, the Root MAY generate P-DAO messages but With this specification, the Root MAY generate P-DAO messages but
other nodes MUST NOT do so. PDR messages MUST be sent to the Root. other nodes MUST NOT do so. PDAOReq messages MUST be sent to the
This specification expects that the communication with the Root is Root. This specification expects that the communication with the
authenticated but does not enforce which method is used. Root is authenticated but does not enforce which method is used.
Additionally, the trust model could include a role validation (e.g., Additionally, the trust model could include a role validation (e.g.,
using a role-based authorization) to ensure that the node that claims using a role-based authorization) to ensure that the node that claims
to be a RPL Root is entitled to do so. That trust should propagate to be a RPL Root is entitled to do so. That trust should propagate
from egress to ingress in the case of a Storing Mode P-DAO. from egress to ingress in the case of a Storing Mode P-DAO.
This specification suggests some validation of the VIO to prevent This specification suggests some validation of the VIO to prevent
basic loops, i.e., by avoiding a node that appears twice. But that basic loops, i.e., by avoiding a node that appears twice. But that
is only a minimal protection. Arguably, an attacker that can inject is only a minimal protection. Arguably, an attacker that can inject
P-DAOs can reroute any traffic and rapidly deplete critical resources P-DAOs can reroute any traffic and rapidly deplete critical resources
skipping to change at line 3726 skipping to change at line 3726
+------------+----------------------+-----------+ +------------+----------------------+-----------+
| 1 | Rank-Error (R) | [RFC6553] | | 1 | Rank-Error (R) | [RFC6553] |
+------------+----------------------+-----------+ +------------+----------------------+-----------+
| 2 | Forwarding-Error (F) | [RFC6553] | | 2 | Forwarding-Error (F) | [RFC6553] |
+------------+----------------------+-----------+ +------------+----------------------+-----------+
| 3 | Projected-Route (P) | RFC 9914 | | 3 | Projected-Route (P) | RFC 9914 |
+------------+----------------------+-----------+ +------------+----------------------+-----------+
| 4..255 | Unassigned | | | 4..255 | Unassigned | |
+------------+----------------------+-----------+ +------------+----------------------+-----------+
Table 24: Initial PDR Flags Table 24: Initial PDAOReq Flags
11.5. RPL Control Codes 11.5. RPL Control Codes
IANA has updated the "RPL Control Codes" registry under the "Routing IANA has updated the "RPL Control Codes" registry under the "Routing
Protocol for Low Power and Lossy Networks (RPL)" registry group Protocol for Low Power and Lossy Networks (RPL)" registry group
[IANA-RPL] as indicated in Table 25: [IANA-RPL] as indicated in Table 25:
+======+=============================+===========+ +======+=========================================+===========+
| Code | Description | Reference | | Code | Description | Reference |
+======+=============================+===========+ +======+=========================================+===========+
| 0x09 | Projected DAO Request (PDR) | RFC 9914 | | 0x09 | Projected DAO Request (PDAOReq) | RFC 9914 |
+------+-----------------------------+-----------+ +------+-----------------------------------------+-----------+
| 0x0A | PDR-ACK | RFC 9914 | | 0x0A | P-DAO Request Acknowledgement (PDAOAck) | RFC 9914 |
+------+-----------------------------+-----------+ +------+-----------------------------------------+-----------+
Table 25: New RPL Control Codes Table 25: New RPL Control Codes
11.6. RPL Control Message Options 11.6. RPL Control Message Options
IANA has updated the "RPL Control Message Options" registry under the IANA has updated the "RPL Control Message Options" registry under the
"Routing Protocol for Low Power and Lossy Networks (RPL)" registry "Routing Protocol for Low Power and Lossy Networks (RPL)" registry
group [IANA-RPL] as indicated in Table 26: group [IANA-RPL] as indicated in Table 26:
+=======+==============================================+===========+ +=======+==============================================+===========+
skipping to change at line 3764 skipping to change at line 3764
+-------+----------------------------------------------+-----------+ +-------+----------------------------------------------+-----------+
| 0x10 | Source-Routed Non-Storing Mode VIO (NSM-VIO) | RFC 9914 | | 0x10 | Source-Routed Non-Storing Mode VIO (NSM-VIO) | RFC 9914 |
+-------+----------------------------------------------+-----------+ +-------+----------------------------------------------+-----------+
| 0x11 | Sibling Information Option (SIO) | RFC 9914 | | 0x11 | Sibling Information Option (SIO) | RFC 9914 |
+-------+----------------------------------------------+-----------+ +-------+----------------------------------------------+-----------+
Table 26: RPL Control Message Options Table 26: RPL Control Message Options
11.7. Registry for Projected DAO Request Flags 11.7. Registry for Projected DAO Request Flags
IANA has created the "Projected DAO Request (PDR) Flags" registry IANA has created the "Projected DAO Request (PDAOReq) Flags" registry
under the "Routing Protocol for Low Power and Lossy Networks (RPL)" under the "Routing Protocol for Low Power and Lossy Networks (RPL)"
registry group [IANA-RPL]. The bits are indexed from 0 (leftmost) to registry group [IANA-RPL]. The bits are indexed from 0 (leftmost) to
7. Each bit is tracked with the following qualities: 7. Each bit is tracked with the following qualities:
* Bit number (counting from bit 0 as the most significant bit) * Bit number (counting from bit 0 as the most significant bit)
* Capability description * Capability description
* Reference * Reference
The registration procedure is Standards Action [RFC8126]. The The registration procedure is Standards Action [RFC8126]. The
initial allocation is as indicated in Table 27: initial allocation is as indicated in Table 27:
+============+========================================+===========+ +============+========================================+===========+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+============+========================================+===========+ +============+========================================+===========+
| 0 | PDR-ACK request (K) | RFC 9914 | | 0 | PDAOAck request (K) | RFC 9914 |
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
| 1 | Requested path should be redundant (R) | RFC 9914 | | 1 | Requested path should be redundant (R) | RFC 9914 |
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
| 2..255 | Unassigned | | | 2..255 | Unassigned | |
+------------+----------------------------------------+-----------+ +------------+----------------------------------------+-----------+
Table 27: Initial PDR Flags Table 27: Initial PDAOReq Flags
11.8. Registry for PDR-ACK Flags 11.8. Registry for PDAOAck Flags
IANA has created the "PDR-ACK Flags" registry under the "Routing IANA has created the "PDAOAck Flags" registry under the "Routing
Protocol for Low Power and Lossy Networks (RPL)" registry group Protocol for Low Power and Lossy Networks (RPL)" registry group
[IANA-RPL]. The bits are indexed from 0 (leftmost) to 7. Each bit [IANA-RPL]. The bits are indexed from 0 (leftmost) to 7. Each bit
is tracked with the following qualities: is tracked with the following qualities:
* Bit number (counting from bit 0 as the most significant bit) * Bit number (counting from bit 0 as the most significant bit)
* Capability description * Capability description
* Reference * Reference
The registration procedure is Standards Action [RFC8126]. At the The registration procedure is Standards Action [RFC8126]. At the
time of publication of this document, no bit has been assigned in time of publication of this document, no bit has been assigned in
this registry. this registry.
11.9. Registry for PDR-ACK Acceptance Status Values 11.9. Registry for PDAOAck Acceptance Status Values
IANA has created the "PDR-ACK Acceptance Status Values" registry IANA has created the "PDAOAck Acceptance Status Values" registry
under the "Routing Protocol for Low Power and Lossy Networks (RPL)" under the "Routing Protocol for Low Power and Lossy Networks (RPL)"
registry group [IANA-RPL]. Each value is tracked with the following registry group [IANA-RPL]. Each value is tracked with the following
qualities: qualities:
* Value * Value
* Meaning * Meaning
* Reference * Reference
skipping to change at line 3832 skipping to change at line 3832
The initial allocation is as indicated in Table 28: The initial allocation is as indicated in Table 28:
+=======+========================+===========+ +=======+========================+===========+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+========================+===========+ +=======+========================+===========+
| 0 | Unqualified Acceptance | RFC 9914 | | 0 | Unqualified Acceptance | RFC 9914 |
+-------+------------------------+-----------+ +-------+------------------------+-----------+
| 1..63 | Unassigned | | | 1..63 | Unassigned | |
+-------+------------------------+-----------+ +-------+------------------------+-----------+
Table 28: Acceptance Values of the PDR-ACK Table 28: Acceptance Values of the PDAOAck
Status Status
11.10. Registry for PDR-ACK Rejection Status Values 11.10. Registry for PDAOAck Rejection Status Values
IANA has created the "PDR-ACK Rejection Status Values" registry under IANA has created the "PDAOAck Rejection Status Values" registry under
the "Routing Protocol for Low Power and Lossy Networks (RPL)" the "Routing Protocol for Low Power and Lossy Networks (RPL)"
registry group [IANA-RPL]. Each value is tracked with the following registry group [IANA-RPL]. Each value is tracked with the following
qualities: qualities:
* Value * Value
* Meaning * Meaning
* Reference * Reference
skipping to change at line 3862 skipping to change at line 3862
+=======+=======================+===========+ +=======+=======================+===========+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+=======================+===========+ +=======+=======================+===========+
| 0 | Unqualified Rejection | RFC 9914 | | 0 | Unqualified Rejection | RFC 9914 |
+-------+-----------------------+-----------+ +-------+-----------------------+-----------+
| 1 | Transient Failure | RFC 9914 | | 1 | Transient Failure | RFC 9914 |
+-------+-----------------------+-----------+ +-------+-----------------------+-----------+
| 2..63 | Unassigned | | | 2..63 | Unassigned | |
+-------+-----------------------+-----------+ +-------+-----------------------+-----------+
Table 29: PDR-ACK Rejection Status Values Table 29: PDAOAck Rejection Status Values
11.11. Registry for Via Information Options Flags 11.11. Registry for Via Information Options Flags
IANA has created the "Via Information Options (VIO) Flags" registry IANA has created the "Via Information Options (VIO) Flags" registry
under the "Routing Protocol for Low Power and Lossy Networks (RPL)" under the "Routing Protocol for Low Power and Lossy Networks (RPL)"
registry group [IANA-RPL]. The bits are indexed from 0 (leftmost) to registry group [IANA-RPL]. The bits are indexed from 0 (leftmost) to
7. Each bit is tracked with the following qualities: 7. Each bit is tracked with the following qualities:
* Bit number (counting from bit 0 as the most significant bit) * Bit number (counting from bit 0 as the most significant bit)
 End of changes. 64 change blocks. 
133 lines changed or deleted 133 lines changed or added

This html diff was produced by rfcdiff 1.48.