[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-thubert-roll-unaware-leaves) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

ROLL                                                     P. Thubert, Ed.
Internet-Draft                                             Cisco Systems
Updates: 6550, 6775, 8505 (if approved)                    M. Richardson
Intended status: Standards Track                               Sandelman
Expires: 20 June 2021                                   17 December 2020

                         Routing for RPL Leaves


   This specification updates RFC6550, RFC6775, and RFC8505.  It
   provides a mechanism for a host that implements a routing-agnostic
   interface based on 6LoWPAN Neighbor Discovery to obtain reachability
   services across a network that leverages RFC6550 for its routing

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 20 June 2021.

Copyright Notice

   Copyright (c) 2020 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 & Richardson      Expires 20 June 2021                  [Page 1]

Internet-Draft             RPL Unaware Leaves              December 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.1.  Requirements Language . . . . . . . . . . . . . . . . . .   6
     2.2.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . .   6
     2.3.  References  . . . . . . . . . . . . . . . . . . . . . . .   7
   3.  RPL External Routes and Dataplane Artifacts . . . . . . . . .   8
   4.  6LoWPAN Neighbor Discovery  . . . . . . . . . . . . . . . . .   9
     4.1.  RFC 6775 Address Registration . . . . . . . . . . . . . .   9
     4.2.  RFC 8505 Extended Address Registration  . . . . . . . . .   9
       4.2.1.  R Flag  . . . . . . . . . . . . . . . . . . . . . . .  10
       4.2.2.  TID, "I" Field and Opaque Fields  . . . . . . . . . .  10
       4.2.3.  Route Ownership Verifier  . . . . . . . . . . . . . .  11
     4.3.  RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . .  11
       4.3.1.  RFC 7400 Capability Indication Option . . . . . . . .  12
   5.  Requirements on the RPL-Unware leaf . . . . . . . . . . . . .  12
     5.1.  Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . .  12
     5.2.  Support of IPv6 Encapsulation . . . . . . . . . . . . . .  13
     5.3.  Support of the Hop-by-Hop Header  . . . . . . . . . . . .  13
     5.4.  Support of the Routing Header . . . . . . . . . . . . . .  13
   6.  Enhancements to RFC 6550  . . . . . . . . . . . . . . . . . .  14
     6.1.  Updated RPL Target Option . . . . . . . . . . . . . . . .  14
     6.2.  Additional Flag in the RPL DODAG Configuration Option . .  16
     6.3.  Updated RPL Status  . . . . . . . . . . . . . . . . . . .  17
   7.  Enhancements to draft-ietf-roll-efficient-npdao . . . . . . .  19
   8.  Enhancements to RFC 6775 and RFC8505  . . . . . . . . . . . .  19
   9.  Protocol Operations for Unicast Addresses . . . . . . . . . .  20
     9.1.  General Flow  . . . . . . . . . . . . . . . . . . . . . .  20
     9.2.  Detailed Operation  . . . . . . . . . . . . . . . . . . .  23
       9.2.1.  Perspective of the 6LN Acting as RUL  . . . . . . . .  23
       9.2.2.  Perspective of the 6LR Acting as Border router  . . .  25
       9.2.3.  Perspective of the RPL Root . . . . . . . . . . . . .  29
       9.2.4.  Perspective of the 6LBR . . . . . . . . . . . . . . .  30
   10. Protocol Operations for Multicast Addresses . . . . . . . . .  30
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  33
   12. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  34
     12.1.  Fixing the Address Registration Option Flags . . . . . .  34
     12.2.  Resizing the ARO Status values . . . . . . . . . . . . .  35
     12.3.  New RPL DODAG Configuration Option Flag  . . . . . . . .  35
     12.4.  RPL Target Option Registry . . . . . . . . . . . . . . .  35
     12.5.  New Subregistry for RPL Non-Rejection Status values  . .  36
     12.6.  New Subregistry for RPL Rejection Status values  . . . .  36
   13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  37
   14. Normative References  . . . . . . . . . . . . . . . . . . . .  37
   15. Informative References  . . . . . . . . . . . . . . . . . . .  38
   Appendix A.  Example Compression  . . . . . . . . . . . . . . . .  40
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  41

Thubert & Richardson      Expires 20 June 2021                  [Page 2]

