draft-ietf-roll-unaware-leaves-23.txt   draft-ietf-roll-unaware-leaves-24.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: 14 May 2021 10 November 2020 Expires: 12 June 2021 9 December 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-23 draft-ietf-roll-unaware-leaves-24
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 14 May 2021. This Internet-Draft will expire on 12 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
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . 9
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 . . . . . . . . . . 10
4.2.3. ROVR . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . 11 4.3.1. RFC 7400 Capability Indication Option . . . . . . . . 11
5. Requirements on the RPL-Unware Leaf . . . . . . . . . . . . . 11 5. Requirements on the RPL-Unware Leaf . . . . . . . . . . . . . 12
5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 11 5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . 13
5.4. Support of the Routing Header . . . . . . . . . . . . . . 12 5.4. Support of the Routing Header . . . . . . . . . . . . . . 13
6. Enhancements to RFC 6550 . . . . . . . . . . . . . . . . . . 13 6. Enhancements to RFC 6550 . . . . . . . . . . . . . . . . . . 13
6.1. Updated RPL Target Option . . . . . . . . . . . . . . . . 13 6.1. Updated RPL Target Option . . . . . . . . . . . . . . . . 14
6.2. New Flag in the RPL DODAG Configuration Option . . . . . 15 6.2. New Flag in the RPL DODAG Configuration Option . . . . . 15
6.3. Updated RPL Status . . . . . . . . . . . . . . . . . . . 16 6.3. Updated RPL Status . . . . . . . . . . . . . . . . . . . 16
7. Enhancements to draft-ietf-roll-efficient-npdao . . . . . . . 17 7. Enhancements to draft-ietf-roll-efficient-npdao . . . . . . . 17
8. Enhancements to RFC 6775 and RFC8505 . . . . . . . . . . . . 17 8. Enhancements to RFC 6775 and RFC8505 . . . . . . . . . . . . 18
9. Protocol Operations for Unicast Addresses . . . . . . . . . . 18 9. Protocol Operations for Unicast Addresses . . . . . . . . . . 18
9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 18 9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 19
9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 21 9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 21
9.2.1. Perspective of the 6LN Acting as RUL . . . . . . . . 21 9.2.1. Perspective of the 6LN Acting as RUL . . . . . . . . 22
9.2.2. Perspective of the 6LR Acting as Border Router . . . 23 9.2.2. Perspective of the 6LR Acting as Border Router . . . 23
9.2.3. Perspective of the RPL Root . . . . . . . . . . . . . 27 9.2.3. Perspective of the RPL Root . . . . . . . . . . . . . 27
9.2.4. Perspective of the 6LBR . . . . . . . . . . . . . . . 28 9.2.4. Perspective of the 6LBR . . . . . . . . . . . . . . . 28
10. Protocol Operations for Multicast Addresses . . . . . . . . . 28 10. Protocol Operations for Multicast Addresses . . . . . . . . . 28
11. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32
12.1. Fixing the Address Registration Option Flags . . . . . . 32 12.1. Fixing the Address Registration Option Flags . . . . . . 32
12.2. Resizing the ARO Status values . . . . . . . . . . . . . 32 12.2. Resizing the ARO Status values . . . . . . . . . . . . . 32
12.3. New RPL DODAG Configuration Option Flag . . . . . . . . 32 12.3. New RPL DODAG Configuration Option Flag . . . . . . . . 33
12.4. RPL Target Option Registry . . . . . . . . . . . . . . . 32 12.4. RPL Target Option Registry . . . . . . . . . . . . . . . 33
12.5. New Subregistry for RPL Non-Rejection Status values . . 33 12.5. New Subregistry for RPL Non-Rejection Status values . . 33
12.6. New Subregistry for RPL Rejection Status values . . . . 33 12.6. New Subregistry for RPL Rejection Status values . . . . 34
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
14. Normative References . . . . . . . . . . . . . . . . . . . . 34 14. Normative References . . . . . . . . . . . . . . . . . . . . 34
15. Informative References . . . . . . . . . . . . . . . . . . . 36 15. Informative References . . . . . . . . . . . . . . . . . . . 36
Appendix A. Example Compression . . . . . . . . . . . . . . . . 37 Appendix A. Example Compression . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
The design of Low Power and Lossy Networks (LLNs) is generally The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, which is the most constrained resource of focused on saving energy, which is the most constrained resource of
all. Other design constraints, such as a limited memory capacity, all. Other design constraints, such as a limited memory capacity,
duty cycling of the LLN devices and low-power lossy transmissions, duty cycling of the LLN devices and low-power lossy transmissions,
derive from that primary concern. derive from that primary concern.
The IETF produced the "Routing Protocol for Low Power and Lossy The IETF produced the "Routing Protocol for Low Power and Lossy
skipping to change at page 4, line 5 skipping to change at page 4, line 5
[RFC4861] [RFC4862] and 6LoWPAN ND [RFC6775] [RFC8505] to maintain [RFC4861] [RFC4862] and 6LoWPAN ND [RFC6775] [RFC8505] to maintain
reachability within a Non-Broadcast Multiple-Access (NBMA) Multi-Link reachability within a Non-Broadcast Multiple-Access (NBMA) Multi-Link
subnet. 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- Section 2 of [USEofRPLinfo] defines the terms RPL Leaf, RPL-Aware-
Unaware Leaf (RUL). A RAL is a Leaf that injects Host routes in RPL Leaf (RAL) and RPL-Unaware Leaf (RUL). A RPL Leaf is a Host attached
to manage the reachability of its IPv6 addresses. Conversely, a RUL to one or more RPL router(s); as such, it relies on the RPL router(s)
does not participate to RPL and cannot inject routes. Section 5 to forward its traffic across the RPL domain but does not forward
details a Host-to-Router interface that the RUL needs to implement to traffic from another node. As opposed to the RAL, the RUL does not
advertise its IPv6 addresses to a Router that supports this participate to RPL, and relies on its RPL router(s) also to inject
specification. This document specifies how the Router injects those the routes to its IPv6 addresses in the RPL domain.
addresses as Host routes in the RPL network on behalf of the RUL.
This specification leverages the Address Registration mechanism A RUL may be unable to participate because it is very energy-
defined in 6LoWPAN ND to enable a 6LoWPAN Node (6LN) acting as a RUL constrained, code-space constrained, or because it would be unsafe to
to interface with a 6LoWPAN Router (6LR) that is also an RPL-Aware let it inject routes in RPL. Using 6LoWPAN ND as opposed to RPL as
router, and request that this router inject a Host route for the the Host-to-Router interface limits the surface of the possible
Registered Address in RPL on its behalf. A RUL may be unable to attacks by the RUL against the RPL domain, and can protect RUL for
participate because it is very energy-constrained, code-space its address ownership.
constrained, or because it would be unsafe to let it inject routes in
RPL. Using 6LowPAN ND as the interface for the RUL limits the This document specifies how the Router injects the Host routes in the
surface of the possible attacks and optionally protects the address RPL domain on behalf of the RUL. Section 5 details how the RUL can
ownership. 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
router is also a 6LoWPAN Router (6LR). Using the 6LoWPAN ND Address
Registration mechanism, the RUL signals that the router must inject a
Host route for the Registered Address.
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 severely energy constrained sensors
window smash sensor (alarm system), and kinetically powered light such as window smash sensor (alarm system), and kinetically powered
switches. Other applications of this specification may include a light switches. Other applications of this specification may include
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 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 in a non-normative fashion the
ND, respectively, that are leveraged in this specification to salient aspects of RPL and 6LoWPAN ND, respectively, that are
provide connectivity to a RUL across a RPL network. leveraged in this specification to provide connectivity to a 6LN
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.
* Section 6 presents the changes made to [RFC6550]; a new behavior * Section 6 presents the changes made to [RFC6550]; a new behavior
is introduced whereby the 6LR advertises the 6LN's addresses in a 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 DAO message based on the ND registration by the 6LN, and the
RPL root performs the EDAR/EDAC exchange with the 6LBR on behalf RPL root performs the EDAR/EDAC exchange with the 6LBR on behalf
of the 6LR; modifications are introduced to some RPL options and of the 6LR; modifications are introduced to some RPL options and
skipping to change at page 5, line 36 skipping to change at page 5, line 36
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",
"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 often uses the following acronyms: This document uses the following acronyms:
AR: Address Resolution (aka Address Lookup) AR: Address Resolution (aka Address Lookup)
ARQ: Automatic Repeat reQuest 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
(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
skipping to change at page 7, line 14 skipping to change at page 7, line 14
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], and "Address Protected Neighbor Discovery
for Low-power and Lossy Networks" [AP-ND]. for Low-power and Lossy Networks" [RFC8928].
3. RPL External Routes and Dataplane Artifacts 3. RPL External Routes and Dataplane Artifacts
Section 4.1 of [USEofRPLinfo] provides a set of rules detailed below Section 4.1 of [USEofRPLinfo] provides a set of rules detailed below
that must be followed for routing packets from and to a RUL. 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 19 skipping to change at page 8, line 19
particular the RUL is expected to ignore the RPL artifacts that are particular the RUL is expected to ignore the RPL artifacts that are
either consumed or not applicable to a Host. either consumed or not applicable to a Host.
A RUL is not expected to support the compression method defined in A RUL is not expected to support the compression method defined in
[RFC8138]. For that reason, the border router uncompresses the [RFC8138]. For that reason, the border router uncompresses the
packet before forwarding over an external route to a RUL packet before forwarding over an external route to a RUL
[USEofRPLinfo]. [USEofRPLinfo].
4. 6LoWPAN Neighbor Discovery 4. 6LoWPAN Neighbor Discovery
This section goes through the 6LoWPAN ND mechanisms that this
specification leverages, as a non-normative reference to the reader.
The full normative text is to be found in [RFC6775], [RFC8505], and
[RFC8928].
4.1. RFC 6775 Address Registration 4.1. RFC 6775 Address Registration
The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861] The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861]
[RFC4862] was defined for serial links and transit media such as [RFC4862] was defined for serial links and transit media such as
Ethernet. It is a reactive protocol that relies heavily on multicast Ethernet. It is a reactive protocol that relies heavily on multicast
operations for Address Discovery (aka Lookup) and Duplicate Address operations for Address Discovery (aka Lookup) and Duplicate Address
Detection (DAD). Detection (DAD).
"Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775]
adapts IPv6 ND for operations over energy-constrained LLNs. The main adapts IPv6 ND for operations over energy-constrained LLNs. The main
skipping to change at page 9, line 23 skipping to change at page 9, line 30
... Registration Ownership Verifier ... ... Registration Ownership Verifier ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: EARO Option Format Figure 1: EARO Option Format
4.2.1. R Flag 4.2.1. R Flag
[RFC8505] introduces the R Flag in the EARO. The Registering Node [RFC8505] introduces the R Flag in the EARO. The Registering Node
sets the R Flag to indicate whether the 6LR should ensure sets the R Flag to indicate whether the 6LR should ensure
reachability for the Registered Address. If the R Flag is not set, reachability for the Registered Address. If the R Flag is set to 0,
then the Registering Node handles the reachability of the Registered then the Registering Node handles the reachability of the Registered
Address by other means. In a RPL network, this means that either it Address by other means. In a RPL network, this means that either it
is a RAN that injects the route by itself or that it uses another RPL is a RAN that injects the route by itself or that it uses another RPL
Router for reachability services. Router for reachability services.
This document specifies how the R Flag is used in the context of RPL. This document specifies how the R Flag is used in the context of RPL.
A RPL Leaf that implements the 6LN functionality in [RFC8505] A RPL Leaf that implements the 6LN functionality in [RFC8505]
requires reachability services for an IPv6 address if and only if it requires reachability services for an IPv6 address if and only if it
sets the R Flag in the NS(EARO) used to register the address to a 6LR sets the R Flag in the NS(EARO) used to register the address to a 6LR
acting as a RPL border Router. Upon receiving the NS(EARO), the RPL acting as a RPL border Router. Upon receiving the NS(EARO), the RPL
Router generates a DAO message for the Registered Address if and only Router generates a DAO message for the Registered Address if and only
if the R flag is set. if the R flag is set to 1.
Section 9.2 specifies additional operations when R flag is set in an Section 9.2 specifies additional operations when R flag is set to 1
EARO that is placed either in an NS or an NA message. in an EARO that is placed either in an NS or an NA message.
4.2.2. TID, "I" Field and Opaque Fields 4.2.2. TID, "I" Field and Opaque Fields
When the T Flag is set, the EARO includes a sequence counter called When the T Flag is set to 1, the EARO includes a sequence counter
Transaction ID (TID), that is needed to fill the Path Sequence Field called Transaction ID (TID), that is needed to fill the Path Sequence
in the RPL Transit Option. This is the reason why the support of Field in the RPL Transit Option. This is the reason why the support
[RFC8505] by the RUL, as opposed to only [RFC6775] is a prerequisite of [RFC8505] by the RUL, as opposed to only [RFC6775] is a
for this specification (more in Section 5.1). The EARO also prerequisite for this specification (more in Section 5.1). The EARO
transports an Opaque field and an associated "I" field that describes also transports an Opaque field and an associated "I" field that
what the Opaque field transports and how to use it. describes what the Opaque field transports and how to use it.
Section 9.2.1 specifies the use of the "I" field and the Opaque field Section 9.2.1 specifies the use of the "I" field and the Opaque field
by a RUL. by a RUL.
4.2.3. ROVR 4.2.3. ROVR
Section 5.3 of [RFC8505] introduces the Registration Ownership Section 5.3 of [RFC8505] introduces the Registration Ownership
Verifier (ROVR) field of variable length from 64 to 256 bits. The Verifier (ROVR) field of variable length from 64 to 256 bits. The
ROVR is a replacement of the EUI-64 in the ARO [RFC6775] that was ROVR is a replacement of the EUI-64 in the ARO [RFC6775] that was
used to identify uniquely an Address Registration with the Link-Layer used to identify uniquely an Address Registration with the Link-Layer
address of the owner but provided no protection against spoofing. address of the owner but provided no protection against spoofing.
"Address Protected Neighbor Discovery for Low-power and Lossy "Address Protected Neighbor Discovery for Low-power and Lossy
Networks" [AP-ND] leverages the ROVR field as a cryptographic proof Networks" [RFC8928] 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. The use of ROVR field enable the 6LR address that is already owned. The use of ROVR field enable the 6LR
to block traffic that is not sourced at an 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 [RFC8928]
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
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
skipping to change at page 11, line 30 skipping to change at page 11, line 44
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 = 1 | Reserved |D|L|B|P|E|G| | Type | Length = 1 | Reserved |D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: 6CIO flags Figure 2: 6CIO flags
A 6LR that can provide reachability services for a RUL in a RPL A 6LR that provides reachability services for a RUL in a RPL network
network as specified in this document MUST include a 6CIO in its RA as specified in this document includes a 6CIO in its RA messages and
messages and set the L, P and E flags as prescribed by [RFC8505]. set the L, P and E flags to 1 as prescribed by [RFC8505], more in
Section 9.2.
5. Requirements on the RPL-Unware Leaf 5. Requirements on the RPL-Unware Leaf
This document provides RPL routing for a RUL. This section describes This document provides RPL routing for a RUL. This section describes
the minimal RPL-independent functionality that the RUL needs to the minimal RPL-independent functionality that the RUL needs to
implement to obtain routing services for its addresses. implement to obtain routing 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 set the "R" and specification, a RUL needs to implement [RFC8505] and set the "R" and
"T" flags in the EARO as discussed in Section 4.2.1 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.3, respectively. Section 9.2.1 specifies new behaviors
for the RUL, e.g., when the R Flag set in a NS(EARO) is not echoed in for the RUL, e.g., when the R Flag set to 1 in a NS(EARO) is not
the NA(EARO), which indicates that the route injection failed. echoed in the NA(EARO), which indicates that the route injection
failed.
The RUL is expected not to request routing services from a Router The RUL is expected to request routing services from a Router only if
that does not originate 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 as discussed in Section 4.3.1, unless configured to E flags all set to 1 as discussed in Section 4.3.1, unless configured
do so. It is suggested that the RUL also implements [AP-ND] 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.
A RUL that may attach to multiple 6LRs is expected to prefer those A RUL that may attach to multiple 6LRs is expected to prefer those
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 refrain from using the address when needs to support both cases and refrain from using the address 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). In order to terminate the IP-in-IP tunnel, the
an IPv6 Host, must be able to decapsulate the tunneled packet and RUL, as an IPv6 Host, would have to be capable of decapsulating the
either drop the inner packet if it is not the final destination, or tunneled packet and either drop the encapsulated packet if it is not
pass it to the upper layer for further processing. Unless it is the final destination, or pass it to the upper layer for further
aware by other means that the RUL can handle IP-in-IP properly, which processing. As indicated in section 4.1 of [USEofRPLinfo], this is
is not mandated by [RFC8504], the Root terminates the IP-in-IP tunnel not mandated by [RFC8504], so the Root typically terminates the IP-
at the parent 6LR. It is thus not necessary for a RUL to support IP- in-IP tunnel at the parent 6LR. It is thus not necessary for a RUL
in-IP decapsulation. to support IP-in-IP decapsulation.
5.3. Support of the HbH Header 5.3. Support of the HbH 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
skipping to change at page 13, line 28 skipping to change at page 13, line 41
new behavior is introduced whereby the RPL Root proxies the EDAR new behavior is introduced whereby the RPL Root proxies the EDAR
message to the 6LBR on behalf of the 6LR (more in Section 8), for any message to the 6LBR on behalf of the 6LR (more in Section 8), for any
Leaf node that implements the 6LN functionality in [RFC8505]. Leaf node that implements the 6LN functionality in [RFC8505].
Section 6.7.7 of [RFC6550] introduces the RPL Target Option, which Section 6.7.7 of [RFC6550] introduces the RPL Target Option, which
can be used in RPL Control messages such as the DAO message to signal can be used in RPL Control messages such as the DAO message to signal
a destination prefix. This document adds the capabilities to a destination prefix. This document adds the capabilities to
transport the ROVR field (see Section 4.2.3) and the IPv6 Address of transport the ROVR field (see Section 4.2.3) and the IPv6 Address of
the prefix advertiser when the Target is a shorter prefix. Their use the prefix advertiser when the Target is a shorter prefix. Their use
is signaled respectively by a new ROVR Size field being non-zero and is signaled respectively by a new ROVR Size field being non-zero and
a new "Advertiser address in Full" 'F' flag set, more in Section 6.1. a new "Advertiser address in Full" 'F' flag set to 1, more in
Section 6.1.
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.
skipping to change at page 14, line 5 skipping to change at page 14, line 17
Operation with multicast support"). This specification extends the Operation with multicast support"). This specification extends the
RPL Root operation to proxy-relay the MLDv2 [RFC3810] operation RPL Root operation to proxy-relay the MLDv2 [RFC3810] operation
between the RUL and the 6LR, more in Section 10. 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 1 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 set to 0, the Target
Prefix field MUST be aligned to the next byte boundary after the size Prefix field MUST be aligned to the next byte boundary after the size
(expressed in bits) indicated by the Prefix Length field. Padding (expressed in bits) indicated by the Prefix Length field. Padding
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.
skipping to change at page 15, line 5 skipping to change at page 15, line 17
ROVRsz (ROVR Size): Indicates the Size of the ROVR. It SHOULD be 1, ROVRsz (ROVR Size): Indicates the Size of the ROVR. It SHOULD be 1,
2, 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. If a legacy Target Option is used, then the value respectively. If a legacy Target Option is used, then the value
must remain 0, as specified in [RFC6550]. In case of a 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 above 4, the size of the ROVR is undetermined and this node cannot
validate the ROVR; an implementation SHOULD propagate the whole validate the ROVR; an implementation SHOULD propagate the whole
Target Option upwards as received to enable the verification by an Target Option upwards as received to enable the verification by an
ancestor that would support the upgraded ROVR. ancestor that would support the upgraded ROVR.
F: 1-bit flag. Set to indicate that Target Prefix field contains F: 1-bit flag. Set to 1 to indicate that Target Prefix field
the complete (128 bit) IPv6 address of the advertising node. contains the complete (128 bit) IPv6 address of the advertising
node.
Flags: The 4 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.
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
skipping to change at page 15, line 35 skipping to change at page 16, line 5
|4 bits | |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' flag is encoded in bit position 1 of the reserved Flags in The 'P' flag is encoded in bit position 1 of the reserved Flags in
the DODAG Configuration Option (counting from bit 0 as the most the DODAG Configuration Option (counting from bit 0 as the most
significant bit) and it is set to 0 in legacy implementations as significant bit) and it is set to 0 in legacy implementations as
specified 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' flag is set to indicate that the Root performs the proxy The 'P' flag is set to 1 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 implementation zero (0) to six (6) only. For a MOP value of 7, the implementation
MUST consider that the Root performs the proxy operation. 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 'P' Flag as set option". Therefore, a legacy parent propagates the 'P' Flag as set
by the Root, and when the 'P' Flag is set, it is transparently to 1 by the Root, and when the 'P' Flag is set to 1, it is
flooded to all the nodes in the DODAG. transparently 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 43 skipping to change at page 17, line 15
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 1 to indicate a rejection. When set to 0, a
value of 0 indicates Success/Unqualified acceptance and other Status value of 0 indicates Success/Unqualified acceptance and
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 this Status Value: 6-bit unsigned integer. If the 'A' flag is set to 1
field transports a Status value defined for IPv6 ND EARO. When this field transports a Status value defined for IPv6 ND EARO.
the 'A' flag is not set, the Status value is defined for RPL. When the 'A' flag is set to 0, 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 to 1. The RPL Root MUST
the 'E' flag for all rejection and unknown status codes. The status set the 'E' flag to 1 for all rejection and unknown status codes.
codes in the 1-10 range [RFC8505] are all considered rejections. The status 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 is processed hop by to support the specification since the message is processed hop by
hop along the path that 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 In the case of a RUL, the 6LR that serves the RUL acts as the RAN
the 6LR that serves as attachment Router for a RUL. A 6LR and a Root that receives the Non-Storing DCO. This specification leverages the
that support this specification MUST implement the Non-Storing DCO. Non-Storing DCO between the Root and 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.
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 two most significant the ND status codes down to 64 values. The two most significant
(leftmost) bits if the original ND status field are now reserved, (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. 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
skipping to change at page 18, line 10 skipping to change at page 18, line 36
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' flag 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' flag is reset, the 6LR MUST generate the periodic EDAR If the 'P' flag is set to 0, 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 20, line 25 skipping to change at page 20, line 42
| | 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 to 1 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 Non-Storing DCO, but the negative Status in the DCO
positive Status in the DAO-ACK regardless of the order in which they supersedes a positive Status in the DAO-ACK regardless of the order
are received. Upon the DAO-ACK - or the DCO if one arrives first - in which they are received. Upon the DAO-ACK - or the DCO if one
the 6LR responds to the RUL with an NA(EARO). arrives first - 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 [RFC8929].
6BBR may send a negative ND status, e.g., in an asynchronous NA(EARO) The 6BBR may send a negative ND status, e.g., in an asynchronous
to the 6LBR. NA(EARO) to the 6LBR.
[6BBR] expects that the 6LBR is collocated with the RPL Root, but if [RFC8929] expects that the 6LBR is collocated with the RPL Root, but
not, the 6LBR MUST forward the status code to the originator of the if not, the 6LBR MUST forward the status code to the originator of
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.
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) |
| | | |<------------| | | | |<------------|
skipping to change at page 21, line 22 skipping to change at page 21, line 37
| |<------------| | | | |<------------| | |
| NA(EARO) | | | | | NA(EARO) | | | |
|<-------------| | | | |<-------------| | | |
| | | | | | | | | |
Figure 8: Asynchronous Issue Figure 8: Asynchronous Issue
If the Root does not proxy, then the EDAC with a negative status If the Root does not proxy, then the EDAC with a negative status
reaches the 6LR directly. In that case, the 6LR MUST clean up the reaches the 6LR directly. In that case, the 6LR MUST clean up the
route using a DAO with a Lifetime of zero, and it MUST propagate the route using a DAO with a Lifetime of zero, and it MUST propagate the
status back to the RUL in a NA(EARO) with the R Flag not set. status back to the RUL in a NA(EARO) with the R Flag set to 0.
The RUL may terminate the registration at any time by using a The RUL may terminate the registration at any time by using a
Registration Lifetime of 0. This specification requires that the RPL Registration Lifetime of 0. This specification requires that the RPL
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 7. proxy, as illustrated in Figure 7.
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.
skipping to change at page 21, line 34 skipping to change at page 22, line 4
The RUL may terminate the registration at any time by using a The RUL may terminate the registration at any time by using a
Registration Lifetime of 0. This specification requires that the RPL Registration Lifetime of 0. This specification requires that the RPL
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 7. proxy, as illustrated in Figure 7.
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
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 does not alter the operation of a 6LoWPAN ND-
compliant 6LN/RUL, which is expected to operate as follows: compliant 6LN/RUL, which is expected to operate as follows:
1. The 6LN obtains an IPv6 global address, either using Stateless 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
and E flags set to 1 as prescribed by [RFC8505].
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].
2. 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
[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 sets the T Flag to 1 as prescribed in
incremented each time and wraps in a lollipop fashion (see [RFC8505]. The TID is incremented each time and wraps in a
section 5.2.1 of [RFC8505], which is fully compatible with lollipop fashion (see section 5.2.1 of [RFC8505], which is fully
section 7.2 of [RFC6550]). compatible with section 7.2 of [RFC6550]).
3. As stated in section 5.2 of [RFC8505], the 6LN can register to 4. 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 may cancel a subset of its the R flag that may differ. The 6LN may cancel a subset of its
registrations, or transfer a registration from one or more old registrations, or transfer a registration from one or more old
6LR(s) to one or more new 6LR(s). To do so, the 6LN sends a 6LR(s) to one or more new 6LR(s). To do so, the 6LN sends a
series of NS(EARO) messages, all with the same TID, with a zero series of NS(EARO) messages, all with the same TID, with a zero
Registration Lifetime to the old 6LR(s) and with a non-zero Registration Lifetime to the old 6LR(s) and with a non-zero
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.
4. 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 SHOULD attempt to use another 6LR. The RUL SHOULD
ensure that one registration succeeds before resetting the R ensure that one registration succeeds before setting the R Flag
Flag. In case of a conflict with the preceding rule on lifetime, to 0. In case of a conflict with the preceding rule on lifetime,
the rule on lifetime has precedence. the rule on lifetime has precedence.
5. 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,
else it MUST leave the Opaque field to zero. else it MUST leave the Opaque field to zero.
skipping to change at page 22, line 51 skipping to change at page 23, line 27
"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 SHOULD indicate the RPLInstanceID of the RPL in a data packet SHOULD indicate the RPLInstanceID of the RPL
Instance where the packet should be forwarded. It is up to the 6LR Instance where the packet should be forwarded. It is up to the 6LR
(e.g., by policy) to use the RPLInstanceID information provided by (e.g., by policy) to use the RPLInstanceID information provided by
the RUL or rewrite it to the selected RPLInstanceID for forwarding 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 inside the RPL domain. All the flags and the Rank field are set to 0
zero as specified by section 11.2 of [RFC6550]. 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
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
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. 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.
If the R Flag is set in the NS(EARO), the 6LR SHOULD inject the Host If the R Flag is set to 1 in the NS(EARO), the 6LR SHOULD inject the
route in RPL, unless this is barred for other reasons, such as the Host route in RPL, unless this is barred for other reasons, such as
saturation of the RPL parents. The 6LR MUST use a RPL Non-Storing the saturation of the RPL parents. The 6LR MUST use a RPL Non-
Mode signaling and the updated Target Option (see Section 6.1). The Storing Mode signaling and the updated Target Option (see
6LR MUST request a DAO-ACK by setting the 'K' flag in the DAO Section 6.1). The 6LR MUST request a DAO-ACK by setting the 'K' flag
message. Success injecting the route to the RUL's address is in the DAO message. Success injecting the route to the RUL's address
indicated by the 'E' flag set to 0 in the RPL status of the DAO-ACK is indicated by the 'E' flag set to 0 in the RPL status of the DAO-
message. ACK message.
The Opaque field in the EARO provides a mean to signal which RPL The Opaque field in the EARO provides a mean 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 23, line 46 skipping to change at page 24, line 27
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, e.g., using a policy least one RPL Instance" [RFC6550] by the 6LR, e.g., using a policy
that maps the 6-tuple into an Instance. 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 set to 0 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).
2. The 6LR indicates one of its global or unique-local IPv6 unicast 2. The 6LR indicates one of its global or unique-local IPv6 unicast
addresses as the Parent Address in the RPL Transit Information addresses as the Parent Address in the RPL Transit Information
Option (TIO) associated with the Target Option Option (TIO) associated with the Target Option
3. The 6LR sets the External 'E' flag in the TIO to indicate that it 3. The 6LR sets the External 'E' flag in the TIO to indicate that it
is redistributing an external target into the RPL network is redistributing an external target into the RPL network
skipping to change at page 24, line 36 skipping to change at page 25, line 21
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, 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 to 1 in the NA(EARO) back if and only if
'E' flag is reset, indicating that the 6LR injected the Registered the 'E' flag is set to 0, indicating that the 6LR injected the
Address in the RPL routing successfully and that the EDAR proxy Registered Address in the RPL routing successfully and that the EDAR
operation succeeded. proxy 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 to 1, the embedded Status
is passed back to the RUL in the EARO Status. If the 'E' flag is value is passed back to the RUL in the EARO Status. If the 'E' flag
also set, the registration failed for 6LoWPAN ND related reasons, and is also set to 1, the registration failed for 6LoWPAN ND related
the NCE is removed. reasons, and 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 to 1. If
error is not related to ND, the 'A' flag is not set. In that case, the error is not related to ND, the 'A' flag is set to 0. In that
the registration succeeds, but the RPL route is not installed. So case, the registration succeeds, but the RPL route is not installed.
the NA(EARO) is returned with a positive status but the R Flag not So the NA(EARO) is returned with a positive status but the R Flag set
set, which means that the 6LN obtained a binding but no route. to 0, which means that the 6LN obtained a binding but no route.
If the 'A' flag is not set in the RPL Status of the DAO-ACK, then the If the 'A' flag is set to 0 in the RPL Status of the DAO-ACK, then
6LoWPAN ND operation succeeded, and an EARO Status of 0 (Success) the 6LoWPAN ND operation succeeded, and an EARO Status of 0 (Success)
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 in the RPL Status of the DAO-ACK, then the If the 'E' flag is set to 1 in the RPL Status of the DAO-ACK, then
route was not installed and the R flag MUST NOT be set in the the route was not installed and the R flag MUST be set to 0 in the
NA(EARO). The R flag MUST NOT be set 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 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 [RFC8928], before the Registration is complete. This flow,
in Figure 9, ensures that the address is validated before it is illustrated in Figure 9, ensures that the address is validated before
injected in the RPL routing. it is 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
| | | | | | | |
skipping to change at page 26, line 42 skipping to change at page 27, line 8
| | | | | | | |
| | |<-- EDAC --| | | |<-- EDAC --|
| |<- DAO-ACK-| | | |<- DAO-ACK-| |
|<----------- NA EARO (status=0)----------| | | |<----------- NA EARO (status=0)----------| | |
| | | | | | | |
... ...
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 set to 0 to signal that it stops providing routing services,
or with the EARO Status 2 "Neighbor Cache full" to signal that it and/or with the EARO Status 2 "Neighbor Cache full" to signal that it
removes the NCE. It may also send a final RA, unicast or multicast, removes the NCE. It may also send a final RA, unicast or multicast,
with a Router Lifetime field of zero, to signal that it stops serving with a Router Lifetime field of zero, to signal that it stops serving
as Router, as specified in section 6.2.5 of [RFC4861]. 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 MUST 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 set to 0 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 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.
9.2.3. Perspective of the RPL Root 9.2.3. Perspective of the RPL Root
A RPL Root MUST set the 'P' flag 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) 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.
skipping to change at page 27, line 51 skipping to change at page 28, line 15
4. The ROVR in the RPL Target Option is copied as is in the EDAR and 4. The ROVR in the RPL Target Option is copied as is in the EDAR and
the ICMP Code Suffix is set to the appropriate value as shown in the ICMP Code Suffix is set to the appropriate value as shown in
Table 4 of [RFC8505] depending on the size of the ROVR field. Table 4 of [RFC8505] depending on the size of the ROVR field.
Upon receiving an EDAC message from the 6LBR, if a DAO is pending, Upon receiving an EDAC message from the 6LBR, if a DAO is pending,
then the Root MUST send a DAO-ACK back to the 6LR. Else, if the then the Root MUST send a DAO-ACK back to the 6LR. Else, if the
Status in the EDAC message is not "Success", then it MUST send an Status in the EDAC message is not "Success", then it MUST send an
asynchronous DCO to the 6LR. asynchronous DCO to the 6LR.
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 to 1.
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 to 1 in the RPL status,
RPL Status value of of "6LBR Registry Saturated" [RFC8505]. and a 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
skipping to change at page 31, line 15 skipping to change at page 31, line 32
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
network by constantly registering and deregistering addresses with network by constantly registering and deregistering addresses with
the R Flag set in the EARO. the R Flag set to 1 in the EARO.
[AP-ND] updated 6LoWPAN ND with the called Address-Protected Neighbor [RFC8928] updated 6LoWPAN ND with the called Address-Protected
Discovery (AP-ND). AP-ND protects the owner of an address against Neighbor Discovery (AP-ND). AP-ND protects the owner of an address
address theft and impersonation attacks in a Low-Power and Lossy against address theft and impersonation attacks in a Low-Power and
Network (LLN). Nodes supporting th extension compute a cryptographic Lossy Network (LLN). Nodes supporting th extension compute a
identifier (Crypto-ID), and use it with one or more of their cryptographic identifier (Crypto-ID), and use it with one or more of
Registered Addresses. The Crypto-ID identifies the owner of the their Registered Addresses. The Crypto-ID identifies the owner of
Registered Address and can be used to provide proof of ownership of the Registered Address and can be used to provide proof of ownership
the Registered Addresses. Once an address is registered with the of the Registered Addresses. Once an address is registered with the
Crypto-ID and a proof of ownership is provided, only the owner of Crypto-ID and a proof of ownership is provided, only the owner of
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. [RFC8928] 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. 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
skipping to change at page 32, line 5 skipping to change at page 32, line 23
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.
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
unknown, the RPL Target Option must be passed on as received in RPL
storing Mode. This creates a possible opening for using DAO messages
as a covert channel. Note that DAO messages are rare and the
overusing that channel could be detected. An implementation SHOULD
notify the network management when a RPL Target Option is receives
with an unknown ROVR field size, to ensure that the situation is
known to the network administrator.
[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 this 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 set to 0, 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 set to 0. 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
skipping to change at page 32, line 46 skipping to change at page 33, line 25
Option Flags for MOP 0..6" [USEofRPLinfo] registry as follows: Option Flags for MOP 0..6" [USEofRPLinfo] registry 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
It is suggested to IANA to indicate that the Flag fields in RPL
options are indexed starting counting from bit 0 as the most
significant bit.
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 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 | | 0 (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 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 reset, 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).
* 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 / RFC 6550 | | 0 | Unqualified acceptance | THIS RFC / RFC 6550 |
+-------+------------------------+---------------------+ +-------+------------------------+---------------------+
| 2..63 | Unassigned | | | 1..63 | Unassigned | |
+-------+------------------------+---------------------+ +-------+------------------------+---------------------+
Table 4: Acceptance values of the RPL Status Table 4: Acceptance values of the RPL Status
12.6. New Subregistry for 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 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).
* 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 |
+-------+-----------------------+-----------+ +-------+-----------------------+-----------+
skipping to change at page 34, line 19 skipping to change at page 34, line 47
+-------+-----------------------+-----------+ +-------+-----------------------+-----------+
| 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. contributions to this document. Also many thanks to Peter Van der
Stok and Carl Wallace for their reviews and useful comments during
the IETF Last Call and the IESG review 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
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
skipping to change at page 35, line 38 skipping to change at page 36, line 20
[RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node [RFC8504] Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504, Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
January 2019, <https://www.rfc-editor.org/info/rfc8504>. January 2019, <https://www.rfc-editor.org/info/rfc8504>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
[AP-ND] Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, [RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and "Address-Protected Neighbor Discovery for Low-Power and
Lossy Networks", Work in Progress, Internet-Draft, draft- Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
ietf-6lo-ap-nd-23, 30 April 2020, 2020, <https://www.rfc-editor.org/info/rfc8928>.
<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-23>.
[USEofRPLinfo] [USEofRPLinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPI Robles, I., Richardson, M., and P. Thubert, "Using RPI
Option Type, Routing Header for Source Routes and IPv6-in- Option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", Work in IPv6 encapsulation in the RPL Data Plane", Work in
Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-41, Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-42,
21 September 2020, <https://tools.ietf.org/html/draft- 12 November 2020, <https://tools.ietf.org/html/draft-ietf-
ietf-roll-useofrplinfo-41>. roll-useofrplinfo-42>.
[EFFICIENT-NPDAO] [EFFICIENT-NPDAO]
Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient
Route Invalidation", Work in Progress, Internet-Draft, Route Invalidation", Work in Progress, Internet-Draft,
draft-ietf-roll-efficient-npdao-18, 15 April 2020, draft-ietf-roll-efficient-npdao-18, 15 April 2020,
<https://tools.ietf.org/html/draft-ietf-roll-efficient- <https://tools.ietf.org/html/draft-ietf-roll-efficient-
npdao-18>. npdao-18>.
15. Informative References 15. Informative References
skipping to change at page 37, line 38 skipping to change at page 38, line 22
and M. Richardson, Ed., "A Security Threat Analysis for and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>. <https://www.rfc-editor.org/info/rfc7416>.
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch", Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
RFC 8025, DOI 10.17487/RFC8025, November 2016, RFC 8025, DOI 10.17487/RFC8025, November 2016,
<https://www.rfc-editor.org/info/rfc8025>. <https://www.rfc-editor.org/info/rfc8025>.
[6BBR] Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
Backbone Router", Work in Progress, Internet-Draft, draft- "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
ietf-6lo-backbone-router-20, 23 March 2020, November 2020, <https://www.rfc-editor.org/info/rfc8929>.
<https://tools.ietf.org/html/draft-ietf-6lo-backbone-
router-20>.
Appendix A. Example Compression Appendix A. Example Compression
Figure 12 illustrates the case in Storing Mode where the packet is Figure 12 illustrates the case in Storing Mode where the packet is
received from the Internet, then the Root encapsulates the packet to received from the Internet, then the Root encapsulates the packet to
insert the RPI and deliver to the 6LR that is the parent and last hop insert the RPI and deliver to the 6LR that is the parent and last hop
to the final destination, which is not known to support [RFC8138]. to the final destination, which is not known to support [RFC8138].
+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
|11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP |11110001|SRH-6LoRH| RPI- |IP-in-IP| NH=1 |11110CPP| UDP | UDP
skipping to change at page 38, line 24 skipping to change at page 38, line 52
The difference with the example presented in Figure 19 of [RFC8138] The difference with the example presented in Figure 19 of [RFC8138]
is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the
compressed address of the 6LR as the destination address of the outer compressed address of the 6LR as the destination address of the outer
IPv6 header. In the [RFC8138] example the destination IP of the IPv6 header. In the [RFC8138] example the destination IP of the
outer header was elided and was implicitly the same address as the outer header was elided and was implicitly the same address as the
destination of the inner header. Type 1 was arbitrarily chosen, and destination of the inner header. Type 1 was arbitrarily chosen, and
the size of 0 denotes a single address in the SRH. the size of 0 denotes a single address in the SRH.
In Figure 12, the source of the IP-in-IP encapsulation is the Root, In Figure 12, the source of the IP-in-IP encapsulation is the Root,
so it is elided in the IP-in-IP 6LoRH. The destination is the parent so it is elided in the IP-in-IP 6LoRH. The destination is the parent
6LR of the destination of the inner packet so it cannot be elided. 6LR of the destination of the encapsulated packet so it cannot be
If the DODAG is operated in Storing Mode, it is the single entry in elided. If the DODAG is operated in Storing Mode, it is the single
the SRH-6LoRH and the SRH-6LoRH Size is encoded as 0. The SRH-6LoRH entry in the SRH-6LoRH and the SRH-6LoRH Size is encoded as 0. The
is the first 6LoRH in the chain. In this particular example, the 6LR SRH-6LoRH is the first 6LoRH in the chain. In this particular
address can be compressed to 2 bytes so a Type of 1 is used. It example, the 6LR address can be compressed to 2 bytes so a Type of 1
results that the total length of the SRH-6LoRH is 4 bytes. is used. It results that the total length of the SRH-6LoRH is 4
bytes.
In Non-Storing Mode, the encapsulation from the Root would be similar In Non-Storing Mode, the encapsulation from the Root would be similar
to that represented in Figure 12 with possibly more hops in the SRH- to that represented in Figure 12 with possibly more hops in the SRH-
6LoRH and possibly multiple SRH-6LoRHs if the various addresses in 6LoRH and possibly multiple SRH-6LoRHs if the various addresses in
the routing header are not compressed to the same format. Note that the routing header are not compressed to the same format. Note that
on the last hop to the parent 6LR, the RH3 is consumed and removed on the last hop to the parent 6LR, the RH3 is consumed and removed
from the compressed form, so the use of Non-Storing Mode vs. Storing from the compressed form, so the use of Non-Storing Mode vs. Storing
Mode is indistinguishable from the packet format. Mode is indistinguishable from the packet format.
The SRH-6LoRHs are followed by RPI-6LoRH and then the IP-in-IP 6LoRH. The SRH-6LoRHs are followed by RPI-6LoRH and then the IP-in-IP 6LoRH.
When the IP-in-IP 6LoRH is removed, all the 6LoRH Headers that When the IP-in-IP 6LoRH is removed, all the 6LoRH Headers that
precede it are also removed. The Paging Dispatch [RFC8025] may also precede it are also removed. The Paging Dispatch [RFC8025] may also
be removed if there was no previous Page change to a Page other than be removed if there was no previous Page change to a Page other than
0 or 1, since the LOWPAN_IPHC is encoded in the same fashion in the 0 or 1, since the LOWPAN_IPHC is encoded in the same fashion in the
default Page 0 and in Page 1. The resulting packet to the default Page 0 and in Page 1. The resulting packet to the
destination is the inner packet compressed with [RFC6282]. destination is the encapsulated packet compressed with [RFC6282].
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
06254 Mougins - Sophia Antipolis 06254 Mougins - Sophia Antipolis
France France
 End of changes. 89 change blocks. 
199 lines changed or deleted 240 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/