rfc9914v4.txt   rfc9914.txt 
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 PDAORAck Control Message 5.2. New PDR-ACK 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 PDAOAck Flags 11.8. Registry for PDR-ACK Flags
11.9. Registry for PDAOAck Acceptance Status Values 11.9. Registry for PDR-ACK Acceptance Status Values
11.10. Registry for PDAOAck Rejection Status Values 11.10. Registry for PDR-ACK 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 311 skipping to change at line 311
NSM-VIO: Non-Storing Mode Via Information Option. Source-routed NSM-VIO: Non-Storing Mode Via Information Option. Source-routed
VIO used in Non-Storing Mode P-DAO messages. 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
PCE: Path Computation Element PCE: Path Computation Element
PDAOAck: P-DAO Acknowledgment
PDAORAck: P-DAO Request Acknowledgment
PDAOReq: P-DAO Request PDAOReq: P-DAO Request
PLR: Point of Local Repair 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) RAN: RPL-Aware Node (either a RPL router or a RPL-Aware Leaf)
RH: Routing Header RH: Routing Header
skipping to change at line 1900 skipping to change at line 1896
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 (PDAOReq) is a new message detailed in Section 5.1. The P-DAO Request (PDAOReq) is a new message detailed in Section 5.1.
As per Section 6 of [RPL], if a node receives this message and it As per Section 6 of [RPL], if a node receives this message and it
does not understand this new code, it discards the message. When the does not understand this new code, it discards the message. When the
Root initiates communication to a node that it has not communicated Root initiates communication to a node that it has not communicated
with 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 P-DAO Acknowledgement (PDAOAck). request a P-DAO Request Acknowledgement (PDR-ACK).
A PDAOReq message enables a Track ingress to request the Track from A PDAOReq message enables a Track ingress to request the Track from
the 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.
skipping to change at line 2098 skipping to change at line 2094
| (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 PDAOReq The set of RPL Control Messages is Extended to include the PDAOReq
and PDAOAck. These two new RPL Control Messages enable a RAN to and PDR-ACK. These two new RPL Control Messages enable a RAN to
request the establishment of a Track between itself (as the Track request the establishment of a Track between itself (as the Track
ingress Node) and a Track egress. The node makes its request by ingress Node) and a Track egress. The node makes its request by
sending a new PDAOReq message to the Root. The Root confirms with a sending a new PDAOReq message to the Root. The Root confirms with a
new PDAOAck message back to the requester RAN; see Section 5.1 for new PDR-ACK message back to the requester RAN; see Section 5.1 for
more. 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 2281 skipping to change at line 2277
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 PDAOReq message is sent by a node in the main DODAG to the Root. The PDAOReq message is sent by a node in the main DODAG to the Root.
It is a request to establish or refresh a Track where the node It is a request to establish or refresh a Track where the node
sending the PDAOReq is the Track ingress, and it signals whether or sending the PDAOReq is the Track ingress, and it signals whether or
not an acknowledgment called PDAOAck is requested. A positive not an acknowledgment called PDR-ACK is requested. A positive PDR-
PDAOAck indicates that the Track was built and that the Root commits ACK indicates that the Track was built and that the Root commits to
to maintaining the Track for the negotiated lifetime. 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
PDAOAck with a negative status. A status of "Transient Failure" (see PDR-ACK with a negative status. A status of "Transient Failure" (see
Section 11.10) is an indication that the PDAOReq may be retried after Section 11.10) is an indication that the PDAOReq may be retried after
a 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 PDAOReq, and the TrackID is indicated in source IPv6 address of the PDAOReq, and the TrackID is indicated in
the message itself. At least one RPL Target Option MUST be present the message itself. At least one RPL Target Option MUST be present
in the message. If more than one RPL Target Option is present, the in the message. If more than one RPL Target Option is present, the
skipping to change at line 2322 skipping to change at line 2318
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
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 PDAOAck back. send a PDR-ACK 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 PDAOReq with a fresher PDAOReqSequence refreshes the lifetime, A PDAOReq with a fresher PDAOReqSequence refreshes the lifetime,
and a ReqLifetime of 0 indicates that the Track MUST be destroyed, and a ReqLifetime of 0 indicates that the Track MUST be destroyed,
e.g., when the application that requested the Track terminates. e.g., when the application that requested the Track terminates.
PDAOReqSequence: 8-bit wrapping sequence number, obeying the PDAOReqSequence: 8-bit wrapping sequence number, obeying the
operation in Section 7.2 of [RPL]. The PDAOReqSequence is used to operation in Section 7.2 of [RPL]. The PDAOReqSequence is used to
correlate a PDAOAck message with the PDAOReq message that correlate a PDR-ACK message with the PDAOReq message that
triggered it. It is incremented at each PDAOReq message and triggered it. It is incremented at each PDAOReq message and
echoed in the PDAOAck by the Root. echoed in the PDR-ACK by the Root.
5.2. New PDAORAck Control Message 5.2. New PDR-ACK Control Message
The new P-DAO Request Acknowledgment (PDAORAck) is sent as a response The new PDR-ACK is sent as a response to a PDAOReq message with the
to a PDAOReq message with the 'K' flag set. The RPL Control Code for 'K' flag set. The RPL Control Code for the PDR-ACK is 0x0A. Its
the PDAORAck is 0x0A. Its format 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|PDAOReqSequence| | TrackID | Flags | Track Lifetime|PDAOReqSequence|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDAORAck Status| Reserved | | PDR-ACK Status| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+
Figure 14: New PDAORAck Control Message Format Figure 14: New PDR-ACK 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
PDAOReq 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.
PDAOReqSequence: 8-bit wrapping sequence number. It is incremented PDAOReqSequence: 8-bit wrapping sequence number. It is incremented
at each PDAOReq message and echoed in the PDAORAck. at each PDAOReq message and echoed in the PDR-ACK.
PDAOAck Status: 8-bit field indicating the completion. The PDAOAck PDR-ACK Status: 8-bit field indicating the completion. The PDR-ACK
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: PDAORAck Status Format Figure 15: PDR-ACK 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 2667 skipping to change at line 2663
This specification introduces the PDAOReq message, which is used by This specification introduces the PDAOReq message, which is used by
an 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 PDAOReq, there owned by the ingress node, and in the absence of a PDAOReq, there
must be some procedure for the Root to assign TrackIDs in that must be some procedure for the Root to assign TrackIDs in that
namespace while avoiding collisions (see more in Section 6.3). namespace while avoiding collisions (see more in Section 6.3).
The PDAOReq signals the desired TrackID and the duration for which The PDAOReq signals the desired TrackID and the duration for which
the Track should be established. Upon a PDAOReq, the Root MAY the Track should be established. Upon a PDAOReq, the Root MAY
install the Track as requested, in which case it answers with a install the Track as requested, in which case it answers with a PDR-
PDAOAck indicating the granted Track Lifetime. All the segments MUST ACK indicating the granted Track Lifetime. All the segments MUST be
be of the same mode, either Storing or Non-Storing. All the segments of the same mode, either Storing or Non-Storing. All the segments
MUST be created with the same TrackID and the same DODAGID signaled MUST be created with the same TrackID and the same DODAGID signaled
in the 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 PDAOReq or between P-DAO messages for Requested Lifetime in the PDAOReq or between P-DAO messages for
different segments. For example, the Root may use shorter lifetimes different segments. For example, the Root may use shorter lifetimes
for the segments and renew them or change them during the lifetime of for the segments and renew them or change them during the lifetime of
the Track. All the components (protection paths and segments) of a the Track. All the components (protection paths and segments) of a
Track MUST be destroyed (or have their lifetime elapsed) before the Track MUST be destroyed (or have their lifetime elapsed) before the
TrackID 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 PDAOReq using the TrackID in the requesting node SHOULD resend a PDAOReq using the TrackID in the PDR-
PDAOAck to extend the lifetime of the Track; otherwise, the Track ACK to extend the lifetime of the Track; otherwise, the Track will
will time out, and the Root will tear down the whole structure. 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 PDAOAck with a Track Lifetime requesting node asynchronously with a PDR-ACK with a Track Lifetime
of 0, indicating that the Track has failed, and a PDAOAck Status, of 0, indicating that the Track has failed, and a PDR-ACK 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 3739 skipping to change at line 3735
+------------+----------------------+-----------+ +------------+----------------------+-----------+
Table 24: Initial PDAOReq 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 (PDAOReq) | RFC 9914 | | 0x09 | Projected DAO Request (PDAOReq) | RFC 9914 |
+------+------------------------------------------+-----------+ +------+---------------------------------+-----------+
| 0x0A | P-DAO Request Acknowledgement (PDAORAck) | RFC 9914 | | 0x0A | PDR-ACK | 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:
+=======+==============================================+===========+ +=======+==============================================+===========+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+==============================================+===========+ +=======+==============================================+===========+
skipping to change at line 3786 skipping to change at line 3782
* 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 | PDAOAck request (K) | RFC 9914 | | 0 | PDR-ACK requested (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 PDAOReq Flags Table 27: Initial PDAOReq Flags
11.8. Registry for PDAOAck Flags 11.8. Registry for PDR-ACK Flags
IANA has created the "PDAOAck Flags" registry under the "Routing IANA has created the "PDR-ACK 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 PDAOAck Acceptance Status Values 11.9. Registry for PDR-ACK Acceptance Status Values
IANA has created the "PDAOAck Acceptance Status Values" registry IANA has created the "PDR-ACK 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 3837 skipping to change at line 3833
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 PDAOAck Table 28: Acceptance Values of the PDR-ACK
Status Status
11.10. Registry for PDAOAck Rejection Status Values 11.10. Registry for PDR-ACK Rejection Status Values
IANA has created the "PDAOAck Rejection Status Values" registry under IANA has created the "PDR-ACK 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 3867 skipping to change at line 3863
+=======+=======================+===========+ +=======+=======================+===========+
| 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: PDAOAck Rejection Status Values Table 29: PDR-ACK 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. 32 change blocks. 
52 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.48.