Internet-Draft             RPL Unaware Leaves              December 2020

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 IPv6 [RFC8200] routing services
   within such constraints.  RPL belongs to the class of Distance-Vector
   protocols, which, compared to link-state protocols, limit the amount
   of topological knowledge that needs to be installed and maintained in
   each node, and does not require convergence to avoid micro-loops.

   To save signaling and routing state in constrained networks, RPL
   allows a path stretch (see [RFC6687]), whereby routing is only
   performed along a Destination-Oriented Directed Acyclic Graph (DODAG)
   that is optimized to reach a Root node, as opposed to along the
   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 an any-to-any shortest path protocol.
   Additionally, 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.

   For many of the nodes, though not all, the 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 the routes proactively, but may only fix
   them reactively, upon actual traffic.  The result is that RPL
   provides reachability for most of the LLN nodes, most of the time,
   but may not converge in the classical sense.

   RPL can be deployed in conjunction with IPv6 Neighbor Discovery (ND)
   [RFC4861] [RFC4862] and 6LoWPAN ND [RFC6775] [RFC8505] to maintain
   reachability within a Non-Broadcast Multiple-Access (NBMA) Multi-Link

   In that mode, IPv6 addresses are advertised individually as host
   routes.  Some nodes may act as routers and participate in the
   forwarding operations whereas others will only receive/originate
   packets, acting as hosts in the data-plane.  In [RFC6550] terms, an
   IPv6 host [RFC8504] that is reachable over the RPL network is called
   a leaf.

Thubert & Richardson      Expires 20 June 2021                  [Page 3]

Internet-Draft             RPL Unaware Leaves              December 2020

   Section 2 of [USEofRPLinfo] defines the terms RPL leaf, RPL-Aware-
   leaf (RAL) and RPL-Unaware Leaf (RUL).  A RPL leaf is a host attached
   to one or more RPL router(s); as such, it relies on the RPL router(s)
   to forward its traffic across the RPL domain but does not forward
   traffic from another node.  As opposed to the RAL, the RUL does not
   participate to RPL, and relies on its RPL router(s) also to inject
   the routes to its IPv6 addresses in the RPL domain.

   A RUL may be unable to participate because it is very energy-
   constrained, code-space constrained, or because it would be unsafe to
   let it inject routes in RPL.  Using 6LoWPAN ND as opposed to RPL as
   the host-to-router interface limits the surface of the possible
   attacks by the RUL against the RPL domain.  If all RULs and RANs use
   6LoWPAN ND for Neighbor Discovery, it is also possible to protect the
   address ownership of all nodes, including the RULs.

   This document specifies how the router injects the host routes in the
   RPL domain on behalf of the RUL.  Section 5 details how the RUL can
   leverage 6LoWPAN ND to obtain the routing services from the router.
   In that model, the RUL is also a 6LoWPAN Node (6LN) and the RPL-Aware
   router is also a 6LoWPAN router (6LR).  Using the 6LoWPAN ND Address
   Registration mechanism, the RUL signals that the router must inject a
   host route for the Registered Address.

                  |          Internet
               |     | <------------- 6LBR / RPL Root
               +-----+                     ^
                  |                        |
            o    o   o  o                  | RPL
        o o   o  o   o  o     o    o       |
       o  o o  o o    o   o  o   o  o      |  +
       o   o      o     o   o   o    o     |
      o  o   o  o   o  o    o    o  o      | 6LoWPAN ND
         o  o  o  o        o   o           |
        o       o            o    o        v
      o      o     o <------------- 6LR / RPL Border router
                                           | 6LoWPAN ND only
                   u <------------- 6LN / RPL-Unaware Leaf

                Figure 1: Injecting Routes on behalf of RULs

Thubert & Richardson      Expires 20 June 2021                  [Page 4]

