< draft-ietf-6lo-rfc6775-update-08.txt   draft-ietf-6lo-rfc6775-update-09.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: March 24, 2018 S. Chakrabarti Expires: March 24, 2018 S. Chakrabarti
September 20, 2017 September 20, 2017
An Update to 6LoWPAN ND An Update to 6LoWPAN ND
draft-ietf-6lo-rfc6775-update-08 draft-ietf-6lo-rfc6775-update-09
Abstract Abstract
This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to
clarify the role of the protocol as a registration technique, clarify the role of the protocol as a registration technique,
simplify the registration operation in 6LoWPAN routers, as well as to simplify the registration operation in 6LoWPAN routers, as well as to
provide enhancements to the registration capabilities and mobility provide enhancements to the registration capabilities and mobility
detection for different network topologies including the backbone detection for different network topologies including the backbone
routers performing proxy Neighbor Discovery in a low power network. routers performing proxy Neighbor Discovery in a low power network.
skipping to change at page 2, line 13 skipping to change at page 2, line 13
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability of Address Registration Options . . . . . . . . 3 2. Applicability of Address Registration Options . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 5 4. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Extended Address Registration Option (EARO . . . . . . . 7 4.1. Extended Address Registration Option (EARO) . . . . . . . 7
4.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 7 4.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. Comparing TID values . . . . . . . . . . . . . . . . 8 4.2.1. Comparing TID values . . . . . . . . . . . . . . . . 8
4.3. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 9 4.3. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 9
4.4. Extended Duplicate Address Messages . . . . . . . . . . . 10 4.4. Extended Duplicate Address Messages . . . . . . . . . . . 10
4.5. Registering the Target Address . . . . . . . . . . . . . 10 4.5. Registering the Target Address . . . . . . . . . . . . . 10
4.6. Link-Local Addresses and Registration . . . . . . . . . . 11 4.6. Link-Local Addresses and Registration . . . . . . . . . . 11
4.7. Maintaining the Registration States . . . . . . . . . . . 13 4.7. Maintaining the Registration States . . . . . . . . . . . 13
5. Detecting Enhanced ARO Capability Support . . . . . . . . . . 14 5. Detecting Enhanced ARO Capability Support . . . . . . . . . . 14
6. Extended ND Options And Messages . . . . . . . . . . . . . . 15 6. Extended ND Options And Messages . . . . . . . . . . . . . . 15
6.1. Enhanced Address Registration Option (EARO) . . . . . . . 15 6.1. Enhanced Address Registration Option (EARO) . . . . . . . 15
6.2. Extended Duplicate Address Message Formats . . . . . . . 18 6.2. Extended Duplicate Address Message Formats . . . . . . . 18
6.3. New 6LoWPAN Capability Bits in the Capability Indication 6.3. New 6LoWPAN Capability Bits in the Capability Indication
Option . . . . . . . . . . . . . . . . . . . . . . . . . 19 Option . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 19 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 19
7.1. Discovering the capabilities of an ND peer . . . . . . . 19 7.1. Discovering the capabilities of an ND peer . . . . . . . 19
7.1.1. Using the E Flag in the 6CIO Option . . . . . . . . . 19 7.1.1. Using the "E" Flag in the 6CIO Option . . . . . . . . 19
7.1.2. Using the T Flag in the EARO . . . . . . . . . . . . 20 7.1.2. Using the "T" Flag in the EARO . . . . . . . . . . . 20
7.2. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 21 7.2. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 21
7.3. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 21 7.3. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 21
7.4. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 22 7.4. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10.1. ARO Flags . . . . . . . . . . . . . . . . . . . . . . . 24 10.1. ARO Flags . . . . . . . . . . . . . . . . . . . . . . . 24
10.2. ICMP Codes . . . . . . . . . . . . . . . . . . . . . . . 24 10.2. ICMP Codes . . . . . . . . . . . . . . . . . . . . . . . 24
10.3. New ARO Status values . . . . . . . . . . . . . . . . . 25 10.3. New ARO Status values . . . . . . . . . . . . . . . . . 25
10.4. New 6LoWPAN capability Bits . . . . . . . . . . . . . . 26 10.4. New 6LoWPAN capability Bits . . . . . . . . . . . . . . 26
skipping to change at page 5, line 48 skipping to change at page 5, line 48
6BBR, which may proxy for the registered node. 6BBR, which may proxy for the registered node.
Registered Address An address owned by the Registered Node node that Registered Address An address owned by the Registered Node node that
was or is being registered. was or is being registered.
legacy and original vs. updated In the context of this legacy and original vs. updated In the context of this
specification, the terms "legacy" and "original" relate to the specification, the terms "legacy" and "original" relate to the
support of the RFC 6775 by a 6LN, a 6LR or a 6LBR, whereas the support of the RFC 6775 by a 6LN, a 6LR or a 6LBR, whereas the
term "updated" refers to the support of this specification. term "updated" refers to the support of this specification.
classical In the context of this specification, the term "classical"
relates to the support of the IPv6 Neighbor Discovery (IPv6 ND)
protocol as specified in RFC 4861 and RFC 4862. This
specification does not deprecate the classical IPv6 ND
Protocol.
4. Updating RFC 6775 4. Updating RFC 6775
This specification introduces the Extended Address Registration This specification introduces the Extended Address Registration
Option (EARO) based on the ARO as defined in RFC 6775 [RFC6775]; in Option (EARO) based on the ARO as defined in RFC 6775 [RFC6775]; in
particular a "T" flag is added that must be set is NS messages when particular a "T" flag is added that MUST be set is NS messages when
this specification is used, and echoed in NA messages to confirm that this specification is used, and echoed in NA messages to confirm that
the protocol is supported. the protocol is supported.
Support for this specification can thus be inferred from the presence
of the Extended ARO ("T" flag set) in 6LoWPAN ND messages.
The extensions to the ARO option are reported to the Duplicate The extensions to the ARO option are reported to the Duplicate
Address Request (DAR) and Duplicate Address Confirmation (DAC) Address Request (DAR) and Duplicate Address Confirmation (DAC)
messages, so as to convey the additional information all the way to messages, so as to convey the additional information all the way to
the 6LBR, and in turn the 6LBR may proxy the registration using the 6LBR, and in turn the 6LBR may proxy the registration using
classical ND over a backbone as illustrated in Figure 1. classical ND over a backbone as illustrated in Figure 1.
6LN 6LR 6LBR 6BBR 6LN 6LR 6LBR 6BBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | | |--------------->| | |
| | Extended DAR | | | | Extended DAR | |
| |-------------->| | | |-------------->| |
| | | | | | | |
| | | proxy NS(EARO) | | | | proxy NS(EARO) |
| | |--------------->| | | |--------------->|
| | | | NS(DAD) | | | | NS(DAD)
| | | | ------> | | | | ------>
| | | |
| | | | <wait> | | | | <wait>
| | | | | | | |
| | | proxy NA(EARO) | | | | proxy NA(EARO) |
| | |<---------------| | | |<---------------|
| | Extended DAC | | | | Extended DAC | |
| |<--------------| | | |<--------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<---------------| | | |<---------------| | |
| | | | | | | |
Figure 1: (Re-)Registration Flow Figure 1: (Re-)Registration Flow
In order to support various types of link layers, this specification In order to support various types of link layers, it is RECOMMENDED
also RECOMMENDS to allow multiple registrations, including for to allow multiple registrations, including for privacy / temporary
privacy / temporary addresses, and provides new mechanisms to help addresses, and provides new mechanisms to help clean up stale
clean up stale registration states as soon as possible. registration states as soon as possible.
A Registering Node that supports this specification SHOULD prefer A Registering Node SHOULD prefer registering to a 6LR that is found
registering to a 6LR that is found to support this specification, as to support this specification, as discussed in Section 7.1, over a
discussed in Section 7.1, over a legacy one. legacy one.
4.1. Extended Address Registration Option (EARO 4.1. Extended Address Registration Option (EARO)
This specification extends the ARO option that is used for the The Extended ARO (EARO) deprecates the ARO and is backward compatible
process of address registration. The new ARO is referred to as with it. More details on backward compatibility can be found in
Extended ARO (EARO), and it is backward compatible with the ARO. Section 7.
More details on backward compatibility can be found in Section 7.
The semantics of the ARO are modified as follows: The semantics of the ARO are modified as follows:
o The address that is being registered with a Neighbor Solicitation o The address that is being registered with a Neighbor Solicitation
(NS) with an EARO is now the Target Address, as opposed to the (NS) with an EARO is now the Target Address, as opposed to the
Source Address as specified in RFC 6775 [RFC6775] (see Source Address as specified in RFC 6775 [RFC6775] (see
Section 4.5). This change enables a 6LBR to use one of its Section 4.5). This change enables a 6LBR to use one of its
addresses as source to the proxy-registration of an address that addresses as source to the proxy-registration of an address that
belongs to a LLN Node to a 6BBR. This also limits the use of an 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 address as source address before it is registered and the
skipping to change at page 7, line 39 skipping to change at page 7, line 38
o The specification introduces a Transaction ID (TID) field in the o The specification introduces a Transaction ID (TID) field in the
EARO (see Section 4.2). The TID MUST be provided by a node that EARO (see Section 4.2). The TID MUST be provided by a node that
supports this specification and a new "T" flag MUST be set to supports this specification and a new "T" flag MUST be set to
indicate so. indicate so.
o Finally, this specification introduces new status codes to help o Finally, this specification introduces new status codes to help
diagnose the cause of a registration failure (see Table 1). diagnose the cause of a registration failure (see Table 1).
4.2. Transaction ID 4.2. Transaction ID
sequence number that is incremented with each re-registration. The The Transaction ID (TID) is a sequence number that is incremented
TID is used to detect the freshness of the registration request and with each re-registration. The TID is used to detect the freshness
useful to detect one single registration by multiple 6LOWPAN border of the registration request and useful to detect one single
routers (e.g., 6LBRs and 6BBRs) supporting the same 6LOWPAN. The TID registration by multiple 6LOWPAN border routers (e.g., 6LBRs and
may also be used by the network to track the sequence of movements of 6BBRs) supporting the same 6LOWPAN. The TID may also be used by the
a node in order to route to the current (freshest known) location of network to track the sequence of movements of a node in order to
a moving node. route to the current (freshest known) location of a moving node.
When a Registered Node is registered with multiple BBRs in parallel, When a Registered Node is registered with multiple BBRs in parallel,
the same TID SHOULD be used, to enable the 6BBRs to determine that the same TID SHOULD be used, to enable the 6BBRs to determine that
the registrations are the same, and distinguish that situation from a the registrations are the same, and distinguish that situation from a
movement. movement.
4.2.1. Comparing TID values 4.2.1. Comparing TID values
The TID is a sequence counter and its operation is the exact match of The TID is a sequence counter and its operation is the exact match of
the path sequence specified in RPL, the IPv6 Routing Protocol for the path sequence specified in RPL, the IPv6 Routing Protocol for
skipping to change at page 14, line 8 skipping to change at page 14, line 8
to the 6LBR. to the 6LBR.
A node that ceases to use an address SHOULD attempt to deregister A node that ceases to use an address SHOULD attempt to deregister
that address from all the 6LRs to which it has registered the that address from all the 6LRs to which it has registered the
address, which is achieved using an NS(EARO) message with a address, which is achieved using an NS(EARO) message with a
Registration Lifetime of 0. Registration Lifetime of 0.
A node that moves away from a particular 6LR SHOULD attempt to A node that moves away from a particular 6LR SHOULD attempt to
deregister all of its addresses registered to that 6LR and register deregister all of its addresses registered to that 6LR and register
to a new 6LR with an incremented TID. When/if the node shows up to a new 6LR with an incremented TID. When/if the node shows up
elsewhere, an used to clean up the state in the previous location. elsewhere, an asynchronous NA(EARO) or EDAC message with a status of
For instance, the "Moved" status can be used by a 6BBR in a NA(EARO) 3 "Moved" SHOULD be used to clean up the state in the previous
message to indicate that the ownership of the proxy state on the location. For instance, the "Moved" status can be used by a 6BBR in
Backbone was transferred to another 6BBR, as the consequence of a a NA(EARO) message to indicate that the ownership of the proxy state
movement of the device. The receiver of the message SHOULD propagate on the Backbone was transferred to another 6BBR, as the consequence
the status down the chain towards the Registered node and clean up of a movement of the device. The receiver of the message SHOULD
its state. propagate the status down the chain towards the Registered node and
clean up its state.
Upon receiving a NS(EARO) message with a Registration Lifetime of 0 Upon receiving a NS(EARO) message with a Registration Lifetime of 0
and determining that this EARO is the freshest for a given NCE (see and determining that this EARO is the freshest for a given NCE (see
Section 4.2), a 6LR cleans up its NCE. If the address was registered Section 4.2), a 6LR cleans up its NCE. If the address was registered
to the 6LBR, then the 6LR MUST report to the 6LBR, through a to the 6LBR, then the 6LR MUST report to the 6LBR, through a
Duplicate Address exchange with the 6LBR, or an alternate protocol, Duplicate Address exchange with the 6LBR, or an alternate protocol,
indicating the null Registration Lifetime and the latest TID that indicating the null Registration Lifetime and the latest TID that
this 6LR is aware of. this 6LR is aware of.
Upon the Extended DAR message, the 6LBR evaluates if this is the Upon the Extended DAR message, the 6LBR evaluates if this is the
skipping to change at page 19, line 45 skipping to change at page 19, line 45
B: Node is a 6LBR. B: Node is a 6LBR.
P: Node is a 6BBR, proxying for nodes on this link. P: Node is a 6BBR, proxying for nodes on this link.
E: This specification is supported and applied. E: This specification is supported and applied.
7. Backward Compatibility 7. Backward Compatibility
7.1. Discovering the capabilities of an ND peer 7.1. Discovering the capabilities of an ND peer
7.1.1. Using the E Flag in the 6CIO Option 7.1.1. Using the "E" Flag in the 6CIO Option
If the 6CIO is used in an ND message and the sending node supports If the 6CIO is used in an ND message and the sending node supports
this specification, then the "E" Flag MUST be set. this specification, then the "E" Flag MUST be set.
A router that supports this specification SHOULD indicate that with a A router that supports this specification SHOULD indicate that with a
6CIO Option, but this might not be practical if the link-layer MTU is 6CIO Option, but this might not be practical if the link-layer MTU is
too small. too small.
If the Registering Node (RN) receives a CIO in a Router Advertisement If the Registering Node (RN) receives a CIO in a Router Advertisement
message, then the setting of the "E" Flag indicates whether or not message, then the setting of the "E" Flag indicates whether or not
this specification is supported. RN SHOULD favor a router that this specification is supported. RN SHOULD favor a router that
supports this specification over those that do not. supports this specification over those that do not.
7.1.2. Using the T Flag in the EARO 7.1.2. Using the "T" Flag in the EARO
One alternate way for a 6LN to discover the router's capabilities to One alternate way for a 6LN to discover the router's capabilities to
first register a Link Local address, placing the same address in the first register a Link Local address, placing the same address in the
Source and Target Address fields of the NS message, and setting the Source and Target Address fields of the NS message, and setting the
"T" Flag. The node may for instance register an address that is "T" Flag. The node may for instance register an address that is
based on EUI-64. For such address, DAD is not required and using the based on EUI-64. For such address, DAD is not required and using the
SLLAO option in the NS is actually more consistent with existing ND SLLAO option in the NS is actually more consistent with existing ND
specifications such as the "Optimistic Duplicate Address Detection specifications such as the "Optimistic Duplicate Address Detection
(DAD) for IPv6" [RFC4429]. (DAD) for IPv6" [RFC4429].
skipping to change at page 21, line 39 skipping to change at page 21, line 39
figure whether the 6LR supports this specification or not. figure whether the 6LR supports this specification or not.
After detecting a legacy 6LR, an updated 6LN may attempt to find an After detecting a legacy 6LR, an updated 6LN may attempt to find an
alternate 6LR that is updated. In order to be backward compatible, alternate 6LR that is updated. In order to be backward compatible,
after detecting that a 6LR is legacy, the 6LN MUST adhere to RFC 6775 after detecting that a 6LR is legacy, the 6LN MUST adhere to RFC 6775
in future protocol exchanges with that 6LR, and source the packet in future protocol exchanges with that 6LR, and source the packet
with the Registered Address. with the Registered Address.
Note that the updated 6LN SHOULD use an EARO in the request Note that the updated 6LN SHOULD use an EARO in the request
regardless of the type of 6LR, legacy or updated, which implies that regardless of the type of 6LR, legacy or updated, which implies that
the 'T' flag is set. the "T" flag is set.
If an updated 6LN moves from an updated 6LR to a legacy 6LR, the If an updated 6LN moves from an updated 6LR to a legacy 6LR, the
legacy 6LR will send a legacy DAR message, which can not be compared legacy 6LR will send a legacy DAR message, which can not be compared
with an updated one for freshness. with an updated one for freshness.
Allowing legacy DAR messages to replace a state established by the Allowing legacy DAR messages to replace a state established by the
updated protocol in the 6LBR would be an attack vector and that updated protocol in the 6LBR would be an attack vector and that
cannot be the default behavior. cannot be the default behavior.
But if legacy and updated 6LRs coexist temporarily in a network, then But if legacy and updated 6LRs coexist temporarily in a network, then
skipping to change at page 22, line 22 skipping to change at page 22, line 22
Note that a legacy 6LBR will accept and process an EDAR message as if Note that a legacy 6LBR will accept and process an EDAR message as if
it was an original one, so the original support of DAD is preserved. it was an original one, so the original support of DAD is preserved.
8. Security Considerations 8. Security Considerations
This specification extends RFC 6775 [RFC6775], and the security This specification extends RFC 6775 [RFC6775], and the security
section of that draft also applies to this as well. In particular, section of that draft also applies to this as well. In particular,
it is expected that the link layer is sufficiently protected to it is expected that the link layer is sufficiently protected to
prevent a rogue access, either by means of physical or IP security on prevent a rogue access, either by means of physical or IP security on
the Backbone Link and link layer cryptography on the LLN. This the Backbone Link and link layer cryptography on the LLN.
specification also expects that the LLN MAC provides secure unicast
to/from the Backbone Router and secure Broadcast from the Backbone This specification also expects that the LLN MAC provides secure
Router in a way that prevents tempering with or replaying the RA unicast to/from the Backbone Router and secure Broadcast from the
messages. Backbone Router in a way that prevents tempering with or replaying
the RA messages.
This specification recommends to using privacy techniques (see This specification recommends to using privacy techniques (see
Section 9, and protection against address theft such as provided by Section 9, and protection against address theft such as provided by
"Address Protected Neighbor Discovery for Low-power and Lossy "Address Protected Neighbor Discovery for Low-power and Lossy
Networks" [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the Networks" [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the
Registered Address using a cryptographic OUID. Registered Address using a cryptographic OUID.
The registration mechanism may be used by a rogue node to attack the The registration mechanism may be used by a rogue node to attack the
6LR or the 6LBR with a Denial-of-Service attack against the registry. 6LR or the 6LBR with a Denial-of-Service attack against the registry.
It may also happen that the registry of a 6LR or a 6LBR is saturated It may also happen that the registry of a 6LR or a 6LBR is saturated
skipping to change at page 24, line 23 skipping to change at page 24, line 23
10. IANA Considerations 10. IANA Considerations
IANA is requested to make a number of changes under the "Internet IANA is requested to make a number of changes under the "Internet
Control Message Protocol version 6 (ICMPv6) Parameters" registry, as Control Message Protocol version 6 (ICMPv6) Parameters" registry, as
follows. follows.
10.1. ARO Flags 10.1. ARO Flags
IANA is requested to create a new subregistry for "ARO Flags". This IANA is requested to create a new subregistry for "ARO Flags". This
specification defines 8 positions, bit 0 to bit 7, and assigns bit 7 specification defines 8 positions, bit 0 to bit 7, and assigns bit 7
for the 'T' flag in Section 6.1. The policy is "IETF Review" or for the "T" flag in Section 6.1. The policy is "IETF Review" or
"IESG Approval" [RFC8126]. The initial content of the registry is as "IESG Approval" [RFC8126]. The initial content of the registry is as
shown in Table 2. 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) [RFC4443] Parameters" Protocol version 6 (ICMPv6) [RFC4443] Parameters"
+------------+--------------+-----------+ +------------+--------------+-----------+
| ARO Status | Description | Document | | ARO Status | Description | Document |
+------------+--------------+-----------+ +------------+--------------+-----------+
| 0..6 | Unassigned | | | 0..6 | Unassigned | |
| 7 | 'T' Flag | RFC This | | 7 | "T" Flag | RFC This |
+------------+--------------+-----------+ +------------+--------------+-----------+
Table 2: new ARO Flags Table 2: new ARO Flags
10.2. ICMP Codes 10.2. ICMP Codes
IANA is requested to create a new entry in the ICMPv6 "Code" Fields IANA is requested to create a new entry in the ICMPv6 "Code" Fields
subregistry of the Internet Control Message Protocol version 6 subregistry of the Internet Control Message Protocol version 6
(ICMPv6) Parameters for the ICMP codes related to the ICMP type 157 (ICMPv6) Parameters for the ICMP codes related to the ICMP type 157
and 158 Duplicate Address Request (shown in Table 3) and Confirmation and 158 Duplicate Address Request (shown in Table 3) and Confirmation
 End of changes. 19 change blocks. 
46 lines changed or deleted 49 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/