< draft-ietf-6lo-rfc6775-update-16.txt   draft-ietf-6lo-rfc6775-update-17.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 Zededa Intended status: Standards Track Zededa
Expires: September 19, 2018 S. Chakrabarti Expires: October 5, 2018 S. Chakrabarti
Verizon Verizon
C. Perkins C. Perkins
Futurewei Futurewei
March 18, 2018 April 3, 2018
Registration Extensions for 6LoWPAN Neighbor Discovery Registration Extensions for 6LoWPAN Neighbor Discovery
draft-ietf-6lo-rfc6775-update-16 draft-ietf-6lo-rfc6775-update-17
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 1, line 40 skipping to change at page 1, line 40
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 19, 2018. This Internet-Draft will expire on October 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
4.7. Maintaining the Registration States . . . . . . . . . . . 14 4.7. Maintaining the Registration States . . . . . . . . . . . 14
5. Detecting Enhanced ARO Capability Support . . . . . . . . . . 15 5. Detecting Enhanced ARO Capability Support . . . . . . . . . . 15
6. Extended ND Options and Messages . . . . . . . . . . . . . . 16 6. Extended ND Options and Messages . . . . . . . . . . . . . . 16
6.1. Extended Address Registration Option (EARO) . . . . . . . 16 6.1. Extended Address Registration Option (EARO) . . . . . . . 16
6.2. Extended Duplicate Address Message Formats . . . . . . . 19 6.2. Extended Duplicate Address Message Formats . . . . . . . 19
6.3. New 6LoWPAN Capability Bits in the Capability Indication 6.3. New 6LoWPAN Capability Bits in the Capability Indication
Option . . . . . . . . . . . . . . . . . . . . . . . . . 20 Option . . . . . . . . . . . . . . . . . . . . . . . . . 20
7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 21 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 21
7.1. Discovering the Capabilities of Router . . . . . . . . . 21 7.1. Discovering the Capabilities of Router . . . . . . . . . 21
7.2. RFC6775-only 6LoWPAN Node . . . . . . . . . . . . . . . . 21 7.2. RFC6775-only 6LoWPAN Node . . . . . . . . . . . . . . . . 21
7.3. RFC6775-only 6LoWPAN Router . . . . . . . . . . . . . . . 21 7.3. RFC6775-only 6LoWPAN Router . . . . . . . . . . . . . . . 22
7.4. RFC6775-only 6LoWPAN Border Router . . . . . . . . . . . 22 7.4. RFC6775-only 6LoWPAN Border Router . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10.1. ARO Flags . . . . . . . . . . . . . . . . . . . . . . . 25 10.1. ARO Flags . . . . . . . . . . . . . . . . . . . . . . . 25
10.2. ICMP Codes . . . . . . . . . . . . . . . . . . . . . . . 25 10.2. ICMP Codes . . . . . . . . . . . . . . . . . . . . . . . 25
10.3. New ARO Status values . . . . . . . . . . . . . . . . . 26 10.3. New ARO Status values . . . . . . . . . . . . . . . . . 26
10.4. New 6LoWPAN capability Bits . . . . . . . . . . . . . . 27 10.4. New 6LoWPAN capability Bits . . . . . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
skipping to change at page 5, line 33 skipping to change at page 5, line 33
Binding: The association between an IP address, a MAC address, a Binding: The association between an IP address, a MAC address, a
port, and other information about the node that owns the IP port, and other information about the node that owns the IP
Address. Address.
Registered Node: The 6LN for which the registration is performed, Registered Node: The 6LN for which the registration is performed,
and which owns the fields in the Extended ARO option. and which owns the fields in the Extended ARO option.
Registering Node: The node that performs the registration; this may Registering Node: The node that performs the registration; this may
be the Registered Node, or a proxy such as a 6LBR performing a be the Registered Node, or a proxy such as a 6LBR performing a
registration to a 6BBR, on behalf of the Registered Node. registration to a 6BBR, on behalf of the Registered Node.
Registered Address: An address owned by the Registered Node that was Registered Address: An address owned by the Registered Node that was
or is being registered. or is being registered.
RFC6775-only: Applied to a type of node or a type of message, this RFC6775-only: Applied to an implementation, a type of node, or a
adjective indicates a behavior that is strictly as specified by type of message, this adjective indicates a behavior that is
[RFC6775] as opposed to updated with this specification. strictly as specified by [RFC6775] as opposed to updated with
this specification.
updated: Qualifies a 6LN, a 6LR, or a 6LBR that supports this updated: Qualifies a 6LN, a 6LR, or a 6LBR that supports this
specification. specification.
3. Applicability of Address Registration Options 3. Applicability of Address Registration Options
The purpose of the Address Registration Option (ARO) in [RFC6775] is The purpose of the Address Registration Option (ARO) in [RFC6775] is
to facilitate duplicate address detection (DAD) for hosts as well as to facilitate duplicate address detection (DAD) for hosts as well as
to populate Neighbor Cache Entries (NCEs) [RFC4861] in the routers. to populate Neighbor Cache Entries (NCEs) [RFC4861] in the routers.
This reduces the reliance on multicast operations, which are often as This reduces the reliance on multicast operations, which are often as
intrusive as broadcast, in IPv6 ND operations. intrusive as broadcast, in IPv6 ND operations.
skipping to change at page 6, line 22 skipping to change at page 6, line 23
to be used to restrict the ability of hosts to form and use multiple to be used to restrict the ability of hosts to form and use multiple
addresses. Rather, the intention is to conform to "Host Address addresses. Rather, the intention is to conform to "Host Address
Availability Recommendations" [RFC7934]. Availability Recommendations" [RFC7934].
In particular, the freedom to form and register addresses is needed In particular, the freedom to form and register addresses is needed
for enhanced privacy; each host may register a number of addresses for enhanced privacy; each host may register a number of addresses
using mechanisms such as "Privacy Extensions for Stateless Address using mechanisms such as "Privacy Extensions for Stateless Address
Autoconfiguration (SLAAC) in IPv6" [RFC4941]. Autoconfiguration (SLAAC) in IPv6" [RFC4941].
In IPv6 ND [RFC4861], a router needs enough storage to hold NCEs for In IPv6 ND [RFC4861], a router needs enough storage to hold NCEs for
all the addresses to which it can currently forward packets. A all directly connected addresses to which it is currently forwarding
router using the Address Registration mechanism also needs enough packets (entries that do not appear to be in use may be flushed). In
storage to hold NCEs for all the addresses that may be registered to contrast, a router serving the Address Registration mechanism needs
it, regardless of whether or not they are actively communicating. enough storage to hold NCEs for all the addresses that may be
The number of registrations supported by a 6LoWPAN Router (6LR) or registered to it, regardless of whether or not they are actively
6LoWPAN Border Router (6LBR) MUST be clearly documented by the vendor communicating. The number of registrations supported by a 6LoWPAN
and the dynamic use of associated resources SHOULD be made available Router (6LR) or 6LoWPAN Border Router (6LBR) MUST be clearly
to the network operator, e.g., to a management console. documented by the vendor and the dynamic use of associated resources
SHOULD be made available to the network operator, e.g., to a
management console.
A network administrator MUST deploy updated 6LR/6LBRs to support the In order to deploy this, network administrators MUST ensure that
number and type of devices in their network, based on the number of 6LR/6LBRs in their network support the number and type of devices
IPv6 addresses that those devices require and their address renewal that can register to them, based on the number of IPv6 addresses that
rate and behavior. those devices require and their address renewal rate and behavior.
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 [RFC6775]. A 'T' flag is Option (EARO) based on the ARO as defined [RFC6775]. A 'T' flag is
added to indicate that a new field, the Transaction ID (TID) is added to indicate that a new field, the Transaction ID (TID) is
populated. The 'T' flag MUST be set in NS messages when this populated. The 'T' flag MUST be set in NS messages when this
specification is used, and echoed in NA messages to confirm that the specification is used, and echoed in NA messages to confirm that the
protocol is supported. The EUI-64 field is overloaded to carry protocol is supported. The EUI-64 field is overloaded to carry
different types of information and its size may be increased when different types of information and its size may be increased when
skipping to change at page 9, line 9 skipping to change at page 9, line 13
the most recent TID. the most recent TID.
When a Registered Node is registered with multiple 6BBRs in parallel, When a Registered Node is registered with multiple 6BBRs in parallel,
the same TID MUST be used. This enables the 6BBRs to determine that the same TID MUST be used. This enables 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 (see section 4 of [I-D.ietf-6lo-backbone-router] and movement (see section 4 of [I-D.ietf-6lo-backbone-router] and
Section 4.7 below). Section 4.7 below).
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 As a note to the implementer, the operation of the TID is fully
the path sequence specified in RPL, the IPv6 Routing Protocol for compatible with that of the RPL Path Sequence counter as described in
Low-Power and Lossy Networks [RFC6550] specification. the "Sequence Counter Operation" section of the "IPv6 Routing
Protocol for Low-Power and Lossy Networks" [RFC6550] specification.
In order to keep this document self-contained and yet compatible, the
text below is an exact copy from section 7.2. "Sequence Counter
Operation" of [RFC6550].
A TID is deemed to be fresher than another when its value is greater A TID is deemed to be fresher than another when its value is greater
per the operations detailed in this section. per the operations detailed in this section.
The TID range is subdivided in a 'lollipop' fashion ([Perlman83]), The TID range is subdivided in a 'lollipop' fashion ([Perlman83]),
where the values from 128 and greater are used as a linear sequence where the values from 128 and greater are used as a linear sequence
to indicate a restart and bootstrap the counter, and the values less to indicate a restart and bootstrap the counter, and the values less
than or equal to 127 used as a circular sequence number space of size than or equal to 127 used as a circular sequence number space of size
128 as in [RFC1982]. Consideration is given to the mode of operation 128 as in [RFC1982]. Consideration is given to the mode of operation
when transitioning from the linear region to the circular region. when transitioning from the linear region to the circular region.
skipping to change at page 11, line 15 skipping to change at page 11, line 15
specification introduces new status codes "Validation Requested" and specification introduces new status codes "Validation Requested" and
"Validation Failed" in the EARO. "Validation Failed" in the EARO.
Note on ROVR collision: different techniques for forming the ROVR Note on ROVR collision: different techniques for forming the ROVR
will operate in different name-spaces. [RFC6775] operates on EUI- will operate in different name-spaces. [RFC6775] operates on EUI-
64(TM) addresses. [I-D.ietf-6lo-ap-nd] generates cryptographic 64(TM) addresses. [I-D.ietf-6lo-ap-nd] generates cryptographic
tokens. While collisions are not expected in the EUI-64 name-space tokens. While collisions are not expected in the EUI-64 name-space
only, they may happen in the case of [I-D.ietf-6lo-ap-nd] and in a only, they may happen in the case of [I-D.ietf-6lo-ap-nd] and in a
mixed situation. An implementation that understands the name-space mixed situation. An implementation that understands the name-space
MUST consider that ROVRs from different name-spaces are different MUST consider that ROVRs from different name-spaces are different
even if they have the same value. An RFC6775-only will confuse the even if they have the same value. An RFC6775-only 6LR or 6LBR will
name-spaces, which slightly increases the risk of a ROVR collision. confuse the name-spaces, which slightly increases the risk of a ROVR
A collision of ROVR has no effect if the two Registering Nodes collision. A collision of ROVR has no effect if the two Registering
register different addresses, since the ROVR is only significant Nodes register different addresses, since the ROVR is only
within the context of one registration. A ROVR is not expected to be significant within the context of one registration. A ROVR is not
unique to one registration, as this specification allows a node to expected to be unique to one registration, as this specification
use the same ROVR to register multiple IPv6 addresses. This is why allows a node to use the same ROVR to register multiple IPv6
the ROVR MUST NOT be used as a key to identify the Registering Node, addresses. This is why the ROVR MUST NOT be used as a key to
or as an index to the registration. It is only used as a match to identify the Registering Node, or as an index to the registration.
ensure that the node that updates a registration for an IPv6 address It is only used as a match to ensure that the node that updates a
is the node that made the original registration for that IPv6 registration for an IPv6 address is the node that made the original
address. Also, when the ROVR is not an EUI-64 address, then it MUST registration for that IPv6 address. Also, when the ROVR is not an
NOT be used as the interface ID of the Registered Address. This way, EUI-64 address, then it MUST NOT be used as the interface ID of the
a registration that uses that ROVR will not collision with that of an Registered Address. This way, a registration that uses that ROVR
IPv6 Address derived from EUI-64 and using the EUI-64 as ROVR per will not collision with that of an IPv6 Address derived from EUI-64
[RFC6775]. and using the EUI-64 as ROVR per [RFC6775].
The Registering Node SHOULD store the ROVR, or enough information to The Registering Node SHOULD store the ROVR, or enough information to
regenerate it, in persistent memory. If this is not done and an regenerate it, in persistent memory. If this is not done and an
event such as a reboot causes a loss of state, re-registering the event such as a reboot causes a loss of state, re-registering the
same address could be impossible until the 6LRs and the 6LBR time out same address could be impossible until the 6LRs and the 6LBR time out
the previous registration, or a management action is taken to clear the previous registration, or a management action is taken to clear
the relevant state in the network. the relevant state in the network.
4.4. Extended Duplicate Address Messages 4.4. Extended Duplicate Address Messages
skipping to change at page 14, line 44 skipping to change at page 14, line 44
or keep the address in TENTATIVE state and retry later. or keep the address in TENTATIVE state and retry later.
A node renews an existing registration by sending a new NS(EARO) A node renews an existing registration by sending a new NS(EARO)
message for the Registered Address. In order to refresh the message for the Registered Address. In order to refresh the
registration state in the 6LBR, the registration MUST be reported to registration state in the 6LBR, the registration MUST be reported to
the 6LBR. the 6LBR.
A node that ceases to use an address SHOULD attempt to de-register A node that ceases to use an address SHOULD attempt to de-register
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. This is achieved using an NS(EARO) message with a address. This is achieved using an NS(EARO) message with a
Registration Lifetime of 0. If this is not done, a state will remain Registration Lifetime of 0. If this is not done, the associated
in the network for its Lifetime. state will remain in the network till the current Registration
Lifetime expires and this may lead to a situation where the 6LR
resources become saturated, even if they are correctly planned to
start with. The 6LR may then take defensive measures that may
prevent this node or some other nodes from owning as many addresses
as they would expect (see Section 8).
A node that moves away from a particular 6LR SHOULD attempt to de- A node that moves away from a particular 6LR SHOULD attempt to de-
register all of its addresses registered to that 6LR and register to register all of its addresses registered to that 6LR and register to
a new 6LR with an incremented TID. When/if the node shows up a new 6LR with an incremented TID. When/if the node shows up
elsewhere, an asynchronous NA(EARO) or EDAC message with a Status elsewhere, an asynchronous NA(EARO) or EDAC message with a Status
Code of "Moved" SHOULD be used to clean up the state in the previous Code of "Moved" SHOULD be used to clean up the state in the previous
location. For instance, as described in location. For instance, as described in
[I-D.ietf-6lo-backbone-router], the "Moved" status can be used by a [I-D.ietf-6lo-backbone-router], the "Moved" status can be used by a
6BBR in an NA(EARO) message to indicate that the ownership of the 6BBR in an NA(EARO) message to indicate that the ownership of the
proxy state on the Backbone Link was transferred to another 6BBR as proxy state on the Backbone Link was transferred to another 6BBR as
the consequence of a movement of the device. If the receiver of the the consequence of a movement of the device. If the receiver of the
message has a state corresponding to the related address, it SHOULD message has a state corresponding to the related address, it SHOULD
propagate the status down the forwarding path to the Registered node propagate the status down the forwarding path to the Registered node
(e.g., reversing an existing RPL [RFC6550] path as prescribed in (e.g., reversing an existing RPL [RFC6550] path as prescribed in
[I-D.ietf-roll-efficient-npdao]). Whether it could do so or not, the [I-D.ietf-roll-efficient-npdao]). Whether it could do so or not, the
receiver MUST clean up said state. receiver MUST clean up said state.
skipping to change at page 21, line 24 skipping to change at page 21, line 24
6LR can process Extended ARO, then the "E" Flag is set in the RA. 6LR can process Extended ARO, then the "E" Flag is set in the RA.
This specification changes the behavior of the peers in a This specification changes the behavior of the peers in a
registration flow. To enable backward compatibility, a 6LN that registration flow. To enable backward compatibility, a 6LN that
registers to a 6LR that is not known to support this specification registers to a 6LR that is not known to support this specification
MUST behave in a manner that is backward-compatible with [RFC6775]. MUST behave in a manner that is backward-compatible with [RFC6775].
On the contrary, if the 6LR is known to support this specification, On the contrary, if the 6LR is known to support this specification,
then the 6LN MUST conform to this specification when communicating then the 6LN MUST conform to this specification when communicating
with that 6LR. with that 6LR.
In order to ensure that it registers a first address successfully a
6LN MAY register a Link Local Address that is derived from an EUI-64,
placing the same address in the Source and Target Address fields of
the NS(EARO) message. For such an address, DAD is not required (see
[RFC6775]) and using the SLLA Option in the NS is actually more
consistent with existing ND specifications such as the "Optimistic
Duplicate Address Detection (ODAD) for IPv6" [RFC4429]. The 6LN MAY
then use that address to register one or more other addresses.
A 6LN that supports this specification MUST always use an EARO as a A 6LN that supports this specification MUST always use an EARO as a
replacement for an ARO in its registration to a router. This is replacement for an ARO in its registration to a router. This is
harmless since the 'T' flag and TID field are reserved in [RFC6775], harmless since the 'T' flag and TID field are reserved in [RFC6775],
and are ignored by an RFC6775-only router. A router that supports and are ignored by an RFC6775-only router. A router that supports
this specification MUST answer an NS(ARO) and an NS(EARO) with an this specification MUST answer an NS(ARO) and an NS(EARO) with an
NA(EARO). A router that does not support this specification will NA(EARO). A router that does not support this specification will
consider the ROVR as an EUI-64 address and treat it the same, which consider the ROVR as an EUI-64 address and treat it the same, which
has no consequence if the Registered Addresses are different. has no consequence if the Registered Addresses are different.
7.2. RFC6775-only 6LoWPAN Node 7.2. RFC6775-only 6LoWPAN Node
skipping to change at page 22, line 17 skipping to change at page 22, line 26
set. It MUST use a ROVR of 64 bits if the 6LR is an RFC6775-only set. It MUST use a ROVR of 64 bits if the 6LR is an RFC6775-only
6LoWPAN Router. 6LoWPAN Router.
If an updated 6LN moves from an updated 6LR to an RFC6775-only 6LR, If an updated 6LN moves from an updated 6LR to an RFC6775-only 6LR,
the RFC6775-only 6LR will send an RFC6775-only DAR message, which the RFC6775-only 6LR will send an RFC6775-only DAR message, which
cannot be compared with an updated one for freshness. Allowing cannot be compared with an updated one for freshness. Allowing
RFC6775-only DAR messages to replace a state established by the RFC6775-only 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. But if RFC6775-only and updated 6LRs cannot be the default behavior. But if RFC6775-only and updated 6LRs
coexist temporarily in a network, then it makes sense for an coexist temporarily in a network, then it makes sense for an
administrator to install a policy that allows so, and the capability administrator to install a policy that allows this, and the
to install such a policy should be configurable in a 6LBR though it capability to install such a policy should be configurable in a 6LBR
is out of scope for this document. though it is out of scope for this document.
7.4. RFC6775-only 6LoWPAN Border Router 7.4. RFC6775-only 6LoWPAN Border Router
With this specification, the Duplicate Address messages are extended With this specification, the Duplicate Address messages are extended
to transport the EARO information. Similarly to the NS/NA exchange, to transport the EARO information. Similarly to the NS/NA exchange,
an updated 6LBR MUST always use the EDA messages. an updated 6LBR MUST always use the EDA messages.
Note that an RFC6775-only 6LBR will accept and process an EDAR Note that an RFC6775-only 6LBR will accept and process an EDAR
message as if it were an RFC6775-only DAR, as long as the ROVR is 64 message as if it were an RFC6775-only DAR, as long as the ROVR is 64
bits long. An updated 6LR discovers the capabilities of the 6LBR in bits long. An updated 6LR discovers the capabilities of the 6LBR in
skipping to change at page 23, line 35 skipping to change at page 23, line 44
o The Registration lifetimes SHOULD be individually configurable for o The Registration lifetimes SHOULD be individually configurable for
each address or group of addresses. The nodes SHOULD be each address or group of addresses. The nodes SHOULD be
configured with a Registration Lifetime that reflects their configured with a Registration Lifetime that reflects their
expectation of how long they will use the address with the 6LR to expectation of how long they will use the address with the 6LR to
which it is registered. In particular, use cases that involve which it is registered. In particular, use cases that involve
mobility or rapid address changes SHOULD use lifetimes that are mobility or rapid address changes SHOULD use lifetimes that are
larger yet of a same order as the duration of the expectation of larger yet of a same order as the duration of the expectation of
presence. presence.
o The router (6LR or 6LBR) SHOULD be configurable so as to limit the o The router (6LR or 6LBR) SHOULD be configurable so as to limit the
number of addresses that can be registered by a single node, but number of addresses that can be registered by a single node, but
as a protective measure only. A node may be identified by MAC as a protective measure only. In any case, a router MUST be able
address, but a stronger identification (e.g., by security to keep a minimum number of addresses per node. That minimum
credentials) is RECOMMENDED. When that maximum is reached, the depends on the type of device and ranges between 3 for a very
constrained LLN and 10 for a larger device. A node may be
identified by its MAC address, as long as it is not obfuscated by
privacy measures. A stronger identification (e.g., by security
credentials) is RECOMMENDED. When the maximum is reached, the
router should use a Least-Recently-Used (LRU) algorithm to clean router should use a Least-Recently-Used (LRU) algorithm to clean
up the addresses, keeping at least one Link-Local Address. The up the addresses, keeping at least one Link-Local Address. The
router SHOULD attempt to keep one or more stable addresses if router SHOULD attempt to keep one or more stable addresses if
stability can be determined, e.g., because they are used over a stability can be determined, e.g., because they are used over a
much longer time span than other (privacy, shorter-lived) much longer time span than other (privacy, shorter-lived)
addresses. Address lifetimes SHOULD be individually configurable. addresses.
o In order to avoid denial of registration for the lack of o In order to avoid denial of registration for the lack of
resources, administrators should take great care to deploy resources, administrators should take great care to deploy
adequate numbers of 6LRs to cover the needs of the nodes in their adequate numbers of 6LRs to cover the needs of the nodes in their
range, so as to avoid a situation of starving nodes. It is range, so as to avoid a situation of starving nodes. It is
expected that the 6LBR that serves an LLN is a more capable node expected that the 6LBR that serves an LLN is a more capable node
than the average 6LR, but in a network condition where it may than the average 6LR, but in a network condition where it may
become saturated, a particular deployment should distribute the become saturated, a particular deployment should distribute the
6LBR functionality, for instance by leveraging a high speed 6LBR functionality, for instance by leveraging a high speed
Backbone Link and Backbone Routers to aggregate multiple LLNs into Backbone Link and Backbone Routers to aggregate multiple LLNs into
a larger subnet. a larger subnet.
skipping to change at page 28, line 11 skipping to change at page 28, line 11
+-----------------+----------------------+-----------+ +-----------------+----------------------+-----------+
Table 6: New 6LoWPAN capability Bits Table 6: New 6LoWPAN capability Bits
11. Acknowledgments 11. Acknowledgments
Kudos to Eric Levy-Abegnoli who designed the First Hop Security Kudos to Eric Levy-Abegnoli who designed the First Hop Security
infrastructure upon which the first backbone router was implemented. infrastructure upon which the first backbone router was implemented.
Many thanks to Sedat Gormus, Rahul Jadhav, Tim Chown, Juergen Many thanks to Sedat Gormus, Rahul Jadhav, Tim Chown, Juergen
Schoenwaelder, Chris Lonvick, Dave Thaler, Adrian Farrel, Peter Yee, Schoenwaelder, Chris Lonvick, Dave Thaler, Adrian Farrel, Peter Yee,
and Lorenzo Colitti for their various contributions and reviews. Warren Kumari, and Lorenzo Colitti for their various contributions
Also, many thanks to Thomas Watteyne for the world first and reviews. Also, many thanks to Thomas Watteyne for the world
implementation of a 6LN that was instrumental to the early tests of first implementation of a 6LN that was instrumental to the early
the 6LR, 6LBR and Backbone Router. tests of the 6LR, 6LBR and Backbone Router.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 30, line 43 skipping to change at page 30, line 43
of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
in progress), November 2017. in progress), November 2017.
[I-D.ietf-mboned-ieee802-mcast-problems] [I-D.ietf-mboned-ieee802-mcast-problems]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
Zuniga, "Multicast Considerations over IEEE 802 Wireless Zuniga, "Multicast Considerations over IEEE 802 Wireless
Media", draft-ietf-mboned-ieee802-mcast-problems-01 (work Media", draft-ietf-mboned-ieee802-mcast-problems-01 (work
in progress), February 2018. in progress), February 2018.
[I-D.ietf-roll-efficient-npdao] [I-D.ietf-roll-efficient-npdao]
Jadhav, R., Sahoo, R., and Z. Cao, "No-Path DAO Jadhav, R., Thubert, P., Sahoo, R., and Z. Cao, "Efficient
modifications", draft-ietf-roll-efficient-npdao-01 (work Route Invalidation", draft-ietf-roll-efficient-npdao-03
in progress), October 2017. (work in progress), March 2018.
[I-D.perkins-intarea-multicast-ieee802] [I-D.perkins-intarea-multicast-ieee802]
Perkins, C., Stanley, D., Kumari, W., and J. Zuniga, Perkins, C., Stanley, D., Kumari, W., and J. Zuniga,
"Multicast Considerations over IEEE 802 Wireless Media", "Multicast Considerations over IEEE 802 Wireless Media",
draft-perkins-intarea-multicast-ieee802-03 (work in draft-perkins-intarea-multicast-ieee802-03 (work in
progress), July 2017. progress), July 2017.
[I-D.struik-lwip-curve-representations] [I-D.struik-lwip-curve-representations]
Struik, R., "Alternative Elliptic Curve Representations", Struik, R., "Alternative Elliptic Curve Representations",
draft-struik-lwip-curve-representations-00 (work in draft-struik-lwip-curve-representations-00 (work in
skipping to change at page 33, line 27 skipping to change at page 33, line 27
readings/p83.pdf>. readings/p83.pdf>.
Appendix A. Applicability and Requirements Served (Not Normative) Appendix A. Applicability and Requirements Served (Not Normative)
This specification extends 6LoWPAN ND to provide a sequence number to This specification extends 6LoWPAN ND to provide a sequence number to
the registration and serves the requirements expressed in the registration and serves the requirements expressed in
Appendix B.1 by enabling the mobility of devices from one LLN to the Appendix B.1 by enabling the mobility of devices from one LLN to the
next based on the complementary work in the "IPv6 Backbone Router" next based on the complementary work in the "IPv6 Backbone Router"
[I-D.ietf-6lo-backbone-router] specification. [I-D.ietf-6lo-backbone-router] specification.
IEEE Std. 802.15.4 [IEEEstd802154], the "6TiSCH architecture" In the context of the Timeslotted Channel Hopping (TSCH) mode of IEEE
Std. 802.15.4 [IEEEstd802154], the "6TiSCH architecture"
[I-D.ietf-6tisch-architecture] introduces how a 6LoWPAN ND host could [I-D.ietf-6tisch-architecture] introduces how a 6LoWPAN ND host could
connect to the Internet via a RPL mesh network, but this requires connect to the Internet via a RPL mesh network, but this requires
additions to the 6LoWPAN ND protocol to support mobility and additions to the 6LoWPAN ND protocol to support mobility and
reachability in a secured and manageable environment. This reachability in a secured and manageable environment. This
specification details the new operations that are required to specification details the new operations that are required to
implement the 6TiSCH architecture and serves the requirements listed implement the 6TiSCH architecture and serves the requirements listed
in Appendix B.2. in Appendix B.2.
The term LLN is used loosely in this specification to cover multiple The term LLN is used loosely in this specification to cover multiple
types of WLANs and WPANs, including Low-Power IEEE Std. 802.11 types of WLANs and WPANs, including Low-Power IEEE Std. 802.11
skipping to change at page 34, line 22 skipping to change at page 34, line 22
energy-constrained sleeping nodes. The value of such extension is energy-constrained sleeping nodes. The value of such extension is
especially apparent in the case of mobile wireless nodes, to reduce especially apparent in the case of mobile wireless nodes, to reduce
the multicast operations that are related to IPv6 ND ([RFC4861], the multicast operations that are related to IPv6 ND ([RFC4861],
[RFC4862]) and affect the operation of the wireless medium [RFC4862]) and affect the operation of the wireless medium
[I-D.ietf-mboned-ieee802-mcast-problems] [I-D.ietf-mboned-ieee802-mcast-problems]
[I-D.perkins-intarea-multicast-ieee802]. This serves the scalability [I-D.perkins-intarea-multicast-ieee802]. This serves the scalability
requirements listed in Appendix B.6. requirements listed in Appendix B.6.
Appendix B. Requirements (Not Normative) Appendix B. Requirements (Not Normative)
This section lists requirements that were discussed discussed by the This section lists requirements that were discussed by the 6lo WG for
6lo WG for an update to 6LoWPAN ND. How those requirements are an update to 6LoWPAN ND. How those requirements are matched with
matched with existing specifications at the time of this writing is existing specifications at the time of this writing is shown in
shown in Appendix B.8. Appendix B.8.
B.1. Requirements Related to Mobility B.1. Requirements Related to Mobility
Due to the unstable nature of LLN links, even in an LLN of immobile Due to the unstable nature of LLN links, even in an LLN of immobile
nodes a 6LN may change its point of attachment from 6LR-a to 6LR-b, nodes, a 6LN may change its point of attachment from 6LR-a to 6LR-b,
and may not be able to notify 6LR-a. Consequently, 6LR-a may still and may not be able to notify 6LR-a. Consequently, 6LR-a may still
attract traffic that it cannot deliver any more. When links to a 6LR attract traffic that it cannot deliver any more. When links to a 6LR
change state, there is thus a need to identify stale states in a 6LR change state, there is thus a need to identify stale states in a 6LR
and restore reachability in a timely fashion, e.g., by using some and restore reachability in a timely fashion, e.g., by using some
signaling upon the detection of the movement, or using a keep-alive signaling upon the detection of the movement, or using a keep-alive
mechanism with a period that is consistent with the application mechanism with a period that is consistent with the application
needs. needs.
Req1.1: Upon a change of point of attachment, connectivity via a new Req1.1: Upon a change of point of attachment, connectivity via a new
6LR MUST be restored in a timely fashion without the need to de- 6LR MUST be restored in a timely fashion without the need to de-
 End of changes. 21 change blocks. 
66 lines changed or deleted 84 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/