Internet-Draft             RPL Unaware Leaves              December 2020

   The RPL Non-Storing Mode mechanism is used to extend the routing
   state with connectivity to the RULs even when the DODAG is operated
   in Storing Mode.  The unicast packet forwarding operation by the 6LR
   serving a RUL is described in section 4.1 of [USEofRPLinfo].

   Examples of possible RULs include severely energy constrained sensors
   such as window smash sensor (alarm system), and kinetically powered
   light switches.  Other applications of this specification may include
   a smart grid network that controls appliances - such as washing
   machines or the heating system - in the home.  Appliances may not
   participate to the RPL protocol operated in the Smartgrid network but
   can still interact with the Smartgrid for control and/or metering.

   This specification can be deployed incrementally in a network that
   implements [USEofRPLinfo].  Only the Root and the 6LRs that connect
   the RULs need to be upgraded.  The RPL routers on path will only see
   unicast IPv6 traffic between the Root and the 6LR.

   This document is organized as follows:

   *  Section 3 and Section 4 present in a non-normative fashion the
      salient aspects of RPL and 6LoWPAN ND, respectively, that are
      leveraged in this specification to provide connectivity to a 6LN
      acting as a RUL across a RPL network.

   *  Section 5 lists the expectations that a RUL needs to match in
      order to be served by a RPL router that complies with this

   *  Section 6 presents the changes made to [RFC6550]; a new behavior
      is introduced whereby the 6LR advertises the 6LN's addresses in a
      RPL DAO message based on the ND registration by the 6LN, and the
      RPL root performs the EDAR/EDAC exchange with the 6LBR on behalf
      of the 6LR; modifications are introduced to some RPL options and
      to the RPL Status to facilitate the integration of the protocols.

   *  Section 7 presents the changes made to [EFFICIENT-NPDAO]; the use
      of the DCO message is extended to the Non-Storing MOP to report
      asynchronous issues from the Root to the 6LR.

   *  Section 8 presents the changes made to [RFC6775] and [RFC8505];
      The range of the ND status codes is reduced down to 64 values, and
      the remaining bits in the original status field are now reserved.

   *  Section 9 and Section 10 present the operation of this
      specification for unicast and multicast flows, respectively, and
      Section 11 presents associated security considerations.

Thubert & Richardson      Expires 20 June 2021                  [Page 5]

Internet-Draft             RPL Unaware Leaves              December 2020

2.  Terminology

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "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.

2.2.  Glossary

   This document uses the following acronyms:

   6CIO:  6LoWPAN Capability Indication Option
   6LN:  6LoWPAN Node (a Low Power host or router)
   6LR:  6LoWPAN router
   6LBR:  6LoWPAN Border router
   (E)ARO:  (Extended) Address Registration Option
   (E)DAR:  (Extended) Duplicate Address Request
   (E)DAC:  (Extended) Duplicate Address Confirmation
   DAD:  Duplicate Address Detection
   DAO:  Destination Advertisement Object (a RPL message)
   DCO:  Destination Cleanup Object (a RPL message)
   DIO:  DODAG Information Object (a RPL message)
   DODAG:  Destination-Oriented Directed Acyclic Graph
   LLN:  Low-Power and Lossy Network
   MOP:  RPL Mode of Operation
   NA:  Neighbor Advertisement
   NCE:  Neighbor Cache Entry
   ND:  Neighbor Discovery
   NS:  Neighbor solicitation
   RA:  router Advertisement
   ROVR:  Registration Ownership Verifier
   RPI:  RPL Packet Information
   RAL:  RPL-aware Leaf
   RAN:  RPL-Aware Node (either a RPL router or a RPL-aware Leaf)
   RUL:  RPL-Unaware Leaf
   SRH:  Source-Routing Header
   TID:  Transaction ID (a sequence counter in the EARO)

Thubert & Richardson      Expires 20 June 2021                  [Page 6]

Internet-Draft             RPL Unaware Leaves              December 2020

