draft-ietf-roll-unaware-leaves-17.txt   draft-ietf-roll-unaware-leaves-18.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: draft-ietf-roll-efficient-npdao, 6550, M. Richardson Updates: draft-ietf-roll-efficient-npdao, 6550, M. Richardson
8505 (if approved) Sandelman 8505 (if approved) Sandelman
Intended status: Standards Track 10 June 2020 Intended status: Standards Track 12 June 2020
Expires: 12 December 2020 Expires: 14 December 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-17 draft-ietf-roll-unaware-leaves-18
Abstract Abstract
This specification extends RFC6550 and RFC8505 to provide routing This specification extends RFC6550 and RFC8505 to provide routing
services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND
but do not participate to RPL. This specification also enables the but do not participate to RPL. This specification also enables the
RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG. RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 December 2020. This Internet-Draft will expire on 14 December 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 41 skipping to change at page 2, line 41
10. Protocol Operations for Unicast Addresses . . . . . . . . . . 15 10. Protocol Operations for Unicast Addresses . . . . . . . . . . 15
10.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 16 10.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 16
10.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 18 10.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 18
10.2.1. Perspective of the RUL Acting as 6LN . . . . . . . . 18 10.2.1. Perspective of the RUL Acting as 6LN . . . . . . . . 18
10.2.2. Perspective of the Border Router Acting as 6LR . . . 19 10.2.2. Perspective of the Border Router Acting as 6LR . . . 19
10.2.3. Perspective of the RPL Root . . . . . . . . . . . . 22 10.2.3. Perspective of the RPL Root . . . . . . . . . . . . 22
10.2.4. Perspective of the 6LBR . . . . . . . . . . . . . . 22 10.2.4. Perspective of the 6LBR . . . . . . . . . . . . . . 22
11. Protocol Operations for Multicast Addresses . . . . . . . . . 23 11. Protocol Operations for Multicast Addresses . . . . . . . . . 23
12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
13.1. Resizing the ARO Status values . . . . . . . . . . . . . 25 13.1. Fixing the Address Registration Option Flags . . . . . . 25
13.2. New DODAG Configuration Option Flag . . . . . . . . . . 25 13.2. Resizing the ARO Status values . . . . . . . . . . . . . 25
13.3. New RPL Target Option Flag . . . . . . . . . . . . . . . 26 14. New DODAG Configuration Option Flag . . . . . . . . . . . . . 26
13.4. New Subregistry for the RPL Non-Rejection Status 15. New RPL Target Option Flag . . . . . . . . . . . . . . . . . 26
values . . . . . . . . . . . . . . . . . . . . . . . . . 26 16. New Subregistry for the RPL Non-Rejection Status values . . . 26
13.5. New Subregistry for the RPL Rejection Status values . . 26 17. New Subregistry for the RPL Rejection Status values . . . . . 27
13.6. Fixing the Address Registration Option Flags . . . . . . 27 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 19. Normative References . . . . . . . . . . . . . . . . . . . . 27
15. Normative References . . . . . . . . . . . . . . . . . . . . 27 20. Informative References . . . . . . . . . . . . . . . . . . . 29
16. Informative References . . . . . . . . . . . . . . . . . . . 29 Appendix A. Example Compression . . . . . . . . . . . . . . . . 31
Appendix A. Example Compression . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
The design of Low Power and Lossy Networks (LLNs) is generally The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, which is the most constrained resource of focused on saving energy, which is the most constrained resource of
all. Other design constraints, such as a limited memory capacity, all. Other design constraints, such as a limited memory capacity,
duty cycling of the LLN devices and low-power lossy transmissions, duty cycling of the LLN devices and low-power lossy transmissions,
derive from that primary concern. derive from that primary concern.
The IETF produced the "Routing Protocol for Low Power and Lossy The IETF produced the "Routing Protocol for Low Power and Lossy
skipping to change at page 3, line 31 skipping to change at page 3, line 31
allows a routing stretch (see [RFC6687]), whereby routing is only allows a routing stretch (see [RFC6687]), whereby routing is only
performed along an acyclic graph optimized to reach a Root node, as performed along an acyclic graph optimized to reach a Root node, as
opposed to straight along a shortest path between 2 peers, whatever opposed to straight along a shortest path between 2 peers, whatever
that would mean in a given LLN. This trades the quality of peer-to- that would mean in a given LLN. This trades the quality of peer-to-
peer (P2P) paths for a vastly reduced amount of control traffic and peer (P2P) paths for a vastly reduced amount of control traffic and
routing state that would be required to operate a any-to-any shortest routing state that would be required to operate a any-to-any shortest
path protocol. Finally, broken routes may be fixed lazily and on- path protocol. Finally, broken routes may be fixed lazily and on-
demand, based on dataplane inconsistency discovery, which avoids demand, based on dataplane inconsistency discovery, which avoids
wasting energy in the proactive repair of unused paths. wasting energy in the proactive repair of unused paths.
To provide alternate paths in lossy networks, RPL forms Direction- To provide alternate paths in lossy networks, RPL forms Destination-
Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information
Sollicitation (DIS) and DODAG Information Object (DIO) messages. For solicitation (DIS) and DODAG Information Object (DIO) messages. For
many of the nodes, though not all, a DODAG provides multiple many of the nodes, though not all, a DODAG provides multiple
forwarding solutions towards the Root of the topology via so-called forwarding solutions towards the Root of the topology via so-called
parents. RPL is designed to adapt to fuzzy connectivity, whereby the parents. RPL is designed to adapt to fuzzy connectivity, whereby the
physical topology cannot be expected to reach a stable state, with a physical topology cannot be expected to reach a stable state, with a
lazy control that creates the routes proactively, but may only fix lazy control that creates the routes proactively, but may only fix
them reactively, upon actual traffic. The result is that RPL them reactively, upon actual traffic. The result is that RPL
provides reachability for most of the LLN nodes, most of the time, provides reachability for most of the LLN nodes, most of the time,
but may not converge in the classical sense. but may not converge in the classical sense.
[RFC6550] provides unicast and multicast routing services to RPL- [RFC6550] provides unicast and multicast routing services to RPL-
Aware nodes (RANs), either as a collection tree or with routing back. Aware nodes (RANs), either as a collection tree for outwards traffic
In the latter case, an RAN injects routes to itself using Destination only, or with routing back to the devices as well. In the latter
Advertisement Object (DAO) messages sent either to parent-nodes, in case, a RAN injects routes to itself using Destination Advertisement
the RPL Storing Mode, or to the Root indicating their parent, in the Object (DAO) messages sent either to parent-nodes, in the RPL Storing
Non-Storing Mode. This process effectively forms a DODAG back to the Mode, or to the Root indicating their parent, in the Non-Storing
device that is a subset of the DODAG to the Root with all links Mode. This process effectively forms a DODAG back to the device that
reversed. is a subset of the DODAG to the Root with all links reversed.
RPL can be deployed as an extension to IPv6 Neighbor Discovery (ND) RPL can be deployed as an extension to IPv6 Neighbor Discovery (ND)
[RFC4861][RFC4862] and 6LoWPAN ND [RFC6775][RFC8505] to maintain [RFC4861][RFC4862] and 6LoWPAN ND [RFC6775][RFC8505] to maintain
reachability within a Non-Broadcast Multi-Access (NBMA) subnet. In reachability within a Non-Broadcast Multi-Access (NBMA) subnet. In
that mode, some nodes may act as Routers and participate to the that mode, some nodes may act as Routers and participate to the
forwarding operations whereas others will only terminate packets, forwarding operations whereas others will only terminate packets,
acting as Hosts in the data-plane. In [RFC6550] terms, a Host that acting as Hosts in the data-plane. In [RFC6550] terms, a Host that
is reachable over the RPL network is called a Leaf. is reachable over the RPL network is called a Leaf.
"When to use RFC 6553, 6554 and IPv6-in-IPv6" [USEofRPLinfo] "When to use RFC 6553, 6554 and IPv6-in-IPv6" [USEofRPLinfo]
skipping to change at page 5, line 19 skipping to change at page 5, line 19
and Lossy Networks (LLNs)" [RFC7102]. A glossary of classical and Lossy Networks (LLNs)" [RFC7102]. A glossary of classical
6LoWPAN acronyms is given in Section 2.3. Other terms in use in LLNs 6LoWPAN acronyms is given in Section 2.3. Other terms in use in LLNs
are found in "Terminology for Constrained-Node Networks" [RFC7228]. are found in "Terminology for Constrained-Node Networks" [RFC7228].
"RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by
a RPLInstanceID) are defined in "RPL: IPv6 Routing Protocol for a RPLInstanceID) are defined in "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks" [RFC6550]. The RPI is the abstract Low-Power and Lossy Networks" [RFC6550]. The RPI is the abstract
information that RPL defines to be placed in data packets, e.g., as information that RPL defines to be placed in data packets, e.g., as
the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header. By the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header. By
extension the term "RPI" is often used to refer to the RPL Option extension the term "RPI" is often used to refer to the RPL Option
itself. The DODAG Information Sollicitation (DIS), Destination itself. The DODAG Information solicitation (DIS), Destination
Advertisement Object (DAO) and DODAG Information Object (DIO) Advertisement Object (DAO) and DODAG Information Object (DIO)
messages are also specified in [RFC6550]. The Destination Cleanup messages are also specified in [RFC6550]. The Destination Cleanup
Object (DCO) message is defined in [EFFICIENT-NPDAO]. Object (DCO) message is defined in [EFFICIENT-NPDAO].
This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware
Leaf (RAL) consistently with [USEofRPLinfo]. The term RPL-Aware Node Leaf (RAL) consistently with [USEofRPLinfo]. The term RPL-Aware Node
(RAN) is introduced to refer to a node that is either an RAL or a RPL (RAN) is introduced to refer to a node that is either an RAL or a RPL
Router. As opposed to a RUL, an RAN manages the reachability of its Router. As opposed to a RUL, a RAN manages the reachability of its
addresses and prefixes by injecting them in RPL by itself. addresses and prefixes by injecting them in RPL by itself.
In this document, readers will encounter terms and concepts that are In this document, readers will encounter terms and concepts that are
discussed in the following documents: discussed in the following documents:
Classical IPv6 ND: "Neighbor Discovery for IP version 6" [RFC4861] Classical IPv6 ND: "Neighbor Discovery for IP version 6" [RFC4861]
and "IPv6 Stateless Address Autoconfiguration" [RFC4862], and "IPv6 Stateless Address Autoconfiguration" [RFC4862],
6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power 6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606] and Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606] and
skipping to change at page 6, line 22 skipping to change at page 6, line 22
(E)DAR: (Extended) Duplicate Address Request (E)DAR: (Extended) Duplicate Address Request
(E)DAC: (Extended) Duplicate Address Confirmation (E)DAC: (Extended) Duplicate Address Confirmation
DAD: Duplicate Address Detection DAD: Duplicate Address Detection
DAO: Destination Advertisement Object (a RPL message) DAO: Destination Advertisement Object (a RPL message)
DCO: Destination Cleanup Object (a RPL message) DCO: Destination Cleanup Object (a RPL message)
DIS: DODAG Information Sollicitation (a RPL message) DIS: DODAG Information solicitation (a RPL message)
DIO: DODAG Information Object (a RPL message) DIO: DODAG Information Object (a RPL message)
DODAG: Destination-Oriented Directed Acyclic Graph DODAG: Destination-Oriented Directed Acyclic Graph
LLN: Low-Power and Lossy Network LLN: Low-Power and Lossy Network
NA: Neighbor Advertisement NA: Neighbor Advertisement
NCE: Neighbor Cache Entry NCE: Neighbor Cache Entry
ND: Neighbor Discovery ND: Neighbor Discovery
NS: Neighbor Sollicitation NS: Neighbor solicitation
RA: Router Advertisement RA: Router Advertisement
ROVR: Registration Ownership Verifier ROVR: Registration Ownership Verifier
RPI: RPL Packet Information RPI: RPL Packet Information
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)
RUL: RPL-Unaware Leaf RUL: RPL-Unaware Leaf
TID: Transaction ID (a sequence counter in the EARO) TID: Transaction ID (a sequence counter in the EARO)
3. 6LoWPAN Neighbor Discovery 3. 6LoWPAN Neighbor Discovery
3.1. RFC 6775 Address Registration 3.1. RFC 6775 Address Registration
The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861] The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861]
[RFC4862] was defined for serial links and transit media such a [RFC4862] was defined for serial links and transit media such as
Ethernet. It is a reactive protocol that relies heavily on multicast Ethernet. It is a reactive protocol that relies heavily on multicast
operations for address discovery (aka lookup) and duplicate address operations for address discovery (aka lookup) and duplicate address
detection (DAD). detection (DAD).
"Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775]
adapts IPv6 ND for operations over energy-constrained LLNs. The main adapts IPv6 ND for operations over energy-constrained LLNs. The main
functions of [RFC6775] are to proactively establish the Neighbor functions of [RFC6775] are to proactively establish the Neighbor
Cache Entry (NCE) in the 6LR and to prevent address duplication. To Cache Entry (NCE) in the 6LR and to prevent address duplication. To
that effect, [RFC6775] introduces a new unicast Address Registration that effect, [RFC6775] introduces a new unicast Address Registration
mechanism that contributes to reducing the use of multicast messages mechanism that contributes to reducing the use of multicast messages
compared to the classical IPv6 ND protocol. compared to the classical IPv6 ND protocol.
[RFC6775] defines a new Address Registration Option (ARO) that is [RFC6775] defines a new Address Registration Option (ARO) that is
carried in the unicast Neighbor Sollicitation (NS) and Neighbor carried in the unicast Neighbor solicitation (NS) and Neighbor
Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the
6LoWPAN Router (6LR). It also defines the Duplicate Address Request 6LoWPAN Router (6LR). It also defines the Duplicate Address Request
(DAR) and Duplicate Address Confirmation (DAC) messages between the (DAR) and Duplicate Address Confirmation (DAC) messages between the
6LR and the 6LoWPAN Border Router (6LBR). In an LLN, the 6LBR is the 6LR and the 6LoWPAN Border Router (6LBR). In an LLN, the 6LBR is the
central repository of all the Registered Addresses in its domain and central repository of all the Registered Addresses in its domain and
the source of truth for uniqueness and ownership. the source of truth for uniqueness and ownership.
3.2. RFC 8505 Extended Address Registration 3.2. RFC 8505 Extended Address Registration
"Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505]
skipping to change at page 8, line 24 skipping to change at page 8, line 24
This document specifies how the "R" flag is used in the context of This document specifies how the "R" flag is used in the context of
RPL. A 6LN is a RUL that requires reachability services for an IPv6 RPL. A 6LN is a RUL that requires reachability services for an IPv6
address if and only if it sets the "R" flag in the NS(EARO) used to address if and only if it sets the "R" flag in the NS(EARO) used to
register the address to a RPL border router acting as 6LR. Upon register the address to a RPL border router acting as 6LR. Upon
receiving the NS(EARO), the RPL router generates a DAO message for receiving the NS(EARO), the RPL router generates a DAO message for
the Registered Address if and only if the "R" flag is set. the Registered Address if and only if the "R" flag is set.
3.2.2. TID, I Field and Opaque Fields 3.2.2. TID, I Field and Opaque Fields
The EARO also includes a sequence counter called Transaction ID When the "T" flag is set, the EARO includes a sequence counter called
(TID), which maps to the Path Sequence Field found in Transit Options Transaction ID (TID), which maps to the Path Sequence Field found in
in RPL DAO messages. This is the reason why the support of [RFC8505] the RPL Transit Option. This is the reason why the support of
by the RUL as opposed to only [RFC6775] is a prerequisite for this [RFC8505] by the RUL as opposed to only [RFC6775] is a prerequisite
specification (more in Section 7.1). The EARO also transports an for this specification (more in Section 7.1). The EARO also
Opaque field and an associated "I" field that describes what the transports an Opaque field and an associated "I" field that describes
Opaque field transports and how to use it. Section 10.2.1 specifies what the Opaque field transports and how to use it. Section 10.2.1
the use of the "I" field and of the Opaque field by a RUL. specifies the use of the "I" field and of the Opaque field by a RUL.
3.2.3. ROVR 3.2.3. ROVR
Section 5.3 of [RFC8505] introduces the Registration Ownership Section 5.3 of [RFC8505] introduces the Registration Ownership
Verifier (ROVR) field of variable length from 64 to 256 bits. The Verifier (ROVR) field of variable length from 64 to 256 bits. The
ROVR is a replacement of the EUI-64 in the ARO [RFC6775] that was ROVR is a replacement of the EUI-64 in the ARO [RFC6775] that was
used to identify uniquely an Address Registration with the Link-Layer used to identify uniquely an Address Registration with the Link-Layer
address of the owner but provided no protection against spoofing. address of the owner but provided no protection against spoofing.
"Address Protected Neighbor Discovery for Low-power and Lossy "Address Protected Neighbor Discovery for Low-power and Lossy
skipping to change at page 10, line 32 skipping to change at page 10, line 32
single keep-alive message, the RPL DAO, traverses the RPL network. A single keep-alive message, the RPL DAO, traverses the RPL network. A
new behavior is introduced whereby the RPL Root proxies the EDAR new behavior is introduced whereby the RPL Root proxies the EDAR
message to the 6LBR on behalf of the 6LR (more in Section 6), for any message to the 6LBR on behalf of the 6LR (more in Section 6), for any
6LN, RUL or RAN. 6LN, RUL or RAN.
Section 6.7.7 of [RFC6550] introduces RPL Target Option, which can be Section 6.7.7 of [RFC6550] introduces RPL Target Option, which can be
used in RPL Control messages such as the DAO message to signal a used in RPL Control messages such as the DAO message to signal a
destination prefix. Section 9 adds the capabilities to transport the destination prefix. Section 9 adds the capabilities to transport the
ROVR field (see Section 3.2.3) and the IPv6 Address of the prefix ROVR field (see Section 3.2.3) and the IPv6 Address of the prefix
advertiser when the Target is a shorter prefix, signaled by a new "F" advertiser when the Target is a shorter prefix, signaled by a new "F"
flag. The position of the "F" flag is indicated in Section 13.3. flag. The position of the "F" flag is indicated in Section 15.
Section 6.7.6 of [RFC6550] defines the DODAG Configuration option Section 6.7.6 of [RFC6550] defines the DODAG Configuration option
with reserved flags. This specification defines the new "Root with reserved flags. This specification defines the new "Root
Proxies EDAR/EDAC" (P) flag and encodes it in one of these reserved Proxies EDAR/EDAC" (P) flag and encodes it in one of these reserved
flags. The "P" flag is set to indicate that the Root performs the flags. The "P" flag is set to indicate that the Root performs the
proxy operation, which implies that it supports the Updated RPL proxy operation, which implies that it supports the Updated RPL
Target Option (see Section 9). The position of the "P" flag is Target Option (see Section 9). The position of the "P" flag is
indicated in Section 13.2. indicated in Section 14.
Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in
the DIO Base Object. The new "P" flag is defined only for MOP value the DIO Base Object. The new "P" flag is defined only for MOP value
between 0 to 6. For a MOP value of 7 or above, the flag MAY be between 0 to 6. For a MOP value of 7 or above, the flag MAY be
redefined and MUST NOT be interpreted as "Root Proxies EDAR/EDAC" redefined and MUST NOT be interpreted as "Root Proxies EDAR/EDAC"
unless the specification of the MOP indicates to do so. unless the specification of the MOP indicates to do so.
The RPL Status defined in section 6.5.1 of [RFC6550] for use in the The RPL Status defined in section 6.5.1 of [RFC6550] for use in the
DAO-ACK message is extended to be placed in DCO messages DAO-ACK message is extended to be placed in DCO messages
[EFFICIENT-NPDAO] as well. Furthermore, this specification enables [EFFICIENT-NPDAO] as well. Furthermore, this specification enables
skipping to change at page 11, line 34 skipping to change at page 11, line 34
7. Requirements on the RPL-Unware Leaf 7. Requirements on the RPL-Unware Leaf
This document provides RPL routing for a RUL, that is a 6LN acting as This document provides RPL routing for a RUL, that is a 6LN acting as
an IPv6 Host and not aware of RPL. Still, a minimal RPL-independent an IPv6 Host and not aware of RPL. Still, a minimal RPL-independent
functionality is required from the RUL to obtain routing services. functionality is required from the RUL to obtain routing services.
7.1. Support of 6LoWPAN ND 7.1. Support of 6LoWPAN ND
In order to obtain routing services from a 6LR, a RUL MUST implement In order to obtain routing services from a 6LR, a RUL MUST implement
[RFC8505] and set the "R" flag in the EARO. The RUL SHOULD support [RFC8505] and set the "R" and "T" flags in the EARO. The RUL SHOULD
[AP-ND] to protect the ownership of its addresses. The RUL MUST NOT support [AP-ND] to protect the ownership of its addresses. The RUL
request routing services from a 6LR that does not originate RA MUST NOT request routing services from a 6LR that does not originate
messages with a CIO that has the L, P, and E flags all set as RA messages with a CIO that has the L, P, and E flags all set as
discussed in Section 3.3.1, unless configured to do so. discussed in Section 3.3.1, unless configured to do so.
A RUL that may attach to multiple 6LRs MUST prefer those that provide A RUL that may attach to multiple 6LRs MUST prefer those that provide
routing services. The RUL MUST register to all the 6LRs from which routing services. The RUL MUST register to all the 6LRs from which
it desires routing services. it desires routing services.
Parallel Address Registrations to several 6LRs SHOULD be performed in Parallel Address Registrations to several 6LRs SHOULD be performed in
an rapid sequence, using the exact same EARO for the same Address. an rapid sequence, using the exact same EARO for the same Address.
Gaps between the Address Registrations will invalidate some of the Gaps between the Address Registrations will invalidate some of the
routes till the Address Registration finally shows on those routes. routes till the Address Registration finally shows on those routes.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
| 128-255 | Rejection | | 128-255 | Rejection |
+---------+--------------------------------+ +---------+--------------------------------+
Table 1: RPL Status per RFC 6550 Table 1: RPL Status per RFC 6550
The 6LoWPAN ND Status was defined for use in the EARO and the The 6LoWPAN ND Status was defined for use in the EARO and the
currently defined values are listed in table 1 of [RFC8505]. This currently defined values are listed in table 1 of [RFC8505]. This
specification enables to carry the 6LoWPAN ND Status values in RPL specification enables to carry the 6LoWPAN ND Status values in RPL
DAO and DCO messages, embedded in the RPL Status field. DAO and DCO messages, embedded in the RPL Status field.
To achieve this, Section 13.1 reduces the range of the EARO Status To achieve this, Section 13.2 reduces the range of the EARO Status
values to 0-63 to ensure that they fit within a RPL Status as shown values to 0-63 to ensure that they fit within a RPL Status as shown
in Figure 3. in Figure 3.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|A| Value | |E|A| Value |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: RPL Status Format Figure 3: RPL Status Format
skipping to change at page 14, line 51 skipping to change at page 14, line 51
ROVR that was also defined for 6LoWPAN ND messages. This enables the ROVR that was also defined for 6LoWPAN ND messages. This enables the
RPL Root to generate the proxied EDAR message to the 6LBR. RPL Root to generate the proxied EDAR message to the 6LBR.
The new "F" flag is set to indicate that the Target Prefix field The new "F" flag is set to indicate that the Target Prefix field
contains the address of the advertising node in full, in which case contains the address of the advertising node in full, in which case
the length of the Target Prefix field is 16 bytes regardless of the the length of the Target Prefix field is 16 bytes regardless of the
value of the Prefix Length field. value of the Prefix Length field.
If the "F" flag is reset, the Target Prefix field MUST be aligned to If the "F" flag is reset, the Target Prefix field MUST be aligned to
the next byte boundary after the size (expressed in bits) indicated the next byte boundary after the size (expressed in bits) indicated
by the Prefix Length field. Padding bits are reserved and set to 0 a by the Prefix Length field. Padding bits are reserved and set to 0
prescribed by section 6.7.7 of [RFC6550]. as prescribed by section 6.7.7 of [RFC6550].
With this specification the ROVR is the remainder of the RPL Target With this specification the ROVR is the remainder of the RPL Target
Option. The size of the ROVR is indicated in a new ROVR Size field Option. The size of the ROVR is indicated in a new ROVR Size field
that is encoded to map one-to-one with the Code Suffix in the EDAR that is encoded to map one-to-one with the Code Suffix in the EDAR
message (see table 4 of [RFC8505]). message (see table 4 of [RFC8505]).
The modified format is illustrated in Figure 4. It is backward The modified format is illustrated in Figure 4. It is backward
compatible with the Target Option in [RFC6550] and SHOULD be used as compatible with the Target Option in [RFC6550] and SHOULD be used as
a replacement in new implementations even for Storing Mode operations a replacement in new implementations even for Storing Mode operations
in preparation for upcoming security mechanisms based in the ROVR. in preparation for upcoming security mechanisms based in the ROVR.
skipping to change at page 18, line 40 skipping to change at page 18, line 40
This specification does not alter the operation of a 6LoWPAN ND- This specification does not alter the operation of a 6LoWPAN ND-
compliant 6LN, and a RUL is expected to operate as follows: compliant 6LN, and a RUL is expected to operate as follows:
1. The 6LN obtains an IPv6 global address, either using Stateless 1. The 6LN obtains an IPv6 global address, either using Stateless
Address Autoconfiguration (SLAAC) [RFC4862] based on a Prefix Address Autoconfiguration (SLAAC) [RFC4862] based on a Prefix
Information Option (PIO) [RFC4861] found in an RA message, or Information Option (PIO) [RFC4861] found in an RA message, or
some other means such as DHCPv6 [RFC3315]. some other means such as DHCPv6 [RFC3315].
2. Once it has formed an address, the 6LN (re)registers its address 2. Once it has formed an address, the 6LN (re)registers its address
periodically, within the Lifetime of the previous Address periodically, within the Lifetime of the previous Address
Registration, as prescribed by [RFC6775] and [RFC8505], to Registration, as prescribed by [RFC6775], to refresh the NCE
refresh the NCE before the lifetime indicated in the EARO before the lifetime indicated in the EARO expires. It MUST set
expires. The TID is incremented each time and wraps in a the "T" flag and the TID is incremented each time and wraps in a
lollipop fashion (see section 5.2.1 of [RFC8505] which is fully lollipop fashion (see section 5.2.1 of [RFC8505] which is fully
compatible with section 7.2 of [RFC6550]). compatible with section 7.2 of [RFC6550]).
3. As stated in section 5.2 of [RFC8505], the 6LN can register to 3. As stated in section 5.2 of [RFC8505], the 6LN can register to
more than one 6LR at the same time. In that case, it uses the more than one 6LR at the same time. In that case, it uses the
same EARO for all of the parallel Address Registrations. The 6LN same EARO for all of the parallel Address Registrations. The 6LN
SHOULD send the registration(s) that have a non-zero Registration SHOULD send the registration(s) that have a non-zero Registration
Lifetime and ensure that one succeeds before it terminates other Lifetime and ensure that one succeeds before it terminates other
registrations, to maintain the state in the network and at the registrations, to maintain the state in the network and at the
6LBR and minimize the churn. 6LBR and minimize the churn.
4. Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets 4. Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets
the "R" flag in the EARO of at least one registration, whereas the "R" flag in the EARO of at least one registration, whereas
acting as an RAN it never does. If the "R" flag is not echoed in acting as a RAN it never does. If the "R" flag is not echoed in
the NA, the RUL SHOULD attempt to use another 6LR. The RUL the NA, the RUL SHOULD attempt to use another 6LR. The RUL
SHOULD send the registration(s) with the "R" flag set and ensure SHOULD send the registration(s) with the "R" flag set and ensure
that one succeeds before it sends the registrations with the flag that one succeeds before it sends the registrations with the flag
reset. In case of a conflict with the preceeding rule on reset. In case of a conflict with the preceeding rule on
lifetime, the rule on lifetime has precedence. lifetime, the rule on lifetime has precedence.
5. The 6LN may use any of the 6LRs to which it registered as default 5. The 6LN may use any of the 6LRs to which it registered as default
gateway. Using a 6LR to which the 6LN is not registered may gateway. Using a 6LR to which the 6LN is not registered may
result in packets dropped at the 6LR by a Source Address result in packets dropped at the 6LR by a Source Address
Validation function (SAVI) so it is NOT RECOMMENDED. Validation function (SAVI) so it is NOT RECOMMENDED.
skipping to change at page 19, line 42 skipping to change at page 19, line 42
RPI in a data packet MUST indicate the RPLInstanceID of the RPL RPI in a data packet MUST indicate the RPLInstanceID of the RPL
Instance where the packet should be forwarded. All the flags and the Instance where the packet should be forwarded. All the flags and the
Rank field are set to zero as specified by section 11.2 of [RFC6550]. Rank field are set to zero as specified by section 11.2 of [RFC6550].
10.2.2. Perspective of the Border Router Acting as 6LR 10.2.2. Perspective of the Border Router Acting as 6LR
Also as prescribed by [RFC8505], the 6LR generates an EDAR message Also as prescribed by [RFC8505], the 6LR generates an EDAR message
upon reception of a valid NS(EARO) message for the registration of a upon reception of a valid NS(EARO) message for the registration of a
new IPv6 Address by a 6LN. If the initial EDAR/EDAC exchange new IPv6 Address by a 6LN. If the initial EDAR/EDAC exchange
succeeds, then the 6LR installs an NCE for the Registration Lifetime. succeeds, then the 6LR installs an NCE for the Registration Lifetime.
For the refreshes of the registration, if the RPL Root has indicated For the registration refreshes, if the RPL Root has indicated that it
that it proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see
Section 4), the 6LR MUST refrain from sending the keep-alive EDAR. Section 4), the 6LR MUST refrain from sending the keep-alive EDAR.
If the "R" flag is set in the NS(EARO), the 6LR SHOULD attempt to If the "R" flag is set in the NS(EARO), the 6LR MUST inject the Host
inject the host route in RPL, unless this is barred for other route in RPL, unless this is barred for other reasons, such as the
reasons, like a saturation of the network or if its RPL parent. The saturation of the RPL parents. The 6LR MUST use a RPL Non-Storing
6LR MUST use a RPL Non-Storing Mode signaling. The 6LR MUST request Mode signaling and the updated Target Option (see Section 9). The
a DAO-ACK by setting the 'K' flag in the DAO message. Success 6LR MUST request a DAO-ACK by setting the 'K' flag in the DAO
injecting the route to the RUL is indicated by the 'E' flag set to 0 message. Success injecting the route to the RUL is indicated by the
in the RPL status of the DAO-ACK message. 'E' flag set to 0 in the RPL status of the DAO-ACK message.
The Opaque field in the EARO hints the 6LR on the RPL Instance that The Opaque field in the EARO hints the 6LR on the RPL Instance that
SHOULD be used for the DAO advertisements, and for the forwarding of SHOULD be used for the DAO advertisements, and for the forwarding of
packets sourced at the registered address when there is no RPI in the packets sourced at the registered address when there is no RPI in the
packet, in which case the 6LR MUST encapsulate the packet to the Root packet, in which case the 6LR MUST encapsulate the packet to the Root
adding an RPI in the outer header. If the Opaque field is zero, the adding an RPI in the outer header. If the Opaque field is zero, the
6LR is free to use the default RPL Instance (zero) for the registered 6LR is free to use the default RPL Instance (zero) for the registered
address or to select an Instance of its choice. address or to select an Instance of its choice.
if the "I" field is not zero, then the 6LR MUST consider that the If the "I" field is not zero, then the 6LR MUST consider that the
Opaque field is zero. If the Opaque field is not zero, then it is Opaque field is zero. If the Opaque field is not zero, then it is
expected to carry a RPLInstanceID for the RPL Instance suggested by expected to carry a RPLInstanceID for the RPL Instance suggested by
the 6LN. If the 6LR does not participate to the associated Instance, the 6LN. If the 6LR does not participate to the associated Instance,
then the 6LR MUST consider that the Opaque field is zero; else, that then the 6LR MUST consider that the Opaque field is zero; else, that
is if the 6LR participates to the suggested RPL Instance, then the is if the 6LR participates to the suggested RPL Instance, then the
6LR SHOULD use that Instance for the Registered Address. 6LR SHOULD use that Instance for the Registered Address.
The DAO message advertising the Registered Address MUST be The DAO message advertising the Registered Address MUST be
constructed as follows: constructed as follows:
1. The Registered Address is signaled as Target Prefix in the RPL 1. The Registered Address is signaled as Target Prefix in the
Target Option in the DAO message; the Prefix Length is set to 128 updated Target Option in the DAO message; the Prefix Length is
set to 128. The ROVR field is copied unchanged from the EARO
(see Section 9).
2. The 6LR indicates one of its global or unique-local IPv6 unicast 2. The 6LR indicates one of its global or unique-local IPv6 unicast
addresses as the Parent Address in the RPL Transit Information addresses as the Parent Address in the RPL Transit Information
Option (TIO) associated with the Target Option Option (TIO) associated with the Target Option
3. The 6LR sets the External 'E' flag in the TIO to indicate that it 3. The 6LR sets the External 'E' flag in the TIO to indicate that it
redistributes an external target into the RPL network redistributes an external target into the RPL network
4. the Path Lifetime in the TIO is computed from the Lifetime in the 4. the Path Lifetime in the TIO is computed from the Lifetime in the
EARO Option. This adapts it to the Lifetime Units used in the EARO Option. This adapts it to the Lifetime Units used in the
skipping to change at page 21, line 46 skipping to change at page 21, line 46
and/or with the EARO Status 2 "Neighbor Cache full" to signal that it and/or with the EARO Status 2 "Neighbor Cache full" to signal that it
removes the NCE. It may also send a final RA, unicast or multicast, removes the NCE. It may also send a final RA, unicast or multicast,
with a Router Lifetime field of zero, to signal that it stops serving with a Router Lifetime field of zero, to signal that it stops serving
as router, as specified in section 6.2.5 of [RFC4861]. as router, as specified in section 6.2.5 of [RFC4861].
If a 6LR receives a valid NS(EARO) message with the "R" flag reset If a 6LR receives a valid NS(EARO) message with the "R" flag reset
and a Registration Lifetime that is not 0, and the 6LR was injecting and a Registration Lifetime that is not 0, and the 6LR was injecting
the Registered Address due to previous NS(EARO) messages with the "R" the Registered Address due to previous NS(EARO) messages with the "R"
flag set, then the 6LR MUST stop injecting the address. It is up to flag set, then the 6LR MUST stop injecting the address. It is up to
the Registering 6LN to maintain the corresponding route from then on, the Registering 6LN to maintain the corresponding route from then on,
either keeping it active via a different 6LR or by acting as an RAN either keeping it active via a different 6LR or by acting as a RAN
and managing its own reachability. and managing its own reachability.
10.2.3. Perspective of the RPL Root 10.2.3. Perspective of the RPL Root
A RPL Root SHOULD set the "P" flag in the RPL configuration option of A RPL Root SHOULD set the "P" flag in the RPL DODAG Configuration
the DIO messages that it generates (see Section 4) to signal that it Option of the DIO messages that it generates (see Section 4) to
proxies the EDAR/EDAC exchange and supports the Updated RPL Target signal that it proxies the EDAR/EDAC exchange and supports the
option. The remainder of this section assumes that it does. Updated RPL Target option. The remainder of this section assumes
that it does.
Upon reception of a DAO message, for each RPL Target Option that
creates or updates an existing RPL state, the Root MUST notify the
6LBR. This can be done using an internal API if they are integrated,
or using a proxied EDAR/EDAC exchange if they are separate entities.
Upon receiving an EDAC message from the 6LBR, if a DAO is pending,
then the Root MUST send a DAO-ACK back to the 6LR. Else, if the
Status in the EDAC message is not "Success", then it MUST send an
asynchronous DCO to the 6LR.
In either case, the EDAC Status is embedded in the RPL Status with Upon reception of a DAO message, for each updated RPL Target Option
the 'A' flag set. (see Section 9) that creates or updates an existing RPL state, the
Root MUST notify the 6LBR. This can be done using an internal API if
they are integrated, or using a proxied EDAR/EDAC exchange if they
are separate entities.
The EDAR message MUST be constructed as follows: The EDAR message MUST be constructed as follows:
1. The Target IPv6 address from the RPL Target Option is placed in 1. The Target IPv6 address from the RPL Target Option is placed in
the Registered Address field of the EDAR message; the Registered Address field of the EDAR message;
2. the Registration Lifetime is adapted from the Path Lifetime in 2. the Registration Lifetime is adapted from the Path Lifetime in
the TIO by converting the Lifetime Units used in RPL into units the TIO by converting the Lifetime Units used in RPL into units
of 60 seconds used in the 6LoWPAN ND messages; of 60 seconds used in the 6LoWPAN ND messages;
3. the TID value is set to the Path Sequence in the TIO and 3. the TID value is set to the Path Sequence in the TIO and
indicated with an ICMP code of 1 in the EDAR message; indicated with an ICMP code of 1 in the EDAR message;
4. The ROVR in the RPL Target Option is copied as is in the EDAR and 4. The ROVR in the RPL Target Option is copied as is in the EDAR and
the ICMP Code Suffix is set to the appropriate value as shown in the ICMP Code Suffix is set to the appropriate value as shown in
Table 4 of [RFC8505] depending on the size of the ROVR field. Table 4 of [RFC8505] depending on the size of the ROVR field.
Upon receiving an EDAC message from the 6LBR, if a DAO is pending,
then the Root MUST send a DAO-ACK back to the 6LR. Else, if the
Status in the EDAC message is not "Success", then it MUST send an
asynchronous DCO to the 6LR.
In either case, the EDAC Status is embedded in the RPL Status with
the 'A' flag set.
10.2.4. Perspective of the 6LBR 10.2.4. Perspective of the 6LBR
The 6LBR is unaware that the RPL Root is not the new attachment 6LR The 6LBR is unaware that the RPL Root is not the new attachment 6LR
of the RUL, so it is not impacted by this specification. of the RUL, so it is not impacted by this specification.
Upon reception of an EDAR message, the 6LBR acts as prescribed by Upon reception of an EDAR message, the 6LBR acts as prescribed by
[RFC8505] and returns an EDAC message to the sender. [RFC8505] and returns an EDAC message to the sender.
11. Protocol Operations for Multicast Addresses 11. Protocol Operations for Multicast Addresses
skipping to change at page 25, line 32 skipping to change at page 25, line 32
entitled to do so. entitled to do so.
At the time of this writing RPL does not have a zerotrust model At the time of this writing RPL does not have a zerotrust model
whereby it is possible to validate the origin of an address that is whereby it is possible to validate the origin of an address that is
injected in a DAO. This specification makes a first step in that injected in a DAO. This specification makes a first step in that
direction by allowing the Root to challenge the RUL via the 6LR that direction by allowing the Root to challenge the RUL via the 6LR that
serves it. serves it.
13. IANA Considerations 13. IANA Considerations
13.1. Resizing the ARO Status values 13.1. Fixing the Address Registration Option Flags
Section 9.1 of [RFC8505] creates a Registry for the 8-bit Address
Registration Option Flags field.
IANA is requested to rename the first column of the table from "ARO
Status" to "Bit number".
13.2. Resizing the ARO Status values
Section 12 of [RFC6775] creates the Address Registration Option Section 12 of [RFC6775] creates the Address Registration Option
Status Values Registry with a range 0-255. This specification Status Values Registry with a range 0-255.
reduces that range to 0-63.
IANA is requested to reduce the unassigned values range from 11-255 This specification reduces that range to 0-63.
to 11-63.
13.2. New DODAG Configuration Option Flag IANA is requested to reduce the upper bound of the unassigned values
in the Address Registration Option Status Values Registry from -255
to -63.
14. New DODAG Configuration Option Flag
This specification updates the Registry for the "DODAG Configuration This specification updates the Registry for the "DODAG Configuration
Option Flags" that was created for [RFC6550] as follows: Option Flags" that was created for [RFC6550] as follows:
+------------+----------------------------+-----------+ +------------+----------------------------+-----------+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+============+============================+===========+ +============+============================+===========+
| 1 | Root Proxies EDAR/EDAC (P) | THIS RFC | | 1 | Root Proxies EDAR/EDAC (P) | THIS RFC |
+------------+----------------------------+-----------+ +------------+----------------------------+-----------+
Table 2: New DODAG Configuration Option Flag Table 2: New DODAG Configuration Option Flag
13.3. New RPL Target Option Flag 15. New RPL Target Option Flag
Section 20.15 of [RFC6550] creates a Registry for the 8-bit "RPL Section 20.15 of [RFC6550] creates a Registry for the 8-bit "RPL
Target Option Flags" field. IANA is requested to reduce the size of Target Option Flags" field. IANA is requested to reduce the size of
the field in the Registry to 4 bits. This specification also defines the field in the Registry to 4 bits. This specification also defines
a new entry in the Registry as follows: a new entry in the Registry as follows:
+------------+--------------------------------+-----------+ +------------+--------------------------------+-----------+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+============+================================+===========+ +============+================================+===========+
| 1 | Advertiser Address in Full (F) | THIS RFC | | 1 | Advertiser Address in Full (F) | THIS RFC |
+------------+--------------------------------+-----------+ +------------+--------------------------------+-----------+
Table 3: New RPL Target Option Flag Table 3: New RPL Target Option Flag
13.4. New Subregistry for the RPL Non-Rejection Status values 16. New Subregistry for the RPL Non-Rejection Status values
This specification creates a new Subregistry for the RPL Non- This specification creates a new Subregistry for the RPL Non-
Rejection Status values for use in RPL DAO-ACK and DCO messages with Rejection Status values for use in RPL DAO-ACK and DCO messages with
the 'A' flag reset, under the ICMPv6 parameters registry. the 'A' flag reset, under the ICMPv6 parameters registry.
* Possible values are 6-bit unsigned integers (0..63). * Possible values are 6-bit unsigned integers (0..63).
* Registration procedure is "Standards Action" [RFC8126]. * Registration procedure is "Standards Action" [RFC8126].
* Initial allocation is as indicated in Table 4: * Initial allocation is as indicated in Table 4:
+-------+------------------------+-----------+ +-------+------------------------+-----------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+========================+===========+ +=======+========================+===========+
| 0 | Unqualified acceptance | RFC 6550 | | 0 | Unqualified acceptance | RFC 6550 |
+-------+------------------------+-----------+ +-------+------------------------+-----------+
Table 4: Acceptance values of the RPL Status Table 4: Acceptance values of the RPL Status
13.5. New Subregistry for the RPL Rejection Status values 17. New Subregistry for the RPL Rejection Status values
This specification creates a new Subregistry for the RPL Rejection This specification creates a new Subregistry for the RPL Rejection
Status values for use in RPL DAO-ACK and RCO messages with the 'A' Status values for use in RPL DAO-ACK and RCO messages with the 'A'
flag reset, under the ICMPv6 parameters registry. flag reset, under the ICMPv6 parameters registry.
* Possible values are 6-bit unsigned integers (0..63). * Possible values are 6-bit unsigned integers (0..63).
* Registration procedure is "Standards Action" [RFC8126]. * Registration procedure is "Standards Action" [RFC8126].
* Initial allocation is as indicated in Table 5: * Initial allocation is as indicated in Table 5:
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+=======================+===============+ +=======+=======================+===============+
| 0 | Unqualified rejection | This document | | 0 | Unqualified rejection | This document |
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
Table 5: Rejection values of the RPL Status Table 5: Rejection values of the RPL Status
13.6. Fixing the Address Registration Option Flags 18. Acknowledgments
Section 9.1 of [RFC8505] creates a Registry for the 8-bit Address
Registration Option Flags field.
IANA is requested to rename the first column of the table from "ARO
Status" to "Bit number".
14. Acknowledgments
The authors wish to thank Ines Robles, Georgios Papadopoulos and The authors wish to thank Ines Robles, Georgios Papadopoulos and
Rahul Jadhav for their reviews and contributions to this document. especially Rahul Jadhav for their reviews and contributions to this
document.
15. Normative References 19. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast
Listener Discovery (MLD) for IPv6", RFC 2710, Listener Discovery (MLD) for IPv6", RFC 2710,
DOI 10.17487/RFC2710, October 1999, DOI 10.17487/RFC2710, October 1999,
<https://www.rfc-editor.org/info/rfc2710>. <https://www.rfc-editor.org/info/rfc2710>.
skipping to change at page 29, line 46 skipping to change at page 29, line 51
23 March 2020, <https://tools.ietf.org/html/draft-ietf- 23 March 2020, <https://tools.ietf.org/html/draft-ietf-
roll-useofrplinfo-38>. roll-useofrplinfo-38>.
[EFFICIENT-NPDAO] [EFFICIENT-NPDAO]
Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient
Route Invalidation", Work in Progress, Internet-Draft, Route Invalidation", Work in Progress, Internet-Draft,
draft-ietf-roll-efficient-npdao-18, 15 April 2020, draft-ietf-roll-efficient-npdao-18, 15 April 2020,
<https://tools.ietf.org/html/draft-ietf-roll-efficient- <https://tools.ietf.org/html/draft-ietf-roll-efficient-
npdao-18>. npdao-18>.
16. Informative References 20. Informative References
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing", Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012, RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>. <https://www.rfc-editor.org/info/rfc6606>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
 End of changes. 40 change blocks. 
102 lines changed or deleted 108 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/