ROLL P. Thubert, Ed.
Internet-Draft Cisco
Updates: 6550, 6775 (if approved) May 23, 2018
Intended status: Standards Track
Expires: November 24, 2018
Routing for RPL Leaves
draft-thubert-roll-unaware-leaves-05
Abstract
This specification updates RFC 6550 and RFC 6775 unicast routing
service in a RPL domain to 6LoWPAN ND nodes that do not participate
to the routing protocol.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 24, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Thubert Expires November 24, 2018 [Page 1]
Internet-Draft Routing for RPL Leaves May 2018
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. References . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . . . 5
3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 6
4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 7
5. Updating RFC 6775 Update . . . . . . . . . . . . . . . . . . 7
6. Dependencies on the 6LN . . . . . . . . . . . . . . . . . . . 8
7. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 8
7.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 8
7.2. 6LN Operation . . . . . . . . . . . . . . . . . . . . . . 10
7.3. 6LR Operation . . . . . . . . . . . . . . . . . . . . . . 11
7.4. RPL Root Operation . . . . . . . . . . . . . . . . . . . 12
7.5. 6LBR Operation . . . . . . . . . . . . . . . . . . . . . 13
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
12.1. Normative References . . . . . . . . . . . . . . . . . . 14
12.2. Informative References . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction
The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, which is the most constrained resource of
all. Other design constraints, such as a limited memory capacity,
duty cycling of the LLN devices and low-power lossy transmissions,
derive from that primary concern.
The IETF produced the "Routing Protocol for Low Power and Lossy
Networks" [RFC6550] (RPL) to provide routing services within such
constraints. RPL is a Distance-Vector protocol, which, compared to
link-state protocols, limits the amount of topological knowledge that
needs to be installed and maintained in each node. In order to
operate in constrained networks, RPL allows a Routing Stretch (see
[RFC6687]), whereby routing is only performed along a DODAG as
opposed to straight along a shortest path between 2 peers, whatever
that would mean in a given LLN. This trades the quality of peer-to-
peer (P2P) paths for a vastly reduced amount of control traffic and
routing state that would be required to operate a any-to-any shortest
path protocol. Finally, broken routes may be fixed lazily and on-
demand, based on dataplane inconsistency discovery, which avoids
wasting energy in the proactive repair of unused paths.
Thubert Expires November 24, 2018 [Page 2]
Internet-Draft Routing for RPL Leaves May 2018
In order to cope with lossy transmissions, RPL forms Direction-
Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information
Solicitation (DIS) and DODAG Information Object (DIO) messages. For
most of the nodes, though not all, a DODAG provides multiple
forwarding solutions towards the Root of the topology via so-called
parents. RPL is designed to adapt to fuzzy connectivity, whereby the
physical topology cannot be expected to reach a stable state, with a
lazy control that creates routes proactively but only fixes them when
they are used by actual traffic. It results that RPL provides
reachability for most of the LLN nodes, most of the time, but does
not really converge in the classical sense. RPL provides unicast and
multicast routing services back to RPL-Aware nodes (RANs). A RAN
will inject routes to self using Destination Advertisement Object
(DAO) messages sent to either their parents in Storing Mode or to the
Root indicating their parent in Non-Storing mode. This process
effectively forms a DODAG back to the device that is a subset of the
DODAG to the Root with all links reversed.
When a routing protocol such as RPL is used to maintain reachability
within a Non-Broadcast Multi-Access (NBMA) subnet, some nodes may act
as routers and participate to the routing operations whereas others
may be plain hosts. In RPL terms, a plain host that does not
participate to the routing protocol is called a Leaf. It must be
noted that a 6LN could participate to RPL and inject DAO routes to
self, but refrain from advertising DIO and get children. In that
case, the 6LN is still a host but not a Leaf.
This specification enables a RPL-Unaware Leaf (RUL) to announce
itself as a host and demand that the 6LR that accepts the
registration also inject the relevant routing information for the
Registered Address in the RPL domain on its behalf. The packet
forwarding operation by the 6LR serving a Leaf 6LN is described in
"When to use RFC 6553, 6554 and IPv6-in-IPv6"
[I-D.ietf-roll-useofrplinfo]. This document adds the capability by a
6LR to advertise the IPv6 address(es) of the 6LN in the RPL protocol.
Examples of routing-agnostic 6LN may include lightly-powered sensors
such as window smash sensor (alarm system), or the kinetically
powered light switch.
2. Terminology
2.1. BCP 14
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
Thubert Expires November 24, 2018 [Page 3]
Internet-Draft Routing for RPL Leaves May 2018
2.2. References
The Terminology used in this document is consistent with and
incorporates that described in Terms Used in Routing for Low-Power
and Lossy Networks (LLNs). [RFC7102].
Other terms in use in LLNs are found in Terminology for Constrained-
Node Networks [RFC7228].
A glossary of classical 6LoWPAN acronyms is given in Section 2.3.
The term "byte" is used in its now customary sense as a synonym for
"octet".
"RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO
and DIS messages are defined in the "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks" [RFC6550] specification.
This document introduces the term RPL-Unaware Leaf (RUL) to refer to
a node that uses a RPL router (without necessarily knowing it) as 6LR
and depends on that router to obtain reachability for its addresses
inside the RPL domain. On the contrary, the term RPL-Aware Leaf
(RAL) is used to refer to a host or a router that participates to RPL
and advertises its addresses of prefixes by itself.
Other terms in use in LLNs are found in Terminology for Constrained-
Node Networks [RFC7228].
Readers are expected to be familiar with all the terms and concepts
that are discussed in
o "Neighbor Discovery for IP version 6" [RFC4861],
o "IPv6 Stateless Address Autoconfiguration" [RFC4862],
o "Problem Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606],
o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
o "Neighbor Discovery Optimization for Low-power and Lossy Networks"
[RFC6775], and
o "Registration Extensions for 6LoWPAN Neighbor Discovery"
[I-D.ietf-6lo-rfc6775-update].
Thubert Expires November 24, 2018 [Page 4]
Internet-Draft Routing for RPL Leaves May 2018
2.3. Subset of a 6LoWPAN Glossary
This document often uses the following acronyms:
6BBR: 6LoWPAN Backbone Router (proxy for the registration)
6LBR: 6LoWPAN Border Router (authoritative on DAD)
6LN: 6LoWPAN Node
6LR: 6LoWPAN Router (relay to the registration process)
6CIO: Capability Indication Option
(E)ARO: (Extended) Address Registration Option
(E)DAR: (Extended) Duplicate Address Request
(E)DAC: (Extended) Duplicate Address Confirmation
DAD: Duplicate Address Detection
DODAG: Destination-Oriented Directed Acyclic Graph
LLN: Low-Power and Lossy Network (a typical IoT network)
NA: Neighbor Advertisement
NCE: Neighbor Cache Entry
ND: Neighbor Discovery
NDP: Neighbor Discovery Protocol
NS: Neighbor Solicitation
ROVR: Registration Ownership Verifier (pronounced rover)
RPL: IPv6 Routing Protocol for LLNs (pronounced ripple)
RA: Router Advertisement
RS: Router Solicitation
TSCH: Timeslotted Channel Hopping
TID: Transaction ID (a sequence counter in the EARO)
Thubert Expires November 24, 2018 [Page 5]
Internet-Draft Routing for RPL Leaves May 2018
3. 6LoWPAN Neighbor Discovery
The IPv6 [RFC8200]Neighbor Discovery (IPv6 ND) Protocol (NDP) suite
[RFC4861] [RFC4862] defined for fast media such a Ethernet, relies
heavily on multicast operations for address discovery and duplicate
address detection (DAD).
"Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775]
(6LoWPAN ND) adapts IPv6 ND for operations over energy-constrained
LLNs. In particular, 6LoWPAN ND introduces a unicast host address
registration mechanism that contributes to reduce the use of
multicast messages that are present in the classical IPv6 ND
protocol. 6LoWPAN ND defines a new Address Registration Option (ARO)
that is carried in the unicast Neighbor Solicitation (NS) and
Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN)
and the 6LoWPAN Router (6LR). 6LoWPAN ND also defines the Duplicate
Address Request (DAR) and Duplicate Address Confirmation (DAC)
messages between 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.
"Registration Extensions for 6LoWPAN Neighbor Discovery"
[I-D.ietf-6lo-rfc6775-update] defines an Extended ARO (EARO). The
format of the EARO is shown in Figure 1:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Status | Opaque |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | I |R|T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
... Registration Ownership Verifier ...
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: EARO Option Format
The 'R' flag that is set if the Registering Node expects that the 6LR
ensures reachability for the Registered Address, e.g., by means of
routing or proxying ND.
The EARO also includes a sequence counter called Transaction ID
(TID), which maps to the Path Sequence Field found in Transit Options
in RPL DAO messages. It is a prerequisite for this specification.
Thubert Expires November 24, 2018 [Page 6]
Internet-Draft Routing for RPL Leaves May 2018
Finally, the EARO transports an Opaque field and an 'I' field that
describes what the Opaque field transports and how to use it. This
specification requires that the I field is left to 0 and to use the
Opaque field to carry the RPL InstanceID if one is known, else to
leave the Opaque field to zero.
4. Updating RFC 6550
This document specifies a new behavior whereby a 6LR injects DAO
messages for unicast addresses registered through the updated 6LoWPAN
ND [I-D.ietf-6lo-rfc6775-update] on behalf of 6LN nodes that are not
RPL-aware.
Upon the renewal of a 6lowPAN ND registration, this specification
changes the behavior of the 6LR as follows. If the 'R' flag is set,
the 6LR injects a DAO targeting the Registered Address, and refrains
from sending a DAR message. the DAR/DAC exchange that refreshes the
state in the 6LBR happens instead between the RPL Root and the 6LBR.
In that flow, the RPL Root acts as a proxy on behalf of the 6LR upon
the reception of the DAO propagation initiated at the 6LR.
5. Updating RFC 6775 Update
The behavior defined in this specification whereby the 6LR that
processes the registration advertises the Registered Address in DAO
messages and bypasses the DAR/DAC process for the renewal of a
registration, is only triggered by an NS(EARO) that has the 'R' flag
set. If the 'R' flag is not set, then the Registering Node is
expected to be a RAN router that handles the reachability of the
Registered Address by itself.
This document also specifies a keep-alive EDAR message that the RPL
Root may use to maintain an existing state in the 6LBR upon receiving
DAO messages. The keep-alive EDAR message may only act as a
refresher and can only update the Lifetime and the TID of the state
in the 6LBR.
This document similarly specifies a keep-alive NS(EARO) message that
the RPL Root may use to maintain an existing state in a 6BBR upon
receiving DAO messages. The keep-alive NS(EARO) message may only act
as a refresher and can only update the Lifetime and the TID of the
state in the 6BBR.
As prescribed by [I-D.ietf-6lo-rfc6775-update], a RPL router SHOULD
NOT set the 'R' flag.
Thubert Expires November 24, 2018 [Page 7]
Internet-Draft Routing for RPL Leaves May 2018
6. Dependencies on the 6LN
This document provides RPL routing for a 6LN acting as a plain host
and not aware of RPL. Still, a minimal RPL-independent functionality
is expected from the 6LN in order to operate properly as a RLU; in
particular:
o the 6LN MUST implement [I-D.ietf-6lo-rfc6775-update] and set the
'R' flag in the EARO option. The 'R' flag is used to determine
whether the Registering Node is a RUL, not aware of the RPL
operation in the network, and thus does not participate to it. A
6LN is considered to be a RUL if and only if it sets the 'R' flag
in the EARO.
o RPL data packets typically carry a Hop-by-Hop Header to transport
a RPL Packet Information (RPI) [RFC6550]. The 6LN MUST ignore the
RPI and skip the HbH header.
o RPL data packets are often encapsulated using IP in IP. The 6LN
MUST be able to decapsulate a packet when it is the destination of
the outer header and process correctly the inner header.
7. Protocol Operations
7.1. General Flow
This specification enables to save the exchange of Extended Duplicate
Address messages, EDAR and EDAC, from a 6LN all the way to the 6LBR
across a RPL mesh, for the sole purpose of refreshing an existing
state in the 6LBR. Instead, the EDAR/EDAC exchange is proxied by the
RPL Root upon a DAO message that refreshes the RPL routing state. To
achieve this, the lifetimes and sequence counters in 6LoWPAN ND and
RPL are aligned. In other words, the Path Sequence and the Path
Lifetime in the DAO message are derived from the Transaction ID and
the registration lifetime in the NS(EARO) message from the 6LN.
From the perspective of the 6LN, the registration flow happens
transparently; it is not delayed by the proxy RPL operation, so the
device does not need to wait more whether RPL proxy operation happens
or not. The flows below are RPL Non-Storing Mode examples. In
Storing Mode, the DAO ACK may not be present, and the DAO messages
cascade from child to parent all the way to the DODAG Root.
On the first registration, illustrated in Figure 2, from the
perspective of the 6LR, the Extended Duplicate Address message takes
place as prescribed by [I-D.ietf-6lo-rfc6775-update]. When
successful, the flow creates a Neighbor Cache Entry (NCE) in the 6LR,
and the 6LR injects the Registered Address in RPL using DAO/DAO-ACK
Thubert Expires November 24, 2018 [Page 8]
Internet-Draft Routing for RPL Leaves May 2018
exchanges all the way to the RPL DODAG Root. The protocol does not
carry a specific information that the Extended Duplicate Address
messages were already exchanged, so the Root proxies them anyway.
6LN 6LR Root 6LBR
| | | |
| NS(EARO) | | |
|--------------->| |
| | Extended DAR |
| |-------------------------------->|
| | |
| | Extended DAC |
| |<--------------------------------|
| NA(EARO) | |
|<---------------| | |
| | DAO | |
| |-------------->| |
| | DAO ACK | |
| |<--------------| |
| | | keep-alive EDAR |
| | |---------------->|
| | | EDAC |
| | |<----------------|
| | | |
Figure 2: First Registration Flow
A re-registration is performed by the 6LN to maintain the NCE in the
6LR alive before lifetime expires. Upon a re-registration, as
illustrated in Figure 2, the 6LR redistributes the Registered Address
NS(EARO) in RPL. This causes the RPL DODAG Root to refresh the state
in the 6LBR with a keep-alive EDAC message. The keep-alive EDAC
lacks the Registration Ownership Verifier (ROVR) information, since
it is not present in RPL DAO messages, but the EDAC message sent in
response by the 6LBR contains the actual value of the ROVR field for
that registration. This enables the RPL Root to perform the proxy-
registration for the Registered Address and attract traffic captured
over the backbone by the 6BBR and route it back to the device.
Thubert Expires November 24, 2018 [Page 9]
Internet-Draft Routing for RPL Leaves May 2018
6LN 6LR Root 6LBR 6BBR
| | | | |
| NS(EARO) | | | |
|--------------->| | | |
| NA(EARO) | | | |
|<---------------| | | |
| | | | |
| | DAO | | |
| |-------------->| | |
| | DAO ACK | | |
| |<--------------| | |
| | | | |
| | | keep-alive EDAR | |
| | |---------------->| |
| | | EDAC(ROVR) | |
| | |<----------------| |
| | | | |
| | | proxy NS(EARO) |
| | |-------------------------------->|
| | | proxy NA(EARO) |
| | |<--------------------------------|
| | | | |
Figure 3: Next Registration Flow
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,
and possibly through internal API calls as opposed to messaging.
7.2. 6LN Operation
This specification does not alter the operation of a 6LowpAN ND-
compliant 6LN, which is expected to operate as follows:
o The 6LN obtains an IPv6 global address, for instance using
autoconfiguration [RFC4862] based on a Prefix Information Option
(PIO) [RFC4861] found in a Router Advertisement message or by some
other means such as DHCPv6 [RFC3315].
o Once it has formed an address, the 6LN (re)registers its address
periodically, within the Lifetime of the previous registration, as
prescribed by [I-D.ietf-6lo-rfc6775-update].
o Upon each consecutive registration, the 6LN MUST increase the TID
field.
o If the 6LN is aware of the RPL Instance the packet should be
injected into, then it SHOULD set the Opaque field to the
Thubert Expires November 24, 2018 [Page 10]
Internet-Draft Routing for RPL Leaves May 2018
InstanceID, else it MUST leave the Opaque field to zero. In any
fashion the 6LN MUST set the 'I' field to zero.
o A 6LN acting as a RUL MUST set the 'R' flag in the EARO whereas a
6LN acting as a RAN SHOULD NOT set the 'R' flag.
o The 6LN MAY register to more than one 6LR at the same time. In
that case, a same value of TID is used for each registration.
o The 6LN MAY use any of the 6LRs to which it register to forward
its packets.
7.3. 6LR Operation
Also as prescribed by [I-D.ietf-6lo-rfc6775-update], the 6LR
generates a DAR message upon reception of a valid NS(EARO) message
for the registration of a new IPv6 Address by a 6LN. If the
Duplicate Address exchange succeeds, then the 6LR installs a Neighbor
Cache Entry (NCE). If the 'R' 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' flag in the ARO of the response NA
message.
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
TID that is incremented each time till it wraps in a lollipop
fashion. As long as the 'R' flag is set and this router can still
manage the reachability of Registered Address, the 6LR keeps setting
the 'R' flag in the EARO of the response NA message, but the exchange
of Extended Duplicate Address messages is skipped.
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
packets sourced at the registered address when there is no RPL Packet
Information (RPI) in the packet, in which case the 6LR SHOULD add one
to the packet. if the 'I' field is not zero, then the 6LR MUST
consider that the Opaque field is left to zero. If the Opaque field
is not set to zero, then it should carry a RPL InstanceID for the
Instance suggested by the 6LN. If the 6LR does not participate to
the associated Instance, then the 6LR MUST consider that the Opaque
field is left to zero. If the Opaque field left to zero, the 6LR is
free to use the default Instance (zero) for the registered address or
to select an Instance of its choice; else, that is if the 6LR
participates to the suggested Instance, then the 6LR SHOULD use that
Instance for the registered address.
Upon a successful NS/NA(EARO) exchange: if the 'R' flag was set in
the EARO of the NS message, then the 6LR SHOULD inject the Registered
Thubert Expires November 24, 2018 [Page 11]
Internet-Draft Routing for RPL Leaves May 2018
Address in RPL by sending a DAO message on behalf of the 6LN; else
the 6LR MUST NOT inject the Registered Address into RPL.
The DAO message advertising the Registered Address MUST be
constructed as follows:
o The Registered Address is placed in a RPL Target Option in the DAO
message as the Target Prefix, and the Prefix Length is set to 128
o the External 'E' flag in the Transit Information Option (TIO)
associated to the Target Option is set to indicate that the 6LR
redistributes an external target into the RPL network
o 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
operation. Note that if the lifetime is 0, then the 6LR generates
a No-Path DAO message that cleans up the routes down to the
Address of the 6LN.
o the Path Sequence in the TIO is set to the TID value found in the
EARO option.
o Additionally, in Non-Storing Mode the 6LR indicates one of its
global IPv6 unicast addresses as the Parent Address in the TIO.
If a 6LR receives a valid NS(EARO) message with the 'R' flag reset
and the 6LR was redistributing the Registered Address due to previous
NS(EARO) messages with the flag set, then it MUST stop injecting the
address. It is up to the Registering Node to maintain the
corresponding route from then on, either keeping it active by sending
further DAO messages, or destroying it using a No-Path DAO.
7.4. RPL Root Operation
In RPL Storing Mode of Operation (MOP), the DAO message is propagated
from child to parent all the way to the Root along the DODAG,
populating routing state as it goes. In Non-Storing Mode, The DAO
message is sent directly to the route. Upon reception of a DAO
message that creates or updates an existing RPL state:
o the Root notifies the 6LBR using an internal API if they are
collocated, or performs a keep-alive DAR/DAC exchange on behalf of
the registering node if they are separated.
o In an extended topology with a Backbone Link, the Root notifies
the 6LBR by proxying a keep-alive NS(EARO) on behalf of the 6LN
that owns the address indicated in the Target Option.
Thubert Expires November 24, 2018 [Page 12]
Internet-Draft Routing for RPL Leaves May 2018
The keep-alive EDAR and the NS(EARO) messages MUST be constructed as
follows:
o The Target IPv6 address from in the RPL Target Option is placed in
the Registered Address field of the EDAR message and in the Target
field of the NS message, respectively
o the ROVR field in the keep-alive EDAR is set to 64-bits of all
ones to indicate that it is not provided and this is a keep-alive
EDAR. The actual value of the ROVR for that registration is
returned by the 6LBR in an EDAC, and used in the proxy NS(EARO).
o the Registration Lifetime is adapted from the Path Lifetime in the
TIO by converting the Lifetime Units used in RPL into units of 60
seconds used in the 6LoWPAN ND messages.
o The RPL Root indicates its own MAC Address as Source Link Layer
Address (SLLA) in the NS(EARO).
o the TID value is set to the Path Sequence in the TIO. The 'T'
flag and an ICMP code of 1 are used in the NS(EARO) and the DAR
message, respectively.
Upon a status in a DAC message that is not "Success", the Root MAY
destroy the formed paths using a No-Path DAO downwards as specified
in [I-D.ietf-roll-efficient-npdao].
In Non-Storing Mode, the outer IPv6 header that is used by the Root
to transport the source routing information in data packets down the
DODAG has the 6LR that serves the 6LN as final destination. This
way, when the final 6LR decapsulates the outer header, it also
removes all the RPL artifacts from the packet.
7.5. 6LBR Operation
Upon reception of a DAR message with the Owner Unique ID field is set
to all ones, the 6LBR checks whether an entry exists for the and
computes whether the TID in the DAR message is fresher than that in
the entry as prescribed in section 4.2.1. of
[I-D.ietf-6lo-rfc6775-update].
If the entry does not exist, the 6LBR does not create the entry, and
answers with a Status "Removed" in the DAC message.
If the entry exists but is not fresher, the 6LBR does not update the
entry, and answers with a Status "Success" in the DAC message.
Thubert Expires November 24, 2018 [Page 13]
Internet-Draft Routing for RPL Leaves May 2018
If the entry exists and the TID in the DAR message is fresher, the
6LBR updates the TID in the entry, and if the lifetime of the entry
is extended by the Registration Lifetime in the DAR message, it also
updates the lifetime of the entry. In that case, the 6LBR replies
with a Status "Success" in the DAC message.
8. Implementation Status
9. Security Considerations
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
right devices are acting in these roles, so as to avoid threats such
as black-holing, or bombing attack whereby an impersonated 6LBR would
destroy state in the network by using the "Removed" Status code.
This trust model could be at a minimum based on a Layer-2 access
control, or could provide role validation as well. This is a generic
6LoWPAN requirement, see Req5.1 in Appendix of
[I-D.ietf-6lo-rfc6775-update].
The keep-alive EDAR message does not carry a valid Registration
Unique ID [I-D.ietf-6lo-rfc6775-update] and it cannot be used to
create a binding state in the 6LBR. The 6LBR MUST NOT create an
entry based on a keep-alive EDAR that does not match an existing
entry. All it can do is refresh the lifetime and the TID of an
existing entry.
10. IANA Considerations
This specification has no requirement on IANA.
11. Acknowledgments
The author wishes to thank Michael Richardson and Georgios
Papadopoulos for their early reviews of and contributions to this
document
12. References
12.1. Normative References
[I-D.ietf-6lo-rfc6775-update]
Thubert, P., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for 6LoWPAN Neighbor
Discovery", draft-ietf-6lo-rfc6775-update-19 (work in
progress), April 2018.
Thubert Expires November 24, 2018 [Page 14]
Internet-Draft Routing for RPL Leaves May 2018
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007,
<https://www.rfc-editor.org/info/rfc4919>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
Thubert Expires November 24, 2018 [Page 15]
Internet-Draft Routing for RPL Leaves May 2018
12.2. Informative References
[I-D.ietf-6lo-ap-nd]
Thubert, P., Sarikaya, B., and M. Sethi, "Address
Protected Neighbor Discovery for Low-power and Lossy
Networks", draft-ietf-6lo-ap-nd-06 (work in progress),
February 2018.
[I-D.ietf-roll-efficient-npdao]
Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient
Route Invalidation", draft-ietf-roll-efficient-npdao-03
(work in progress), March 2018.
[I-D.ietf-roll-useofrplinfo]
Robles, I., Richardson, M., and P. Thubert, "When to use
RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll-
useofrplinfo-23 (work in progress), May 2018.
[IEEEstd802154]
IEEE standard for Information Technology, "IEEE Standard
for Local and metropolitan area networks-- Part 15.4: Low-
Rate Wireless Personal Area Networks (LR-WPANs)".
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur,
Ed., "Performance Evaluation of the Routing Protocol for
Low-Power and Lossy Networks (RPL)", RFC 6687,
DOI 10.17487/RFC6687, October 2012,
<https://www.rfc-editor.org/info/rfc6687>.
[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>.
Author's Address
Thubert Expires November 24, 2018 [Page 16]
Internet-Draft Routing for RPL Leaves May 2018
Pascal Thubert (editor)
Cisco Systems, Inc
Building D
45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254
FRANCE
Phone: +33 497 23 26 34
Email: pthubert@cisco.com
Thubert Expires November 24, 2018 [Page 17]