2.3.  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].  A glossary of classical
   6LoWPAN acronyms is given in Section 2.2.  Other terms in use in LLNs
   are found in "Terminology for Constrained-Node Networks" [RFC7228].
   This specification uses the terms 6LN and 6LR to refer specifically
   to nodes that implement the 6LN and 6LR roles in 6LoWPAN ND and does
   not expect other functionality such as 6LoWPAN Header Compression
   [RFC6282] from those nodes.

   "RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by
   a RPLInstanceID), "up", "down" are defined in "RPL: IPv6 Routing
   Protocol for Low-Power and Lossy Networks" [RFC6550].  The RPI is the
   abstract information that RPL defines to be placed in data packets,
   e.g., as the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header.
   By extension, the term "RPI" is often used to refer to the RPL Option
   itself.  The Destination Advertisement Object (DAO) and DODAG
   Information Object (DIO) messages are also specified in [RFC6550].
   The Destination Cleanup Object (DCO) message is defined in

   This document uses the terms RPL-Unaware Leaf (RUL), RPL-Aware Node
   (RAN) and RPL aware Leaf (RAL) consistently with [USEofRPLinfo].  A
   RAN is either an RAL or a RPL router.  As opposed to a RUL, a RAN
   manages the reachability of its addresses and prefixes by injecting
   them in RPL by itself.

   In this document, readers will encounter terms and concepts that are
   discussed in the following documents:

   Classical IPv6 ND:  "Neighbor Discovery for IP version 6" [RFC4861]
      and "IPv6 Stateless Address Autoconfiguration" [RFC4862],

   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],

   6LoWPAN ND:  Neighbor Discovery Optimization for Low-Power and Lossy
      Networks [RFC6775], "Registration Extensions for 6LoWPAN Neighbor
      Discovery" [RFC8505], "Address Protected Neighbor Discovery for
      Low-power and Lossy Networks" [RFC8928], and "IPv6 Backbone
      Router" [RFC8929].

Thubert & Richardson      Expires 20 June 2021                  [Page 7]

Internet-Draft             RPL Unaware Leaves              December 2020

3.  RPL External Routes and Dataplane Artifacts

   Section 4.1 of [USEofRPLinfo] provides a set of rules summarized
   below that must be followed for routing packets from and to a RUL.

   A 6LR that acts as a border router for external routes advertises
   them using Non-Storing Mode DAO messages that are unicast directly to
   the Root, even if the DODAG is operated in Storing Mode.  Non-Storing
   Mode routes are not visible inside the RPL domain and all packets are
   routed via the Root.  The RPL Root tunnels the packets directly to
   the 6LR that advertised the external route, which decapsulates and
   forwards the original (inner) packet.

   The RPL Non-Storing MOP signaling and the associated IPv6-in-IPv6
   encapsulated packets appear as normal traffic to the intermediate
   routers.  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 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 route that happens to be also a host route.

   The RPL data packets typically carry a Hop-by-Hop Header with a RPL
   Option [RFC6553] that contains the Packet Information (RPI) defined
   in section 11.2 of [RFC6550].  Unless the RUL already placed a RPL
   Option in outer header chain, the packets from and to the RUL are
   encapsulated using an IPv6-in-IPv6 tunnel between the Root and the
   6LR that serves the RUL (see sections 7 and 8 of [USEofRPLinfo] for
   details).  If the packet from the RUL has an RPI, the 6LR as a RPL
   border router rewrites the RPI to indicate the selected Instance and
   set the flags, but it does not need to encapsulate the packet (see
   Section 9.2.2) .

   In Non-Storing Mode, packets going down carry a Source Routing Header
   (SRH).  The IPv6-in-IPv6 encapsulation, the RPI and the SRH are
   collectively called the "RPL artifacts" and can be compressed using
   [RFC8138].  Appendix A presents an example compressed format for a
   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
   artifacts, e.g., an RPI if the original packet was generated with it,
   and an SRH in a Non-Storing Mode DODAG.  [USEofRPLinfo] expects the
   RUL to support the basic "IPv6 Node Requirements" [RFC8504] and in
   particular the mandates in Sections 4.2 and 4.4 of [RFC8200].  As
   such, the RUL is expected to ignore the RPL artifacts that may be
   left over, either an SRH with zero Segments Left or a RPL Option in
   the Hop-by-Hop Header, which can be skipped when not recognized, see
   Section 5 for more.

Thubert & Richardson      Expires 20 June 2021                  [Page 8]

Internet-Draft             RPL Unaware Leaves              December 2020

   A RUL is not expected to support the compression method defined in
   [RFC8138].  For that reason, the border router (the 6LR here)
   uncompresses the packet before forwarding it over an external route
   to a RUL [USEofRPLinfo].

4.  6LoWPAN Neighbor Discovery

   This section goes through the 6LoWPAN ND mechanisms that this
   specification leverages, as a non-normative reference to the reader.
   The full normative text is to be found in [RFC6775], [RFC8505], and

