draft-ietf-6lo-rfc6775-update-00.txt   draft-ietf-6lo-rfc6775-update-01.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 Arista Networks Intended status: Standards Track Arista Networks
Expires: June 26, 2017 S. Chakrabarti Expires: July 14, 2017 S. Chakrabarti
Ericsson January 10, 2017
December 23, 2016
An Update to 6LoWPAN ND An Update to 6LoWPAN ND
draft-ietf-6lo-rfc6775-update-00 draft-ietf-6lo-rfc6775-update-01
Abstract Abstract
This specification updates 6LoWPAN Neighbor Discovery (RFC6775), to This specification updates 6LoWPAN Neighbor Discovery (RFC6775), 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
skipping to change at page 1, line 37 skipping to change at page 1, line 36
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 April 29, 2017. This Internet-Draft will expire on July 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 4 3. Updating RFC 6775 . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Extended Address Registration Option . . . . . . . . . . 4 3.1. Transaction ID . . . . . . . . . . . . . . . . . . . . . 4
3.2. Registering the Target Address . . . . . . . . . . . . . 5 3.2. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 5
3.3. Link-local Addresses and Registration . . . . . . . . . . 5 3.3. Extended Address Registration Option . . . . . . . . . . 5
4. Applicability and Requirements Served . . . . . . . . . . . . 7 3.4. Registering the Target Address . . . . . . . . . . . . . 6
5. The Enhanced Address Registration Option (EARO) . . . . . . . 7 3.5. Link-local Addresses and Registration . . . . . . . . . . 6
6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 11 4. Applicability and Requirements Served . . . . . . . . . . . . 8
6.1. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 11 5. The Enhanced Address Registration Option (EARO) . . . . . . . 8
6.2. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 11 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12
6.3. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 12 6.1. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 6.2. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6.3. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.3. External Informative References . . . . . . . . . . . . 16 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 15
A.1. Requirements Related to Mobility . . . . . . . . . . . . 17 10.3. External Informative References . . . . . . . . . . . . 17
A.2. Requirements Related to Routing Protocols . . . . . . . . 17 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 18
A.1. Requirements Related to Mobility . . . . . . . . . . . . 18
A.2. Requirements Related to Routing Protocols . . . . . . . . 18
A.3. Requirements Related to the Variety of Low-Power Link A.3. Requirements Related to the Variety of Low-Power Link
types . . . . . . . . . . . . . . . . . . . . . . . . . . 18 types . . . . . . . . . . . . . . . . . . . . . . . . . . 19
A.4. Requirements Related to Proxy Operations . . . . . . . . 19 A.4. Requirements Related to Proxy Operations . . . . . . . . 20
A.5. Requirements Related to Security . . . . . . . . . . . . 20 A.5. Requirements Related to Security . . . . . . . . . . . . 20
A.6. Requirements Related to Scalability . . . . . . . . . . . 21 A.6. Requirements Related to Scalability . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
IPv6 Neighbor Discovery (ND) Optimization for IPv6 over Low-Power
Wireless Personal Area Networks(6LoWPANs) [RFC6775] introduced a
proactive registration mechanism to IPv6 ND services that is well
suited to nodes belonging to a LLN.
The scope of this draft is an IPv6 Low Power Lossy Network (LLN), The scope of this draft is an IPv6 Low Power Lossy Network (LLN),
which can be a simple star or a more complex mesh topology. The LLN which can be a simple star or a more complex mesh topology. The LLN
may be anchored at an IPv6 Backbone Router (6BBR). The Backbone may be anchored at an IPv6 Backbone Router (6BBR). The Backbone
Routers interconnect the LLNs over a Backbone Link and emulate that Routers interconnect the LLNs over a Backbone Link and emulate that
the LLN nodes are present on the Backbone using proxy-ND operations. the LLN nodes are present on the Backbone using proxy-ND operations.
IPv6 Neighbor Discovery (ND) Optimization for IPv6 over Low-Power
Wireless Personal Area Networks(6LoWPANs) [RFC6775] introduced a
proactive registration mechanism to IPv6 ND services for nodes
belonging to a LLN.
This specification modifies and extends the behaviour and protocol This specification modifies and extends the behaviour and protocol
elements of [RFC6775] to enable additional capabilities, in elements of [RFC6775] to enable additional capabilities, in
particular the registration to a 6BBR for proxy ND operations particular the registration to a 6BBR for proxy ND operations
[I-D.ietf-6lo-backbone-router]. [I-D.ietf-6lo-backbone-router].
2. Terminology 2. 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 [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 4, line 27 skipping to change at page 4, line 27
route them over the LLN. 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.
3. Updating RFC 6775 3. Updating RFC 6775
The support of this specification is signaled in Router Advertisement The support of this specification is signaled in Router Advertisement
(RA) messages by 6LoWPAN Router (6LR) (how: tbd). Support for this (RA) messages by 6LoWPAN Router (6LR) (how: tbd). Support for this
specification can also be inferred from the update of the ARO option specification can also be inferred from the update of the ARO option
in the ND exchanges in the ND exchanges.
. 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 [RFC6775]. over that of [RFC6775].
3.1. Extended Address Registration Option 3.1. Transaction ID
The specification expects that the Registered Node can provide a
sequence number called Transaction ID (TID) that is incremented with
each re-registration. The TID essentially obeys the same rules as
the Path Sequence field in the Transit Information Option (TIO) found
in RPL's Destination Advertisement Object (DAO). This way, the LLN
node can use the same counter for ND and RPL, and a 6LBR acting as
RPL root may easily maintain the registration on behalf of a RPL node
deep inside the mesh by simply using the RPL TIO Path Sequence as TID
for EARO.
When a Registered Node is registered to multiple BBRs in parallel, it
is expected that the same TID is used, to enable the 6BBRs to
correlate the registrations as being a single one, and differentiate
that situation from a movement.
If the TIDs are different, the resolution inherited from RPL sorts
out the most recent registration and other ones are removed. The
operation for computing and comparing the Path Sequence is detailed
in section 7 of [RFC6550] and applies to the TID in the exact same
fashion.
3.2. Owner Unique ID
The Owner Unique ID (OUID) enables to differentiate a real duplicate
address registration from a double registration or a movement. An ND
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
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
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
avoided.
Alternatively, the unique ID can be a cryptographic string that can
can be used to prove the ownership of the registration as discussed
in Address Protected Neighbor Discovery for Low-power and Lossy
Networks [I-D.ietf-6lo-ap-nd].
In any fashion, it is recommended that the node stores the unique Id
or the keys used to generate that ID in persistent memory.
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
registration.
3.3. Extended Address Registration Option
This specification extends the Address Registration Option (ARO) used This specification extends the Address Registration Option (ARO) used
for the process of address registration. The new ARO is referred to for the process of address registration. The new ARO is referred to
as Extended ARO (EARO), and its semantics are modified as follows: as Extended ARO (EARO), and its semantics are modified as follows:
The address that is being registered with a Neighbor Solicitation The address that is being registered with a Neighbor Solicitation
(NS) with an EARO is now the Target Address, as opposed to the Source (NS) with an EARO is now the Target Address, as opposed to the Source
Address as specified in [RFC6775]. This change enables a 6LBR to use Address as specified in [RFC6775]. This change enables a 6LBR to use
an address of his as source to the proxy-registration of an address 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 that belongs to a LLN Node to a 6BBR. This also limits the use of an
skipping to change at page 5, line 11 skipping to change at page 6, line 11
Provable Temporary UID (PT-UID) as opposed to burn-in MAC address, 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 PT-UID providing a trusted anchor by the 6LR and 6LBR to protect
the state associated to the node. the state associated to the node.
The specification introduces a Transaction ID (TID) field in the The specification introduces a Transaction ID (TID) field in the
EARO. The TID MUST be provided by a node that supports this 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 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 can be used to determine whether the peer supports this
specification. specification.
3.2. Registering the Target Address 3.4. Registering the Target Address
One of the requirements that this specification serves is the One of the requirements that this specification serves is the
capability by a router such as a RPL root to proxy-register an capability by a router such as a RPL root to proxy-register an
address to a 6BBR on behalf of a 6LN, as discussed in Appendix A.4. address to a 6BBR on behalf of a 6LN, as discussed in Appendix A.4.
In order to serve that requirement, this specification changes the In order to serve that requirement, this specification changes the
behaviour of the 6LN and the 6LR so that the Registered Address is behaviour of the 6LN and the 6LR so that the Registered Address is
found in the Target Address field of the NS and NA messages as found in the Target Address field of the NS and NA messages as
opposed to the Source Address. opposed to the Source Address.
With this convention, a TLLA option would indicate the link-layer With this convention, a TLLA option would indicate the link-layer
address of the 6LN that owns the address, whereas the SLLA Option in address 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 a NS 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 [RFC6775], and it is REQUIRED that an maintain compatibility with [RFC6775], and it is REQUIRED that an
SLLA Option is always placed in a registration NS(EARO) message. SLLA Option is always placed in a registration NS(EARO) message.
3.3. Link-local Addresses and Registration 3.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 [RFC6775], this specification only requires that a link- Compared to [RFC6775], this specification only requires that a link-
local address is unique from the perspective of the peering nodes. local address is unique from the perspective of the peering nodes.
This simplifies the Duplicate Address Detection (DAD) for link-local This simplifies the Duplicate Address Detection (DAD) for link-local
addresses, and there is no DAR/DAC exchange between the 6LR and a addresses, and there is no DAR/DAC exchange between the 6LR and a
6LBR for link-local addresses. 6LBR for link-local addresses.
skipping to change at page 6, line 51 skipping to change at page 7, line 51
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 [RFC6775]. that MUST be placed in the NS(EARO) message as required in [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 [RFC6775], a via that 6LR. As opposed to a node that complies to [RFC6775], a
Registering Node registering a GUA does use that GUA as Source Registering Node registering a GUA does not use that GUA as Source
Address for the registration to a 6LR that conforms this 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 [RFC6775]. local addresses as prescribed by [RFC6775].
4. Applicability and Requirements Served 4. 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 A.1 by enabling the and serves the requirements expressed Appendix A.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 [I-D.ietf-6lo-backbone-router]. complementary work in [I-D.ietf-6lo-backbone-router].
In the context of the the TimeSlotted Channel Hopping (TSCH) mode of In the context of the the TimeSlotted Channel Hopping (TSCH) mode of
[IEEE802154], the 6TiSCH architecture [I-D.ietf-6tisch-architecture] [IEEEstd802154], the 6TiSCH architecture
introduces how a 6LoWPAN ND host could connect to the Internet via a [I-D.ietf-6tisch-architecture] introduces how a 6LoWPAN ND host could
RPL mesh Network, but this requires additions to the 6LOWPAN ND connect to the Internet via a RPL mesh Network, but this requires
protocol to support mobility and reachability in a secured and additions to the 6LOWPAN ND protocol to support mobility and
manageable environment. This specification details the new reachability in a secured and manageable environment. This
operations that are required to implement the 6TiSCH architecture and specification details the new operations that are required to
serves the requirements listed in Appendix A.2. implement the 6TiSCH architecture and serves the requirements listed
in Appendix A.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 Wi-Fi, BLUETOOTH(R) Low types of WLANs and WPANs, including Low-Power Wi-Fi, BLUETOOTH(R) Low
Energy, IEEE802.11AH and IEEE802.15.4 wireless meshes, so as to Energy, IEEE std 802.11AH and IEEE std 802.15.4 wireless meshes, so
address the requirements discussed in Appendix A.3 as to address the requirements discussed in Appendix A.3
This specification can be used by any wireless node to associate at This specification can be used by any wireless node to associate at
Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing
services including proxy-ND operations over the backbone, effectively services including proxy-ND operations over the backbone, effectively
providing a solution to the requirements expressed in Appendix A.4. providing a solution to the requirements expressed in Appendix A.4.
Efficiency aware IPv6 Neighbor Discovery Optimizations Efficiency aware IPv6 Neighbor Discovery Optimizations
[I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND
[RFC6775] can be extended to other types of links beyond IEEE802.15.4 [RFC6775] can be extended to other types of links beyond IEEE std
for which it was defined. The registration technique is beneficial 802.15.4 for which it was defined. The registration technique is
when the Link-Layer technique used to carry IPv6 multicast packets is beneficial when the Link-Layer technique used to carry IPv6 multicast
not sufficiently efficient in terms of delivery ratio or energy packets is not sufficiently efficient in terms of delivery ratio or
consumption in the end devices, in particular to enable energy- energy consumption in the end devices, in particular to enable
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 classical ND ([RFC4861], the multicast operations that are related to classical ND ([RFC4861],
[RFC4862]) and plague the wireless medium. This serves scalability [RFC4862]) and plague the wireless medium. This serves scalability
requirements listed in Appendix A.6. requirements listed in Appendix A.6.
5. The Enhanced Address Registration Option (EARO) 5. The Enhanced Address Registration Option (EARO)
With the ARO option defined in 6LoWPAN ND [RFC6775], the address With the ARO option defined in 6LoWPAN ND [RFC6775], the address
being registered and its owner can be uniquely identified and matched being registered and its owner can be uniquely identified and matched
with the Binding Table entries of each Backbone Router. with the Binding Table entries of each Backbone Router.
skipping to change at page 12, line 39 skipping to change at page 13, line 39
protected, either by means of physical or IP security for the protected, either by means of physical or IP security for the
Backbone Link or MAC sublayer cryptography. In particular, it is Backbone Link or MAC sublayer cryptography. In particular, it is
expected that the LLN MAC provides secure unicast to/from the expected that the LLN MAC provides secure unicast to/from the
Backbone Router and secure Broadcast from the Backbone Router in a Backbone Router and secure Broadcast from the Backbone Router in a
way that prevents tempering with or replaying the RA messages. way that prevents tempering with or replaying the RA messages.
The use of EUI-64 for forming the Interface ID in the link-local The use of EUI-64 for forming the Interface ID in the link-local
address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and
address privacy techniques. This specification RECOMMENDS the use of address privacy techniques. This specification RECOMMENDS the use of
additional protection against address theft such as provided by additional protection against address theft such as provided by
[I-D.sarikaya-6lo-ap-nd], which guarantees the ownership of the OUID. [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the OUID.
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.
skipping to change at page 14, line 39 skipping to change at page 15, line 39
6man-efficient-nd-07 (work in progress), February 2015. 6man-efficient-nd-07 (work in progress), February 2015.
[I-D.delcarpio-6lo-wlanah] [I-D.delcarpio-6lo-wlanah]
Vega, L., Robles, I., and R. Morabito, "IPv6 over Vega, L., Robles, I., and R. Morabito, "IPv6 over
802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in
progress), October 2015. progress), October 2015.
[I-D.ietf-6lo-6lobac] [I-D.ietf-6lo-6lobac]
Lynn, K., Martocci, J., Neilson, C., and S. Donaldson, Lynn, K., Martocci, J., Neilson, C., and S. Donaldson,
"Transmission of IPv6 over MS/TP Networks", draft-ietf- "Transmission of IPv6 over MS/TP Networks", draft-ietf-
6lo-6lobac-05 (work in progress), June 2016. 6lo-6lobac-06 (work in progress), October 2016.
[I-D.ietf-6lo-ap-nd]
Sarikaya, B., Thubert, P., and M. Sethi, "Address
Protected Neighbor Discovery for Low-power and Lossy
Networks", draft-ietf-6lo-ap-nd-00 (work in progress),
November 2016.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
backbone-router-02 (work in progress), September 2016. backbone-router-02 (work in progress), September 2016.
[I-D.ietf-6lo-dect-ule] [I-D.ietf-6lo-dect-ule]
Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D. Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D.
Barthel, "Transmission of IPv6 Packets over DECT Ultra Low Barthel, "Transmission of IPv6 Packets over DECT Ultra Low
Energy", draft-ietf-6lo-dect-ule-07 (work in progress), Energy", draft-ietf-6lo-dect-ule-09 (work in progress),
October 2016. December 2016.
[I-D.ietf-6lo-nfc] [I-D.ietf-6lo-nfc]
Choi, Y., Youn, J., and Y. Hong, "Transmission of IPv6 Choi, Y., Youn, J., and Y. Hong, "Transmission of IPv6
Packets over Near Field Communication", draft-ietf-6lo- Packets over Near Field Communication", draft-ietf-6lo-
nfc-05 (work in progress), October 2016. nfc-05 (work in progress), October 2016.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work
in progress), June 2016. in progress), June 2016.
[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-07 (work in 802.15.4e", draft-ietf-6tisch-terminology-08 (work in
progress), March 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-04 (work in Replication", draft-ietf-bier-architecture-05 (work in
progress), July 2016. progress), October 2016.
[I-D.ietf-ipv6-multilink-subnets] [I-D.ietf-ipv6-multilink-subnets]
Thaler, D. and C. Huitema, "Multi-link Subnet Support in Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
progress), July 2002. progress), July 2002.
[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]
Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets
over IEEE 1901.2 Narrowband Powerline Communication over IEEE 1901.2 Narrowband Powerline Communication
Networks", draft-popa-6lo-6loplc-ipv6-over- Networks", draft-popa-6lo-6loplc-ipv6-over-
ieee19012-networks-00 (work in progress), March 2014. ieee19012-networks-00 (work in progress), March 2014.
[I-D.sarikaya-6lo-ap-nd] [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
Sethi, M., Thubert, P., and B. Sarikaya, "Address CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September
Protected Neighbor Discovery for Low-power and Lossy 2003, <http://www.rfc-editor.org/info/rfc3610>.
Networks", draft-sarikaya-6lo-ap-nd-04 (work in progress),
August 2016.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004,
<http://www.rfc-editor.org/info/rfc3810>. <http://www.rfc-editor.org/info/rfc3810>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005, DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>. <http://www.rfc-editor.org/info/rfc3971>.
skipping to change at page 16, line 42 skipping to change at page 17, line 47
DOI 10.17487/RFC7428, February 2015, DOI 10.17487/RFC7428, February 2015,
<http://www.rfc-editor.org/info/rfc7428>. <http://www.rfc-editor.org/info/rfc7428>.
[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>.
10.3. External Informative References 10.3. External Informative References
[IEEE80211] [IEEEstd802154]
IEEE standard for Information Technology, "IEEE Standard
for Information technology-- Telecommunications and
information exchange between systems Local and
metropolitan area networks-- Specific requirements Part
11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications".
[IEEE802151]
IEEE standard for Information Technology, "IEEE Standard
for Information Technology - Telecommunications and
Information Exchange Between Systems - Local and
Metropolitan Area Networks - Specific Requirements. - Part
15.1: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Wireless Personal Area
Networks (WPANs)".
[IEEE802154]
IEEE standard for Information Technology, "IEEE Standard IEEE standard for Information Technology, "IEEE Standard
for Local and metropolitan area networks-- Part 15.4: Low- for Local and metropolitan area networks-- Part 15.4: Low-
Rate Wireless Personal Area Networks (LR-WPANs)". Rate Wireless Personal Area Networks (LR-WPANs)".
Appendix A. Requirements Appendix A. Requirements
This section lists requirements that were discussed at 6lo for an This section lists requirements that were discussed at 6lo for an
update to 6LoWPAN ND. This specification meets most of them, but update to 6LoWPAN ND. This specification meets most of them, but
those listed in Appendix A.5 which are deferred to a different those listed in Appendix A.5 which are deferred to a different
specification such as [I-D.sarikaya-6lo-ap-nd]. specification such as [I-D.ietf-6lo-ap-nd].
A.1. Requirements Related to Mobility A.1. Requirements Related to Mobility
Due to the unstable nature of LLN links, even in a LLN of immobile Due to the unstable nature of LLN links, even in a LLN of immobile
nodes a 6LN may change its point of attachment to a 6LR, say 6LR-a, nodes a 6LN may change its point of attachment to a 6LR, say 6LR-a,
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. and restore reachability in a timely fashion.
skipping to change at page 18, line 46 skipping to change at page 19, line 35
option, a RPLInstanceID. option, a RPLInstanceID.
Req2.3: Multicast operations SHOULD be supported and optimized, for Req2.3: Multicast operations SHOULD be supported and optimized, for
instance using BIER or MPL. Whether ND is appropriate for the instance using BIER or MPL. Whether ND is appropriate for the
registration to the 6BBR is to be defined, considering the additional registration to the 6BBR is to be defined, considering the additional
burden of supporting the Multicast Listener Discovery Version 2 burden of supporting the Multicast Listener Discovery Version 2
[RFC3810] (MLDv2) for IPv6. [RFC3810] (MLDv2) for IPv6.
A.3. Requirements Related to the Variety of Low-Power Link types A.3. Requirements Related to the Variety of Low-Power Link types
6LoWPAN ND [RFC6775] was defined with a focus on IEEE802.15.4 and in 6LoWPAN ND [RFC6775] was defined with a focus on IEEE std 802.15.4
particular the capability to derive a unique Identifier from a and in particular the capability to derive a unique Identifier from a
globally unique MAC-64 address. At this point, the 6lo Working Group globally unique MAC-64 address. At this point, the 6lo Working Group
is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique
to other link types ITU-T G.9959 [RFC7428], Master-Slave/Token- to other link types ITU-T G.9959 [RFC7428], Master-Slave/Token-
Passing [I-D.ietf-6lo-6lobac], DECT Ultra Low Energy Passing [I-D.ietf-6lo-6lobac], DECT Ultra Low Energy
[I-D.ietf-6lo-dect-ule], Near Field Communication [I-D.ietf-6lo-nfc], [I-D.ietf-6lo-dect-ule], Near Field Communication [I-D.ietf-6lo-nfc],
IEEE802.11ah [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 IEEE std 802.11ah [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2
Narrowband Powerline Communication Networks Narrowband Powerline Communication Networks
[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R) [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R)
Low Energy [RFC7668]. Low Energy [RFC7668].
Related requirements are: Related requirements are:
Req3.1: The support of the registration mechanism SHOULD be extended Req3.1: The support of the registration mechanism SHOULD be extended
to more LLN links than IEEE 802.15.4, matching at least the LLN links to more LLN links than IEEE std 802.15.4, matching at least the LLN
for which an "IPv6 over foo" specification exists, as well as Low- links for which an "IPv6 over foo" specification exists, as well as
Power Wi-Fi. Low-Power Wi-Fi.
Req3.2: As part of this extension, a mechanism to compute a unique Req3.2: As part of this extension, a mechanism to compute a unique
Identifier should be provided, with the capability to form a Link- Identifier should be provided, with the capability to form a Link-
Local Address that SHOULD be unique at least within the LLN connected Local Address that SHOULD be unique at least within the LLN connected
to a 6LBR discovered by ND in each node within the LLN. to a 6LBR discovered by ND in each node within the LLN.
Req3.3: The Address Registration Option used in the ND registration Req3.3: The Address Registration Option used in the ND registration
SHOULD be extended to carry the relevant forms of unique Identifier. SHOULD be extended to carry the relevant forms of unique Identifier.
Req3.4: The Neighbour Discovery should specify the formation of a Req3.4: The Neighbour Discovery should specify the formation of a
skipping to change at page 20, line 39 skipping to change at page 21, line 27
their respective roles, as well as with the 6LoWPAN Node for the role their respective roles, as well as with the 6LoWPAN Node for the role
of 6LR. of 6LR.
Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for
the 6LR and the 6LBR to validate new registration of authorized the 6LR and the 6LBR to validate new registration of authorized
nodes. Joining of unauthorized nodes MUST be impossible. nodes. Joining of unauthorized nodes MUST be impossible.
Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet
sizes. In particular, the NS, NA, DAR and DAC messages for a re- sizes. In particular, the NS, NA, DAR and DAC messages for a re-
registration flow SHOULD NOT exceed 80 octets so as to fit in a registration flow SHOULD NOT exceed 80 octets so as to fit in a
secured IEEE802.15.4 frame. secured IEEE std 802.15.4 [IEEEstd802154] frame.
Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be
computationally intensive on the LoWPAN Node CPU. When a Key hash computationally intensive on the LoWPAN Node CPU. When a Key hash
calculation is employed, a mechanism lighter than SHA-1 SHOULD be calculation is employed, a mechanism lighter than SHA-1 SHOULD be
preferred. preferred.
Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate
SHOULD be minimized. SHOULD be minimized.
Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable CCM* for use Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable the
at both Layer 2 and Layer 3, and SHOULD enable the reuse of security variation of CCM [RFC3610] called CCM* for use at both Layer 2 and
code that has to be present on the device for upper layer security Layer 3, and SHOULD enable the reuse of security code that has to be
such as TLS. present on the device for upper layer security such as TLS.
Req5.7: Public key and signature sizes SHOULD be minimized while Req5.7: Public key and signature sizes SHOULD be minimized while
maintaining adequate confidentiality and data origin authentication maintaining adequate confidentiality and data origin authentication
for multiple types of applications with various degrees of for multiple types of applications with various degrees of
criticality. criticality.
Req5.8: Routing of packets should continue when links pass from the Req5.8: Routing of packets should continue when links pass from the
unsecured to the secured state. unsecured to the secured state.
Req5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for Req5.9: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for
skipping to change at page 22, line 4 skipping to change at page 22, line 34
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254 MOUGINS - Sophia Antipolis 06254
FRANCE FRANCE
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Erik Nordmark Erik Nordmark
Arista Networks Arista Networks
Santa Clara, CA Santa Clara, CA
USA USA
Email: nordmark@arista.com Email: nordmark@arista.com
Samita Chakrabarti Samita Chakrabarti
Ericsson
San Jose, CA San Jose, CA
USA USA
Email: samita.chakrabarti@ericsson.com Email: samitac.ietf@gmail.com
 End of changes. 35 change blocks. 
100 lines changed or deleted 134 lines changed or added

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