Tech-invite3GPPspecsGlossariesIETFRFCsGroupsSIPABNFs   Ti+   SearchTech-invite World Map Symbol

RFC 8505

 Errata 
Proposed STD
Pages: 47
Top     in Index     Prev     Next
in Group Index     Prev in Group     No Next: Highest Number in Group     Group: 6LO

Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery

Part 1 of 3, p. 1 to 14
None       Next Section

Updates:    6775


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                   P. Thubert, Ed.
Request for Comments: 8505                                         Cisco
Updates: 6775                                                E. Nordmark
Category: Standards Track                                         Zededa
ISSN: 2070-1721                                           S. Chakrabarti
                                                                 Verizon
                                                              C. Perkins
                                                               Futurewei
                                                           November 2018


                 Registration Extensions for IPv6 over
 Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery

Abstract

   This specification updates RFC 6775 -- the Low-Power Wireless
   Personal Area Network (6LoWPAN) Neighbor Discovery specification --
   to clarify the role of the protocol as a registration technique and
   simplify the registration operation in 6LoWPAN routers, as well as to
   provide enhancements to the registration capabilities and mobility
   detection for different network topologies, including the Routing
   Registrars performing routing for host routes and/or proxy Neighbor
   Discovery in a low-power network.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8505.

Top      ToC       Page 2 
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.

Table of Contents

   1. Introduction ....................................................3
   2. Terminology .....................................................4
      2.1. Requirements Language ......................................4
      2.2. Related Documents ..........................................4
      2.3. Abbreviations ..............................................4
      2.4. New Terms ..................................................6
   3. Applicability of Address Registration Options ...................7
   4. Extended Neighbor Discovery Options and Messages ................8
      4.1. Extended Address Registration Option (EARO) ................8
      4.2. Extended Duplicate Address Message Formats ................12
      4.3. Extensions to the Capability Indication Option ............13
   5. Updating RFC 6775 ..............................................14
      5.1. Extending the Address Registration Option .................16
      5.2. Transaction ID ............................................17
           5.2.1. Comparing TID Values ...............................17
      5.3. Registration Ownership Verifier (ROVR) ....................19
      5.4. Extended Duplicate Address Messages .......................20
      5.5. Registering the Target Address ............................20
      5.6. Link-Local Addresses and Registration .....................21
      5.7. Maintaining the Registration States .......................22
   6. Backward Compatibility .........................................24
      6.1. Signaling EARO Support ....................................25
      6.2. RFC 6775-Only 6LN .........................................25
      6.3. RFC 6775-Only 6LR .........................................25
      6.4. RFC 6775-Only 6LBR ........................................26
   7. Security Considerations ........................................26
   8. Privacy Considerations .........................................28

Top      ToC       Page 3 
   9. IANA Considerations ............................................29
      9.1. Address Registration Option Flags .........................29
      9.2. Address Registration Option I-Field .......................29
      9.3. ICMP Codes ................................................30
      9.4. New ARO Status Values .....................................31
      9.5. New 6LoWPAN Capability Bits ...............................32
   10. References ....................................................32
      10.1. Normative References .....................................32
      10.2. Informative References ...................................34
   Appendix A. Applicability and Fulfilled Requirements
               (Not Normative) .......................................38
   Appendix B. Requirements (Not Normative) ..........................39
     B.1. Requirements Related to Mobility ...........................39
     B.2. Requirements Related to Routing Protocols ..................40
     B.3. Requirements Related to Various Low-Power Link Types .......41
     B.4. Requirements Related to Proxy Operations ...................42
     B.5. Requirements Related to Security ...........................42
     B.6. Requirements Related to Scalability ........................44
     B.7. Requirements Related to Operations and Management ..........44
     B.8. Matching Requirements with Specifications ..................45
   Acknowledgments ...................................................47
   Authors' Addresses ................................................47

1.  Introduction

   IPv6 Low-Power and Lossy Networks (LLNs) support star and mesh
   topologies.  For such networks, "Neighbor Discovery Optimization for
   IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)"
   [RFC6775] (also referred to as "6LoWPAN Neighbor Discovery (ND)")
   defines a registration mechanism and a central IPv6 ND Registrar to
   ensure unique addresses.  The 6LoWPAN ND mechanism reduces the
   dependency of the IPv6 ND protocol [RFC4861] [RFC4862] on
   network-layer multicast and link-layer broadcast operations.

   This specification updates 6LoWPAN ND [RFC6775] to simplify and
   generalize registration in 6LoWPAN Routers (6LRs).  In particular,
   this specification modifies and extends the behavior and protocol
   elements of 6LoWPAN ND to enable the following actions:

   o  Determining the most recent location in the case of node mobility

   o  Simplifying the registration flow for Link-Local Addresses

   o  Support for a routing-unaware leaf node in a route-over network

   o  Proxy registration in a route-over network

