RFC 8505
Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery 🎀
(part 1 of 10 ✨)
RFC 8505 💖 is from the IETF, and it's part of the Internet Standards Track 🔥. It was published in November 2018, and it was written by P. Thubert, Ed. (Cisco), E. Nordmark (Zededa), S. Chakrabarti (Verizon), and C. Perkins (Futurewei). It updates RFC 6775 🦋, so it's basically a glow-up of the 6LoWPAN Neighbor Discovery spec. Its ISSN is 2070-1721 🌸.
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 2018Abstract ✨
Okay so this spec updates RFC 6775, which is the 6LoWPAN Neighbor Discovery spec 💅. The goal is to make it clear that 6LoWPAN ND is a registration technique, and to make the registration process simpler for 6LoWPAN routers 🧚. It also adds upgrades to how registration works and how mobility gets detected across different network topologies. That includes Routing Registrars doing routing for host routes and/or proxy Neighbor Discovery in a low-power network. Main character energy 👑.
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 went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841 📚.
Info about the current status of this document, any errata, and how to send feedback can be found 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) as they're in effect on the date this document was published. Please actually read these, because they explain your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they're 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 🦋
Okay, so IPv6 Low-Power and Lossy Networks (LLNs) support star and mesh topologies 🌸. For these networks, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775] (also called "6LoWPAN Neighbor Discovery (ND)") defines a registration mechanism and a central IPv6 ND Registrar to make sure addresses are unique 🔐. The 6LoWPAN ND mechanism also cuts down how much the IPv6 ND protocol [RFC4861] [RFC4862] depends on network-layer multicast and link-layer broadcast operations 📉. Less noise, more slay 💅.
This specification updates 6LoWPAN ND [RFC6775] to simplify and generalize registration in 6LoWPAN Routers (6LRs) ✨. Specifically, it changes and extends the behavior and protocol elements of 6LoWPAN ND so it can do the following:
- Figure out the most recent location when a node moves around 🏃♀️
- Simplify the registration flow for Link-Local Addresses 🌙
- Support a routing-unaware leaf node in a route-over network 🍃
- Do proxy registration in a route-over network 🧚
- Enable verification for the registration, using the Registration Ownership Verifier (ROVR) (Section 5.3) 🔑
- Register to an IPv6 ND proxy (for example, a Routing Registrar) 👑
- Better support privacy and temporary addresses 🙈
All of these features satisfy the requirements listed in Appendix B 💖.
2. Terminology 🌈
2.1. Requirements Language 💅
Here's the vibe check on keywords: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are interpreted as described in BCP 14 [RFC2119] [RFC8174] only when they show up in all capitals, exactly as shown here 🎀. Lowercase versions are just regular words, bestie 🫶.
2.2. Related Documents 📚
Okay, so you'll run into terms and concepts discussed in these documents:
- "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861] 🌸
- "IPv6 Stateless Address Autoconfiguration" [RFC4862] 🦋
- "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919] 🍓
- "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606] 🧚
- "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775] 👑
2.3. Abbreviations 🔤
This document uses these abbreviations (I've kept the list exactly as written so nothing gets lost 🫶):
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 🧚
Here are the new terms, explained in my own words so they stick 💖:
- Backbone Link: an IPv6 transit link that connects two or more Backbone Routers 🌉.
- Binding: the association between an IP address, a Media Access Control (MAC) address, and other info about the node that owns that IP address 🔗.
- Registration: the process where a 6LN registers an IPv6 Address with a 6LR so it can get connectivity to the LLN ✨.
- Registered Node: the 6LN the registration is done for, based on the fields in the EARO 🎀.
- Registering Node: the node that actually does the registration. It's either the Registered Node itself or a proxy 🫶.
- IPv6 ND Registrar: a node that can process a registration in either an NS(EARO) or an EDAR message, and then reply with an NA or EDAC message that has the EARO and the right 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 this document specifies 🙈.
- Route-over network: a network where 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, so multiple LLNs connected by a Backbone Link work as a single IPv6 subnetwork 🦋.
- updated: a 6LN, 6LR, or 6LBR that supports this specification, as opposed to an RFC 6775-only device 💜.
3. Applicability of Address Registration Options 🎀
okay so bestie, the ARO from [RFC6775] is what makes DAD work for hosts and fills up the NCEs [RFC4861] in the routers 💅 and that means less reliance on multicast operations, which are basically as intrusive as broadcast, in IPv6 ND operations (see [Multicast-over-IEEE802-Wireless]). it's giving efficiency ✨
this document specifies new status codes for registrations that get rejected by a 6LR or 6LBR for reasons other than address duplication 🙈 examples include:
- the router running out of space. 💀
- a registration bearing a stale sequence number. this could happen if the host moves after the registration was placed. 🦋
- a host misbehaving and attempting to register an invalid address, such as the unspecified address as defined in [RFC4291]. 😭
- a host using an address that is not topologically correct on that link. 🌸
in cases like these, the host gets an error that helps it diagnose the issue 🫶 the host MAY retry, and it's giving "try again smarter" energy: maybe with a different address, or maybe registering to a different router, depending on the returned error. the ability to return errors to address registrations is NOT meant to restrict hosts from forming and using multiple addresses, bestie 🌈 each host can form and register a bunch of addresses for enhanced privacy, using mechanisms like the ones in [RFC4941] ("Privacy Extensions for Stateless Address Autoconfiguration in IPv6"), e.g., Stateless Address Autoconfiguration (SLAAC), and it SHOULD conform to [RFC7934] ("Host Address Availability Recommendations") 💖
as [RFC4861] says, a router needs enough storage to hold NCEs for all directly connected addresses it's currently forwarding packets to (unused entries may be flushed) 🧚 but a router serving the address-registration mechanism needs enough storage for ALL the addresses that may be registered to it, whether or not they're actively communicating 👑 that's a big difference, iykyk 💅
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 admins need to make sure the 6LRs/6LBRs in their network can handle the number and types of devices registering to them, based on how many IPv6 Addresses those devices need, plus their address renewal rate and behavior ✨ no cap, that's a lot to track fr fr 😭
4. Extended Neighbor Discovery Options and Messages 🦋
this spec doesn't introduce any new options 💅 it modifies existing options and updates the associated behaviors. slay 🔥
4.1. Extended Address Registration Option (EARO) 🎀
the ARO is defined in Section 4.1 of [RFC6775] 🌸
this spec introduces the EARO, which 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 figure out the latest location of a registering mobile device 🦋 a new T flag says the TID field is populated and that the option is an EARO ✨ and 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" so it can carry different types of info, e.g., cryptographic info 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, in units of 8 bytes, is the Length value of the option minus 1. and again, a larger ROVR size MAY be used if and only if backward compatibility is not an issue in the particular LLN 🙈 (yes it's said twice, bestie, the original really wanted you to know 💀)
Section 5.1 digs into those changes in depth 🫶
here's the EARO format, 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 Formatoption fields, bestie 💜
- Type: 33 🌈
- Length: 8-bit unsigned integer. the length of the option in units of 8 bytes. 💖
- Status: 8-bit unsigned integer. it indicates the status of a registration in the NA response. it 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 means the Opaque field carries an abstract index used to decide which routing topology the address is expected to be injected into. in that case, the Opaque field is passed to a routing process with the indication that it carries topology info, and the value of 0 means 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 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 means the registration has ended and 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. 💅
the ROVR is basically the bouncer that matches up multiple attempts to register the same address 🙈 so yeah, it's kind of a big deal, bestie 💀
now the status codes, Table 1 🌈
+-------+-----------------------------------------------------------+
| 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 🍓
hmm, that's the whole vibe for part 2, bestie 🧚 keep reading when you're ready 💜
4.2. Extended Duplicate Address Message Formats ✨
okay bestie, so the DAR and DAC messages share a common base format, the one from Section 4.4 of [RFC6775] 🎀. Those messages are what let info from the ARO hop across multiple hops 🦋. So the DAR and DAC get extended like this:
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:36D: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.
5. Updating RFC 6775 🦋
The EARO (see Section 4.1) updates the ARO used within NS and NA messages between a 6LN and a 6LR. The update enables a registration to a Routing Registrar in order to obtain additional services, such as return routability to the Registered Address by such means as routing and/or proxy ND, as illustrated in Figure 4. 👑
Routing
6LN Registrar
| |
| NS(EARO) |
|--------------->|
| |
| | Inject/maintain
| | host route or
| | IPv6 ND proxy state
| | <----------------->
| NA(EARO) |
|<---------------|
| |Figure 4: (Re-)Registration Flow
Similarly, the EDAR and EDAC update the DAR and DAC messages so as to transport the new information between 6LRs and 6LBRs across an LLN mesh. The extensions to the ARO are the DAR and the DAC, as used in the Duplicate Address messages. They convey the additional information all the way to the 6LBR. ✨
In turn, the 6LBR may proxy the registration to obtain reachability services from a Routing Registrar such as a 6BBR, as illustrated in Figure 5. This specification avoids the Duplicate Address message flow for Link-Local Addresses in a route-over [RFC6606] topology (see Section 5.6). 🌈
Routing
6LN 6LR 6LBR Registrar
| | | |
|<Link-local>| <Routed> |<Link-local>|
| | | |
| NS(EARO) | | |
|----------->| | |
| | Extended DAR | |
| |------------->| |
| | | proxy |
| | | NS(EARO) |
| | |----------->|
| | | | Inject/maintain
| | | | host route or
| | | | IPv6 ND proxy state
| | | | <----------------->
| | | proxy |
| | | NA(EARO) |
| | Extended DAC |<-----------|
| |<-------------| |
| NA(EARO) | | |
|<-----------| | |
| | | |Figure 5: (Re-)Registration Flow
This specification allows multiple registrations, including registrations for privacy and temporary addresses, and provides a mechanism to help clean up stale registration state as soon as possible, e.g., after a movement (see Section 7). 🧚
Section 5 of [RFC6775] specifies how a 6LN bootstraps an interface and locates available 6LRs. A Registering Node SHOULD register to a 6LR that supports this specification if one is found, as discussed in Section 6.1, instead of registering to an RFC 6775-only 6LR; otherwise, the Registering Node operates in a backward-compatible fashion when attaching to an RFC 6775-only 6LR. 💅
5.1. Extending the Address Registration Option 💖
The EARO updates the ARO and is backward compatible with the ARO if and only if the Length value of the option is set to 2. The format of the EARO is presented in Section 4.1. More details on backward compatibility can be found in Section 6.
The NS message and the ARO are modified as follows:
- The Target Address field in the NS containing the EARO is now the field that indicates the address that is being registered, as opposed to the Source Address field in the NS as specified in [RFC6775] (see Section 5.5). This change enables a 6LBR to send a proxy registration for a 6LN's address to a Routing Registrar and in most cases also avoids the use of an address as the Source Address before it is registered.
- The EUI-64 field in the ARO is renamed "Registration Ownership Verifier (ROVR)" and is not required to be derived from a MAC address (see Section 5.3).
- The option's Length value MAY be different than 2 and take a value between 3 and 5, in which case the EARO is not backward compatible with an ARO. The increase in size corresponds to a larger ROVR field, so the size of the ROVR is inferred from the option's Length value.
- A new Opaque field is introduced to carry opaque information in cases where the registration is relayed to another process, e.g., to be advertised by a routing protocol. A new "I" field provides a type for the opaque information and indicates the other process to which the 6LN passes the opaque value. A value of 0 for the "I" field indicates topological information to be passed to a routing process if the registration is redistributed. In that case, a value of 0 for the Opaque field (1) is backward compatible with the reserved fields that are overloaded and (2) indicates that the default topology is to be used.
- This document specifies a new flag in the EARO: the R flag. If the R flag is set, the Registering Node requests that the 6LR ensure reachability for the Registered Address, e.g., by means of routing or proxy ND. Conversely, when it is not set, the R flag indicates that the Registering Node is a router and that it will advertise reachability to the Registered Address via a routing protocol (such as RPL [RFC6550]).
- A node that supports this specification MUST provide a TID field in the EARO and set the T flag to indicate the presence of the TID (see Section 5.2).
- Finally, this specification introduces new status codes to help diagnose the cause of a registration failure (see Table 1).
When registering, a 6LN that acts only as a host MUST set the R flag to indicate that it is not a router and that it will not handle its own reachability. A 6LR that manages its reachability SHOULD NOT set the R flag; if it does, routes towards this router may be installed on its behalf and may interfere with those it advertises. 🎀
5.2. Transaction ID 🎀
Okay so the TID is basically a sequence number 💖 The 6LN bumps it up by one every time it re-registers to a 6LR. The network uses it to figure out which registration is the newest, which tells it where a moving 6LN is right now 🦋 When a Registered Node is registered with multiple 6LRs in parallel, the same TID MUST be used. That way the 6LBRs and/or Routing Registrars can tell that the registrations are identical and not mistake them for a move (see Section 5.7 and Appendix A) 🫶
5.2.1. Comparing TID Values ✨
This is fully compatible with the RPL Path Sequence counter from Section 7.2 of [RFC6550] ("RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks"). Same energy, bestie 💅
A TID counts as more recent than another one when its value is greater, based on the operations described in this section.
Here's the vibe. The TID range is split up in a "lollipop" fashion [Perlman83] 🍭 Values from 128 and up are used as a linear sequence, which is how the counter restarts and bootstraps itself. Values less than or equal to 127 form a circular sequence number space of size 128, as mentioned in [RFC1982]. There's some thinking about the mode of operation when you move from the linear part to the circular part. And when you're in the circular part, if sequence numbers are too far apart, they just aren't comparable, which I'll explain below 🌈
A comparison window, SEQUENCE_WINDOW = 16, is set based on a value of 2^N, where N is defined to be 4 in this specification.
For a given sequence counter:
- Before using it, the sequence counter SHOULD be initialized to an implementation-defined value of 128 or greater. A recommended value is 240 (
256 - SEQUENCE_WINDOW). 🌸 - When a sequence counter increment would push it past its maximum value, the sequence counter MUST wrap back to 0. When incrementing a sequence counter greater than or equal to 128, the maximum value is 255. When incrementing a sequence counter less than 128, the maximum value is 127. 🔁
- When comparing two sequence counters, the following rules MUST be applied:
- When a first sequence counter A is in the interval
[128-255]and a second sequence counter B is in the interval[0-127]:- If
(256 + B - A)is less than or equal toSEQUENCE_WINDOW, then B is greater than A, A is less than B, and the two are not equal. - If
(256 + B - A)is greater thanSEQUENCE_WINDOW, then A is greater than B, B is less than A, and the two are not equal.
- If
- When a first sequence counter A is in the interval
For example, if A is 240 and B is 5, then (256 + 5 - 240) is 21. 21 is greater than SEQUENCE_WINDOW (16), so 240 is greater than 5. 🙈 As another example, if A is 250 and B is 5, then (256 + 5 - 250) is 11. 11 is less than SEQUENCE_WINDOW (16), so 250 is less than 5. Plot twist, I know 💀
- In the case where both sequence counters to be compared are less than or equal to 127, and in the case where both sequence counters to be compared are greater than or equal to 128:
- If the absolute magnitude of difference between the two sequence counters is less than or equal to
SEQUENCE_WINDOW, then a comparison as described in [RFC1982] is used to determine the relationships "greater than", "less than", and "equal". - If the absolute magnitude of difference of the two sequence counters is greater than
SEQUENCE_WINDOW, then a desynchronization has occurred and the two sequence numbers are not comparable. 😭
- If the absolute magnitude of difference between the two sequence counters is less than or equal to
- If two sequence numbers are determined to be not comparable, i.e., the results of the comparison are not defined, then a node should give precedence to the sequence number that was most recently incremented. Failing this, the node should select the sequence number in order to minimize the resulting changes to its own state. 🧚
5.3. Registration Ownership Verifier (ROVR) 👑
The ROVR field replaces the EUI-64 field of the ARO defined in [RFC6775]. In the 6LR and the 6LBR, it's tied to the registration state. The ROVR can be a unique ID of the Registering Node, such as the EUI-64 address of an interface. It can also be a token made with cryptographic methods, which can be used in extra protocol exchanges to link a cryptographic identity (key) to this registration. That way only the owner can change it later, as long as they can prove they own the ROVR 🔐 The scope of a ROVR is the registration of one particular IPv6 Address, and it MUST NOT be used to correlate registrations of different addresses. No cross-referencing, periodt 🙅♀️
The ROVR can come in different types, and the type is signaled in the message that carries it. For instance, the type can be a cryptographic string, which can prove ownership of the registration as specified in [AP-ND] ("Address Protected Neighbor Discovery for Low-power and Lossy Networks"). To support the flows related to proving ownership, this specification introduces new status codes "Validation Requested" and "Validation Failed" in the EARO 🎀
Note regarding ROVR collisions: Different techniques for forming the ROVR operate in different namespaces. [RFC6775] specifies the use of EUI-64 addresses. [AP-ND] specifies the generation of cryptographic tokens. Collisions aren't expected in the EUI-64 namespace alone, but they may happen if [AP-ND] is implemented by at least one of the nodes. An implementation that understands the namespace MUST consider that ROVRs from different namespaces are different even if they have the same value. An RFC 6775-only 6LBR or 6LR will mix up the namespaces, which slightly raises the risk of a ROVR collision. A ROVR collision has no effect if the two Registering Nodes register different addresses, since the ROVR only matters within the context of one registration. A ROVR isn't expected to be unique to one registration, because this specification allows a node to use the same ROVR to register multiple IPv6 Addresses. That's why the ROVR MUST NOT be used as a key to identify the Registering Node or as an index to the registration. It's only used as a match, to make sure the node updating a registration for an IPv6 Address is the same node that made the original registration for that address. Also, when the ROVR isn't an EUI-64 address, it MUST NOT be used as the Interface Identifier of the Registered Address. This way, a registration using that ROVR won't collide with an IPv6 Address derived from EUI-64 that uses the EUI-64 as the ROVR per [RFC6775] ✨
The Registering Node SHOULD store the ROVR, or enough information to regenerate it, in persistent memory. If it doesn't, and something like a reboot causes a loss of state, re-registering the same address could be impossible until either (1) the 6LRs and the 6LBR time out the previous registration, or (2) a management action clears the relevant state in the network. Nobody wants that, so save it, bestie 💾
5.4. Extended Duplicate Address Messages 🦋
To map the new EARO content into the EDA messages, a new TID field is added to the EDAR and EDAC messages as a replacement for the Reserved field. A non-null value of the ICMP Code indicates support for this specification. The format of the EDAR and EDAC messages is presented in Section 4.2. 💅
Just like the EARO, the EDA messages are backward compatible with the RFC 6775-only versions, as long as the ROVR field is 64 bits long. Remarks about backward compatibility for the protocol between the 6LN and the 6LR apply in a similar way between a 6LR and a 6LBR 🌈
5.5. Registering the Target Address 🧚
An NS message with an EARO is a registration if and only if it also carries an SLLA Option ("SLLAO") [RFC6775] ("SLLA" stands for "Source Link-Layer Address") 🍓 The EARO can also be used in NS and NA messages between Routing Registrars to figure out the distributed registration state. In that case, it doesn't carry the SLLA Option and isn't confused with a registration.
The Registering Node is the node that does the registration to the Routing Registrar. As also described in [RFC6775], it may be the Registered Node too. In that case, it registers one of its own addresses and puts its own MAC address in the SLLA of the NS(EARO) 🫶
This specification adds the ability to proxy the registration on behalf of a Registered Node that's reachable over an LLN mesh. In that case, if the Registered Node is reachable from the Routing Registrar via a mesh-under configuration, the Registering Node puts the MAC address of the Registered Node in the SLLA of the NS(EARO). If the Registered Node is reachable over a route-over configuration from the Registering Node, the SLLA in the NS(ARO) is that of the Registering Node. This lets the Registering Node attract the packets from the Routing Registrar and route them over the LLN to the Registered Node 🦋
To make that second operation work, this specification changes how the 6LN and the 6LR behave, so the Registered Address is found in the Target Address field of the NS and NA messages instead of the Source Address field. With this convention, a TLLA Option (Target Link-Layer Address Option, or "TLLAO") indicates the link-layer address of the 6LN that owns the address 💜
A Registering Node (e.g., a 6LBR also acting as a RPL root) that advertises reachability for the 6LN MUST place its own link-layer address in the SLLA Option of the registration NS(EARO) message. This keeps things compatible with RFC 6775-only 6LoWPAN ND. ⚠️
5.6. Link-Local Addresses and Registration 🦋
okay so bestie, LLN nodes are often not wired and they move around a LOT 🏃♀️💨 which means there is no guarantee that a Link-Local Address stays unique among a huge and possibly changing crowd of neighbors 😭
compared to [RFC6775], this spec only requires that a Link-Local Address be unique from the perspective of the two nodes that actually talk to each other (for example the 6LN and the 6LR in an NS/NA exchange) 💖 this is SO simplifying for DAD in a route-over topology, because it skips the EDA message exchange between the 6LR and a 6LBR for those addresses ✨
an exchange between two nodes using Link-Local Addresses implies they are reachable over one hop 🧚 a node MUST register a Link-Local Address to a 6LR in order to get further reachability through that 6LR, and especially to use that Link-Local Address as the Source Address when it registers other addresses, like global ones 🌸
if there is no collision with a previously registered address, the Link-Local Address is unique from the standpoint of this 6LR and the registration is not a duplicate 🙌 two different 6LRs might claim the same Link-Local Address but with different link-layer addresses, and in that case a 6LN MUST only interact with at most one of the 6LRs 🫶
the EDAR and EDAC exchange between the 6LR and a 6LBR, which makes sure an address is unique across the whole domain covered by the 6LBR, does NOT need to happen for Link-Local Addresses 🙈
when sending an NS(EARO) to a 6LR, a 6LN MUST use a Link-Local Address as the Source Address of the registration, no matter what type of IPv6 Address is being registered 💅 that Link-Local Address MUST be either an address that is already registered to the 6LR, or the address that is being registered 🔥
when a 6LN starts up, it typically multicasts an RS and gets one or more unicast RA messages back from 6LRs 🌈 if the 6LR can process EARO messages, it puts a 6CIO in its RA with the E flag set, as required in Section 6.1 💜
when a Registering Node doesn't have an already-registered address yet, it MUST register a Link-Local Address, using it as both the Source Address and the Target Address of an NS(EARO) message 👑 in that case it is RECOMMENDED to use an address for which DAD is not required (see [RFC6775]), like one derived from a globally unique EUI-64 address 🍓 using the SLLA Option in the NS is consistent with existing ND specs like [RFC4429] ("Optimistic Duplicate Address Detection (DAD) for IPv6") 🦋 the 6LN MAY then use that address to register one or more other addresses ⭐
a 6LR that supports this spec replies with an NA(EARO), setting the appropriate status 💖 since there is no EDAR or EDAC exchange for Link-Local Addresses, the 6LR may answer immediately to the registration of a Link-Local Address, based only on its existing state and the SLLA Option placed in the NS(EARO) as required in [RFC6775] 🎀
a node registers its IPv6 Global Unicast Addresses (GUAs) to a 6LR so it can get global reachability for them through that 6LR 🌍 when registering with an updated 6LR, a Registering Node does NOT use a GUA as the Source Address, unlike a node that complies with [RFC6775] 🙅♀️ for non-Link-Local Addresses, the EDAR and EDAC exchange MUST conform to [RFC6775], but the extended formats in this spec for the DAR and the DAC are used to carry the extended info when there's an EARO 💅✨
5.7. Maintaining the Registration States 💜
this section is about the protocol actions involving the Registering Node, the 6LR, and the 6LBR 🧚 the part about a 6LBR only applies to addresses registered to it, and as discussed in Section 5.6, that is NOT the case for Link-Local Addresses 🙈 the registration state includes all the data the router stores about that registration, especially (but not only) an NCE 💖 6LBRs and Routing Registrars may store extra registration info and use synchronization protocols, but those are out of scope for this document 🌸
a 6LR cannot accept a new registration when its registration storage space is exhausted 😭 in that situation, the EARO comes back in an NA message with a status code of "Neighbor Cache Full" (Status 2; see [RFC6775] and Table 1), and the Registering Node MAY try to register with another 6LR 🦋
if the registry in the 6LBR is full, the 6LBR can't decide whether a registration for a new address is a duplicate 💀 so it replies to an EDAR message with an EDAC message carrying a new status code, "6LBR Registry Saturated" (Table 1) ✨ note: this code is used by 6LBRs instead of "Neighbor Cache Full" when responding to a Duplicate Address message exchange, and the 6LR passes it on to the Registering Node 🎀 there is no point in the node retrying via another 6LR, since the problem is network-wide 🙅♀️ the node MAY abandon that address, de-register other addresses first to make room, or keep the address "tentative" [RFC4861] and retry later 👑
a node renews an existing registration by sending a new NS(EARO) message for the Registered Address, and the 6LR MUST report the new registration to the 6LBR 🔥
a node that stops using an address SHOULD try to de-register that address from all the 6LRs it registered it with 🧹 this is done with an NS(EARO) message with a Registration Lifetime of 0 💅 if this doesn't happen, the state sticks around in the network until the current Registration Lifetime expires 😬 which can saturate the 6LR resources even if they were planned correctly from the start 💀 the 6LR may then take defensive measures that could stop this node, or other nodes, from owning as many addresses as they request (see Section 7) 🛡️
a node that moves away from a particular 6LR SHOULD try to de-register all of its addresses registered to that 6LR, and register with a new 6LR using an incremented TID 🏃♀️💨 when/if the node shows up somewhere else, an asynchronous NA(EARO) or EDAC message with a status code of "Moved" SHOULD be used to clean up the state in the previous location 🧼 the "Moved" status can be used by a Routing Registrar in an NA(EARO) message to say that ownership of the proxy state was transferred to another Routing Registrar because the device moved ✨ if the message receiver has registration state for the related address, it SHOULD pass the status down the forwarding path to the Registered Node (for example by reversing an existing RPL [RFC6550] path as prescribed in [Efficient-NPDAO]) 🌈 whether it could do that or not, the receiver MUST clean up that state 🫧
upon receiving an NS(EARO) with a Registration Lifetime of 0, and determining that this EARO is the most recent one for a given NCE (see Section 5.2), a 6LR cleans up its NCE 🧽 if the address was registered to the 6LBR, the 6LR MUST report to the 6LBR, through a Duplicate Address exchange with the 6LBR, indicating the null Registration Lifetime and the latest TID this 6LR knows about 💜
upon receiving the EDAR message, the 6LBR checks whether this is the most recent TID it has received for that particular registry entry 👀 if so, the EDAR gets answered with an EDAC message bearing status code 0 ("Success") [RFC6775], and the entry is scheduled to be removed 🗑️ otherwise, a status code of "Moved" is returned instead, and the existing entry is kept 🙌
when an address is scheduled to be removed, the 6LBR SHOULD keep its NCE in a DELAY state [RFC4861] for a configurable amount of time 🕰️ this prevents a scenario where (1) a mobile node de-registered from one 6LR but hasn't registered with a new one yet, or (2) the new registration hasn't reached the 6LBR yet because of propagation delays in the network 🚚 once the DELAY time has passed, the 6LBR quietly removes its entry 🤫
6. Backward Compatibility 🔙
this spec changes how peers behave in a registration flow 🔄 to keep things backward compatible, a 6LN that registers to a 6LR not known to support this spec MUST behave in a way that is backward compatible with [RFC6775] 🫶 but if the 6LR is found to support this spec, then the 6LN MUST conform to this spec when talking to that 6LR 💅
a 6LN that supports this spec MUST always use an EARO as a replacement for an ARO in its registration to a router 🎀 this is backward compatible, because the T flag and TID field sit in fields that are reserved in [RFC6775] and are therefore ignored by an RFC 6775-only router 🙌 a router that supports this spec MUST answer an NS(ARO) and an NS(EARO) with an NA(EARO) 🔥 a router that doesn't support this spec will treat the ROVR as an EUI-64 address and handle it the same way; this has no consequence as long as the Registered Addresses are different 🧠
6.1. Signaling EARO Support 📣
[RFC7400] specifies the 6CIO, which tells a node's peers about its capabilities 💜 the 6CIO MUST be present in both RS and RA messages, unless the 6CIO information was already shared in recent exchanges or pre-configured in all nodes in a network 🌸 in any case, a 6CIO MUST be placed in an RA message sent in response to an RS with a 6CIO 🦋
Section 4.3 defines a new flag for the 6CIO to signal EARO support by the message issuer ✨ new flags are also added to the 6CIO to signal the sender's capability to act as a 6LR, 6LBR, and Routing Registrar (see Section 4.3) 🧚
Section 4.3 also defines a new flag indicating that the 6LBR supports EDAR and EDAC messages 🙌 this flag is valid in RA messages but NOT in RS messages 🙅♀️ more info on the 6LBR is in a separate Authoritative Border Router Option (ABRO) 🌈 the ABRO is placed in RA messages as prescribed by [RFC6775]; in particular, it MUST be placed in an RA message sent in response to an RS with a 6CIO indicating the capability to act as a 6LR, since the RA propagates info between routers 🫶
6.2. RFC 6775-Only 6LN 🌱
an RFC 6775-only 6LN uses the Registered Address as the Source Address of the NS message and does NOT use an EARO 💀 an updated 6LR MUST accept that registration if it is valid per [RFC6775], and it MUST manage the binding cache accordingly 🗂️ the updated 6LR MUST then use the RFC 6775-only DAR and DAC messages as specified in [RFC6775] to tell the 6LBR that the TID is not present in the messages 👑
the main difference from [RFC6775] is that the DAR and DAC exchange for DAD purposes is avoided for Link-Local Addresses ✨ in any case, the 6LR MUST use an EARO in the reply and can use any of the status codes defined in this specification 💖
6.3. RFC 6775-Only 6LR 🌸
okay so an updated 6LN figures out what the 6LR can do by checking the 6CIO in its RA messages 👀 and if there's no 6CIO in the RA, the 6LR gets treated as RFC 6775-only 🫶
an updated 6LN MUST use an EARO in the request, no matter what kind of 6LR it's talking to, RFC 6775-only or updated 💅 which also means the T flag is set ✨ and if the 6LR is RFC 6775-only, the 6LN MUST use a 64-bit ROVR 🔥
now here's the drama 😭 if an updated 6LN moves from an updated 6LR over to an RFC 6775-only 6LR, that old-school 6LR is gonna send an RFC 6775-only DAR message, and you literally cannot compare that one with an updated one for recency 💀 letting RFC 6775-only DAR messages overwrite a state that the updated protocol set up in the 6LBR would be an attack vector 🙅♀️ so that can't be the default behavior 🚫 BUT if RFC 6775-only and updated 6LRs are chilling in the same network for a little while, it makes sense for an administrator to install a policy that allows this, using some method that is out of scope for this document 🧚
Letting old DAR messages override newer state is the attack vector here, so this behavior is never the default. Only a deliberate administrator policy can allow it, and the method for that policy is out of scope for this document.
6.4. RFC 6775-Only 6LBR 🦋
this spec extends the Duplicate Address messages so they can carry the EARO info 🎀 just like the NS/NA exchange, an updated 6LBR MUST always use the EDAR and EDAC messages 💖
ooh, but also: an RFC 6775-only 6LBR will accept and process an EDAR message as if it were a plain RFC 6775-only DAR, as long as the ROVR is 64 bits long 🥹 and an updated 6LR figures out what the 6LBR can do by checking the 6CIO in RA messages from the 6LR ✨ if the 6CIO wasn't in any RA, the 6LBR is assumed to be RFC 6775-only 🧸
if the 6LBR is RFC 6775-only, the 6LR MUST use only the 64 leftmost bits of the ROVR and put the result in the EDAR message so everything stays compatible 🫶 that way, DAD support is preserved 💜
7. Security Considerations 🔐
this spec extends [RFC6775], so the Security Considerations section of that document also applies here 🙌 most importantly, the link layer SHOULD be sufficiently protected to prevent rogue access 🚨
[RFC6775] doesn't protect the content of its messages and expects lower-layer encryption to handle potential attacks 😬 this spec requires the LLN MAC layer to provide secure unicast to and from a Routing Registrar, plus secure broadcast or multicast from the Routing Registrar, in a way that prevents tampering with or replaying the ND messages 🛡️
this spec recommends using privacy techniques (see Section 8) and protecting against address theft with methods outside the scope of this document 🦋 as an example, [AP-ND] guarantees ownership of the Registered Address using a cryptographic ROVR 💅
the registration mechanism could be abused by a rogue node to launch a denial-of-service attack against the registry of a 6LR or 6LBR 😱 it's also possible for that registry to get saturated and not take any more registrations, which effectively stops the requesting node from using a new address 💀 to ease those worries, (1) Section 5.2 provides a sequence counter that keeps incrementing so stale registration info can be detected and cleaned up, and it helps defeat replay attacks, and (2) Section 5.7 provides a bunch of recommendations so a stale registration gets removed from the 6LR and 6LBR as soon as possible 🧹
in particular, this spec recommends that:
- a node that stops using an address SHOULD attempt to de-register that address from all the 6LRs it's registered with 🫶
- registration lifetimes SHOULD be individually configurable for each address or group of addresses ⏳ a node SHOULD be configured, for each address (or address category), with a Registration Lifetime that matches how long it expects to use that address with the 6LR it's registered to 🎀 for use cases with mobility or rapid address changes, lifetimes SHOULD be the same order of magnitude as the expected duration of presence, but still longer 🚀
- the router (6LR or 6LBR) SHOULD be configurable so it can limit how many addresses a single node registers, but only as a protective measure 🛡️ no matter what, a router MUST be able to keep a minimum number of addresses per node 🧚 that minimum depends on the device type and ranges from 3 for a very constrained LLN up to 10 for a larger device 📏 a node may be identified by its MAC address, as long as privacy measures aren't obfuscating it 👀 a stronger identification (for example, by security credentials) is RECOMMENDED 🔑 when the maximum is hit, the router SHOULD use a Least Recently Used (LRU) algorithm to clean up addresses, while keeping at least one Link-Local Address 🧹 the router SHOULD also try to keep one or more stable addresses if stability can be determined, for example because they're used over a much longer time span than other privacy, shorter-lived addresses 💅
- administrators should take great care to deploy enough 6LRs to cover the needs of the nodes in their range, so that nodes don't end up starving 🥺 the 6LBR that serves an LLN is expected to be a more capable node than the average 6LR 💪 but if the network might get saturated, a particular LLN should spread out the 6LBR functionality, for instance by using a high-speed Backbone Link and Routing Registrars to aggregate multiple LLNs into a larger subnet 🌈
the LLN nodes depend on a 6LBR and may use the services of a Routing Registrar to operate 🧚 a trust model MUST be put in place so that only authorized devices act in these roles, to avoid threats like black-holing or bombing attacks, where an impersonated 6LBR would destroy state in the network by using the "Removed" status code 💀🚨 at a minimum, this trust model could be based on Layer 2 access control, or it could provide role validation as well (see Req-5.1 in Appendix B.5) 🔐
8. Privacy Considerations 🫧
as Section 3 pointed out, this protocol doesn't limit how many IPv6 Addresses each device can form 🌸 still, to mitigate denial-of-service attacks, it can be useful as a protective measure to have a limit that's high enough not to get in the way of normal device behavior ✨ a host should be able to form and register any address that's topologically correct in the subnet(s) advertised by the 6LR/6LBR 💖
this spec doesn't mandate any particular way of forming IPv6 Addresses 🙌 but it discourages using EUI-64 for forming the Interface Identifier in the Link-Local Address, because that method blocks Secure Neighbor Discovery (SEND) [RFC3971], Cryptographically Generated Addresses (CGAs) [RFC3972], and other address privacy techniques 🙈
[RFC8065] ("Privacy Considerations for IPv6 Adaptation-Layer Mechanisms") explains why privacy matters and how to form privacy-aware addresses 🦋 all implementations and deployments must consider the option of privacy addresses in their own environments 💜
the IPv6 Address of the 6LN in the IPv6 header can be compressed statelessly when the Interface Identifier can be derived from the lower-layer address 🧚 when getting that compression isn't critical, like when the address can be compressed statefully, or it's rarely used, or it's only used over one hop, privacy concerns should be considered 🫶 new implementations should follow [RFC8064] ("Recommendation on Stable IPv6 Interface Identifiers") 🌈 [RFC8064] recommends the mechanism specified in [RFC7217] ("A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)") for generating Interface Identifiers to be used in SLAAC 💅
9. IANA Considerations 📋
IANA has made a few changes under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry, as follows 🎀
9.1. Address Registration Option Flags 🚩
IANA has created a new subregistry for "Address Registration Option Flags" under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry 🌸 (see [RFC4443] for info about ICMPv6 ✨)
this spec defines eight positions, bit 0 to bit 7, and assigns bit 6 to the R flag and bit 7 to the T flag (see Section 4.1) 🦋 the registration procedure is "IETF Review" or "IESG Approval" (see [RFC8126]) 🫶
the initial contents of the registry are shown in Table 2 👑
+-------------+--------------+------------+
| ARO Status | Description | Reference |
+-------------+--------------+------------+
| 0-5 | Unassigned | |
| | | |
| 6 | R Flag | RFC 8505 |
| | | |
| 7 | T Flag | RFC 8505 |
+-------------+--------------+------------+Table 2: New Address Registration Option Flags 💖
9.2. Address Registration Option I-Field 🧚
IANA has created a new subregistry for "Address Registration Option I-Field" under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry 🌈
this spec defines four integer values, from 0 to 3, and assigns value 0 to "Abstract Index for Topology Selection" (see Section 4.1) ✨ the registration procedure is "IETF Review" or "IESG Approval" [RFC8126] 💅
the initial contents of the registry are shown in Table 3 🎀
+--------+---------------------------------------+------------+
| Value | Meaning | Reference |
+--------+---------------------------------------+------------+
| 0 | Abstract Index for Topology Selection | RFC 8505 |
| | | |
| 1-3 | Unassigned | |
+--------+---------------------------------------+------------+Table 3: New Subregistry for the EARO I-Field 🫶
9.3. ICMP Codes 🎀
okay so IANA made two brand-new subregistries 💅 They live inside the 'ICMPv6 "Code" Fields' registry, which is itself a subregistry of ICMPv6 codes in the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry 🧚
They belong to ICMP Types 157 (Duplicate Address Request), shown in Table 4, and 158 (Duplicate Address Confirmation), shown in Table 5 🦋 For those two types, the ICMP Code field gets split into two subfields: the Code Prefix and the Code Suffix. The new subregistries only cover the Code Suffix part, and the range is 0-15 in every case 🔢 The registration procedure for both is "IETF Review" or "IESG Approval" [RFC8126] ✨
Here are the starting contents of each one:
+--------------+--------------------------------------+------------+
| Code Suffix | Meaning | Reference |
+--------------+--------------------------------------+------------+
| 0 | DAR message | RFC 6775 |
| | | |
| 1 | EDAR message with 64-bit ROVR field | RFC 8505 |
| | | |
| 2 | EDAR message with 128-bit ROVR field | RFC 8505 |
| | | |
| 3 | EDAR message with 192-bit ROVR field | RFC 8505 |
| | | |
| 4 | EDAR message with 256-bit ROVR field | RFC 8505 |
| | | |
| 5-15 | Unassigned | |
+--------------+--------------------------------------+------------+
Table 4: Code Suffixes for ICMP Type 157 DAR Message
+--------------+--------------------------------------+------------+
| Code Suffix | Meaning | Reference |
+--------------+--------------------------------------+------------+
| 0 | DAC message | RFC 6775 |
| | | |
| 1 | EDAC message with 64-bit ROVR field | RFC 8505 |
| | | |
| 2 | EDAC message with 128-bit ROVR field | RFC 8505 |
| | | |
| 3 | EDAC message with 192-bit ROVR field | RFC 8505 |
| | | |
| 4 | EDAC message with 256-bit ROVR field | RFC 8505 |
| | | |
| 5-15 | Unassigned | |
+--------------+--------------------------------------+------------+
Table 5: Code Suffixes for ICMP Type 158 DAC Message9.4. New ARO Status Values 🌸
IANA has added some new values to the "Address Registration Option Status Values" subregistry, and they're all from RFC 8505 🫶 Here's the full lineup:
+-------+--------------------------------------------+------------+
| Value | Description | Reference |
+-------+--------------------------------------------+------------+
| 3 | Moved | RFC 8505 |
| | | |
| 4 | Removed | RFC 8505 |
| | | |
| 5 | Validation Requested | RFC 8505 |
| | | |
| 6 | Duplicate Source Address | RFC 8505 |
| | | |
| 7 | Invalid Source Address | RFC 8505 |
| | | |
| 8 | Registered Address Topologically Incorrect | RFC 8505 |
| | | |
| 9 | 6LBR Registry Saturated | RFC 8505 |
| | | |
| 10 | Validation Failed | RFC 8505 |
+-------+--------------------------------------------+------------+
Table 6: New ARO Status Values9.5. New 6LoWPAN Capability Bits 🦋
IANA also added some bits to the "6LoWPAN Capability Bits" subregistry, all from RFC 8505 ✨ These are the five new ones:
+------+---------------------------+------------+
| Bit | Description | Reference |
+------+---------------------------+------------+
| 10 | EDA Support (D bit) | RFC 8505 |
| | | |
| 11 | 6LR capable (L bit) | RFC 8505 |
| | | |
| 12 | 6LBR capable (B bit) | RFC 8505 |
| | | |
| 13 | Routing Registrar (P bit) | RFC 8505 |
| | | |
| 14 | EARO support (E bit) | RFC 8505 |
+------+---------------------------+------------+
Table 7: New 6LoWPAN Capability Bits10. References 📚
10.1. Normative References 💜
Here's the list of normative references, with every detail kept exactly as the original has it 🫶
[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>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[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>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, <https://www.rfc-editor.org/info/rfc4919>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing", RFC 6606, DOI 10.17487/RFC6606, May 2012, <https://www.rfc-editor.org/info/rfc6606>.
[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>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 2014, <https://www.rfc-editor.org/info/rfc7400>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References ✨
okay bestie, this is the extra-credit reading list 📚🎀 these ones are informative, so they're background and context rather than the core rules 💅
- [Alternative-Ellip-Curve-Reps] Struik, R., "Alternative Elliptic Curve Representations", Work in Progress, draft-struik-lwip-curve-representations-00, October 2017.
- [AP-ND] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, "Address Protected Neighbor Discovery for Low-power and Lossy Networks", Work in Progress, draft-ietf-6lo-ap-nd-08, October 2018.
- [Arch-for-6TiSCH] Thubert, P., Ed., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Work in Progress, draft-ietf-6tisch-architecture-17, November 2018.
- [Efficient-NPDAO] Jadhav, R., Ed., Thubert, P., Sahoo, R., and Z. Cao, "Efficient Route Invalidation", Work in Progress, draft-ietf-roll-efficient-npdao-09, October 2018.
- [IEEE-802-15-4] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Standard 802.15.4, DOI 10.1109/IEEESTD.2016.7460875,
<https://ieeexplore.ieee.org/document/7460875/>. - [IPv6-Backbone-Router] Thubert, P., Ed. and C. Perkins, "IPv6 Backbone Router", Work in Progress, draft-ietf-6lo-backbone-router-08, October 2018.
- [IPv6-over-802.11ah] Del Carpio Vega, L., Robles, M., and R. Morabito, "IPv6 over 802.11ah", Work in Progress, draft-delcarpio-6lo-wlanah-01, October 2015.
- [IPv6-over-NFC] Choi, Y., Ed., Hong, Y-G., Youn, J-S., Kim, D-K., and J-H. Choi, "Transmission of IPv6 Packets over Near Field Communication", Work in Progress, draft-ietf-6lo-nfc-12, November 2018.
- [IPv6-over-PLC] Hou, J., Liu, B., Hong, Y-G., Tang, X., and C. Perkins, "Transmission of IPv6 Packets over PLC Networks", Work in Progress, draft-hou-6lo-plc-05, October 2018.
- [Multicast-over-IEEE802-Wireless] Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", Work in Progress, draft-ietf-mboned-ieee802-mcast-problems-03, October 2018.
- [ND-Optimizations] Chakrabarti, S., Nordmark, E., Thubert, P., and M. Wasserman, "IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks", Work in Progress, draft-chakrabarti-nordmark-6man-efficient-nd-07, February 2015.
- [Perlman83] Perlman, R., "Fault-Tolerant Broadcast of Routing Information", North-Holland Computer Networks 7: pp. 395-405, DOI 10.1016/0376-5075(83)90034-X, 1983,
<http://www.cs.illinois.edu/~pbg/courses/cs598fa09/readings/p83.pdf>. - [RFC1958] Carpenter, B., Ed., "Architectural Principles of the Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
<https://www.rfc-editor.org/info/rfc1958>. - [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996,
<https://www.rfc-editor.org/info/rfc1982>. - [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003,
<https://www.rfc-editor.org/info/rfc3610>. - [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>. - [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>. - [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>. - [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<https://www.rfc-editor.org/info/rfc4429>. - [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<https://www.rfc-editor.org/info/rfc4941>. - [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>. - [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>. - [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/RFC7428, February 2015,
<https://www.rfc-editor.org/info/rfc7428>. - [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<https://www.rfc-editor.org/info/rfc7668>. - [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, "Host Address Availability Recommendations", BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016,
<https://www.rfc-editor.org/info/rfc7934>. - [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>. - [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, February 2017,
<https://www.rfc-editor.org/info/rfc8065>. - [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, M., and D. Barthel, "Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May 2017,
<https://www.rfc-editor.org/info/rfc8105>. - [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. Donaldson, "Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, May 2017,
<https://www.rfc-editor.org/info/rfc8163>. - [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, "Multicast Using Bit Index Explicit Replication (BIER)", RFC 8279, DOI 10.17487/RFC8279, November 2017,
<https://www.rfc-editor.org/info/rfc8279>. - [Routing-for-RPL-Leaves] Thubert, P., Ed., "Routing for RPL Leaves", Work in Progress, draft-thubert-roll-unaware-leaves-05, May 2018.
Appendix A. Applicability and Fulfilled Requirements (Not Normative) 🦋
okay so this spec is basically a glow-up for 6LoWPAN ND 💖 it adds a sequence number to the registration 🔢 and that's how it checks off Appendix B.1, by letting devices move from one LLN to the next 🚶♀️✨ the full mobility recipe, built on the EARO and the registration procedures defined here, lives in later work: [IPv6-Backbone-Router] ("IPv6 Backbone Router") 🧚 the 6BBR is an example of a Routing Registrar that acts as an IPv6 ND proxy over a Backbone Link, and it federates multiple LLNs plus the Backbone Link itself into one single IPv6 subnet 🫶 the registration flow for that case is in Figure 6, and any combination of 6LR, 6LBR, and 6BBR may be collocated 💅
6LN 6LR 6LBR 6BBR
| | | |
| NS(EARO) | | |
|--------------->| | |
| | Extended DAR | |
| |-------------->| |
| | | |
| | | proxy NS(EARO) |
| | |--------------->|
| | | | NS(DAD)
| | | | ------>
| | | | <wait>
| | | |
| | | proxy NA(EARO) |
| | |<---------------|
| | Extended DAC | |
| |<--------------| |
| NA(EARO) | | |
|<---------------| | |
| | | |
Figure 6: (Re-)Registration Flow[Arch-for-6TiSCH] ("An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4") explains how a 6LoWPAN ND host using the Time-Slotted Channel Hopping (TSCH) mode of IEEE Std. 802.15.4 [IEEE-802-15-4] can connect to the Internet through an RPL mesh network 🌸 that setup needs extra 6LoWPAN ND additions to handle mobility and reachability in a secure and manageable network environment 🔐 this document specifies those new operations, and it fulfills the requirements listed in Appendix B.2 ✅
the term "LLN" gets used loosely in this document 🌈 it's meant to cover several kinds of WLANs and WPANs, including Low-Power IEEE Std. 802.11 networking, Bluetooth low energy, IEEE Std. 802.11ah, and IEEE Std. 802.15.4 wireless meshes, so that it can address the requirements discussed in Appendix B.3 🍓
this specification can be used by any wireless node to register its IPv6 Addresses with a Routing Registrar and to get routing services, like proxy ND operations over a Backbone Link 🦋 that satisfies the requirements expressed in Appendix B.4 🎀
[AP-ND] extends this specification to provide a solution for some of the security-related requirements expressed in Appendix B.5 🔐💜
[ND-Optimizations] ("IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks") suggests that 6LoWPAN ND [RFC6775] can be extended to other kinds of links, beyond IEEE Std. 802.15.4, that it was originally defined for 👑 the registration technique pays off when the link-layer technique used to carry IPv6 multicast packets isn't efficient enough in delivery ratio or energy consumption on the end devices 🔋 especially to enable energy-constrained sleeping nodes 😴 the value of this extension really shines for mobile wireless nodes, since it cuts down the multicast operations related to IPv6 ND [RFC4861] [RFC4862] that affect the wireless medium [Multicast-over-IEEE802-Wireless] 📡 this fulfills the scalability requirements listed in Appendix B.6 🌈
Appendix B. Requirements (Not Normative) 🎀
okay so bestie, this appendix is basically the 6lo Working Group's wishlist 📝✨ these are the requirements they talked about for an update to 6LoWPAN ND. (How they actually got matched up with existing specs is shown in Appendix B.8, so go peek there for the receipts 💅)
B.1. Requirements Related to Mobility 🦋
okay so LLN links are super unstable 😭 even if every node in the LLN is totally stationary, a 6LN can switch its point of attachment from, say, 6LR-a to 6LR-b, and then it might not be able to tell 6LR-a about it. 💀 So 6LR-a keeps attracting traffic it literally can't deliver anymore. Yikes!! So when links to a 6LR change state, there's a need to spot the stale states in a 6LR and get reachability back ASAP. You could do that with some kind of signaling when movement is detected, or with a keep-alive mechanism on a period that fits what the application needs. ⏰
Req-1.1: Upon a change of point of attachment, connectivity via a new 6LR MUST be restored in a timely fashion without the need to de-register from the previous 6LR.
Req-1.2: For that purpose, the protocol MUST enable differentiating between multiple registrations from one 6LN and registrations from different 6LNs claiming the same address.
Req-1.3: Stale states MUST be cleaned up in 6LRs.
Req-1.4: A 6LN SHOULD also be able to register its address concurrently to multiple 6LRs.
B.2. Requirements Related to Routing Protocols 🛣️
The point of attachment of a 6LN might be a 6LR in an LLN mesh. 🕸️ IPv6 routing in an LLN can be based on RPL, which is the routing protocol the IETF defined for this exact purpose. 💖 Other routing protocols are also being looked at by Standards Development Organizations (SDOs) depending on the network characteristics they expect. It is required that a 6LN attached via ND to a 6LR indicate whether or not it (1) participates in the selected routing protocol to get reachability via the 6LR or (2) expects the 6LR to manage its reachability. 🫶
The specified updates let other specs define new services, like Source Address Validation Improvement (SAVI) (via [AP-ND]), participation as an unaware leaf to a routing protocol (such as the protocol described in [RFC6550] (RPL)) (via [Routing-for-RPL-Leaves]), and registration to Backbone Routers doing proxy ND in an LLN (via [IPv6-Backbone-Router]). 🧚
Beyond the 6LBR unicast address registered by ND, other addresses, including multicast addresses, are needed too. For example, a routing protocol often uses a multicast address to register changes to established paths. ND needs to register such a multicast address so routing can happen at the same time as discovery. 🌈
Multicast is needed for groups. Groups might be formed by device type (e.g., routers, street lamps), location (geography, RPL subtree), or both. 🍓
The Bit Index Explicit Replication (BIER) architecture [RFC8279] proposes an optimized technique to enable multicast in an LLN with a very limited requirement for routing state in the nodes. ✨
Related requirements are as follows:
Req-2.1: The ND registration method SHOULD be extended so that the 6LR is instructed whether to advertise the address of a 6LN over the selected routing protocol and obtain reachability to that address using the selected routing protocol.
Req-2.2: Considering RPL, the ARO that is used in the ND registration SHOULD be extended to carry enough information to generate a DAO message as specified in Section 6.4 of [RFC6550] -- in particular, the capability to compute a Path Sequence and, as an option, a RPLInstanceID.
Req-2.3: Multicast operations SHOULD be supported and optimized -- for instance, using BIER or the Multicast Protocol for Low-Power and Lossy Networks (MPL). Whether ND is appropriate for the registration to the Routing Registrar is to be defined, considering the additional burden of supporting Multicast Listener Discovery Version 2 (MLDv2) for IPv6 [RFC3810].
B.3. Requirements Related to Various Low-Power Link Types 📡
6LoWPAN ND [RFC6775] was designed with a focus on IEEE Std.802.15.4 and, in particular, the ability to derive a unique identifier from a globally unique EUI-64 address. 🔑 Right now, the 6lo Working Group is extending the 6LoWPAN Header Compression (HC) technique [RFC6282] to other link types, including ITU-T G.9959 [RFC7428], Master-Slave/Token-Passing [RFC8163], Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy [RFC8105], Near Field Communication [IPv6-over-NFC], and IEEE Std. 802.11ah [IPv6-over-802.11ah], plus Bluetooth low energy [RFC7668] and Power Line Communication (PLC) Networks [IPv6-over-PLC]. 📶
Related requirements are as follows:
Req-3.1: The support of the registration mechanism SHOULD be extended to more LLN links than IEEE Std.802.15.4, matching at least the LLN links for which an "IPv6 over foo" specification exists, as well as low-power Wi-Fi.
Req-3.2: As part of this extension, a mechanism to compute a unique identifier should be provided, with the capability to form a Link-Local Address that SHOULD be unique at least within the LLN connected to a 6LBR discovered by ND in each node within the LLN.
Req-3.3: The ARO used in the ND registration SHOULD be extended to carry the relevant forms of the unique identifier.
Req-3.4: ND should specify the formation of a site-local address that follows the security recommendations in [RFC7217].
B.4. Requirements Related to Proxy Operations 🤝
Duty-cycled devices might not be awake to answer a lookup from a node that uses IPv6 ND, so they may need a proxy. 😴 Also, the duty-cycled device may rely on the 6LBR to do registration to the Routing Registrar. 💜
The ND registration method SHOULD defend the addresses of duty-cycled devices that are sleeping most of the time and incapable of defending their own addresses. 🛡️
Related requirements are as follows:
Req-4.1: The registration mechanism SHOULD enable a third party to proxy-register an address on behalf of a 6LN that may be sleeping or located deeper in an LLN mesh.
Req-4.2: The registration mechanism SHOULD be applicable to a duty-cycled device regardless of the link type and SHOULD enable a Routing Registrar to operate as a proxy to defend the Registered Addresses on its behalf.
Req-4.3: The registration mechanism SHOULD enable long sleep durations, on the order of multiple days to a month. 🌙
B.5. Requirements Related to Security 🔐
To guarantee the operations of the 6LoWPAN ND flows, spoofing the roles of the 6LR, 6LBR, and Routing Registrar should be avoided. 🚫 Once a node successfully registers an address, 6LoWPAN ND should provide energy-efficient means for the 6LBR to protect that ownership even when the node that registered the address is sleeping. 😴🔒
In particular, the 6LR and the 6LBR should then be able to verify whether a subsequent registration for a given address comes from the original node. 🕵️♀️
In an LLN, it makes sense to base security on Layer 2 security. 💅 During bootstrap of the LLN, nodes join the network after authorization by a Joining Assistant (JA) or a Commissioning Tool (CT). After joining, nodes communicate with each other via secured links. The keys for Layer 2 security are distributed by the JA/CT. 🗝️
The JA/CT can be part of the LLN or be outside the LLN. In both cases, the ability to route packets between the JA/CT and the joining node is needed. 🗺️
Related requirements are as follows:
Req-5.1: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for the 6LR, 6LBR, and Routing Registrar to authenticate and authorize one another for their respective roles, as well as with the 6LN for the role of 6LR.
Req-5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for the 6LR and the 6LBR to validate new registrations of authorized nodes. Joining of unauthorized nodes MUST be prevented.
Req-5.3: The use of 6LoWPAN ND security mechanisms SHOULD NOT result in large packet sizes. In particular, the NS, NA, DAR, and DAC messages for a re-registration flow SHOULD NOT exceed 80 octets so as to fit in a secured IEEE Std.802.15.4 [IEEE-802-15-4] frame.
Req-5.4: Recurrent 6LoWPAN ND security operations MUST NOT be computationally intensive on the 6LN's CPU. When calculation of a key hash is employed, a mechanism lighter than SHA-1 SHOULD be used.
Req-5.5: The number of keys that the 6LN needs to manipulate SHOULD be minimized.
Req-5.6: 6LoWPAN ND security mechanisms SHOULD enable (1) the variation of CCM ("Counter with CBC-MAC") [RFC3610] called "CCM*" for use at both Layer 2 and Layer 3 and (2) the reuse of a security code that has to be present on the device for upper-layer security (e.g., TLS). Algorithm agility and support for large keys (e.g., 256-bit key sizes) are also desirable.
Req-5.7: Public key and signature sizes SHOULD be minimized while maintaining adequate confidentiality and data origin authentication for multiple types of applications with various degrees of criticality.
Req-5.8: Routing of packets should continue when links pass from the unsecured state to the secured state.
Req-5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for the 6LR and the 6LBR to validate whether a new registration for a given address corresponds to the same 6LN that registered it initially and, if not, determine the rightful owner and deny or clean up the registration if it is a duplicate.
B.6. Requirements Related to Scalability 📈
Use cases from Automatic Meter Reading (AMR) (collection-tree operations) and Advanced Metering Infrastructure (AMI) (bidirectional communication to the meters) show the need for a large number of LLN nodes pertaining to a single RPL DODAG (e.g., 5000) and connected to the 6LBR over a large number of LLN hops (e.g., 15). 💡
Related requirements are as follows:
Req-6.1: The registration mechanism SHOULD enable a single 6LBR to register multiple thousands of devices.
Req-6.2: The timing of the registration operation should allow for long latency, such as that found in LLNs with ten or more hops.
B.7. Requirements Related to Operations and Management 🛠️✨
okay so Guideline 3.8 in Section 3 of [RFC1958] ("Architectural Principles of the Internet") gives a really good vibe check 💅. It says:
"Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually."
This is extra true for LLNs 🌸, because there can be SO many devices and setting each one up by hand is just not happening. Dynamic configuration on LLN devices also has limits from the network and from power, so it's not always a free pass 🥺.
A network admin should be able to check that the network is running within its capacity 📊. The big thing to watch is whether a 6LBR is getting slammed with way too many registrations 😭. If it is, the admin can add a Backbone Link with more 6LBRs and Routing Registrars to the network 🧚. Main character admin energy, honestly 👑.
Here are the related requirements, bestie 🫶:
- Req-7.1: A management model SHOULD be provided that enables access to the 6LBR, monitors its usage vs. capacity, and sends alerts in the case of congestion. It is recommended that the 6LBR be reachable over a non-LLN link 🦋.
- Req-7.2: A management model SHOULD be provided that enables access to the 6LR and its capacity to host additional NCEs 🍓. This management model SHOULD avoid polling individual 6LRs in a way that could disrupt the operation of the LLN 🙈.
- Req-7.3: Information on successful and failed registrations SHOULD be provided, including information such as the ROVR of the 6LN, the Registered Address, the address of the 6LR, and the duration of the registration flow 📝.
- Req-7.4: In the case of a failed registration, information on the failure SHOULD be provided, including the identification of the node that rejected the registration and the status in the EARO 💀.
B.8. Matching Requirements with Specifications 🌈
Here's the tea ☕. This table shows which document addresses each requirement. Some rows are blank, and the Technology Dependent ones are exactly what they sound like 🎀.
+-------------+--------------------------------+
| Requirement | Document |
+-------------+--------------------------------+
| Req-1.1 | [IPv6-Backbone-Router] |
| | |
| Req-1.2 | [RFC6775] |
| | |
| Req-1.3 | [RFC6775] |
| | |
| Req-1.4 | RFC 8505 |
| | |
| Req-2.1 | RFC 8505 |
| | |
| Req-2.2 | RFC 8505 |
| | |
| Req-2.3 | |
| | |
| Req-3.1 | Technology Dependent |
| | |
| Req-3.2 | Technology Dependent |
| | |
| Req-3.3 | Technology Dependent |
| | |
| Req-3.4 | Technology Dependent |
| | |
| Req-4.1 | RFC 8505 |
| | |
| Req-4.2 | RFC 8505 |
| | |
| Req-4.3 | [RFC6775] |
| | |
| Req-5.1 | |
| | |
| Req-5.2 | [AP-ND] |
| | |
| Req-5.3 | |
| | |
| Req-5.4 | |
| | |
| Req-5.5 | [AP-ND] |
| | |
| Req-5.6 | [Alternative-Ellip-Curve-Reps] |
| | |
| Req-5.7 | [AP-ND] |
| | |
| Req-5.8 | |
| | |
| Req-5.9 | [AP-ND] |
| | |
| Req-6.1 | RFC 8505 |
| | |
| Req-6.2 | RFC 8505 |
| | |
| Req-7.1 | |
| | |
| Req-7.2 | |
| | |
| Req-7.3 | |
| | |
| Req-7.4 | |
+-------------+--------------------------------+
Table 8: Documents That Address RequirementsAcknowledgments 💖
Huge kudos to Eric Levy-Abegnoli 👑, who designed the "First-Hop Security" infrastructure that the very first Backbone Router was built on. Many thanks to Sedat Gormus, Rahul Jadhav, Tim Chown, Juergen Schoenwaelder, Chris Lonvick, Dave Thaler, Adrian Farrel, Peter Yee, Warren Kumari, Benjamin Kaduk, Mirja Kuehlewind, Ben Campbell, Eric Rescorla, and Lorenzo Colitti for all their contributions and reviews 🫶. Also, a massive thank you to Thomas Watteyne 🧚, who made the world's first 6LN implementation. It was a big help for the early tests of the 6LR, 6LBR, and Backbone Router 🎉.
Authors' Addresses 🦋
Pascal Thubert (editor)
Cisco Systems, Inc.
Building D (Regus) 45 Allee des Ormes
Mougins - Sophia Antipolis
France
Phone: +33 4 97 23 26 34
Email: pthubert@cisco.com
Erik Nordmark
Zededa
Santa Clara, CA
United States of America
Email: nordmark@sonic.net
Samita Chakrabarti
Verizon
San Jose, CA
United States of America
Email: samitac.ietf@gmail.com
Charles E. Perkins
Futurewei
2330 Central Expressway
Santa Clara, CA 95050
United States of America
Email: charliep@computer.org📦 where this page comes from
- ietf: rfc8505 2018-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms