Skip to main content

RPL-BIER
draft-thubert-roll-unaware-leaves-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
Author Pascal Thubert
Last updated 2018-02-13
Replaced by draft-ietf-roll-unaware-leaves, draft-ietf-roll-unaware-leaves, RFC 9010
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-thubert-roll-unaware-leaves-00
ROLL                                                     P. Thubert, Ed.
Internet-Draft                                                     Cisco
Updates: 6550, 6775 (if approved)                      February 13, 2018
Intended status: Standards Track
Expires: August 17, 2018

                                RPL-BIER
                  draft-thubert-roll-unaware-leaves-00

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 August 17, 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 August 17, 2018                [Page 1]
Internet-Draft                  RPL-BIER                   February 2018

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Updating RFC 6775 Update  . . . . . . . . . . . . . . . . . .   4
   5.  Updated EARO  . . . . . . . . . . . . . . . . . . . . . . . .   5
   6.  Protocol Operations . . . . . . . . . . . . . . . . . . . . .   5
     6.1.  6LN Operation . . . . . . . . . . . . . . . . . . . . . .   6
     6.2.  6LR Operation . . . . . . . . . . . . . . . . . . . . . .   6
     6.3.  RPL Root Operation  . . . . . . . . . . . . . . . . . . .   7
     6.4.  6LBR Operation  . . . . . . . . . . . . . . . . . . . . .   7
   7.  Implementation Status . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   8
     11.2.  Informative References . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

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.  RPL also
   leverages Routing Stretch to reduce further the amount of control
   traffic and routing state that is required to operate the 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.  Because it is designed to adapt to fuzzy connectivity with
   lazy control, RPL can only provide a best effort routability,
   connecting most of the LLN nodes, most of the time.  RPL provides

Thubert                  Expires August 17, 2018                [Page 2]
Internet-Draft                  RPL-BIER                   February 2018

   unicast and multicast routing services back to RPL-Aware nodes.  A
   RPL-Aware Node 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.

   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.

   RFC 6775 was further updated with [I-D.ietf-6lo-rfc6775-update] to
   enable mobility and proxy operations; this latter update includes
   changes that are required by this document.  The update defines an
   Extended Address Registration Option (EARO) to include a sequence
   counter called Transaction ID (TID), which maps to the Path Sequence
   Field found in Transit Options in a RPL DAO messages.

   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 6LoWPAN ND terms, this means that 6LN that
   may also be a 6LR and manage its own routing.  Alternatively, it may
   rely on its 6LR to perform routing on its behalf.  With this
   specification, a 6LN may declare itself as a router in the 6LoWPAN ND
   exchange in order to declare that it will manage it own routing.  By
   default, the 6LN is considered as a plain host, and the 6LR that
   accepts the registration will inject routing information on behalf of
   the 6LN in the RPL domain.

Thubert                  Expires August 17, 2018                [Page 3]
Internet-Draft                  RPL-BIER                   February 2018

2.  Terminology

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

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

   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.

3.  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 registration, this specification changes the
   behavior or the 6LR.  If a DAO is sent for the registered address,
   then the 6LR refrains from sending a DAR message.  Upon reception of
   the DAO message initiated at the 6LR, the DAR/DAC exchange happens
   between the RPL Root and the 6LBR, the Root acting as a proxy Root on
   behalf of the 6LR to maintain an existing state in the 6LBR.

4.  Updating RFC 6775 Update

   This document specifies a new flag in the EARO option, the 'R' flag,
   used by the registering node to indicate that the 6LN that performs
   the registration is a router and that it handles its reachability.
   Setting the 'R' flag effectively suppresses 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.

   This document also specifies a keep-alive DAR message that the RPL
   Root may use to maintain an existing state in the 6LBR upon receiving

Thubert                  Expires August 17, 2018                [Page 4]
Internet-Draft                  RPL-BIER                   February 2018

   DAO messages.  The DAR message may only act as a refresher and can
   only update the Lifetime and the TID of the state in the 6LBR.

