draft-ietf-roll-unaware-leaves-24.txt   draft-ietf-roll-unaware-leaves-25.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550, 6775, 8505 (if approved) M. Richardson Updates: 6550, 6775, 8505 (if approved) M. Richardson
Intended status: Standards Track Sandelman Intended status: Standards Track Sandelman
Expires: 12 June 2021 9 December 2020 Expires: 18 June 2021 15 December 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-24 draft-ietf-roll-unaware-leaves-25
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 IPv6 Nodes that implement RFC6775, RFC8505, and
the extensions therein. their extensions therein, but do not support RFC6550.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 June 2021. This Internet-Draft will expire on 18 June 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 6
2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. References . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. References . . . . . . . . . . . . . . . . . . . . . . . 7
3. RPL External Routes and Dataplane Artifacts . . . . . . . . . 7 3. RPL External Routes and Dataplane Artifacts . . . . . . . . . 8
4. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 8 4. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 9
4.1. RFC 6775 Address Registration . . . . . . . . . . . . . . 8 4.1. RFC 6775 Address Registration . . . . . . . . . . . . . . 9
4.2. RFC 8505 Extended Address Registration . . . . . . . . . 9 4.2. RFC 8505 Extended Address Registration . . . . . . . . . 9
4.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. TID, "I" Field and Opaque Fields . . . . . . . . . . 10 4.2.2. TID, "I" Field and Opaque Fields . . . . . . . . . . 10
4.2.3. ROVR . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.3. Route Ownership Verifier . . . . . . . . . . . . . . 11
4.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 10 4.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 11
4.3.1. RFC 7400 Capability Indication Option . . . . . . . . 11 4.3.1. RFC 7400 Capability Indication Option . . . . . . . . 12
5. Requirements on the RPL-Unware Leaf . . . . . . . . . . . . . 12 5. Requirements on the RPL-Unware leaf . . . . . . . . . . . . . 12
5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 12 5.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 12
5.2. Support of IPv6 Encapsulation . . . . . . . . . . . . . . 12 5.2. Support of IPv6 Encapsulation . . . . . . . . . . . . . . 13
5.3. Support of the HbH Header . . . . . . . . . . . . . . . . 13 5.3. Support of the Hop-by-Hop Header . . . . . . . . . . . . 13
5.4. Support of the Routing Header . . . . . . . . . . . . . . 13 5.4. Support of the Routing Header . . . . . . . . . . . . . . 13
6. Enhancements to RFC 6550 . . . . . . . . . . . . . . . . . . 13 6. Enhancements to RFC 6550 . . . . . . . . . . . . . . . . . . 14
6.1. Updated RPL Target Option . . . . . . . . . . . . . . . . 14 6.1. Updated RPL Target Option . . . . . . . . . . . . . . . . 14
6.2. New Flag in the RPL DODAG Configuration Option . . . . . 15 6.2. Additional Flag in the RPL DODAG Configuration Option . . 16
6.3. Updated RPL Status . . . . . . . . . . . . . . . . . . . 16 6.3. Updated RPL Status . . . . . . . . . . . . . . . . . . . 17
7. Enhancements to draft-ietf-roll-efficient-npdao . . . . . . . 17 7. Enhancements to draft-ietf-roll-efficient-npdao . . . . . . . 18
8. Enhancements to RFC 6775 and RFC8505 . . . . . . . . . . . . 18 8. Enhancements to RFC 6775 and RFC8505 . . . . . . . . . . . . 19
9. Protocol Operations for Unicast Addresses . . . . . . . . . . 18 9. Protocol Operations for Unicast Addresses . . . . . . . . . . 19
9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 19 9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 20
9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 21 9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 23
9.2.1. Perspective of the 6LN Acting as RUL . . . . . . . . 22 9.2.1. Perspective of the 6LN Acting as RUL . . . . . . . . 23
9.2.2. Perspective of the 6LR Acting as Border Router . . . 23 9.2.2. Perspective of the 6LR Acting as Border router . . . 24
9.2.3. Perspective of the RPL Root . . . . . . . . . . . . . 27 9.2.3. Perspective of the RPL Root . . . . . . . . . . . . . 29
9.2.4. Perspective of the 6LBR . . . . . . . . . . . . . . . 28 9.2.4. Perspective of the 6LBR . . . . . . . . . . . . . . . 30
10. Protocol Operations for Multicast Addresses . . . . . . . . . 28 10. Protocol Operations for Multicast Addresses . . . . . . . . . 30
11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12.1. Fixing the Address Registration Option Flags . . . . . . 32 12.1. Fixing the Address Registration Option Flags . . . . . . 34
12.2. Resizing the ARO Status values . . . . . . . . . . . . . 32 12.2. Resizing the ARO Status values . . . . . . . . . . . . . 34
12.3. New RPL DODAG Configuration Option Flag . . . . . . . . 33 12.3. New RPL DODAG Configuration Option Flag . . . . . . . . 34
12.4. RPL Target Option Registry . . . . . . . . . . . . . . . 33 12.4. RPL Target Option Registry . . . . . . . . . . . . . . . 35
12.5. New Subregistry for RPL Non-Rejection Status values . . 33 12.5. New Subregistry for RPL Non-Rejection Status values . . 35
12.6. New Subregistry for RPL Rejection Status values . . . . 34 12.6. New Subregistry for RPL Rejection Status values . . . . 36
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
14. Normative References . . . . . . . . . . . . . . . . . . . . 34 14. Normative References . . . . . . . . . . . . . . . . . . . . 36
15. Informative References . . . . . . . . . . . . . . . . . . . 36 15. Informative References . . . . . . . . . . . . . . . . . . . 38
Appendix A. Example Compression . . . . . . . . . . . . . . . . 38 Appendix A. Example Compression . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
The design of Low Power and Lossy Networks (LLNs) is generally The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, which is the most constrained resource of focused on saving energy, which is the most constrained resource of
all. Other design constraints, such as a limited memory capacity, all. Other design constraints, such as a limited memory capacity,
duty cycling of the LLN devices and low-power lossy transmissions, duty cycling of the LLN devices and low-power lossy transmissions,
derive from that primary concern. derive from that primary concern.
The IETF produced the "Routing Protocol for Low Power and Lossy The IETF produced the "Routing Protocol for Low Power and Lossy
skipping to change at page 3, line 46 skipping to change at page 3, line 46
lazy control that creates the routes proactively, but may only fix lazy control that creates the routes proactively, but may only fix
them reactively, upon actual traffic. The result is that RPL them reactively, upon actual traffic. The result is that RPL
provides reachability for most of the LLN nodes, most of the time, provides reachability for most of the LLN nodes, most of the time,
but may not converge in the classical sense. but may not converge in the classical sense.
RPL can be deployed in conjunction with IPv6 Neighbor Discovery (ND) RPL can be deployed in conjunction with IPv6 Neighbor Discovery (ND)
[RFC4861] [RFC4862] and 6LoWPAN ND [RFC6775] [RFC8505] to maintain [RFC4861] [RFC4862] and 6LoWPAN ND [RFC6775] [RFC8505] to maintain
reachability within a Non-Broadcast 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 receive/originate
acting as Hosts in the data-plane. In [RFC6550] terms, an IPv6 Host packets, acting as hosts in the data-plane. In [RFC6550] terms, an
[RFC8504] that is reachable over the RPL network is called a Leaf. IPv6 host [RFC8504] that is reachable over the RPL network is called
a leaf.
Section 2 of [USEofRPLinfo] defines the terms RPL Leaf, RPL-Aware- Section 2 of [USEofRPLinfo] defines the terms RPL leaf, RPL-Aware-
Leaf (RAL) and RPL-Unaware Leaf (RUL). A RPL Leaf is a Host attached leaf (RAL) and RPL-Unaware Leaf (RUL). A RPL leaf is a host attached
to one or more RPL router(s); as such, it relies on the RPL router(s) to one or more RPL router(s); as such, it relies on the RPL router(s)
to forward its traffic across the RPL domain but does not forward to forward its traffic across the RPL domain but does not forward
traffic from another node. As opposed to the RAL, the RUL does not traffic from another node. As opposed to the RAL, the RUL does not
participate to RPL, and relies on its RPL router(s) also to inject participate to RPL, and relies on its RPL router(s) also to inject
the routes to its IPv6 addresses in the RPL domain. the routes to its IPv6 addresses in the RPL domain.
A RUL may be unable to participate because it is very energy- A RUL may be unable to participate because it is very energy-
constrained, code-space constrained, or because it would be unsafe to constrained, code-space constrained, or because it would be unsafe to
let it inject routes in RPL. Using 6LoWPAN ND as opposed to RPL as let it inject routes in RPL. Using 6LoWPAN ND as opposed to RPL as
the Host-to-Router interface limits the surface of the possible the host-to-router interface limits the surface of the possible
attacks by the RUL against the RPL domain, and can protect RUL for attacks by the RUL against the RPL domain, and can protect RUL for
its address ownership. its address ownership.
This document specifies how the Router injects the Host routes in the This document specifies how the router injects the host routes in the
RPL domain on behalf of the RUL. Section 5 details how the RUL can RPL domain on behalf of the RUL. Section 5 details how the RUL can
leverage 6LoWPAN ND to obtain the routing services from the router. leverage 6LoWPAN ND to obtain the routing services from the router.
In that model, the RUL is also a 6LoWPAN Node (6LN) and the RPL-Aware In that model, the RUL is also a 6LoWPAN Node (6LN) and the RPL-Aware
router is also a 6LoWPAN Router (6LR). Using the 6LoWPAN ND Address router is also a 6LoWPAN router (6LR). Using the 6LoWPAN ND Address
Registration mechanism, the RUL signals that the router must inject a Registration mechanism, the RUL signals that the router must inject a
Host route for the Registered Address. host route for the Registered Address.
------+---------
| Internet
|
+-----+
| | <------------- 6LBR / RPL Root
+-----+ ^
| |
o o o o | RPL
o o o o o o o o |
o o o o o o o o o o | +
o o o o o o o |
o o o o o o o o o | 6LoWPAN ND
o o o o o o |
o o o o v
o o o <------------- 6LR / RPL Border router
^
| 6LoWPAN ND only
v
u <------------- 6LN / RPL-Unaware Leaf
Figure 1: Injecting Routes on behalf of RULs
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 severely energy constrained sensors Examples of possible RULs include severely energy constrained sensors
such as window smash sensor (alarm system), and kinetically powered such as window smash sensor (alarm system), and kinetically powered
light switches. Other applications of this specification may include light switches. Other applications of this specification may include
a smart grid network that controls appliances - such as washing a smart grid network that controls appliances - such as washing
skipping to change at page 5, line 41 skipping to change at page 6, line 19
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. Glossary 2.2. Glossary
This document uses the following acronyms: This document uses the following acronyms:
AR: Address Resolution (aka Address Lookup) 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
6LBR: 6LoWPAN Border router
(E)ARO: (Extended) Address Registration Option (E)ARO: (Extended) Address Registration Option
(E)DAR: (Extended) Duplicate Address Request (E)DAR: (Extended) Duplicate Address Request
(E)DAC: (Extended) Duplicate Address Confirmation (E)DAC: (Extended) Duplicate Address Confirmation
DAD: Duplicate Address Detection DAD: Duplicate Address Detection
DAO: Destination Advertisement Object (a RPL message) DAO: Destination Advertisement Object (a RPL message)
DCO: Destination Cleanup Object (a RPL message) DCO: Destination Cleanup Object (a RPL message)
DIS: DODAG Information solicitation (a RPL message) DIS: DODAG Information solicitation (a RPL message)
DIO: DODAG Information Object (a RPL message) DIO: DODAG Information Object (a RPL message)
DODAG: Destination-Oriented Directed Acyclic Graph DODAG: Destination-Oriented Directed Acyclic Graph
LLN: Low-Power and Lossy Network LLN: Low-Power and Lossy Network
MOP: RPL Mode of Operation
NA: Neighbor Advertisement NA: Neighbor Advertisement
NCE: Neighbor Cache Entry NCE: Neighbor Cache Entry
ND: Neighbor Discovery ND: Neighbor Discovery
NS: Neighbor solicitation NS: Neighbor solicitation
RA: Router Advertisement RA: router Advertisement
ROVR: Registration Ownership Verifier ROVR: Registration Ownership Verifier
RPI: RPL Packet Information RPI: RPL Packet Information
RAL: RPL-Aware Leaf RAL: RPL-aware Leaf
RAN: RPL-Aware Node (either a RPL Router or a RPL-Aware Leaf) RAN: RPL-Aware Node (either a RPL router or a RPL-aware Leaf)
RUL: RPL-Unaware Leaf RUL: RPL-Unaware Leaf
SRH: Source-Routing Header
TID: Transaction ID (a sequence counter in the EARO) TID: Transaction ID (a sequence counter in the EARO)
2.3. References 2.3. References
The Terminology used in this document is consistent with and The Terminology used in this document is consistent with and
incorporates that described in "Terms Used in Routing for Low-Power incorporates that described in "Terms Used in Routing for Low-Power
and Lossy Networks (LLNs)" [RFC7102]. A glossary of classical and Lossy Networks (LLNs)" [RFC7102]. A glossary of classical
6LoWPAN acronyms is given in Section 2.2. Other terms in use in LLNs 6LoWPAN acronyms is given in Section 2.2. Other terms in use in LLNs
are found in "Terminology for Constrained-Node Networks" [RFC7228]. are found in "Terminology for Constrained-Node Networks" [RFC7228].
This specification uses the terms 6LN and 6LR to refer specifically This specification uses the terms 6LN and 6LR to refer specifically
to nodes that implement the 6LN and 6LR roles in 6LoWPAN ND and does to nodes that implement the 6LN and 6LR roles in 6LoWPAN ND and does
not expect other functionality such as 6LoWPAN Header Compression not expect other functionality such as 6LoWPAN Header Compression
[RFC6282] from those nodes. [RFC6282] from those nodes.
"RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by
a RPLInstanceID) are defined in "RPL: IPv6 Routing Protocol for a RPLInstanceID), "up", "down" are defined in "RPL: IPv6 Routing
Low-Power and Lossy Networks" [RFC6550]. The RPI is the abstract Protocol for Low-Power and Lossy Networks" [RFC6550]. The RPI is the
information that RPL defines to be placed in data packets, e.g., as abstract information that RPL defines to be placed in data packets,
the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header. By e.g., as the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header.
extension, the term "RPI" is often used to refer to the RPL Option By extension, the term "RPI" is often used to refer to the RPL Option
itself. The DODAG Information solicitation (DIS), Destination itself. The DODAG Information solicitation (DIS), Destination
Advertisement Object (DAO) and DODAG Information Object (DIO) Advertisement Object (DAO) and DODAG Information Object (DIO)
messages are also specified in [RFC6550]. The Destination Cleanup messages are also specified in [RFC6550]. The Destination Cleanup
Object (DCO) message is defined in [EFFICIENT-NPDAO]. Object (DCO) message is defined in [EFFICIENT-NPDAO].
This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware This document uses the terms RPL-Unaware Leaf (RUL), RPL-Aware Node
Leaf (RAL) consistently with [USEofRPLinfo]. The term RPL-Aware Node (RAN) and RPL aware Leaf (RAL) consistently with [USEofRPLinfo]. A
(RAN) is introduced to refer to a node that is either an RAL or a RPL RAN is either an RAL or a RPL router. As opposed to a RUL, a RAN
Router. As opposed to a RUL, a RAN manages the reachability of its manages the reachability of its addresses and prefixes by injecting
addresses and prefixes by injecting them in RPL by itself. them in RPL by itself.
In this document, readers will encounter terms and concepts that are In this document, readers will encounter terms and concepts that are
discussed in the following documents: discussed in the following documents:
Classical IPv6 ND: "Neighbor Discovery for IP version 6" [RFC4861] Classical IPv6 ND: "Neighbor Discovery for IP version 6" [RFC4861]
and "IPv6 Stateless Address Autoconfiguration" [RFC4862], and "IPv6 Stateless Address Autoconfiguration" [RFC4862],
6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power 6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606] and Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606] and
"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" [RFC8928]. 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 summarized
that must be followed for routing packets from and to a RUL. below that must be followed for routing packets from and to a RUL.
A 6LR that acts as a border Router for external routes advertises A 6LR that acts as a border router for external routes advertises
them using Non-Storing Mode DAO messages that are unicast directly to them using Non-Storing Mode DAO messages that are unicast directly to
the Root, even if the DODAG is operated in Storing Mode. Non-Storing the Root, even if the DODAG is operated in Storing Mode. Non-Storing
Mode routes are not visible inside the RPL domain and all packets are Mode routes are not visible inside the RPL domain and all packets are
routed via the Root. The RPL Root tunnels the packets directly to routed via the Root. The RPL Root tunnels the packets directly to
the 6LR that advertised the external route, which decapsulates and the 6LR that advertised the external route, which decapsulates and
forwards the original (inner) packet. forwards the original (inner) packet.
The RPL Non-Storing MOP signaling and the associated IP-in-IP The RPL Non-Storing MOP signaling and the associated IPv6-in-IPv6
encapsulated packets appear as normal traffic to the intermediate encapsulated packets appear as normal traffic to the intermediate
Routers. The support of external routes only impacts the Root and routers. The support of external routes only impacts the Root and
the 6LR. It can be operated with legacy intermediate Routers and the 6LR. It can be operated with legacy intermediate routers and
does not add to the amount of state that must be maintained in those does not add to the amount of state that must be maintained in those
Routers. A RUL is an example of a destination that is reachable via routers. A RUL is an example of a destination that is reachable via
an external route that happens to be also a Host route. an external route that happens to be also a host route.
The RPL data packets always carry a Hop-by-Hop Header to transport a The RPL data packets typically carry a Hop-by-Hop Header with a RPL
RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates Option [RFC6553] that contains the Packet Information (RPI) defined
its packets with an RPI, the 6LR needs to tunnel them to the Root to in section 11.2 of [RFC6550]. Unless the RUL already placed a RPL
add the RPI. As a rule of a thumb and except for the very special Option in outer header chain, the packets from and to the RUL are
case above, the packets from and to a RUL are always encapsulated encapsulated using an IPv6-in-IPv6 tunnel between the Root and the
using an IP-in-IP tunnel between the Root and the 6LR that serves the 6LR that serves the RUL (see sections 7 and 8 of [USEofRPLinfo] for
RUL (see sections 7 and 8 of [USEofRPLinfo] for details). If the details). If the packet from the RUL has an RPI, the 6LR as a RPL
packet from the RUL has an RPI, the 6LR as a RPL border router SHOULD border router SHOULD rewrite the RPI to indicate the selected
rewrite the RPI to indicate the selected Instance and set the flags, Instance and set the flags, but it does not need to encapsulate the
but it does not need to encapsulate the packet. packet.
In Non-Storing Mode, packets going down carry a Source Routing Header In Non-Storing Mode, packets going down carry a Source Routing Header
(SRH). The IP-in-IP encapsulation, the RPI and the SRH are (SRH). The IPv6-in-IPv6 encapsulation, the RPI and the SRH are
collectively called the "RPL artifacts" and can be compressed using collectively called the "RPL artifacts" and can be compressed using
[RFC8138]. Appendix A presents an example compressed format for a [RFC8138]. Appendix A presents an example compressed format for a
packet forwarded by the Root to a RUL in a Storing Mode DODAG. packet forwarded by the Root to a RUL in a Storing Mode DODAG.
The inner packet that is forwarded to the RUL may carry some RPL The inner packet that is forwarded to the RUL may carry some RPL
artifacts, e.g., an RPI if the original packet was generated with it, artifacts, e.g., an RPI if the original packet was generated with it,
and an SRH in a Non-Storing Mode DODAG. [USEofRPLinfo] expects the and an SRH in a Non-Storing Mode DODAG. [USEofRPLinfo] expects the
RUL to support the basic "IPv6 Node Requirements" [RFC8504]. In RUL to support the basic "IPv6 Node Requirements" [RFC8504]. In
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 it 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 This section goes through the 6LoWPAN ND mechanisms that this
specification leverages, as a non-normative reference to the reader. specification leverages, as a non-normative reference to the reader.
The full normative text is to be found in [RFC6775], [RFC8505], and The full normative text is to be found in [RFC6775], [RFC8505], and
[RFC8928]. [RFC8928].
4.1. RFC 6775 Address Registration 4.1. RFC 6775 Address Registration
skipping to change at page 8, line 43 skipping to change at page 9, line 36
adapts IPv6 ND for operations over energy-constrained LLNs. The main adapts IPv6 ND for operations over energy-constrained LLNs. The main
functions of [RFC6775] are to proactively establish the Neighbor functions of [RFC6775] are to proactively establish the Neighbor
Cache Entry (NCE) in the 6LR and to prevent address duplication. To Cache Entry (NCE) in the 6LR and to prevent address duplication. To
that effect, [RFC6775] introduces a new unicast Address Registration that effect, [RFC6775] introduces a new unicast Address Registration
mechanism that contributes to reducing the use of multicast messages mechanism that contributes to reducing the use of multicast messages
compared to the classical IPv6 ND protocol. compared to the classical IPv6 ND protocol.
[RFC6775] defines a new Address Registration Option (ARO) that is [RFC6775] defines a new Address Registration Option (ARO) that is
carried in the unicast Neighbor solicitation (NS) and Neighbor carried in the unicast Neighbor solicitation (NS) and Neighbor
Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the
6LoWPAN Router (6LR). It also defines the Duplicate Address Request 6LoWPAN router (6LR). It also defines the Duplicate Address Request
(DAR) and Duplicate Address Confirmation (DAC) messages between the (DAR) and Duplicate Address Confirmation (DAC) messages between the
6LR and the 6LoWPAN Border Router (6LBR). In an LLN, the 6LBR is the 6LR and the 6LoWPAN Border router (6LBR). In an LLN, the 6LBR is the
central repository of all the Registered Addresses in its domain and central repository of all the Registered Addresses in its domain and
the source of truth for uniqueness and ownership. the source of truth for uniqueness and ownership.
4.2. RFC 8505 Extended Address Registration 4.2. RFC 8505 Extended Address Registration
"Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505] "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505]
updates the behavior of RFC 6775 to enable a generic Address updates the behavior of RFC 6775 to enable a generic Address
Registration to services such as routing and ND proxy, and defines Registration to services such as routing and ND proxy, and defines
the Extended Address Registration Option (EARO) as shown in Figure 1: the Extended Address Registration Option (EARO) as shown in Figure 2:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | Opaque | | Type | Length | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | I |R|T| TID | Registration Lifetime | | Rsvd | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... Registration Ownership Verifier ... ... Registration Ownership Verifier ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: EARO Option Format Figure 2: 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 set to 0, 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 to 1. if the R flag is set to 1.
Section 9.2 specifies additional operations when R flag is set to 1 Section 9.2 specifies additional operations when R flag is set to 1
in an 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 to 1, the EARO includes a sequence counter When the T Flag is set to 1, the EARO includes a sequence counter
called Transaction ID (TID), that is needed to fill the Path Sequence called Transaction ID (TID), that is needed to fill the Path Sequence
Field in the RPL Transit Option. This is the reason why the support Field in the RPL Transit Option. This is the reason why the support
of [RFC8505] by the RUL, as opposed to only [RFC6775] is a of [RFC8505] by the RUL, as opposed to only [RFC6775] is a
prerequisite for this specification (more in Section 5.1). The EARO prerequisite for this specification)/; this requirement is fully
also transports an Opaque field and an associated "I" field that explained in Section 5.1. The EARO also transports an Opaque field
describes what the Opaque field transports and how to use it. and an associated "I" field that 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. Route Ownership Verifier
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" [RFC8928] 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 enables 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 [RFC8928] 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
to create, refresh, and delete the corresponding state in the 6LBR. to create, refresh, and delete the corresponding state in the 6LBR.
The exchange is protected by the retry mechanism (ARQ) specified in The exchange is protected by the retry mechanism (ARQ) specified in
8.2.6 of [RFC6775], though in an LLN, a duration longer than the Section 8.2.6 of [RFC6775], though in an LLN, a duration longer than
RETRANS_TIMER [RFC4861] of 1 second may be necessary to cover the the default value of the RetransTimer (RETRANS_TIMER) [RFC4861] of 1
Turn Around Trip delay between the 6LR and the 6LBR. second may be necessary to cover the round trip delay between the 6LR
and the 6LBR.
RPL [RFC6550] specifies a periodic DAO from the 6LN all the way to RPL [RFC6550] specifies a periodic DAO from the 6LN all the way to
the Root that maintains the routing state in the RPL network for the the Root that maintains the routing state in the RPL network for the
lifetime indicated by the source of the DAO. This means that for lifetime indicated by the source of the DAO. This means that for
each address, there are two keep-alive messages that traverse the each address, there are two keep-alive messages that traverse the
whole network, one to the Root and one to the 6LBR. whole network, one to the Root and one to the 6LBR.
This specification avoids the periodic EDAR/EDAC exchange across the This specification avoids the periodic EDAR/EDAC exchange across the
LLN. The 6LR turns the periodic NS(EARO) from the RUL into a DAO LLN. The 6LR turns the periodic NS(EARO) from the RUL into a DAO
message to the Root on every refresh, but it only generates the EDAR message to the Root on every refresh, but it only generates the EDAR
upon the first registration, for the purpose of DAD, which must be upon the first registration, for the purpose of DAD, which must be
verified before the address is injected in RPL. Upon the DAO verified before the address is injected in RPL. Upon the DAO
message, the Root proxies the EDAR exchange to refresh the state at message, the Root proxies the EDAR exchange to refresh the state at
the 6LBR on behalf of the 6LR, as illustrated in Figure 7. the 6LBR on behalf of the 6LR, as illustrated in Figure 8 in
Section 9.1.
4.3.1. RFC 7400 Capability Indication Option 4.3.1. RFC 7400 Capability Indication Option
"6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)" [RFC7400] defines the Wireless Personal Area Networks (6LoWPANs)" [RFC7400] defines the
6LoWPAN Capability Indication Option (6CIO) that enables a node to 6LoWPAN Capability Indication Option (6CIO) that enables a node to
expose its capabilities in Router Advertisement (RA) messages. expose its capabilities in router Advertisement (RA) messages.
[RFC8505] defines a number of bits in the 6CIO, in particular: [RFC8505] defines a number of bits in the 6CIO, in particular:
L: Node is a 6LR. L: Node is a 6LR.
E: Node is an IPv6 ND Registrar -- i.e., it supports registrations E: Node is an IPv6 ND Registrar -- i.e., it supports registrations
based on EARO. based on EARO.
P: Node is a Routing Registrar, -- i.e., an IPv6 ND Registrar that P: Node is a Routing Registrar, -- i.e., an IPv6 ND Registrar that
also provides reachability services for the Registered Address. also provides reachability services for the Registered Address.
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 3: 6CIO flags
A 6LR that provides reachability services for a RUL in a RPL network A 6LR that provides reachability services for a RUL in a RPL network
as specified in this document includes a 6CIO in its RA messages and as specified in this document includes a 6CIO in its RA messages and
set the L, P and E flags to 1 as prescribed by [RFC8505], more in set the L, P and E flags to 1 as prescribed by [RFC8505]; this is
Section 9.2. fully explained 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 describes how RPL routing can be extended to reach a
the minimal RPL-independent functionality that the RUL needs to RUL. This section specifies the minimal RPL-independent
implement to obtain routing services for its addresses. functionality that the RUL needs to 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 sets the "R"
"T" flags in the EARO to 1 as discussed in Section 4.2.1 and and "T" flags in the EARO to 1 as discussed in Section 4.2.1 and
Section 4.2.3, respectively. Section 9.2.1 specifies new behaviors Section 4.2.3, respectively. Section 9.2.1 specifies new behaviors
for the RUL, e.g., when the R Flag set to 1 in a NS(EARO) is not for the RUL, e.g., when the R Flag set to 1 in a NS(EARO) is not
echoed in the NA(EARO), which indicates that the route injection echoed in the NA(EARO), which indicates that the route injection
failed. failed.
The RUL is expected to request routing services from a Router only if The RUL is expected to request routing services from a router only if
that router originates RA messages with a CIO that has the L, P, and that router originates RA messages with a CIO that has the L, P, and
E flags all set to 1 as discussed in Section 4.3.1, unless configured E flags all set to 1 as discussed in Section 4.3.1, unless configured
to do so. It is suggested that the RUL also implements [RFC8928] to to do so. It is suggested that the RUL also implements [RFC8928] to
protect the ownership of its addresses. protect the ownership of its addresses.
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
skipping to change at page 12, line 44 skipping to change at page 13, line 28
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). In order to terminate the IP-in-IP tunnel, the (designated as 6LR). In order to terminate the IPv6-in-IPv6 tunnel,
RUL, as an IPv6 Host, would have to be capable of decapsulating the the RUL, as an IPv6 host, would have to be capable of decapsulating
tunneled packet and either drop the encapsulated packet if it is not the tunneled packet and either drop the encapsulated packet if it is
the final destination, or pass it to the upper layer for further not the final destination, or pass it to the upper layer for further
processing. As indicated in section 4.1 of [USEofRPLinfo], this is processing. As indicated in section 4.1 of [USEofRPLinfo], this is
not mandated by [RFC8504], so the Root typically terminates the IP- not mandated by [RFC8504], so the Root typically terminates the IPv6-
in-IP tunnel at the parent 6LR. It is thus not necessary for a RUL in-IPv6 tunnel at the parent 6LR. It is thus not necessary for a RUL
to support IP-in-IP decapsulation. to support IPv6-in-IPv6 decapsulation.
5.3. Support of the HbH Header 5.3. Support of the Hop-by-Hop Header
A RUL is expected to process an Option Type in a Hop-by-Hop Header as A RUL is expected to process an Option Type in a Hop-by-Hop Header as
prescribed by section 4.2 of [RFC8200]. An RPI with an Option Type prescribed by section 4.2 of [RFC8200]. An RPI with an Option Type
of 0x23 [USEofRPLinfo] is thus skipped when not recognized. of 0x23 [USEofRPLinfo] is thus skipped when not recognized.
5.4. Support of the Routing Header 5.4. Support of the Routing Header
A RUL is expected to process an unknown Routing Header Type as A RUL is expected to process an unknown Routing Header Type as
prescribed by section 4.4 of [RFC8200]. This implies that the Source prescribed by section 4.4 of [RFC8200]. This implies that the Source
Routing Header with a Routing Type of 3 [RFC6554] is ignored when the Routing Header with a Routing Type of 3 [RFC6554] is ignored when the
Segments Left is zero, and the packet is dropped otherwise. Segments Left is zero.
6. Enhancements to RFC 6550 6. Enhancements to RFC 6550
This document specifies a new behavior whereby a 6LR injects DAO This document specifies a new behavior whereby a 6LR injects DAO
messages for unicast addresses (see Section 9) and multicast messages for unicast addresses (see Section 9) and multicast
addresses (see Section 10) on behalf of leaves that are not aware of addresses (see Section 10) on behalf of leaves that are not aware of
RPL. The RUL addresses are exposed as external targets [RFC6550]. RPL. The RUL addresses are exposed as external targets [RFC6550].
Conforming to [USEofRPLinfo], an IP-in-IP encapsulation between the Conforming to [USEofRPLinfo], an IPv6-in-IPv6 encapsulation between
6LR and the RPL Root is used to carry the RPL artifacts and remove the 6LR and the RPL Root is used to carry the RPL artifacts and
them when forwarding outside the RPL domain, e.g., to a RUL. remove them when forwarding outside the RPL domain, e.g., to a RUL.
This document also synchronizes the liveness monitoring at the Root This document also synchronizes the liveness monitoring at the Root
and the 6LBR. The same value of lifetime is used for both, and a and the 6LBR. The same value of lifetime is used for both, and a
single keep-alive message, the RPL DAO, traverses the RPL network. A single keep-alive message, the RPL DAO, traverses the RPL network. A
new behavior is introduced whereby the RPL Root proxies the EDAR new behavior is introduced whereby the RPL Root proxies the EDAR
message to the 6LBR on behalf of the 6LR (more in Section 8), for any message to the 6LBR on behalf of the 6LR (see 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 to 1, more in a new "Advertiser address in Full" 'F' flag set to 1, see
Section 6.1. Section 6.1.
This specification defines the new "Root Proxies EDAR/EDAC" (P) flag This specification defines a new flag, "Root Proxies EDAR/EDAC" (P),
and encodes it in one of these reserved flags of the RPL DODAG in the RPL DODAG Configuration option, see 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, see Section 6.3.
Section 12 of [RFC6550] details the RPL support for multicast flows Section 12 of [RFC6550] details the RPL support for multicast flows
when the RPLInstance is operated in the MOP of 3 ("Storing Mode of when the RPLInstance is operated in the MOP of 3 ("Storing Mode of
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, see 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 1 to indicate that the Target Prefix field The Target Prefix of the RPL Target Option is left (high bit)
contains the IPv6 address of the advertising node, in which case the justified and contains the advertised prefix; its size may be smaller
length of the Target Prefix field is 128 bits regardless of the value than 128 when it indicates a Prefix route. The Prefix Length field
of the Prefix Length field. If the 'F' flag is set to 0, the Target signals the number of bits that correspond to the advertised Prefix;
Prefix field MUST be aligned to the next byte boundary after the size it is 128 for a host route or less in the case of a Prefix route.
(expressed in bits) indicated by the Prefix Length field. Padding This remains unchanged.
bits are reserved and set to 0 per section 6.7.7 of [RFC6550].
This specification defines the new 'F' flag. When it is set to 1,
the size of the Target Prefix field MUST be 128 bits and it MUST
contain an IPv6 address of the advertising node taken from the
advertised Prefix. In that case, the Target Prefix field carries two
distinct pieces of information: a route that can be a host route or a
Prefix route depending on the Prefix Length, and an IPv6 address that
can be used to reach the advertising node and validate the route.
If the 'F' flag is set to 0, the Target Prefix field can be shorter
than 128 bits and it MUST be aligned to the next byte boundary after
the end of the prefix. Any additional bits in the rightmost octet
are filled with padding bits. Padding bits are reserved and set to 0
as specified in section 6.7.7 of [RFC6550].
With this specification the ROVR is the remainder of the RPL Target With this specification the ROVR is the remainder of the RPL Target
Option. The size of the ROVR is indicated in a new ROVR Size field Option. The size of the ROVR is indicated in a new ROVR Size field
that is encoded to map one-to-one with the Code Suffix in the EDAR that is encoded to map one-to-one with the Code Suffix in the EDAR
message (see table 4 of [RFC8505]). The ROVR Size field is taken message (see table 4 of [RFC8505]). The ROVR Size field is taken
from the flags field, which is an update to the RPL Target Option from the flags field, which is an update to the RPL Target Option
Flags IANA registry. Flags IANA registry.
The updated format is illustrated in Figure 3. It is backward The updated format is illustrated in Figure 4. It is backward
compatible with the Target Option in [RFC6550]. It is recommended compatible with the Target Option in [RFC6550]. It is recommended
that the updated format be used as a replacement in new that the updated format be used as a replacement in new
implementations in all MOPs in preparation for upcoming Route implementations in all MOPs in preparation for upcoming Route
Ownership Validation mechanisms based on the ROVR, unless the device Ownership Validation mechanisms based on the ROVR, unless the device
or the network is so constrained that this is not feasible. or the network is so constrained that this is not feasible.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x05 | Option Length |ROVRsz |F|Flags| Prefix Length | | Type = 0x05 | Option Length |ROVRsz |F|Flags| Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Target Prefix (Variable Length) | | Target Prefix (Variable Length) |
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... Registration Ownership Verifier (ROVR) ... ... Registration Ownership Verifier (ROVR) ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Updated Target Option Figure 4: Updated Target Option
New fields: New fields:
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 1 to indicate that Target Prefix field F: 1-bit flag. Set to 1 to indicate that Target Prefix field
contains the complete (128 bit) IPv6 address of the advertising contains the complete (128 bit) IPv6 address of the advertising
node. node.
Flags: The 4 bits remaining unused in the Flags field are reserved Flags: The 3 bits remaining unused in the Flags field are reserved
for flags. The field MUST be initialized to zero by the sender for flags. The field MUST be initialized to zero by the sender
and MUST be ignored by the receiver. 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. Additional Flag in the RPL DODAG Configuration Option
The DODAG Configuration Option is defined in Section 6.7.6 of The DODAG Configuration Option is defined in Section 6.7.6 of
[RFC6550]. Its purpose is extended to distribute configuration [RFC6550]. Its purpose is extended to distribute configuration
information affecting the construction and maintenance of the DODAG, information affecting the construction and maintenance of the DODAG,
as well as operational parameters for RPL on the DODAG, through the as well as operational parameters for RPL on the DODAG, through the
DODAG. This Option was originally designed with 4 bit positions DODAG. This Option was originally designed with 4 bit positions
reserved for future use as Flags. reserved for future use as Flags.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x04 |Opt Length = 14| |P| | |A| ... | | Type = 0x04 |Opt Length = 14| |P| | |A| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
|4 bits | |4 bits |
Figure 4: DODAG Configuration Option (Partial View) Figure 5: 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 1 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).
skipping to change at page 16, line 21 skipping to change at page 17, line 21
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
to 1 by the Root, and when the 'P' Flag is set to 1, it is by the Root, and when the 'P' Flag is set to 1, it is transparently
transparently flooded to all the nodes in the DODAG. flooded to all the nodes in the DODAG.
6.3. Updated RPL Status 6.3. Updated RPL Status
The RPL Status is defined in section 6.5.1 of [RFC6550] for use in The RPL Status is defined in section 6.5.1 of [RFC6550] for use in
the DAO-ACK message and values are assigned as follows: the DAO-ACK message and values are assigned as follows:
+---------+--------------------------------+ +---------+--------------------------------+
| Range | Meaning | | Range | Meaning |
+---------+--------------------------------+ +---------+--------------------------------+
| 0 | Success/Unqualified acceptance | | 0 | Success/Unqualified acceptance |
+---------+--------------------------------+ +---------+--------------------------------+
| 1-127 | Not an outright rejection | | 1-127 | Not an outright rejection |
+---------+--------------------------------+ +---------+--------------------------------+
| 128-255 | Rejection | | 128-255 | Rejection |
+---------+--------------------------------+ +---------+--------------------------------+
Table 1: RPL Status per RFC 6550 Table 1: RPL Status per RFC 6550
The 6LoWPAN ND Status was defined for use in the EARO, see section The 6LoWPAN ND Status was defined for use in the EARO, see section
4.1 of [RFC8505]. This specification enables to carry the 6LoWPAN ND 4.1 of [RFC8505]. This specification adds a capability to allow the
Status values in RPL DAO and DCO messages, embedded in the RPL Status carriage of 6LoWPAN ND Status values in RPL DAO and DCO messages,
field. embedded in the RPL Status field.
To achieve this, the range of the ARO/EARO Status values is reduced To achieve this, the range of the ARO/EARO Status values is reduced
to 0-63, which updates the IANA registry created for [RFC6775]. This to 0-63, which updates the IANA registry created for [RFC6775]. This
reduction ensures that the values fit within a RPL Status as shown in reduction ensures that the values fit within a RPL Status as shown in
Figure 5. See Section 12.2, Section 12.5, and Section 12.6 for the Figure 6. See Section 12.2, Section 12.5, and Section 12.6 for the
respective IANA declarations. respective IANA declarations.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|A|StatusValue| |E|A|StatusValue|
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 5: RPL Status Format Figure 6: 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 1 to indicate a rejection. When set to 0, a E: 1-bit flag. set to 1 to indicate a rejection. When set to 0, a
Status value of 0 indicates Success/Unqualified acceptance and Status value of 0 indicates Success/Unqualified acceptance and
other values indicate "not an outright rejection" as per RFC 6550. other values indicate "not an outright rejection" as per RFC 6550.
A: 1-bit flag. Indicates the type of the RPL Status value. A: 1-bit flag. Indicates the type of the RPL Status value.
skipping to change at page 18, line 8 skipping to change at page 19, line 8
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.
In the case of a RUL, the 6LR that serves the RUL acts as the RAN In the case of a RUL, the 6LR that serves the RUL acts as the RAN
that receives the Non-Storing DCO. This specification leverages the that receives the Non-Storing DCO. This specification leverages the
Non-Storing DCO between the Root and the 6LR that serves as 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 attachment router for a RUL. A 6LR and a Root that support this
specification MUST implement the Non-Storing DCO. 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
follows: follows:
* If the RPL Root advertises the capability to proxy the EDAR/EDAC * If the RPL Root advertises the capability to proxy the EDAR/EDAC
exchange to the 6LBR, the 6LR refrains from sending the keep-alive exchange to the 6LBR, the 6LR refrains from sending the keep-alive
EDAR message. If it is separated from the 6LBR, the Root EDAR message. If it is separated from the 6LBR, the Root
regenerates the EDAR message to the 6LBR periodically, upon a DAO regenerates the EDAR message to the 6LBR periodically, upon a DAO
message that signals the liveliness of the address. message that signals the liveliness of the address.
* The use of the R Flag is extended to the NA(EARO) to confirm * The use of the R Flag is extended to the NA(EARO) to confirm
whether the route was installed. whether the route was installed.
9. Protocol Operations for Unicast Addresses 9. Protocol Operations for Unicast Addresses
The description below assumes that the Root sets the 'P' 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
presented in Section 4.3 .
If the 'P' flag is set to 0, 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.
skipping to change at page 19, line 20 skipping to change at page 20, line 20
with the 6LBR is proxied by the RPL Root upon the DAO message that with the 6LBR is proxied by the RPL Root upon the DAO message that
refreshes the RPL routing state. The first EDAR upon a new refreshes the RPL routing state. The first EDAR upon a new
Registration cannot be proxied, though, as it serves for the purpose Registration cannot be proxied, though, as it serves for the purpose
of DAD, which must be verified before the address is injected in RPL. of DAD, which must be verified before the address is injected in RPL.
In a RPL network where the function is enabled, refreshing the state In a RPL network where the function is enabled, refreshing the state
in the 6LBR is the responsibility of the Root. Consequently, only in the 6LBR is the responsibility of the Root. Consequently, only
addresses that are injected in RPL will be kept alive at the 6LBR by addresses that are injected in RPL will be kept alive at the 6LBR by
the RPL Root. Since RULs are advertised using Non-Storing Mode, the the RPL Root. Since RULs are advertised using Non-Storing Mode, the
DAO message flow and the keep alive EDAR/EDAC can be nested within DAO message flow and the keep alive EDAR/EDAC can be nested within
the Address (re)Registration flow. Figure 6 illustrates that, for the Address (re)Registration flow. Figure 7 illustrates that, for
the first Registration, both the DAD and the keep-alive EDAR/EDAC the first Registration, both the DAD and the keep-alive EDAR/EDAC
exchanges happen in the same sequence. exchanges happen in the same sequence.
6LN/RUL 6LR <6LR*> Root 6LBR 6LN/RUL 6LR <6LR*> Root 6LBR
| | | | | | | |
|<------ND------>|<----RPL----->|<-------ND-------->| |<------ND------>|<----RPL----->|<-------ND-------->|
| |<----------------ND-------------->| | |<----------------ND-------------->|
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | |--------------->| |
| | Extended DAR | | | EDAR |
| |--------------------------------->| | |--------------------------------->|
| | | | | |
| | Extended DAC | | | EDAC |
| |<---------------------------------| | |<---------------------------------|
| | DAO | | | | DAO | |
| |------------->| | | |------------->| |
| | | EDAR | | | | EDAR |
| | |------------------>| | | |------------------>|
| | | EDAC | | | | EDAC |
| | |<------------------| | | |<------------------|
| | DAO-ACK | | | | DAO-ACK | |
| |<-------------| | | |<-------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |<---------------| | |
| | | | | | | |
Figure 6: First RUL Registration Flow Figure 7: First RUL Registration Flow
This flow requires that the lifetimes and sequence counters in This flow requires that the lifetimes and sequence counters in
6LoWPAN ND and RPL are aligned. 6LoWPAN ND and RPL are aligned.
To achieve this, the Path Sequence and the Path Lifetime in the DAO To achieve this, the Path Sequence and the Path Lifetime in the DAO
message are taken from the Transaction ID and the Address message are taken from the Transaction ID and the Address
Registration lifetime in the NS(EARO) message from the 6LN. Registration lifetime in the NS(EARO) message from the 6LN.
On the first Address Registration, illustrated in Figure 6 for RPL On the first Address Registration, illustrated in Figure 7 for RPL
Non-Storing Mode, the Extended Duplicate Address exchange takes place Non-Storing Mode, the Extended Duplicate Address exchange takes place
as prescribed by [RFC8505]. If the exchange fails, the 6LR returns as prescribed by [RFC8505]. If the exchange fails, the 6LR returns
an NA message with a negative status to the 6LN, the NCE is not an NA message with a non-zero status to the 6LN, the NCE is not
created, and the address is not injected in RPL. Otherwise, the 6LR created, and the address is not injected in RPL. Otherwise, the 6LR
creates an NCE and injects the Registered Address in the RPL routing creates an NCE and injects the Registered Address in the RPL routing
using a DAO/DAO-ACK exchange with the RPL DODAG Root. using a DAO/DAO-ACK exchange with the RPL DODAG Root.
An Address Registration refresh is performed by the 6LN to maintain An Address Registration refresh is performed by the 6LN to maintain
the NCE in the 6LR alive before the lifetime expires. Upon the the NCE in the 6LR alive before the lifetime expires. Upon the
refresh of a registration, the 6LR reinjects the corresponding route refresh of a registration, the 6LR reinjects the corresponding route
in RPL before it expires, as illustrated in Figure 7. in RPL before it expires, as illustrated in Figure 8.
6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR 6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | | |--------------->| | |
| | DAO | | | | DAO | |
| |------------->| | | |------------->| |
| | | EDAR | | | | EDAR |
| | |------------------>| | | |------------------>|
| | | EDAC | | | | EDAC |
| | |<------------------| | | |<------------------|
| | DAO-ACK | | | | DAO-ACK | |
| |<-------------| | | |<-------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |<---------------| | |
Figure 7: Next RUL Registration Flow Figure 8: 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 to 1 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 Non-Storing DCO, but the negative Status in the DCO asynchronous Non-Storing DCO, but the non-zero status in the DCO
supersedes a positive Status in the DAO-ACK regardless of the order supersedes a positive Status in the DAO-ACK regardless of the order
in which they are received. Upon the DAO-ACK - or the DCO if one in which they are received. Upon the DAO-ACK - or the DCO if one
arrives first - 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 [RFC8929]. Backbone router (6BBR), see Figure 5 in section 3.3 of [RFC8929].
The 6BBR may send a negative ND status, e.g., in an asynchronous The 6BBR may send a negative ND status, e.g., in an asynchronous
NA(EARO) to the 6LBR. NA(EARO) to the 6LBR.
[RFC8929] expects that the 6LBR is collocated with the RPL Root, but [RFC8929] expects that the 6LBR is collocated with the RPL Root, but
if not, the 6LBR MUST forward the status code to the originator of if not, the 6LBR MUST forward the status code to the originator of
the EDAR, either the 6LR or the RPL Root that proxies for it. The ND the EDAR, either the 6LR or the RPL Root that proxies for it. The ND
status code is mapped in a RPL Status value by the RPL Root, and then status code is mapped in a RPL Status value by the RPL Root, and then
back by the 6LR. back by the 6LR.
Figure 8 illustrates this in the case where the 6LBR and the Root are Figure 9 illustrates this in the case where the 6LBR and the Root are
not collocated, and the Root proxies the EDAR messages. not collocated, and the Root proxies the EDAR messages.
6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR <-ND-> 6BBR 6LN/RUL <-ND-> 6LR <-RPL-> Root <-ND-> 6LBR <-ND-> 6BBR
| | | | | | | | | |
| | | | NA(EARO) | | | | | NA(EARO) |
| | | |<------------| | | | |<------------|
| | | EDAC | | | | | EDAC | |
| | |<-------------| | | | |<-------------| |
| | DCO | | | | | DCO | | |
| |<------------| | | | |<------------| | |
| NA(EARO) | | | | | NA(EARO) | | | |
|<-------------| | | | |<-------------| | | |
| | | | | | | | | |
Figure 8: Asynchronous Issue Figure 9: 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 non-zero 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 set to 0. 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 8.
Any combination of the logical functions of 6LR, Root, and 6LBR might Any combination of the logical functions of 6LR, Root, and 6LBR might
be collapsed in a single node. be collapsed in a single node.
9.2. Detailed Operation 9.2. Detailed Operation
The following section specify respectively the behaviour of the 6LN
Acting as RUL, the 6LR Acting as Border router ad serving the 6LN,
the RPL Root and the 6LBR in the control flows that enable RPL
routing back to the RUL.
9.2.1. Perspective of the 6LN Acting as RUL 9.2.1. Perspective of the 6LN Acting as RUL
This specification does not alter the operation of a 6LoWPAN ND- This specification 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 selects a 6LR that provides reachability services for a 1. The 6LN selects a 6LR that provides reachability services for a
RUL. This is signaled a 6CIO in the RA messages with the L, P RUL. This is signaled a 6CIO in the RA messages with the L, P
and E flags set to 1 as prescribed by [RFC8505]. and E flags set to 1 as prescribed by [RFC8505].
2. The 6LN obtains an IPv6 global address, either using Stateless 2. The 6LN obtains an IPv6 global address, either using Stateless
skipping to change at page 23, line 14 skipping to change at page 24, line 22
6. The 6LN may use any of the 6LRs to which it registered as the 6. The 6LN may use any of the 6LRs to which it registered as the
default gateway. Using a 6LR to which the 6LN is not registered default gateway. Using a 6LR to which the 6LN is not registered
may result in packets dropped at the 6LR by a Source Address may result in packets dropped at the 6LR by a Source Address
Validation function (SAVI) [RFC7039] so it is not recommended. Validation function (SAVI) [RFC7039] so it is not recommended.
Even without support for RPL, the RUL may be configured with an Even without support for RPL, the RUL may be configured with an
opaque value to be provided to the routing protocol. If the RUL has opaque value to be provided to the routing protocol. If the RUL has
knowledge of the RPL Instance the packet should be injected into, knowledge of the RPL Instance the packet should be injected into,
then it SHOULD set the Opaque field in the EARO to the RPLInstanceID, then it SHOULD set the Opaque field in the EARO to the RPLInstanceID,
else it MUST leave the Opaque field to zero. otherwise it MUST leave the Opaque field as zero.
Regardless of the setting of the Opaque field, the 6LN MUST set the Regardless of the setting of the Opaque field, the 6LN MUST set the
"I" field to zero to signal "topological information to be passed to "I" field to zero to signal "topological information to be passed to
a routing process", as specified in section 5.1 of [RFC8505]. a routing process", as specified in section 5.1 of [RFC8505].
A RUL is not expected to produce RPL artifacts in the data packets, A RUL is not expected to produce RPL artifacts in the data packets,
but it may do so. For instance, if the RUL has minimal awareness of but it may do so. For instance, if the RUL has minimal awareness of
the RPL Instance then it can build an RPI. A RUL that places an RPI the RPL Instance then it can build an RPI. A RUL that places an RPI
in a data packet 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 0 inside the RPL domain. All the flags and the Rank field are set to 0
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 A 6LR that provides reachability services for a RUL in a RPL network
as specified in this document MUST include a 6CIO in its RA messages as specified in this document MUST include a 6CIO in its RA messages
and set the L, P and E flags to 1 as prescribed by [RFC8505]. and set the L, P and E flags to 1 as prescribed by [RFC8505].
As prescribed by [RFC8505], the 6LR generates an EDAR message upon As prescribed by [RFC8505], the 6LR generates an EDAR message upon
reception of a valid NS(EARO) message for the registration of a new reception of a valid NS(EARO) message for the registration of a new
IPv6 address by a 6LN. If the initial EDAR/EDAC exchange succeeds, IPv6 address by a 6LN. If the initial EDAR/EDAC exchange succeeds,
then the 6LR installs an NCE for the Registration Lifetime. For the then the 6LR installs an NCE for the Registration Lifetime. 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 to 1 in the NS(EARO), the 6LR SHOULD inject the If the R Flag is set to 1 in the NS(EARO), the 6LR SHOULD inject the
Host route in RPL, unless this is barred for other reasons, such as host route in RPL, unless this is barred for other reasons, such as
the saturation of the RPL parents. The 6LR MUST use a RPL Non- the saturation of the RPL parents. The 6LR MUST use a RPL Non-
Storing Mode signaling and the updated Target Option (see Storing Mode signaling and the updated Target Option (see
Section 6.1). The 6LR MUST request a DAO-ACK by setting the 'K' flag Section 6.1). The 6LR MUST request a DAO-ACK by setting the 'K' flag
in the DAO message. Success injecting the route to the RUL's address in the DAO message. Success injecting the route to the RUL's address
is indicated by the 'E' flag set to 0 in the RPL status of the DAO- is indicated by the 'E' flag set to 0 in the RPL status of the DAO-
ACK message. ACK message.
The Opaque field in the EARO provides a mean to signal which RPL The Opaque field in the EARO provides a means to signal which RPL
Instance is to be used for the DAO advertisements and the forwarding Instance is to be used for the DAO advertisements and the forwarding
of packets sourced at the Registered Address when there is no RPI in of packets sourced at the Registered Address when there is no RPI in
the packet. the packet.
As described in [RFC8505], if the "I" field is zero, then the Opaque As described in [RFC8505], if the "I" field is zero, then the Opaque
field is expected to carry the RPLInstanceID suggested by the 6LN; field is expected to carry the RPLInstanceID suggested by the 6LN;
otherwise, there is no suggested Instance. If the 6LR participates otherwise, there is no suggested Instance. If the 6LR participates
in the suggested RPL Instance, then the 6LR MUST use that RPL in the suggested RPL Instance, then the 6LR MUST use that RPL
Instance for the Registered Address. Instance for the Registered Address.
skipping to change at page 25, line 34 skipping to change at page 26, line 46
proxy operation succeeded. proxy operation succeeded.
If the 'A' flag in the RPL Status is set to 1, the embedded Status If the 'A' flag in the RPL Status is set to 1, the embedded Status
value is passed back to the RUL in the EARO Status. If the 'E' flag value is passed back to the RUL in the EARO Status. If the 'E' flag
is also set to 1, the registration failed for 6LoWPAN ND related is also set to 1, the registration failed for 6LoWPAN ND related
reasons, and the NCE is removed. reasons, and the NCE is removed.
An error injecting the route causes the 'E' flag to be set to 1. If An error injecting the route causes the 'E' flag to be set to 1. If
the error is not related to ND, the 'A' flag is set to 0. In that the error is not related to ND, the 'A' flag is set to 0. In that
case, the registration succeeds, but the RPL route is not installed. case, the registration succeeds, but the RPL route is not installed.
So the NA(EARO) is returned with a positive status but the R Flag set So the NA(EARO) is returned with a status indicating success but the
to 0, which means that the 6LN obtained a binding but no route. R Flag set to 0, which means that the 6LN obtained a binding but no
route.
If the 'A' flag is set to 0 in the RPL Status of the DAO-ACK, then If the 'A' flag is set to 0 in the RPL Status of the DAO-ACK, then
the 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 to 1 in the RPL Status of the DAO-ACK, then If the 'E' flag is set to 1 in the RPL Status of the DAO-ACK, then
the route was not installed and the R flag MUST be set to 0 in the the route was not installed and the R flag MUST be set to 0 in the
NA(EARO). The R flag MUST be set to 0 if the 6LR did not attempt to NA(EARO). The R flag MUST be set to 0 if the 6LR did not attempt to
inject the route. inject the route.
In a network where Address Protected Neighbor Discovery (AP-ND) is In a network where Address Protected Neighbor Discovery (AP-ND) is
enabled, in case of a DAO-ACK or a DCO indicating transporting an enabled, in case of a DAO-ACK or a DCO 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
[RFC8928], before the Registration is complete. This flow, [RFC8928], before the Registration is complete. This flow,
illustrated in Figure 9, ensures that the address is validated before illustrated in Figure 10, ensures that the address is validated
it is injected in the RPL routing. before 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 27, line 5 skipping to change at page 28, line 39
|------ NS EARO (ROVR=Crypto-ID) -------->| | | |------ NS EARO (ROVR=Crypto-ID) -------->| | |
| |-- DAO --->| | | |-- DAO --->| |
| | |-- EDAR -->| | | |-- EDAR -->|
| | | | | | | |
| | |<-- EDAC --| | | |<-- EDAC --|
| |<- DAO-ACK-| | | |<- DAO-ACK-| |
|<----------- NA EARO (status=0)----------| | | |<----------- NA EARO (status=0)----------| | |
| | | | | | | |
... ...
Figure 9: Address Protection Figure 10: 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 set to 0 to signal that it stops providing routing services, R Flag set to 0 to signal that it stops providing routing services,
and/or with the EARO Status 2 "Neighbor Cache full" to signal that it and/or with the EARO Status 2 "Neighbor Cache full" to signal that it
removes the NCE. It may also send a final RA, unicast or multicast, removes the NCE. It may also send a final RA, unicast or multicast,
with a Router Lifetime field of zero, to signal that it stops serving with a router Lifetime field of zero, to signal that it is ceasing to
as Router, as specified in section 6.2.5 of [RFC4861]. This may serve as router, as specified in section 6.2.5 of [RFC4861]. This
happen upon a DCO or a DAO-ACK message indicating the path is already may happen upon a DCO or a DAO-ACK message indicating the path is
removed; else the 6LR MUST remove the Host route to the 6LN using a already removed; else the 6LR MUST remove the host route to the 6LN
DAO message with a Path Lifetime of zero. using a DAO message with a Path Lifetime of zero.
A valid NS(EARO) message with the R Flag set to 0 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 to 1, the 6LR was injecting the Host route to the Registered Flag set to 1, the 6LR was injecting the host route to the Registered
Address in RPL using DAO messages, then the 6LR MUST invalidate the Address in RPL using DAO messages, then the 6LR MUST invalidate the
Host route in RPL using a DAO with a Path Lifetime of zero. It is up host route in RPL using a DAO with a Path Lifetime of zero. It is up
to the Registering 6LN to maintain the corresponding route from then to the Registering 6LN to maintain the corresponding route from then
on, either keeping it active via a different 6LR or by acting as a on, either keeping it active via a different 6LR or by acting as a
RAN and managing its own reachability. RAN and managing its own reachability.
9.2.3. Perspective of the RPL Root 9.2.3. Perspective of the RPL Root
A RPL Root MUST set the 'P' flag to 1 in the RPL DODAG Configuration A RPL Root MUST set the 'P' flag to 1 in the RPL DODAG Configuration
Option of the DIO messages that it generates (see Section 6) to Option of the DIO messages that it generates (see Section 6) to
signal that it proxies the EDAR/EDAC exchange and supports the signal that it proxies the EDAR/EDAC exchange and supports the
Updated RPL Target option. Updated RPL Target option.
skipping to change at page 28, line 10 skipping to change at page 29, line 46
of 60 seconds used in the 6LoWPAN ND messages; of 60 seconds used in the 6LoWPAN ND messages;
3. the TID value is set to the Path Sequence in the TIO and 3. the TID value is set to the Path Sequence in the TIO and
indicated with an ICMP code of 1 in the EDAR message; indicated with an ICMP code of 1 in the EDAR message;
4. The ROVR in the RPL Target Option is copied as is in the EDAR and 4. The ROVR in the RPL Target Option is copied as is in the EDAR and
the ICMP Code Suffix is set to the appropriate value as shown in the ICMP Code Suffix is set to the appropriate value as shown in
Table 4 of [RFC8505] depending on the size of the ROVR field. Table 4 of [RFC8505] depending on the size of the ROVR field.
Upon receiving an EDAC message from the 6LBR, if a DAO is pending, 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. Otherwise, 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 to 1. 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
skipping to change at page 28, line 50 skipping to change at page 30, line 38
is 3. is 3.
The RPL support of multicast is not source-specific and only operates The RPL support of multicast is not source-specific and only operates
as an extension to the Storing Mode of Operation for unicast packets. as an extension to the Storing Mode of Operation for unicast packets.
Note that it is the RPL model that the multicast packet is passed as Note that it is the RPL model that the multicast packet is passed as
a Layer-2 unicast to each of the interested children. This remains a Layer-2 unicast to each of the interested children. This remains
true when forwarding between the 6LR and the listener 6LN. true when forwarding between the 6LR and the listener 6LN.
"Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810] "Multicast Listener Discovery Version 2 (MLDv2) for IPv6" [RFC3810]
provides an interface for a listener to register to multicast flows. provides an interface for a listener to register to multicast flows.
In the MLD model, the Router is a "querier", and the Host is a In the MLD model, the router is a "querier", and the host is a
multicast listener that registers to the querier to obtain copies of multicast listener that registers to the querier to obtain copies of
the particular flows it is interested in. the particular flows it is interested in.
The equivalent of the first Address Registration happens as The equivalent of the first Address Registration happens as
illustrated in Figure 10. The 6LN, as an MLD listener, sends an illustrated in Figure 11. The 6LN, as an MLD listener, sends an
unsolicited Report to the 6LR. This enables it to start receiving unsolicited Report to the 6LR. This enables it to start receiving
the flow immediately, and causes the 6LR to inject the multicast the flow immediately, and causes the 6LR to inject the multicast
route in RPL. route in RPL.
This specification does not change MLD but will operate more This specification does not change MLD but will operate more
efficiently if the asynchronous messages for unsolicited Report and efficiently if the asynchronous messages for unsolicited Report and
Done are sent by the 6LN as Layer-2 unicast to the 6LR, in particular Done are sent by the 6LN as Layer-2 unicast to the 6LR, in particular
on wireless. on wireless.
The 6LR acts as a generic MLD querier and generates a DAO with the The 6LR acts as a generic MLD querier and generates a DAO with the
Multicast Address as the Target Prefix as described in section 12 of Multicast Address as the Target Prefix as described in section 12 of
[RFC6550]. As for the Unicast Host routes, the Path Lifetime [RFC6550]. As for the Unicast host routes, the Path Lifetime
associated to the Target is mapped from the Query Interval, and set associated to the Target is mapped from the Query Interval, and set
to be larger to account for variable propagation delays to the Root. to be larger to account for variable propagation delays to the Root.
The Root proxies the MLD exchange as a listener with the 6LBR acting The Root proxies the MLD exchange as a listener with the 6LBR acting
as the querier, so as to get packets from a source external to the as the querier, so as to get packets from a source external to the
RPL domain. RPL domain.
Upon a DAO with a Target option for a multicast address, the RPL Root Upon a DAO with a Target option for a multicast address, the RPL Root
checks if it is already registered as a listener for that address, checks if it is already registered as a listener for that address,
and if not, it performs its own unsolicited Report for the multicast and if not, it performs its own unsolicited Report for the multicast
address as described in section 5.1 of [RFC3810]. The report is address as described in section 5.1 of [RFC3810]. The report is
skipping to change at page 29, line 44 skipping to change at page 31, line 33
|------------------->| | | |------------------->| | |
| | DAO | | | | DAO | |
| |-------------->| | | |-------------->| |
| | DAO-ACK | | | | DAO-ACK | |
| |<--------------| | | |<--------------| |
| | | <if not done already> | | | | <if not done already> |
| | | unsolicited Report | | | | unsolicited Report |
| | |---------------------->| | | |---------------------->|
| | | | | | | |
Figure 10: First Multicast Registration Flow Figure 11: First Multicast Registration Flow
The equivalent of the registration refresh is pulled periodically by The equivalent of the registration refresh is pulled periodically by
the 6LR acting as querier. Upon the timing out of the Query the 6LR acting as querier. Upon the timing out of the Query
Interval, the 6LR sends a Multicast Address Specific Query to each of Interval, the 6LR sends a Multicast Address Specific Query to each of
its listeners, for each Multicast Address, and gets a Report back its listeners, for each Multicast Address, and gets a Report back
that is mapped into a DAO one by one. Optionally, the 6LR MAY send a that is mapped into a DAO one by one. Optionally, the 6LR MAY send a
General Query, where the Multicast Address field is set to zero. In General Query, where the Multicast Address field is set to zero. In
that case, the multicast packet is passed as a Layer-2 unicast to that case, the multicast packet is passed as a Layer-2 unicast to
each of the interested children. . each of the interested children. .
skipping to change at page 30, line 28 skipping to change at page 32, line 9
of the 6LR's parents. of the 6LR's parents.
Asynchronously to this, a similar procedure happens between the Root Asynchronously to this, a similar procedure happens between the Root
and a router such as the 6LBR that serves multicast flows on the Link and a router such as the 6LBR that serves multicast flows on the Link
where the Root is located. Again the Query and Report messages are where the Root is located. Again the Query and Report messages are
source independent. The Root lists exactly once each Multicast source independent. The Root lists exactly once each Multicast
Address for which it has at least one active multicast DAO state, Address for which it has at least one active multicast DAO state,
copying the multicast address in the DAO state in the Multicast copying the multicast address in the DAO state in the Multicast
Address field of the Multicast Address Records in the Report message. Address field of the Multicast Address Records in the Report message.
This is illustrated in Figure 11: This is illustrated in Figure 12:
6LN/RUL 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| Query | | | | Query | | |
|<-------------------| | | |<-------------------| | |
| Report | | | | Report | | |
|------------------->| | | |------------------->| | |
| | DAO | | | | DAO | |
| |-------------->| | | |-------------->| |
| | DAO-ACK | | | | DAO-ACK | |
| |<--------------| | | |<--------------| |
| | | Query | | | | Query |
| | |<-------------------| | | |<-------------------|
| | | Report | | | | Report |
| | |------------------->| | | |------------------->|
| | | | | | | |
Figure 11: Next Registration Flow Figure 12: Next Registration Flow
Note that any of the functions 6LR, Root and 6LBR might be collapsed Note that any of the functions 6LR, Root and 6LBR might be collapsed
in a single node, in which case the flow above happens internally, in a single node, in which case the flow above happens internally,
and possibly through internal API calls as opposed to messaging. and possibly through internal API calls as opposed to messaging.
11. Security Considerations 11. Security Considerations
It is worth noting that with [RFC6550], every node in the LLN is RPL- It is worth noting that with [RFC6550], every node in the LLN is RPL-
aware and can inject any RPL-based attack in the network. This aware and can inject any RPL-based attack in the network. This
specification isolates edge nodes that can only interact with the RPL specification isolates edge nodes that can only interact with the RPL
Routers using 6LoWPAN ND, meaning that they cannot perform RPL routers using 6LoWPAN ND, meaning that they cannot perform RPL
insider attacks. insider attacks.
The LLN nodes depend on the 6LBR and the RPL participants for their The LLN nodes depend on the 6LBR and the RPL participants for their
operation. A trust model must be put in place to ensure that the operation. A trust model must be put in place to ensure that the
right devices are acting in these roles, so as to avoid threats such right devices are acting in these roles, so as to avoid threats such
as black-holing, (see [RFC7416] section 7), Denial-Of-Service attacks as black-holing, (see [RFC7416] section 7), Denial-Of-Service attacks
whereby a rogue 6LR creates a high churn in the RPL network by whereby a rogue 6LR creates a high churn in the RPL network by
advertising and removing many forged addresses, or bombing attack advertising and removing many forged addresses, or bombing attack
whereby an impersonated 6LBR would destroy state in the network by whereby an impersonated 6LBR would destroy state in the network by
using the status code of 4 ("Removed"). using the status code of 4 ("Removed").
This trust model could be at a minimum based on a Layer-2 Secure This trust model could be at a minimum based on a Layer-2 Secure
joining and the Link-Layer security. This is a generic 6LoWPAN joining and the Link-Layer security. This is a generic 6LoWPAN
requirement, see Req5.1 in Appendix of [RFC8505]. requirement, see Req5.1 in Appendix B.5 of [RFC8505].
In a general manner, the Security Considerations in [RFC7416] In a general manner, the Security Considerations in [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 to 1 in the EARO. the R Flag set to 1 in the EARO.
[RFC8928] updated 6LoWPAN ND with the called Address-Protected [RFC8928] updated 6LoWPAN ND with the called Address-Protected
skipping to change at page 33, line 25 skipping to change at page 35, line 13
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:
skipping to change at page 34, line 47 skipping to change at page 36, line 31
+-------+-----------------------+-----------+ +-------+-----------------------+-----------+
| 1..63 | Unassigned | | | 1..63 | Unassigned | |
+-------+-----------------------+-----------+ +-------+-----------------------+-----------+
Table 5: Rejection values of the RPL Status Table 5: Rejection values of the RPL Status
13. Acknowledgments 13. Acknowledgments
The authors wish to thank Ines Robles, Georgios Papadopoulos and The authors wish to thank Ines Robles, Georgios Papadopoulos and
especially Rahul Jadhav and Alvaro Retana for their reviews and especially Rahul Jadhav and Alvaro Retana for their reviews and
contributions to this document. Also many thanks to Peter Van der contributions to this document. Also many thanks to Elwyn Davies,
Stok and Carl Wallace for their reviews and useful comments during Eric Vyncke, Peter Van der Stok and Carl Wallace for their reviews
the IETF Last Call and the IESG review sessions. 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 38, line 28 skipping to change at page 40, line 11
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>.
[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, [RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli,
"IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929, "IPv6 Backbone Router", RFC 8929, DOI 10.17487/RFC8929,
November 2020, <https://www.rfc-editor.org/info/rfc8929>. November 2020, <https://www.rfc-editor.org/info/rfc8929>.
Appendix A. Example Compression Appendix A. Example Compression
Figure 12 illustrates the case in Storing Mode where the packet is Figure 13 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- |IPv6-in-IPv6| NH=1 |11110CPP| UDP | UDP
|Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld |Page 1 |Type1 S=0| 6LoRH | 6LoRH |LOWPAN_IPHC| UDP | hdr |Payld
+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-... +-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
<-4 bytes-> <- RFC 6282 -> <-4 bytes-> <- RFC 6282 ->
<- No RPL artifact ... <- No RPL artifact ...
Figure 12: Encapsulation to Parent 6LR in Storing Mode Figure 13: Encapsulation to Parent 6LR in Storing Mode
The difference with the example presented in Figure 19 of [RFC8138] The difference with the example presented in Figure 19 of [RFC8138]
is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the is the addition of a SRH-6LoRH before the RPI-6LoRH to transport the
compressed address of the 6LR as the destination address of the outer compressed address of the 6LR as the destination address of the outer
IPv6 header. In the [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 13, the source of the IPv6-in-IPv6 encapsulation is the
so it is elided in the IP-in-IP 6LoRH. The destination is the parent Root, so it is elided in the IPv6-in-IPv6 6LoRH. The destination is
6LR of the destination of the encapsulated packet so it cannot be the parent 6LR of the destination of the encapsulated packet so it
elided. If the DODAG is operated in Storing Mode, it is the single cannot be elided. If the DODAG is operated in Storing Mode, it is
entry in the SRH-6LoRH and the SRH-6LoRH Size is encoded as 0. The the single entry in the SRH-6LoRH and the SRH-6LoRH Size is encoded
SRH-6LoRH is the first 6LoRH in the chain. In this particular as 0. The SRH-6LoRH is the first 6LoRH in the chain. In this
example, the 6LR address can be compressed to 2 bytes so a Type of 1 particular example, the 6LR address can be compressed to 2 bytes so a
is used. It results that the total length of the SRH-6LoRH is 4 Type of 1 is used. It results that the total length of the SRH-6LoRH
bytes. 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 13 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 IPv6-in-IPv6
When the IP-in-IP 6LoRH is removed, all the 6LoRH Headers that 6LoRH. When the IPv6-in-IPv6 6LoRH is removed, all the 6LoRH Headers
precede it are also removed. The Paging Dispatch [RFC8025] may also that precede it are also removed. The Paging Dispatch [RFC8025] may
be removed if there was no previous Page change to a Page other than also be removed if there was no previous Page change to a Page other
0 or 1, since the LOWPAN_IPHC is encoded in the same fashion in the than 0 or 1, since the LOWPAN_IPHC is encoded in the same fashion in
default Page 0 and in Page 1. The resulting packet to the the default Page 0 and in Page 1. The resulting packet to the
destination is the encapsulated 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. 117 change blocks. 
234 lines changed or deleted 281 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/