Top      ToC       Page 4 
   o  Enabling verification for the registration, using the Registration
      Ownership Verifier (ROVR) (Section 5.3)

   o  Registration to an IPv6 ND proxy (e.g., a Routing Registrar)

   o  Better support for privacy and temporary addresses

   These features satisfy the requirements listed in Appendix B.

2.  Terminology

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.2.  Related Documents

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

   o  "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861]

   o  "IPv6 Stateless Address Autoconfiguration" [RFC4862]

   o  "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
      Overview, Assumptions, Problem Statement, and Goals" [RFC4919]

   o  "Problem Statement and Requirements for IPv6 over Low-Power
      Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606]

   o  "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
      Personal Area Networks (6LoWPANs)" [RFC6775]

2.3.  Abbreviations

   This document uses the following abbreviations:

   6BBR: 6LoWPAN Backbone Router

   6CIO: Capability Indication Option

   6LBR: 6LoWPAN Border Router

   6LN:  6LoWPAN Node

Top      ToC       Page 5 
   6LoWPAN:  IPv6 over Low-Power Wireless Personal Area Network

   6LR:  6LoWPAN Router

   ARO:  Address Registration Option

   DAC:  Duplicate Address Confirmation

   DAD:  Duplicate Address Detection

   DAR:  Duplicate Address Request

   DODAG:  Destination-Oriented Directed Acyclic Graph

   EARO: Extended Address Registration Option

   EDA:  Extended Duplicate Address

   EDAC: Extended Duplicate Address Confirmation

   EDAR: Extended Duplicate Address Request

   LLN:  Low-Power and Lossy Network

   NA:   Neighbor Advertisement

   NCE:  Neighbor Cache Entry

   ND:   Neighbor Discovery

   NS:   Neighbor Solicitation

   RA:   Router Advertisement

   ROVR: Registration Ownership Verifier (pronounced "rover")

   RPL:  IPv6 Routing Protocol for LLNs (pronounced "ripple") [RFC6550]

   RS:   Router Solicitation

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

Top      ToC       Page 6 
2.4.  New Terms

   Backbone Link:  An IPv6 transit link that interconnects two or more
         Backbone Routers.

   Binding:  The association between an IP address, a Media Access
         Control (MAC) address, and other information about the node
         that owns the IP address.

   Registration:  The process by which a 6LN registers an IPv6 Address
         with a 6LR in order to establish connectivity to the LLN.

   Registered Node:  The 6LN for which the registration is performed,
         according to the fields in the EARO.

   Registering Node:  The node that performs the registration.  Either
         the Registered Node or a proxy.

   IPv6 ND Registrar:  A node that can process a registration in either
         NS(EARO) or EDAR messages and consequently respond with an NA
         or EDAC message containing the EARO and appropriate status for
         the registration.

   Registered Address:  An address registered for the Registered Node.

   RFC 6775-only:  An implementation, a type of node, or a message that
         behaves only as specified by [RFC6775], as opposed to the
         behavior specified in this document.

   Route-over network:  A network for which connectivity is provided at
         the IP layer.

   Routing Registrar:  An IPv6 ND Registrar that also provides
         reachability services for the Registered Address, including DAD
         and proxy NA.

   Backbone Router (6BBR):  A Routing Registrar that proxies the 6LoWPAN
         ND operations specified in this document to ensure that
         multiple LLNs federated by a Backbone Link operate as a single
         IPv6 subnetwork.

   updated:  A 6LN, 6LR, or 6LBR that supports this specification, in
         contrast to an RFC 6775-only device.

