draft-ietf-roll-unaware-leaves-22.txt   draft-ietf-roll-unaware-leaves-23.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550, 6775, 8505 (if approved) M. Richardson Updates: 6550, 6775, 8505 (if approved) M. Richardson
Intended status: Standards Track Sandelman Intended status: Standards Track Sandelman
Expires: 12 April 2021 9 October 2020 Expires: 14 May 2021 10 November 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-22 draft-ietf-roll-unaware-leaves-23
Abstract Abstract
This specification updates RFC6550, RFC6775, and RFC8505, to provide This specification updates RFC6550, RFC6775, and RFC8505, to provide
routing services to RPL Unaware Leaves that implement 6LoWPAN ND and routing services to RPL Unaware Leaves that implement 6LoWPAN ND and
the extensions therein. the extensions therein.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 April 2021. This Internet-Draft will expire on 14 May 2021.
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 18 skipping to change at page 2, line 18
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. References . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. References . . . . . . . . . . . . . . . . . . . . . . . 6
3. RPL External Routes and Dataplane Artifacts . . . . . . . . . 7 3. RPL External Routes and Dataplane Artifacts . . . . . . . . . 7
4. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 8 4. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 8
4.1. RFC 6775 Address Registration . . . . . . . . . . . . . . 8 4.1. RFC 6775 Address Registration . . . . . . . . . . . . . . 8
4.2. RFC 8505 Extended Address Registration . . . . . . . . . 8 4.2. RFC 8505 Extended Address Registration . . . . . . . . . 8
4.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. TID, "I" Field and Opaque Fields . . . . . . . . . . 9 4.2.2. TID, "I" Field and Opaque Fields . . . . . . . . . . 9
4.2.3. ROVR . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.3. ROVR . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 10 4.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 10
4.3.1. RFC 7400 Capability Indication Option . . . . . . . . 10 4.3.1. RFC 7400 Capability Indication Option . . . . . . . . 11
5. Requirements on the RPL-Unware Leaf . . . . . . . . . . . . . 11 5. Requirements on the RPL-Unware Leaf . . . . . . . . . . . . . 11
5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 11 5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 11
5.2. Support of IPv6 Encapsulation . . . . . . . . . . . . . . 12 5.2. Support of IPv6 Encapsulation . . . . . . . . . . . . . . 12
5.3. Support of the HbH Header . . . . . . . . . . . . . . . . 12 5.3. Support of the HbH Header . . . . . . . . . . . . . . . . 12
5.4. Support of the Routing Header . . . . . . . . . . . . . . 12 5.4. Support of the Routing Header . . . . . . . . . . . . . . 12
6. Enhancements to RFC 6550 . . . . . . . . . . . . . . . . . . 12 6. Enhancements to RFC 6550 . . . . . . . . . . . . . . . . . . 13
6.1. Updated RPL Target Option . . . . . . . . . . . . . . . . 13 6.1. Updated RPL Target Option . . . . . . . . . . . . . . . . 13
6.2. New Flag in the RPL DODAG Configuration Option . . . . . 14 6.2. New Flag in the RPL DODAG Configuration Option . . . . . 15
6.3. Updated RPL Status . . . . . . . . . . . . . . . . . . . 15 6.3. Updated RPL Status . . . . . . . . . . . . . . . . . . . 16
7. Enhancements to draft-ietf-roll-efficient-npdao . . . . . . . 16 7. Enhancements to draft-ietf-roll-efficient-npdao . . . . . . . 17
8. Enhancements to RFC 6775 and RFC8505 . . . . . . . . . . . . 17 8. Enhancements to RFC 6775 and RFC8505 . . . . . . . . . . . . 17
9. Protocol Operations for Unicast Addresses . . . . . . . . . . 17 9. Protocol Operations for Unicast Addresses . . . . . . . . . . 18
9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 18 9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 20 9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 21
9.2.1. Perspective of the 6LN Acting as RUL . . . . . . . . 20 9.2.1. Perspective of the 6LN Acting as RUL . . . . . . . . 21
9.2.2. Perspective of the 6LR Acting as Border Router . . . 22 9.2.2. Perspective of the 6LR Acting as Border Router . . . 23
9.2.3. Perspective of the RPL Root . . . . . . . . . . . . . 26 9.2.3. Perspective of the RPL Root . . . . . . . . . . . . . 27
9.2.4. Perspective of the 6LBR . . . . . . . . . . . . . . . 27 9.2.4. Perspective of the 6LBR . . . . . . . . . . . . . . . 28
10. Protocol Operations for Multicast Addresses . . . . . . . . . 27 10. Protocol Operations for Multicast Addresses . . . . . . . . . 28
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 11. Security Considerations . . . . . . . . . . . . . . . . . . . 30
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
12.1. Fixing the Address Registration Option Flags . . . . . . 31 12.1. Fixing the Address Registration Option Flags . . . . . . 32
12.2. Resizing the ARO Status values . . . . . . . . . . . . . 31 12.2. Resizing the ARO Status values . . . . . . . . . . . . . 32
12.3. New DODAG Configuration Option Flag . . . . . . . . . . 31 12.3. New RPL DODAG Configuration Option Flag . . . . . . . . 32
12.4. RPL Target Option Registry . . . . . . . . . . . . . . . 31 12.4. RPL Target Option Registry . . . . . . . . . . . . . . . 32
12.5. New Subregistry for the RPL Non-Rejection Status 12.5. New Subregistry for RPL Non-Rejection Status values . . 33
values . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.6. New Subregistry for RPL Rejection Status values . . . . 33
12.6. New Subregistry for the RPL Rejection Status values . . 32 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 14. Normative References . . . . . . . . . . . . . . . . . . . . 34
14. Normative References . . . . . . . . . . . . . . . . . . . . 33 15. Informative References . . . . . . . . . . . . . . . . . . . 36
15. Informative References . . . . . . . . . . . . . . . . . . . 35 Appendix A. Example Compression . . . . . . . . . . . . . . . . 37
Appendix A. Example Compression . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37
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 44 skipping to change at page 3, line 43
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.
RPL can be deployed in conjunction with IPv6 Neighbor Discovery (ND) RPL can be deployed in conjunction with 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- (NBMA) Multi-Link subnet. reachability within a Non-Broadcast Multiple-Access (NBMA) Multi-Link
subnet.
In that mode, IPv6 addresses are advertised individually as Host In that mode, IPv6 addresses are advertised individually as Host
routes. Some nodes may act as Routers and participate in the routes. Some nodes may act as Routers and participate in 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, an IPv6 Host acting as Hosts in the data-plane. In [RFC6550] terms, an IPv6 Host
[RFC8504] that is reachable over the RPL network is called a Leaf. [RFC8504] that is reachable over the RPL network is called a Leaf.
[USEofRPLinfo] introduces the terms RPL-Aware-Leaf (RAL) and RPL- [USEofRPLinfo] introduces the terms RPL-Aware-Leaf (RAL) and RPL-
Unaware Leaf (RUL). A RAL is a Leaf that injects Host routes in RPL Unaware Leaf (RUL). A RAL is a Leaf that injects Host routes in RPL
to manage the reachability of its IPv6 addresses. Conversely, a RUL to manage the reachability of its IPv6 addresses. Conversely, a RUL
does not participate to RPL and cannot inject routes. Section 5 does not participate to RPL and cannot inject routes. Section 5
details a Host-to-Router interface that the RUL needs to implement to details a Host-to-Router interface that the RUL needs to implement to
advertise its IPv6 addresses to a Router that supports this advertise its IPv6 addresses to a Router that supports this
specification. The document specifies how the Router injects those specification. This document specifies how the Router injects those
addresses as Host routes in the RPL network on behalf of the RUL. addresses as Host routes in the RPL network on behalf of the RUL.
This specification leverages the Address Registration mechanism This specification leverages the Address Registration mechanism
defined in 6LoWPAN ND to enable a 6LoWPAN Node (6LN) acting as a RUL defined in 6LoWPAN ND to enable a 6LoWPAN Node (6LN) acting as a RUL
to interface with a 6LoWPAN Router (6LR) that is RPL-Aware router, to interface with a 6LoWPAN Router (6LR) that is also an RPL-Aware
and request that the router injects a Host route for the Registered router, and request that this router inject a Host route for the
Address in RPL on its behalf. A RUL may be unable to participate Registered Address in RPL on its behalf. A RUL may be unable to
because it is very energy-constrained, or because it is unsafe to let participate because it is very energy-constrained, code-space
it inject routes in RPL, in which case using 6LowPAN ND as the constrained, or because it would be unsafe to let it inject routes in
interface for the RUL limits the surface of the possible attacks and RPL. Using 6LowPAN ND as the interface for the RUL limits the
optionally protects the address ownership. surface of the possible attacks and optionally protects the address
ownership.
The RPL Non-Storing Mode mechanism is used to extend the routing The RPL Non-Storing Mode mechanism is used to extend the routing
state with connectivity to the RULs even when the DODAG is operated state with connectivity to the RULs even when the DODAG is operated
in Storing Mode. The unicast packet forwarding operation by the 6LR in Storing Mode. The unicast packet forwarding operation by the 6LR
serving a RUL is described in section 4.1 of [USEofRPLinfo]. serving a RUL is described in section 4.1 of [USEofRPLinfo].
Examples of possible RULs include lightly powered sensors such as Examples of possible RULs include lightly powered sensors such as
window smash sensor (alarm system), and kinetically powered light window smash sensor (alarm system), and kinetically powered light
switches. Other applications of this specification may include a switches. Other applications of this specification may include a
smart grid network that controls appliances - such as washing smart grid network that controls appliances - such as washing
skipping to change at page 4, line 47 skipping to change at page 5, line 5
This document is organized as follows: This document is organized as follows:
* Section 3 and Section 4 present salient aspects of RPL and 6LoWPAN * Section 3 and Section 4 present salient aspects of RPL and 6LoWPAN
ND, respectively, that are leveraged in this specification to ND, respectively, that are leveraged in this specification to
provide connectivity to a RUL across a RPL network. provide connectivity to a RUL across a RPL network.
* Section 5 lists the expectations that a RUL needs to match in * Section 5 lists the expectations that a RUL needs to match in
order to be served by a RPL router that complies with this order to be served by a RPL router that complies with this
specification. specification.
* Section 6, Section 7, and Section 8 present the changes made to * Section 6 presents the changes made to [RFC6550]; a new behavior
[RFC6550], [EFFICIENT-NPDAO], [RFC6775] and [RFC8505]. is introduced whereby the 6LR advertises the 6LN's addresses in a
RPL DAO message based on the ND registration by the 6LN, and the
RPL root performs the EDAR/EDAC exchange with the 6LBR on behalf
of the 6LR; modifications are introduced to some RPL options and
to the RPL Status to facilitate the integration of the protocols.
* Section 7 presents the changes made to [EFFICIENT-NPDAO]; the use
of the DCO message is extended to the Non-Storing MOP to report
asynchronous issues from the Root to the 6LR.
* Section 8 presents the changes made to [RFC6775] and [RFC8505];
The range of the ND status codes is reduced down to 64 values, and
the remaining bits in the original status field are now reserved.
* Section 9 and Section 10 present the operation of this * Section 9 and Section 10 present the operation of this
specification for unicast and multicast flows, respectively, and specification for unicast and multicast flows, respectively, and
Section 11 presents associated security considerations. Section 11 presents associated security considerations.
2. Terminology 2. Terminology
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 7, line 32 skipping to change at page 7, line 43
does not add to the amount of state that must be maintained in those does not add to the amount of state that must be maintained in those
Routers. A RUL is an example of a destination that is reachable via Routers. A RUL is an example of a destination that is reachable via
an external route that happens to be also a Host route. an external route that happens to be also a Host route.
The RPL data packets always carry a Hop-by-Hop Header to transport a The RPL data packets always carry a Hop-by-Hop Header to transport a
RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates
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 and 8 of [USEofRPLinfo] for details). RUL (see sections 7 and 8 of [USEofRPLinfo] for details). If the
packet from the RUL has an RPI, the 6LR as a RPL border router SHOULD
rewrite the RPI to indicate the selected Instance and set the flags,
but it does not need to encapsulate the packet.
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]. Appendix A presents an example compressed format for a [RFC8138]. Appendix A 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 an SRH in a Non-Storing Mode DODAG. [USEofRPLinfo] expects the and an SRH in a Non-Storing Mode DODAG. [USEofRPLinfo] expects the
skipping to change at page 9, line 50 skipping to change at page 10, line 16
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 registering an of ownership to prevent a rogue third party from registering an
address that is already owned and enable the 6LR to block traffic address that is already owned. The use of ROVR field enable the 6LR
that is not sourced at a owned address. to block traffic that is not sourced at an owned address.
This specification does not address how the protection by [AP-ND] This specification does not address how the protection by [AP-ND]
could be extended for use in RPL. On the other hand, it adds the could be extended for use in RPL. On the other hand, it adds the
ROVR to the DAO to build the proxied EDAR at the Root (see ROVR to the DAO to build the proxied EDAR at the Root (see
Section 6.1), which means that nodes that are aware of the Host route Section 6.1), which means that nodes that are aware of the Host route
are also aware of the ROVR associated to the Target Address. are also aware of the ROVR associated to the Target Address.
4.3. RFC 8505 Extended DAR/DAC 4.3. RFC 8505 Extended DAR/DAC
[RFC8505] updates the DAR/DAC messages into the Extended DAR/DAC to [RFC8505] updates the DAR/DAC messages into the Extended DAR/DAC to
skipping to change at page 11, line 51 skipping to change at page 12, line 22
that provide routing services. The RUL needs to register to all the that provide routing services. The RUL needs to register to all the
6LRs from which it desires routing services. 6LRs from which it desires routing services.
Parallel Address Registrations to several 6LRs should be performed in Parallel Address Registrations to several 6LRs should be performed in
a rapid sequence, using the same EARO for the same Address. Gaps a rapid sequence, using the same EARO for the same Address. Gaps
between the Address Registrations will invalidate some of the routes between the Address Registrations will invalidate some of the routes
till the Address Registration finally shows on those routes. till the Address Registration finally shows on those routes.
[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
needs to support both cases and should refrain from using the address needs to support both cases and refrain from using the address when
when the Status Value indicates a rejection (see Section 6.3). the Status value indicates a rejection (see Section 6.3).
5.2. Support of IPv6 Encapsulation 5.2. Support of IPv6 Encapsulation
Section 2.1 of [USEofRPLinfo] defines the rules for tunneling either Section 2.1 of [USEofRPLinfo] defines the rules for tunneling either
to the final destination (e.g., a RUL) or to its attachment Router to the final destination (e.g., a RUL) or to its attachment Router
(designated as 6LR). To terminate the IP-in-IP tunnel, the RUL, as (designated as 6LR). To terminate the IP-in-IP tunnel, the RUL, as
an IPv6 Host, must be able to decapsulate the tunneled packet and an IPv6 Host, must be able to decapsulate the tunneled packet and
either drop the inner packet if it is not the final destination, or either drop the inner packet if it is not the final destination, or
pass it to the upper layer for further processing. Unless it is pass it to the upper layer for further processing. Unless it is
aware by other means that the RUL can handle IP-in-IP properly, which aware by other means that the RUL can handle IP-in-IP properly, which
skipping to change at page 13, line 23 skipping to change at page 13, line 40
This specification defines the new "Root Proxies EDAR/EDAC" (P) flag This specification defines the new "Root Proxies EDAR/EDAC" (P) flag
and encodes it in one of these reserved flags of the RPL DODAG and encodes it in one of these reserved flags of the RPL DODAG
Configuration option, more in Section 6.2. Configuration option, more in Section 6.2.
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
to carry the EARO Status defined for 6LoWPAN ND in RPL DAO and DCO to carry the EARO Status defined for 6LoWPAN ND in RPL DAO and DCO
messages, embedded in a RPL Status, more in Section 6.3. messages, embedded in a RPL Status, more in Section 6.3.
Section 12 of [RFC6550] details the RPL support for multicast flows
when the RPLInstance is operated in the MOP of 3 ("Storing Mode of
Operation with multicast support"). This specification extends the
RPL Root operation to proxy-relay the MLDv2 [RFC3810] operation
between the RUL and the 6LR, more in Section 10.
6.1. Updated RPL Target Option 6.1. Updated RPL Target Option
This specification updates the RPL Target Option to transport the This specification updates the RPL Target Option to transport the
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 IPv6 address of the advertising node, in which case the contains the IPv6 address of the advertising node, in which case the
length of the Target Prefix field is 128 bits regardless of the value length of the Target Prefix field is 128 bits regardless of the value
of the Prefix Length field. If the 'F' flag is reset, the Target of the Prefix Length field. If the 'F' flag is reset, the Target
skipping to change at page 13, line 45 skipping to change at page 14, line 21
bits are reserved and set to 0 per section 6.7.7 of [RFC6550]. bits are reserved and set to 0 per 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]). The ROVR Size field is taken message (see table 4 of [RFC8505]). The ROVR Size field is taken
from the flags field, which is an update to the RPL Target Option from the flags field, which is an update to the RPL Target Option
Flags IANA registry. Flags IANA registry.
The updated format is illustrated in Figure 3. It is backward The updated format is illustrated in Figure 3. It is backward
compatible with the Target Option in [RFC6550]. It SHOULD be used as compatible with the Target Option in [RFC6550]. It is recommended
a replacement in new implementations in all MOPs in preparation for that the updated format be used as a replacement in new
upcoming Route Ownership Validation mechanisms based on the ROVR, implementations in all MOPs in preparation for upcoming Route
unless the device or the network is so constrained that this is not Ownership Validation mechanisms based on the ROVR, unless the device
feasible. or the network is so constrained that this is not feasible.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x05 | Option Length |ROVRsz |F|Flags| Prefix Length | | Type = 0x05 | Option Length |ROVRsz |F|Flags| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Target Prefix (Variable Length) | | Target Prefix (Variable Length) |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... Registration Ownership Verifier (ROVR) ... ... Registration Ownership Verifier (ROVR) ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Updated Target Option Figure 3: Updated Target Option
New fields: New fields:
ROVRsz (ROVR Size): Indicates the Size of the ROVR. It MAY be 1, 2, ROVRsz (ROVR Size): Indicates the Size of the ROVR. It SHOULD be 1,
3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits, 2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits,
respectively. A value if 0 thus denotes a legacy Target Option. respectively. If a legacy Target Option is used, then the value
must remain 0, as specified in [RFC6550]. In case of a value
above 4, the size of the ROVR is undetermined and this node cannot
validate the ROVR; an implementation SHOULD propagate the whole
Target Option upwards as received to enable the verification by an
ancestor that would support the upgraded ROVR.
F: 1-bit flag. Set to indicate that Target Prefix field contains an F: 1-bit flag. Set to indicate that Target Prefix field contains
address of prefix advertiser in full. the complete (128 bit) IPv6 address of the advertising node.
Registration Ownership Verifier (ROVR): This is the same field as in Registration Ownership Verifier (ROVR): This is the same field as in
the EARO, see [RFC8505] the EARO, see [RFC8505]
6.2. New Flag in the RPL DODAG Configuration Option 6.2. New Flag in the RPL DODAG Configuration Option
The DODAG Configuration Option is defined in Section 6.7.6 of The DODAG Configuration Option is defined in Section 6.7.6 of
[RFC6550]. Its purpose is extended to distribute configuration [RFC6550]. Its purpose is extended to distribute configuration
information affecting the construction and maintenance of the DODAG, information affecting the construction and maintenance of the DODAG,
as well as operational parameters for RPL on the DODAG, through the as well as operational parameters for RPL on the DODAG, through the
DODAG. As shown in Figure 4, the Option was originally designed with DODAG. This Option was originally designed with 4 bit positions
4 bit positions reserved for future use as Flags. reserved for future use as Flags.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |Opt Length = 14| |P| | |A| ... | | Type = 0x04 |Opt Length = 14| |P| | |A| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
<- Flags -> |4 bits |
Figure 4: DODAG Configuration Option (Partial View) Figure 4: DODAG Configuration Option (Partial View)
This specification defines a new flag "Root Proxies EDAR/EDAC" (P). This specification defines a new flag "Root Proxies EDAR/EDAC" (P).
The 'P' bit is encoded in position 1 of the reserved Flags in the The 'P' flag is encoded in bit position 1 of the reserved Flags in
DODAG Configuration Option (counting from bit 0 as the most the DODAG Configuration Option (counting from bit 0 as the most
significant bit) and set to 0 in legacy implementations as specified significant bit) and it is set to 0 in legacy implementations as
respectively in Sections 20.14 and 6.7.6 of [RFC6550]. specified respectively in Sections 20.14 and 6.7.6 of [RFC6550].
The 'P' bit is set to indicate that the Root performs the proxy The 'P' flag is set to indicate that the Root performs the proxy
operation, which implies that it supports this specification and the operation, which implies that it supports this specification and the
updated RPL Target Option (see Section 6.1). updated RPL Target Option (see Section 6.1).
Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the
definition of the Flags applies to Mode of Operation (MOP) values definition of the Flags applies to Mode of Operation (MOP) values
zero (0) to six (6) only. For a MOP value of 7, the Root is expected zero (0) to six (6) only. For a MOP value of 7, the implementation
to perform the proxy operation by default. MUST consider that the Root performs the proxy operation.
The RPL DODAG Configuration Option is typically placed in a DODAG The RPL DODAG Configuration Option is typically placed in a DODAG
Information Object (DIO) message. The DIO message propagates down Information Object (DIO) message. The DIO message propagates down
the DODAG to form and then maintain its structure. The DODAG the DODAG to form and then maintain its structure. The DODAG
Configuration Option is copied unmodified from parents to children. Configuration Option is copied unmodified from parents to children.
[RFC6550] states that "Nodes other than the DODAG Root MUST NOT [RFC6550] states that "Nodes other than the DODAG Root MUST NOT
modify this information when propagating the DODAG Configuration modify this information when propagating the DODAG Configuration
option". Therefore, a legacy parent propagates the T Flag as set by option". Therefore, a legacy parent propagates the 'P' Flag as set
the Root, and when the T Flag is set, it is transparently flooded to by the Root, and when the 'P' Flag is set, it is transparently
all the nodes in the DODAG. flooded to all the nodes in the DODAG.
6.3. Updated RPL Status 6.3. 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 |
skipping to change at page 16, line 5 skipping to change at page 16, line 27
| 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, see section The 6LoWPAN ND Status was defined for use in the EARO, see section
4.1 of [RFC8505]. This specification enables to carry the 6LoWPAN ND 4.1 of [RFC8505]. This specification enables to carry the 6LoWPAN ND
Status values in RPL DAO and DCO messages, embedded in the RPL Status Status values in RPL DAO and DCO messages, embedded in the RPL Status
field. field.
To achieve this, the range of the EARO Status values is reduced to To achieve this, the range of the ARO/EARO Status values is reduced
0-63, which updates the IANA registry created for [RFC6775]. This to 0-63, which updates the IANA registry created for [RFC6775]. This
reduction ensures that the values fit within a RPL Status as shown in reduction ensures that the values fit within a RPL Status as shown in
Figure 5. See Section 12.2, Section 12.5, and Section 12.6 for the Figure 5. See Section 12.2, Section 12.5, and Section 12.6 for the
respective IANA declarations. respective IANA declarations.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|A|StatusValue| |E|A|StatusValue|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 5: RPL Status Format Figure 5: RPL Status Format
This specification updates the RPL Status with subfields as indicated This specification updates the RPL Status with subfields as indicated
below: below:
E: 1-bit flag. Set to indicate a rejection. When not set, a Status E: 1-bit flag. Set to indicate a rejection. When not set, a Status
Value of 0 indicates Success/Unqualified acceptance and other value of 0 indicates Success/Unqualified acceptance and other
values indicate "not an outright rejection" as per RFC 6550. values indicate "not an outright rejection" as per RFC 6550.
A: 1-bit flag. Indicates the type of the RPL Status Value. A: 1-bit flag. Indicates the type of the RPL 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 for RPL. the 'A' flag is not set, the Status value is defined for RPL.
When building a DCO or a DAO-ACK message upon an IPv6 ND NA or a EDAC When building a DCO or a DAO-ACK message upon an IPv6 ND NA or a EDAC
message, the RPL Root MUST copy the 6LoWPAN ND Status Code unchanged message, the RPL Root MUST copy the 6LoWPAN ND status code unchanged
in the RPL Status Value and set the 'A' flag. The RPL Root MUST set in the RPL Status value and set the 'A' flag. The RPL Root MUST set
the 'E' flag for all rejection and unknown Status Codes. The Status the 'E' flag for all rejection and unknown status codes. The status
Codes in range 1-10 [RFC8505] are all considered rejections. codes in the 1-10 range [RFC8505] are all considered rejections.
Reciprocally, upon a DCO or a DAO-ACK message from the RPL Root with Reciprocally, upon a DCO or a DAO-ACK message from the RPL Root with
a RPL Status that has the 'A' flag set, the 6LR MUST copy the RPL a RPL Status that has the 'A' flag set, the 6LR MUST copy the RPL
Status Value unchanged in the Status field of the EARO when Status value unchanged in the Status field of the EARO when
generating an NA to the RUL. generating an NA to the RUL.
7. Enhancements to draft-ietf-roll-efficient-npdao 7. Enhancements to draft-ietf-roll-efficient-npdao
[EFFICIENT-NPDAO] defines the DCO message for RPL Storing Mode only, [EFFICIENT-NPDAO] defines the DCO message for RPL Storing Mode only,
with a link-local scope. All nodes in the RPL network are expected with a link-local scope. All nodes in the RPL network are expected
to support the specification since the message in processed hop by to support the specification since the message is processed hop by
hop along the path this is being cleaned up. hop along the path that is being cleaned up.
This specification extends the use of the DCO message to the Non- This specification extends the use of the DCO message to the Non-
Storing MOP, whereby the DCO is sent end-to-end by the Root directly Storing MOP, whereby the DCO is sent end-to-end by the Root directly
to the RAN that injected the DAO message for the considered target. to the RAN that injected the DAO message for the considered target.
In that case, intermediate nodes do not need to support In that case, intermediate nodes do not need to support
[EFFICIENT-NPDAO]; they forward the DCO message as a plain IPv6 [EFFICIENT-NPDAO]; they forward the DCO message as a plain IPv6
packet between the Root and the RAN. packet between the Root and the RAN.
This specification leverages the Non-Storing DCO between the Root and This specification leverages the Non-Storing DCO between the Root and
the 6LR that serves as attachment Router for a RUL. A 6LR and a Root the 6LR that serves as attachment Router for a RUL. A 6LR and a Root
that support this specification MUST implement the Non-Storing DCO. that support this specification MUST implement the Non-Storing DCO.
8. Enhancements to RFC 6775 and RFC8505 8. Enhancements to RFC 6775 and RFC8505
This document updates [RFC6775] and [RFC8505] to reduce the range of This document updates [RFC6775] and [RFC8505] to reduce the range of
the ND Status Codes down to 64 values. the ND status codes down to 64 values. The two most significant
(leftmost) bits if the original ND status field are now reserved,
they MUST be set to zero by the sender and ignored by the receiver.
This document also changes the behavior of a 6LR acting as RPL Router This document also changes the behavior of a 6LR acting as RPL Router
and of a 6LN acting as RUL in the 6LoWPAN ND Address Registration as and of a 6LN acting as RUL in the 6LoWPAN ND Address Registration as
follows: follows:
* If the RPL Root advertises the capability to proxy the EDAR/EDAC * If the RPL Root advertises the capability to proxy the EDAR/EDAC
exchange to the 6LBR, the 6LR refrains from sending the keep-alive exchange to the 6LBR, the 6LR refrains from sending the keep-alive
EDAR message. If it is separated from the 6LBR, the Root EDAR message. If it is separated from the 6LBR, the Root
regenerates the EDAR message to the 6LBR periodically, upon a DAO regenerates the EDAR message to the 6LBR periodically, upon a DAO
message that signals the liveliness of the address. message that signals the liveliness of the address.
* The use of the R Flag is extended to the NA(EARO) to confirm * The use of the R Flag is extended to the NA(EARO) to confirm
whether the route was installed. whether the route was installed.
9. Protocol Operations for Unicast Addresses 9. Protocol Operations for Unicast Addresses
The description below assumes that the Root sets the 'P' bit in the The description below assumes that the Root sets the 'P' flag in the
DODAG Configuration Option and performs the EDAR proxy operation. DODAG Configuration Option and performs the EDAR proxy operation.
If the 'P' bit is reset, the 6LR MUST generate the periodic EDAR If the 'P' flag is reset, the 6LR MUST generate the periodic EDAR
messages and process the returned status as specified in [RFC8505]. messages and process the returned status as specified in [RFC8505].
If the EDAC indicates success, the rest of the flow takes place as If the EDAC indicates success, the rest of the flow takes place as
presented but without the proxied EDAR/EDAC exchange. presented but without the proxied EDAR/EDAC exchange.
Section 9.1 provides an overview of the route injection in RPL, Section 9.1 provides an overview of the route injection in RPL,
whereas Section 9.2 offers more details from the perspective of the whereas Section 9.2 offers more details from the perspective of the
different nodes involved in the flow. different nodes involved in the flow.
9.1. General Flow 9.1. General Flow
skipping to change at page 18, line 24 skipping to change at page 19, line 5
In a RPL network where the function is enabled, refreshing the state In a RPL network where the function is enabled, refreshing the state
in the 6LBR is the responsibility of the Root. Consequently, only in the 6LBR is the responsibility of the Root. Consequently, only
addresses that are injected in RPL will be kept alive at the 6LBR by addresses that are injected in RPL will be kept alive at the 6LBR by
the RPL Root. Since RULs are advertised using Non-Storing Mode, the the RPL Root. Since RULs are advertised using Non-Storing Mode, the
DAO message flow and the keep alive EDAR/EDAC can be nested within DAO message flow and the keep alive EDAR/EDAC can be nested within
the Address (re)Registration flow. Figure 6 illustrates that, for the Address (re)Registration flow. Figure 6 illustrates that, for
the first Registration, both the DAD and the keep-alive EDAR/EDAC the first Registration, both the DAD and the keep-alive EDAR/EDAC
exchanges happen in the same sequence. exchanges happen in the same sequence.
6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR 6LN/RUL 6LR <6LR*> Root 6LBR
| | | | | | | |
| NS(EARO) | | | |<------ND------>|<----RPL----->|<-------ND-------->|
|--------------->| | | |<----------------ND-------------->|
| | Extended DAR | | | | |
| |--------------------------------->| | NS(EARO) | | |
| | | |--------------->| |
| | Extended DAC | | | Extended DAR |
| |<---------------------------------| | |--------------------------------->|
| | DAO | | | | |
| |------------->| | | | Extended DAC |
| | | EDAR | | |<---------------------------------|
| | |------------------>| | | DAO | |
| | | EDAC | | |------------->| |
| | |<------------------| | | | EDAR |
| | DAO-ACK | | | | |------------------>|
| |<-------------| | | | | EDAC |
| NA(EARO) | | | | | |<------------------|
|<---------------| | | | | DAO-ACK | |
| | | | | |<-------------| |
| NA(EARO) | | |
|<---------------| | |
| | | |
Figure 6: First RUL Registration Flow Figure 6: First RUL Registration Flow
This flow requires that the lifetimes and sequence counters in This flow requires that the lifetimes and sequence counters in
6LoWPAN ND and RPL are aligned. 6LoWPAN ND and RPL are aligned.
ITo achieve this, the Path Sequence and the Path Lifetime in the DAO To achieve this, the Path Sequence and the Path Lifetime in the DAO
message are taken from the Transaction ID and the Address message are taken from the Transaction ID and the Address
Registration lifetime in the NS(EARO) message from the 6LN. Registration lifetime in the NS(EARO) message from the 6LN.
On the first Address Registration, illustrated in Figure 6 for RPL On the first Address Registration, illustrated in Figure 6 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. Otherwise, the 6LR created, and the address is not injected in RPL. Otherwise, the 6LR
creates an NCE and injects the Registered Address in the RPL routing creates an NCE and injects the Registered Address in the RPL routing
using a DAO/DAO-ACK exchange with the RPL DODAG Root. using a DAO/DAO-ACK exchange with the RPL DODAG Root.
skipping to change at page 19, line 38 skipping to change at page 20, line 25
| | DAO-ACK | | | | DAO-ACK | |
| |<-------------| | | |<-------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |<---------------| | |
Figure 7: Next RUL Registration Flow Figure 7: Next RUL Registration Flow
This is what causes the RPL Root to refresh the state in the 6LBR, This is what causes the RPL Root to refresh the state in the 6LBR,
using an EDAC message. In case of an error in the proxied EDAR flow, using an EDAC message. In case of an error in the proxied EDAR flow,
the error is returned in the DAO-ACK using a RPL Status with the 'A' the error is returned in the DAO-ACK using a RPL Status with the 'A'
flag set that imbeds a 6LoWPAN Status Value as discussed in flag set that imbeds a 6LoWPAN Status value as discussed in
Section 6.3. Section 6.3.
The 6LR may receive a requested DAO-ACK after it received an The 6LR may receive a requested DAO-ACK after it received an
asynchronous DCO, but the negative Status in the DCO supersedes a asynchronous DCO, but the negative Status in the DCO supersedes a
positive Status in the DAO-ACK regardless of the order in which they positive Status in the DAO-ACK regardless of the order in which they
are received. Upon the DAO-ACK - or the DCO if one arrives first - are received. Upon the DAO-ACK - or the DCO if one arrives first -
the 6LR responds to the RUL with an NA(EARO). the 6LR responds to the RUL with an NA(EARO).
An issue may be detected later, e.g., the address moves to a An issue may be detected later, e.g., the address moves to a
different DODAG with the 6LBR attached to a different 6LoWPAN different DODAG with the 6LBR attached to a different 6LoWPAN
Backbone Router (6BBR), see Figure 5 in section 3.3 of [6BBR]. The Backbone Router (6BBR), see Figure 5 in section 3.3 of [6BBR]. The
6BBR may send a negative ND status, e.g., in an asynchronous NA(EARO) 6BBR may send a negative ND status, e.g., in an asynchronous NA(EARO)
to the 6LBR. to the 6LBR.
[6BBR] expects that the 6LBR is collocated with the RPL Root, but if [6BBR] expects that the 6LBR is collocated with the RPL Root, but if
not, the 6LBR MUST forward the Status Code to the originator of the not, the 6LBR MUST forward the status code to the originator of the
EDAR, either the 6LR or the RPL Root that proxies for it. The ND EDAR, either the 6LR or the RPL Root that proxies for it. The ND
Status Code is mapped in a RPL Status Value by the RPL Root, and then status code is mapped in a RPL Status value by the RPL Root, and then
back by the 6LR. back by the 6LR.
Figure 8 illustrates this in the case where the 6LBR and the Root are Figure 8 illustrates this in the case where the 6LBR and the Root are
not collocated, and the Root proxies the EDAR messages. not collocated, and the Root proxies the EDAR messages.
6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR <-ND-> 6BBR 6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR <-ND-> 6BBR
| | | | | | | | | |
| | | | NA(EARO) | | | | | NA(EARO) |
| | | |<------------| | | | |<------------|
| | | EDAC | | | | | EDAC | |
skipping to change at page 21, line 18 skipping to change at page 22, line 9
[RFC6775], to refresh the NCE before the lifetime indicated in [RFC6775], to refresh the NCE before the lifetime indicated in
the EARO expires. It MUST set the T Flag. The TID is the EARO expires. It MUST set the T Flag. The TID is
incremented each time and wraps in a lollipop fashion (see incremented each time and wraps in a lollipop fashion (see
section 5.2.1 of [RFC8505], which is fully compatible with section 5.2.1 of [RFC8505], which is fully compatible with
section 7.2 of [RFC6550]). 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, with the same EARO for all of the parallel Address Registrations, with the
exception of the Registration Lifetime field and the setting of exception of the Registration Lifetime field and the setting of
the R flag that may differ. The 6LN SHOULD send the NS(EARO), if the R flag that may differ. The 6LN may cancel a subset of its
any, that maintain a registration active (i.e., with a non-zero registrations, or transfer a registration from one or more old
Registration Lifetime) and ensure that one succeeds before it 6LR(s) to one or more new 6LR(s). To do so, the 6LN sends a
sends an NS(EARO) that terminates another registration, to avoid series of NS(EARO) messages, all with the same TID, with a zero
the churn related to transient route invalidation in the RPL Registration Lifetime to the old 6LR(s) and with a non-zero
network. Registration Lifetime to the new 6LR(s). In that process, the
6LN SHOULD send the NS(EARO) with a non-zero Registration
Lifetime and ensure that at least one succeeds before it sends an
NS(EARO) that terminates another registration. This avoids the
churn related to transient route invalidation in the RPL network
above the common parent of the involved 6LRs.
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 its registration(s) for which it the R Flag in the EARO of its registration(s) for which it
requires routing services. If the R Flag is not echoed in the requires routing services. If the R Flag is not echoed in the
NA, the RUL SHOULD attempt to use another 6LR. The RUL SHOULD NA, the RUL SHOULD attempt to use another 6LR. The RUL SHOULD
send the registration(s) with the R Flag set and ensure that one ensure that one registration succeeds before resetting the R
succeeds before it sends the registrations with the flag reset. Flag. In case of a conflict with the preceding rule on lifetime,
In case of a conflict with the preceding rule on lifetime, the the rule on lifetime has precedence.
rule on lifetime has precedence.
5. The 6LN may use any of the 6LRs to which it registered as the 5. The 6LN may use any of the 6LRs to which it registered as the
default gateway. Using a 6LR to which the 6LN is not registered default gateway. Using a 6LR to which the 6LN is not registered
may result in packets dropped at the 6LR by a Source Address may result in packets dropped at the 6LR by a Source Address
Validation function (SAVI) [RFC7039] so it is not recommended. Validation function (SAVI) [RFC7039] so it is not recommended.
Even without support for RPL, the RUL may be configured with an Even without support for RPL, the RUL may be configured with an
opaque value to be provided to the routing protocol. If the RUL has opaque value to be provided to the routing protocol. If the RUL has
knowledge of the RPL Instance the packet should be injected into, knowledge of the RPL Instance the packet should be injected into,
then it SHOULD set the Opaque field in the EARO to the RPLInstanceID, then it SHOULD set the Opaque field in the EARO to the RPLInstanceID,
else it MUST leave the Opaque field to zero. else it MUST leave the Opaque field to zero.
Regardless of the setting of the Opaque field, the 6LN MUST set the Regardless of the setting of the Opaque field, the 6LN MUST set the
"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 minimal awareness of but it may do so. For instance, if the RUL has minimal awareness of
the RPL Instance then it can build an RPI. A RUL that places an RPI 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 Instance in a data packet SHOULD indicate the RPLInstanceID of the RPL
where the packet should be forwarded. All the flags and the Rank Instance where the packet should be forwarded. It is up to the 6LR
field are set to zero as specified by section 11.2 of [RFC6550]. (e.g., by policy) to use the RPLInstanceID information provided by
the RUL or rewrite it to the selected RPLInstanceID for forwarding
inside the RPL domain. All the flags and the Rank field are set to
zero as specified by section 11.2 of [RFC6550].
9.2.2. Perspective of the 6LR Acting as Border Router 9.2.2. Perspective of the 6LR Acting as Border Router
As prescribed by [RFC8505], the 6LR generates an EDAR message upon As prescribed by [RFC8505], the 6LR generates an EDAR message upon
reception of a valid NS(EARO) message for the registration of a new reception of a valid NS(EARO) message for the registration of a new
IPv6 address by a 6LN. If the initial EDAR/EDAC exchange succeeds, IPv6 address by a 6LN. If the initial EDAR/EDAC exchange succeeds,
then the 6LR installs an NCE for the Registration Lifetime. For the then the 6LR installs an NCE for the Registration Lifetime. For the
registration refreshes, if the RPL Root has indicated that it proxies registration refreshes, if the RPL Root has indicated that it proxies
the keep-alive EDAR/EDAC exchange with the 6LBR (see Section 6), the the keep-alive EDAR/EDAC exchange with the 6LBR (see Section 6), the
6LR MUST refrain from sending the keep-alive EDAR. 6LR MUST refrain from sending the keep-alive EDAR.
skipping to change at page 22, line 45 skipping to change at page 23, line 38
As described in [RFC8505], if the "I" field is zero, then the Opaque As described in [RFC8505], if the "I" field is zero, then the Opaque
field is expected to carry the RPLInstanceID suggested by the 6LN; field is expected to carry the RPLInstanceID suggested by the 6LN;
otherwise, there is no suggested Instance. If the 6LR participates otherwise, there is no suggested Instance. If the 6LR participates
in the suggested RPL Instance, then the 6LR MUST use that RPL in the suggested RPL Instance, then the 6LR MUST use that RPL
Instance for the Registered Address. Instance for the Registered Address.
If there is no suggested RPL Instance or else if the 6LR does not If there is no suggested RPL Instance or else if the 6LR does not
participate to the suggested Instance, it is expected that the participate to the suggested Instance, it is expected that the
packets coming from the 6LN "can unambiguously be associated to at packets coming from the 6LN "can unambiguously be associated to at
least one RPL Instance" [RFC6550] by the 6LR. least one RPL Instance" [RFC6550] by the 6LR, e.g., using a policy
that maps the 6-tuple into an Instance.
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 the Target Prefix in the 1. The Registered Address is signaled as the Target Prefix in the
updated Target Option in the DAO message; the Prefix Length is updated Target Option in the DAO message; the Prefix Length is
set to 128 but the 'F' flag is not set since the advertiser is set to 128 but the 'F' flag is not set since the advertiser is
not the RUL. The ROVR field is copied unchanged from the EARO not the RUL. The ROVR field is copied unchanged from the EARO
(see Section 6.1). (see Section 6.1).
skipping to change at page 24, line 5 skipping to change at page 24, line 41
NA(EARO) to the RUL. Upon receiving an asynchronous DCO message, if NA(EARO) to the RUL. Upon receiving an asynchronous DCO message, if
a DAO-ACK is pending then the 6LR MUST wait for the DAO-ACK to send a DAO-ACK is pending then the 6LR MUST wait for the DAO-ACK to send
the NA(EARO) and deliver the status found in the DCO, else it MUST the NA(EARO) and deliver the status found in the DCO, else it MUST
send an asynchronous NA(EARO) to the RUL immediately. send an asynchronous NA(EARO) to the RUL immediately.
The 6LR MUST set the R Flag in the NA(EARO) back if and only if the The 6LR MUST set the R Flag in the NA(EARO) back if and only if the
'E' flag is reset, indicating that the 6LR injected the Registered 'E' flag is reset, indicating that the 6LR injected the Registered
Address in the RPL routing successfully and that the EDAR proxy Address in the RPL routing successfully and that the EDAR proxy
operation succeeded. operation succeeded.
If the 'A' flag in the RPL Status is set, the embedded Status Value If the 'A' flag in the RPL Status is set, the embedded Status value
is passed back to the RUL in the EARO Status. If the 'E' flag is is passed back to the RUL in the EARO Status. If the 'E' flag is
also set, the registration failed for 6LoWPAN ND related reasons, and also set, the registration failed for 6LoWPAN ND related reasons, and
the NCE is removed. the NCE is removed.
An error injecting the route causes the 'E' flag to be set. If the An error injecting the route causes the 'E' flag to be set. If the
error is not related to ND, the 'A' flag is not set. In that case, error is not related to ND, the 'A' flag is not set. In that case,
the registration succeeds, but the RPL route is not installed. So the registration succeeds, but the RPL route is not installed. So
the NA(EARO) is returned with a positive status but the R Flag not the NA(EARO) is returned with a positive status but the R Flag not
set, which means that the 6LN obtained a binding but no route. set, which means that the 6LN obtained a binding but no route.
skipping to change at page 24, line 29 skipping to change at page 25, line 18
if the 6LR did not attempt to inject the route but could create the if the 6LR did not attempt to inject the route but could create the
binding after a successful EDAR/EDAC exchange or refresh it. binding after a successful EDAR/EDAC exchange or refresh it.
If the 'E' flag is set in the RPL Status of the DAO-ACK, then the If the 'E' flag is set in the RPL Status of the DAO-ACK, then the
route was not installed and the R flag MUST NOT be set in the route was not installed and the R flag MUST NOT be set in the
NA(EARO). The R flag MUST NOT be set if the 6LR did not attempt to NA(EARO). The R flag MUST NOT be set if the 6LR did not attempt to
inject the route. inject the route.
In a network where Address Protected Neighbor Discovery (AP-ND) is In a network where Address Protected Neighbor Discovery (AP-ND) is
enabled, in case of a DAO-ACK or a DCO indicating transporting an enabled, in case of a DAO-ACK or a DCO indicating transporting an
EARO Status Value of 5 (Validation Requested), the 6LR MUST challenge EARO Status value of 5 (Validation Requested), the 6LR MUST challenge
the 6LN for ownership of the address, as described in section 6.1 of the 6LN for ownership of the address, as described in section 6.1 of
[AP-ND], before the Registration is complete. This flow, illustrated [AP-ND], before the Registration is complete. This flow, illustrated
in Figure 9, ensures that the address is validated before it is in Figure 9, ensures that the address is validated before it is
injected in the RPL routing. injected in the RPL routing.
If the challenge succeeds, then the operations continue as normal. If the challenge succeeds, then the operations continue as normal.
In particular, a DAO message is generated upon the NS(EARO) that In particular, a DAO message is generated upon the NS(EARO) that
proves the ownership of the address. If the challenge failed, the proves the ownership of the address. If the challenge failed, the
6LR rejects the registration as prescribed by AP-ND and may take 6LR rejects the registration as prescribed by AP-ND and may take
actions to protect itself against DoS attacks by a rogue 6LN, see actions to protect itself against DoS attacks by a rogue 6LN, see
skipping to change at page 25, line 48 skipping to change at page 26, line 48
Figure 9: Address Protection Figure 9: Address Protection
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, and/ 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 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]. This may as Router, as specified in section 6.2.5 of [RFC4861]. This may
happen upon a DCO or a DAO-ACK message indicating the path is already happen upon a DCO or a DAO-ACK message indicating the path is already
removed; else the 6LR SHOULD remove the Host route to the 6LN using a removed; else the 6LR MUST remove the Host route to the 6LN using a
DAO message with a Path Lifetime of zero. DAO message with a Path Lifetime of zero.
A valid NS(EARO) message with the R Flag not set and a Registration A valid NS(EARO) message with the R Flag not set and a Registration
Lifetime that is not zero signals that the 6LN wishes to maintain the Lifetime that is not zero signals that the 6LN wishes to maintain the
binding but does not require the routing services from the 6LR (any binding but does not require the routing services from the 6LR (any
more). Upon this message, if, due to previous NS(EARO) with the R more). Upon this message, if, due to previous NS(EARO) with the R
Flag set, the 6LR was injecting the Host route to the Registered Flag set, the 6LR was injecting the Host route to the Registered
Address in RPL using DAO messages, then the 6LR MUST invalidate the Address in RPL using DAO messages, then the 6LR MUST invalidate the
Host route in RPL using a DAO with a Path Lifetime of zero. It is up Host route in RPL using a DAO with a Path Lifetime of zero. It is up
to the Registering 6LN to maintain the corresponding route from then to the Registering 6LN to maintain the corresponding route from then
on, either keeping it active via a different 6LR or by acting as a on, either keeping it active via a different 6LR or by acting as a
RAN and managing its own reachability. RAN and managing its own reachability.
9.2.3. Perspective of the RPL Root 9.2.3. Perspective of the RPL Root
A RPL Root MUST set the 'P' bit in the RPL DODAG Configuration Option A RPL Root MUST set the 'P' flag in the RPL DODAG Configuration
of the DIO messages that it generates (see Section 6) to signal that Option of the DIO messages that it generates (see Section 6) to
it proxies the EDAR/EDAC exchange and supports the Updated RPL Target signal that it proxies the EDAR/EDAC exchange and supports the
option. Updated RPL Target option.
Upon reception of a DAO message, for each updated RPL Target Option Upon reception of a DAO message, for each updated RPL Target Option
(see Section 6.1) that creates or updates an existing RPL state, the (see Section 6.1) that creates or updates an existing RPL state, the
Root MUST notify the 6LBR by using a proxied EDAR/EDAC exchange. If Root MUST notify the 6LBR by using a proxied EDAR/EDAC exchange. If
if the RPL Root and the 6LBR are integrated, an internal API can be if the RPL Root and the 6LBR are integrated, an internal API can be
used. used.
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
skipping to change at page 27, line 12 skipping to change at page 28, line 12
In either case, the EDAC Status is embedded in the RPL Status with In either case, the EDAC Status is embedded in the RPL Status with
the 'A' flag set. the 'A' flag set.
The proxied EDAR/EDAC exchange MUST be protected with a timer of an The proxied EDAR/EDAC exchange MUST be protected with a timer of an
appropriate duration and a number of retries, that are appropriate duration and a number of retries, that are
implementation-dependent, and SHOULD be configurable since the Root implementation-dependent, and SHOULD be configurable since the Root
and the 6LBR are typically nodes with a higher capacity and and the 6LBR are typically nodes with a higher capacity and
manageability than 6LRs. Upon timing out, the Root MUST send an manageability than 6LRs. Upon timing out, the Root MUST send an
error back to the 6LR as above, either using a DAO-ACK or a DCO, as error back to the 6LR as above, either using a DAO-ACK or a DCO, as
appropriate, with the 'A' and 'E' flags set in the RPL status, and a appropriate, with the 'A' and 'E' flags set in the RPL status, and a
RPL Status Value of of "6LBR Registry Saturated" [RFC8505]. RPL Status value of of "6LBR Registry Saturated" [RFC8505].
9.2.4. Perspective of the 6LBR 9.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.
10. Protocol Operations for Multicast Addresses 10. Protocol Operations for Multicast Addresses
Section 12 of [RFC6550] details the RPL support for multicast flows. Section 12 of [RFC6550] details the RPL support for multicast flows.
This support is not source-specific and only operates as an extension This support is activated by the MOP of 3 ("Storing Mode of Operation
to the Storing Mode of Operation for unicast packets. Note that it with multicast support") in the DIO messages that form the DODAG.
is the RPL model that the multicast packet is passed as a Layer-2 This section also applies if and only if the MOP of the RPLInstance
unicast to each of the interested children. This remains true when is 3.
forwarding between the 6LR and the listener 6LN.
The RPL support of multicast is not source-specific and only operates
as an extension to the Storing Mode of Operation for unicast packets.
Note that it is the RPL model that the multicast packet is passed as
a Layer-2 unicast to each of the interested children. This remains
true when forwarding between the 6LR and the listener 6LN.
"Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810] "Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810]
provide an interface for a listener to register to multicast flows. provides an interface for a listener to register to multicast flows.
In the MLD model, the Router is a "querier", and the Host is a In the MLD model, the Router is a "querier", and the Host is a
multicast listener that registers to the querier to obtain copies of multicast listener that registers to the querier to obtain copies of
the particular flows it is interested in. the particular flows it is interested in.
The equivalent of the first Address Registration happens as The equivalent of the first Address Registration happens as
illustrated in Figure 10. The 6LN, as an MLD listener, sends an illustrated in Figure 10. The 6LN, as an MLD listener, sends an
unsolicited Report to the 6LR. This enables it to start receiving unsolicited Report to the 6LR. This enables it to start receiving
the flow immediately, and causes the 6LR to inject the multicast the flow immediately, and causes the 6LR to inject the multicast
route in RPL. route in RPL.
skipping to change at page 28, line 4 skipping to change at page 29, line 10
This specification does not change MLD but will operate more This specification does not change MLD but will operate more
efficiently if the asynchronous messages for unsolicited Report and efficiently if the asynchronous messages for unsolicited Report and
Done are sent by the 6LN as Layer-2 unicast to the 6LR, in particular Done are sent by the 6LN as Layer-2 unicast to the 6LR, in particular
on wireless. on wireless.
The 6LR acts as a generic MLD querier and generates a DAO with the The 6LR acts as a generic MLD querier and generates a DAO with the
Multicast Address as the Target Prefix as described in section 12 of Multicast Address as the Target Prefix as described in section 12 of
[RFC6550]. As for the Unicast Host routes, the Path Lifetime [RFC6550]. As for the Unicast Host routes, the Path Lifetime
associated to the Target is mapped from the Query Interval, and set associated to the Target is mapped from the Query Interval, and set
to be larger to account for variable propagation delays to the Root. to be larger to account for variable propagation delays to the Root.
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. RPL domain.
Upon a DAO with a Target option for a multicast address, the RPL Root Upon a DAO with a Target option for a multicast address, the RPL Root
checks if it is already registered as a listener for that address, checks if it is already registered as a listener for that address,
and if not, it performs its own unsolicited Report for the multicast and if not, it performs its own unsolicited Report for the multicast
address as sescribed in section 5.1 of [RFC3810]. The report is address as described in section 5.1 of [RFC3810]. The report is
source independent, so there is no Source Address listed. source independent, so there is no Source Address listed.
6LN/RUL 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| unsolicited Report | | | | unsolicited Report | | |
|------------------->| | | |------------------->| | |
| <L2 ack> | | |
| | DAO | | | | DAO | |
| |-------------->| | | |-------------->| |
| | DAO-ACK | | | | DAO-ACK | |
| |<--------------| | | |<--------------| |
| | | <if not done already> | | | | <if not done already> |
| | | unsolicited Report | | | | unsolicited Report |
| | |---------------------->| | | |---------------------->|
| | | | | | | |
Figure 10: First Multicast Registration Flow Figure 10: First Multicast Registration Flow
skipping to change at page 29, line 44 skipping to change at page 30, line 48
Routers using 6LoWPAN ND, meaning that they cannot perform RPL Routers using 6LoWPAN ND, meaning that they cannot perform RPL
insider attacks. insider attacks.
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), Denial-Of-Service attacks as black-holing, (see [RFC7416] section 7), Denial-Of-Service attacks
whereby a rogue 6LR creates a high churn in the RPL network by whereby a rogue 6LR creates a high churn in the RPL network by
advertising and removing many forged addresses, or bombing attack advertising and removing many forged addresses, or bombing attack
whereby an impersonated 6LBR would destroy state in the network by whereby an impersonated 6LBR would destroy state in the network by
using the "Removed" Status code. using the status code of 4 ("Removed").
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
requirement, see Req5.1 in Appendix of [RFC8505]. requirement, see Req5.1 in Appendix of [RFC8505].
In a general manner, the Security Considerations in [RFC7416] In a general manner, the Security Considerations in [RFC7416]
[RFC6775], and [RFC8505] apply to this specification as well. [RFC6775], and [RFC8505] apply to this specification as well.
The Link-Layer security is needed in particular to prevent Denial-Of- The Link-Layer security is needed in particular to prevent Denial-Of-
Service attacks whereby a rogue 6LN creates a high churn in the RPL Service attacks whereby a rogue 6LN creates a high churn in the RPL
skipping to change at page 30, line 29 skipping to change at page 31, line 36
that address can modify the registration information, thereby that address can modify the registration information, thereby
enforcing Source Address Validation. [AP-ND] reduces even more the enforcing Source Address Validation. [AP-ND] reduces even more the
attack perimeter that is available to the edge nodes and its use is attack perimeter that is available to the edge nodes and its use is
suggested in this specification. suggested in this specification.
Additionally, the trust model could include a role validation to Additionally, the trust model could include a role validation to
ensure that the node that claims to be a 6LBR or a RPL Root is ensure that the node that claims to be a 6LBR or a RPL Root is
entitled to do so. entitled to do so.
The Opaque field in the EARO enables the RUL to suggest a The Opaque field in the EARO enables the RUL to suggest a
RPLInstanceID where its traffic is placed. This opens to attacks RPLInstanceID where its traffic is placed. It is also possible for
where a RPL instance would be reserved for critical traffic, e.g., an attacker RUL to include an RPI in the packet. This opens to
with a specific bandwidth reservation, that the additional traffic attacks where a RPL instance would be reserved for critical traffic,
generated by a rogue may disrupt. This may be alleviated by e.g., with a specific bandwidth reservation, that the additional
traditional access control mechanisms where the 6LR shapes the traffic generated by a rogue may disrupt. The attack may be
incoming traffic from the 6LN. alleviated by traditional access control and traffic shaping
mechanisms where the 6LR controls the incoming traffic from the 6LN.
More importantly, the 6LR is the node that injects the traffic in the
RPL domain, so it has the final word on which RPLInstance is to be
used for the traffic coming from the RUL, per its own policy.
At the time of this writing, RPL does not have a Route Ownership At the time of this writing, RPL does not have a Route Ownership
Validation model whereby it is possible to validate the origin of an Validation model whereby it is possible to validate the origin of an
address that is injected in a DAO. This specification makes a first address that is injected in a DAO. This specification makes a first
step in that direction by allowing the Root to challenge the RUL via step in that direction by allowing the Root to challenge the RUL via
the 6LR that serves it. the 6LR that serves it.
[EFFICIENT-NPDAO] introduces the ability for a rogue common ancestor [EFFICIENT-NPDAO] introduces the ability for a rogue common ancestor
node to invalidate a route on behalf of the target node. In that node to invalidate a route on behalf of the target node. In this
case, the RPL Status in the DCO has the 'A' flag not set, and a case, the RPL Status in the DCO has the 'A' flag not set, and a
NA(EARO) is returned to the 6LN with the R flag not set. This NA(EARO) is returned to the 6LN with the R flag not set. This
encourages the 6LN to try another 6LR. If a 6LR exists that does not encourages the 6LN to try another 6LR. If a 6LR exists that does not
use the rogue common ancestor, then the 6LN will eventually succeed use the rogue common ancestor, then the 6LN will eventually succeed
gaining reachability over the RPL network in spite of the rogue node. gaining reachability over the RPL network in spite of the rogue node.
12. IANA Considerations 12. IANA Considerations
12.1. Fixing the Address Registration Option Flags 12.1. Fixing the Address Registration Option Flags
Section 9.1 of [RFC8505] creates a Registry for the 8-bit Address Section 9.1 of [RFC8505] creates a Registry for the 8-bit Address
Registration Option Flags field. IANA is requested to rename the Registration Option Flags field. IANA is requested to rename the
first column of the table from "ARO Status" to "Bit number". first column of the table from "ARO Status" to "Bit number".
12.2. Resizing the ARO Status values 12.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. Status values Registry with a range 0-255.
This specification reduces that range to 0-63, see Section 6.3. This specification reduces that range to 0-63, see Section 6.3.
IANA is requested modify the Address Registration Option Status IANA is requested to modify the Address Registration Option Status
Values Registry so that the upper bound of the unassigned values is values Registry so that the upper bound of the unassigned values is
63. This document should be added as a reference. The registration 63. This document should be added as a reference. The registration
procedure does not change. procedure does not change.
12.3. New DODAG Configuration Option Flag 12.3. New RPL DODAG Configuration Option Flag
This specification updates the Registry that was created for IANA is requested to assign a flag from the "DODAG Configuration
[RFC6550] as the registry for "DODAG Configuration Option Flags" and Option Flags for MOP 0..6" [USEofRPLinfo] registry as follows:
updated as the registry for "DODAG Configuration Option Flags for MOP
0..6" by [USEofRPLinfo], by allocating one new Flag as follows:
+---------------+----------------------------+-----------+ +---------------+----------------------------+-----------+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+---------------+----------------------------+-----------+ +---------------+----------------------------+-----------+
| 1 (suggested) | Root Proxies EDAR/EDAC (P) | THIS RFC | | 1 (suggested) | Root Proxies EDAR/EDAC (P) | THIS RFC |
+---------------+----------------------------+-----------+ +---------------+----------------------------+-----------+
Table 2: New DODAG Configuration Option Flag Table 2: New DODAG Configuration Option Flag
12.4. RPL Target Option Registry 12.4. RPL Target Option Registry
Section 20.15 of [RFC6550] creates a Registry for the 8-bit "RPL This document modifies the "RPL Target Option Flags" registry
Target Option Flags" field. IANA is requested to reduce the size of initially created in Section 20.15 of [RFC6550] . The registry now
the field in the Registry to 4 bits. Section 6.1 also defines a new includes only 4 bits (Section 6.1) and should point to this document
entry in the Registry as follows: as an additional reference. The registration procedure doesn't
change.
Section 6.1 also defines a new entry in the Registry as follows:
+---------------+--------------------------------+-----------+ +---------------+--------------------------------+-----------+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+---------------+--------------------------------+-----------+ +---------------+--------------------------------+-----------+
| 1 (suggested) | Advertiser address in Full (F) | THIS RFC | | 1 (suggested) | Advertiser address in Full (F) | THIS RFC |
+---------------+--------------------------------+-----------+ +---------------+--------------------------------+-----------+
Table 3: RPL Target Option Registry Table 3: RPL Target Option Registry
12.5. New Subregistry for the RPL Non-Rejection Status values 12.5. New Subregistry for 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 the RPL DAO-ACK and DCO messages Rejection Status values for use in the RPL DAO-ACK, DCO, and DCO-ACK
with the 'A' flag reset, under the RPL registry. messages with the 'A' flag reset, under the RPL registry.
* Possible values are 6-bit unsigned integers (0..63). * Possible values are 6-bit unsigned integers (0..63).
* Registration procedure is "IETF Review" [RFC8126]. * Registration procedure is "IETF Review" [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 | THIS RFC | | 0 | Unqualified acceptance | THIS RFC / RFC 6550 |
+-------+--------------------------+-------------------+ +-------+------------------------+---------------------+
| 1 | No routing-entry for the | [EFFICIENT-NPDAO] | | 2..63 | Unassigned | |
| | indicated Target found | | +-------+------------------------+---------------------+
+-------+--------------------------+-------------------+
Table 4: Acceptance values of the RPL Status Table 4: Acceptance values of the RPL Status
12.6. New Subregistry for the RPL Rejection Status values 12.6. New Subregistry for 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 the RPL DAO-ACK and DCO messages with the Status values for use in the RPL DAO-ACK and DCO messages with the
'A' flag reset, under the RPL registry. 'A' flag reset, under the RPL registry.
* Possible values are 6-bit unsigned integers (0..63). * Possible values are 6-bit unsigned integers (0..63).
* Registration procedure is "IETF Review" [RFC8126]. * Registration procedure is "IETF Review" [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 RFC | | 0 | Unqualified rejection | THIS RFC |
+-------+-----------------------+-----------+ +-------+-----------------------+-----------+
| 1..63 | Unassigned | |
+-------+-----------------------+-----------+
Table 5: Rejection values of the RPL Status Table 5: Rejection values of the RPL Status
13. Acknowledgments 13. Acknowledgments
The authors wish to thank Ines Robles, Georgios Papadopoulos and The authors wish to thank Ines Robles, Georgios Papadopoulos and
especially Rahul Jadhav and Alvaro Retana for their reviews and especially Rahul Jadhav and Alvaro Retana for their reviews and
contributions to this document. contributions to this document.
14. Normative References 14. Normative References
 End of changes. 69 change blocks. 
183 lines changed or deleted 232 lines changed or added

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