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: 8928 8929 9010
Proposed Standard
→ Errata
Updates: 6775
Updated by: 8928 8929 9010
Part 1 of 3 – Pages 1 to 14
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 DiscoveryAbstract
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.
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
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 ................................................471. 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
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
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)
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.
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.
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.
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.
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.
+-------+-----------------------------------------------------------+ | 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
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.
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
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)