draft-ietf-6lo-rfc6775-update-05.txt   draft-ietf-6lo-rfc6775-update-06.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: November 13, 2017 S. Chakrabarti Expires: December 23, 2017 S. Chakrabarti
May 12, 2017 June 21, 2017
An Update to 6LoWPAN ND An Update to 6LoWPAN ND
draft-ietf-6lo-rfc6775-update-05 draft-ietf-6lo-rfc6775-update-06
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, and provide simplify the registration operation in 6LoWPAN routers, as well as to
enhancements to the registration capabilities, in particular for the provide enhancements to the registration capabilities and mobility
registration to a Backbone Router for proxy ND operations. detection for different network topologies including the backbone
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 http://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 November 13, 2017. This Internet-Draft will expire on December 23, 2017.
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 (http://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. Considerations On Registration Rejection . . . . . . . . . . 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 . . . . . . . . . . 5 4.1. Extended Address Registration Option . . . . . . . . . . 6
4.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 6 4.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 6
4.3. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 7 4.3. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 7
4.4. Registering the Target Address . . . . . . . . . . . . . 7 4.4. Registering the Target Address . . . . . . . . . . . . . 7
4.5. Link-Local Addresses and Registration . . . . . . . . . . 8 4.5. Link-Local Addresses and Registration . . . . . . . . . . 8
4.6. Maintaining the Registration States . . . . . . . . . . . 9 4.6. Maintaining the Registration States . . . . . . . . . . . 9
5. Extending RFC 7400 . . . . . . . . . . . . . . . . . . . . . 11 5. Detecting Enhanced ARO Capability Support . . . . . . . . . . 10
6. Updated ND Options . . . . . . . . . . . . . . . . . . . . . 11 6. Updated ND Options . . . . . . . . . . . . . . . . . . . . . 11
6.1. The Enhanced Address Registration Option (EARO) . . . . . 11 6.1. The Enhanced Address Registration Option (EARO) . . . . . 11
6.2. New 6LoWPAN capability Bits in the Capability Indication 6.2. New 6LoWPAN capability Bits in the Capability Indication
Option . . . . . . . . . . . . . . . . . . . . . . . . . 14 Option . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 14 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 14
7.1. Discovering the capabilities of an ND peer . . . . . . . 14 7.1. Discovering the capabilities of an ND peer . . . . . . . 14
7.1.1. Using the E Flag in the CIO . . . . . . . . . . . . . 14 7.1.1. Using the E Flag in the CIO . . . . . . . . . . . . . 14
7.1.2. Using the T Flag in the EARO . . . . . . . . . . . . 15 7.1.2. Using the T Flag in the EARO . . . . . . . . . . . . 15
7.2. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 15 7.2. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 15
7.3. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 16 7.3. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 16
7.4. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 16 7.4. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.3. External Informative References . . . . . . . . . . . . 24 12.2. Informative References . . . . . . . . . . . . . . . . . 21
12.3. External Informative References . . . . . . . . . . . . 23
Appendix A. Applicability and Requirements Served . . . . . . . 24 Appendix A. Applicability and Requirements Served . . . . . . . 24
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 24
B.1. Requirements Related to Mobility . . . . . . . . . . . . 25 B.1. Requirements Related to Mobility . . . . . . . . . . . . 25
B.2. Requirements Related to Routing Protocols . . . . . . . . 25 B.2. Requirements Related to Routing Protocols . . . . . . . . 25
B.3. Requirements Related to the Variety of Low-Power Link B.3. Requirements Related to the Variety of Low-Power Link
types . . . . . . . . . . . . . . . . . . . . . . . . . . 26 types . . . . . . . . . . . . . . . . . . . . . . . . . . 26
B.4. Requirements Related to Proxy Operations . . . . . . . . 27 B.4. Requirements Related to Proxy Operations . . . . . . . . 27
B.5. Requirements Related to Security . . . . . . . . . . . . 27 B.5. Requirements Related to Security . . . . . . . . . . . . 27
B.6. Requirements Related to Scalability . . . . . . . . . . . 29 B.6. Requirements Related to Scalability . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
RFC 6775, the "Neighbor Discovery Optimization for IPv6 over Low- The scope of this draft is an IPv6 Low Power Networks including star
Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775] and mesh topologies. This specification modifies and extends the
introduced a proactive registration mechanism to IPv6 Neighbor behavior and protocol elements of RFC 6775 "Neighbor Discovery
Discovery (ND) services that is well suited to nodes belonging to a Optimization for IPv6 over Low-Power Wireless Personal Area Networks
Low Power Lossy Network (LLN). (6LoWPANs)" [RFC6775] to enable additional capabilities such as:
The scope of this draft is an IPv6 LLN, which can be a simple star or * Support the indication of mobility vs retry (T-bit)
a more complex mesh topology. The LLN may be anchored at an IPv6
Backbone Router (6BBR) [I-D.ietf-6lo-backbone-router]. This
specification modifies and extends the behavior and protocol elements
of RFC 6775 [RFC6775] to enable additional capabilities, in
particular the registration to a 6BBR for proxy ND operations.
2. Considerations On Registration Rejection * Ease up requirement of registration for link-local addresses
* Introducing Enhancement to Address Registration Option (ARO)
* Permitting regitration of target address
* Clarification of support of privacy and temporary addresses
The following sections will discuss applicability of 6LoWPAN ND
registration, new extensions and updates to RFC 6775. Finally, we
will discuss how the extensions of registration framework can be
useful for a scenario such as Backbone router(6BBR) proxy ND
operations.
2. Applicability of Address Registration Options
The purpose of the Address Registration Option (ARO) [RFC6775] and of The purpose of the Address Registration Option (ARO) [RFC6775] and of
the Extended ARO (EARO) that is introduced in this document is to the Extended ARO (EARO) that is introduced in this document is to
facilitate duplicate address detection (DAD) for hosts and pre- facilitate duplicate address detection (DAD) for hosts and pre-
populate Neighbor Cache Entries (NCE) [RFC4861] in the routers to populate Neighbor Cache Entries (NCE) [RFC4861] in the routers to
reduce the need for sending multicast neighbor solicitations and also reduce the need for sending 'multicast neighbor solicitations' which
to be able to support IPv6 Backbone Routers. may be harmful in low power constrained nodes networks where
multicast is most often treated as broadcasts.
In some cases the address registration can fail or be useless for In some cases the address registration can fail or becomes useless
reasons other than a duplicate address. Examples are the router for reasons other than a duplicate address. Examples are the router
having run out of space, a registration bearing a stale sequence having run out of space, a registration bearing a stale sequence
number (e.g. denoting a movement of the host after this registration number (e.g. denoting a movement of the host after this registration
was placed), a host misbehaving and attempting to register an invalid was placed), a host misbehaving and attempting to register an invalid
address such as the unspecified address [RFC4291], or the host using address such as the unspecified address [RFC4291], or the host using
an address which is not topologically correct on that link. In such an address which is not topologically correct on that link. In such
cases the host will receive an error to help diagnose the issue and cases the host will receive an error to help diagnose the issue and
may retry, possibly with a different address, and possibly may retry, possibly with a different address, and possibly
registering to a different 6LR, depending on the returned error. registering to a different 6LR, depending on the returned error.
However, the ability to return errors to address registrations MUST However, the ability to return errors to address registrations MUST
skipping to change at page 4, line 27 skipping to change at page 4, line 36
"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): "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" "Neighbor Discovery Optimization for Low-power and Lossy Networks"
[RFC6775] and [RFC6775] and
"Multi-link Subnet Support in IPv6" "Multi-link Subnet Support in IPv6"
[I-D.ietf-ipv6-multilink-subnets]. [I-D.ietf-ipv6-multilink-subnets].
Additionally, this document uses terminology from
"Terms Used in Routing for Low-Power and Lossy Networks" [RFC7102]
and
the "6TiSCH Terminology" [I-D.ietf-6tisch-terminology],
as well as this additional terminology: as well as this additional terminology:
Backbone This is an IPv6 transit link that interconnects 2 or more Backbone This is an IPv6 transit link that interconnects 2 or more
Backbone Routers. It is expected to be deployed as a high Backbone Routers. It is expected to be deployed as a high
speed Backbone in order to federate a potentially large set of speed Backbone in order to federate a potentially large set of
LLNS. Also referred to as a LLN Backbone or Backbone network. LLNS. Also referred to as a LLN Backbone or Backbone network.
Backbone Router An IPv6 router that federates the LLN using a Backbone Router An IPv6 router that federates the LLN using a
Backbone link as a Backbone. A 6BBR acts as a 6LoWPAN Border Backbone link as a Backbone. A 6BBR acts as a 6LoWPAN Border
Routers (6LBR) and an Energy Aware Default Router (NEAR). Routers (6LBR) and an Energy Aware Default Router (NEAR).
skipping to change at page 6, line 34 skipping to change at page 6, line 40
supports this specification. supports this specification.
Finally, this specification introduces a number of new Status codes Finally, this specification introduces a number of new Status codes
to help diagnose the cause of a registration failure (more in to help diagnose the cause of a registration failure (more in
Table 1). Table 1).
4.2. Transaction ID 4.2. Transaction ID
The specification expects that the Registered Node can provide a The specification expects that the Registered Node can provide a
sequence number called Transaction ID (TID) that is incremented with sequence number called Transaction ID (TID) that is incremented with
each re-registration. The TID essentially obeys the same rules as each re-registration. The TID is used to detect the freshness of the
the Path Sequence field in the Transit Information Option (TIO) found registration request and useful to detect one single registration by
in the RPL Destination Advertisement Object (DAO) [RFC6550]. This multiple 6LOWPAN border routers supporting the same large 6LOWPAN, as
way, the LLN node can use the same counter for ND and RPL, and a 6LBR is the case for backbone routers (BBR).
acting as RPL root may easily maintain the registration on behalf of
a RPL node deep inside the mesh by simply using the RPL TIO Path
Sequence as TID for EARO.
When a Registered Node is registered to multiple BBRs in parallel, it For example, when a Registered Node is registered with multiple BBRs
is expected that the same TID is used, to enable the 6BBRs to in parallel, it is expected that the same TID is used, to enable the
correlate the registrations as being a single one, and differentiate 6BBRs to correlate the registrations as being a single one, and
that situation from a movement. differentiate that situation from a movement.
If the TIDs are different, a conflict resolution inherited from RPL Thus TID could be tracked to follow the sequence of mobility of a
sorts out the most recent registration and other ones are removed. node. The details protocols of mobility verification by the border
The operation for computing and comparing the Path Sequence is routers is not part of this specification.
detailed in section 7 of RFC 6550 [RFC6550] and applies to the TID in
the exact same fashion. The resolution is used to determine the
freshest registration for a particular address, and an EARO is
processed only if it is the freshest, otherwise a Status code 3
"Moved" is returned.
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 to differentiate a real duplicate
address registration from a double registration or a movement. An ND address registration 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 and if they relate to a same target then
they reflect an address duplication. The Owner Unique ID can be as they reflect an address duplication. The Owner Unique ID can be as
skipping to change at page 8, line 19 skipping to change at page 8, line 15
message. message.
4.5. Link-Local Addresses and Registration 4.5. 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 Compared to RFC 6775 [RFC6775], this specification only requires that
a Link-Local address is unique from the perspective of the peering a Link-Local address is unique from the perspective of the peering
nodes. This simplifies the Duplicate Address Detection (DAD) for nodes. This simplifies the Duplicate Address Detection (DAD) for
Link-Local addresses, and there is no DAR/DAC exchange between the Link-Local addresses, and there is no Duplicate Address Request (DAR)
6LR and a 6LBR for Link-Local addresses. / 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) Additionally, RFC 6775 [RFC6775] requires that a 6LoWPAN Node (6LN)
uses an address being registered as the source of the registration uses an address being registered as the source of the registration
message. This generates complexities in the 6LR to be able to cope message. This generates complexities in the 6LR to be able to cope
with a potential duplication, in particular for global addresses. To with a potential duplication, in particular for global addresses. To
simplify this, a 6LN and a 6LR that conform this specification always simplify this, a 6LN and a 6LR that conform this specification always
use Link-Local addresses as source and destination addresses for the use Link-Local addresses as source and destination addresses for the
registration NS/NA exchange. As a result, the registration is registration NS/NA exchange. As a result, the registration is
globally faster, and some of the complexity is removed. globally faster, and some of the complexity is removed.
skipping to change at page 10, line 15 skipping to change at page 10, line 13
register to another 6LR. Conversely the registry in the 6LBR may be register to another 6LR. Conversely the registry in the 6LBR may be
saturated, in which case the 6LBR cannot guarantee that a new address 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 is effectively not a duplicate. In that case, the 6LBR replies to a
DAR message with a DAC message that carries a Status code 9 DAR message with a DAC message that carries a Status code 9
indicating "6LBR Registry saturated", and the address stays in indicating "6LBR Registry saturated", and the address stays in
TENTATIVE state. TENTATIVE state.
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. This is normally done through a DAR/DAC exchange, but to the 6LBR.
the refresh MAY alternatively be piggy-backed in another protocol
such as RPL [RFC6550], as long as the semantics of the EARO are fully
carried in the alternate protocol. In the particular case of RPL,
the TID MUST be used as the Path Sequence in the TIO, and the
Registration Lifetime MUST be used as Path Lifetime. It is also
REQUIRED that the root of the RPL DODAG passes that information to
the 6LBR on behalf of the 6LR, either through a DAR/DAC exchange, or
through internal methods if they are collocated.
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. deregister all of its addresses registered to that 6LR.
Upon receiving a NS(EARO) message with a Registration Lifetime of 0 Upon receiving a NS(EARO) message with a Registration Lifetime of 0
skipping to change at page 11, line 5 skipping to change at page 10, line 40
Upon the DAR message, the 6LBR evaluates if this is the freshest EARO Upon the DAR message, the 6LBR evaluates if this is the freshest EARO
it has received for that particular registry entry. If it is, then it has received for that particular registry entry. If it is, then
the entry is scheduled to be removed, and the DAR is answered with a the entry is scheduled to be removed, and the DAR is answered with a
DAC message bearing a Status of 0 "Success". If it is not the DAC message bearing a Status of 0 "Success". If it is not the
freshest, then a Status 2 "Moved" is returned instead, and the freshest, then a Status 2 "Moved" is returned instead, and the
existing entry is conserved. The 6LBR SHOULD conserve the address in existing entry is conserved. The 6LBR SHOULD conserve the address in
a DELAY state for a configurable period of time, so as to protect a a DELAY state for a configurable period of time, so as to protect a
mobile node that deregistered from one 6LR and did not register yet mobile node that deregistered from one 6LR and did not register yet
to a new one. to a new one.
5. Extending RFC 7400 5. Detecting Enhanced ARO Capability Support
The nodes and routers in a network may be mixed and if a node wants
to use EARO feature for address registration, it has to find a router
which supports it. Thus all implementations with EARO option MUST
provide the capability detection method using 6CIO option to support
both types of registrations (ARO and EARO) as described in later
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 RFC 7400 [RFC7400] introduces the 6LoWPAN Capability Indication
Option (6CIO) to indicate a node's capabilities to its peers. This Option (6CIO) to indicate a node's capabilities to its peers. This
specification extends the format defined in RFC 7400 to signal the 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 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 [RFC7400], the 6CIO is typically sent Router
Solicitation (RS) messages. When used to signal the capabilities Solicitation (RS) messages. When used to signal the capabilities
above per this specification, the 6CIO is typically present Router above per this specification, the 6CIO is typically present Router
skipping to change at page 13, line 39 skipping to change at page 13, line 39
| | | | | |
| 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. This | | | accepted because the 6LBR Registry is saturated. |
| | code is used by 6LBRs instead of Status 2 when responding | | | |
| | to a DAR/DAC exchange and passed on to the Registering | | 10 | Incorrect proof: The proof of ownership of the registered |
| | Node by the 6LR. There is no point for the node to retry | | | address is not correct. |
| | 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. |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Table 1: EARO Status Table 1: EARO Status
Note: the code "6LBR Registry saturated" is used by 6LBRs instead of
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 6.2. New 6LoWPAN capability Bits in the Capability Indication Option
This specification defines a number of capability bits in the CIO This specification defines a number of capability bits in the CIO
that was introduced by RFC 7400 [RFC7400]. that was introduced by RFC 7400 [RFC7400].
Support for this specification is indicated by setting the "E" flag Support for this specification is indicated by setting the "E" flag
in a CIO option. Routers that are capable of acting as 6LR, 6LBR and in a CIO option. Routers that are capable of acting as 6LR, 6LBR and
6BBR SHOULD set the L, B and P flags, respectively. 6BBR SHOULD set the L, B and P flags, respectively.
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
skipping to change at page 15, line 8 skipping to change at page 15, line 12
If the CIO is used in an ND message, then the "E" Flag MUST be set by If the CIO is used in an ND message, then the "E" Flag MUST be set by
the sending node if supports this specification. the sending node if supports this specification.
It is RECOMMENDED that a router that supports this specification It is RECOMMENDED that a router that supports this specification
indicates so with a CIO option, but this might not be practical if indicates so with a CIO option, but this might not be practical if
the link-layer MTU is too small. the link-layer MTU is too small.
If the Registering Node receives a CIO in a RA, then the setting of If the Registering Node receives a CIO in a RA, then the setting of
the E" Flag indicates whether or not this specification is supported. the E" Flag indicates whether or not this specification is supported.
A node which does not implement this draft or parse 6CIO option, MUST
ignore the packet and the sender of option SHOULD use legacy
registration method according to RFC 6775 [RFC6775] after a timeout
period.
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 amenable 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]. Once that first registration is complete,
skipping to change at page 16, line 45 skipping to change at page 16, line 50
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 does not mandate any particular way for forming This specification recommends to using privacy techniques (more in
IPv6 addresses, but it recognizes that use of EUI-64 for forming the section Section 9, and protection against address theft such as
Interface ID in the Link-Local address prevents the usage of "SEcure provided by "Address Protected Neighbor Discovery for Low-power and
Neighbor Discovery (SEND)" [RFC3971] and "Cryptographically Generated Lossy Networks" [I-D.ietf-6lo-ap-nd], which guarantees the ownership
Addresses (CGA)" [RFC3972], and that of address privacy techniques, of the Registered Address using a cryptographic OUID.
such as recommended in "Privacy Considerations for IPv6 Adaptation-
Layer Mechanisms" [RFC8065]. This specification RECOMMENDS the use
of privacy techniques, and that of additional protection against
address theft such as provided by "Address Protected Neighbor
Discovery for Low-power and Lossy Networks" [I-D.ietf-6lo-ap-nd],
which guarantees the ownership of the Registered Address using a
cryptographic OUID.
As indicated in section Section 2, this protocol does not aim at
limiting the number of IPv6 addresses that a device can form, either.
A host should be able to register any address that is topologically
correct in the subnet(s) advertised by the 6LR/6LBR.
On the other hand, the registration mechanism may be used by a rogue The registration mechanism may be used by a rogue node to attack the
node to attack the 6LR or the 6LBR with a Denial-of-Service attack 6LR or the 6LBR with a Denial-of-Service attack against the registry.
against the registry. It may also happen that the registry of a 6LR It may also happen that the registry of a 6LR or a 6LBR is saturated
or a 6LBR is saturated and cannot take any more registration, which and cannot take any more registration, which effectively denies the
effectively denies the requesting a node the capability to use a new requesting a node the capability to use a new address. In order to
address. In order to alleviate those concerns, Section 4.6 provides alleviate those concerns, Section 4.6 provides a number of
a number of recommendations that ensure that a stale registration is recommendations that ensure that a stale registration is removed as
removed as soon as possible from the 6LR and 6LBR. In particular, soon as possible from the 6LR and 6LBR. In particular, this
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 nodes should be configured with a Registration Lifetime that
reflects their expectation of how long they will use the address reflects their expectation of how long they will use the address
with the 6LR to which it is registered. In particular, use cases with the 6LR to which it is registered. In particular, use cases
that involve mobility or rapid address changes should use that involve mobility or rapid address changes should use
skipping to change at page 18, line 17 skipping to change at page 18, line 11
When the ownership of the OUID cannot be assessed, this specification When the ownership of the OUID cannot be assessed, this specification
limits the cases where the OUID and the TID are multicasted, and limits the cases where the OUID and the TID are multicasted, and
obfuscates them in responses to attempts to take over an address. obfuscates them in responses to attempts to take over an address.
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. IANA Considerations 9. Privacy Considerations
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
should be able to form and register any address that is topologically
correct in the subnet(s) advertised by the 6LR/6LBR.
This specification does not mandate any particular way for forming
IPv6 addresses, but it recognizes that use of EUI-64 for forming the
Interface ID in the Link-Local address prevents the usage of "SEcure
Neighbor Discovery (SEND)" [RFC3971] and "Cryptographically Generated
Addresses (CGA)" [RFC3972], and that of address privacy techniques.
"Privacy Considerations for IPv6 Adaptation-Layer Mechanisms"
[RFC8065] addresses why privacy is important and how to form such
addresses. All implementations and deployment must consider the
option of privacy addresses in their own environment. Also future
specifications involving 6LOWPAN Neighbor Discovery should consult
"Recommendation on Stable IPv6 Interface Identifiers" [RFC8064] for
default interface identifaction.
10. IANA Considerations
IANA is requested to create a new subregistry for "ARO Flags" under IANA is requested to create a new subregistry for "ARO Flags" under
the "Internet Control Message Protocol version 6 (ICMPv6) the "Internet Control Message Protocol version 6 (ICMPv6)
Parameters". This specification defines 8 positions, bit 0 to bit 7, Parameters". 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 and assigns bit 7 for the "T" flag in Section 6.1. The policy is
"IETF Review" or "IESG Approval" [RFC5226]. The initial content of "IETF Review" or "IESG Approval" [RFC5226]. The initial content of
the registry is as shown in Table 2. 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) Parameters"
skipping to change at page 19, line 24 skipping to change at page 19, line 27
| 5 | Proof 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 | Incorrect proof | RFC This |
+------------+------------------------------------------+-----------+ +------------+------------------------------------------+-----------+
Table 3: New ARO Status values Table 3: New ARO Status values
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 |
+----------------+----------------------+-----------+ +----------------+----------------------+-----------+
skipping to change at page 19, line 45 skipping to change at page 20, line 5
| | | | | | | |
| 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 4: New 6LoWPAN capability Bits
10. 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. infrastructure at Cisco.
11. References 12. References
11.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>. <http://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, <http://www.rfc-editor.org/info/rfc4291>.
skipping to change at page 20, line 29 skipping to change at page 20, line 34
"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>. <http://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>. <http://www.rfc-editor.org/info/rfc4862>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[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>. <http://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>. <http://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, <http://www.rfc-editor.org/info/rfc7400>.
11.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]
Vega, L., Robles, I., and R. Morabito, "IPv6 over Vega, L., Robles, I., and R. Morabito, "IPv6 over
802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in
progress), October 2015. progress), October 2015.
[I-D.ietf-6lo-ap-nd] [I-D.ietf-6lo-ap-nd]
Sarikaya, B., Thubert, P., and M. Sethi, "Address Sarikaya, B., Thubert, P., and M. Sethi, "Address
Protected Neighbor Discovery for Low-power and Lossy Protected Neighbor Discovery for Low-power and Lossy
Networks", draft-ietf-6lo-ap-nd-00 (work in progress), Networks", draft-ietf-6lo-ap-nd-02 (work in progress), May
November 2016. 2017.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
backbone-router-03 (work in progress), January 2017. backbone-router-03 (work in progress), January 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-06 (work in progress), Communication", draft-ietf-6lo-nfc-07 (work in progress),
March 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-11 (work
in progress), January 2017. in progress), January 2017.
[I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-08 (work in
progress), December 2016.
[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-06 (work in Replication", draft-ietf-bier-architecture-07 (work in
progress), April 2017. progress), June 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-
skipping to change at page 23, line 12 skipping to change at page 23, line 5
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>. <http://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>. <http://www.rfc-editor.org/info/rfc6550>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>.
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc7428>.
skipping to change at page 23, line 37 skipping to change at page 23, line 26
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc7934>.
[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
"Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017,
<http://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, <http://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, <http://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, <http://www.rfc-editor.org/info/rfc8163>.
11.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/>.
Appendix A. Applicability and Requirements Served Appendix A. Applicability and Requirements Served
This specification extends 6LoWPAN ND to sequence the registration This specification extends 6LoWPAN ND to sequence the registration
and serves the requirements expressed Appendix B.1 by enabling the and serves the requirements expressed Appendix B.1 by enabling the
 End of changes. 41 change blocks. 
130 lines changed or deleted 143 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/