< draft-ietf-6lo-rfc6775-update-02.txt   draft-ietf-6lo-rfc6775-update-03.txt >
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft cisco Internet-Draft cisco
Updates: 6775, 7400 (if approved) E. Nordmark Updates: 6775 (if approved) E. Nordmark
Intended status: Standards Track Intended status: Standards Track
Expires: October 9, 2017 S. Chakrabarti Expires: October 29, 2017 S. Chakrabarti
April 7, 2017 April 27, 2017
An Update to 6LoWPAN ND An Update to 6LoWPAN ND
draft-ietf-6lo-rfc6775-update-02 draft-ietf-6lo-rfc6775-update-03
Abstract Abstract
This specification updates 6LoWPAN Neighbor Discovery (RFC 6775), 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, and provide
enhancements to the registration capabilities, in particular for the enhancements to the registration capabilities, in particular for the
registration to a Backbone Router for proxy ND operations. registration to a Backbone Router for proxy ND operations.
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 October 9, 2017. This Internet-Draft will expire on October 29, 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
skipping to change at page 2, line 12 skipping to change at page 2, line 12
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. Considerations On Registration Rejection . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Updating RFC 7400 . . . . . . . . . . . . . . . . . . . . . . 5 4. Extending RFC 7400 . . . . . . . . . . . . . . . . . . . . . 5
5. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 5 5. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Transaction ID . . . . . . . . . . . . . . . . . . . . . 6 5.1. Extended Address Registration Option . . . . . . . . . . 6
5.2. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 6 5.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 6
5.3. Extended Address Registration Option . . . . . . . . . . 7 5.3. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 7
5.4. Registering the Target Address . . . . . . . . . . . . . 7 5.4. Registering the Target Address . . . . . . . . . . . . . 8
5.5. Link-local Addresses and Registration . . . . . . . . . . 8 5.5. Link-Local Addresses and Registration . . . . . . . . . . 8
6. Updated ND Options . . . . . . . . . . . . . . . . . . . . . 9 5.6. Maintaining the Registration States . . . . . . . . . . . 10
6. Updated ND Options . . . . . . . . . . . . . . . . . . . . . 11
6.1. New 6LoWPAN capability Bits in the Capability Indication 6.1. New 6LoWPAN capability Bits in the Capability Indication
Option . . . . . . . . . . . . . . . . . . . . . . . . . 9 Option . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.2. The Enhanced Address Registration Option (EARO) . . . . . 10 6.2. The Enhanced Address Registration Option (EARO) . . . . . 12
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 13 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15
7.1. Discovering the capabilities of an ND peer . . . . . . . 13 7.1. Discovering the capabilities of an ND peer . . . . . . . 15
7.1.1. Using the E Flag in the CIO . . . . . . . . . . . . . 13 7.1.1. Using the E Flag in the CIO . . . . . . . . . . . . . 15
7.1.2. Using the T Flag in the EARO . . . . . . . . . . . . 13 7.1.2. Using the T Flag in the EARO . . . . . . . . . . . . 15
7.2. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 14 7.2. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 16
7.3. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 14 7.3. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 16
7.4. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 14 7.4. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . 21
11.3. External Informative References . . . . . . . . . . . . 20 11.3. External Informative References . . . . . . . . . . . . 24
Appendix A. Applicability and Requirements Served . . . . . . . 20 Appendix A. Applicability and Requirements Served . . . . . . . 24
Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 21 Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 25
B.1. Requirements Related to Mobility . . . . . . . . . . . . 22 B.1. Requirements Related to Mobility . . . . . . . . . . . . 25
B.2. Requirements Related to Routing Protocols . . . . . . . . 22 B.2. Requirements Related to Routing Protocols . . . . . . . . 26
B.3. Requirements Related to the Variety of Low-Power Link B.3. Requirements Related to the Variety of Low-Power Link
types . . . . . . . . . . . . . . . . . . . . . . . . . . 23 types . . . . . . . . . . . . . . . . . . . . . . . . . . 27
B.4. Requirements Related to Proxy Operations . . . . . . . . 24 B.4. Requirements Related to Proxy Operations . . . . . . . . 27
B.5. Requirements Related to Security . . . . . . . . . . . . 24 B.5. Requirements Related to Security . . . . . . . . . . . . 28
B.6. Requirements Related to Scalability . . . . . . . . . . . 25 B.6. Requirements Related to Scalability . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
RFC 6775, the "Neighbor Discovery Optimization for IPv6 over Low- RFC 6775, the "Neighbor Discovery Optimization for IPv6 over Low-
Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775] Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775]
introduced a proactive registration mechanism to IPv6 Neighbor introduced a proactive registration mechanism to IPv6 Neighbor
Discovery (ND) services that is well suited to nodes belonging to a Discovery (ND) services that is well suited to nodes belonging to a
Low Power Lossy Network (LLN). Low Power Lossy Network (LLN).
The scope of this draft is an IPv6 LLN, which can be a simple star or The scope of this draft is an IPv6 LLN, which can be a simple star or
skipping to change at page 3, line 50 skipping to change at page 3, line 50
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
NOT be used to restrict the ability of hosts to form and use NOT be used to restrict the ability of hosts to form and use
addresses as recommended in "Host Address Availability addresses as recommended in "Host Address Availability
Recommendations" [RFC7934]. In particular, this is needed for Recommendations" [RFC7934]. In particular, this is needed for
enhanced privacy, which implies that each host will register a enhanced privacy, which implies that each host will register a
multiplicity of address as part mechanisms like "Privacy Extensions multiplicity of address as part mechanisms like "Privacy Extensions
for Stateless Address Autoconfiguration (SLAAC) in IPv6" [RFC4941]. for Stateless Address Autoconfiguration (SLAAC) in IPv6" [RFC4941].
This implies that a 6LR or 6LBR which is intended to support N hosts This implies that the capabilities of 6LR and 6LBRs in terms of
MUST have space to register at least on the order of 10N IPv6 number of registrations must be clearly announced in the router
addresses. documentation, and that 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.
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
skipping to change at page 5, line 29 skipping to change at page 5, line 33
Address of the Registered Node as SLLA in the NS(EARO). Address of the Registered Node as SLLA in the NS(EARO).
Otherwise, it is expected that the Registered Device is Otherwise, it is expected that the Registered Device is
reachable over a Route-Over mesh from the Registering Node, in reachable over a Route-Over mesh from the Registering Node, in
which case the SLLA in the NS(ARO) is that of the Registering 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 Node, which causes it to attract the packets from the 6BBR to
the Registered Node and route them over the LLN. the Registered Node and route them over the LLN.
Registered Address The address owned by the Registered Node node Registered Address The address owned by the Registered Node node
that is being registered. that is being registered.
4. Updating RFC 7400 4. Extending RFC 7400
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 6, line 5 skipping to change at page 6, line 7
5. Updating RFC 6775 5. Updating RFC 6775
This specification extends the Address Registration Option (ARO) This specification extends the Address Registration Option (ARO)
defined in RFC 6775 [RFC6775]; in particular a "T" flag is added that defined in RFC 6775 [RFC6775]; in particular a "T" flag is added that
must be set is NS messages when this specification is used, and must be set is NS messages when this specification is used, and
echo'ed in NA messages to confirm that the protocol effectively echo'ed in NA messages to confirm that the protocol effectively
supported. Support for this specification can thus be inferred from supported. Support for this specification can thus be inferred from
the presence of the Extended ARO ("T" flag set) in ND messages. the presence of the Extended ARO ("T" flag set) in ND messages.
In order to support various types of link layers, this specification
also adds recommendation to allow multiple registrations, including
for privacy / temporary addresses, and provides new mechanisms to
help 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 will favor
registering to a 6LR that indicates support for this specification registering to a 6LR that indicates support for this specification
over that of RFC 6775 [RFC6775]. over that of RFC 6775 [RFC6775].
5.1. Transaction ID 5.1. Extended Address Registration Option
This specification extends the ARO option that is used for the
process of address registration. The new ARO is referred to as
Extended ARO (EARO), and its semantics are modified as follows:
The address that is being registered with a Neighbor Solicitation
(NS) with an EARO is now the Target Address, as opposed to the Source
Address as specified in RFC 6775 [RFC6775] (see Section 5.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
address (see Section 5.3 for more). This enables in particular the
use of a Provable Temporary UID (PT-UID) as opposed to burn-in MAC
address, the PT-UID providing a trusted anchor by the 6LR and 6LBR to
protect the state associated to the node.
The specification introduces a Transaction ID (TID) field in the EARO
(see Section 5.2 for more on TID). The TID MUST be provided by a
node that supports this specification and a new T flag MUST be set to
indicate so. The T bit can be used to determine whether the peer
supports this specification.
Finally, this specification introduces a number of new Status codes
to help diagnose the cause of a registration failure (more in
Table 1).
5.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 essentially obeys the same rules as
the Path Sequence field in the Transit Information Option (TIO) found the Path Sequence field in the Transit Information Option (TIO) found
in RPL's Destination Advertisement Object (DAO). This way, the LLN in the RPL Destination Advertisement Object (DAO) [RFC6550]. This
node can use the same counter for ND and RPL, and a 6LBR acting as way, the LLN node can use the same counter for ND and RPL, and a 6LBR
RPL root may easily maintain the registration on behalf of a RPL node acting as RPL root may easily maintain the registration on behalf of
deep inside the mesh by simply using the RPL TIO Path Sequence as TID a RPL node deep inside the mesh by simply using the RPL TIO Path
for EARO. Sequence as TID for EARO.
When a Registered Node is registered to multiple BBRs in parallel, it When a Registered Node is registered to multiple BBRs in parallel, it
is expected that the same TID is used, to enable the 6BBRs to is expected that the same TID is used, to enable the 6BBRs to
correlate the registrations as being a single one, and differentiate correlate the registrations as being a single one, and differentiate
that situation from a movement. that situation from a movement.
If the TIDs are different, the resolution inherited from RPL sorts If the TIDs are different, a conflict resolution inherited from RPL
out the most recent registration and other ones are removed. The sorts out the most recent registration and other ones are removed.
operation for computing and comparing the Path Sequence is detailed The operation for computing and comparing the Path Sequence is
in section 7 of RFC 6550 [RFC6550] and applies to the TID in the detailed in section 7 of RFC 6550 [RFC6550] and applies to the TID in
exact same fashion. 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.
5.2. Owner Unique ID 5.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
simple as a EUI-64 burn-in address, if duplicate EUI-64 addresses are simple as a EUI-64 burn-in address, if duplicate EUI-64 addresses are
avoided. avoided.
skipping to change at page 7, line 7 skipping to change at page 8, line 5
can be used to prove the ownership of the registration as discussed can be used to prove the ownership of the registration as discussed
in "Address Protected Neighbor Discovery for Low-power and Lossy 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 after a reboot that
would cause a loss of memory until the Backbone Router times out the would cause a loss of memory until the Backbone Router times out the
registration. registration.
5.3. Extended Address Registration Option
This specification extends the ARO option that is used for the
process of address registration. The new ARO is referred to as
Extended ARO (EARO), and its semantics are modified as follows:
The address that is being registered with a Neighbor Solicitation
(NS) with an EARO is now the Target Address, as opposed to the Source
Address as specified in RFC 6775 [RFC6775]. 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
address. A new TLV format is introduced and a IANA registry is
created for the type (TBD). This enables in particular the use of a
Provable Temporary UID (PT-UID) as opposed to burn-in MAC address,
the PT-UID providing a trusted anchor by the 6LR and 6LBR to protect
the state associated to the node.
The specification introduces a Transaction ID (TID) field in the
EARO. The TID MUST be provided by a node that supports this
specification and a new T flag MUST be set to indicate so. The T bit
can be used to determine whether the peer supports this
specification.
5.4. Registering the Target Address 5.4. Registering the Target Address
This specification changes the behaviour of the 6LN and the 6LR so This specification changes the behaviour of the 6LN and the 6LR so
that the Registered Address is found in the Target Address field of that the Registered Address is found in the Target Address field of
the NS and NA messages as opposed to the Source Address. 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 in Route-Over meshes, for instance to enable that a
RPL root registers addresses on behalf LLN nodes that are deeper in a RPL root registers addresses on behalf LLN nodes that are deeper in a
6TiSCH mesh, as discussed in Appendix B.4. In that case, the 6TiSCH mesh, as discussed in Appendix B.4. In that case, the
skipping to change at page 8, line 16 skipping to change at page 8, line 33
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 Since the Registering Node is the one that has reachability with the
6LR, and is the one expecting packets for the 6LN, it makes sense to 6LR, and is the one expecting packets for the 6LN, it makes sense to
maintain compatibility with RFC 6775 [RFC6775], and it is REQUIRED maintain compatibility with RFC 6775 [RFC6775], and it is REQUIRED
that an SLLA Option is always placed in a registration NS(EARO) that an SLLA Option is always placed in a registration NS(EARO)
message. message.
5.5. Link-local Addresses and Registration 5.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 DAR/DAC exchange between the
6LR and a 6LBR for link-local addresses. 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.
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 a Conversely, it may possibly happen that two different 6LRs expose a
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 6LR 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 6LoWPAN Border Router (6LBR),
which is based on a Duplicate Address Request (DAR) / Duplicate which is based on a Duplicate Address Request (DAR) / Duplicate
Address Confirmation (DAC) exchange as described in RFC 6775 Address Confirmation (DAC) exchange as described in RFC 6775
[RFC6775], does not need to take place 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
registrered, or the address that is being registered. registrered, 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 DAR/DAC exchange for Link-Local addresses, the 6LR
may answer immediately to the registration of a link-local address, may answer immediately to the registration of a Link-Local address,
based solely on its existing state and the Source Link-Layer Option based solely on its existing state and the Source Link-Layer Option
that MUST be placed in the NS(EARO) message as required in RFC 6775 that MUST be placed in the NS(EARO) message as required in RFC 6775
[RFC6775]. [RFC6775].
A node needs to register its IPv6 Global Unicast IPv6 Addresses (GUA) A node needs to register its IPv6 Global Unicast IPv6 Addresses (GUA)
to a 6LR in order to obtain a global reachability for these addresses to a 6LR in order to obtain a global reachability for these addresses
via that 6LR. As opposed to a node that complies to RFC 6775 via that 6LR. As opposed to a node that complies to RFC 6775
[RFC6775], a Registering Node registering a GUA does not use that GUA [RFC6775], a Registering Node registering a GUA does not use that GUA
as Source Address for the registration to a 6LR that conforms this as Source Address for the registration to a 6LR that conforms this
specification. The DAR/DAC exchange MUST take place for non-link- specification. The DAR/DAC exchange MUST take place for non-Link-
local addresses as prescribed by RFC 6775 [RFC6775]. Local addresses as prescribed by RFC 6775 [RFC6775].
5.6. Maintaining the Registration States
This section discusses protocol actions that involve the registering
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
to it, which, as discussed in Section 5.5, is not the case for Link-
Local addresses. The registration state includes all data that is
stored in the router relative to that registration, in particular,
but not limited to, an NCE in a 6LR. 6LBRs and 6BBRs may store
additional registration information in more complex data structures
and use protocols that are out of scope of this document to keep them
synchonized when they are distributed.
When its Neighbor Cache is full, a 6LR cannot accept a new
registration. In that situation, the EARO is returned in a NA
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
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
DAR message with a DAC message that carries a Status code 9
indicating "6LBR Registry saturated", and the address stays in
TENTATIVE state.
A node renews an existing registration by repeatedly sending NS(EARO)
messages for the registered address. In order to refresh the
registration state in the 6LBR, these registrations MUST be reported
to the 6LBR. This is normally done through a DAR/DAC exchange, but
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
that address from all the 6LRs to which it has registered the
address, which is achieved using an NS(EARO) message with a
Registration Lifetime of 0.
A node that moves away from a particular 6LR SHOULD attempt to
deregister all of its addresses registered to that 6LR.
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
Section 5.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
exchange with the 6LBR, or an alternate protocol, 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
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
DAC message bearing a Status of 0 "Success". If it is not the
freshest, then a Status 2 "Moved" is returned instead, and the
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
mobile node that deregistered from one 6LR and did not register yet
to a new one.
6. Updated ND Options 6. Updated ND Options
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 behaviours as follow: existing ones and updates the associated behaviours as follow:
6.1. New 6LoWPAN capability Bits in the Capability Indication Option 6.1. 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 andP flags, respectively. 6BBR SHOULD set the L, B andP 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
multiple roles, it SHOULD set all the related flags. multiple roles, 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 |_____________________|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|_______________________________________________________________| |_______________________________________________________________|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: New capability Bits L, B, P, E in the CIO Figure 1: New capability Bits L, B, P, E in the CIO
Option Fields Option Fields
skipping to change at page 11, line 46 skipping to change at page 13, line 39
Reserved: This field is unused. It MUST be initialized to zero by Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver. the sender and MUST be ignored by the receiver.
T: One bit flag. Set if the next octet is a used as a TID. T: One bit flag. Set if the next octet is a used as a TID.
TID: 1-byte integer; a transaction id that is maintained by the node TID: 1-byte integer; a transaction id that is maintained by the node
and incremented with each transaction. it is recommended that the and incremented with each transaction. it is recommended that the
node maintains the TID in a persistent storage. node maintains the TID in a persistent 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 state should be means that the registration has ended and the associated state
removed. 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 of an node associated. This can be the EUI-64 derived IID of an
interface, or some provable ID obtained cryptographically. interface, or some provable ID obtained cryptographically.
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| Value | Description | | Value | Description |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
| 0..2 | See RFC 6775 [RFC6775]. Note that a Status of 1 | | 0..2 | See RFC 6775 [RFC6775]. Note that a Status of 1 |
| | "Duplicate Address" applies to the Registered Address. If | | | "Duplicate Address" applies to the Registered Address. If |
| | the Source Address conflicts with an existing | | | the Source Address conflicts with an existing |
| | registration, "Duplicate Source Address" should be used | | | registration, "Duplicate Source Address" should be used |
| | instead | | | instead |
| | | | | |
| 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 | Proof requested: The registering node is challenged for |
| | owning the registered address or for being an acceptable | | | owning the registered address or for being an acceptable |
| | proxy for the registration. This status is expected in | | | proxy for the registration. This Status is expected in |
| | asynchronous messages from a registrar (6LR, 6LBR, 6BBR) | | | asynchronous messages from a registrar (6LR, 6LBR, 6BBR) |
| | to indicate that the registration state is removed, for | | | to indicate that the registration state is removed, for |
| | instance due to time out of a lifetime, or a movement. It | | | instance due to time out of a lifetime, or a movement. It |
| | is used for instance by a 6BBR in a NA(ARO) message to | | | is used for instance by a 6BBR in a NA(ARO) message to |
| | indicate that the ownership of the proxy state on the | | | indicate that the ownership of the proxy state on the |
| | backbone was transfered to another 6BBR, which is | | | backbone was transfered to another 6BBR, which is |
| | indicative of a movement of the device. The receiver of | | | indicative of a movement of the device. The receiver of |
| | the NA is the device that has performed a registration | | | the NA is the device that has performed a registration |
| | that is now stale and it should clean up its state. | | | 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 usable on this link, e.g. it is not | | | NS(ARO) is not a Link-Local address as prescribed by this |
| | topologically correct | | | document. |
| | | | | |
| 8 | Invalid Registered Address: The address being registered | | 8 | Registered Address topologically incorrect: The address |
| | is not usable on this link, e.g. it is not topologically | | | being registered is not usable on this link, e.g. it is |
| | correct | | | not topologically correct |
| | |
| 9 | 6LBR Registry saturated: A new registration cannot be |
| | accepted because the 6LBR Registry is saturated. This |
| | code 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. |
+-------+-----------------------------------------------------------+ +-------+-----------------------------------------------------------+
Table 1: EARO Status Table 1: EARO Status
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 CIO
skipping to change at page 14, line 14 skipping to change at page 16, line 16
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. In order to be backward compatible, an updated
6LR needs to accept that registration if it is valid per the 6LR needs to accept that registration if it is valid per the
"Cryptographically Generated Addresses (CGA)" [RFC3972] "Cryptographically Generated Addresses (CGA)" [RFC3972]
specification, and manage the binding cache accordingly. specification, and manage the binding cache accordingly.
The main difference with RFC 3972 [RFC3972] is that DAR/DAC exchange The main difference with RFC 3972 [RFC3972] is that DAR/DAC exchange
for DAD may be avoided for link-local addresses. Additionally, the for DAD may be avoided for Link-Local addresses. Additionally, the
6LR SHOULD use an EARO in the reply, and may use any of the status 6LR SHOULD use an EARO in the reply, and may use any of the Status
codes defined in this specification. codes 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 a an updated 6LN is for a Link-Local
address, using that link-local address as source. A legacy 6LN will address, using that Link-Local address as source. A legacy 6LN will
not makes a difference and accept -or reject- that registration as if not makes 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 6LN will always areply with an ARO option message, whereas a legacy 6LN will always areply with an ARO option
in the NA message. So from that first registration, the updated 6LN in the NA message. So from that first registration, the updated 6LN
can figure whether the 6LR supports this specification or not. can figure whether the 6LR supports this specification or not.
When facing a legacy 6LR, an updated 6LN may attempt to find an When facing 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,
skipping to change at page 14, line 48 skipping to change at page 17, line 7
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 DAR/DAC transports an EARO option as
opposed to an ARO option. As described for the NS/NA exchange, opposed to an ARO option. As described for the NS/NA exchange,
devices that support this specification always use an EARO option and devices that support this specification always use an EARO option and
all the associated behaviour. all the associated behaviour.
8. Security Considerations 8. Security Considerations
This specification expects that the link layer is sufficiently This specification extends RFC 6775 [RFC6775], and the security
protected, either by means of physical or IP security for the section of that draft also applies to this as well. In particular,
Backbone Link or MAC sublayer cryptography. In particular, it is it is expected that the link layer is sufficiently protected to
expected that the LLN MAC provides secure unicast to/from the prevent a rogue access, either by means of physical or IP security on
Backbone Router and secure Broadcast from the Backbone Router in a the Backbone Link and link layer cryptography on the LLN. This
way that prevents tempering with or replaying the RA messages. specification also expects that the LLN MAC provides secure unicast
to/from the Backbone Router and secure Broadcast from the Backbone
Router in a way that prevents tempering with or replaying the RA
messages.
The use of EUI-64 for forming the Interface ID in the link-local This specification does not mandate any particular way for forming
address prevents the usage of "SEcure Neighbor Discovery (SEND)" IPv6 addresses, but it recognizes that use of EUI-64 for forming the
[RFC3971] and CGA [RFC3972], and that of address privacy techniques. Interface ID in the Link-Local address prevents the usage of "SEcure
This specification RECOMMENDS the use of additional protection Neighbor Discovery (SEND)" [RFC3971] and CGA [RFC3972], and that of
against address theft such as provided by "Address Protected Neighbor address privacy techniques. This specification RECOMMENDS the use of
Discovery for Low-power and Lossy Networks" [I-D.ietf-6lo-ap-nd], additional protection against address theft such as provided by
which guarantees the ownership of the OUID. "Address Protected Neighbor Discovery for Low-power and Lossy
Networks" [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the
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
node to attack the 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 and cannot take any more registration, which
effectively denies the requesting a node the capability to use a new
address. In order to alleviate those concerns, Section 5.6 provides
a number of recommendations that ensure that a stale registration is
removed as soon as possible from the 6LR and 6LBR. In particular,
this specification recommends that:
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
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.
o The nodes should be configured with a Registration Lifetime that
reflects their expectation of how long they will use the address
with the 6LR to which it is registered. In particular, use cases
that involve mobility or rapid address changes should use
lifetimes that are homogeneous with the expectation of presence.
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
identified at least by MAC address and preferably by security
credentials. When that maximum is reached, the router should use
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
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
formed or because they are used over a much longer time span than
other (privacy, shorter-lived) addresses.
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 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. 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.2. The policy is and assigns bit 7 for the "T" flag in Section 6.2. 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.
skipping to change at page 16, line 7 skipping to change at page 19, line 23
| 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 IANA is requested to make additions to existing registries as
follows: 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 | 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 | Invalid Registered Address | RFC This | | 8 | Registered Address topologically | RFC This |
+------------+----------------------------+-----------+ | | incorrect | |
| | | |
| 9 | 6LBR registry saturated | 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 |
+----------------+----------------------+-----------+ +----------------+----------------------+-----------+
| 11 | 6LR capable (L bit) | RFC This | | 11 | 6LR capable (L bit) | RFC This |
skipping to change at page 19, line 31 skipping to change at page 23, line 8
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-08 (work in 802.15.4e", draft-ietf-6tisch-terminology-08 (work in
progress), December 2016. 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-05 (work in Replication", draft-ietf-bier-architecture-06 (work in
progress), October 2016. progress), April 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 20, line 44 skipping to change at page 24, line 25
[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>.
11.3. External Informative References 11.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, 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
mobility of devices from one LLN to the next based on the mobility of devices from one LLN to the next based on the
complementary work in the "IPv6 Backbone Router" complementary work in the "IPv6 Backbone Router"
[I-D.ietf-6lo-backbone-router] specification. [I-D.ietf-6lo-backbone-router] specification.
 End of changes. 48 change blocks. 
148 lines changed or deleted 289 lines changed or added

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