Tech-invite3GPPspaceIETF RFCsSIP
9190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 8505

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

Pages: 47
Proposed Standard
Errata
Updates:  6775
Updated by:  892889299010
Part 1 of 3 – Pages 1 to 14
None   None   Next

Top   ToC   RFC8505 - 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   RFC8505 - 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   RFC8505 - 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   RFC8505 - 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   RFC8505 - 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   RFC8505 - 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   RFC8505 - 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   RFC8505 - 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   RFC8505 - 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   RFC8505 - 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   RFC8505 - 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   RFC8505 - 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   RFC8505 - 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   RFC8505 - 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