draft-ietf-roll-unaware-leaves-26.txt   draft-ietf-roll-unaware-leaves-27.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: 19 June 2021 16 December 2020 Expires: 20 June 2021 17 December 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-26 draft-ietf-roll-unaware-leaves-27
Abstract Abstract
This specification updates RFC6550, RFC6775, and RFC8505. It This specification updates RFC6550, RFC6775, and RFC8505. It
provides a mechanism for a host that implements a routing-agnostic provides a mechanism for a host that implements a routing-agnostic
interface based on 6LoWPAN Neighbor Discovery to obtain reachability interface based on 6LoWPAN Neighbor Discovery to obtain reachability
services across a network that leverages RFC6550 for its routing services across a network that leverages RFC6550 for its routing
operations. operations.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 June 2021. This Internet-Draft will expire on 20 June 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
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. References . . . . . . . . . . . . . . . . . . . . . . . 7 2.3. References . . . . . . . . . . . . . . . . . . . . . . . 7
3. RPL External Routes and Dataplane Artifacts . . . . . . . . . 8 3. RPL External Routes and Dataplane Artifacts . . . . . . . . . 8
4. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 9 4. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 9
4.1. RFC 6775 Address Registration . . . . . . . . . . . . . . 9 4.1. RFC 6775 Address Registration . . . . . . . . . . . . . . 9
4.2. RFC 8505 Extended Address Registration . . . . . . . . . 9 4.2. RFC 8505 Extended Address Registration . . . . . . . . . 9
4.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. TID, "I" Field and Opaque Fields . . . . . . . . . . 10 4.2.2. TID, "I" Field and Opaque Fields . . . . . . . . . . 10
4.2.3. Route Ownership Verifier . . . . . . . . . . . . . . 11 4.2.3. Route Ownership Verifier . . . . . . . . . . . . . . 11
skipping to change at page 2, line 30 skipping to change at page 2, line 30
4.3.1. RFC 7400 Capability Indication Option . . . . . . . . 12 4.3.1. RFC 7400 Capability Indication Option . . . . . . . . 12
5. Requirements on the RPL-Unware leaf . . . . . . . . . . . . . 12 5. Requirements on the RPL-Unware leaf . . . . . . . . . . . . . 12
5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 12 5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 12
5.2. Support of IPv6 Encapsulation . . . . . . . . . . . . . . 13 5.2. Support of IPv6 Encapsulation . . . . . . . . . . . . . . 13
5.3. Support of the Hop-by-Hop Header . . . . . . . . . . . . 13 5.3. Support of the Hop-by-Hop Header . . . . . . . . . . . . 13
5.4. Support of the Routing Header . . . . . . . . . . . . . . 13 5.4. Support of the Routing Header . . . . . . . . . . . . . . 13
6. Enhancements to RFC 6550 . . . . . . . . . . . . . . . . . . 14 6. Enhancements to RFC 6550 . . . . . . . . . . . . . . . . . . 14
6.1. Updated RPL Target Option . . . . . . . . . . . . . . . . 14 6.1. Updated RPL Target Option . . . . . . . . . . . . . . . . 14
6.2. Additional Flag in the RPL DODAG Configuration Option . . 16 6.2. Additional Flag in the RPL DODAG Configuration Option . . 16
6.3. Updated RPL Status . . . . . . . . . . . . . . . . . . . 17 6.3. Updated RPL Status . . . . . . . . . . . . . . . . . . . 17
7. Enhancements to draft-ietf-roll-efficient-npdao . . . . . . . 18 7. Enhancements to draft-ietf-roll-efficient-npdao . . . . . . . 19
8. Enhancements to RFC 6775 and RFC8505 . . . . . . . . . . . . 19 8. Enhancements to RFC 6775 and RFC8505 . . . . . . . . . . . . 19
9. Protocol Operations for Unicast Addresses . . . . . . . . . . 19 9. Protocol Operations for Unicast Addresses . . . . . . . . . . 20
9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 20 9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 20
9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 23 9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 23
9.2.1. Perspective of the 6LN Acting as RUL . . . . . . . . 23 9.2.1. Perspective of the 6LN Acting as RUL . . . . . . . . 23
9.2.2. Perspective of the 6LR Acting as Border router . . . 24 9.2.2. Perspective of the 6LR Acting as Border router . . . 25
9.2.3. Perspective of the RPL Root . . . . . . . . . . . . . 29 9.2.3. Perspective of the RPL Root . . . . . . . . . . . . . 29
9.2.4. Perspective of the 6LBR . . . . . . . . . . . . . . . 30 9.2.4. Perspective of the 6LBR . . . . . . . . . . . . . . . 30
10. Protocol Operations for Multicast Addresses . . . . . . . . . 30 10. Protocol Operations for Multicast Addresses . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12.1. Fixing the Address Registration Option Flags . . . . . . 34 12.1. Fixing the Address Registration Option Flags . . . . . . 34
12.2. Resizing the ARO Status values . . . . . . . . . . . . . 34 12.2. Resizing the ARO Status values . . . . . . . . . . . . . 35
12.3. New RPL DODAG Configuration Option Flag . . . . . . . . 34 12.3. New RPL DODAG Configuration Option Flag . . . . . . . . 35
12.4. RPL Target Option Registry . . . . . . . . . . . . . . . 35 12.4. RPL Target Option Registry . . . . . . . . . . . . . . . 35
12.5. New Subregistry for RPL Non-Rejection Status values . . 35 12.5. New Subregistry for RPL Non-Rejection Status values . . 36
12.6. New Subregistry for RPL Rejection Status values . . . . 36 12.6. New Subregistry for RPL Rejection Status values . . . . 36
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
14. Normative References . . . . . . . . . . . . . . . . . . . . 36 14. Normative References . . . . . . . . . . . . . . . . . . . . 37
15. Informative References . . . . . . . . . . . . . . . . . . . 38 15. Informative References . . . . . . . . . . . . . . . . . . . 38
Appendix A. Example Compression . . . . . . . . . . . . . . . . 40 Appendix A. Example Compression . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
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,
skipping to change at page 4, line 17 skipping to change at page 4, line 17
to one or more RPL router(s); as such, it relies on the RPL router(s) to one or more RPL router(s); as such, it relies on the RPL router(s)
to forward its traffic across the RPL domain but does not forward to forward its traffic across the RPL domain but does not forward
traffic from another node. As opposed to the RAL, the RUL does not traffic from another node. As opposed to the RAL, the RUL does not
participate to RPL, and relies on its RPL router(s) also to inject participate to RPL, and relies on its RPL router(s) also to inject
the routes to its IPv6 addresses in the RPL domain. the routes to its IPv6 addresses in the RPL domain.
A RUL may be unable to participate because it is very energy- A RUL may be unable to participate because it is very energy-
constrained, code-space constrained, or because it would be unsafe to constrained, code-space constrained, or because it would be unsafe to
let it inject routes in RPL. Using 6LoWPAN ND as opposed to RPL as let it inject routes in RPL. Using 6LoWPAN ND as opposed to RPL as
the host-to-router interface limits the surface of the possible the host-to-router interface limits the surface of the possible
attacks by the RUL against the RPL domain, and can protect RUL for attacks by the RUL against the RPL domain. If all RULs and RANs use
its address ownership. 6LoWPAN ND for Neighbor Discovery, it is also possible to protect the
address ownership of all nodes, including the RULs.
This document specifies how the router injects the host routes in the This document specifies how the router injects the host routes in the
RPL domain on behalf of the RUL. Section 5 details how the RUL can RPL domain on behalf of the RUL. Section 5 details how the RUL can
leverage 6LoWPAN ND to obtain the routing services from the router. leverage 6LoWPAN ND to obtain the routing services from the router.
In that model, the RUL is also a 6LoWPAN Node (6LN) and the RPL-Aware In that model, the RUL is also a 6LoWPAN Node (6LN) and the RPL-Aware
router is also a 6LoWPAN router (6LR). Using the 6LoWPAN ND Address router is also a 6LoWPAN router (6LR). Using the 6LoWPAN ND Address
Registration mechanism, the RUL signals that the router must inject a Registration mechanism, the RUL signals that the router must inject a
host route for the Registered Address. host route for the Registered Address.
------+--------- ------+---------
skipping to change at page 5, line 18 skipping to change at page 5, line 18
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 severely energy constrained sensors Examples of possible RULs include severely energy constrained 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.
This specification can be deployed incrementally in a network that
implements [USEofRPLinfo]. Only the Root and the 6LRs that connect
the RULs need to be upgraded. The RPL routers on path will only see
unicast IPv6 traffic between the Root and the 6LR.
This document is organized as follows: This document is organized as follows:
* Section 3 and Section 4 present in a non-normative fashion the * Section 3 and Section 4 present in a non-normative fashion the
salient aspects of RPL and 6LoWPAN ND, respectively, that are salient aspects of RPL and 6LoWPAN ND, respectively, that are
leveraged in this specification to provide connectivity to a 6LN leveraged in this specification to provide connectivity to a 6LN
acting as a RUL across a RPL network. acting as 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.
skipping to change at page 6, line 16 skipping to change at page 6, line 19
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Glossary 2.2. Glossary
This document uses the following acronyms: This document uses the following acronyms:
AR: Address Resolution (aka Address Lookup)
ARQ: Automatic Repeat reQuest
6CIO: 6LoWPAN Capability Indication Option 6CIO: 6LoWPAN Capability Indication Option
6LN: 6LoWPAN Node (a Low Power host or router) 6LN: 6LoWPAN Node (a Low Power host or router)
6LR: 6LoWPAN router 6LR: 6LoWPAN router
6LBR: 6LoWPAN Border router 6LBR: 6LoWPAN Border router
(E)ARO: (Extended) Address Registration Option (E)ARO: (Extended) Address Registration Option
(E)DAR: (Extended) Duplicate Address Request (E)DAR: (Extended) Duplicate Address Request
(E)DAC: (Extended) Duplicate Address Confirmation (E)DAC: (Extended) Duplicate Address Confirmation
DAD: Duplicate Address Detection DAD: Duplicate Address Detection
DAO: Destination Advertisement Object (a RPL message) DAO: Destination Advertisement Object (a RPL message)
DCO: Destination Cleanup Object (a RPL message) DCO: Destination Cleanup Object (a RPL message)
DIS: DODAG Information solicitation (a RPL message)
DIO: DODAG Information Object (a RPL message) DIO: DODAG Information Object (a RPL message)
DODAG: Destination-Oriented Directed Acyclic Graph DODAG: Destination-Oriented Directed Acyclic Graph
LLN: Low-Power and Lossy Network LLN: Low-Power and Lossy Network
MOP: RPL Mode of Operation MOP: RPL Mode of Operation
NA: Neighbor Advertisement NA: Neighbor Advertisement
NCE: Neighbor Cache Entry NCE: Neighbor Cache Entry
ND: Neighbor Discovery ND: Neighbor Discovery
NS: Neighbor solicitation NS: Neighbor solicitation
RA: router Advertisement RA: router Advertisement
ROVR: Registration Ownership Verifier ROVR: Registration Ownership Verifier
skipping to change at page 7, line 23 skipping to change at page 7, line 23
to nodes that implement the 6LN and 6LR roles in 6LoWPAN ND and does to nodes that implement the 6LN and 6LR roles in 6LoWPAN ND and does
not expect other functionality such as 6LoWPAN Header Compression not expect other functionality such as 6LoWPAN Header Compression
[RFC6282] from those nodes. [RFC6282] from those nodes.
"RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by
a RPLInstanceID), "up", "down" are defined in "RPL: IPv6 Routing a RPLInstanceID), "up", "down" are defined in "RPL: IPv6 Routing
Protocol for Low-Power and Lossy Networks" [RFC6550]. The RPI is the Protocol for Low-Power and Lossy Networks" [RFC6550]. The RPI is the
abstract information that RPL defines to be placed in data packets, abstract information that RPL defines to be placed in data packets,
e.g., as the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header. e.g., as the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header.
By extension, the term "RPI" is often used to refer to the RPL Option By extension, the term "RPI" is often used to refer to the RPL Option
itself. The DODAG Information solicitation (DIS), Destination itself. The Destination Advertisement Object (DAO) and DODAG
Advertisement Object (DAO) and DODAG Information Object (DIO) Information Object (DIO) messages are also specified in [RFC6550].
messages are also specified in [RFC6550]. The Destination Cleanup The Destination Cleanup Object (DCO) message is defined in
Object (DCO) message is defined in [EFFICIENT-NPDAO]. [EFFICIENT-NPDAO].
This document uses the terms RPL-Unaware Leaf (RUL), RPL-Aware Node This document uses the terms RPL-Unaware Leaf (RUL), RPL-Aware Node
(RAN) and RPL aware Leaf (RAL) consistently with [USEofRPLinfo]. A (RAN) and RPL aware Leaf (RAL) consistently with [USEofRPLinfo]. A
RAN is either an RAL or a RPL router. As opposed to a RUL, a RAN RAN is either an RAL or a RPL router. As opposed to a RUL, a RAN
manages the reachability of its addresses and prefixes by injecting manages the reachability of its addresses and prefixes by injecting
them in RPL by itself. them in RPL by itself.
In this document, readers will encounter terms and concepts that are In this document, readers will encounter terms and concepts that are
discussed in the following documents: discussed in the following documents:
skipping to change at page 7, line 48 skipping to change at page 7, line 48
and "IPv6 Stateless Address Autoconfiguration" [RFC4862], and "IPv6 Stateless Address Autoconfiguration" [RFC4862],
6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power 6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606] and Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606] and
"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals" [RFC4919], Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
and and
6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy 6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy
Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor
Discovery" [RFC8505], and "Address Protected Neighbor Discovery Discovery" [RFC8505], "Address Protected Neighbor Discovery for
for Low-power and Lossy Networks" [RFC8928]. Low-power and Lossy Networks" [RFC8928], and "IPv6 Backbone
Router" [RFC8929].
3. RPL External Routes and Dataplane Artifacts 3. RPL External Routes and Dataplane Artifacts
Section 4.1 of [USEofRPLinfo] provides a set of rules summarized Section 4.1 of [USEofRPLinfo] provides a set of rules summarized
below that must be followed for routing packets from and to a RUL. below that must be followed for routing packets from and to a RUL.
A 6LR that acts as a border router for external routes advertises A 6LR that acts as a border router for external routes advertises
them using Non-Storing Mode DAO messages that are unicast directly to them using Non-Storing Mode DAO messages that are unicast directly to
the Root, even if the DODAG is operated in Storing Mode. Non-Storing the Root, even if the DODAG is operated in Storing Mode. Non-Storing
Mode routes are not visible inside the RPL domain and all packets are Mode routes are not visible inside the RPL domain and all packets are
skipping to change at page 8, line 33 skipping to change at page 8, line 33
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 typically carry a Hop-by-Hop Header with a RPL The RPL data packets typically carry a Hop-by-Hop Header with a RPL
Option [RFC6553] that contains the Packet Information (RPI) defined Option [RFC6553] that contains the Packet Information (RPI) defined
in section 11.2 of [RFC6550]. Unless the RUL already placed a RPL in section 11.2 of [RFC6550]. Unless the RUL already placed a RPL
Option in outer header chain, the packets from and to the RUL are Option in outer header chain, the packets from and to the RUL are
encapsulated using an IPv6-in-IPv6 tunnel between the Root and the encapsulated using an IPv6-in-IPv6 tunnel between the Root and the
6LR that serves the RUL (see sections 7 and 8 of [USEofRPLinfo] for 6LR that serves the RUL (see sections 7 and 8 of [USEofRPLinfo] for
details). If the packet from the RUL has an RPI, the 6LR as a RPL 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 border router rewrites the RPI to indicate the selected Instance and
Instance and set the flags, but it does not need to encapsulate the set the flags, but it does not need to encapsulate the packet (see
packet. Section 9.2.2) .
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 IPv6-in-IPv6 encapsulation, the RPI and the SRH are (SRH). The IPv6-in-IPv6 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
RUL to support the basic "IPv6 Node Requirements" [RFC8504] and in RUL to support the basic "IPv6 Node Requirements" [RFC8504] and in
particular the mandates in Sections 4.2 and 4.4 of [RFC8200]. As particular the mandates in Sections 4.2 and 4.4 of [RFC8200]. As
such, the RUL is expected to ignore the RPL artifacts that may be such, the RUL is expected to ignore the RPL artifacts that may be
left over, either an SRH with zero Segments Left or a RPL Option in left over, either an SRH with zero Segments Left or a RPL Option in
the Hop-by-Hop Header, which can be skipped when not recognized, see the Hop-by-Hop Header, which can be skipped when not recognized, see
Section 5 for more. Section 5 for more.
A RUL is not expected to support the compression method defined in A RUL is not expected to support the compression method defined in
[RFC8138]. For that reason, the border router uncompresses the [RFC8138]. For that reason, the border router (the 6LR here)
packet before forwarding it over an external route to a RUL uncompresses the packet before forwarding it over an external route
[USEofRPLinfo]. to a RUL [USEofRPLinfo].
4. 6LoWPAN Neighbor Discovery 4. 6LoWPAN Neighbor Discovery
This section goes through the 6LoWPAN ND mechanisms that this This section goes through the 6LoWPAN ND mechanisms that this
specification leverages, as a non-normative reference to the reader. specification leverages, as a non-normative reference to the reader.
The full normative text is to be found in [RFC6775], [RFC8505], and The full normative text is to be found in [RFC6775], [RFC8505], and
[RFC8928]. [RFC8928].
4.1. RFC 6775 Address Registration 4.1. RFC 6775 Address Registration
skipping to change at page 9, line 45 skipping to change at page 9, line 45
Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the
6LoWPAN router (6LR). It also defines the Duplicate Address Request 6LoWPAN router (6LR). It also defines the Duplicate Address Request
(DAR) and Duplicate Address Confirmation (DAC) messages between the (DAR) and Duplicate Address Confirmation (DAC) messages between the
6LR and the 6LoWPAN Border router (6LBR). In an LLN, the 6LBR is the 6LR and the 6LoWPAN Border router (6LBR). In an LLN, the 6LBR is the
central repository of all the Registered Addresses in its domain and central repository of all the Registered Addresses in its domain and
the source of truth for uniqueness and ownership. the source of truth for uniqueness and ownership.
4.2. RFC 8505 Extended Address Registration 4.2. RFC 8505 Extended Address Registration
"Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505]
updates the behavior of RFC 6775 to enable a generic Address updates RFC 6775 into a generic Address Registration mechanism that
Registration to services such as routing and ND proxy, and defines can be used to access services such as routing and ND proxy. To that
the Extended Address Registration Option (EARO) as shown in Figure 2: effect, [RFC8505] defines the Extended Address Registration Option
(EARO), shown in Figure 2:
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 | Length | Status | Opaque | | Type | Length | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | I |R|T| TID | Registration Lifetime | | Rsvd | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... Registration Ownership Verifier ... ... Registration Ownership Verifier ...
skipping to change at page 11, line 31 skipping to change at page 11, line 31
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
carry the ROVR field. The EDAR/EDAC exchange takes place between the carry the ROVR field. The EDAR/EDAC exchange takes place between the
6LR and the 6LBR. It is triggered by an NS(EARO) message from a 6LN 6LR and the 6LBR. It is triggered by an NS(EARO) message from a 6LN
to create, refresh, and delete the corresponding state in the 6LBR. to create, refresh, and delete the corresponding state in the 6LBR.
The exchange is protected by the retry mechanism (ARQ) specified in The exchange is protected by the retry mechanism specified in
Section 8.2.6 of [RFC6775], though in an LLN, a duration longer than Section 8.2.6 of [RFC6775], though in an LLN, a duration longer than
the default value of the RetransTimer (RETRANS_TIMER) [RFC4861] of 1 the default value of the RetransTimer (RETRANS_TIMER) [RFC4861] of 1
second may be necessary to cover the round trip delay between the 6LR second may be necessary to cover the round trip delay between the 6LR
and the 6LBR. and the 6LBR.
RPL [RFC6550] specifies a periodic DAO from the 6LN all the way to RPL [RFC6550] specifies a periodic DAO from the 6LN all the way to
the Root that maintains the routing state in the RPL network for the the Root that maintains the routing state in the RPL network for the
lifetime indicated by the source of the DAO. This means that for lifetime indicated by the source of the DAO. This means that for
each address, there are two keep-alive messages that traverse the each address, there are two keep-alive messages that traverse the
whole network, one to the Root and one to the 6LBR. whole network, one to the Root and one to the 6LBR.
skipping to change at page 12, line 47 skipping to change at page 12, line 47
This document describes how RPL routing can be extended to reach a This document describes how RPL routing can be extended to reach a
RUL. This section specifies the minimal RPL-independent RUL. This section specifies the minimal RPL-independent
functionality that the RUL needs to implement to obtain routing functionality that the RUL needs to implement to obtain routing
services for its addresses. services for its addresses.
5.1. Support of 6LoWPAN ND 5.1. Support of 6LoWPAN ND
To obtain routing services from a router that implements this To obtain routing services from a router that implements this
specification, a RUL needs to implement [RFC8505] and sets the "R" specification, a RUL needs to implement [RFC8505] and sets the "R"
and "T" flags in the EARO to 1 as discussed in Section 4.2.1 and and "T" flags in the EARO to 1 as discussed in Section 4.2.1 and
Section 4.2.3, respectively. Section 9.2.1 specifies new behaviors Section 4.2.2, respectively. Section 9.2.1 specifies new behaviors
for the RUL, e.g., when the R Flag set to 1 in a NS(EARO) is not for the RUL, e.g., when the R Flag set to 1 in a NS(EARO) is not
echoed in the NA(EARO), which indicates that the route injection echoed in the NA(EARO), which indicates that the route injection
failed. failed.
The RUL is expected to request routing services from a router only if The RUL is expected to request routing services from a router only if
that router originates RA messages with a CIO that has the L, P, and that router originates RA messages with a CIO that has the L, P, and
E flags all set to 1 as discussed in Section 4.3.1, unless configured E flags all set to 1 as discussed in Section 4.3.1, unless configured
to do so. It is suggested that the RUL also implements [RFC8928] to to do so. It is suggested that the RUL also implements [RFC8928] to
protect the ownership of its addresses. protect the ownership of its addresses.
skipping to change at page 13, line 48 skipping to change at page 13, line 48
5.3. Support of the Hop-by-Hop Header 5.3. Support of the Hop-by-Hop Header
A RUL is expected to process an Option Type in a Hop-by-Hop Header as A RUL is expected to process an Option Type in a Hop-by-Hop Header as
prescribed by section 4.2 of [RFC8200]. An RPI with an Option Type prescribed by section 4.2 of [RFC8200]. An RPI with an Option Type
of 0x23 [USEofRPLinfo] is thus skipped when not recognized. of 0x23 [USEofRPLinfo] is thus skipped when not recognized.
5.4. Support of the Routing Header 5.4. 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 implies that the Source prescribed by section 4.4 of [RFC8200]. This implies that the Source
Routing Header with a Routing Type of 3 [RFC6554] is ignored when the Routing Header, which has a Routing Type of 3 [RFC6554], is ignored
Segments Left is zero. when the Segments Left is zero. When the Segments Left is non-zero,
the RUL discards the packet and send an ICMP Parameter Problem, Code
0, message to the packet's Source Address, pointing to the
unrecognized Routing Type.
6. Enhancements to RFC 6550 6. Enhancements to RFC 6550
This document specifies a new behavior whereby a 6LR injects DAO This document specifies a new behavior whereby a 6LR injects DAO
messages for unicast addresses (see Section 9) and multicast messages for unicast addresses (see Section 9) and multicast
addresses (see Section 10) on behalf of leaves that are not aware of addresses (see Section 10) on behalf of leaves that are not aware of
RPL. The RUL addresses are exposed as external targets [RFC6550]. RPL. The RUL addresses are exposed as external targets [RFC6550].
Conforming to [USEofRPLinfo], an IPv6-in-IPv6 encapsulation between Conforming to [USEofRPLinfo], an IPv6-in-IPv6 encapsulation between
the 6LR and the RPL Root is used to carry the RPL artifacts and the 6LR and the RPL Root is used to carry the RPL artifacts and
remove them when forwarding outside the RPL domain, e.g., to a RUL. remove them when forwarding outside the RPL domain, e.g., to a RUL.
skipping to change at page 15, line 43 skipping to change at page 15, line 43
The updated format is illustrated in Figure 4. It is backward The updated format is illustrated in Figure 4. It is backward
compatible with the Target Option in [RFC6550]. It is recommended compatible with the Target Option in [RFC6550]. It is recommended
that the updated format be used as a replacement in new that the updated format be used as a replacement in new
implementations in all MOPs in preparation for upcoming Route implementations in all MOPs in preparation for upcoming Route
Ownership Validation mechanisms based on the ROVR, unless the device Ownership Validation mechanisms based on the ROVR, unless the device
or the network is so constrained that this is not 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 |F|X|Flg|ROVRsz | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Target Prefix (Variable Length) | | Target Prefix (Variable Length) |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... Registration Ownership Verifier (ROVR) ... ... Registration Ownership Verifier (ROVR) ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Updated Target Option Figure 4: Updated Target Option
New fields: New fields:
ROVRsz (ROVR Size): Indicates the Size of the ROVR. It MUST be set
to 1, 2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256
bits, 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 1 to indicate that Target Prefix field F: 1-bit flag. Set to 1 to indicate that Target Prefix field
contains the complete (128 bit) IPv6 address of the advertising contains the complete (128 bit) IPv6 address of the advertising
node. node.
Flags: The 3 bits remaining unused in the Flags field are reserved X: 1-bit flag. Set to 1 to request that the Root performs a proxy
for flags. The field MUST be initialized to zero by the sender EDAR/EDAC exchange.
and MUST be ignored by the receiver.
The 'X' flag can only be set to 1 if the DODAG is operating in
Non-Storing Mode and if the Root sets the "Root Proxies EDAR/EDAC
(P)" flag to 1 in the DODAG Configuration Option, see Section 6.2.
The 'X' flag can be set for host routes to RULs and RANs; it can
also be set for internal prefix routes if the 'F' flag is set,
using the node's address in the Target Prefix field to form the
EDAR, but it cannot be used otherwise.
Flg (Flags): The 2 bits remaining unused in the Flags field are
reserved for flags. The field MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
ROVRsz (ROVR Size): Indicates the Size of the ROVR. It MUST be set
to 1, 2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256
bits, 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.
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. Additional Flag in the RPL DODAG Configuration Option 6.2. Additional 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
skipping to change at page 18, line 21 skipping to change at page 18, line 44
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 1 to indicate a rejection. When set to 0, a E: 1-bit flag. set to 1 to indicate a rejection. When set to 0, a
Status value of 0 indicates Success/Unqualified acceptance and Status value of 0 indicates Success/Unqualified acceptance and
other values indicate "not an outright rejection" as per RFC 6550. other 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 to 1 Status Value: 6-bit unsigned integer.
this field transports a Status value defined for IPv6 ND EARO.
When the 'A' flag is set to 0, the Status value is defined for If the 'A' flag is set to 1 this field transports a value defined
RPL. for the 6LoWPAN ND EARO Status.
When the 'A' flag is set to 0, this field transports a Status
Value 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 to 1. The RPL Root MUST in the RPL Status Value and set the 'A' flag to 1. The RPL Root MUST
set the 'E' flag to 1 for all rejection and unknown status codes. set the 'E' flag to 1 for all rejection and unknown status codes.
The status codes in the 1-10 range [RFC8505] are all considered The status codes in the 1-10 range [RFC8505] are all considered
rejections. 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
skipping to change at page 20, line 25 skipping to change at page 21, line 6
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 7 illustrates that, for the Address (re)Registration flow. Figure 7 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 6LR <6LR*> Root 6LBR 6LN/RUL 6LR <6LR*> Root 6LBR
| | | | |<---Using ND--->|<--Using RPL->|<-----Using ND---->|
|<------ND------>|<----RPL----->|<-------ND-------->| | |<-----------Using ND------------->|
| |<----------------ND-------------->|
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | |--------------->| |
| | EDAR | | | EDAR |
| |--------------------------------->| | |--------------------------------->|
| | | | | |
| | EDAC | | | EDAC |
| |<---------------------------------| | |<---------------------------------|
| | DAO | | | | |
| | DAO(X=0) | |
| |------------->| | | |------------->| |
| | | EDAR | | | |
| | |------------------>|
| | | EDAC |
| | |<------------------|
| | DAO-ACK | | | | DAO-ACK | |
| |<-------------| | | |<-------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |<---------------| | |
| | | | | | | |
Figure 7: First RUL Registration Flow Figure 7: 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.
skipping to change at page 21, line 17 skipping to change at page 21, line 43
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 7 for RPL On the first Address Registration, illustrated in Figure 7 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 non-zero status to the 6LN, the NCE is not an NA message with a non-zero 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.
An Address Registration refresh is performed by the 6LN to maintain An Address Registration refresh is performed by the 6LN to keep the
the NCE in the 6LR alive before the lifetime expires. Upon the NCE in the 6LR alive before the lifetime expires. Upon the refresh
refresh of a registration, the 6LR reinjects the corresponding route of a registration, the 6LR reinjects the corresponding route in RPL
in RPL before it expires, as illustrated in Figure 8. before it expires, as illustrated in Figure 8.
6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR 6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | | |--------------->| | |
| | DAO | | | | DAO(X=1) | |
| |------------->| | | |------------->| |
| | | EDAR | | | | EDAR |
| | |------------------>| | | |------------------>|
| | | EDAC | | | | EDAC |
| | |<------------------| | | |<------------------|
| | DAO-ACK | | | | DAO-ACK | |
| |<-------------| | | |<-------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |<---------------| | |
skipping to change at page 22, line 15 skipping to change at page 22, line 44
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 [RFC8929]. Backbone router (6BBR), see Figure 5 in section 3.3 of [RFC8929].
The 6BBR may send a negative ND status, e.g., in an asynchronous The 6BBR may send a negative ND status, e.g., in an asynchronous
NA(EARO) to the 6LBR. NA(EARO) to the 6LBR.
[RFC8929] expects that the 6LBR is collocated with the RPL Root, but [RFC8929] expects that the 6LBR is collocated with the RPL Root, but
if not, the 6LBR MUST forward the status code to the originator of if 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 the 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. Note that a legacy RAN that receives a Non-Storing
DCO that it does not support will ignore it silently, as specified in
section 6 of [RFC6550]. The result is that it may ignore for a while
that it is no more reachable. The situation will be cleared upon the
next Non-Storing DAO exchange if the error is returned in a DAO-ACK.
Figure 9 illustrates this in the case where the 6LBR and the Root are Figure 9 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/EDAC flow.
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 | |
| | |<-------------| | | | |<-------------| |
| | DCO | | | | | DCO | | |
| |<------------| | | | |<------------| | |
| NA(EARO) | | | | | NA(EARO) | | | |
skipping to change at page 23, line 8 skipping to change at page 23, line 36
Target Option transports the ROVR. This way, the same flow as the Target Option transports the ROVR. This way, the same flow as the
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 8. proxy, as illustrated in Figure 8.
Any combination of the logical functions of 6LR, Root, and 6LBR might Any combination of the logical functions of 6LR, Root, and 6LBR might
be collapsed in a single node. be collapsed in a single node.
9.2. Detailed Operation 9.2. Detailed Operation
The following section specify respectively the behaviour of the 6LN The following section specify respectively the behaviour of the 6LN
Acting as RUL, the 6LR Acting as Border router ad serving the 6LN, Acting as RUL, the 6LR Acting as Border router and serving the 6LN,
the RPL Root and the 6LBR in the control flows that enable RPL the RPL Root and the 6LBR in the control flows that enable RPL
routing back to the RUL. routing back to the RUL.
9.2.1. Perspective of the 6LN Acting as RUL 9.2.1. Perspective of the 6LN Acting as RUL
This specification does not alter the operation of a 6LoWPAN ND- This specification builds on the operation of a 6LoWPAN ND-compliant
compliant 6LN/RUL, which is expected to operate as follows: 6LN/RUL, which is expected to operate as follows:
1. The 6LN selects a 6LR that provides reachability services for a 1. The 6LN selects a 6LR that provides reachability services for a
RUL. This is signaled a 6CIO in the RA messages with the L, P RUL. This is signaled by a 6CIO in the RA messages with the L, P
and E flags set to 1 as prescribed by [RFC8505]. and E flags set to 1 as prescribed by [RFC8505].
2. The 6LN obtains an IPv6 global address, either using Stateless 2. 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 [RFC8415]. some other means, such as DHCPv6 [RFC8415].
3. Once it has formed an address, the 6LN registers its address and 3. Once it has formed an address, the 6LN registers its address and
refreshes its registration periodically, early enough within the refreshes its registration periodically, early enough within the
Lifetime of the previous Address Registration, as prescribed by Lifetime of the previous Address Registration, as prescribed by
skipping to change at page 24, line 8 skipping to change at page 24, line 33
Registration Lifetime to the new 6LR(s). In that process, the Registration Lifetime to the new 6LR(s). In that process, the
6LN SHOULD send the NS(EARO) with a non-zero Registration 6LN SHOULD send the NS(EARO) with a non-zero Registration
Lifetime and ensure that at least one succeeds before it sends an Lifetime and ensure that at least one succeeds before it sends an
NS(EARO) that terminates another registration. This avoids the NS(EARO) that terminates another registration. This avoids the
churn related to transient route invalidation in the RPL network churn related to transient route invalidation in the RPL network
above the common parent of the involved 6LRs. above the common parent of the involved 6LRs.
5. Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets 5. 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 MUST consider that establishing the routing services
ensure that one registration succeeds before setting the R Flag via this 6LR failed and it SHOULD attempt to use another 6LR.
to 0. In case of a conflict with the preceding rule on lifetime, The RUL SHOULD ensure that one registration succeeds before
the rule on lifetime has precedence. setting the R Flag to 0. In case of a conflict with the
preceding rule on lifetime, the rule on lifetime has precedence.
6. The 6LN may use any of the 6LRs to which it registered as the 6. 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,
skipping to change at page 24, line 47 skipping to change at page 25, line 24
9.2.2. Perspective of the 6LR Acting as Border router 9.2.2. Perspective of the 6LR Acting as Border router
A 6LR that provides reachability services for a RUL in a RPL network A 6LR that provides reachability services for a RUL in a RPL network
as specified in this document MUST include a 6CIO in its RA messages as specified in this document MUST include a 6CIO in its RA messages
and set the L, P and E flags to 1 as prescribed by [RFC8505]. and set the L, P and E flags to 1 as prescribed by [RFC8505].
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.
registration refreshes, if the RPL Root has indicated that it proxies
the keep-alive EDAR/EDAC exchange with the 6LBR (see Section 6), the
6LR MUST refrain from sending the keep-alive EDAR.
If the R Flag is set to 1 in the NS(EARO), the 6LR SHOULD inject the If the R Flag is set to 1 in the NS(EARO), the 6LR SHOULD inject the
host route in RPL, unless this is barred for other reasons, such as host route in RPL, unless this is barred for other reasons, such as
the saturation of the RPL parents. The 6LR MUST use a RPL Non- the saturation of the RPL parents. The 6LR MUST use a RPL Non-
Storing Mode signaling and the updated Target Option (see Storing Mode signaling and the updated Target Option (see
Section 6.1). The 6LR MUST request a DAO-ACK by setting the 'K' flag Section 6.1). The 6LR SHOULD refrain from setting the 'X' flag to
in the DAO message. Success injecting the route to the RUL's address avoid a redundant EDAR/EDAC flow to the 6LBR. The 6LR MUST request a
is indicated by the 'E' flag set to 0 in the RPL status of the DAO- DAO-ACK by setting the 'K' flag in the DAO message. Success
ACK message. injecting the route to the RUL's address is indicated by the 'E' flag
set to 0 in the RPL status of the DAO-ACK message.
For the registration refreshes, if the RPL Root sets the 'P' flag in
the DODAG Configuration Option to 1, then the 6LR MUST refrain from
sending the keep-alive EDAR; instead, it MUST set the 'X' flag to 1
in the Target Option of the DAO messages, to request that the Root
proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see
Section 6); if the 'P' flag is set to 0 then the 6LR MUST set the 'X'
flag to 0 and handle the EDAR/EDAC flow itself.
The Opaque field in the EARO provides a means to signal which RPL The Opaque field in the EARO provides a means to signal which RPL
Instance is to be used for the DAO advertisements and the forwarding Instance is to be used for the DAO advertisements and the forwarding
of packets sourced at the Registered Address when there is no RPI in of packets sourced at the Registered Address when there is no RPI in
the packet. the packet.
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
skipping to change at page 26, line 28 skipping to change at page 27, line 7
Lifetime is also 0 and the DAO message becomes a No-Path DAO, Lifetime is also 0 and the DAO message becomes a No-Path DAO,
which cleans up the routes down to the RUL's address; this also which cleans up the routes down to the RUL's address; this also
causes the Root as a proxy to send an EDAR message to the 6LBR causes the Root as a proxy to send an EDAR message to the 6LBR
with a Lifetime of 0. with a Lifetime of 0.
5. the Path Sequence in the TIO is set to the TID value found in the 5. the Path Sequence in the TIO is set to the TID value found in the
EARO option. EARO option.
Upon receiving or timing out the DAO-ACK after an implementation- Upon receiving or timing out the DAO-ACK after an implementation-
specific number of retries, the 6LR MUST send the corresponding specific number of retries, the 6LR MUST send the corresponding
NA(EARO) to the RUL. Upon receiving an asynchronous DCO message, if NA(EARO) to the RUL. Upon receiving an asynchronous DCO message, it
a DAO-ACK is pending then the 6LR MUST wait for the DAO-ACK to send MUST send an asynchronous NA(EARO) to the RUL immediately, but still
the NA(EARO) and deliver the status found in the DCO, else it MUST be capable of processing the DAO-ACK if one is pending.
send an asynchronous NA(EARO) to the RUL immediately.
The 6LR MUST set the R Flag to 1 in the NA(EARO) back if and only if The 6LR MUST set the R Flag to 1 in the NA(EARO) back if and only if
the 'E' flag is set to 0, indicating that the 6LR injected the the 'E' flag in the RPL Status is set to 0, indicating that the 6LR
Registered Address in the RPL routing successfully and that the EDAR injected the Registered Address in the RPL routing successfully and
proxy operation succeeded. that the EDAR proxy operation succeeded.
If the 'A' flag in the RPL Status is set to 1, the embedded Status If the 'A' flag in the RPL Status is set to 1, the embedded Status
value is passed back to the RUL in the EARO Status. If the 'E' flag value is passed back to the RUL in the EARO Status. If the 'E' flag
is also set to 1, the registration failed for 6LoWPAN ND related is also set to 1, the registration failed for 6LoWPAN ND related
reasons, and the NCE is removed. reasons, and the NCE is removed.
An error injecting the route causes the 'E' flag to be set to 1. If An error injecting the route causes the 'E' flag to be set to 1. If
the error is not related to ND, the 'A' flag is set to 0. In that the error is not related to ND, the 'A' flag is set to 0. In that
case, the registration succeeds, but the RPL route is not installed. case, the registration succeeds, but the RPL route is not installed.
So the NA(EARO) is returned with a status indicating success but the So the NA(EARO) is returned with a status indicating success but the
skipping to change at page 27, line 17 skipping to change at page 27, line 40
MUST be returned to the 6LN. The EARO Status of 0 MUST also be used MUST be returned to the 6LN. The EARO Status of 0 MUST also be used
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 to 1 in the RPL Status of the DAO-ACK, then If the 'E' flag is set to 1 in the RPL Status of the DAO-ACK, then
the route was not installed and the R flag MUST be set to 0 in the the route was not installed and the R flag MUST be set to 0 in the
NA(EARO). The R flag MUST be set to 0 if the 6LR did not attempt to NA(EARO). The R flag MUST be set to 0 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 transporting an EARO Status
EARO Status value of 5 (Validation Requested), the 6LR MUST challenge value of 5 (Validation Requested), the 6LR MUST challenge the 6LN for
the 6LN for ownership of the address, as described in section 6.1 of ownership of the address, as described in section 6.1 of [RFC8928],
[RFC8928], before the Registration is complete. This flow, before the Registration is complete. This flow, illustrated in
illustrated in Figure 10, ensures that the address is validated Figure 10, ensures that the address is validated before it is
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
Section 11. Section 11.
6LN 6LR Root 6LBR 6LN 6LR Root 6LBR
| | | | | | | |
|<--------------- RA ---------------------| | | |<--------------- RA ---------------------| | |
| | | | | | | |
|------ NS EARO (ROVR=Crypto-ID) -------->| | | |------ NS EARO (ROVR=Crypto-ID) -------->| | |
| | | | | | | |
|<- NA EARO(status=Validation Requested) -| | | |<- NA EARO(status=Validation Requested) -| | |
| | | | | | | |
|----- NS EARO and Proof-of-ownership -->| | |----- NS EARO and Proof-of-ownership -->| |
| | | |
| <validate the Proof> | |
| | |
|<----------- NA EARO (status=10)---<if failed> | |
| | |
| <else> | |
| | | |
| |--------- EDAR ------->| | |--------- EDAR ------->|
| | | | | |
| |<-------- EDAC --------| | |<-------- EDAC --------|
| | | | | |
| | | | | | | |
| |-- DAO --->| | | |-DAO(X=0)->| |
| | |-- EDAR -->|
| | | | | | | |
| | |<-- EDAC --|
| |<- DAO-ACK-| | | |<- DAO-ACK-| |
| | | | | | | |
|<----------- NA EARO (status=0)----------| | | |<----------- NA EARO (status=0)----------| | |
| | | | | | | |
... ...
| | | | | | | |
|------ NS EARO (ROVR=Crypto-ID) -------->| | | |------ NS EARO (ROVR=Crypto-ID) -------->| | |
| |-- DAO --->| | | |-DAO(X=1)->| |
| | |-- EDAR -->| | | |-- EDAR -->|
| | | | | | | |
| | |<-- EDAC --| | | |<-- EDAC --|
| |<- DAO-ACK-| | | |<- DAO-ACK-| |
|<----------- NA EARO (status=0)----------| | | |<----------- NA EARO (status=0)----------| | |
| | | | | | | |
... ...
Figure 10: Address Protection Figure 10: Address Protection
skipping to change at page 29, line 16 skipping to change at page 29, line 26
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 to 1, the 6LR was injecting the host route to the Registered Flag set to 1, 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.
When forwarding a packet from the RUL into the RPL domain, if the
packet does not have an RPI then the 6LR MUST encapsulate the packet
to the Root, and add an RPI. If there is an RPI in the packet, the
6LR MUST rewrite the RPI but it does not need to encapsulate.
9.2.3. Perspective of the RPL Root 9.2.3. Perspective of the RPL Root
A RPL Root MUST set the 'P' flag to 1 in the RPL DODAG Configuration A RPL Root MUST set the 'P' flag to 1 in the RPL DODAG Configuration
Option of the DIO messages that it generates (see Section 6) to Option of the DIO messages that it generates (see Section 6) to
signal that it proxies the EDAR/EDAC exchange and supports the signal that it proxies the EDAR/EDAC exchange and supports the
Updated RPL Target 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) with the 'X' flag set to 1, the Root MUST notify
Root MUST notify the 6LBR by using a proxied EDAR/EDAC exchange. If the 6LBR by using a proxied EDAR/EDAC exchange; if the RPL Root and
if the RPL Root and the 6LBR are integrated, an internal API can be the 6LBR are integrated, an internal API can be used instead.
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
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;
skipping to change at page 32, line 37 skipping to change at page 33, line 9
Figure 12: Next Registration Flow Figure 12: 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
It is worth noting that with [RFC6550], every node in the LLN is RPL- It is worth noting that with [RFC6550], every node in the LLN is RPL-
aware and can inject any RPL-based attack in the network. This aware and can inject any RPL-based attack in the network. This
specification isolates edge nodes that can only interact with the RPL specification improves the situation by isolating edge nodes that can
routers using 6LoWPAN ND, meaning that they cannot perform RPL only interact with the RPL routers using 6LoWPAN ND, meaning that
insider attacks. they cannot perform RPL 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 status code of 4 ("Removed"). 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 B.5 of [RFC8505]. requirement, see Req5.1 in Appendix B.5 of [RFC8505].
In a general manner, the Security Considerations in [RFC7416] In a general manner, the Security Considerations in [RFC6550],
[RFC6775], and [RFC8505] apply to this specification as well. [RFC7416] [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
network by constantly registering and deregistering addresses with network by constantly registering and deregistering addresses with
the R Flag set to 1 in the EARO. the R Flag set to 1 in the EARO.
[RFC8928] updated 6LoWPAN ND with the called Address-Protected [RFC8928] updated 6LoWPAN ND with the called Address-Protected
Neighbor Discovery (AP-ND). AP-ND protects the owner of an address Neighbor Discovery (AP-ND). AP-ND protects the owner of an address
against address theft and impersonation attacks in a Low-Power and against address theft and impersonation attacks in a Low-Power and
Lossy Network (LLN). Nodes supporting th extension compute a Lossy Network (LLN). Nodes supporting th extension compute a
skipping to change at page 33, line 45 skipping to change at page 34, line 15
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. It is also possible for RPLInstanceID where its traffic is placed. It is also possible for
an attacker RUL to include an RPI in the packet. This opens to an attacker RUL to include an RPI in the packet. This opens to
attacks where a RPL instance would be reserved for critical traffic, attacks where a RPL instance would be reserved for critical traffic,
e.g., with a specific bandwidth reservation, that the additional e.g., with a specific bandwidth reservation, that the additional
traffic generated by a rogue may disrupt. The attack may be traffic generated by a rogue may disrupt. The attack may be
alleviated by traditional access control and traffic shaping alleviated by traditional access control and traffic shaping
mechanisms where the 6LR controls the incoming traffic from the 6LN. mechanisms where the 6LR controls the incoming traffic from the 6LN.
More importantly, the 6LR is the node that injects the traffic in the 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 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. used for the traffic coming from the RUL, per its own policy. In
particular, a policy can override the formal language that forces to
use the Opaque field or to rewrite the RPI provided by the RUL, in a
situation where the network administrator finds it relevant.
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.
Section 6.1 indicates that when the length of the ROVR field is Section 6.1 indicates that when the length of the ROVR field is
unknown, the RPL Target Option must be passed on as received in RPL unknown, the RPL Target Option must be passed on as received in RPL
storing Mode. This creates a possible opening for using DAO messages storing Mode. This creates a possible opening for using DAO messages
skipping to change at page 35, line 21 skipping to change at page 35, line 38
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
This document modifies the "RPL Target Option Flags" registry This document modifies the "RPL Target Option Flags" registry
initially created in Section 20.15 of [RFC6550] . The registry now initially created in Section 20.15 of [RFC6550] . The registry now
includes only 4 bits (Section 6.1) and should point to this document includes only 4 bits (Section 6.1) and should point to this document
as an additional reference. The registration procedure doesn't as an additional reference. The registration procedure doesn't
change. change.
Section 6.1 also defines a new entry in the Registry as follows: Section 6.1 also defines 2 new entries in the Registry as follows:
+---------------+--------------------------------+-----------+ +---------------+--------------------------------+-----------+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+---------------+--------------------------------+-----------+ +---------------+--------------------------------+-----------+
| 0 (suggested) | Advertiser address in Full (F) | THIS RFC | | 0 (suggested) | Advertiser address in Full (F) | THIS RFC |
+---------------+--------------------------------+-----------+ +---------------+--------------------------------+-----------+
| 1 (suggested) | Proxy EDAR Requested (X) | THIS RFC |
+---------------+--------------------------------+-----------+
Table 3: RPL Target Option Registry Table 3: RPL Target Option Registry
12.5. New Subregistry for 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, DCO, and DCO-ACK Rejection Status values for use in the RPL DAO-ACK, DCO, and DCO-ACK
messages with the 'A' flag set to 0, under the RPL registry. messages with the 'A' flag set to 0, under the RPL registry.
* Possible values are 6-bit unsigned integers (0..63). * Possible values are 6-bit unsigned integers (0..63).
skipping to change at page 36, line 31 skipping to change at page 37, line 9
+-------+-----------------------+-----------+ +-------+-----------------------+-----------+
| 1..63 | Unassigned | | | 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. Also many thanks to Elwyn Davies, contributions to this document. Also many thanks to Eric Vyncke,
Eric Vyncke, Peter Van der Stok and Carl Wallace for their reviews Erik Kline, Murray Kucherawy, Peter Van der Stok, Carl Wallace, and
and useful comments during the IETF Last Call and the IESG review especially Benjamin Kaduk and Elwyn Davies, for their reviews and
useful comments during the IETF Last Call and the IESG review
sessions. sessions.
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>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
 End of changes. 56 change blocks. 
117 lines changed or deleted 167 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/