4.1.  RFC 6775 Address Registration

   The classical "IPv6 Neighbor Discovery (IPv6 ND) Protocol" [RFC4861]
   [RFC4862] was defined for serial links and transit media such as
   Ethernet.  It is a reactive protocol that relies heavily on multicast
   operations for Address Discovery (aka Lookup) and Duplicate Address
   Detection (DAD).

   "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775]
   adapts IPv6 ND for operations over energy-constrained LLNs.  The main
   functions of [RFC6775] are to proactively establish the Neighbor
   Cache Entry (NCE) in the 6LR and to prevent address duplication.  To
   that effect, [RFC6775] introduces a new unicast Address Registration
   mechanism that contributes to reducing the use of multicast messages
   compared to the classical IPv6 ND protocol.

   [RFC6775] 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).  It 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 and
   the source of truth for uniqueness and ownership.

4.2.  RFC 8505 Extended Address Registration

   "Registration Extensions for 6LoWPAN Neighbor Discovery" [RFC8505]
   updates RFC 6775 into a generic Address Registration mechanism that
   can be used to access services such as routing and ND proxy.  To that
   effect, [RFC8505] defines the Extended Address Registration Option
   (EARO), shown in Figure 2:

Thubert & Richardson      Expires 20 June 2021                  [Page 9]

Internet-Draft             RPL Unaware Leaves              December 2020

      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 2: EARO Option Format

4.2.1.  R Flag

   [RFC8505] introduces the R Flag in the EARO.  The Registering Node
   sets the R Flag to indicate whether the 6LR should ensure
   reachability for the Registered Address.  If the R Flag is set to 0,
   then the Registering Node handles the reachability of the Registered
   Address by other means.  In a RPL network, this means that either it
   is a RAN that injects the route by itself or that it uses another RPL
   router for reachability services.

   This document specifies how the R Flag is used in the context of RPL.
   A RPL leaf that implements the 6LN functionality in [RFC8505]
   requires reachability services for an IPv6 address if and only if it
   sets the R Flag in the NS(EARO) used to register the address to a 6LR
   acting as a RPL border router.  Upon receiving the NS(EARO), the RPL
   router generates a DAO message for the Registered Address if and only
   if the R flag is set to 1.

   Section 9.2 specifies additional operations when R flag is set to 1
   in an EARO that is placed either in an NS or an NA message.

4.2.2.  TID, "I" Field and Opaque Fields

   When the T Flag is set to 1, the EARO includes a sequence counter
   called Transaction ID (TID), that is needed to fill the Path Sequence
   Field in the RPL Transit Option.  This is the reason why the support
   of [RFC8505] by the RUL, as opposed to only [RFC6775] is a
   prerequisite for this specification)/; this requirement is fully
   explained in Section 5.1.  The EARO also transports an Opaque field
   and an associated "I" field that describes what the Opaque field
   transports and how to use it.

   Section 9.2.1 specifies the use of the "I" field and the Opaque field
   by a RUL.

Thubert & Richardson      Expires 20 June 2021                 [Page 10]

Internet-Draft             RPL Unaware Leaves              December 2020

4.2.3.  Route Ownership Verifier

   Section 5.3 of [RFC8505] introduces the Registration Ownership
   Verifier (ROVR) field of variable length from 64 to 256 bits.  The
   ROVR is a replacement of the EUI-64 in the ARO [RFC6775] that was
   used to identify uniquely an Address Registration with the Link-Layer
   address of the owner but provided no protection against spoofing.

   "Address Protected Neighbor Discovery for Low-power and Lossy
   Networks" [RFC8928] leverages the ROVR field as a cryptographic proof
   of ownership to prevent a rogue third party from registering an
   address that is already owned.  The use of ROVR field enables the 6LR
   to block traffic that is not sourced at an owned address.

   This specification does not address how the protection by [RFC8928]
   could be extended for use in RPL.  On the other hand, it adds the
   ROVR to the DAO to build the proxied EDAR at the Root (see
   Section 6.1), which means that nodes that are aware of the host route
   are also aware of the ROVR associated to the Target Address.