Top      ToC       Page 7 
3.  Applicability of Address Registration Options

   The ARO as described in [RFC6775] facilitates DAD for hosts and
   populates NCEs [RFC4861] in the routers.  This reduces the reliance
   on multicast operations, which are often as intrusive as broadcast,
   in IPv6 ND operations (see [Multicast-over-IEEE802-Wireless]).

   This document specifies new status codes for registrations rejected
   by a 6LR or 6LBR for reasons other than address duplication.
   Examples include:

   o  the router running out of space.

   o  a registration bearing a stale sequence number.  This could happen
      if the host moves after the registration was placed.

   o  a host misbehaving and attempting to register an invalid address,
      such as the unspecified address as defined in [RFC4291].

   o  a host using an address that is not topologically correct on
      that link.

   In such cases, the host will receive an error that will help diagnose
   the issue; the host may retry -- possibly with a different address or
   possibly registering to a different router -- depending on the
   returned error.  The ability to return errors to address
   registrations is not intended to be used to restrict the ability of
   hosts to form and use multiple addresses.  Each host may form and
   register a number of addresses for enhanced privacy, using mechanisms
   such as those described in [RFC4941] ("Privacy Extensions for
   Stateless Address Autoconfiguration in IPv6"), e.g., Stateless
   Address Autoconfiguration (SLAAC), and SHOULD conform to [RFC7934]
   ("Host Address Availability Recommendations").

   As indicated in IPv6 ND [RFC4861], a router needs enough storage to
   hold NCEs for all directly connected addresses to which it is
   currently forwarding packets (unused entries may be flushed).  In
   contrast, a router serving the address-registration mechanism needs
   enough storage to hold NCEs for all the addresses that may be
   registered to it, regardless of whether or not they are actively
   communicating.  The number of registrations supported by a 6LR or
   6LBR MUST be clearly documented by the vendor, and the dynamic use of
   associated resources SHOULD be made available to the network
   operator, e.g., to a management console.  Network administrators need
   to ensure that 6LRs/6LBRs in their network support the number and
   types of devices that can register to them, based on the number of
   IPv6 Addresses that those devices require, as well as their address
   renewal rate and behavior.

Top      ToC       Page 8 
4.  Extended Neighbor Discovery Options and Messages

   This specification does not introduce any new options; it modifies
   existing options and updates the associated behaviors.

4.1.  Extended Address Registration Option (EARO)

   The ARO is defined in Section 4.1 of [RFC6775].

   This specification introduces the EARO; the EARO is based on the ARO
   for use in NS and NA messages.  The EARO includes a sequence counter
   called the Transaction ID (TID), which is used to determine the
   latest location of a registering mobile device.  A new T flag
   indicates that the presence of the TID field is populated and that
   the option is an EARO.  A 6LN requests routing or proxy services from
   a 6LR using a new R flag in the EARO.

   The EUI-64 field is redefined and renamed "ROVR field" in order to
   carry different types of information, e.g., cryptographic information
   of variable size (see Section 5.3).  A larger ROVR size MAY be used
   if and only if backward compatibility is not an issue in the
   particular LLN.  The length of the ROVR field, expressed in units of
   8 bytes, is the Length value of the option minus 1.  A larger ROVR
   size MAY be used if and only if backward compatibility is not an
   issue in the particular LLN.

   Section 5.1 discusses those changes in depth.

Top      ToC       Page 9 
   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 (ROVR)           ...
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 1: EARO Format

   Option Fields:

   Type:       33

   Length:     8-bit unsigned integer.  The length of the option in
               units of 8 bytes.

   Status:     8-bit unsigned integer.  Indicates the status of a
               registration in the NA response.  MUST be set to 0 in NS
               messages.  See Table 1 below.

   Opaque:     An octet opaque to ND.  The 6LN MAY pass it transparently
               to another process.  It MUST be set to 0 when not used.

   Rsvd (Reserved):
               This field is unused.  It MUST be initialized to 0 by the
               sender and MUST be ignored by the receiver.

   I:          2-bit integer.  A value of 0 indicates that the Opaque
               field carries an abstract index that is used to decide in
               which routing topology the address is expected to be
               injected.  In that case, the Opaque field is passed to a
               routing process with the indication that it carries
               topology information, and the value of 0 indicates
               default.  All other values of "I" are reserved and
               MUST NOT be used.

   R:          The Registering Node sets the R flag to request
               reachability services for the Registered Address from a
               Routing Registrar.

   T:          1-bit flag.  Set if the next octet is used as a TID.

Top      ToC       Page 10 
   TID:        1-byte unsigned integer.  A Transaction ID that is
               maintained by the node and incremented with each
               transaction of one or more registrations performed at the
               same time to one or more 6LRs.  This field MUST be
               ignored if the T flag is not set.

   Registration Lifetime:
               16-bit integer, expressed in minutes.  A value of 0
               indicates that the registration has ended and that the
               associated state MUST be removed.

   Registration Ownership Verifier (ROVR):
               Enables the correlation between multiple attempts to
               register the same IPv6 Address.  The ROVR size MUST be
               64 bits when backward compatibility is needed; otherwise,
               the size MAY be 128, 192, or 256 bits.

Top      ToC       Page 11 
   +-------+-----------------------------------------------------------+
   | Value | Description                                               |
   +-------+-----------------------------------------------------------+
   |  0-2  | As defined in [RFC6775].  Note: A Status value of 1       |
   |       | ("Duplicate Address") applies to the Registered Address.  |
   |       | If the Source Address conflicts with an existing          |
   |       | registration, "Duplicate Source Address" MUST be used.    |
   |       |                                                           |
   |   3   | Moved: The registration failed because it is not the most |
   |       | recent.  This Status indicates that the registration is   |
   |       | rejected because another more recent registration was     |
   |       | done, as indicated by the same ROVR and a more recent     |
   |       | TID.  One possible cause is a stale registration that has |
   |       | progressed slowly in the network and was passed by a more |
   |       | recent one.  It could also indicate a ROVR collision.     |
   |       |                                                           |
   |   4   | Removed: The binding state was removed.  This Status MAY  |
   |       | be placed in an NA(EARO) message that is sent as the      |
   |       | rejection of a proxy registration to an IPv6 ND           |
   |       | Registrar, or in an asynchronous NA(EARO), at any time.   |
   |       |                                                           |
   |   5   | Validation Requested: The Registering Node is challenged  |
   |       | for owning the Registered Address or for being an         |
   |       | acceptable proxy for the registration.  An IPv6 ND        |
   |       | Registrar MAY place this Status in asynchronous DAC or NA |
   |       | messages.                                                 |
   |       |                                                           |
   |   6   | Duplicate Source Address: The address used as the source  |
   |       | of the NS(EARO) conflicts with an existing registration.  |
   |       |                                                           |
   |   7   | Invalid Source Address: The address used as the source of |
   |       | the NS(EARO) is not a Link-Local Address.                 |
   |       |                                                           |
   |   8   | Registered Address Topologically Incorrect: The address   |
   |       | being registered is not usable on this link.              |
   |       |                                                           |
   |   9   | 6LBR Registry Saturated: A new registration cannot be     |
   |       | accepted because the 6LBR Registry is saturated.  Note:   |
   |       | This code is used by 6LBRs instead of Status 2 when       |
   |       | responding to a Duplicate Address message exchange and is |
   |       | passed on to the Registering Node by the 6LR.             |
   |       |                                                           |
   |   10  | Validation Failed: The proof of ownership of the          |
   |       | Registered Address is not correct.                        |
   +-------+-----------------------------------------------------------+

                        Table 1: EARO Status Codes

Top      ToC       Page 12 
4.2.  Extended Duplicate Address Message Formats

   The DAR and DAC messages share a common base format as defined in
   Section 4.4 of [RFC6775].  Those messages enable information from the
   ARO to be transported over multiple hops.  The DAR and DAC are
   extended as shown in Figure 2:

      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      |CodePfx|CodeSfx|          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Status     |     TID       |     Registration Lifetime     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
    ...            Registration Ownership Verifier (ROVR)           ...
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     +                                                               +
     |                                                               |
     +                       Registered Address                      +
     |                                                               |
     +                                                               +
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 2: Extended Duplicate Address Message Format

   Modified Message Fields:

   Code:       The ICMP Code [RFC4443] for Duplicate Address messages is
               split into two 4-bit fields: the Code Prefix and the Code
               Suffix.  The Code Prefix MUST be set to 0 by the sender
               and MUST be ignored by the receiver.  A non-null value of
               the Code Suffix indicates support for this specification.
               It MUST be set to 1 when operating in a backward-
               compatible mode, indicating a ROVR size of 64 bits.  It
               MAY be 2, 3, or 4, denoting a ROVR size of 128, 192, or
               256 bits, respectively.

   TID:        1-byte integer.  Same definition and processing as the
               TID in the EARO as defined in Section 4.1.  This field
               MUST be ignored if the ICMP Code is null.

Top      ToC       Page 13 
   Registration Ownership Verifier (ROVR):
               The size of the ROVR is known from the ICMP Code Suffix.
               This field has the same definition and processing as the
               ROVR in the EARO as defined in Section 4.1.

4.3.  Extensions to the Capability Indication Option

   This specification defines five new capability bits for use in the
   6CIO as defined by [RFC7400] ("6LoWPAN-GHC: Generic Header
   Compression for IPv6 over Low-Power Wireless Personal Area Networks
   (6LoWPANs)"), for use in IPv6 ND messages.  (The G flag is defined in
   Section 3.3 of [RFC7400].)

   The D flag indicates that the 6LBR supports EDAR and EDAC messages.
   A 6LR that learns the D flag from advertisements can then exchange
   EDAR and EDAC messages with the 6LBR, and it also sets the D flag as
   well as the L flag in the 6CIO in its own advertisements.  In this
   way, 6LNs will be able to prefer registration with a 6LR that can
   make use of new 6LBR features.

   The new L, B, and P flags indicate whether a router is capable of
   acting as a 6LR, 6LBR, or Routing Registrar (e.g., 6BBR) (or some
   combination thereof), respectively.  These flags are not mutually
   exclusive; an updated node can advertise multiple collocated
   functions.

   The E flag indicates that the EARO can be used in a registration.  A
   6LR that supports this specification MUST set the E flag.

      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: New Capability Bits in the 6CIO

Top      ToC       Page 14 
   Option Fields:

   Type:  36

   D: The 6LBR supports EDAR and EDAC messages.

   L: The node is a 6LR.

   B: The node is a 6LBR.

   P: The node is a Routing Registrar.

   E: The node is an IPv6 ND Registrar; i.e., it supports registrations
      based on the EARO.



(page 14 continued on part 2)

Next Section