draft-ietf-roll-unaware-leaves-15.txt   draft-ietf-roll-unaware-leaves-16.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550, 8505 (if approved) M. Richardson Updates: 6550, 8505 (if approved) M. Richardson
Intended status: Standards Track Sandelman Intended status: Standards Track Sandelman
Expires: 17 October 2020 15 April 2020 Expires: 10 December 2020 8 June 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-15 draft-ietf-roll-unaware-leaves-16
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 34 skipping to change at page 1, line 34
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 17 October 2020. This Internet-Draft will expire on 10 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 32 skipping to change at page 2, line 32
6. Requirements on the RPL-Unware Leaf . . . . . . . . . . . . . 11 6. Requirements on the RPL-Unware Leaf . . . . . . . . . . . . . 11
6.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 11 6.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 11
6.2. External Routes and RPL Artifacts . . . . . . . . . . . . 12 6.2. External Routes and RPL Artifacts . . . . . . . . . . . . 12
6.2.1. Support of IPv6 Encapsulation . . . . . . . . . . . . 13 6.2.1. Support of IPv6 Encapsulation . . . . . . . . . . . . 13
6.2.2. Support of the HbH Header . . . . . . . . . . . . . . 13 6.2.2. Support of the HbH Header . . . . . . . . . . . . . . 13
6.2.3. Support of the Routing Header . . . . . . . . . . . . 13 6.2.3. Support of the Routing Header . . . . . . . . . . . . 13
7. Updated RPL Status . . . . . . . . . . . . . . . . . . . . . 13 7. Updated RPL Status . . . . . . . . . . . . . . . . . . . . . 13
8. Updated RPL Target option . . . . . . . . . . . . . . . . . . 14 8. Updated RPL Target option . . . . . . . . . . . . . . . . . . 14
9. Protocol Operations for Unicast Addresses . . . . . . . . . . 15 9. Protocol Operations for Unicast Addresses . . . . . . . . . . 15
9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 15 9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 15
9.1.1. In RPL Non-Storing-Mode . . . . . . . . . . . . . . . 16 9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 19
9.1.2. In RPL Storing-Mode . . . . . . . . . . . . . . . . . 19 9.2.1. Perspective of the RUL Acting as 6LN . . . . . . . . 19
9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 21 9.2.2. Perspective of the RPL Border Router Acting as 6LR . 20
9.2.1. By the RUL Acting as 6LN . . . . . . . . . . . . . . 21 9.2.3. Perspective of the RPL Root . . . . . . . . . . . . . 22
9.2.2. By the RPL Border Router Acting as 6LR . . . . . . . 22 9.2.4. Perspective of the 6LBR . . . . . . . . . . . . . . . 23
9.2.3. By the RPL Root . . . . . . . . . . . . . . . . . . . 24 10. Protocol Operations for Multicast Addresses . . . . . . . . . 24
9.2.4. By the 6LBR . . . . . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
10. Protocol Operations for Multicast Addresses . . . . . . . . . 26 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
11. Security Considerations . . . . . . . . . . . . . . . . . . . 28 12.1. Resizing the ARO Status values . . . . . . . . . . . . . 27
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 12.1.1. RPL Target Option Flags . . . . . . . . . . . . . . 27
12.1. Resizing the ARO Status values . . . . . . . . . . . . . 29 12.1.2. Address Registration Option Flags . . . . . . . . . 27
12.2. New DODAG Configuration Option Flag . . . . . . . . . . 29 12.2. New DODAG Configuration Option Flag . . . . . . . . . . 27
12.3. RPL Target Option Flags . . . . . . . . . . . . . . . . 29 12.3. New Subregistry for the RPL Non-Rejection Status
12.4. New Subregistry for the RPL Non-Rejection Status values . . . . . . . . . . . . . . . . . . . . . . . . . 27
values . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.4. New Subregistry for the RPL Rejection Status values . . 28
12.5. New Subregistry for the RPL Rejection Status values . . 30 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
13. acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 14. Normative References . . . . . . . . . . . . . . . . . . . . 28
14. Normative References . . . . . . . . . . . . . . . . . . . . 30 15. Informative References . . . . . . . . . . . . . . . . . . . 31
15. Informative References . . . . . . . . . . . . . . . . . . . 32 Appendix A. Example Compression . . . . . . . . . . . . . . . . 32
Appendix A. Example Compression . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
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 4, line 32 skipping to change at page 4, line 32
defined in 6LoWPAN ND to enable a RUL as a 6LoWPAN Node (6LN) to defined in 6LoWPAN ND to enable a RUL as a 6LoWPAN Node (6LN) to
interface with a RPL-Aware Router as a 6LoWPAN Router (6LR) to interface with a RPL-Aware Router as a 6LoWPAN Router (6LR) to
request that the 6LR injects the relevant routing information for the request that the 6LR injects the relevant routing information for the
Registered Address in the RPL domain on its behalf. A RUL may be Registered Address in the RPL domain on its behalf. A RUL may be
unable to participate because it is very energy-constrained, or unable to participate because it is very energy-constrained, or
because it is unsafe to let it inject routes in RPL, in which case because it is unsafe to let it inject routes in RPL, in which case
using 6LowPAN ND as the interface for the RUL limits the surface of using 6LowPAN ND as the interface for the RUL limits the surface of
the possible attacks and optionally protects the address ownership. the possible attacks and optionally protects the address ownership.
The Non-Storing Mode mechanisms are used to extend the routing state The Non-Storing Mode mechanisms are used to extend the routing state
with connectivity to RULs even when the DODAG is operated in Storing- with connectivity to RULs even when the DODAG is operated in Storing
Mode DODAGs. The unicast packet forwarding operation by the 6LR Mode DODAGs. The unicast packet forwarding operation by the 6LR
serving a 6LN that is a RPL Leaf is described in [USEofRPLinfo]. serving a 6LN that is a RPL Leaf is described in [USEofRPLinfo].
Examples of routing-agnostic 6LNs include lightly-powered sensors Examples of routing-agnostic 6LNs include lightly-powered sensors
such as window smash sensor (alarm system), and kinetically powered such as window smash sensor (alarm system), and kinetically powered
light switches. Other applications of this specification may include light switches. Other applications of this specification may include
a smart grid network that controls appliances - such as washing a smart grid network that controls appliances - such as washing
machines or the heating system - in the home. Appliances may not machines or the heating system - in the home. Appliances may not
participate to the RPL protocol operated in the Smartgrid network but participate to the RPL protocol operated in the Smartgrid network but
can still interact with the Smartgrid for control and/or metering. can still interact with the Smartgrid for control and/or metering.
skipping to change at page 8, line 34 skipping to change at page 8, line 34
(TID), which maps to the Path Sequence Field found in Transit Options (TID), which maps to the Path Sequence Field found in Transit Options
in RPL DAO messages. This is the reason why the support of [RFC8505] in RPL DAO messages. This is the reason why the support of [RFC8505]
by the RUL as opposed to only [RFC6775] is a prerequisite for this by the RUL as opposed to only [RFC6775] is a prerequisite for this
specification (more in Section 6.1). The EARO also transports an specification (more in Section 6.1). The EARO also transports an
Opaque field and an "I" field that describes what the Opaque field Opaque field and an "I" field that describes what the Opaque field
transports and how to use it. Section 9.2.1 specifies the use of the transports and how to use it. Section 9.2.1 specifies the use of the
"I" field and of the Opaque field by a RUL. "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
Networks" [AP-ND] leverages the ROVR field as a cryptographic proof Networks" [AP-ND] leverages the ROVR field as a cryptographic proof
of ownership to prevent a rogue third party from misusing the of ownership to prevent a rogue third party from misusing the
address. [AP-ND] adds a challenge/response exchange to the [RFC8505] address. [AP-ND] adds a challenge/response exchange to the [RFC8505]
Address Registration and enables Source Address Validation by a 6LR Address Registration and enables Source Address Validation by a 6LR
skipping to change at page 10, line 27 skipping to change at page 10, line 27
Root is used to remove RPL artifacts and compression techniques that Root is used to remove RPL artifacts and compression techniques that
may not be processed correctly outside of the RPL domain. may not be processed correctly outside of the RPL domain.
This document also synchronizes the liveness monitoring at the Root This document also synchronizes the liveness monitoring at the Root
and the 6LBR. A same value of lifetime is used for both, and a and the 6LBR. A same value of lifetime is used for both, and a
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 5), for any message to the 6LBR on behalf of the 6LR (more in Section 5), for any
6LN, RUL or RAN. 6LN, RUL or RAN.
RPL defines a configuration option that is registered to IANA in Section 6.7.6 of [RFC6550] defines the DODAG Configuration option
section 20.14. of [RFC6550]. This specification defines a new flag with reserved flags. This specification defines the new "Root
"Root Proxies EDAR/EDAC" (P) that is encoded in one of the reserved Proxies EDAR/EDAC" (P) flag and consumes one of the reserved flags to
control bits in the option. The new flag is set to indicate that the encode it. The "P" flag is set to indicate that the Root performs
Root performs the proxy operation and that all nodes in the RPL the proxy operation and that all nodes in the RPL network must
network must refrain from renewing the 6LBR state directly. The bit refrain from renewing the 6LBR state directly. It also indicates
position of the "P" flag is indicated in Section 12.2. that the Root supports the Updated RPL Target Option (see Section 8).
The position of the "P" flag is indicated in Section 12.2.
Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP) Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in
in the DIO Base Object. The new "P" flag is defined only for MOP the DIO Base Object. The new "P" flag is defined only for MOP value
value between 0 to 6. For a MOP value of 7 or above, the flag MAY between 0 to 6. For a MOP value of 7 or above, the flag MAY be
indicate something different and MUST NOT be interpreted as "Root redefined and MUST NOT be interpreted as "Root Proxies EDAR/EDAC"
Proxies EDAR/EDAC" unless the specification of the MOP indicates to unless the specification of the MOP indicates to do so.
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 used in the DCO messages DAO-Ack message is extended to be used in the DCO messages
[EFFICIENT-NPDAO] as well. Furthermore, this specification enables [EFFICIENT-NPDAO] as well. Furthermore, this specification enables
to use a RPL Status to transport the IPv6 ND Status defined for use to use a RPL Status to embed the IPv6 ND Status defined for use in
in the EARO, more in Section 7. the EARO, more in Section 7.
Section 6.7. of [RFC6550] introduces the RPL Control message Options Section 6.7 of [RFC6550] introduces the RPL Control message Options
such as the RPL Target Option that can be included in a RPL Control such as the RPL Target Option that can be included in a RPL Control
message such as the DAO. Section 8 updates the RPL Target Option to message such as the DAO. Section 8 updates the RPL Target Option to
optionally transport the ROVR used in the IPv6 Registration (see optionally transport the ROVR used in the IPv6 Registration (see
Section 3.2.3) so the RPL Root can generate a full EDAR message. Section 3.2.3) so the RPL Root can generate a full EDAR message.
5. Updating RFC 8505 5. Updating RFC 8505
This document updates [RFC8505] to introduce the anonymous EDAR and This document updates [RFC8505] to introduce the anonymous EDAR and
NS(EARO) messages. The anonymous messages are used for backward NS(EARO) messages. The anonymous messages are used for backward
compatibility. The anonymous messages are recognizable by a zero compatibility. The anonymous messages are recognizable by a zero
ROVR field and can only be used as a refresher for a pre-existing ROVR field and can only be used as a refresher for a pre-existing
state associated to the Registered Address. More specifically, an state associated to the Registered Address. More specifically, an
anonymous message can only increase the lifetime and/or increment the anonymous message can only increase the lifetime and/or increment the
TID of an existing state at the 6LBR. TID of an existing state at the 6LBR.
Upon the renewal of a 6LoWPAN ND Address Registration, this Upon the renewal of a 6LoWPAN ND Address Registration, this
specification changes the behavior of a RPL Router acting as 6LR for specification changes the behavior of a RPL Router acting as 6LR for
the registration. If the Root indicates the capability to proxy the the registration. If the Root indicates the capability to proxy the
EDAR/EDAC exchange to the 6LBR then the 6LR refrains from sending an EDAR/EDAC exchange to the 6LBR by setting the "P" flag, the 6LR
EDAR message; if the Root is separated from the 6LBR, the Root refrains from sending an EDAR message; if the Root is separated from
regenerates the EDAR message to the 6LBR upon a DAO message that the 6LBR, the Root regenerates the EDAR message to the 6LBR upon a
signals the liveliness of the Address. The regenerated message is DAO message that signals the liveliness of the Address. The
anonymous iff the DAO is a legacy message that does not carry a ROVR regenerated message is anonymous if and only if the DAO is a legacy
as specified in Section 8. message that does not carry a ROVR as specified in Section 8.
6. Requirements on the RPL-Unware Leaf 6. 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.
6.1. Support of 6LoWPAN ND 6.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
skipping to change at page 12, line 7 skipping to change at page 12, line 7
invalidate some of the routes till the Address Registration finally invalidate some of the routes till the Address Registration finally
shows on those routes as well. shows on those routes as well.
[RFC8505] introduces error Status values in the NA(EARO) which can be [RFC8505] introduces error Status values in the NA(EARO) which can be
received synchronously upon an NS(EARO) or asynchronously. The RUL received synchronously upon an NS(EARO) or asynchronously. The RUL
MUST support both cases and MUST refrain from using the address when MUST support both cases and MUST refrain from using the address when
the Status value indicates a rejection. the Status value indicates a rejection.
6.2. External Routes and RPL Artifacts 6.2. External Routes and RPL Artifacts
Section 4.1. of [USEofRPLinfo] provides a set of rules that MUST be Section 4.1 of [USEofRPLinfo] provides a set of rules that MUST be
followed for the routing operations to a RUL. followed for the routing operations to a RUL.
A 6LR that is upgraded to act as a border router for external routes A 6LR that is upgraded to act as a border router for external routes
advertises them using Non-Storing Mode DAO messages that are unicast advertises them using Non-Storing Mode DAO messages that are unicast
directly to the Root, even if the DODAG is operated in Storing Mode. directly to the Root, even if the DODAG is operated in Storing Mode.
Non-Storing Mode routes are not visible inside the RPL domain and all Non-Storing Mode routes are not visible inside the RPL domain and all
packets are routed via the Root. An upgraded Root tunnels the packets are routed via the Root. An upgraded Root tunnels the
packets directly to the 6LR that advertised the external route which packets directly to the 6LR that advertised the external route which
decapsulates and forwards the original (inner) packet. decapsulates and forwards the original (inner) packet.
skipping to change at page 12, line 38 skipping to change at page 12, line 38
its packets with an RPI, the 6LR needs to tunnel them to the Root to its packets with an RPI, the 6LR needs to tunnel them to the Root to
add the RPI. As a rule of a thumb and except for the very special add the RPI. As a rule of a thumb and except for the very special
case above, the packets from and to a RUL are always encapsulated case above, the packets from and to a RUL are always encapsulated
using an IP-in-IP tunnel between the Root and the 6LR that serves the using an IP-in-IP tunnel between the Root and the 6LR that serves the
RUL (see sections 7.1.4, 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4, RUL (see sections 7.1.4, 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4,
8.2.3, 8.2.4, 8.3.3 and 8.3.4 of [USEofRPLinfo] for details). 8.2.3, 8.2.4, 8.3.3 and 8.3.4 of [USEofRPLinfo] for details).
In Non-Storing Mode, packets going down carry a Source Routing Header In Non-Storing Mode, packets going down carry a Source Routing Header
(SRH). The IP-in-IP encapsulation, the RPI and the SRH are (SRH). The IP-in-IP encapsulation, the RPI and the SRH are
collectively called the "RPL artifacts" and can be compressed using collectively called the "RPL artifacts" and can be compressed using
[RFC8138]. Figure 14 presents an example compressed format for a [RFC8138]. Figure 11 presents an example compressed format for a
packet forwarded by the Root to a RUL in a Storing Mode DODAG. packet forwarded by the Root to a RUL in a Storing Mode DODAG.
The inner packet that is forwarded to the RUL may carry some RPL The inner packet that is forwarded to the RUL may carry some RPL
artifacts, e.g., an RPI if the original packet was generated with it artifacts, e.g., an RPI if the original packet was generated with it
and possibly an SRH in a Non-Storing Mode DODAG. [USEofRPLinfo] and possibly an SRH in a Non-Storing Mode DODAG. [USEofRPLinfo]
expects the RUL to support the basic "IPv6 Node Requirements" expects the RUL to support the basic "IPv6 Node Requirements"
[RFC8504]. In particular the RUL is expected to ignore the RPL [RFC8504]. In particular the RUL is expected to ignore the RPL
artifacts that are either consumed or not applicable to a Host. artifacts that are either consumed or not applicable to a Host.
A RUL is not expected to support the compression method defined in A RUL is not expected to support the compression method defined in
skipping to change at page 13, line 33 skipping to change at page 13, line 33
6.2.3. Support of the Routing Header 6.2.3. Support of the Routing Header
A RUL is expected to process an unknown Routing Header Type as A RUL is expected to process an unknown Routing Header Type as
prescribed by section 4.4 of [RFC8200]. This means in particular prescribed by section 4.4 of [RFC8200]. This means in particular
that Routing Header with a Routing Type of 3 [RFC6554] is ignored that Routing Header with a Routing Type of 3 [RFC6554] is ignored
when the Segments Left is zero, and the packet is dropped otherwise. when the Segments Left is zero, and the packet is dropped otherwise.
7. Updated RPL Status 7. Updated RPL Status
The RPL Status is defined in section 6.5.1. of [RFC6550] for use in The RPL Status is defined in section 6.5.1 of [RFC6550] for use in
the DAO-Ack message and values are assigned as follows: the DAO-Ack message and values are assigned as follows:
+---------+--------------------------------+ +---------+--------------------------------+
| Range | Meaning | | Range | Meaning |
+=========+================================+ +=========+================================+
| 0 | Success/Unqualified acceptance | | 0 | Success/Unqualified acceptance |
+---------+--------------------------------+ +---------+--------------------------------+
| 1-127 | Not an outright rejection | | 1-127 | Not an outright rejection |
+---------+--------------------------------+ +---------+--------------------------------+
| 128-255 | Rejection | | 128-255 | Rejection |
skipping to change at page 14, line 29 skipping to change at page 14, line 29
of 0 indicates Success/Unqualified acceptance and other values of 0 indicates Success/Unqualified acceptance and other values
indicate "not an outright rejection" as per RFC 6550. indicate "not an outright rejection" as per RFC 6550.
A: 1-bit flag. Indicates the type of the Status value. A: 1-bit flag. Indicates the type of the Status value.
Status Value: 6-bit unsigned integer. If the 'A' flag is set this Status Value: 6-bit unsigned integer. If the 'A' flag is set this
field transports a Status value defined for IPv6 ND EARO. When field transports a Status value defined for IPv6 ND EARO. When
the 'A' flag is not set, the Status value is defined in a RPL the 'A' flag is not set, the Status value is defined in a RPL
extension. extension.
When building a DCO or a DAO-ACK message upon an IPv6 ND NA or a DAC When building a DCO or a DAO-ACK message upon an IPv6 ND NA or a EDAC
message, the RPL Root MUST copy the ARO Status unchanged in a RPL message, the RPL Root MUST copy the ND Status unchanged in a RPL
Status with the 'A' bit set. The RPL Root MUST set the 'E' flag for Status with the 'A' bit set. The RPL Root MUST set the 'E' flag for
all values in range 1-10 which are all considered rejections. all values in range 1-10 which are all considered rejections.
Conversely, the 6LR MUST copy the value of the RPL Status unchanged Conversely, the 6LR MUST copy the value of the RPL Status unchanged
in the EARO of an NA message that is built upon a RPL Status with the in the EARO of an NA message that is built upon a RPL Status with the
'A' bit set in a DCO or a DAO-ACK message. 'A' bit set in a DCO or a DAO-ACK message.
8. Updated RPL Target option 8. Updated RPL Target option
This specification updates the RPL Target option to transport the This specification updates the RPL Target option to transport the
skipping to change at page 16, line 22 skipping to change at page 16, line 22
On the first Address Registration, illustrated in Figure 5 for RPL On the first Address Registration, illustrated in Figure 5 for RPL
Non-Storing Mode, the Extended Duplicate Address exchange takes place Non-Storing Mode, the Extended Duplicate Address exchange takes place
as prescribed by [RFC8505]. If the exchange fails, the 6LR returns as prescribed by [RFC8505]. If the exchange fails, the 6LR returns
an NA message with a negative status to the 6LN, the NCE is not an NA message with a negative status to the 6LN, the NCE is not
created and the address is not injected in RPL. If it is successful, created and the address is not injected in RPL. If it is successful,
the 6LR creates an NCE and injects the Registered Address in RPL the 6LR creates an NCE and injects the Registered Address in RPL
using DAO/DAO-ACK exchanges all the way to the RPL DODAG Root. using DAO/DAO-ACK exchanges all the way to the RPL DODAG Root.
The 6LN signals the termination of a registration with a 6LR using an The 6LN signals the termination of a registration with a 6LR using an
NS(EARO) with a Registration Lifetime set to 0. Upon this, the 6LR NS(EARO) with a Registration Lifetime set to 0. Upon this, the 6LR
MUST perform an EDAR/EDAC exchange to clean up the state at the 6LBR, ensures that an EDAR/EDAC exchange happens to clean up the state at
as illustrated in Figure 8, unless it uses the ROVR in the RPL Target the 6LBR, either directly as shown in Figure 8, or, if the Root sets
Option and, in Storing Mode, it is propagated to the Root. the "P" flag, by setting the ROVR in the RPL Target Option.
9.1.1. In RPL Non-Storing-Mode
In Non-Storing Mode, the DAO message flow can be nested within the Since RULs are advertised using Non-Storing Mode, the DAO message
Address Registration flow as illustrated in Figure 5. flow can be nested within the Address Registration flow as
illustrated in Figure 5.
6LN/RUL 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | |--------------->| |
| | Extended DAR | | | Extended DAR |
| |--------------------------------->| | |--------------------------------->|
| | | | | |
| | Extended DAC | | | Extended DAC |
| |<---------------------------------| | |<---------------------------------|
| | DAO | | | | DAO | |
| |------------->| | | |------------->| |
| | | (anonymous) EDAR | | | | (anonymous) EDAR |
| | |------------------>| | | |------------------>|
| | | EDAC | | | | EDAC |
| | |<------------------| | | |<------------------|
| | DAO-ACK | | | | DAO-ACK | |
| |<-------------| | | |<-------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |<---------------| | |
| | | | | | | |
Figure 5: First Registration Flow in Non-Storing Mode Figure 5: First RUL Registration Flow
An issue may be detected later, e.g., the address moves within the An issue may be detected later, e.g., the address moves within the
LLN or to a different Root on a backbone [6BBR]. In that case the LLN or to a different Root on a backbone [6BBR]. In that case the
value of the status that indicates the issue can be passed from value of the status that indicates the issue can be passed from
6LoWPAN ND to RPL and back as illustrated in Figure 6. 6LoWPAN ND to RPL and back as illustrated in Figure 6.
6LN/RUL 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| | | NA(EARO, Status) | | | | NA(EARO, Status) |
| | |<-----------------| | | |<-----------------|
| | DCO(Status) | | | | DCO(Status) | |
| |<------------| | | |<------------| |
| NA(EARO, Status) | | | | NA(EARO, Status) | | |
|<-----------------| | | |<-----------------| | |
| | | | | | | |
Figure 6: Asynchronous Issue Figure 6: Asynchronous Issue
An Address re-Registration is performed by the 6LN to maintain the An Address re-Registration is performed by the 6LN to maintain the
NCE in the 6LR alive before lifetime expires. Upon an Address re- NCE in the 6LR alive before lifetime expires. Upon an Address re-
Registration, as illustrated in Figure 7, the 6LR redistributes the Registration, as illustrated in Figure 7, the 6LR redistributes the
Registered Address NS(EARO) in RPL. Registered Address NS(EARO) in RPL.
6LN/RUL 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | |--------------->| |
| | DAO | | | | DAO | |
| |------------->| | | |------------->| |
| | | (anonymous) EDAR | | | | (anonymous) EDAR |
| | |------------------>| | | |------------------>|
| | | EDAC | | | | EDAC |
| | |<------------------| | | |<------------------|
| | DAO-ACK | | | | DAO-ACK | |
| |<-------------| | | |<-------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |<---------------| | |
Figure 7: Next Registration Flow in Non-Storing Mode Figure 7: Next RUL Registration Flow
This causes the RPL DODAG Root to refresh the state in the 6LBR with This causes the RPL DODAG Root to refresh the state in the 6LBR with
an EDAC message or an anonymous EDAC if the ROVR is not indicated in an EDAC message or an anonymous EDAC if the ROVR is not indicated in
the Target Option. In both cases, the EDAC message sent in response the Target Option. In both cases, the EDAC message sent in response
by the 6LBR contains the actual value of the ROVR field for that by the 6LBR contains the actual value of the ROVR field for that
Address Registration. In case of an error on the proxied EDAR flow, Address Registration. In case of an error on the proxied EDAR flow,
the error MUST be returned in the DAO-ACK - if one was requested - the error MUST be returned in the DAO-ACK - if one was requested -
using a RPL Status with the 'A' flag set that imbeds a 6LoWPAN Status using a RPL Status with the 'A' flag set that imbeds a 6LoWPAN Status
value as discussed in Section 7. value as discussed in Section 7.
If the Root could not return the negative Status in the DAO-ACK then If the Root could not return the negative Status in a DAO-ACK then it
it sends an asynchronous Destination Cleanup Object (DCO) message sends an asynchronous Destination Cleanup Object (DCO) message
[EFFICIENT-NPDAO] to the 6LR by placing the negative Status in the [EFFICIENT-NPDAO] to the 6LR by placing the negative Status in the
RPL Status with the 'A' flag set. Note that if both are used in a RPL Status with the 'A' flag set. Note that if both are used in a
short interval of time, the DAO-ACK and DCO messages are not short interval of time, the DAO-ACK and DCO messages are not
guaranteed to arrive in the same order at the 6LR. guaranteed to arrive in the same order at the 6LR.
The 6LR may receive a requested DAO-ACK even after it received a DCO, The 6LR may receive a requested DAO-ACK even after it received a DCO,
but the negative Status in the DCO supercedes a positive Status in but the negative Status in the DCO supercedes a positive Status in
the DAO-ACK regardless of the order in which they are received. Upon the DAO-ACK regardless of the order in which they are received. Upon
the DAO-ACK - or the DCO if it arrives first - the 6LR responds to the DAO-ACK - or the DCO if it arrives first - the 6LR responds to
the RUL with an NA(EARO). If the RPL Status has the 'A' flag set, the RUL with an NA(EARO). If the RPL Status has the 'A' flag set,
skipping to change at page 18, line 29 skipping to change at page 18, line 29
is used; else, the ND Status of 0 indicating "Success" is used. is used; else, the ND Status of 0 indicating "Success" is used.
The RUL may terminate the registration at anytime by using a The RUL may terminate the registration at anytime by using a
Registration Lifetime of 0. This specification expects that the RPL Registration Lifetime of 0. This specification expects that the RPL
Target option transports a ROVR. If that is the case, the normal Target option transports a ROVR. If that is the case, the normal
heartbeat flow is sufficient to inform the 6LBR using the Root as heartbeat flow is sufficient to inform the 6LBR using the Root as
proxy as illustrated in Figure 7. If the 6LR could not add the ROVR proxy as illustrated in Figure 7. If the 6LR could not add the ROVR
to the DAO message, then it MUST inform the 6LBR separately using as to the DAO message, then it MUST inform the 6LBR separately using as
illustrated in Figure 8. illustrated in Figure 8.
6LN/RUL 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
|NS(EARO,Lifet=0)| | | |NS(EARO,Lifet=0)| | |
|--------------->| | |--------------->| |
| | Extended DAR | | | Extended DAR |
| |--------------------------------->| | |------------------------------------->|
| | | | | |
| | Extended DAC | | | Extended DAC |
| |<---------------------------------| | |<-------------------------------------|
| |DAO (Lifeti=0)| | | | DAO (Lifetime=0) | |
| |------------->| | | |----------------->| |
| | | anonymous EDAR | | | | anonymous EDAR |
| | |------------------>| | | |------------------>|
| | | EDAC | | | | EDAC |
| | |<------------------| | | |<------------------|
| | DAO-ACK | | | | DAO-ACK | |
| |<-------------| | | |<-----------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |<---------------| | |
| | | | | | | |
| <Remove NCE> | | | <Remove NCE> | |
| | | | | | | |
Figure 8: Last Registration Flow in Non-Storing Mode, No ROVR
9.1.2. In RPL Storing-Mode
In RPL Storing Mode, the DAO-ACK is optional. When it is used, it is
generated by the RPL parent, which does not need to wait for the
grand-parent to send the acknowledgment. A successful DAO-ACK is not
a guarantee that the DAO has yet reached the Root or that the EDAR
was successfully proxied by the Root.
The 6LR uses the EDAR/EDAC exchange as in Non-Storing Mode, for the
initial registration, and also possibly at the termination in the
case the 6LR could not add the ROVR to the RPL Target option of the
DAO message.
6LN/RUL 6LR 6LR Root 6LBR
| | | | |
| NS(EARO) | | | |
|-------------->| | | |
| | Extended DAR |
| |------------------------------------------------->|
| | |
| | Extended DAC |
| |<-------------------------------------------------|
| NA(EARO) | | | |
|<--------------| | | |
| | DAO | | |
| |-------------->| | |
| | DAO-ACK | | |
| |<--------------| | |
| | | DAO | |
| | |-------------->| |
| | | DAO-ACK | |
| | |<--------------| |
| | | | (anonymous) EDAR |
| | | |----------------->|
| | | | EDAC(ROVR) |
| | | |<-----------------|
| | | | |
Figure 9: First Registration Flow in Storing Mode
The Storing Mode of RPL does not provide and end-to-end confirmation
that a DAO reached the root. When the 6LR has just joined, and later
if DAO messages are lost before reaching the Root, the 6LR might not
be reachable back from the Root. Performing an EDAR/EDAC exchange on
behalf of a RUL provides that confirmation. On the other hand, if
the 6LR retries an EDAR and never gets and EDAC back, it SHOULD
resend a DAO to become reachable again, before it tries another
sequence of EDAR.
6LN/RUL 6LR 6LR Root 6LBR
| | | | |
| NS(EARO) | | | |
|-------------->| | | |
| NA(EARO) | | | |
|<--------------| | | |
| | DAO | | |
| |-------------->| | |
| | DAO-ACK | | |
| |<--------------| | |
| | | DAO | |
| | |-------------->| |
| | | DAO-ACK | |
| | |<--------------| |
| | | | (anonymous) EDAR |
| | | |----------------->|
| | | | EDAC(ROVR) |
| | | |<-----------------|
| | | | |
Figure 10: Next Registration Flow in Storing Mode
If the keep-alive fails, or an asynchronous issue is reported, the
path can be cleaned up asynchronously using a DCO message
[EFFICIENT-NPDAO] as illustrated in Figure 11 and described in
further details in Section 9.2.3.
6LN/RUL 6LR 6LR Root 6LBR
| | | | |
| | | | NA(EARO, Status) |
| | | |<-----------------|
| | | | |
| | | DCO(Status) | |
| | |<------------| |
| | | | |
| | DCO(Status) | | |
| |<------------| | |
| | | | |
| NA(EARO, Status) | | | |
|<-----------------| | | |
| | | | |
Figure 11: Issue in Storing Mode
In the case illustrated here, the issue is actually detected in the Figure 8: Last RUL Registration Flow, No ROVR
ND protocol and reported in the State of a NA(EARO) message. That
statis is transported in the DCO message as a RPL Status with the 'A'
and typically the 'E' flags set.
9.2. Detailed Operation 9.2. Detailed Operation
9.2.1. By the RUL Acting as 6LN 9.2.1. Perspective of the RUL Acting as 6LN
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
skipping to change at page 22, line 16 skipping to change at page 20, line 16
"I" field to zero to signal "topological information to be passed to "I" field to zero to signal "topological information to be passed to
a routing process" as specified in section 5.1 of [RFC8505]. a routing process" as specified in section 5.1 of [RFC8505].
A RUL is not expected to produce RPL artifacts in the data packets, A RUL is not expected to produce RPL artifacts in the data packets,
but it MAY do so. For instance, if the RUL has a minimal awareness but it MAY do so. For instance, if the RUL has a minimal awareness
of the RPL Instance then it can build an RPI. A RUL that places an of the RPL Instance then it can build an RPI. A RUL that places an
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].
9.2.2. By the RPL Border Router Acting as 6LR 9.2.2. Perspective of the RPL 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 refreshes of the registration, if the RPL Root has indicated
that it proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see that it 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
itself. itself.
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 SHOULD attempt to
inject the host route in RPL, unless this is barred for other inject the host route in RPL, unless this is barred for other
reasons, like a saturation of the network or if its RPL parent. The reasons, like a saturation of the network or if its RPL parent. The
6LR MUST set "R" flag in the NA(EARO) back if and only if it 6LR MUST use a RPL Non-Storing Mode signaling.
successfully injected the Registered Address in RPL.
The 6LR SHOULD request a DAO-ACK, failure to do so may incur an
asynchronous error flow that will tear down a state just installed
with the RUL. The 6LR MUST set "R" flag in the NA(EARO) back if and
only if it injected the Registered Address in the RPL routing. If a
DAO-ACK was requested, this is done upon receiving the DAO-ACK from
the Root with a positive status.
The 6LR may at any time send a unicast asynchronous NA(EARO) with the The 6LR may at any time send a unicast asynchronous NA(EARO) with the
"R" flag reset to signal that it stops providing routing services, "R" flag reset to signal that it stops providing routing services,
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].
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
skipping to change at page 24, line 34 skipping to change at page 22, line 34
ND Status value if there was one, and the "R" flag not set. ND Status value if there was one, and the "R" flag not set.
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 and a Registration Lifetime that is not 0, and the 6LR was
redistributing the Registered Address due to previous NS(EARO) redistributing the Registered Address due to previous NS(EARO)
messages with the flag set, then it MUST stop injecting the address. messages with the flag set, then it MUST stop injecting the address.
It is up to the Registering 6LN to maintain the corresponding route It is up to the Registering 6LN to maintain the corresponding route
from then on, either keeping it active via a different 6LR or by from then on, either keeping it active via a different 6LR or by
acting as an RAN and managing its own reachability. acting as an RAN and managing its own reachability.
9.2.3. By the RPL Root 9.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 configuration option of
the DIO messages that it generates (see Section 4) to signal that it the DIO messages that it generates (see Section 4) to signal that it
proxies the keep-alive EDAR/EDAC echange. The remainder of this proxies the keep-alive EDAR/EDAC exchange and supports the Updated
section assumes that it does. RPL Target option. The remainder of this section assumes that it
does.
Upon reception of a DAO message, for each RPL Target option that Upon reception of a DAO message, for each RPL Target option that
creates or updates an existing RPL state, the Root notifies the 6LBR. creates or updates an existing RPL state, the Root MUST notify the
This can be done using an internal API if they are co-located, or 6LBR. This can be done using an internal API if they are co-located,
using a proxied EDAR/EDAC exchange if they are separated. or using a proxied EDAR/EDAC exchange if they are separated.
If the RPL Target option transports a ROVR, then the Root MUST use it Upon receiving an EDAC message from the 6LBR, if a DAO is pending,
to build a full EDAR message; else, an anonymous EDAR is used with then the Root MUST send a DAO-ACK back to the 6LR. Else, if the
the ROVR field set to zero. 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.
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. If the ROVR is present in the RPL Target option, it is copied as 4. If the ROVR is present in the RPL Target option, it is copied as
is in the EDAR and the ICMP Code Suffix is set to the appropriate is in the EDAR and the ICMP Code Suffix is set to the appropriate
value as shown in Table 4 of [RFC8505] depending on the size of value as shown in Table 4 of [RFC8505] depending on the size of
the ROVR field; else, the ROVR field in the EDAR is set to zero the ROVR field; else, the ROVR field in the EDAR is set to zero
indicating an anonymous EDAR. indicating an anonymous EDAR.
Upon a Status value in an EDAC message that is not "Success", the 9.2.4. Perspective of the 6LBR
Root SHOULD destroy the formed paths using either a DAO-ACK (in Non-
Storing Mode) or a DCO downwards as specified in [EFFICIENT-NPDAO].
Failure to destroy the former path would result in Stale routing
state and local black holes if the address belongs to another party
elsewhere in the network. The RPL Status value that maps the 6LoWPAN
ND Status value MUST be embedded in the RPL Status in the DCO.
9.2.4. By the 6LBR
Upon reception of an EDAR message with the ROVR field set to a non- Upon reception of an EDAR message with the ROVR field set to a non-
zero value, the 6LBR acts as prescribed by [RFC8505]. If the ROVR is zero value, the 6LBR acts as prescribed by [RFC8505] and returns an
set to 0, indicating an anonymous EDAR, the 6LBR MUST act as below: EDAC message to the sender.
If the ROVR is set to 0, indicating an anonymous EDAR, the 6LBR MUST
act as below:
1. The 6LBR checks whether an entry exists for the address. If the 1. The 6LBR checks whether an entry exists for the address. If the
entry does not exist, the 6LBR MUST NOT create the entry, and it entry does not exist, the 6LBR MUST NOT create the entry, and it
MUST answer with a Status "Removed" in the EDAC message. If the MUST answer with a Status "Removed" in the EDAC message. If the
entry exists, the 6LBR computes whether the TID in the EDAR entry exists, the 6LBR computes whether the TID in the EDAR
message is fresher than the one in the entry as prescribed in message is fresher than the one in the entry as prescribed in
section 4.2.1. of [RFC8505], and continues as follows: section 4.2.1 of [RFC8505], and continues as follows:
2. If the anonymous EDAR message is fresher, the 6LBR updates the 2. If the anonymous EDAR message is fresher, the 6LBR updates the
TID in the entry, restarts the heartbeat timer for the entry, and TID in the entry, restarts the heartbeat timer for the entry, and
answers with a Status "Success" in the EDAC message. If the answers with a Status "Success" in the EDAC message. If the
value of the Registration Lifetime is smaller than the value in value of the Registration Lifetime is smaller than the value in
the entry, then the latter value MUST be used for the heartbeat; the entry, then the latter value MUST be used for the heartbeat;
this means in particular that the Registration Lifetime of 0 is this means in particular that the Registration Lifetime of 0 is
ignored. Conversely, if the duration of the Lifetime is extended ignored. Conversely, if the duration of the Lifetime is extended
by the Registration Lifetime in the EDAR message, it is used for by the Registration Lifetime in the EDAR message, it is used for
the hearbeat and to the value in the entry is updated. the hearbeat and to the value in the entry is updated.
skipping to change at page 26, line 30 skipping to change at page 24, line 26
"Multicast Listener Discovery (MLD) for IPv6" [RFC2710] and its "Multicast Listener Discovery (MLD) for IPv6" [RFC2710] and its
updated version "Multicast Listener Discovery Version 2 (MLDv2) for updated version "Multicast Listener Discovery Version 2 (MLDv2) for
IPv6" [RFC3810] provide an interface for a listener to register to IPv6" [RFC3810] provide an interface for a listener to register to
multicast flows. MLDv2 is backwards compatible with MLD, and adds in multicast flows. MLDv2 is backwards compatible with MLD, and adds in
particular the capability to filter the sources via black lists and particular the capability to filter the sources via black lists and
white lists. In the MLD model, the Router is a "querier" and the white lists. In the MLD model, the Router is a "querier" and the
Host is a multicast listener that registers to the querier to obtain Host is a multicast listener that registers to the querier to obtain
copies of the particular flows it is interested in. copies of the particular flows it is interested in.
On the first Address Registration, as illustrated in Figure 12, the On the first Address Registration, as illustrated in Figure 9, the
6LN, as an MLD listener, sends an unsolicited Report to the 6LR in 6LN, as an MLD listener, sends an unsolicited Report to the 6LR in
order to start receiving the flow immediately. order to start receiving the flow immediately.
6LN/RUL 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| unsolicited Report | | | | unsolicited Report | | |
|------------------->| | | |------------------->| | |
| <L2 ack> | DAO | | | <L2 ack> | | |
| | DAO | |
| |-------------->| | | |-------------->| |
| | DAO-ACK | | | | DAO-ACK | |
| |<--------------| <if not listening> | | |<--------------| |
| | | <if not listening> |
| | | unsolicited Report | | | | unsolicited Report |
| | |------------------->| | | |------------------->|
| | | | | | | |
Figure 12: First Multicast Registration Flow Figure 9: First Multicast Registration Flow
Since multicast Layer-2 messages are avoided, it is important that Since multicast Layer-2 messages are avoided, it is important that
the asynchronous messages for unsolicited Report and Done are sent the asynchronous messages for unsolicited Report and Done are sent
reliably, for instance using a Layer-2 acknowledgment, or attempted reliably, for instance using a Layer-2 acknowledgment, or attempted
multiple times. multiple times.
The 6LR acts as a generic MLD querier and generates a DAO for the The 6LR acts as a generic MLD querier and generates a DAO for the
multicast target. The lifetime of the DAO is set to be in the order multicast target. The lifetime of the DAO is set to be in the order
of the Query Interval, yet larger to account for variable propagation of the Query Interval, yet larger to account for variable propagation
delays. delays.
skipping to change at page 27, line 20 skipping to change at page 25, line 20
The Root proxies the MLD exchange as a listener with the 6LBR acting The Root proxies the MLD exchange as a listener with the 6LBR acting
as the querier, so as to get packets from a source external to the as the querier, so as to get packets from a source external to the
RPL domain. Upon a DAO with a multicast target, the RPL Root checks RPL domain. Upon a DAO with a multicast target, the RPL Root checks
if it is already registered as a listener for that address, and if if it is already registered as a listener for that address, and if
not, it performs its own unsolicited Report for the multicast target. not, it performs its own unsolicited Report for the multicast target.
An Address re-Registration is pulled periodically by 6LR acting as An Address re-Registration is pulled periodically by 6LR acting as
querier. Note that the message may be sent unicast to all the known querier. Note that the message may be sent unicast to all the known
individual listeners. Upon a time out of the Query Interval, the 6LR individual listeners. Upon a time out of the Query Interval, the 6LR
sends a Query to each of its listeners, and gets a Report back that sends a Query to each of its listeners, and gets a Report back that
is mapped into a DAO, as illustrated in Figure 13: is mapped into a DAO, as illustrated in Figure 10:
6LN/RUL 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| Query | | | | Query | | |
|<-------------------| | | |<-------------------| | |
| Report | | | | Report | | |
|------------------->| | | |------------------->| | |
| <L2 ack> | | |
| | DAO | | | | DAO | |
| |-------------->| | | |-------------->| |
| | DAO-ACK | | | | DAO-ACK | |
| |<--------------| | | |<--------------| |
| | | | | | | |
| | | Query | | | | Query |
| | |<-------------------| | | |<-------------------|
| | | Report | | | | Report |
| | |------------------->| | | |------------------->|
| | | | | | | |
| | | | | | | |
Figure 13: Next Registration Flow Figure 10: Next Registration Flow
Note that any of the functions 6LR, Root and 6LBR might be collapsed Note that any of the functions 6LR, Root and 6LBR might be collapsed
in a single node, in which case the flow above happens internally, in a single node, in which case the flow above happens internally,
and possibly through internal API calls as opposed to messaging. and possibly through internal API calls as opposed to messaging.
11. Security Considerations 11. Security Considerations
First of all, it is worth noting that with [RFC6550], every node in First of all, it is worth noting that with [RFC6550], every node in
the LLN is RPL-aware and can inject any RPL-based attack in the the LLN is RPL-aware and can inject any RPL-based attack in the
network. This specification isolates edge nodes that can only network. This specification isolates edge nodes that can only
interact with the RPL routers using 6LoWPAN ND, meaning that they interact with the RPL routers using 6LoWPAN ND, meaning that they
cannot perform RPL insider attacks. 6LoWPAN ND can optionally provide cannot perform RPL insider attacks.
SAVI features, which reduces even more the attack perimeter that is
available to the edge nodes. 6LoWPAN ND can optionally provide SAVI features with [AP-ND], which
reduces even more the attack perimeter that is available to the edge
nodes.
The LLN nodes depend on the 6LBR and the RPL participants for their The LLN nodes depend on the 6LBR and the RPL participants for their
operation. A trust model must be put in place to ensure that the operation. A trust model must be put in place to ensure that the
right devices are acting in these roles, so as to avoid threats such right devices are acting in these roles, so as to avoid threats such
as black-holing, (see [RFC7416] section 7) or bombing attack whereby as black-holing, (see [RFC7416] section 7) or bombing attack whereby
an impersonated 6LBR would destroy state in the network by using the an impersonated 6LBR would destroy state in the network by using the
"Removed" Status code. "Removed" Status code.
This trust model could be at a minimum based on a Layer-2 Secure This trust model could be at a minimum based on a Layer-2 Secure
joining and the Link-Layer security. This is a generic 6LoWPAN joining and the Link-Layer security. This is a generic 6LoWPAN
skipping to change at page 29, line 4 skipping to change at page 27, line 6
(forged) addresses and ROVR, and that this is a much easier DoS (forged) addresses and ROVR, and that this is a much easier DoS
attack than trying to keep existing state alive longer. attack than trying to keep existing state alive longer.
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 by the 6LR that direction by allowing the Root to challenge the RUL by the 6LR that
serves it. serves it.
12. IANA Considerations 12. IANA Considerations
12.1. Resizing the ARO Status values 12.1. Resizing the ARO Status values
IANA is requested to modify the Address Registration Option Status Section 12 of [RFC6775] creates the Address Registration Option
Values Registry as follows: The unassigned values range is reduced Status Values Registry with a range 0-255. This specification
from 11-255 to 11-63. reduces that range to 0-63.
IANA is requested to reduce the unassigned values range from 11-255
to 11-63.
12.1.1. RPL Target Option Flags
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 the field in the Registry to
4 bits.
12.1.2. 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".
12.2. New DODAG Configuration Option Flag 12.2. 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
12.3. RPL Target Option Flags 12.3. New Subregistry for the RPL Non-Rejection Status values
Section 20.15 of [RFC6550] creates a registry for the 8-bit RPL
Target Option Flags field. This specification reduces the field to 4
bits. The IANA is requested to reduce the size of the registry
accordingly.
12.4. 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 3: * Initial allocation is as indicated in Table 3:
+-------+------------------------+-----------+ +-------+------------------------+-----------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+========================+===========+ +=======+========================+===========+
| 0 | Unqualified acceptance | RFC 6550 | | 0 | Unqualified acceptance | RFC 6550 |
+-------+------------------------+-----------+ +-------+------------------------+-----------+
Table 3: Acceptance values of the RPL Status Table 3: Acceptance values of the RPL Status
12.5. New Subregistry for the RPL Rejection Status values 12.4. 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 4: * Initial allocation is as indicated in Table 4:
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+=======================+===============+ +=======+=======================+===============+
| 0 | Unqualified rejection | This document | | 0 | Unqualified rejection | This document |
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
Table 4: Rejection values of the RPL Status Table 4: Rejection values of the RPL Status
13. acknowledgments 13. Acknowledgments
The authors wish to thank Georgios Papadopoulos and Rahul Jadhav for The authors wish to thank Ines Robles, Georgios Papadopoulos and
their early reviews of and contributions to this document Rahul Jadhav for their reviews and contributions to this document.
14. Normative References 14. 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,
skipping to change at page 32, line 33 skipping to change at page 30, line 47
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
[AP-ND] Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, [AP-ND] Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and "Address Protected Neighbor Discovery for Low-power and
Lossy Networks", Work in Progress, Internet-Draft, draft- Lossy Networks", Work in Progress, Internet-Draft, draft-
ietf-6lo-ap-nd-20, 9 March 2020, ietf-6lo-ap-nd-23, 30 April 2020,
<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-20>. <https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-23>.
[USEofRPLinfo] [USEofRPLinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPI Robles, I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes and IPv6-in- Option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", Work in IPv6 encapsulation in the RPL Data Plane", Work in
Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-38, Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-38,
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-17, 30 October 2019, 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-17>. npdao-18>.
15. Informative References 15. 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,
skipping to change at page 34, line 7 skipping to change at page 32, line 17
January 2019, <https://www.rfc-editor.org/info/rfc8504>. January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[6BBR] Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 [6BBR] Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
Backbone Router", Work in Progress, Internet-Draft, draft- Backbone Router", Work in Progress, Internet-Draft, draft-
ietf-6lo-backbone-router-20, 23 March 2020, ietf-6lo-backbone-router-20, 23 March 2020,
<https://tools.ietf.org/html/draft-ietf-6lo-backbone- <https://tools.ietf.org/html/draft-ietf-6lo-backbone-
router-20>. router-20>.
Appendix A. Example Compression Appendix A. Example Compression
Figure 14 illustrates the case in Storing Mode where the packet is Figure 11 illustrates the case in Storing Mode where the packet is
received from the Internet, then the Root encapsulates the packet to received from the Internet, then the Root encapsulates the packet to
insert the RPI and deliver to the 6LR that is the parent and last hop insert the RPI and deliver to the 6LR that is the parent and last hop
to the final destination, which is not known to support [RFC8138]. to the final destination, which is not known to support [RFC8138].
+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
|11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP
|Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld |Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
<-4 bytes-> <- RFC 6282 -> <-4 bytes-> <- RFC 6282 ->
<- No RPL artifact ... <- No RPL artifact ...
Figure 14: Encapsulation to Parent 6LR in Storing Mode Figure 11: Encapsulation to Parent 6LR in Storing Mode
The difference with the example presented in Figure 19 of [RFC8138] The difference with the example presented in Figure 19 of [RFC8138]
is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the
compressed address of the 6LR as the destination address of the outer compressed address of the 6LR as the destination address of the outer
IPv6 header. In the original example the destination IP of the outer IPv6 header. In the original example the destination IP of the outer
header was elided and was implicitly the same address as the header was elided and was implicitly the same address as the
destination of the inner header. Type 1 was arbitrarily chosen, and destination of the inner header. Type 1 was arbitrarily chosen, and
the size of 0 denotes a single address in the SRH. the size of 0 denotes a single address in the SRH.
In Figure 14, the source of the IP-in-IP encapsulation is the Root, In Figure 11, the source of the IP-in-IP encapsulation is the Root,
so it is elided in the IP-in-IP 6LoRH. The destination is the parent so it is elided in the IP-in-IP 6LoRH. The destination is the parent
6LR of the destination of the inner packet so it cannot be elided. 6LR of the destination of the inner packet so it cannot be elided.
In Storing Mode, it is placed as the single entry in an SRH-6LoRH as If the DODAG is operated in Storing Mode, it is the single entry in
the first 6LoRH. Since there is a single entry so the SRH-6LoRH Size the SRH-6LoRH and the SRH-6LoRH Size is encoded as 0. The SRH-6LoRH
is 0. In this particular example, the 6LR address can be compressed is the first 6LoRH in the chain. In this particular example, the 6LR
to 2 bytes so a Type of 1 is used. It results that the total length address can be compressed to 2 bytes so a Type of 1 is used. It
of the SRH-6LoRH is 4 bytes. results that the total length of the SRH-6LoRH is 4 bytes.
In Non-Storing Mode, the encapsulation from the Root would be similar In Non-Storing Mode, the encapsulation from the Root would be similar
to that represented in Figure 14 with possibly more hops in the SRH- to that represented in Figure 11 with possibly more hops in the SRH-
6LoRH and possibly multiple SRH-6LoRHs if the various addresses in 6LoRH and possibly multiple SRH-6LoRHs if the various addresses in
the routing header are not compressed to the same format. Note that the routing header are not compressed to the same format. Note that
on the last hop to the parent 6LR, the RH3 is consumed and removed on the last hop to the parent 6LR, the RH3 is consumed and removed
from the compressed form, so the use of Non-Storing Mode vs. Storing from the compressed form, so the use of Non-Storing Mode vs. Storing
Mode is indistinguishable from the packet format. Mode is indistinguishable from the packet format.
The SRH-6LoRHs are followed by RPI-6LoRH and then the IP-in-IP 6LoRH. The SRH-6LoRHs are followed by RPI-6LoRH and then the IP-in-IP 6LoRH.
When the IP-in-IP 6LoRH is removed, all the 6LoRH Headers that When the IP-in-IP 6LoRH is removed, all the 6LoRH Headers that
precede it are also removed. The Paging Dispatch [RFC8025] may also precede it are also removed. The Paging Dispatch [RFC8025] may also
be removed if there was no previous Page change to a Page other than be removed if there was no previous Page change to a Page other than
 End of changes. 58 change blocks. 
291 lines changed or deleted 213 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/