4.3.  RFC 8505 Extended DAR/DAC

   [RFC8505] updates the DAR/DAC messages into the Extended DAR/DAC to
   carry the ROVR field.  The EDAR/EDAC exchange takes place between the
   6LR and the 6LBR.  It is triggered by an NS(EARO) message from a 6LN
   to create, refresh, and delete the corresponding state in the 6LBR.
   The exchange is protected by the retry mechanism specified in
   Section 8.2.6 of [RFC6775], though in an LLN, a duration longer than
   the default value of the RetransTimer (RETRANS_TIMER) [RFC4861] of 1
   second may be necessary to cover the round trip delay between the 6LR
   and the 6LBR.

   RPL [RFC6550] specifies a periodic DAO from the 6LN all the way to
   the Root that maintains the routing state in the RPL network for the
   lifetime indicated by the source of the DAO.  This means that for
   each address, there are two keep-alive messages that traverse the
   whole network, one to the Root and one to the 6LBR.

   This specification avoids the periodic EDAR/EDAC exchange across the
   LLN.  The 6LR turns the periodic NS(EARO) from the RUL into a DAO
   message to the Root on every refresh, but it only generates the EDAR
   upon the first registration, for the purpose of DAD, which must be
   verified before the address is injected in RPL.  Upon the DAO
   message, the Root proxies the EDAR exchange to refresh the state at
   the 6LBR on behalf of the 6LR, as illustrated in Figure 8 in
   Section 9.1.

Thubert & Richardson      Expires 20 June 2021                 [Page 11]

Internet-Draft             RPL Unaware Leaves              December 2020

4.3.1.  RFC 7400 Capability Indication Option

   "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power
   Wireless Personal Area Networks (6LoWPANs)" [RFC7400] defines the
   6LoWPAN Capability Indication Option (6CIO) that enables a node to
   expose its capabilities in router Advertisement (RA) messages.

   [RFC8505] defines a number of bits in the 6CIO, in particular:

   L:  Node is a 6LR.
   E:  Node is an IPv6 ND Registrar -- i.e., it supports registrations
      based on EARO.
   P:  Node is a Routing Registrar, -- i.e., an IPv6 ND Registrar that
      also provides reachability services for the Registered Address.

       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 = 1  |     Reserved      |D|L|B|P|E|G|
      |                           Reserved                            |

                            Figure 3: 6CIO flags

   A 6LR that provides reachability services for a RUL in a RPL network
   as specified in this document includes a 6CIO in its RA messages and
   set the L, P and E flags to 1 as prescribed by [RFC8505]; this is
   fully explained in Section 9.2.

5.  Requirements on the RPL-Unware leaf

   This document describes how RPL routing can be extended to reach a
   RUL.  This section specifies the minimal RPL-independent
   functionality that the RUL needs to implement to obtain routing
   services for its addresses.

5.1.  Support of 6LoWPAN ND

   To obtain routing services from a router that implements this
   specification, a RUL needs to implement [RFC8505] and sets the "R"
   and "T" flags in the EARO to 1 as discussed in Section 4.2.1 and
   Section 4.2.2, respectively.  Section 9.2.1 specifies new behaviors
   for the RUL, e.g., when the R Flag set to 1 in a NS(EARO) is not
   echoed in the NA(EARO), which indicates that the route injection

Thubert & Richardson      Expires 20 June 2021                 [Page 12]

Internet-Draft             RPL Unaware Leaves              December 2020

   The RUL is expected to request routing services from a router only if
   that router originates RA messages with a CIO that has the L, P, and
   E flags all set to 1 as discussed in Section 4.3.1, unless configured
   to do so.  It is suggested that the RUL also implements [RFC8928] to
   protect the ownership of its addresses.

   A RUL that may attach to multiple 6LRs is expected to prefer those
   that provide routing services.  The RUL needs to register to all the
   6LRs from which it desires routing services.

   Parallel Address Registrations to several 6LRs should be performed in
   a rapid sequence, using the same EARO for the same Address.  Gaps
   between the Address Registrations will invalidate some of the routes
   till the Address Registration finally shows on those routes.

   [RFC8505] introduces error Status values in the NA(EARO) which can be
   received synchronously upon an NS(EARO) or asynchronously.  The RUL
   needs to support both cases and refrain from using the address when
   the Status value indicates a rejection (see Section 6.3).