5.  Updated EARO

   This document introduces a new 'R' flag in the EARO option, as
   follows:

       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     |    Reserved   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         |R|C|T|     TID       |     Registration Lifetime     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +         Owner Unique ID (EUI-64 or Crypto-ID)                 +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 1: Enhanced Address Registration Option

   Type:           33
   Length:         8-bit unsigned integer.  The length of the option
                   (including the type and length fields) in units of 8
                   bytes.
   Status:         Defined in [RFC6775] and updated in
                   [I-D.ietf-6lo-ap-nd].
   Reserved:       This field is unused.  It MUST be initialized to zero
                   by the sender and MUST be ignored by the receiver.
   R:              When set, this flag indicates that the registering
                   node is a router that handles it reachability.  If
                   the 'R' flag is not set, the registering node expects
                   that the 6LR ensures reachability for the registered
                   address.  In the context of this specification, this
                   means that the 6LR will advertise the registered
                   address in the RPL domain.
   C:              --> Defined in [I-D.ietf-6lo-ap-nd].
   T and TID:      Defined in [I-D.ietf-6lo-rfc6775-update].
   Owner Unique ID:  Defined in [RFC6775] and updated in
                   [I-D.ietf-6lo-ap-nd].

6.  Protocol Operations

Thubert                  Expires August 17, 2018                [Page 5]
Internet-Draft                  RPL-BIER                   February 2018

6.1.  6LN Operation

   This specification does not alter the operation of a 6LowpAN ND-
   compliant 6LN, which is expected to operate as follows:

      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].
      Once it ha 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].
      Upon each consecutive registration, the 6LN increases the TID
      field.
      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.
      The 6LN MAY use any of the 6LRs to which it register to forward
      its packets.

6.2.  6LR Operation

   Also as prescribed by [I-D.ietf-6lo-rfc6775-update], the 6LR
   generates a DAR/DAC message upon reception of a valid NS(EARO)
   message for a new registration.  If the exchange succeeds, then the
   6LR installs a Neighbor Cache Entry (NCE).

   At this stage, and upon each NS(EARO) received afterwards that
   maintain the NCE in the 6LR; if the 'R' flag was set in a NS(EARO)
   message, the 6LR refrains from injecting the registered address into
   RPL; else the 6LR SHOULD redistribute the registered address into RPL
   by sending a DAO message on behalf of the 6LN.

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

Thubert                  Expires August 17, 2018                [Page 6]
Internet-Draft                  RPL-BIER                   February 2018

   If a 6LR receives a valid NS(EARO) message with the 'R' flag set and
   the 6LR was redistributing the registered address due to previous
   NS(EARO) messages with the flag not set, then it MUST stop
   redistributing 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.

6.3.  RPL Root Operation

   Upon reception of a DAO message that creates or updates an existing
   RPL state, the Root notifies the 6LR using an internal API if they
   are collocated, or a proxied DAR/DAC exchange on behalf of the
   registering node if they are separated.

   In the latter case, the DAR message MUST be constructed as follows:

   o  The registered address from in the Target Option is placed in the
      Registered Address field
   o  the Owner Unique ID field is set to all ones to indicate that it
      is not provided
   o  the Registration Lifetime in the DAR message is adapted from the
      Path Lifetime in the TIO.
   o  the TID value is set to the Path Sequence in the TIO.

   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.

6.4.  6LBR Operation

   Upon reception of a DAR message with the Owner Unique ID field is set
   to all ones, the 6LBR checks whether and entry exists for the and
   computes whether the TID in the DAR message is fresher than that in
   the entry as prescribed in [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 August 17, 2018                [Page 7]
Internet-Draft                  RPL-BIER                   February 2018

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

7.  Implementation Status

   TBD

8.  Security Considerations

   TBD

9.  IANA Considerations

   This specification has no requirement on IANA.

10.  Acknowledgments

   TBD

11.  References

11.1.  Normative References

   [I-D.ietf-6lo-rfc6775-update]
              Thubert, P., Nordmark, E., Chakrabarti, S., and C.
              Perkins, "An Update to 6LoWPAN ND", draft-ietf-6lo-
              rfc6775-update-11 (work in progress), December 2017.

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

Thubert                  Expires August 17, 2018                [Page 8]
Internet-Draft                  RPL-BIER                   February 2018

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

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

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

11.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-05 (work in progress),
              January 2018.

   [I-D.ietf-roll-efficient-npdao]
              Jadhav, R., Sahoo, R., and Z. Cao, "No-Path DAO
              modifications", draft-ietf-roll-efficient-npdao-01 (work
              in progress), October 2017.

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

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

Thubert                  Expires August 17, 2018                [Page 9]
Internet-Draft                  RPL-BIER                   February 2018

   [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

   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 August 17, 2018               [Page 10]