draft-ietf-6lo-rfc6775-update-07.txt   draft-ietf-6lo-rfc6775-update-08.txt 
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft cisco Internet-Draft cisco
Updates: 6775 (if approved) E. Nordmark Updates: 6775 (if approved) E. Nordmark
Intended status: Standards Track Intended status: Standards Track
Expires: January 29, 2018 S. Chakrabarti Expires: March 24, 2018 S. Chakrabarti
July 28, 2017 September 20, 2017
An Update to 6LoWPAN ND An Update to 6LoWPAN ND
draft-ietf-6lo-rfc6775-update-07 draft-ietf-6lo-rfc6775-update-08
Abstract Abstract
This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to
clarify the role of the protocol as a registration technique, clarify the role of the protocol as a registration technique,
simplify the registration operation in 6LoWPAN routers, as well as to simplify the registration operation in 6LoWPAN routers, as well as to
provide enhancements to the registration capabilities and mobility provide enhancements to the registration capabilities and mobility
detection for different network topologies including the backbone detection for different network topologies including the backbone
routers performing proxy Neighbor Discovery in a low power network. routers performing proxy Neighbor Discovery in a low power network.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 29, 2018. This Internet-Draft will expire on March 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability of Address Registration Options . . . . . . . . 3 2. Applicability of Address Registration Options . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 5 4. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Extended Address Registration Option . . . . . . . . . . 6 4.1. Extended Address Registration Option (EARO . . . . . . . 7
4.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 6 4.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Comparing TID values . . . . . . . . . . . . . . . . 7 4.2.1. Comparing TID values . . . . . . . . . . . . . . . . 8
4.3. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 8 4.3. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 9
4.4. Registering the Target Address . . . . . . . . . . . . . 9 4.4. Extended Duplicate Address Messages . . . . . . . . . . . 10
4.5. Link-Local Addresses and Registration . . . . . . . . . . 9 4.5. Registering the Target Address . . . . . . . . . . . . . 10
4.6. Maintaining the Registration States . . . . . . . . . . . 11 4.6. Link-Local Addresses and Registration . . . . . . . . . . 11
5. Detecting Enhanced ARO Capability Support . . . . . . . . . . 12 4.7. Maintaining the Registration States . . . . . . . . . . . 13
6. Updated ND Options . . . . . . . . . . . . . . . . . . . . . 13 5. Detecting Enhanced ARO Capability Support . . . . . . . . . . 14
6.1. The Enhanced Address Registration Option (EARO) . . . . . 13 6. Extended ND Options And Messages . . . . . . . . . . . . . . 15
6.2. New 6LoWPAN capability Bits in the Capability Indication 6.1. Enhanced Address Registration Option (EARO) . . . . . . . 15
Option . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. Extended Duplicate Address Message Formats . . . . . . . 18
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 16 6.3. New 6LoWPAN Capability Bits in the Capability Indication
7.1. Discovering the capabilities of an ND peer . . . . . . . 16 Option . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1.1. Using the E Flag in the CIO . . . . . . . . . . . . . 16 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 19
7.1.2. Using the T Flag in the EARO . . . . . . . . . . . . 17 7.1. Discovering the capabilities of an ND peer . . . . . . . 19
7.2. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 17 7.1.1. Using the E Flag in the 6CIO Option . . . . . . . . . 19
7.3. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 17 7.1.2. Using the T Flag in the EARO . . . . . . . . . . . . 20
7.4. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 18 7.2. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7.3. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 21
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 7.4. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.1. ARO Flags . . . . . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 23 10.2. ICMP Codes . . . . . . . . . . . . . . . . . . . . . . . 24
12.3. External Informative References . . . . . . . . . . . . 26 10.3. New ARO Status values . . . . . . . . . . . . . . . . . 25
Appendix A. Applicability and Requirements Served . . . . . . . 26 10.4. New 6LoWPAN capability Bits . . . . . . . . . . . . . . 26
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
B.1. Requirements Related to Mobility . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.2. Requirements Related to Routing Protocols . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 27
12.3. External Informative References . . . . . . . . . . . . 30
Appendix A. Applicability and Requirements Served . . . . . . . 30
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 31
B.1. Requirements Related to Mobility . . . . . . . . . . . . 32
B.2. Requirements Related to Routing Protocols . . . . . . . . 32
B.3. Requirements Related to the Variety of Low-Power Link B.3. Requirements Related to the Variety of Low-Power Link
types . . . . . . . . . . . . . . . . . . . . . . . . . . 28 types . . . . . . . . . . . . . . . . . . . . . . . . . . 33
B.4. Requirements Related to Proxy Operations . . . . . . . . 29 B.4. Requirements Related to Proxy Operations . . . . . . . . 34
B.5. Requirements Related to Security . . . . . . . . . . . . 29 B.5. Requirements Related to Security . . . . . . . . . . . . 34
B.6. Requirements Related to Scalability . . . . . . . . . . . 31 B.6. Requirements Related to Scalability . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
The scope of this draft is an IPv6 Low Power Networks including star The scope of this draft is an IPv6 Low Power Networks including star
and mesh topologies. This specification modifies and extends the and mesh topologies. This specification modifies and extends the
behavior and protocol elements of RFC 6775 "Neighbor Discovery behavior and protocol elements of "Neighbor Discovery Optimization
Optimization for IPv6 over Low-Power Wireless Personal Area Networks for IPv6 over Low-Power Wireless Personal Area Networks" (6LoWPAN ND)
(6LoWPANs)" [RFC6775] to enable additional capabilities such as: [RFC6775] to enable additional capabilities such as:
* Support the indication of mobility vs retry (T-bit) o Support for indicating mobility vs retry (T-bit)
* Ease up requirement of registration for link-local addresses o Ease up requirement of registration for link-local addresses
* Introducing Enhancement to Address Registration Option (ARO) o Enhancement to Address Registration Option (ARO)
* Permitting regitration of target address o Permitting registration of target address
* Clarification of support of privacy and temporary addresses o Clarification of support of privacy and temporary addresses
The following sections will discuss applicability of 6LoWPAN ND The applicability of 6LoWPAN ND registration is discussed in
registration, new extensions and updates to RFC 6775. Finally, we Section 2, and new extensions and updates to RFC 6775 are presented
will discuss how the extensions of registration framework can be in Section 4. Considerations on Backward Compatibility, Security and
useful for a scenario such as Backbone router(6BBR) proxy ND Privacy are also elaborated upon in Section 7, Section 8 and in
operations. Section 9, respectively.
2. Applicability of Address Registration Options 2. Applicability of Address Registration Options
The purpose of the Address Registration Option (ARO) [RFC6775] and of The original purpose of the Address Registration Option (ARO) in the
the Extended ARO (EARO) that is introduced in this document is to original 6LoWPAN ND specification is to facilitate duplicate address
facilitate duplicate address detection (DAD) for hosts and pre- detection (DAD) for hosts as well as populate Neighbor Cache Entries
populate Neighbor Cache Entries (NCE) [RFC4861] in the routers to (NCE) [RFC4861] in the routers. This reduces the reliance on
reduce the need for sending 'multicast neighbor solicitations' which multicast operations, which are often as intrusive as broadcast, in
may be harmful in low power constrained nodes networks where IPv6 ND operations.
multicast is most often treated as broadcasts.
In some cases the address registration can fail or becomes useless With this specification, a registration can fail or become useless
for reasons other than a duplicate address. Examples are the router for reasons other than address duplication. Examples include: the
having run out of space, a registration bearing a stale sequence router having run out of space; a registration bearing a stale
number (e.g. denoting a movement of the host after this registration sequence number perhaps denoting a movement of the host after the
was placed), a host misbehaving and attempting to register an invalid registration was placed; a host misbehaving and attempting to
address such as the unspecified address [RFC4291], or the host using register an invalid address such as the unspecified address
an address which is not topologically correct on that link. In such [RFC4291]; or a host using an address which is not topologically
cases the host will receive an error to help diagnose the issue and correct on that link.
may retry, possibly with a different address, and possibly
registering to a different 6LR, depending on the returned error.
However, the ability to return errors to address registrations MUST In such cases the host will receive an error to help diagnose the
NOT be used to restrict the ability of hosts to form and use issue and may retry, possibly with a different address, and possibly
addresses as recommended in "Host Address Availability registering to a different router, depending on the returned error.
Recommendations" [RFC7934]. In particular, this is needed for However, the ability to return errors to address registrations is not
enhanced privacy, which implies that each host will register a intended to be used to restrict the ability of hosts to form and use
multiplicity of address as part mechanisms like "Privacy Extensions addresses, as recommended in "Host Address Availability
for Stateless Address Autoconfiguration (SLAAC) in IPv6" [RFC4941]. Recommendations" [RFC7934].
This implies that the capabilities of 6LR and 6LBRs in terms of
number of registrations must be clearly announced in the router In particular, the freedom to form and register addresses is needed
documentation, and that a network administrator should deploy adapted for enhanced privacy; each host may register a multiplicity of
6LR/6LBRs to support the number and type of devices in his network, address using mechanisms such as "Privacy Extensions for Stateless
based on the number of IPv6 addresses that those devices require. Address Autoconfiguration (SLAAC) in IPv6" [RFC4941].
In the classical IPv6 ND [RFC4861], a router must have enough storage
to hold neighbor cache entries for all the addresses to which it may
forward. A router using 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. For this reason, the number of registrations
supported by a 6LoWPAN Router (6LR) or 6LoWPAN Border Router (6LBR)
must be clearly documented.
A network administrator should deploy adapted 6LR/6LBRs to support
the number and type of devices in his network, based on the number of
IPv6 addresses that those devices require and their renewal rate and
behaviour.
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Readers are expected to be familiar with all the terms and concepts Readers are expected to be familiar with all the terms and concepts
that are discussed in that are discussed in
"Neighbor Discovery for IP version 6" [RFC4861], o "Neighbor Discovery for IP version 6" [RFC4861],
"IPv6 Stateless Address Autoconfiguration" [RFC4862], o "IPv6 Stateless Address Autoconfiguration" [RFC4862],
"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals" [RFC4919], Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
"Neighbor Discovery Optimization for Low-power and Lossy Networks" o "Neighbor Discovery Optimization for Low-power and Lossy Networks"
[RFC6775] and [RFC6775] and
"Multi-link Subnet Support in IPv6" o "Multi-link Subnet Support in IPv6"
[I-D.ietf-ipv6-multilink-subnets]. [I-D.ietf-ipv6-multilink-subnets],
as well as this additional terminology: as well as the following terminology:
Backbone This is an IPv6 transit link that interconnects 2 or more Backbone Link An IPv6 transit link that interconnects two or more
Backbone Routers. It is expected to be deployed as a high Backbone Routers. It is expected to be of a relatively high
speed Backbone in order to federate a potentially large set of speed compared to the LLN in order to support the trafic that
LLNS. Also referred to as a LLN Backbone or Backbone network. is required to federate multiple segments of the potentially
large LLN into a single IPv6 subnet. Also referred to as a to
as a Backbone, a LLN Backbone, and a Backbone Network.
Backbone Router An IPv6 router that federates the LLN using a Backbone Router A logical network function in an IPv6 router that
Backbone link as a Backbone. A 6BBR acts as a 6LoWPAN Border federates a LLN over a Backbone Link. In order to do so, the
Routers (6LBR) and an Energy Aware Default Router (NEAR). Backbone Router (6BBR) proxies the 6LoWPAN ND operations
detailed in the document onto the matching operations that run
over the backbone, typically classical IPv6 ND. Note that 6BBR
is a logical function, just like 6LR and 6LBR, and that a same
physical router may operate all three.
Extended LLN This is the aggregation of multiple LLNs as defined in Extended LLN The aggregation of multiple LLNs as defined in RFC 4919
RFC 4919 [RFC4919], interconnected by a Backbone Link via [RFC4919], interconnected by a Backbone Link via Backbone
Backbone Routers, and forming a single IPv6 MultiLink Subnet. Routers, and forming a single IPv6 MultiLink Subnet.
Registration The process during which a wireless Node registers its Registration The process during which a wireless Node registers its
address(es) with the Border Router so the 6BBR can proxy ND for address(es) with the Border Router so the 6BBR can serve as
it over the Backbone. proxy for ND operations over the Backbone.
Binding The state in the 6BBR that associates an IP address with a Binding The association between an IP address with a MAC address, a
MAC address, a port and some other information about the node port and/or other information about the node that owns the IP
that owns the IP address. address.
Registered Node The node for which the registration is performed, Registered Node The node for which the registration is performed,
which owns the fields in the EARO option. and which owns the fields in the EARO option.
Registering Node The node that performs the registration to the Registering Node The node that performs the registration to the
6BBR, either for one of its own addresses, in which case it is 6BBR, which may proxy for the registered node.
Registered Node and indicates its own MAC Address as Source
Link Layer Address (SLLA) in the NS(EARO), or on behalf of a
Registered Node that is reachable over a LLN mesh. In the
latter case, if the Registered Node is reachable from the 6BBR
over a Mesh-Under mesh, the Registering Node indicates the MAC
Address of the Registered Node as SLLA in the NS(EARO).
Otherwise, it is expected that the Registered Device is
reachable over a Route-Over mesh from the Registering Node, in
which case the SLLA in the NS(ARO) is that of the Registering
Node, which causes it to attract the packets from the 6BBR to
the Registered Node and route them over the LLN.
Registered Address The address owned by the Registered Node node Registered Address An address owned by the Registered Node node that
that is being registered. was or is being registered.
legacy and original vs. updated In the context of this
specification, the terms "legacy" and "original" relate to the
support of the RFC 6775 by a 6LN, a 6LR or a 6LBR, whereas the
term "updated" refers to the support of this specification.
4. Updating RFC 6775 4. Updating RFC 6775
This specification extends the Address Registration Option (ARO) This specification introduces the Extended Address Registration
defined in RFC 6775 [RFC6775]; in particular a "T" flag is added that Option (EARO) based on the ARO as defined in RFC 6775 [RFC6775]; in
must be set is NS messages when this specification is used, and particular a "T" flag is added that must be set is NS messages when
echo'ed in NA messages to confirm that the protocol effectively this specification is used, and echoed in NA messages to confirm that
supported. Support for this specification can thus be inferred from the protocol is supported.
the presence of the Extended ARO ("T" flag set) in ND messages.
Support for this specification can thus be inferred from the presence
of the Extended ARO ("T" flag set) in 6LoWPAN ND messages.
The extensions to the ARO option are reported to the Duplicate
Address Request (DAR) and Duplicate Address Confirmation (DAC)
messages, so as to convey the additional information all the way to
the 6LBR, and in turn the 6LBR may proxy the registration using
classical ND over a backbone as illustrated in Figure 1.
6LN 6LR 6LBR 6BBR
| | | |
| NS(EARO) | | |
|--------------->| | |
| | Extended DAR | |
| |-------------->| |
| | | |
| | | proxy NS(EARO) |
| | |--------------->|
| | | | NS(DAD)
| | | | ------>
| | | |
| | | | <wait>
| | | |
| | | proxy NA(EARO) |
| | |<---------------|
| | Extended DAC | |
| |<--------------| |
| NA(EARO) | | |
|<---------------| | |
| | | |
Figure 1: (Re-)Registration Flow
In order to support various types of link layers, this specification In order to support various types of link layers, this specification
also adds recommendation to allow multiple registrations, including also RECOMMENDS to allow multiple registrations, including for
for privacy / temporary addresses, and provides new mechanisms to privacy / temporary addresses, and provides new mechanisms to help
help clean up stale registration states as soon as possible. clean up stale registration states as soon as possible.
A Registering Node that supports this specification will favor A Registering Node that supports this specification SHOULD prefer
registering to a 6LR that indicates support for this specification registering to a 6LR that is found to support this specification, as
over that of RFC 6775 [RFC6775]. discussed in Section 7.1, over a legacy one.
4.1. Extended Address Registration Option 4.1. Extended Address Registration Option (EARO
This specification extends the ARO option that is used for the This specification extends the ARO option that is used for the
process of address registration. The new ARO is referred to as process of address registration. The new ARO is referred to as
Extended ARO (EARO), and its semantics are modified as follows: Extended ARO (EARO), and it is backward compatible with the ARO.
More details on backward compatibility can be found in Section 7.
The address that is being registered with a Neighbor Solicitation The semantics of the ARO are modified as follows:
(NS) with an EARO is now the Target Address, as opposed to the Source
Address as specified in RFC 6775 [RFC6775] (see Section 4.4 for
more). This change enables a 6LBR to use an address of his as source
to the proxy-registration of an address that belongs to a LLN Node to
a 6BBR. This also limits the use of an address as source address
before it is registered and the associated Duplicate Address
Detection (DAD) is complete.
The Unique ID in the EARO option does no more have to be a MAC o The address that is being registered with a Neighbor Solicitation
address (see Section 4.3 for more). This enables in particular the (NS) with an EARO is now the Target Address, as opposed to the
use of a Provable Temporary UID (PT-UID) as opposed to burn-in MAC Source Address as specified in RFC 6775 [RFC6775] (see
address, the PT-UID providing a trusted anchor by the 6LR and 6LBR to Section 4.5). This change enables a 6LBR to use one of its
protect the state associated to the node. addresses as source to the proxy-registration of an address that
belongs to a LLN Node to a 6BBR. This also limits the use of an
address as source address before it is registered and the
associated DAD process is complete.
The specification introduces a Transaction ID (TID) field in the EARO o The Unique ID in the EARO Option is no longer required to be a MAC
(see Section 4.2 for more on TID). The TID MUST be provided by a address (see Section 4.3). This enables in particular the use of
node that supports this specification and a new T flag MUST be set to a Provable Temporary UID (PT-UID) as opposed to burn-in MAC
indicate so. The T bit can be used to determine whether the peer address; the PT-UID provides an anchor trusted by the 6LR and 6LBR
supports this specification. to protect the state associated to the node.
Finally, this specification introduces a number of new Status codes o The specification introduces a Transaction ID (TID) field in the
to help diagnose the cause of a registration failure (more in EARO (see Section 4.2). The TID MUST be provided by a node that
Table 1). supports this specification and a new "T" flag MUST be set to
indicate so.
4.2. Transaction ID o Finally, this specification introduces new status codes to help
diagnose the cause of a registration failure (see Table 1).
The specification expects that the Registered Node can provide a 4.2. Transaction ID
sequence number called Transaction ID (TID) that is incremented with
each re-registration. The TID is used to detect the freshness of the
registration request and useful to detect one single registration by
multiple 6LOWPAN border routers supporting the same large 6LOWPAN, as
is the case for backbone routers (BBR).
For example, when a Registered Node is registered with multiple BBRs sequence number that is incremented with each re-registration. The
in parallel, it is expected that the same TID is used, to enable the TID is used to detect the freshness of the registration request and
6BBRs to correlate the registrations as being a single one, and useful to detect one single registration by multiple 6LOWPAN border
differentiate that situation from a movement. routers (e.g., 6LBRs and 6BBRs) supporting the same 6LOWPAN. The TID
may also be used by the network to track the sequence of movements of
a node in order to route to the current (freshest known) location of
a moving node.
Thus the TID could be tracked to follow the sequence of mobility of a When a Registered Node is registered with multiple BBRs in parallel,
node. The details protocols of mobility verification by the border the same TID SHOULD be used, to enable the 6BBRs to determine that
routers is not part of this specification. the registrations are the same, and distinguish that situation from a
movement.
4.2.1. Comparing TID values 4.2.1. Comparing TID values
The TID is a sequence counter and by design, its operation is the The TID is a sequence counter and its operation is the exact match of
exact match of the path sequence specified in RPL, the IPv6 Routing the path sequence specified in RPL, the IPv6 Routing Protocol for
Protocol for Low-Power and Lossy Networks [RFC6550] specification. Low-Power and Lossy Networks [RFC6550] specification.
In order to keep this document self-contained and yet compatible, the In order to keep this document self-contained and yet compatible, the
text below is an exact copy from section 7.2. "Sequence Counter text below is an exact copy from section 7.2. "Sequence Counter
Operation" of [RFC6550]. A TID is deemed to be fresher than another Operation" of [RFC6550].
when its value is greater per the operations detailed in this
section. A TID is deemed to be fresher than another when its value is greater
per the operations detailed in this section.
The TID range is subdivided in a 'lollipop' fashion ([Perlman83]), The TID range is subdivided in a 'lollipop' fashion ([Perlman83]),
where the values from 128 and greater are used as a linear sequence where the values from 128 and greater are used as a linear sequence
to indicate a restart and bootstrap the counter, and the values less to indicate a restart and bootstrap the counter, and the values less
than or equal to 127 used as a circular sequence number space of size than or equal to 127 used as a circular sequence number space of size
128 as in [RFC1982]. Consideration is given to the mode of operation 128 as in [RFC1982]. Consideration is given to the mode of operation
when transitioning from the linear region to the circular region. when transitioning from the linear region to the circular region.
Finally, when operating in the circular region, if sequence numbers Finally, when operating in the circular region, if sequence numbers
are detected to be too far apart then they are not comparable, as are detected to be too far apart then they are not comparable, as
detailed below. detailed below.
skipping to change at page 8, line 41 skipping to change at page 9, line 41
4. If two sequence numbers are determined to be not comparable, i.e. 4. If two sequence numbers are determined to be not comparable, i.e.
the results of the comparison are not defined, then a node should the results of the comparison are not defined, then a node should
consider the comparison as if it has evaluated in such a way so consider the comparison as if it has evaluated in such a way so
as to give precedence to the sequence number that has most as to give precedence to the sequence number that has most
recently been observed to increment. Failing this, the node recently been observed to increment. Failing this, the node
should consider the comparison as if it has evaluated in such a should consider the comparison as if it has evaluated in such a
way so as to minimize the resulting changes to its own state. way so as to minimize the resulting changes to its own state.
4.3. Owner Unique ID 4.3. Owner Unique ID
The Owner Unique ID (OUID) enables to differentiate a real duplicate The Owner Unique ID (OUID) enables a duplicate address registration
address registration from a double registration or a movement. An ND to be distinguished from a double registration or a movement. An ND
message from the 6BBR over the Backbone that is proxied on behalf of message from the 6BBR over the Backbone that is proxied on behalf of
a Registered Node must carry the most recent EARO option seen for a Registered Node must carry the most recent EARO option seen for
that node. A NS/NA with an EARO and a NS/NA without a EARO thus that node. A NS/NA with an EARO and a NS/NA without a EARO thus
represent different nodes and if they relate to a same target then represent different nodes; if they relate to a same target then an
they reflect an address duplication. The Owner Unique ID can be as address duplication is likely.
simple as a EUI-64 burn-in address, if duplicate EUI-64 addresses are
avoided.
Alternatively, the unique ID can be a cryptographic string that can With RFC 6775, the Owner Unique ID carries an EUI-64 burn-in address,
can be used to prove the ownership of the registration as discussed which implies that duplicate EUI-64 addresses are avoided. With this
in "Address Protected Neighbor Discovery for Low-power and Lossy specification, the Owner Unique ID is allowed to be extended to
different types of identifier, as long as the type is clearly
indicated. For instance, the type can be a cryptographic string and
used to prove the ownership of the registration as discussed in
"Address Protected Neighbor Discovery for Low-power and Lossy
Networks" [I-D.ietf-6lo-ap-nd]. Networks" [I-D.ietf-6lo-ap-nd].
In any fashion, it is recommended that the node stores the unique Id In any fashion, it is recommended that the node stores the unique Id
or the keys used to generate that ID in persistent memory. or the keys used to generate that ID in persistent memory.
Otherwise, it will be prevented to re-register after a reboot that Otherwise, it will be prevented to re-register a same address after a
would cause a loss of memory until the Backbone Router times out the reboot that would cause a loss of memory until the 6LBR times out the
registration. registration.
4.4. Registering the Target Address 4.4. Extended Duplicate Address Messages
This specification changes the behavior of the 6LN and the 6LR so In order to map the new EARO content in the DAR/DAC messages, a new
that the Registered Address is found in the Target Address field of TID field is added to the Extended DAR (EDAR) and the Extended DAC
the NS and NA messages as opposed to the Source Address. (EDAC) messages as a replacement to a Reserved field, and an odd
value of the ICMP Code indicates support for the TID, to transport
the "T" flag.
In order to prepare for new extensions, and though no option had been
earlier defined for the Duplicate Address messages, implementations
SHOULD expect ND options after the main body, and SHOULD ignore them.
As for the EARO, the Extended Duplicate Address messages are backward
compatible with the original versions, and remarks concerning
backwards compatibility between the 6LN and the 6LR apply similarly
between a 6LR and a 6LBR.
4.5. Registering the Target Address
The Registering Node is the node that performs the registration to
the 6BBR. As inherited from RFC 6775, it may be the Registered Node
as well, in which case it registers one of its own addresses, and
indicates its own MAC Address as Source Link Layer Address (SLLA) in
the NS(EARO).
This specification adds the capability to proxy the registration
operation on behalf of a Registered Node that is reachable over a LLN
mesh. In that case, if the Registered Node is reachable from the
6BBR over a Mesh-Under mesh, the Registering Node indicates the MAC
Address of the Registered Node as SLLA in the NS(EARO). If the
Registered Node is reachable over a Route-Over mesh from the
Registering Node, the SLLA in the NS(ARO) is that of the Registering
Node. This enables the Registering Node to attract the packets from
the 6BBR and route them over the LLN to the Registered Node .
In order to enable the latter operation, this specification changes
the behavior of the 6LN and the 6LR so that the Registered Address is
found in the Target Address field of the NS and NA messages as
opposed to the Source Address.
The reason for this change is to enable proxy-registrations on behalf The reason for this change is to enable proxy-registrations on behalf
of other nodes in Route-Over meshes, for instance to enable that a of other nodes, for instance to enable a RPL root to register
RPL root registers addresses on behalf LLN nodes that are deeper in a addresses on behalf of other LLN nodes, as discussed in Appendix B.4.
6TiSCH mesh, as discussed in Appendix B.4. In that case, the In that case, the Registering Node MUST indicate its own address as
Registering Node MUST indicate its own address as source of the ND source of the ND message and its MAC address in the Source Link-Layer
message and its MAC address in the Source Link-Layer Address Option Address Option (SLLAO), since it still expects to receive and route
(SLLAO), since it still expects to get the packets and route them the packets. Since the Registered Address belongs to the Registered
down the mesh. But the Registered Address belongs to another node, Node, that address is indicated in the Target Address field of the NS
the Registered Node, and that address is indicated in the Target message.
Address field of the NS message.
With this convention, a TLLA option indicates the link-layer address With this convention, a TLLA option indicates the link-layer address
of the 6LN that owns the address, whereas the SLLA Option in a NS of the 6LN that owns the address, whereas the SLLA Option in a NS
message indicates that of the Registering Node, which can be the message indicates that of the Registering Node, which can be the
owner device, or a proxy. owner device, or a proxy.
Since the Registering Node is the one that has reachability with the The Registering Node is reachable from the 6LR, and is also the one
6LR, and is the one expecting packets for the 6LN, it makes sense to expecting packets for the 6LN. Therefore, it MUST place its own Link
maintain compatibility with RFC 6775 [RFC6775], and it is REQUIRED Layer Address in the SLLA Option that MUST always be placed in a
that an SLLA Option is always placed in a registration NS(EARO) registration NS(EARO) message. This maintains compatibility with the
message. original 6LoWPAN ND [RFC6775].
4.5. Link-Local Addresses and Registration 4.6. Link-Local Addresses and Registration
Considering that LLN nodes are often not wired and may move, there is Considering that LLN nodes are often not wired and may move, there is
no guarantee that a Link-Local address stays unique between a no guarantee that a Link-Local address stays unique between a
potentially variable and unbounded set of neighboring nodes. potentially variable and unbounded set of neighboring nodes.
Compared to RFC 6775 [RFC6775], this specification only requires that
a Link-Local address is unique from the perspective of the peering
nodes. This simplifies the Duplicate Address Detection (DAD) for
Link-Local addresses, and there is no Duplicate Address Request (DAR)
/ Duplicate Address Confirmation (DAC) exchange between the 6LR and a
6LBR for Link-Local addresses.
Additionally, RFC 6775 [RFC6775] requires that a 6LoWPAN Node (6LN) Compared to RFC 6775, this specification only requires that a Link-
uses an address being registered as the source of the registration Local address is unique from the perspective of the nodes that use it
message. This generates complexities in the 6LR to be able to cope to communicate (e.g. the 6LN and the 6LR in an NS/NA exchange). This
with a potential duplication, in particular for global addresses. To simplifies the DAD process for Link-Local addresses, and there is no
simplify this, a 6LN and a 6LR that conform this specification always exchange of Duplicate Address messages between the 6LR and a 6LBR for
use Link-Local addresses as source and destination addresses for the Link-Local addresses.
registration NS/NA exchange. As a result, the registration is
globally faster, and some of the complexity is removed. According to RFC 6775, a 6LoWPAN Node (6LN) uses the an address being
registered as the source of the registration message. This generates
complexities in the 6LR to be able to cope with a potential
duplication, in particular for global addresses.
To simplify this, a 6LN and a 6LR that conform this specification
MUST always use Link-Local addresses as source and destination
addresses for the registration NS/NA exchange. As a result, the
registration is globally faster, and some of the complexity is
removed.
In more details: In more details:
An exchange between two nodes using Link-Local addresses implies that An exchange between two nodes using Link-Local addresses implies that
they are reachable over one hop and that at least one of the 2 nodes they are reachable over one hop and that at least one of the 2 nodes
acts as a 6LR. A node MUST register a Link-Local address to a 6LR in acts as a 6LR. A node MUST register a Link-Local address to a 6LR in
order to obtain reachability from that 6LR beyond the current order to obtain reachability from that 6LR beyond the current
exchange, and in particular to use the Link-Local address as source exchange, and in particular to use the Link-Local address as source
address to register other addresses, e.g. global addresses. address to register other addresses, e.g. global addresses.
If there is no collision with an address previously registered to If there is no collision with an address previously registered to
this 6LR by another 6LN, then, from the standpoint of this 6LR, this this 6LR by another 6LN, then, from the standpoint of this 6LR, this
Link-Local address is unique and the registration is acceptable. Link-Local address is unique and the registration is acceptable.
Conversely, it may possibly happen that two different 6LRs expose the Conversely, it may possibly happen that two different 6LRs expose the
same Link-Local address but different link-layer addresses. In that same Link-Local address but different link-layer addresses. In that
case, a 6LN may only interact with one of the 6LR so as to avoid case, a 6LN may only interact with one of the 6LRs so as to avoid
confusion in the 6LN neighbor cache. confusion in the 6LN neighbor cache.
The DAD process between the 6LR and a 6LoWPAN Border Router (6LBR), The DAD process between the 6LR and a 6LBR, which is based on an
which is based on a Duplicate Address Request (DAR) / Duplicate exchange of Duplicate Address messages, does not need to take place
Address Confirmation (DAC) exchange as described in RFC 6775 for Link-Local addresses.
[RFC6775], does not need to take place for Link-Local addresses.
It is desired that a 6LR does not need to modify its state associated It is desired that a 6LR does not need to modify its state associated
to the Source Address of an NS(EARO) message. For that reason, when to the Source Address of an NS(EARO) message. For that reason, when
possible, it is RECOMMENDED to use an address that is already possible, it is RECOMMENDED to use an address that is already
registered with a 6LR registered with a 6LR
When registering to a 6LR that conforms this specification, a node When registering to a 6LR that conforms this specification, a node
MUST use a Link-Local address as the source address of the MUST use a Link-Local address as the source address of the
registration, whatever the type of IPv6 address that is being registration, whatever the type of IPv6 address that is being
registered. That Link-Local Address MUST be either already registered. That Link-Local Address MUST be either already
registered, or the address that is being registered. registered, or the address that is being registered.
When a Registering Node does not have an already-Registered Address, When a Registering Node does not have an already-Registered Address,
it MUST register a Link-Local address, using it as both the Source it MUST register a Link-Local address, using it as both the Source
and the Target Address of an NS(EARO) message. In that case, it is and the Target Address of an NS(EARO) message. In that case, it is
RECOMMENDED to use a Link-Local address that is (expected to be) RECOMMENDED to use a Link-Local address that is (expected to be)
globally unique, e.g. derived from a burn-in MAC address. An EARO globally unique, e.g. derived from a burn-in MAC address. An EARO
option in the response NA indicates that the 6LR supports this option in the response NA indicates that the 6LR supports this
specification. specification.
Since there is no DAR/DAC exchange for Link-Local addresses, the 6LR Since there is no Duplicate Address exchange for Link-Local
may answer immediately to the registration of a Link-Local address, addresses, the 6LR may answer immediately to the registration of a
based solely on its existing state and the Source Link-Layer Option Link-Local address, based solely on its existing state and the Source
that MUST be placed in the NS(EARO) message as required in RFC 6775 Link-Layer Option that MUST be placed in the NS(EARO) message as
[RFC6775]. required in RFC 6775 [RFC6775].
A node needs to register its IPv6 Global Unicast IPv6 Addresses (GUA) A node needs to register its IPv6 Global Unicast IPv6 Addresses
to a 6LR in order to obtain a global reachability for these addresses (GUAs) to a 6LR in order to establish global reachability for these
via that 6LR. As opposed to a node that complies to RFC 6775 addresses via that 6LR. When registering with a 6LR that conforms
[RFC6775], a Registering Node registering a GUA does not use that GUA this specification, a Registering Node does not use its GUA as Source
as Source Address for the registration to a 6LR that conforms this Address, in contrast to a node that complies to RFC 6775 [RFC6775].
specification. The DAR/DAC exchange MUST take place for non-Link- For non-Link-Local addresses, the Duplicate Address exchange MUST
Local addresses as prescribed by RFC 6775 [RFC6775]. conform to RFC 6775, but the extended formats described in this
specification for the DAR and the DAC are used to relay the extended
information in the case of an EARO.
4.6. Maintaining the Registration States 4.7. Maintaining the Registration States
This section discusses protocol actions that involve the Registering This section discusses protocol actions that involve the Registering
Node, the 6LR and the 6LBR. It must be noted that the portion that Node, the 6LR and the 6LBR. It must be noted that the portion that
deals with a 6LBR only applies to those addresses that are registered deals with a 6LBR only applies to those addresses that are registered
to it, which, as discussed in Section 4.5, is not the case for Link- to it, which, as discussed in Section 4.6, is not the case for Link-
Local addresses. The registration state includes all data that is Local addresses. The registration state includes all data that is
stored in the router relative to that registration, in particular, stored in the router relative to that registration, in particular,
but not limited to, an NCE in a 6LR. 6LBRs and 6BBRs may store but not limited to, an NCE in a 6LR. 6LBRs and 6BBRs may store
additional registration information in more complex data structures additional registration information in more complex data structures
and use protocols that are out of scope of this document to keep them and use protocols that are out of scope of this document to keep them
synchonized when they are distributed. synchonized when they are distributed.
When its Neighbor Cache is full, a 6LR cannot accept a new When its Neighbor Cache is full, a 6LR cannot accept a new
registration. In that situation, the EARO is returned in a NA registration. In that situation, the EARO is returned in a NA
message with a Status of 2, and the Registering Node may attempt to message with a Status of 2, and the Registering Node may attempt to
register to another 6LR. Conversely the registry in the 6LBR may be register to another 6LR.
saturated, in which case the 6LBR cannot guarantee that a new address
is effectively not a duplicate. In that case, the 6LBR replies to a Conversely the registry in the 6LBR may be saturated, in which case
DAR message with a DAC message that carries a Status code 9 the LBR cannot guarantee that a new address is effectively not a
indicating "6LBR Registry saturated", and the address stays in duplicate. In that case, the 6LBR replies to a EDAR message with a
TENTATIVE state. EDAC message that carries a Status code 9 indicating "6LBR Registry
saturated", and the address stays in TENTATIVE state. Note: this
code is used by 6LBRs instead of Status 2 when responding to a
Duplicate Address message exchange and passed on to the Registering
Node by the 6LR. There is no point for the node to retry this
registration immediately via another 6LR, since the problem is global
to the network. The node may either abandon that address, deregister
other addresses first to make room, or keep the address in TENTATIVE
state and retry later.
A node renews an existing registration by repeatedly sending NS(EARO) A node renews an existing registration by repeatedly sending NS(EARO)
messages for the Registered Address. In order to refresh the messages for the Registered Address. In order to refresh the
registration state in the 6LBR, these registrations MUST be reported registration state in the 6LBR, these registrations MUST be reported
to the 6LBR. to the 6LBR.
A node that ceases to use an address SHOULD attempt to deregister A node that ceases to use an address SHOULD attempt to deregister
that address from all the 6LRs to which it has registered the that address from all the 6LRs to which it has registered the
address, which is achieved using an NS(EARO) message with a address, which is achieved using an NS(EARO) message with a
Registration Lifetime of 0. Registration Lifetime of 0.
A node that moves away from a particular 6LR SHOULD attempt to A node that moves away from a particular 6LR SHOULD attempt to
deregister all of its addresses registered to that 6LR and register deregister all of its addresses registered to that 6LR and register
to a new 6LR with an incremented TID. to a new 6LR with an incremented TID. When/if the node shows up
elsewhere, an used to clean up the state in the previous location.
For instance, the "Moved" status can be used by a 6BBR in a NA(EARO)
message to indicate that the ownership of the proxy state on the
Backbone was transferred to another 6BBR, as the consequence of a
movement of the device. The receiver of the message SHOULD propagate
the status down the chain towards the Registered node and clean up
its state.
Upon receiving a NS(EARO) message with a Registration Lifetime of 0 Upon receiving a NS(EARO) message with a Registration Lifetime of 0
and determining that this EARO is the freshest for a given NCE (see and determining that this EARO is the freshest for a given NCE (see
Section 4.2), a 6LR cleans up its NCE. If the address was registered Section 4.2), a 6LR cleans up its NCE. If the address was registered
to the 6LBR, then the 6LR MUST report to the 6LBR, through a DAR/DAC to the 6LBR, then the 6LR MUST report to the 6LBR, through a
exchange with the 6LBR, or an alternate protocol, indicating the null Duplicate Address exchange with the 6LBR, or an alternate protocol,
Registration Lifetime and the latest TID that this 6LR is aware of. indicating the null Registration Lifetime and the latest TID that
this 6LR is aware of.
Upon the DAR message, the 6LBR evaluates if this is the freshest EARO Upon the Extended DAR message, the 6LBR evaluates if this is the
it has received for that particular registry entry. If it is, then freshest TID it has received for that particular registry entry. If
the entry is scheduled to be removed, and the DAR is answered with a it is, then the entry is scheduled to be removed, and the EDAR is
DAC message bearing a Status of 0 "Success". If it is not the answered with a EDAC message bearing a Status of 0 "Success". If it
freshest, then a Status 2 "Moved" is returned instead, and the is not the freshest, then a Status 3 "Moved" is returned instead, and
existing entry is conserved. the existing entry is conserved.
Upon timing out a registration, a 6LR removes silently its binding Upon timing out a registration, a 6LR removes silently its binding
cache entry, and a 6LBR schedules its entry to be removed. cache entry, and a 6LBR schedules its entry to be removed.
When an address is scheduled to be removed, the 6LBR SHOULD conserve When an address is scheduled to be removed, the 6LBR SHOULD keep its
its entry in a DELAY state for a configurable period of time, so as entry in a DELAY state for a configurable period of time, so as to
to protect a mobile node that deregistered from one 6LR and did not protect a mobile node that deregistered from one 6LR and did not
register yet to a new one, or the new registration did not reach yet register yet to a new one, or the new registration did not reach yet
the 6LBR due to propagation delays in the network. Once the DELAY the 6LBR due to propagation delays in the network. Once the DELAY
time is passed, the 6LBR removes silently its entry. time is passed, the 6LBR removes silently its entry.
5. Detecting Enhanced ARO Capability Support 5. Detecting Enhanced ARO Capability Support
The nodes and routers in a network may be mixed and if a node wants The "Generic Header Compression for IPv6 over 6LoWPANs" [RFC7400]
to use EARO feature for address registration, it has to find a router introduces the 6LoWPAN Capability Indication Option (6CIO) to
which supports it. Thus all implementations with EARO option MUST indicate a node's capabilities to its peers. This specification
provide the capability detection method using 6CIO option to support extends the format defined in RFC 7400 to signal the support for
both types of registrations (ARO and EARO) as described in later EARO, as well as the node's capability to act as a 6LR, 6LBR and
sections. Moreover, any new implementation of 6LOWPAN is also
RECOMMENDED to support 6LoWPAN Capability Indication option(6CIO)in
general.
RFC 7400 [RFC7400] introduces the 6LoWPAN Capability Indication
Option (6CIO) to indicate a node's capabilities to its peers. This
specification extends the format defined in RFC 7400 to signal the
support for EARO, as well as the capability to act as a 6LR, 6LBR and
6BBR. 6BBR.
With RFC 7400 [RFC7400], the 6CIO is typically sent Router With RFC 7400, the 6CIO is typically sent in a Router Solicitation
Solicitation (RS) messages. When used to signal the capabilities (RS) message. When used to signal the capabilities above per this
above per this specification, the 6CIO is typically present Router specification, the 6CIO is typically present in Router Advertisement
Advertisement (RA) messages but can also be present in RS, Neighbor (RA) messages but can also be present in RS, Neighbor Solicitation
Solicitation (NS) and Neighbor Advertisement (NA) messages. (NS) and Neighbor Advertisement (NA) messages.
6. Updated ND Options 6. Extended ND Options And Messages
This specification does not introduce new options, but it modifies This specification does not introduce new options, but it modifies
existing ones and updates the associated behaviors as follow: existing ones and updates the associated behaviors as specified in
the following subsections.
6.1. The Enhanced Address Registration Option (EARO) 6.1. Enhanced Address Registration Option (EARO)
The Address Registration Option (ARO) is defined in section 4.1. of
[RFC6775].
The Enhanced Address Registration Option (EARO) is intended to be The Enhanced Address Registration Option (EARO) is intended to be
used as a replacement to the ARO option within Neighbor Discovery NS used as a replacement to the ARO option within Neighbor Discovery NS
and NA messages between a LLN node and its 6LoWPAN Router (6LR), as and NA messages between a 6LN and its 6LR. Conversely, the Extended
well as in Duplicate Address Request (DAR) and the Duplicate Address Duplicate Address messages, EDAR and EDAC, are to be used in
Confirmation (DAC) messages between 6LRs and 6LBRs in LLNs meshes replacement of the DAR and DAC messages so as to transport the new
such as 6TiSCH networks. information between 6LRs and 6LBRs across LLNs meshes such as 6TiSCH
networks.
An NS message with an EARO option is a registration if and only if it An NS message with an EARO option is a registration if and only if it
also carries an SLLAO option. The EARO option also used in NS and NA also carries an SLLAO option. The EARO option also used in NS and NA
messages between Backbone Routers over the Backbone link to sort out messages between Backbone Routers over the Backbone link to sort out
the distributed registration state, and in that case, it does not the distributed registration state; in that case, it does not carry
carry the SLLAO option and is not confused with a registration. the SLLAO option and is not confused with a registration.
When using the EARO option, the address being registered is found in When using the EARO option, the address being registered is found in
the Target Address field of the NS and NA messages. This differs the Target Address field of the NS and NA messages. This differs
from 6LoWPAN ND RFC 6775 [RFC6775] which specifies that the address from 6LoWPAN ND RFC 6775 [RFC6775] which specifies that the address
being registered is the source of the NS. being registered is the source of the NS.
The EARO extends the ARO and is recognized by the "T" flag set. The The EARO extends the ARO and is recognized by the "T" flag set. The
format of the EARO option is as follows: format of the EARO option is as follows:
0 1 2 3 0 1 2 3
skipping to change at page 13, line 51 skipping to change at page 16, line 17
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Status | Reserved | | Type | Length = 2 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T| TID | Registration Lifetime | | Reserved |T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Owner Unique ID (EUI-64 or equivalent) + + Owner Unique ID (EUI-64 or equivalent) +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: EARO Figure 2: EARO
Option Fields Option Fields
Type: 33 Type: 33
Length: 8-bit unsigned integer. Length: 8-bit unsigned integer. The length of the option in
units of 8 bytes. Always 2.
Status: 8-bit unsigned integer. Indicates the status of a Status: 8-bit unsigned integer. Indicates the status of a
registration in the NA response. MUST be set to 0 in registration in the NA response. MUST be set to 0 in
NS messages. See Table 1 below. NS messages. See Table 1 below.
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| Value | Description | | Value | Description |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 0..2 | See RFC 6775 [RFC6775]. Note that a Status of 1 | | 0..2 | See RFC 6775 [RFC6775]. Note: a Status of 1 "Duplicate |
| | "Duplicate Address" applies to the Registered Address. If | | | Address" applies to the Registered Address. If the Source |
| | the Source Address conflicts with an existing | | | Address conflicts with an existing registration, |
| | registration, "Duplicate Source Address" should be used. | | | "Duplicate Source Address" should be used. |
| | | | | |
| 3 | Moved: The registration fails because it is not the | | 3 | Moved: The registration fails because it is not the |
| | freshest. This Status indicates that the registration is | | | freshest. This Status indicates that the registration is |
| | rejected because another more recent registration was | | | rejected because another more recent registration was |
| | done, as indicated by a same OUI and a more recent TID. | | | done, as indicated by a same OUI and a more recent TID. |
| | One possible cause is a stale registration that has | | | One possible cause is a stale registration that has |
| | progressed slowly in the network and was passed by a more | | | progressed slowly in the network and was passed by a more |
| | recent one. It could also indicate a OUI collision. | | | recent one. It could also indicate a OUI collision. |
| | | | | |
| 4 | Removed: The binding state was removed. This may be | | 4 | Removed: The binding state was removed. This may be |
| | placed in an asynchronous NS(ARO) message, or as the | | | placed in an asynchronous NS(ARO) message, or as the |
| | rejection of a proxy registration to a Backbone Router | | | rejection of a proxy registration to a Backbone Router |
| | | | | |
| 5 | Proof requested: The Registering Node is challenged for | | 5 | Validation Requested: The Registering Node is challenged |
| | owning the Registered Address or for being an acceptable | | | for owning the Registered Address or for being an |
| | proxy for the registration. This Status is expected in | | | acceptable proxy for the registration. This Status is |
| | asynchronous messages from a registrar (6LR, 6LBR, 6BBR) | | | expected in asynchronous messages from a registrar (6LR, |
| | to indicate that the registration state is removed, for | | | 6LBR, 6BBR) to indicate that the registration state is |
| | instance due to time out of a lifetime, or a movement. | | | removed, for instance due to a movement of the device. |
| | The receiver of the NA is the device that has performed a |
| | registration that is now stale and it should clean up its |
| | state. |
| | | | | |
| 6 | Duplicate Source Address: The address used as source of | | 6 | Duplicate Source Address: The address used as source of |
| | the NS(ARO) conflicts with an existing registration. | | | the NS(ARO) conflicts with an existing registration. |
| | | | | |
| 7 | Invalid Source Address: The address used as source of the | | 7 | Invalid Source Address: The address used as source of the |
| | NS(ARO) is not a Link-Local address as prescribed by this | | | NS(ARO) is not a Link-Local address as prescribed by this |
| | document. | | | document. |
| | | | | |
| 8 | Registered Address topologically incorrect: The address | | 8 | Registered Address topologically incorrect: The address |
| | being registered is not usable on this link, e.g. it is | | | being registered is not usable on this link, e.g. it is |
| | not topologically correct | | | not topologically correct |
| | | | | |
| 9 | 6LBR Registry saturated: A new registration cannot be | | 9 | 6LBR Registry saturated: A new registration cannot be |
| | accepted because the 6LBR Registry is saturated. | | | 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 |
| | passed on to the Registering Node by the 6LR. |
| | | | | |
| 10 | Incorrect proof: The proof of ownership of the registered | | 10 | Validation Failed: The proof of ownership of the |
| | address is not correct. | | | registered address is not correct. |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Table 1: EARO Status Table 1: EARO Status
Reserved: This field is unused. It MUST be initialized to zero Reserved: This field is unused. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
T: One bit flag. Set if the next octet is a used as a T: One bit flag. Set if the next octet is a used as a
TID. TID.
TID: 1-byte integer; a transaction id that is maintained TID: 1-byte integer; a transaction id that is maintained
by the node and incremented with each transaction. by the node and incremented with each transaction.
it is recommended that the node maintains the TID in The node SHOULD maintain the TID in a persistent
a persistent storage. storage.
Registration Lifetime: 16-bit integer; expressed in minutes. 0 Registration Lifetime: 16-bit integer; expressed in minutes. 0
means that the registration has ended and the means that the registration has ended and the
associated state should be removed. associated state should be removed.
Owner Unique Identifier (OUI): A globally unique identifier for the Owner Unique Identifier (OUI): A globally unique identifier for the
node associated. This can be the EUI-64 derived IID node associated. This can be the EUI-64 derived IID
of an interface, or some provable ID obtained of an interface, or some provable ID obtained
cryptographically. cryptographically.
Note: the code "6LBR Registry saturated" is used by 6LBRs instead of 6.2. Extended Duplicate Address Message Formats
Status 2 when responding to a DAR/DAC exchange and passed on to the
Registering Node by the 6LR. There is no point for the node to retry
this registration immediately via another 6LR, since the problem is
global to the network. The node may either abandon that address,
deregister other addresses first to make room, or keep the address in
TENTATIVE state and retry later.
6.2. New 6LoWPAN capability Bits in the Capability Indication Option The Duplicate Address Request (DAR) and the Duplicate Address
Confirmation (DAC) messages are defined in section 4.4. of [RFC6775].
Those messages follow a common base format, which enables information
from the ARO to be transported over multiple hops.
This specification defines a number of capability bits in the CIO The Duplicate Address Messages are extended to adapt to the Extended
that was introduced by RFC 7400 [RFC7400]. ARO format, as follows:
Support for this specification is indicated by setting the "E" flag 0 1 2 3
in a CIO option. Routers that are capable of acting as 6LR, 6LBR and 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
6BBR SHOULD set the L, B and P flags, respectively. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Unique ID (EUI-64 or equivalent) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Registered Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Duplicate Address Messages Format
Modified Message Fields
Code: The ICMP Code as defined in [RFC4443]. The ICMP Code
MUST be set to 1 with this specification. An odd
value of the ICMP Code indicates that the TID field
is present and obeys this specification.
TID: 1-byte integer; same definition and processing as the
TID in the EARO option as defined in Section 6.1.
Owner Unique Identifier (OUI): 8 bytes; same definition and
processing as the OUI in the EARO option as defined
in Section 6.1.
6.3. New 6LoWPAN Capability Bits in the Capability Indication Option
This specification defines a number of capability bits in the 6CIO
that was introduced by RFC 7400 for use in IPv6 ND RA messages.
Routers that support this specification SHOULD set the "E" flag and
6LN SHOULD favor 6LR routers that support this specification over
those that do not. Routers that are capable of acting as 6LR, 6LBR
and 6BBR SHOULD set the "L", "B" and "P" flags, respectively. In
particular, the function 6LR is usually collocated with that of 6LBR.
Those flags are not mutually exclusive and if a router is capable of Those flags are not mutually exclusive and if a router is capable of
multiple roles, it SHOULD set all the related flags. running multiple functions, it SHOULD set all the related flags.
0 1 2 3 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 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 |_____________________|L|B|P|E|G| | Type | Length = 1 | Reserved |L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: New capability Bits L, B, P, E in the CIO Figure 4: New capability Bits L, B, P, E in the 6CIO
Option Fields Option Fields
Type: 36 Type: 36
L: Node is a 6LR, it can take registrations. L: Node is a 6LR, it can take registrations.
B: Node is a 6LBR. B: Node is a 6LBR.
P: Node is a 6BBR, proxying for nodes on this link. P: Node is a 6BBR, proxying for nodes on this link.
E: This specification is supported and applied. E: This specification is supported and applied.
7. Backward Compatibility 7. Backward Compatibility
7.1. Discovering the capabilities of an ND peer 7.1. Discovering the capabilities of an ND peer
7.1.1. Using the E Flag in the CIO 7.1.1. Using the E Flag in the 6CIO Option
If the CIO is used in an ND message, then the "E" Flag MUST be set by
the sending node if supports this specification.
It is RECOMMENDED that a router that supports this specification If the 6CIO is used in an ND message and the sending node supports
indicates so with a CIO option, but this might not be practical if this specification, then the "E" Flag MUST be set.
the link-layer MTU is too small.
If the Registering Node receives a CIO in a RA, then the setting of A router that supports this specification SHOULD indicate that with a
the E" Flag indicates whether or not this specification is supported. 6CIO Option, but this might not be practical if the link-layer MTU is
too small.
A node which does not implement this draft or parse 6CIO option, MUST If the Registering Node (RN) receives a CIO in a Router Advertisement
ignore the packet and the sender of option SHOULD use legacy message, then the setting of the "E" Flag indicates whether or not
registration method according to RFC 6775 [RFC6775] after a timeout this specification is supported. RN SHOULD favor a router that
period. supports this specification over those that do not.
7.1.2. Using the T Flag in the EARO 7.1.2. Using the T Flag in the EARO
One alternate way for a 6LN to discover the router's capabilities to One alternate way for a 6LN to discover the router's capabilities to
first register a Link Local address, placing the same address in the first register a Link Local address, placing the same address in the
Source and Target Address fields of the NS message, and setting the Source and Target Address fields of the NS message, and setting the
"T" Flag. The node may for instance register an address that is "T" Flag. The node may for instance register an address that is
based on EUI-64. For such address, DAD is not required and using the based on EUI-64. For such address, DAD is not required and using the
SLLAO option in the NS is actually more amenable with existing ND SLLAO option in the NS is actually more consistent with existing ND
specifications such as the "Optimistic Duplicate Address Detection specifications such as the "Optimistic Duplicate Address Detection
(DAD) for IPv6" [RFC4429]. Once that first registration is complete, (DAD) for IPv6" [RFC4429].
the node knows from the setting of the "T" Flag in the response
whether the router supports this specification. If this is verified, Once that first registration is complete, the node knows from the
the node may register other addresses that it owns, or proxy-register setting of the "T" Flag in the response whether the router supports
addresses on behalf some another node, indicating those addresses this specification. If support is verified, the node may register
being registered in the Target Address field of the NS messages, other addresses that it owns, or proxy-register addresses on behalf
while using one of its own, already registered, addresses as source. some another node, indicating those addresses being registered in the
Target Address field of the NS messages, while using one of its own
previously registered addresses as source.
A node that supports this specification MUST always use an EARO as a A node that supports this specification MUST always use an EARO as a
replacement to an ARO in its registration to a router. This is replacement to an ARO in its registration to a router. This is
harmless since the "T" flag and TID field are reserved in RFC 6775 harmless since the "T" flag and TID field are reserved in RFC 6775
[RFC6775] are ignored by a legacy router. A router that supports are ignored by a legacy router. A router that supports this
this specification answers to an ARO with an ARO and to an EARO with specification answers an ARO with an ARO and answers an EARO with an
an EARO. EARO.
This specification changes the behavior of the peers in a This specification changes the behavior of the peers in a
registration flows. To enable backward compatibility, a node that registration flows. To enable backward compatibility, a 6LB that
registers to a router that is not known to support this specification registers to a 6LR that is not known to support this specification
MUST behave as prescribed by RFC 6775. Once the router is known to MUST behave in a manner that is compatible with RFC 6775. A 6LN can
support this specification, the node MUST obey this specification. achieve that by sending a NS(EARO) message with a Link-Local Address
used as both Source and Target Address, as described in Section 4.6.
Once the 6LR is known to support this specification, the 6LN MUST
obey this specification.
7.2. Legacy 6LoWPAN Node 7.2. Legacy 6LoWPAN Node
A legacy 6LN will use the Registered Address as source and will not A legacy 6LN will use the Registered Address as source and will not
use an EARO option. In order to be backward compatible, an updated use an EARO option. An updated 6LR MUST accept that registration if
6LR needs to accept that registration if it is valid per the RFC 6775 it is valid per RFC 6775, and it MUST manage the binding cache
[RFC6775] specification, and manage the binding cache accordingly. accordingly. The updated 6LR MUST then use the original Duplicate
Address messages as specified in RFC 6775 to indicate to the 6LBR
that the TID is not present in the messages.
The main difference with RFC 6775 is that DAR/DAC exchange for DAD The main difference with RFC 6775 is that Duplicate Address exchange
may be avoided for Link-Local addresses. Additionally, the 6LR for DAD is avoided for Link-Local addresses. In any case, the 6LR
SHOULD use an EARO in the reply, and may use any of the Status codes SHOULD use an EARO in the reply, and may use any of the Status codes
defined in this specification. defined in this specification.
7.3. Legacy 6LoWPAN Router 7.3. Legacy 6LoWPAN Router
The first registration by a an updated 6LN is for a Link-Local The first registration by an updated 6LN MUST be for a Link-Local
address, using that Link-Local address as source. A legacy 6LR will address, using that Link-Local address as source. A legacy 6LR will
not make a difference and accept -or reject- that registration as if not make a difference and accept -or reject- that registration as if
the 6LN was a legacy node. the 6LN was a legacy node.
An updated 6LN will always use an EARO option in the registration NS An updated 6LN will always use an EARO option in the registration NS
message, whereas a legacy 6LR will always reply with an ARO option in message, whereas a legacy 6LR will always reply with an ARO option in
the NA message. So from that first registration, the updated 6LN can the NA message. So from that first registration, the updated 6LN can
figure whether the 6LR supports this specification or not. figure whether the 6LR supports this specification or not.
When facing a legacy 6LR, an updated 6LN may attempt to find an After detecting a legacy 6LR, an updated 6LN may attempt to find an
alternate 6LR that is updated. In order to be backward compatible, alternate 6LR that is updated. In order to be backward compatible,
based on the discovery that a 6LR is legacy, the 6LN needs to after detecting that a 6LR is legacy, the 6LN MUST adhere to RFC 6775
fallback to legacy behavior and source the packet with the Registered in future protocol exchanges with that 6LR, and source the packet
Address. with the Registered Address.
The main difference is that the updated 6LN SHOULD use an EARO in the Note that the updated 6LN SHOULD use an EARO in the request
request regardless of the type of 6LR, legacy or updated regardless of the type of 6LR, legacy or updated, which implies that
the 'T' flag is set.
If an updated 6LN moves from an updated 6LR to a legacy 6LR, the
legacy 6LR will send a legacy DAR message, which can not be compared
with an updated one for freshness.
Allowing legacy DAR messages to replace a state established by the
updated protocol in the 6LBR would be an attack vector and that
cannot be the default behavior.
But if legacy and updated 6LRs coexist temporarily in a network, then
it makes sense for an administrator to install a policy that allows
so, and the capability to install such a policy should be
configurable in a 6LBR though it is out of scope for this document.
7.4. Legacy 6LoWPAN Border Router 7.4. Legacy 6LoWPAN Border Router
With this specification, the DAR/DAC transports an EARO option as With this specification, the Duplicate Address messages are extended
opposed to an ARO option. As described for the NS/NA exchange, 6LBR to transport the EARO information. Similarly to the NS/NA exchange,
devices that support this specification always use an EARO option and updated 6LBR devices always use the Extended Duplicate Address
all the associated behavior. A legacy 6LBR will accept and process messages and all the associated behavior so they can amlways be
an EARO option as if it was an ARO option, so the legacy support of differentiated from legacy ones.
DAD will function. But considering that there are a lot fewer 6LBR
than 6LR, the expectation is that they are upgraded as soon as Note that a legacy 6LBR will accept and process an EDAR message as if
devices that implement this specification are deployed. it was an original one, so the original support of DAD is preserved.
8. Security Considerations 8. Security Considerations
This specification extends RFC 6775 [RFC6775], and the security This specification extends RFC 6775 [RFC6775], and the security
section of that draft also applies to this as well. In particular, section of that draft also applies to this as well. In particular,
it is expected that the link layer is sufficiently protected to it is expected that the link layer is sufficiently protected to
prevent a rogue access, either by means of physical or IP security on prevent a rogue access, either by means of physical or IP security on
the Backbone Link and link layer cryptography on the LLN. This the Backbone Link and link layer cryptography on the LLN. This
specification also expects that the LLN MAC provides secure unicast specification also expects that the LLN MAC provides secure unicast
to/from the Backbone Router and secure Broadcast from the Backbone to/from the Backbone Router and secure Broadcast from the Backbone
Router in a way that prevents tempering with or replaying the RA Router in a way that prevents tempering with or replaying the RA
messages. messages.
This specification recommends to using privacy techniques (more in This specification recommends to using privacy techniques (see
section Section 9, and protection against address theft such as Section 9, and protection against address theft such as provided by
provided by "Address Protected Neighbor Discovery for Low-power and "Address Protected Neighbor Discovery for Low-power and Lossy
Lossy Networks" [I-D.ietf-6lo-ap-nd], which guarantees the ownership Networks" [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the
of the Registered Address using a cryptographic OUID. Registered Address using a cryptographic OUID.
The registration mechanism may be used by a rogue node to attack the The registration mechanism may be used by a rogue node to attack the
6LR or the 6LBR with a Denial-of-Service attack against the registry. 6LR or the 6LBR with a Denial-of-Service attack against the registry.
It may also happen that the registry of a 6LR or a 6LBR is saturated It may also happen that the registry of a 6LR or a 6LBR is saturated
and cannot take any more registration, which effectively denies the and cannot take any more registration, which effectively denies the
requesting a node the capability to use a new address. In order to requesting a node the capability to use a new address. In order to
alleviate those concerns, Section 4.6 provides a number of alleviate those concerns, Section 4.7 provides a number of
recommendations that ensure that a stale registration is removed as recommendations that ensure that a stale registration is removed as
soon as possible from the 6LR and 6LBR. In particular, this soon as possible from the 6LR and 6LBR. In particular, this
specification recommends that: specification recommends that:
o A node that ceases to use an address should attempt to deregister o A node that ceases to use an address SHOULD attempt to deregister
that address from all the 6LRs to which it is registered. The that address from all the 6LRs to which it is registered. The
flow is propagated to the 6LBR when needed, and a sequence number flow is propagated to the 6LBR when needed, and a sequence number
is used to make sure that only the freshest command is acted upon. is used to make sure that only the freshest command is acted upon.
o The nodes should be configured with a Registration Lifetime that o The Registration lifetimes SHOULD be individually configurable for
reflects their expectation of how long they will use the address each address or group of addresses. The nodes SHOULD be
with the 6LR to which it is registered. In particular, use cases configured with a Registration Lifetime that reflects their
that involve mobility or rapid address changes should use expectation of how long they will use the address with the 6LR to
lifetimes that are homogeneous with the expectation of presence. which it is registered. In particular, use cases that involve
mobility or rapid address changes SHOULD use lifetimes that are
larger yet of a same order as the duration of the expectation of
presence.
o The router (6LR or 6LBR) should be configurable so as to limit the o The router (6LR or 6LBR) SHOULD be configurable so as to limit the
number of addresses that can be registered by a single node, as number of addresses that can be registered by a single node, as
identified at least by MAC address and preferably by security identified at least by MAC address and preferably by security
credentials. When that maximum is reached, the router should use credentials. When that maximum is reached, the router should use
a Least-Recently-Used (LRU) logic so as to clean up the addresses a Least-Recently-Used (LRU) logic so as to clean up the addresses
that were not used for the longest time, keeping at least one that were not used for the longest time, keeping at least one
Link-Local address, and attempting to keep one or more stable Link-Local address, and attempting to keep one or more stable
addresses if such can be recognized, e.g. from the way the IID is addresses if such can be recognized, e.g. from the way the IID is
formed or because they are used over a much longer time span than formed or because they are used over a much longer time span than
other (privacy, shorter-lived) addresses. other (privacy, shorter-lived) addresses. The address lifetimes
SHOULD be individually configurable.
o Administrators should take great care to deploy adequate numbers
of 6LR to cover the needs of the nodes in their range, so as to
avoid a situation of starving nodes. It is expected that the 6LBR
that serves a LLN is a more capable node then the average 6LR, but
in a network condition where it may become saturated, a particular
deployment should distribute the 6LBR functionality, for instance
by leveraging a high speed Backbone and Backbone Routers to
aggregate multiple LLNs into a larger subnet.
When the ownership of the OUID cannot be assessed, this specification o In order to avoid denial of registration for the lack of
limits the cases where the OUID and the TID are multicasted, and resources, administrators SHOULD take great care to deploy
obfuscates them in responses to attempts to take over an address. adequate numbers of 6LRs to cover the needs of the nodes in their
range, so as to avoid a situation of starving nodes. It is
expected that the 6LBR that serves a LLN is a more capable node
then the average 6LR, but in a network condition where it may
become saturated, a particular deployment SHOULD distribute the
6LBR functionality, for instance by leveraging a high speed
Backbone and Backbone Routers to aggregate multiple LLNs into a
larger subnet.
The LLN nodes depend on the 6LBR and the 6BBR for their operation. A The LLN nodes depend on the 6LBR and the 6BBR for their operation. A
trust model must be put in place to ensure that the right devices are trust model must be put in place to ensure that the right devices are
acting in these roles, so as to avoid threats such as black-holing, acting in these roles, so as to avoid threats such as black-holing,
or bombing attack whereby an impersonated 6LBR would destroy state in or bombing attack whereby an impersonated 6LBR would destroy state in
the network by using the "Removed" Status code. the network by using the "Removed" Status code.
9. Privacy Considerations 9. Privacy Considerations
As indicated in section Section 2, this protocol does not aim at As indicated in section Section 2, this protocol does not aim at
limiting the number of IPv6 addresses that a device can form. A host limiting the number of IPv6 addresses that a device can form. A host
should be able to form and register any address that is topologically should be able to form and register any address that is topologically
correct in the subnet(s) advertised by the 6LR/6LBR. correct in the subnet(s) advertised by the 6LR/6LBR.
This specification does not mandate any particular way for forming This specification does not mandate any particular way for forming
IPv6 addresses, but it recognizes that use of EUI-64 for forming the IPv6 addresses, but it discourages using EUI-64 for forming the
Interface ID in the Link-Local address prevents the usage of "SEcure Interface ID in the Link-Local address because this method prevents
Neighbor Discovery (SEND)" [RFC3971] and "Cryptographically Generated the usage of "SEcure Neighbor Discovery (SEND)" [RFC3971] and
Addresses (CGA)" [RFC3972], and that of address privacy techniques. "Cryptographically Generated Addresses (CGA)" [RFC3972], and that of
address privacy techniques.
"Privacy Considerations for IPv6 Adaptation-Layer Mechanisms" "Privacy Considerations for IPv6 Adaptation-Layer Mechanisms"
[RFC8065] addresses why privacy is important and how to form such [RFC8065] explains why privacy is important and how to form such
addresses. All implementations and deployment must consider the addresses. All implementations and deployment must consider the
option of privacy addresses in their own environment. Also future option of privacy addresses in their own environment. Also future
specifications involving 6LOWPAN Neighbor Discovery should consult specifications involving 6LOWPAN Neighbor Discovery should consult
"Recommendation on Stable IPv6 Interface Identifiers" [RFC8064] for "Recommendation on Stable IPv6 Interface Identifiers" [RFC8064] for
default interface identifaction. default interface identifaction.
10. IANA Considerations 10. IANA Considerations
IANA is requested to create a new subregistry for "ARO Flags" under IANA is requested to make a number of changes under the "Internet
the "Internet Control Message Protocol version 6 (ICMPv6) Control Message Protocol version 6 (ICMPv6) Parameters" registry, as
Parameters". This specification defines 8 positions, bit 0 to bit 7, follows.
and assigns bit 7 for the "T" flag in Section 6.1. The policy is
"IETF Review" or "IESG Approval" [RFC8126]. The initial content of 10.1. ARO Flags
the registry is as shown in Table 2.
IANA is requested to create a new subregistry for "ARO Flags". This
specification defines 8 positions, bit 0 to bit 7, and assigns bit 7
for the 'T' flag in Section 6.1. The policy is "IETF Review" or
"IESG Approval" [RFC8126]. The initial content of the registry is as
shown in Table 2.
New subregistry for ARO Flags under the "Internet Control Message New subregistry for ARO Flags under the "Internet Control Message
Protocol version 6 (ICMPv6) Parameters" Protocol version 6 (ICMPv6) [RFC4443] Parameters"
+------------+--------------+-----------+ +------------+--------------+-----------+
| ARO Status | Description | Document | | ARO Status | Description | Document |
+------------+--------------+-----------+ +------------+--------------+-----------+
| 0..6 | Unassigned | | | 0..6 | Unassigned | |
| | | | | 7 | 'T' Flag | RFC This |
| 7 | "T" Flag | RFC This |
+------------+--------------+-----------+ +------------+--------------+-----------+
Table 2: new ARO Flags Table 2: new ARO Flags
IANA is requested to make additions to existing registries as 10.2. ICMP Codes
follows:
IANA is requested to create a new entry in the ICMPv6 "Code" Fields
subregistry of the Internet Control Message Protocol version 6
(ICMPv6) Parameters for the ICMP codes related to the ICMP type 157
and 158 Duplicate Address Request (shown in Table 3) and Confirmation
(shown in Table 4), respectively, as follows:
New entries for ICMP types 157 DAR message
+------+----------------------+------------+
| Code | Name | Reference |
+------+----------------------+------------+
| 0 | Original DAR message | RFC 6775 |
| 1 | Extended DAR message | RFC This |
+------+----------------------+------------+
Table 3: new ICMPv6 Code Fields
New entries for ICMP types 158 DAC message
+------+----------------------+------------+
| Code | Name | Reference |
+------+----------------------+------------+
| 0 | Original DAC message | RFC 6775 |
| 1 | Extended DAC message | RFC This |
+------+----------------------+------------+
Table 4: new ICMPv6 Code Fields
10.3. New ARO Status values
IANA is requested to make additions to the Address Registration
Option Status Values Registry as follows:
Address Registration Option Status Values Registry Address Registration Option Status Values Registry
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| ARO Status | Description | Document | | ARO Status | Description | Document |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
| 3 | Moved | RFC This | | 3 | Moved | RFC This |
| | | |
| 4 | Removed | RFC This | | 4 | Removed | RFC This |
| | | | | 5 | Validation Requested | RFC This |
| 5 | Proof requested | RFC This |
| | | |
| 6 | Duplicate Source Address | RFC This | | 6 | Duplicate Source Address | RFC This |
| | | |
| 7 | Invalid Source Address | RFC This | | 7 | Invalid Source Address | RFC This |
| | | |
| 8 | Registered Address topologically | RFC This | | 8 | Registered Address topologically | RFC This |
| | incorrect | | | | incorrect | |
| | | |
| 9 | 6LBR registry saturated | RFC This | | 9 | 6LBR registry saturated | RFC This |
| | | | | 10 | Validation Failed | RFC This |
| 10 | Incorrect proof | RFC This |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
Table 3: New ARO Status values Table 5: New ARO Status values
10.4. New 6LoWPAN capability Bits
IANA is requested to make additions to the Subregistry for "6LoWPAN
capability Bits" as follows:
Subregistry for "6LoWPAN capability Bits" under the "Internet Control Subregistry for "6LoWPAN capability Bits" under the "Internet Control
Message Protocol version 6 (ICMPv6) Parameters" Message Protocol version 6 (ICMPv6) Parameters"
+----------------+----------------------+-----------+ +----------------+----------------------+-----------+
| capability Bit | Description | Document | | capability Bit | Description | Document |
+----------------+----------------------+-----------+ +----------------+----------------------+-----------+
| 11 | 6LR capable (L bit) | RFC This | | 11 | 6LR capable (L bit) | RFC This |
| | | |
| 12 | 6LBR capable (B bit) | RFC This | | 12 | 6LBR capable (B bit) | RFC This |
| | | |
| 13 | 6BBR capable (P bit) | RFC This | | 13 | 6BBR capable (P bit) | RFC This |
| | | |
| 14 | EARO support (E bit) | RFC This | | 14 | EARO support (E bit) | RFC This |
+----------------+----------------------+-----------+ +----------------+----------------------+-----------+
Table 4: New 6LoWPAN capability Bits Table 6: New 6LoWPAN capability Bits
11. Acknowledgments 11. Acknowledgments
Kudos to Eric Levy-Abegnoli who designed the First Hop Security Kudos to Eric Levy-Abegnoli who designed the First Hop Security
infrastructure at Cisco, upon which the first backbone router wsa infrastructure upon which the first backbone router was implemented;
implemented; many thanks to Sedat Gormus, Rahul Jadhav, Charlie many thanks to Charlie Perkins for his in-depth reviews and
Perkins for their various contributions and reviews. Also many constructive suggestions, as well as to Sedat Gormus, Rahul Jadhav
thanks to Thomas Watteyne for his early implementation of a 6LN that and Lorenzo Colitti for their various contributions and reviews.
was instrumental to test the 6LR, 6LBR and Backbone Router. Also many thanks to Thomas Watteyne for his early implementation of a
6LN that was instrumental to the early tests of the 6LR, 6LBR and
Backbone Router.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>. 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, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc6282>. <https://www.rfc-editor.org/info/rfc6282>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for
IPv6 over Low-Power Wireless Personal Area Networks IPv6 over Low-Power Wireless Personal Area Networks
(6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November
2014, <http://www.rfc-editor.org/info/rfc7400>. 2014, <https://www.rfc-editor.org/info/rfc7400>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<http://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
12.2. Informative References 12.2. Informative References
[I-D.chakrabarti-nordmark-6man-efficient-nd] [I-D.chakrabarti-nordmark-6man-efficient-nd]
Chakrabarti, S., Nordmark, E., Thubert, P., and M. Chakrabarti, S., Nordmark, E., Thubert, P., and M.
Wasserman, "IPv6 Neighbor Discovery Optimizations for Wasserman, "IPv6 Neighbor Discovery Optimizations for
Wired and Wireless Networks", draft-chakrabarti-nordmark- Wired and Wireless Networks", draft-chakrabarti-nordmark-
6man-efficient-nd-07 (work in progress), February 2015. 6man-efficient-nd-07 (work in progress), February 2015.
[I-D.delcarpio-6lo-wlanah] [I-D.delcarpio-6lo-wlanah]
skipping to change at page 23, line 36 skipping to change at page 28, line 23
backbone-router-04 (work in progress), July 2017. backbone-router-04 (work in progress), July 2017.
[I-D.ietf-6lo-nfc] [I-D.ietf-6lo-nfc]
Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi, Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi,
"Transmission of IPv6 Packets over Near Field "Transmission of IPv6 Packets over Near Field
Communication", draft-ietf-6lo-nfc-07 (work in progress), Communication", draft-ietf-6lo-nfc-07 (work in progress),
June 2017. June 2017.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work
in progress), January 2017. in progress), August 2017.
[I-D.ietf-bier-architecture] [I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-ietf-bier-architecture-07 (work in Replication", draft-ietf-bier-architecture-08 (work in
progress), June 2017. progress), September 2017.
[I-D.ietf-ipv6-multilink-subnets] [I-D.ietf-ipv6-multilink-subnets]
Thaler, D. and C. Huitema, "Multi-link Subnet Support in Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
progress), July 2002. progress), July 2002.
[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]
Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets
over IEEE 1901.2 Narrowband Powerline Communication over IEEE 1901.2 Narrowband Powerline Communication
Networks", draft-popa-6lo-6loplc-ipv6-over- Networks", draft-popa-6lo-6loplc-ipv6-over-
ieee19012-networks-00 (work in progress), March 2014. ieee19012-networks-00 (work in progress), March 2014.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
DOI 10.17487/RFC1982, August 1996, DOI 10.17487/RFC1982, August 1996,
<http://www.rfc-editor.org/info/rfc1982>. <https://www.rfc-editor.org/info/rfc1982>.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
2003, <http://www.rfc-editor.org/info/rfc3610>. 2003, <https://www.rfc-editor.org/info/rfc3610>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004,
<http://www.rfc-editor.org/info/rfc3810>. <https://www.rfc-editor.org/info/rfc3810>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005, DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>. <https://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<http://www.rfc-editor.org/info/rfc3972>. <https://www.rfc-editor.org/info/rfc3972>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<http://www.rfc-editor.org/info/rfc4429>. <https://www.rfc-editor.org/info/rfc4429>.
[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
over Low-Power Wireless Personal Area Networks (6LoWPANs): over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals", Overview, Assumptions, Problem Statement, and Goals",
RFC 4919, DOI 10.17487/RFC4919, August 2007, RFC 4919, DOI 10.17487/RFC4919, August 2007,
<http://www.rfc-editor.org/info/rfc4919>. <https://www.rfc-editor.org/info/rfc4919>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>. <https://www.rfc-editor.org/info/rfc4941>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>. <https://www.rfc-editor.org/info/rfc7217>.
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
over ITU-T G.9959 Networks", RFC 7428, over ITU-T G.9959 Networks", RFC 7428,
DOI 10.17487/RFC7428, February 2015, DOI 10.17487/RFC7428, February 2015,
<http://www.rfc-editor.org/info/rfc7428>. <https://www.rfc-editor.org/info/rfc7428>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<http://www.rfc-editor.org/info/rfc7668>. <https://www.rfc-editor.org/info/rfc7668>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204, "Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016, RFC 7934, DOI 10.17487/RFC7934, July 2016,
<http://www.rfc-editor.org/info/rfc7934>. <https://www.rfc-editor.org/info/rfc7934>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017, RFC 8064, DOI 10.17487/RFC8064, February 2017,
<http://www.rfc-editor.org/info/rfc8064>. <https://www.rfc-editor.org/info/rfc8064>.
[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation- [RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <http://www.rfc-editor.org/info/rfc8065>. February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, [RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,
M., and D. Barthel, "Transmission of IPv6 Packets over M., and D. Barthel, "Transmission of IPv6 Packets over
Digital Enhanced Cordless Telecommunications (DECT) Ultra Digital Enhanced Cordless Telecommunications (DECT) Ultra
Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
2017, <http://www.rfc-editor.org/info/rfc8105>. 2017, <https://www.rfc-editor.org/info/rfc8105>.
[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. [RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S.
Donaldson, "Transmission of IPv6 over Master-Slave/Token- Donaldson, "Transmission of IPv6 over Master-Slave/Token-
Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163, Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
May 2017, <http://www.rfc-editor.org/info/rfc8163>. May 2017, <https://www.rfc-editor.org/info/rfc8163>.
12.3. External Informative References 12.3. External Informative References
[IEEEstd802154] [IEEEstd802154]
IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE, "IEEE Standard for Low-Rate Wireless Networks",
IEEE Standard 802.15.4, DOI 10.1109/IEEESTD.2016.7460875, IEEE Standard 802.15.4, DOI 10.1109/IEEESTD.2016.7460875,
<http://ieeexplore.ieee.org/document/7460875/>. <http://ieeexplore.ieee.org/document/7460875/>.
[Perlman83] [Perlman83]
Perlman, R., "Fault-Tolerant Broadcast of Routing Perlman, R., "Fault-Tolerant Broadcast of Routing
 End of changes. 157 change blocks. 
460 lines changed or deleted 662 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/