5.2.  Support of IPv6 Encapsulation

   Section 2.1 of [USEofRPLinfo] defines the rules for tunneling either
   to the final destination (e.g., a RUL) or to its attachment router
   (designated as 6LR).  In order to terminate the IPv6-in-IPv6 tunnel,
   the RUL, as an IPv6 host, would have to be capable of decapsulating
   the tunneled packet and either drop the encapsulated packet if it is
   not the final destination, or pass it to the upper layer for further
   processing.  As indicated in section 4.1 of [USEofRPLinfo], this is
   not mandated by [RFC8504], so the Root typically terminates the IPv6-
   in-IPv6 tunnel at the parent 6LR.  It is thus not necessary for a RUL
   to support IPv6-in-IPv6 decapsulation.

5.3.  Support of the Hop-by-Hop Header

   A RUL is expected to process an Option Type in a Hop-by-Hop Header as
   prescribed by section 4.2 of [RFC8200].  An RPI with an Option Type
   of 0x23 [USEofRPLinfo] is thus skipped when not recognized.

5.4.  Support of the Routing Header

   A RUL is expected to process an unknown Routing Header Type as
   prescribed by section 4.4 of [RFC8200].  This implies that the Source
   Routing Header, which has a Routing Type of 3 [RFC6554], is ignored
   when the Segments Left is zero.  When the Segments Left is non-zero,
   the RUL discards the packet and send an ICMP Parameter Problem, Code
   0, message to the packet's Source Address, pointing to the
   unrecognized Routing Type.

Thubert & Richardson      Expires 20 June 2021                 [Page 13]

Internet-Draft             RPL Unaware Leaves              December 2020

