draft-ietf-roll-unaware-leaves-11.txt   draft-ietf-roll-unaware-leaves-12.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550, 8505 (if approved) M. Richardson Updates: 6550, 8505 (if approved) M. Richardson
Intended status: Standards Track Sandelman Intended status: Standards Track Sandelman
Expires: 14 September 2020 13 March 2020 Expires: 18 September 2020 17 March 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-11 draft-ietf-roll-unaware-leaves-12
Abstract Abstract
This specification extends RFC6550 and RFC8505 to provide unicast and This specification extends RFC6550 and RFC8505 to provide routing
multicast routing services in a RPL domain to 6LNs that are plain services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND
Hosts and do not participate to RPL, and enables the RPL Root to but do not participate to RPL. This specification also enables the
proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its DODAG. RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG.
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 14 September 2020. This Internet-Draft will expire on 18 September 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. References . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 7 3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 7
3.1. RFC 6775 Address Registration . . . . . . . . . . . . . . 7 3.1. RFC 6775 Address Registration . . . . . . . . . . . . . . 7
3.2. RFC 8505 Extended Address Registration . . . . . . . . . 7 3.2. RFC 8505 Extended Address Registration . . . . . . . . . 7
3.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. TID, I Field and Opaque Fields . . . . . . . . . . . 8 3.2.2. TID, I Field and Opaque Fields . . . . . . . . . . . 8
3.2.3. ROVR . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.3. ROVR . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 9 3.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 9
3.3.1. RFC 7400 Capability Indication Option . . . . . . . . 9 3.3.1. RFC 7400 Capability Indication Option . . . . . . . . 9
4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 10 4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 16 skipping to change at page 3, line 16
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
Networks" [RFC6550] (RPL) to provide IPv6 [RFC8200] routing services Networks" [RFC6550] (RPL) to provide IPv6 [RFC8200] routing services
within such constraints. RPL belongs to the class of Distance-Vector within such constraints. RPL belongs to the class of Distance-Vector
protocol, which, compared to link-state protocols, limits the amount protocols, which, compared to link-state protocols, limit the amount
of topological knowledge that needs to be installed and maintained in of topological knowledge that needs to be installed and maintained in
each node. each node.
In order to operate in constrained networks, RPL allows a routing To save signaling and routing state in constrained networks, RPL
stretch (see [RFC6687]), whereby routing is only performed along an allows a routing stretch (see [RFC6687]), whereby routing is only
acyclic graph optimized to reach a Root node, as opposed to straight performed along an acyclic graph optimized to reach a Root node, as
along a shortest path between 2 peers, whatever that would mean in a opposed to straight along a shortest path between 2 peers, whatever
given LLN. This trades the quality of peer-to-peer (P2P) paths for a that would mean in a given LLN. This trades the quality of peer-to-
vastly reduced amount of control traffic and routing state that would peer (P2P) paths for a vastly reduced amount of control traffic and
be required to operate a any-to-any shortest path protocol. Finally, routing state that would be required to operate a any-to-any shortest
broken routes may be fixed lazily and on-demand, based on dataplane path protocol. Finally, broken routes may be fixed lazily and on-
inconsistency discovery, which avoids wasting energy in the proactive demand, based on dataplane inconsistency discovery, which avoids
repair of unused paths. wasting energy in the proactive repair of unused paths.
In order to cope with lossy transmissions, RPL forms Direction- In provide alternate paths in lossy networks, RPL forms Direction-
Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information
Solicitation (DIS) and DODAG Information Object (DIO) messages. For Solicitation (DIS) and DODAG Information Object (DIO) messages. For
many of the nodes, though not all, a DODAG provides multiple many of the nodes, though not all, a DODAG provides multiple
forwarding solutions towards the Root of the topology via so-called forwarding solutions towards the Root of the topology via so-called
parents. RPL is designed to adapt to fuzzy connectivity, whereby the parents. RPL is designed to adapt to fuzzy connectivity, whereby the
physical topology cannot be expected to reach a stable state, with a physical topology cannot be expected to reach a stable state, with a
lazy control that creates the routes proactively, but may only fix lazy control that creates the routes proactively, but may only fix
them reactively, upon actual traffic. The result is that RPL them reactively, upon actual traffic. The result is that RPL
provides reachability for most of the LLN nodes, most of the time, provides reachability for most of the LLN nodes, most of the time,
but may not converge in the classical sense. but may not converge in the classical sense.
[RFC6550] provides unicast and multicast routing services back to [RFC6550] provides unicast and multicast routing services to RPL-
RPL-Aware nodes (RANs), either as a collection tree or with routing Aware nodes (RANs), either as a collection tree or with routing back.
back. In tha latter case, a RAN injects routes to itself using In the latter case, a RAN injects routes to itself using Destination
Destination Advertisement Object (DAO) messages sent to either Advertisement Object (DAO) messages sent either to parent-nodes, in
parent-nodes in the RPL Storing Mode or to the Root indicating their the RPL Storing Mode, or to the Root indicating their parent, in the
parent in the Non-Storing Mode. This process effectively forms a Non-Storing Mode. This process effectively forms a DODAG back to the
DODAG back to the device that is a subset of the DODAG to the Root device that is a subset of the DODAG to the Root with all links
with all links reversed. reversed.
RPL can be deployed as an extension to IPv6 Neighbor Discovery (ND) RPL can be deployed as an extension to IPv6 Neighbor Discovery (ND)
[RFC4861][RFC4862] and 6LoWPAN ND [RFC6775][RFC8505] to maintain [RFC4861][RFC4862] and 6LoWPAN ND [RFC6775][RFC8505] to maintain
reachability within a Non-Broadcast Multi-Access (NBMA) subnet. In reachability within a Non-Broadcast Multi-Access (NBMA) subnet. In
that mode, some nodes may act as Routers and participate to the that mode, some nodes may act as Routers and participate to the
forwarding operations whereas others will only terminate packets, forwarding operations whereas others will only terminate packets,
acting as Hosts in the data-plane. In [RFC6550] terms, a Host that acting as Hosts in the data-plane. In [RFC6550] terms, a Host that
is reachable over the RPL network is called a Leaf. is reachable over the RPL network is called a Leaf.
"When to use RFC 6553, 6554 and IPv6-in-IPv6" [USEofRPLinfo] "When to use RFC 6553, 6554 and IPv6-in-IPv6" [USEofRPLinfo]
introduces the term RPL-Aware-Leaf (RAL) for a Leaf that injects introduces the term RPL-Aware-Leaf (RAL) for a Leaf that injects
routes in RPL to manage the reachability of its own IPv6 addresses. routes in RPL to manage the reachability of its own IPv6 addresses.
In contrast, the term RPL-Unaware Leaf (RUL) designates a Leaf does In contrast, the term RPL-Unaware Leaf (RUL) designates a Leaf that
not participate to RPL at all. A RUL is a plain Host that needs a does not participate to RPL at all. RULs may be unable to
RPL-Aware Router to obtain routing services over the RPL network. participate because they are very energy constrained.
A RUL is an IPv6 Host [RFC8504] that needs a RPL-Aware Router to
obtain routing services over the RPL network. The Non-Storing Mode
mechanisms are used to extend the routing state with connectivity to
RULs even when the DODAG is operated in Storing-Mode DODAGs.
This specification leverages the Address Registration mechanism This specification leverages the Address Registration mechanism
defined in 6LoWPAN ND to enable a RUL as a 6LoWPAN Node (6LN) to defined in 6LoWPAN ND to enable a RUL as a 6LoWPAN Node (6LN) to
interface with a RPL-Aware Router as a 6LoWPAN Router (6LR) to interface with a RPL-Aware Router as a 6LoWPAN Router (6LR) to
request that the 6LR injects the relevant routing information for the request that the 6LR injects the relevant routing information for the
Registered Address in the RPL domain on its behalf. The unicast Registered Address in the RPL domain on its behalf. The unicast
packet forwarding operation by the 6LR serving a 6LN that is a RPL packet forwarding operation by the 6LR serving a 6LN that is a RPL
Leaf is described in [USEofRPLinfo]. Leaf is described in [USEofRPLinfo].
Examples of routing-agnostic 6LNs include lightly-powered sensors Examples of routing-agnostic 6LNs include lightly-powered sensors
such as window smash sensor (alarm system), and kinetically powered such as window smash sensor (alarm system), and kinetically powered
light switches. Other application of this specification may include light switches. Other applications of this specification may include
a smart grid network that controls appliances - such as washing a smart grid network that controls appliances - such as washing
machines or the heating system - in the home. Appliances may not machines or the heating system - in the home. Appliances may not
participate to the RPL protocol operated in the Smartgrid network but participate to the RPL protocol operated in the Smartgrid network but
can still interact with the Smartgrid for control and/or metering. can still interact with the Smartgrid for control and/or metering.
2. Terminology 2. Terminology
2.1. BCP 14 2.1. BCP 14
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. References 2.2. 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]. and Lossy Networks (LLNs)" [RFC7102]. A glossary of classical
6LoWPAN acronyms is given in Section 2.3. Other terms in use in LLNs
A glossary of classical 6LoWPAN acronyms is given in Section 2.3. are found in "Terminology for Constrained-Node Networks" [RFC7228].
The term "byte" is used in its now customary sense as a synonym for
"octet".
"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) are defined in "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks" [RFC6550] . The DODAG Information Low-Power and Lossy Networks" [RFC6550]. The RPI is the abstract
Solicitation (DIS), Destination Advertisement Object (DAO) and DODAG information that RPL defines to be placed in data packets, e.g., as
Information Object (DIO) messages are also specified in [RFC6550]. the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header. By
The Destination Cleanup Object (DCO) message is defined in extension the term "RPI" is often used to refer to the RPL Option
[EFFICIENT-NPDAO]. itself. The DODAG Information Solicitation (DIS), Destination
Advertisement Object (DAO) and DODAG Information Object (DIO)
messages are also specified in [RFC6550]. The Destination Cleanup
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) and RPL Aware
Leaf (RAL) consistently with [USEofRPLinfo]. The term RPL-Aware Node Leaf (RAL) consistently with [USEofRPLinfo]. The term RPL-Aware Node
(RAN) is introduced to refer to a node that is either a RAL or a RPL (RAN) is introduced to refer to a node that is either a RAL or a RPL
Router. As opposed to a RUL, a RAN manages the reachability of its Router. As opposed to a RUL, a RAN manages the reachability of its
addresses and prefixes by injecting them in RPL by itself. addresses and prefixes by injecting them in RPL by itself.
Other terms in use in LLNs are found in Terminology for In this document, readers will encounter terms and concepts that are
Constrained-Node Networks [RFC7228]. discussed in the following documents:
Readers are expected to be familiar with all the terms and concepts
that are discussed in
* "Neighbor Discovery for IP version 6" [RFC4861],
* "IPv6 Stateless Address Autoconfiguration" [RFC4862],
* "Problem Statement and Requirements for IPv6 over Low-Power Classical IPv6 ND: "Neighbor Discovery for IP version 6" [RFC4861]
Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], and "IPv6 Stateless Address Autoconfiguration" [RFC4862],
* "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606] and
"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals" [RFC4919], Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
and
* "Neighbor Discovery Optimization for Low-power and Lossy Networks" 6LoWPAN ND: Neighbor Discovery Optimization for Low-Power and Lossy
[RFC6775], and Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor
Discovery" [RFC8505], and "Address Protected Neighbor Discovery
* "Registration Extensions for IPv6 over Low-Power Wireless Personal for Low-power and Lossy Networks" [AP-ND] .
Area Network (6LoWPAN) Neighbor Discovery" [RFC8505].
2.3. Glossary 2.3. Glossary
This document often uses the following acronyms: This document often uses the following acronyms:
AR: Address Resolution (aka Address Lookup) AR: Address Resolution (aka Address Lookup)
6CIO: 6LoWPAN Capability Indication Option 6CIO: 6LoWPAN Capability Indication Option
6LN: 6LoWPAN Node (a Low Power Host or Router) 6LN: 6LoWPAN Node (a Low Power Host or Router)
6LR: 6LoWPAN Router 6LR: 6LoWPAN Router
(E)ARO: (Extended) Address Registration Option (E)ARO: (Extended) Address Registration Option
(E)DAR: (Extended) Duplicate Address Request (E)DAR: (Extended) Duplicate Address Request
(E)DAC: (Extended) Duplicate Address Confirmation (E)DAC: (Extended) Duplicate Address Confirmation
skipping to change at page 6, line 40 skipping to change at page 6, line 42
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 (the abstract information RPL places in RPI: RPL Packet Information
data packets as the RPL Option within the IPv6 Hop-By-Hop Header,
and by extension the RPL Option itself)
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
TID: Transaction ID (a sequence counter in the EARO) TID: Transaction ID (a sequence counter in the EARO)
3. 6LoWPAN Neighbor Discovery 3. 6LoWPAN Neighbor Discovery
skipping to change at page 9, line 20 skipping to change at page 9, line 20
exchange is triggered by a NS(EARO) message and is intended to create exchange is triggered by a NS(EARO) message and is intended to create
and then refresh the corresponding state in the 6LBR for a lifetime and then refresh the corresponding state in the 6LBR for a lifetime
that is indicated by the 6LN. that is indicated by the 6LN.
Conversely, RPL [RFC6550] specifies a periodic DAO from the 6LN all Conversely, RPL [RFC6550] specifies a periodic DAO from the 6LN all
the way to the Root that maintains the routing state in the RPL the way to the Root that maintains the routing state in the RPL
network for the lifetime indicated by the source of the DAO. This network for the lifetime indicated by the source of the DAO. This
means that for each address, there are two keep-alive messages that means that for each address, there are two keep-alive messages that
traverse the whole network, one to the Root and one to the 6LBR. traverse the whole network, one to the Root and one to the 6LBR.
This specification saves the extraneous keep-alive across the LLN. This specification removes the extraneous keep-alive across the LLN.
The 6LR turns the periodic Address Registration from the RUL into a The 6LR turns the periodic Address Registration from the RUL into a
DAO message to the Root every time, but only generates the EDAR upon DAO message to the Root on every refresh, but it only generates the
the first registration, for the purpose of DAD. Upon a refresher EDAR upon the first registration, for the purpose of DAD. Upon a
DAO, the Root proxies the EDAR exchange to refresh the state at the refresher DAO, the Root proxies the EDAR exchange to refresh the
6LBR on behalf of the 6LR, as illustrated in Figure 7. state at the 6LBR on behalf of the 6LR, as illustrated in Figure 7.
3.3.1. RFC 7400 Capability Indication Option 3.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.
skipping to change at page 11, line 29 skipping to change at page 11, line 29
EDAR message; if the Root is separated from the 6LBR, the Root EDAR message; if the Root is separated from the 6LBR, the Root
regenerates the EDAR message to the 6LBR upon a DAO message that regenerates the EDAR message to the 6LBR upon a DAO message that
signals the liveliness of the Address. The regenerated message is signals the liveliness of the Address. The regenerated message is
anonymous iff the DAO is a legacy message that does not carry a ROVR anonymous iff the DAO is a legacy message that does not carry a ROVR
as specified in Section 8. as specified in Section 8.
6. Requirements on the RPL-Unware Leaf 6. Requirements on the RPL-Unware Leaf
This document provides RPL routing for a RUL, that is a 6LN acting as This document provides RPL routing for a RUL, that is a 6LN acting as
an IPv6 Host and not aware of RPL. Still, a minimal RPL-independent an IPv6 Host and not aware of RPL. Still, a minimal RPL-independent
functionality is required from the RUL in order to obtain routing functionality is required from the RUL to obtain routing services.
services from the 6LR.
6.1. Support of 6LoWPAN ND 6.1. Support of 6LoWPAN ND
In order to obtain routing services from a 6LR, a RUL MUST implement In order to obtain routing services from a 6LR, a RUL MUST implement
[RFC8505] and set the "R" flag in the EARO option. The RUL MUST NOT [RFC8505] and set the "R" flag in the EARO. The RUL SHOULD support
request routing services from a 6LR unless the 6LR originates RA [AP-ND] and use it to protect the ownership of its addresses. The
messages with a CIO that has the L, P and E flags are all set as RUL MUST NOT request routing services from a 6LR that does not
discussed in Section 3.3.1. originate RA messages with a CIO that has the L, P, and E flags all
set as discussed in Section 3.3.1.
The RUL MUST register to all the 6LRs from which it requests routing A RUL that has multiple potential routers MUST prefer those that
services. The Address Registrations SHOULD be performed in a rapid provide routing services. The RUL MUST register to all the 6LRs from
sequence, using the exact same EARO for a same Address. Gaps between which it desires routing services. If there are no available
the Address Registrations will invalidate some of the routes till the routers, the connection of the RUL fails. The Address Registrations
Address Registration finally shows on those routes as well. SHOULD be performed in a rapid sequence, using the exact same EARO
for a same Address. Gaps between the Address Registrations will
invalidate some of the routes till the Address Registration finally
shows on those routes as well.
[RFC8505] introduces error Status values in the NA(EARO) which can be [RFC8505] introduces error Status values in the NA(EARO) which can be
received synchronously upon an NS(EARO) or asynchronously. The RUL received synchronously upon an NS(EARO) or asynchronously. The RUL
MUST support both cases and MUST refrain from using the address when MUST support both cases and MUST refrain from using the address when
the Status value indicates a rejection. the Status value indicates a rejection.
A RUL SHOULD support [AP-ND] to protect the ownership of its
addresses.
6.2. External Routes and RPL Artifacts 6.2. External Routes and RPL Artifacts
Section 4.1. of [USEofRPLinfo] provides a set of rules that MUST be Section 4.1. of [USEofRPLinfo] provides a set of rules that MUST be
followed for the routing operations to a RUL. followed for the routing operations to a RUL.
A 6LR that is upgraded to act as a border router for external routes A 6LR that is upgraded to act as a border router for external routes
advertises them using Non-Storing Mode DAO messages that are unicast advertises them using Non-Storing Mode DAO messages that are unicast
directly to the Root, even if the DODAG is operated in Storing Mode. directly to the Root, even if the DODAG is operated in Storing Mode.
Non-Storing Mode routes are not visible inside the RPL domain and all Non-Storing Mode routes are not visible inside the RPL domain and all
packets are routed via the Root. An upgraded Root tunnels the packets are routed via the Root. An upgraded Root tunnels the
skipping to change at page 12, line 29 skipping to change at page 12, line 29
encapsulated packets are normal traffic for the intermediate Routers. encapsulated packets are normal traffic for the intermediate Routers.
The support of external routes only impacts the Root and the 6LR. It The support of external routes only impacts the Root and the 6LR. It
can be operated with legacy intermediate routers and does not add to can be operated with legacy intermediate routers and does not add to
the amount of state that must be maintained in those routers. A RUL the amount of state that must be maintained in those routers. A RUL
is an example of a destination that is reachable via an external is an example of a destination that is reachable via an external
route which happens to be a Host route. route which happens to be a Host route.
The RPL data packets always carry a Hop-by-Hop Header to transport a The RPL data packets always carry a Hop-by-Hop Header to transport a
RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates RPL Packet Information (RPI) [RFC6550]. So unless the RUL originates
its packets with an RPI, the 6LR needs to tunnel them to the Root to its packets with an RPI, the 6LR needs to tunnel them to the Root to
add the RPI. As a rule of a thumb and except the very special case add the RPI. As a rule of a thumb and except for the very special
above, the packets from and to a RUL are always encapsulated using an case above, the packets from and to a RUL are always encapsulated
IP-in-IP tunnel between the Root and the 6LR that serves the RUL. using an IP-in-IP tunnel between the Root and the 6LR that serves the
RUL. (see sections 7.1.4, 7.2.3, 7.2.4, 7.3.3, 7.3.4, 8.1.3, 8.1.4,
8.2.3, 8.2.4, 8.3.3 and 8.3.4 of [USEofRPLinfo] for details)
In Non-Storing Mode, packets going down carry a Source Routing Header In Non-Storing Mode, packets going down carry a Source Routing Header
(SRH). The IP-in-IP encapsulation, the RPI and the SRH are (SRH). The IP-in-IP encapsulation, the RPI and the SRH are
collectively called the "RPL artifacts" and can be compressed using collectively called the "RPL artifacts" and can be compressed using
[RFC8138]. Figure 12 presents an example compressed format for a [RFC8138]. Figure 12 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 encapsulated by the Root with that RPI still present in the inner and possibly an SRH in a Non-Storing Mode DODAG. [USEofRPLinfo]
header, and possibly an SRH in a Non-Storing Mode DODAG. expects the RUL to support the basic "IPv6 Node Requirements"
[USEofRPLinfo] expects the RUL to support the basic "IPv6 Node [RFC8504]. In particular the RUL is expected to ignore the RPL
Requirements" [RFC8504], in particular to ignore the RPL artifacts artifacts that are either consumed or not applicable to a Host.
that are either consumed or not applicable to a Host, but not
necessarily IP-in-IP encapsulation, more in the next sections.
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]. Unless configured otherwise, the border router MUST [RFC8138]. Unless configured otherwise, the border router MUST
uncompress the outgoing packet before forwarding over an external uncompress the outgoing packet before forwarding over an external
route, and if it is not the destination of the incoming packet, and route, even if it is not the destination of the incoming packet, and
even when delivering to a RUL. even when delivering to a RUL.
6.2.1. Support of IPv6 Encapsulation 6.2.1. Support of IPv6 Encapsulation
Section 2.1 of [USEofRPLinfo] sets the rules for forwarding IP-in-IP Section 2.1 of [USEofRPLinfo] sets the rules for forwarding IP-in-IP
either to the final 6LN or to a parent 6LR. In order to enable IP- either to the final 6LN or to a parent 6LR. In order to enable IP-
in-IP to the 6LN in Non-Storing Mode, the 6LN must be able to in-IP to the 6LN in Non-Storing Mode, the 6LN must be able to
decapsulate the tunneled packet and either drop the inner packet if decapsulate the tunneled packet and either drop the inner packet if
it is not the final destination, or pass it to the upper layer for it is not the final destination, or pass it to the upper layer for
further processing. Unless it is aware that the RUL can handle IP- further processing. Unless it is aware that the RUL can handle IP-
skipping to change at page 13, line 28 skipping to change at page 13, line 28
A RUL is expected to process an unknown Option Type in a Hop-by-Hop A RUL is expected to process an unknown Option Type in a Hop-by-Hop
Header as prescribed by section 4.2 of [RFC8200]. This means in Header as prescribed by section 4.2 of [RFC8200]. This means in
particular that an RPI with an Option Type of 0x23 [USEofRPLinfo] is particular that an RPI with an Option Type of 0x23 [USEofRPLinfo] is
ignored when not understood. ignored when not understood.
6.2.3. Support of the Routing Header 6.2.3. Support of the Routing Header
A RUL is expected to process an unknown Routing Header Type as A RUL is expected to process an unknown Routing Header Type as
prescribed by section 4.4 of [RFC8200]. This means in particular prescribed by section 4.4 of [RFC8200]. This means in particular
that Routing Header with a Routing Type of 3 [RFC6553] is ignored that Routing Header with a Routing Type of 3 [RFC6554] is ignored
when the Segments Left is zero, and the packet is dropped otherwise. when the Segments Left is zero, and the packet is dropped otherwise.
7. Updated RPL Status 7. Updated RPL Status
The RPL Status is defined in section 6.5.1. of [RFC6550] for use in The RPL Status is defined in section 6.5.1. of [RFC6550] for use in
the DAO-Ack message and values are assigned as follows: the DAO-Ack message and values are assigned as follows:
+---------+--------------------------------+ +---------+--------------------------------+
| Range | Meaning | | Range | Meaning |
+=========+================================+ +=========+================================+
skipping to change at page 15, line 42 skipping to change at page 15, line 42
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]
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.
9.1. General Flow 9.1. General Flow
This specification enables to save the exchange of keep-alive This specification eliminates the need to exchange keep-alive
Extended Duplicate Address messages, EDAR and EDAC, from a 6LN all Extended Duplicate Address messages, EDAR and EDAC, all the way from
the way to the 6LBR across a RPL mesh. Instead, the EDAR/EDAC a 6LN to the 6LBR across a RPL mesh. Instead, the EDAR/EDAC exchange
exchange with the 6LBR is proxied by the RPL Root upon a DAO message with the 6LBR is proxied by the RPL Root upon a DAO message that
that refreshes the RPL routing state. refreshes the RPL routing state.
To achieve this, the lifetimes and sequence counters in 6LoWPAN ND To achieve this, the lifetimes and sequence counters in 6LoWPAN ND
and RPL are aligned. In other words, the Path Sequence and the Path and RPL are aligned. In other words, the Path Sequence and the Path
Lifetime in the DAO message are taken from the Transaction ID and the Lifetime in the DAO message are taken from the Transaction ID and the
Address Registration lifetime in the NS(EARO) message from the 6LN. Address Registration lifetime in the NS(EARO) message from the 6LN.
The proxy operation applies to both RULs and RANs. In a RPL network The proxy operation applies to both RULs and RANs. In a RPL network
where the function is enabled, refreshing the state in the 6LBR is where the function is enabled, refreshing the state in the 6LBR is
the responsibility of the Root. Consequently, only addresses that the responsibility of the Root. Consequently, only addresses that
are injected in RPL will be kept alive by the RPL Root. are injected in RPL will be kept alive by the RPL Root.
skipping to change at page 16, line 31 skipping to change at page 16, line 31
6LR, and the 6LR injects the Registered Address in RPL using DAO/DAO- 6LR, and the 6LR injects the Registered Address in RPL using DAO/DAO-
ACK exchanges all the way to the RPL DODAG Root. The protocol does ACK exchanges all the way to the RPL DODAG Root. The protocol does
not carry a specific information that the Extended Duplicate Address not carry a specific information that the Extended Duplicate Address
messages were already exchanged, so the Root proxies them anyway. messages were already exchanged, so the Root proxies them anyway.
9.1.1. In RPL Non-Storing-Mode 9.1.1. In RPL Non-Storing-Mode
In Non-Storing Mode, the DAO message flow can be nested within the In Non-Storing Mode, the DAO message flow can be nested within the
Address Registration flow as illustrated in Figure 5. Address Registration flow as illustrated in Figure 5.
6LN 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | |--------------->| |
| | Extended DAR | | | Extended DAR |
| |--------------------------------->| | |--------------------------------->|
| | | | | |
| | Extended DAC | | | Extended DAC |
| |<---------------------------------| | |<---------------------------------|
| | DAO | | | | DAO | |
| |------------->| | | |------------->| |
skipping to change at page 17, line 10 skipping to change at page 17, line 10
|<---------------| | | |<---------------| | |
| | | | | | | |
Figure 5: First Registration Flow in Non-Storing Mode Figure 5: First Registration Flow in Non-Storing Mode
An issue may be detected later, e.g., the address moves within the An issue may be detected later, e.g., the address moves within the
LLN or to a different Root on a backbone [6BBR]. In that case the LLN or to a different Root on a backbone [6BBR]. In that case the
value of the status that indicates the issue can be passed from value of the status that indicates the issue can be passed from
6LoWPAN ND to RPL and back as illustrated in Figure 6. 6LoWPAN ND to RPL and back as illustrated in Figure 6.
6LN 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| | | NA(EARO, Status) | | | | NA(EARO, Status) |
| | |<-----------------| | | |<-----------------|
| | DCO(Status) | | | | DCO(Status) | |
| |<------------| | | |<------------| |
| NA(EARO, Status) | | | | NA(EARO, Status) | | |
|<-----------------| | | |<-----------------| | |
| | | | | | | |
Figure 6: Asynchronous Issue Figure 6: Asynchronous Issue
An Address re-Registration is performed by the 6LN to maintain the An Address re-Registration is performed by the 6LN to maintain the
NCE in the 6LR alive before lifetime expires. Upon an Address re- NCE in the 6LR alive before lifetime expires. Upon an Address re-
Registration, as illustrated in Figure 7, the 6LR redistributes the Registration, as illustrated in Figure 7, the 6LR redistributes the
Registered Address NS(EARO) in RPL. Registered Address NS(EARO) in RPL.
6LN 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | |--------------->| |
| | DAO | | | | DAO | |
| |------------->| | | |------------->| |
| | | (anonymous) EDAR | | | | (anonymous) EDAR |
| | |------------------>| | | |------------------>|
| | | EDAC | | | | EDAC |
| | |<------------------| | | |<------------------|
| | DAO-ACK | | | | DAO-ACK | |
skipping to change at page 18, line 7 skipping to change at page 18, line 7
an EDAC message or an anonymous EDAC if the ROVR is not indicated in an EDAC message or an anonymous EDAC if the ROVR is not indicated in
the Target Option. In both cases, the EDAC message sent in response the Target Option. In both cases, the EDAC message sent in response
by the 6LBR contains the actual value of the ROVR field for that by the 6LBR contains the actual value of the ROVR field for that
Address Registration. In case of an error on the proxied EDAR flow, Address Registration. In case of an error on the proxied EDAR flow,
the error MUST be returned in the DAO-ACK - if one was requested - the error MUST be returned in the DAO-ACK - if one was requested -
using a RPL Status with the 'A' flag set that imbeds a 6LoWPAN Status using a RPL Status with the 'A' flag set that imbeds a 6LoWPAN Status
value as discussed in Section 7. value as discussed in Section 7.
If the Root could not return the negative Status in the DAO-ACK then If the Root could not return the negative Status in the DAO-ACK then
it sends an asynchronous Destination Cleanup Object (DCO) message it sends an asynchronous Destination Cleanup Object (DCO) message
[EFFICIENT-NPDAO] to the 6LR placing the negative Status in the RPL [EFFICIENT-NPDAO] to the 6LR by placing the negative Status in the
Status with the 'A' flag set. Note that if both are used in a short RPL Status with the 'A' flag set. Note that if both are used in a
interval of time, the DAO-ACK and DCO messages are not guaranteed to short interval of time, the DAO-ACK and DCO messages are not
arrive in the same order at the 6LR. guaranteed to arrive in the same order at the 6LR.
The 6LR may still receive a requested DAO-ACK even after it received The 6LR may still receive a requested DAO-ACK even after it received
a DCO, but the negative Status in the DCO supercedes a positive a DCO, but the negative Status in the DCO supercedes a positive
Status in the DAO-ACK regardless of the order in which they are Status in the DAO-ACK regardless of the order in which they are
received. Upon the DAO-ACK - or the DCO if it arrives first - the received. Upon the DAO-ACK - or the DCO if it arrives first - the
6LR responds to the RUL with a NA(EARO). If the RPL Status has the 6LR responds to the RUL with a NA(EARO). If the RPL Status has the
'A' flag set, then the ND Status is extracted and passed in the EARO; 'A' flag set, then the ND Status is extracted and passed in the EARO;
else, if the 'E' flag is set, indicating a rejection, then the status else, if the 'E' flag is set, indicating a rejection, then the status
4 "Removed" is used; else, the ND Status of 0 indicating "Success" is 4 "Removed" is used; else, the ND Status of 0 indicating "Success" is
used. used.
9.1.2. In RPL Storing-Mode 9.1.2. In RPL Storing-Mode
In RPL Storing Mode, the DAO-ACK is optional. When it is used, it is In RPL Storing Mode, the DAO-ACK is optional. When it is used, it is
generated by the RPL parent, which does not need to wait for the generated by the RPL parent, which does not need to wait for the
grand-parent to send the acknowledgement. A successful DAO-ACK is grand-parent to send the acknowledgement. A successful DAO-ACK is
not a guarantee that the DAO has yet reached the Root or that the not a guarantee that the DAO has yet reached the Root or that the
EDAR has succeeded. EDAR has succeeded.
6LN 6LR 6LR Root 6LBR 6LN/RUL 6LR 6LR Root 6LBR
| | | | | | | | | |
| NS(EARO) | | | | | NS(EARO) | | | |
|-------------->| | | | |-------------->| | | |
| NA(EARO) | | | | | NA(EARO) | | | |
|<--------------| | | | |<--------------| | | |
| | | | | | | | | |
| | DAO | | | | | DAO | | |
| |-------------->| | | | |-------------->| | |
| | DAO-ACK | | | | | DAO-ACK | | |
| |<--------------| | | | |<--------------| | |
skipping to change at page 19, line 11 skipping to change at page 19, line 11
| | | | EDAC(ROVR) | | | | | EDAC(ROVR) |
| | | |<-----------------| | | | |<-----------------|
| | | | | | | | | |
Figure 8: Next Registration Flow in Storing Mode Figure 8: Next Registration Flow in Storing Mode
If the keep-alive fails, or an asynchronous issue is reported, the If the keep-alive fails, or an asynchronous issue is reported, the
path can be cleaned up asynchronously using a DCO message path can be cleaned up asynchronously using a DCO message
[EFFICIENT-NPDAO] as illustrated in Figure 9 and described in further [EFFICIENT-NPDAO] as illustrated in Figure 9 and described in further
details in Section 9.2.3. details in Section 9.2.3.
6LN 6LR 6LR Root 6LBR 6LN/RUL 6LR 6LR Root 6LBR
| | | | | | | | | |
| | | | NA(EARO, Status) | | | | | NA(EARO, Status) |
| | | |<-----------------| | | | |<-----------------|
| | | | | | | | | |
| | | DCO(Status) | | | | | DCO(Status) | |
| | |<------------| | | | |<------------| |
| | | | | | | | | |
| | DCO(Status) | | | | | DCO(Status) | | |
| |<------------| | | | |<------------| | |
| | | | | | | | | |
skipping to change at page 19, line 44 skipping to change at page 19, line 44
* The 6LN obtains an IPv6 global address, either using Stateless * The 6LN obtains an IPv6 global address, either using Stateless
Address Autoconfiguration (SLAAC) [RFC4862] based on a Prefix Address Autoconfiguration (SLAAC) [RFC4862] based on a Prefix
Information Option (PIO) [RFC4861] found in a Router Advertisement Information Option (PIO) [RFC4861] found in a Router Advertisement
message, or some other means such as DHCPv6 [RFC3315]. message, or some other means such as DHCPv6 [RFC3315].
* Once it has formed an address, the 6LN (re)registers its address * Once it has formed an address, the 6LN (re)registers its address
periodically, within the Lifetime of the previous Address periodically, within the Lifetime of the previous Address
Registration, as prescribed by [RFC6775] and [RFC8505]. Registration, as prescribed by [RFC6775] and [RFC8505].
* The 6LN can register to more than one 6LR at the same time. In * As stated in section 5.2 of [RFC8505], the 6LN can register to
that case, it MUST use the same value of TID for all of the more than one 6LR at the same time. In that case, it MUST use the
parallel Address Registrations. same value of TID for all of the parallel Address Registrations.
* Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets the * Following section 5.1 of [RFC8505], a 6LN acting as a RUL sets the
"R" flag in the EARO of at least one registration, whereas acting "R" flag in the EARO of at least one registration, whereas acting
as a RAN it never does. If the "R" flag is set in the NS but not as a RAN it never does. If the "R" flag is set in the NS but not
echoed in the NA, the RUL SHOULD attempt to use another 6LR. echoed in the NA, the RUL SHOULD attempt to use another 6LR.
* Upon each consecutive Address Registration, the 6LN increases the * Upon each consecutive Address Registration, the 6LN increases the
TID field in the EARO, as prescribed by [RFC8505] section 5.2. TID field in the EARO, as prescribed by [RFC8505] section 5.2.
* The 6LN may use any of the 6LRs to which it register to forward * The 6LN may use any of the 6LRs to which it register to forward
skipping to change at page 20, line 43 skipping to change at page 20, line 43
Also as prescribed by [RFC8505], the 6LR generates an EDAR message Also as prescribed by [RFC8505], the 6LR generates an EDAR message
upon reception of a valid NS(EARO) message for the Address upon reception of a valid NS(EARO) message for the Address
Registration of a new IPv6 Address by a 6LN. If the Duplicate Registration of a new IPv6 Address by a 6LN. If the Duplicate
Address exchange succeeds, then the 6LR installs an NCE. If the "R" Address exchange succeeds, then the 6LR installs an NCE. If the "R"
flag was set in the EARO of the NS message, and this 6LR can manage flag was set in the EARO of the NS message, and this 6LR can manage
the reachability of Registered Address, then the 6LR sets the "R" the reachability of Registered Address, then the 6LR sets the "R"
flag in the EARO of the NA message that is sends in response. flag in the EARO of the NA message that is sends in response.
From then on, the 6LN periodically sends a new NS(EARO) to refresh From then on, the 6LN periodically sends a new NS(EARO) to refresh
the NCE state before the lifetime indicated in the EARO expires, with the NCE state before the lifetime indicated in the EARO expires, with
TID that is incremented each time till it wraps in a lollipop fashion a TID that is incremented each time till it wraps in a lollipop
(see section 5.2.1 of [RFC8505] which is fully compatible with fashion (see section 5.2.1 of [RFC8505] which is fully compatible
section 7.2 of [RFC6550]). As long as the "R" flag is set and this with section 7.2 of [RFC6550]). As long as the "R" flag is set and
Router can still manage the reachability of Registered Address, the this Router can still manage the reachability of Registered Address,
6LR keeps setting the "R" flag in the EARO of the response NA the 6LR keeps setting the "R" flag in the EARO of the response NA
message, but the exchange of keep-alive Extended Duplicate Address message, but the exchange of keep-alive Extended Duplicate Address
messages with the 6LBR is avoided if the RPL Root has indicated that messages with the 6LBR is avoided if the RPL Root has indicated that
it proxies for it. it proxies for it.
The Opaque field in the EARO hints the 6LR on the RPL Instance that The Opaque field in the EARO hints the 6LR on the RPL Instance that
should be used for the DAO advertisements, and for the forwarding of should be used for the DAO advertisements, and for the forwarding of
packets sourced at the registered address when there is no RPI in the packets sourced at the registered address when there is no RPI in the
packet, in which case the 6LR MUST encapsulate the packet to the Root packet, in which case the 6LR MUST encapsulate the packet to the Root
adding an RPI in the outer header. If the Opaque field is zero, the adding an RPI in the outer header. If the Opaque field is zero, the
6LR is free to use the default RPL Instance (zero) for the registered 6LR is free to use the default RPL Instance (zero) for the registered
skipping to change at page 21, line 24 skipping to change at page 21, line 24
Opaque field is zero. If the Opaque field is not zero, then it is Opaque field is zero. If the Opaque field is not zero, then it is
expected to carry a RPLInstanceID for the RPL Instance suggested by expected to carry a RPLInstanceID for the RPL Instance suggested by
the 6LN. If the 6LR does not participate to the associated Instance, the 6LN. If the 6LR does not participate to the associated Instance,
then the 6LR MUST consider that the Opaque field is zero; else, that then the 6LR MUST consider that the Opaque field is zero; else, that
is if the 6LR participates to the suggested Instance, then the 6LR is if the 6LR participates to the suggested Instance, then the 6LR
SHOULD use that Instance for the registered address. SHOULD use that Instance for the registered address.
The DAO message advertising the Registered Address MUST be The DAO message advertising the Registered Address MUST be
constructed as follows: constructed as follows:
* The Registered Address is placed in a RPL Target Option in the DAO 1. The Registered Address is placed in an RPL Target Option in the
message as the Target Prefix, and the Prefix Length is set to 128; DAO message as the Target Prefix, and the Prefix Length is set to
128;
* RPL Non-Storing Mode is used, and the 6LR indicates one of its 2. RPL Non-Storing Mode is to be used. The 6LR indicates one of its
global or unique-local IPv6 unicast addresses as the Parent global or unique-local IPv6 unicast addresses as the Parent
Address in the associated RPL Transit Information Option (TIO). Address in the associated RPL Transit Information Option (TIO).
* the External 'E' flag in the TIO is set to indicate that the 6LR 3. the External 'E' flag in the TIO is set to indicate that the 6LR
redistributes an external target into the RPL network. redistributes an external target into the RPL network.
* the Path Lifetime in the TIO is computed from the Lifetime in the 4. the Path Lifetime in the TIO is computed from the Lifetime in the
EARO Option to adapt it to the Lifetime Units used in the RPL EARO Option. This adapts it to the Lifetime Units used in the
operation. Note that if the lifetime is 0, then the 6LR generates RPL operation. Note that if the lifetime is 0, then the 6LR
a No-Path DAO message that cleans up the routes down to the generates a No-Path DAO message that cleans up the routes down to
Address of the 6LN; the Address of the 6LN;
* the Path Sequence in the TIO is set to the TID value found in the 5. the Path Sequence in the TIO is set to the TID value found in the
EARO option; EARO option;
Upon an NS(EARO), iff the "R" flag was set, the 6LR SHOULD inject the 6. Upon receiving an NS message with an EARO and the "R" flag set,
Registered Address in RPL by sending a DAO message on behalf of the the 6LR SHOULD inject the Registered Address in RPL by sending a
6LN. If the Registration Lifetime was 0, the effect is to remove the DAO message on behalf of the 6LN. If the Registration Lifetime
route and then the NCE. was 0, the effect is to remove the route and then the NCE;
If for whatever reason the 6LR does not inject the Registered Address If for whatever reason the 6LR does not inject the Registered Address
in RPL, it MUST send an NA(EARO) back with the appropriate status and in RPL, it MUST send an NA(EARO) back with the appropriate status and
the "R" flag not set. the "R" flag not set.
If the 6LR injects the Registered Address in RPL and either a DAO-ACK If the 6LR injects the Registered Address in RPL and either a DAO-ACK
was not requested or is received with a RPL Status that is not a was not requested or is received with a RPL Status that is not a
rejection ("E" flag not set), the 6LR MUST install or refresh the NCE rejection ("E" flag not set), the 6LR MUST install or refresh the NCE
for the address and reply to the RUL with an NA(EARO) with a Status for the address and reply to the RUL with an NA(EARO) with a Status
of 0 (Success) and the "R" flag set. of 0 (Success) and the "R" flag set.
skipping to change at page 24, line 31 skipping to change at page 24, line 31
copies of the particular flows it is interested in. copies of the particular flows it is interested in.
On the first Address Registration, as illustrated in Figure 10, the On the first Address Registration, as illustrated in Figure 10, the
6LN, as an MLD listener, sends an unsolicited Report to the 6LR in 6LN, as an MLD listener, sends an unsolicited Report to the 6LR in
order to start receiving the flow immediately. Since multicast order to start receiving the flow immediately. Since multicast
Layer-2 messages are avoided, it is important that the asynchronous Layer-2 messages are avoided, it is important that the asynchronous
messages for unsolicited Report and Done are sent reliably, for messages for unsolicited Report and Done are sent reliably, for
instance using an Layer-2 acknoledgement, or attempted multiple instance using an Layer-2 acknoledgement, or attempted multiple
times. times.
6LN 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| unsolicited Report | | | | unsolicited Report | | |
|------------------->| | | |------------------->| | |
| <L2 ack> | | | | <L2 ack> | | |
| | DAO | | | | DAO | |
| |-------------->| | | |-------------->| |
| | DAO-ACK | | | | DAO-ACK | |
| |<--------------| | | |<--------------| |
| | | <if not listening> | | | | <if not listening> |
| | | unsolicited Report | | | | unsolicited Report |
skipping to change at page 25, line 5 skipping to change at page 25, line 5
| | | | | | | |
| | | | | | | |
Figure 10: First Multicast Registration Flow Figure 10: First Multicast Registration Flow
The 6LR acts as a generic MLD querier and generates a DAO for the The 6LR acts as a generic MLD querier and generates a DAO for the
multicast target. The lifetime of the DAO is set to be in the order multicast target. The lifetime of the DAO is set to be in the order
of the Query Interval, yet larger to account for variable propagation of the Query Interval, yet larger to account for variable propagation
delays. delays.
The Root proxies the MLD echange as listener with the 6LBR acting as The Root proxies the MLD exchange as a listener with the 6LBR acting
the querier, so as to get packets from a source external to the RPL as the querier, so as to get packets from a source external to the
domain. Upon a DAO with a multicast target, the RPL Root checks if RPL domain. Upon a DAO with a multicast target, the RPL Root checks
it is already registered as a listener for that address, and if not, if it is already registered as a listener for that address, and if
it performs its own unsolicited Report for the multicast target. not, it performs its own unsolicited Report for the multicast target.
An Address re-Registration is pulled periodically by 6LR acting as An Address re-Registration is pulled periodically by 6LR acting as
querier. Note that th message may be sent unicast to all the known querier. Note that the message may be sent unicast to all the known
individual listeners. Upon a time out of the Query Interval, the 6LR individual listeners. Upon a time out of the Query Interval, the 6LR
sends a Query to each of its listeners, and gets a Report back that sends a Query to each of its listeners, and gets a Report back that
is mapped into a DAO, as illustrated in Figure 11: is mapped into a DAO, as illustrated in Figure 11:
6LN 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| Query | | | | Query | | |
|<-------------------| | | |<-------------------| | |
| Report | | | | Report | | |
|------------------->| | | |------------------->| | |
| | DAO | | | | DAO | |
| |-------------->| | | |-------------->| |
| | DAO-ACK | | | | DAO-ACK | |
| |<--------------| | | |<--------------| |
| | | | | | | |
skipping to change at page 26, line 15 skipping to change at page 26, line 15
Additionally, the trust model could include a role validation to Additionally, the trust model could include a role validation to
ensure that the node that claims to be a 6LBR or a RPL Root is ensure that the node that claims to be a 6LBR or a RPL Root is
entitled to do so. entitled to do so.
The anonymous EDAR message does not carry a valid Registration Unique The anonymous EDAR message does not carry a valid Registration Unique
ID [RFC8505] in the form of a ROVR and may be played by any node on ID [RFC8505] in the form of a ROVR and may be played by any node on
the network without the need to know the ROVR. The 6LBR MUST NOT the network without the need to know the ROVR. The 6LBR MUST NOT
create an entry based on a anonymous EDAR that does not match an create an entry based on a anonymous EDAR that does not match an
existing entry. All it can do is refresh the lifetime and the TID of existing entry. All it can do is refresh the lifetime and the TID of
an existing entry. So the message cannot be used to create a binding an existing entry. So the message cannot be used to create a binding
state in the 6LBR but it can be use to maitain one active longer than state in the 6LBR but it can be use to maintain one active longer
expected. than expected.
Note that a full EDAR message with a lifetime of 0 will destroy that Note that a full EDAR message with a lifetime of 0 will destroy that
state and the anonymous message will not recreate it. Note also that state and the anonymous message will not recreate it. Note also that
a rogue that has access to the network can attack the 6LBR with other a rogue that has access to the network can attack the 6LBR with other
(forged) addresses and ROVR, and that this is a much easier DoS (forged) addresses and ROVR, and that this is a much easier DoS
attack than trying to keep existing state alive longer. attack than trying to keep existing state alive longer.
At the time of this writing RPL does not have a zerotrust model At the time of this writing RPL does not have a zerotrust model
whereby the it is possible to validate the origin of an address that whereby the it is possible to validate the origin of an address that
is injected in a DAO. This specification makes a first step in that is injected in a DAO. This specification makes a first step in that
skipping to change at page 29, line 7 skipping to change at page 29, line 7
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553, Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012, DOI 10.17487/RFC6553, March 2012,
<https://www.rfc-editor.org/info/rfc6553>. <https://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012,
<https://www.rfc-editor.org/info/rfc6554>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
2014, <https://www.rfc-editor.org/info/rfc7400>. 2014, <https://www.rfc-editor.org/info/rfc7400>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
skipping to change at page 29, line 46 skipping to change at page 30, line 14
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
[AP-ND] Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, [AP-ND] Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and "Address Protected Neighbor Discovery for Low-power and
Lossy Networks", Work in Progress, Internet-Draft, draft- Lossy Networks", Work in Progress, Internet-Draft, draft-
ietf-6lo-ap-nd-19, 6 February 2020, ietf-6lo-ap-nd-20, 9 March 2020,
<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-19>. <https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-20>.
[USEofRPLinfo] [USEofRPLinfo]
Robles, I., Richardson, M., and P. Thubert, "Using RPI Robles, I., Richardson, M., and P. Thubert, "Using RPI
option Type, Routing Header for Source Routes and IPv6-in- option Type, Routing Header for Source Routes and IPv6-in-
IPv6 encapsulation in the RPL Data Plane", Work in IPv6 encapsulation in the RPL Data Plane", Work in
Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-36, Progress, Internet-Draft, draft-ietf-roll-useofrplinfo-36,
26 February 2020, <https://tools.ietf.org/html/draft-ietf- 26 February 2020, <https://tools.ietf.org/html/draft-ietf-
roll-useofrplinfo-36>. roll-useofrplinfo-36>.
[EFFICIENT-NPDAO] [EFFICIENT-NPDAO]
Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient
Route Invalidation", Work in Progress, Internet-Draft, Route Invalidation", Work in Progress, Internet-Draft,
draft-ietf-roll-efficient-npdao-17, 30 October 2019, draft-ietf-roll-efficient-npdao-17, 30 October 2019,
<https://tools.ietf.org/html/draft-ietf-roll-efficient- <https://tools.ietf.org/html/draft-ietf-roll-efficient-
npdao-17>. npdao-17>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>.
15. Informative References 15. Informative References
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing", Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012, RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>. <https://www.rfc-editor.org/info/rfc6606>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
skipping to change at page 30, line 44 skipping to change at page 31, line 7
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur, [RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur,
Ed., "Performance Evaluation of the Routing Protocol for Ed., "Performance Evaluation of the Routing Protocol for
Low-Power and Lossy Networks (RPL)", RFC 6687, Low-Power and Lossy Networks (RPL)", RFC 6687,
DOI 10.17487/RFC6687, October 2012, DOI 10.17487/RFC6687, October 2012,
<https://www.rfc-editor.org/info/rfc6687>. <https://www.rfc-editor.org/info/rfc6687>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, Ed., "A Security Threat Analysis for and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<https://www.rfc-editor.org/info/rfc7416>. <https://www.rfc-editor.org/info/rfc7416>.
[RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Paging Dispatch", Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
RFC 8025, DOI 10.17487/RFC8025, November 2016, RFC 8025, DOI 10.17487/RFC8025, November 2016,
<https://www.rfc-editor.org/info/rfc8025>. <https://www.rfc-editor.org/info/rfc8025>.
 End of changes. 56 change blocks. 
157 lines changed or deleted 162 lines changed or added

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