ROLL                                                     P. Thubert, Ed.
Internet-Draft                                                     Cisco
Updates: 6550, 8505 (if approved)                           July 2, 4, 2019
Intended status: Standards Track
Expires: January 3, 5, 2020

                         Routing for RPL Leaves


   This specification leverages 6LoWPAN ND to provide a unicast and
   multicast routing service in a RPL domain to 6LNs that do not
   participate to RPL.

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

   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 January 3, 5, 2020.

Copyright Notice

   Copyright (c) 2019 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
   ( 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  BCP 14  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  References  . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . .   5
   3.  6LoWPAN Neighbor Discovery  . . . . . . . . . . . . . . . . .   6
   4.  Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . .   7
   6.  Dependencies on the 6LN . . . . . . . . . . . . . . . . . . .   8
   7.  Protocol Operations for Unicast Addresses . . . . . . . . . .   9
     7.1.  General Flow  . . . . . . . . . . . . . . . . . . . . . .   9
     7.2.  6LN Operation . . . . . . . . . . . . . . . . . . . . . .  11
     7.3.  6LR Operation . . . . . . . . . . . . . . . . . . . . . .  12
     7.4.  RPL Root Operation  . . . . . . . . . . . . . . . . . . .  13
     7.5.  6LBR Operation  . . . . . . . . . . . . . . . . . . . . .  14
   8.  Protocol Operations for Multicast Addresses . . . . . . . . .  15
   9.  Implementation Status . . . . . . . . . . . . . . . . . . . .  17
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  17
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  17
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  17
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  17
     13.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Appendix A.  Example Compression  . . . . . . . . . . . . . . . .  20
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  20  21

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.

   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 unicast
   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 Global, Unique-Local and Multicast 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.  Other application of this specification may
   include a smart grid network that controls appliances - such as
   washing machines or the heating system - in the home.  Applicances
   may not participate to the RPL protocol operated in the smart grid
   network but can still receive control packet from the smart grid.

2.  Terminology

2.1.  BCP 14

   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.  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

   "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 IPv6 over Low-Power Wireless Personal
      Area Network (6LoWPAN) Neighbor Discovery" [RFC8505].

2.3.  Glossary

   This document often uses the following acronyms:

   AR:   Address Resolution (aka Address Lookup)

   6BBR: 6LoWPAN Backbone Router (proxy ND)

   6LBR: 6LoWPAN Border Router (an Address Registrar that is
         authoritative on DAD)

   6LN:  6LoWPAN Node (a Low Power host or router)

   6LR:  6LoWPAN Router

   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

   NA:   Neighbor Advertisement

   NCE:  Neighbor Cache Entry

   ND:   Neighbor Discovery

   NDP:  Neighbor Discovery Protocol

   NS:   Neighbor Solicitation
   RA:   Router Advertisement

   ROVR: Registration Ownership Verifier (pronounced rover)

   RPI:  RPL Packet Information (an Option in the Hop-By_Hop header)

   RAL:  RPL-Aware Leaf

   RS:   Router Solicitation

   RPL:  IPv6 Routing Protocol for LLNs (pronounced ripple)

   RUL:  RPL-Unaware Leaf

   TID:  Transaction ID (a sequence counter in the EARO)

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" [RFC8505]
   updates the behavior of RFC 6775 to enable a generic registration to
   routing services and 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.

   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 [RFC8505] 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 8505

   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 [RFC8505], a RPL router SHOULD NOT set the 'R' flag.

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

   o  the 6LN MUST implement [RFC8505] 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 are often encapsulated using IP in IP and in Non-
      Storing Mode, packets going down will carry an SRH as well.  RPL
      data packets also typically carry a Hop-by-Hop Header to transport
      a RPL Packet Information (RPI) [RFC6550].  These additional
      headers are called RPL artifacts.

   o  An arbitrary 6LN is expected to support IPv6-in-IPv6 encapsulation
      when it is the destination of the outer header.  If the 6LN is a
      host, it is expected to drop the inner packet if it is not the
      destination of the inner header.

   o  An arbitrary 6LN 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 particular that an RPI with an Option Type of 0x23
      [I-D.ietf-roll-useofrplinfo] is ignored when not understood.

   o  An arbitrary 6LN is expected to process an unknown Routing Header
      Type as prescribed by section 4.4 of [RFC8200].  This means in
      particular that Routing Header with a Routing Type of 3 [RFC6553]
      is ignored when the Segments Left is zero, and dropped otherwise.

   o  When IP-in-IP is used and the outer headers terminate at the 6LR
      that generated the DAO, then the 6LR decapsulates the packet to
      the 6LN. 6LN ( see Appendix A for the format in Storing Mode).  In that
      case the 6LN gets a packet that is free of RPL artifacts.  IP-in-IP  IP-in-
      IP to the 6LR MUST be used if the 6LN cannot handle or ignore the
      RPL artifacts or the way they are compressed [RFC8138].  It SHOULD
      be used it there is a particular bandwidth or power constraint at
      the 6LN that justifies saving the encapsulation at the last hop.

   o  In order to save the IP-in-IP encapsulation and to support Storing
      Mode of operation, it is preferred that the 6LN can ignore an RPI
      and consume a routing header in both the native and compressed
      forms.  In order to enable IP-in-IP to a 6LN in Non-Storing Mode,
      it is also of interest that the 6LN supports decapsulating IP-in-
      IP in both forms.  But since the preferred behaviour when using
      IP-in-IP is that the outter headers terminate at the 6LR,
      supporting this capability is secondary.

7.  Protocol Operations for Unicast Addresses

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 in Non-Storing Mode, the Extended Duplicate
   Address message takes place as prescribed by [RFC8505].  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
   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.
   Note that in Storing Mode the DAO ACK is generated from the parent
   that does not necessary wait for the grand parent to acknowledge, so
   the DAO-ACK is no guarantee that the keep-alive EDAR succeeded.  On
   the other hand, the flows can be nested in Non-Storing Mode, and it
   is possible to carry information such as an updated lifetime from the
   6LBR all the way to the 6LN.

        6LN              6LR             Root             6LBR
         |                |               |                 |
         |   NS(EARO)     |               |                 |
         |--------------->|                                 |
         |                |           Extended DAR          |
         |                |-------------------------------->|
         |                |                                 |
         |                |           Extended DAC          |
         |                |<--------------------------------|
         |                |      DAO      |                 |
         |                |-------------->|                 |
         |                |               | keep-alive EDAR |
         |                |               |---------------->|
         |                |               |      EDAC       |
         |                |               |<----------------|
         |                |    DAO ACK    |                 |
         |                |<--------------|                 |
         |   NA(EARO)     |                                 |
         |<---------------|               |                 |
         |                |               |                 |

                     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 3, 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.

   6LN             6LR             Root             6LBR           6BBR
    |               |               |                 |              |
    |   NS(EARO)    |               |                 |              |
    |-------------->|               |                 |              |
    |   NA(EARO)    |               |                 |              |
    |<--------------|               |                 |              |
    |               |               |                 |              |
    |               |      DAO      |                 |              |
    |               |-------------->|                 |              |
    |               |               |                 |              |
    |               |               | keep-alive EDAR |              |
    |               |               |---------------->|              |
    |               |               |   EDAC(ROVR)    |              |
    |               |               |<----------------|              |
    |               |               |                 |              |
    |               |               |          proxy NS(EARO)        |
    |               |               |------------------------------->|
    |               |               |          proxy NA(EARO)        |
    |               |               |<-------------------------------|
    |               |               |                 |              |
    |               |    DAO ACK    |                 |              |
    |               |<--------------|                 |              |
    |               |               |                 |              |

                     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 [RFC8505].

   o  Upon each consecutive registration, the 6LN MUST increase the TID

   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
      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.

   o  the 6LN is not expected to be aware of RPL so it is not expected
      to produce RPL artifacts in the data packets.

7.3.  6LR Operation

   Also as prescribed by [RFC8505], 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
   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.  This is
      how the Root knows in Non-Storing Mode to use IP-in-IP and
      terminate the outters headers at the 6LR that generated the DAO.

   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.

   The keep-alive EDAR and the NS(EARO) messages MUST be constructed as

   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 [RFC8505].

   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.

   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.  Protocol Operations for Multicast Addresses

   Section 12 of [RFC6550] details the RPL support for multicast flows.
   This support is not source-specific and only operates as an extension
   to the Storing Mode of Operation for unicast packets.  Note that it
   is the RPL model that the multicast packet is passed as a Layer-2
   unicast to each if the interested children.  This remains true when
   forwarding between the 6LR and the listener 6LN.

   "Multicast Listener Discovery (MLD) for IPv6" [RFC2710] and its
   updated version "Multicast Listener Discovery Version 2 (MLDv2) for
   IPv6" [RFC3810] provide an interface for a listener to register to
   multicast flows.  MLDv2 is backwards compatible with MLD, and adds in
   particular the capability to filter the sources via black lists and
   white lists.  In the MLD model, the router is a "querier" and the
   host is a multicast listener that registers to the querier to obtain
   copies of the particular flows it is interested in.

   On the first registration, as illustrated in Figure 4, the 6LN, as an
   MLD listener, sends an unsolicited Report to the 6LR in order to
   start receiving the flow immediately.  Since multicast Layer-2
   messages are avoided, it is important that the asynchronous messages
   for unsolicited Report and Done are sent reliably, for instance using
   an Layer-2 acknoledgement, or attempted multiple times.

   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
   of the Query Interval, yet larger to account for variable propagation

   The Root proxies the MLD echange as listener with the 6BBR acting as
   the querier, so as to get packets from a source external to the RPL
   domain.  Upon a DAO with a multicast target, the RPL Root checks if
   it is already registered as a listener for that address, and if not,
   it performs its own unsolicited Report for the multicast target.

        6LN                  6LR             Root                6LBR
         |                    |               |                    |
         | unsolicited Report |               |                    |
         |------------------->|               |                    |
         |   <L2 ack>         |               |                    |
         |                    | DAO           |                    |
         |                    |-------------->|                    |
         |                    |    DAO ACK    |                    |
         |                    |<--------------|                    |
         |                    |               | <if not listening> |
         |                    |               | unsolicited Report |
         |                    |               |------------------->|
         |                    |               |                    |
         |                    |               |                    |

                Figure 4: First Multicast Registration Flow

   A re-registration is pulled by 6LR acting as querier.  Note that the
   message may sent unicast to all the known 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 is mapped into a DAO, as
   illustrated in Figure 5,

        6LN                  6LR             Root                6LBR
         |                    |               |                    |
         |       Query        |               |                    |
         |<-------------------|               |                    |
         |       Report       |               |                    |
         |------------------->|               |                    |
         |                    | DAO           |                    |
         |                    |-------------->|                    |
         |                    |    DAO ACK    |                    |
         |                    |<--------------|                    |
         |                    |               |                    |
         |                    |               |       Query        |
         |                    |               |<-------------------|
         |                    |               |       Report       |
         |                    |               |------------------->|
         |                    |               |                    |
         |                    |               |                    |

                     Figure 5: 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.

9.  Implementation Status

10.  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 [RFC8505].

   The keep-alive EDAR message does not carry a valid Registration
   Unique ID [RFC8505] 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.

11.  IANA Considerations

   This specification has no requirement on IANA.

12.  Acknowledgments

   The author wishes to thank Michael Richardson and Georgios
   Papadopoulos for their early reviews of and contributions to this

13.  References

13.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              DOI 10.17487/RFC2710, October 1999,

   [RFC3810]  Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
              Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
              DOI 10.17487/RFC3810, June 2004,

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

   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,

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

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

   [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
              Power and Lossy Networks (RPL) Option for Carrying RPL
              Information in Data-Plane Datagrams", RFC 6553,
              DOI 10.17487/RFC6553, March 2012,

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

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

   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
              "IPv6 over Low-Power Wireless Personal Area Network
              (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
              April 2017, <>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <>.

   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,

   [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
              Perkins, "Registration Extensions for IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Neighbor
              Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,

13.2.  Informative References

              Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient
              Route Invalidation", draft-ietf-roll-efficient-npdao-13 draft-ietf-roll-efficient-npdao-14
              (work in progress), June July 2019.

              Robles, I., Richardson, M., and P. Thubert, "Using RPL
              Option Type, Routing Header for Source Routes and IPv6-in-
              IPv6 encapsulation in the RPL Data Plane", draft-ietf-
              roll-useofrplinfo-30 (work in progress), June 2019.

   [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, <>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,

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

   [RFC7102]  Vasseur, JP., "Terms Used in Routing for Low-Power and
              Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
              2014, <>.

   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
              Constrained-Node Networks", RFC 7228,
              DOI 10.17487/RFC7228, May 2014,

   [RFC8025]  Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power
              Wireless Personal Area Network (6LoWPAN) Paging Dispatch",
              RFC 8025, DOI 10.17487/RFC8025, November 2016,

Appendix A.  Example Compression

   Figure 6 illustrates the case in Storing mode where the packet is
   received from the Internet, then the root encapsulates the packet to
   insert the RPI and deliver to the 6LR that is the parent and last hop
   to the final destination, which is not known to support [RFC8138].
   The difference with the format presented in Figure 19 of [RFC8138] is
   the addition of a SRH-6LoRH before the RPI-6LoRH to transpotr the
   destination address of the outer IPv6 header.

 +-+ ... -+-+ ... +-+- ... -+-+- ... +-+-+-+ ... +-+-+ ... -+ ... +-...
 |11110001|SRH-6LoRH| RPI-  | IP-in-IP | NH=1      |11110CPP| UDP | UDP
 |Page 1  |Type1 S=0| 6LoRH |  6LoRH   |LOWPAN_IPHC| UDP    | hdr |Payld
 +-+ ... -+-+ ... +-+- ... -+-+-- ... -+-+-+ ... +-+-+ ... -+ ... +-...
           <-4bytes->                    <-        RFC 6282      ->
                                                 No RPL artifact

             Figure 6: Encapsulation to Parent in Storing Mode

   In Figure 6, the source of the IP-in-IP encapsulation is the Root, so
   it is elided in the IP-in-IP 6LoRH.  The destination is the parent
   6LR of the destination of the inner packet so it cannot be elided.
   In Storing Mode, it is placed as the single entry in an SRH-6LoRH as
   the first 6LoRH.  Since there is a single entry so the SRH-6LoRH Size
   is 0.  In this particular example, the 6LR address can be compressed
   to 2 bytes so a Type of 1 is used.  It results that the total length
   of the SRH-6LoRH is 4 bytes.

   In Non-Storing Mode, the encapsulation from the root would be similar
   to that represented in Figure 6 with possibly more hops in the SRH-
   6LoRH and possibly multiple SRH-6LoRHs if the various addresses in
   the routing header are not compressed to the same format.  Note that
   on the last hop to the parent 6LR, the RH3 is consumed and removed
   from the compressed form, so the use of Non-Storing Mode vs.  Storing
   Mode is indistinguishable from the packet format.

   Follows the RPI-6LoRH and then the IP-in-IP 6LoRH.  When the IP-in-IP
   6LoRH is removed, all the router headers that precede it are also

   The Paging Dispatch [RFC8025] may also be removed if there was no
   previous Page change to a Page other than 0 or 1, since the
   LOWPAN_IPHC is encoded in the same fashion in the default Page 0 and
   in Page 1.  The resulting packet to the destination is the inner
   packet compressed with [RFC6282].

Author's Address

   Pascal Thubert (editor)
   Cisco Systems, Inc
   Building D
   45 Allee des Ormes - BP1200
   MOUGINS - Sophia Antipolis  06254

   Phone: +33 497 23 26 34