6.  Enhancements to RFC 6550

   This document specifies a new behavior whereby a 6LR injects DAO
   messages for unicast addresses (see Section 9) and multicast
   addresses (see Section 10) on behalf of leaves that are not aware of
   RPL.  The RUL addresses are exposed as external targets [RFC6550].
   Conforming to [USEofRPLinfo], an IPv6-in-IPv6 encapsulation between
   the 6LR and the RPL Root is used to carry the RPL artifacts and
   remove them when forwarding outside the RPL domain, e.g., to a RUL.

   This document also synchronizes the liveness monitoring at the Root
   and the 6LBR.  The same value of lifetime is used for both, and a
   single keep-alive message, the RPL DAO, traverses the RPL network.  A
   new behavior is introduced whereby the RPL Root proxies the EDAR
   message to the 6LBR on behalf of the 6LR (see Section 8), for any
   leaf node that implements the 6LN functionality in [RFC8505].

   Section 6.7.7 of [RFC6550] introduces the RPL Target Option, which
   can be used in RPL Control messages such as the DAO message to signal
   a destination prefix.  This document adds the capabilities to
   transport the ROVR field (see Section 4.2.3) and the IPv6 Address of
   the prefix advertiser when the Target is a shorter prefix.  Their use
   is signaled respectively by a new ROVR Size field being non-zero and
   a new "Advertiser address in Full" 'F' flag set to 1, see
   Section 6.1.

   This specification defines a new flag, "Root Proxies EDAR/EDAC" (P),
   in the RPL DODAG Configuration option, see Section 6.2.

   The RPL Status defined in section 6.5.1 of [RFC6550] for use in the
   DAO-ACK message is extended to be placed in DCO messages
   [EFFICIENT-NPDAO] as well.  Furthermore, this specification enables
   to carry the EARO Status defined for 6LoWPAN ND in RPL DAO and DCO
   messages, embedded in a RPL Status, see Section 6.3.

   Section 12 of [RFC6550] details the RPL support for multicast flows
   when the RPLInstance is operated in the MOP of 3 ("Storing Mode of
   Operation with multicast support").  This specification extends the
   RPL Root operation to proxy-relay the MLDv2 [RFC3810] operation
   between the RUL and the 6LR, see Section 10.

6.1.  Updated RPL Target Option

   This specification updates the RPL Target Option to transport the
   ROVR that was also defined for 6LoWPAN ND messages.  This enables the
   RPL Root to generate the proxied EDAR message to the 6LBR.

Thubert & Richardson      Expires 20 June 2021                 [Page 14]

Internet-Draft             RPL Unaware Leaves              December 2020

   The Target Prefix of the RPL Target Option is left (high bit)
   justified and contains the advertised prefix; its size may be smaller
   than 128 when it indicates a Prefix route.  The Prefix Length field
   signals the number of bits that correspond to the advertised Prefix;
   it is 128 for a host route or less in the case of a Prefix route.
   This remains unchanged.

   This specification defines the new 'F' flag.  When it is set to 1,
   the size of the Target Prefix field MUST be 128 bits and it MUST
   contain an IPv6 address of the advertising node taken from the
   advertised Prefix.  In that case, the Target Prefix field carries two
   distinct pieces of information: a route that can be a host route or a
   Prefix route depending on the Prefix Length, and an IPv6 address that
   can be used to reach the advertising node and validate the route.

   If the 'F' flag is set to 0, the Target Prefix field can be shorter
   than 128 bits and it MUST be aligned to the next byte boundary after
   the end of the prefix.  Any additional bits in the rightmost octet
   are filled with padding bits.  Padding bits are reserved and set to 0
   as specified in section 6.7.7 of [RFC6550].

   With this specification the ROVR is the remainder of the RPL Target
   Option.  The size of the ROVR is indicated in a new ROVR Size field
   that is encoded to map one-to-one with the Code Suffix in the EDAR
   message (see table 4 of [RFC8505]).  The ROVR Size field is taken
   from the flags field, which is an update to the RPL Target Option
   Flags IANA registry.

   The updated format is illustrated in Figure 4.  It is backward
   compatible with the Target Option in [RFC6550].  It is recommended
   that the updated format be used as a replacement in new
   implementations in all MOPs in preparation for upcoming Route
   Ownership Validation mechanisms based on the ROVR, unless the device
   or the network is so constrained that this is not feasible.

      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 = 0x05 | Option Length |F|X|Flg|ROVRsz | Prefix Length |
     |                                                               |
     |                Target Prefix (Variable Length)                |
     .                                                               .
     |                                                               |
    ...            Registration Ownership Verifier (ROVR)           ...
     |                                                               |

Thubert & Richardson      Expires 20 June 2021                 [Page 15]

Internet-Draft             RPL Unaware Leaves              December 2020

                      Figure 4: Updated Target Option

   New fields:

   F:  1-bit flag.  Set to 1 to indicate that Target Prefix field
      contains the complete (128 bit) IPv6 address of the advertising

   X:  1-bit flag.  Set to 1 to request that the Root performs a proxy
      EDAR/EDAC exchange.

      The 'X' flag can only be set to 1 if the DODAG is operating in
      Non-Storing Mode and if the Root sets the "Root Proxies EDAR/EDAC
      (P)" flag to 1 in the DODAG Configuration Option, see Section 6.2.

      The 'X' flag can be set for host routes to RULs and RANs; it can
      also be set for internal prefix routes if the 'F' flag is set,
      using the node's address in the Target Prefix field to form the
      EDAR, but it cannot be used otherwise.

   Flg (Flags):  The 2 bits remaining unused in the Flags field are
      reserved for flags.  The field MUST be initialized to zero by the
      sender and MUST be ignored by the receiver.

   ROVRsz (ROVR Size):  Indicates the Size of the ROVR.  It MUST be set
      to 1, 2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256
      bits, respectively.

      If a legacy Target Option is used, then the value must remain 0,
      as specified in [RFC6550].

      In case of a value above 4, the size of the ROVR is undetermined
      and this node cannot validate the ROVR; an implementation SHOULD
      propagate the whole Target Option upwards as received to enable
      the verification by an ancestor that would support the upgraded

   Registration Ownership Verifier (ROVR):  This is the same field as in
      the EARO, see [RFC8505]

6.2.  Additional Flag in the RPL DODAG Configuration Option

   The DODAG Configuration Option is defined in Section 6.7.6 of
   [RFC6550].  Its purpose is extended to distribute configuration
   information affecting the construction and maintenance of the DODAG,
   as well as operational parameters for RPL on the DODAG, through the
   DODAG.  This Option was originally designed with 4 bit positions
   reserved for future use as Flags.

Thubert & Richardson      Expires 20 June 2021                 [Page 16]

Internet-Draft             RPL Unaware Leaves              December 2020

      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 = 0x04 |Opt Length = 14| |P