draft-ietf-6lo-backbone-router-03.txt   draft-ietf-6lo-backbone-router-04.txt 
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft cisco Internet-Draft cisco
Intended status: Standards Track January 11, 2017 Intended status: Standards Track July 17, 2017
Expires: July 15, 2017 Expires: January 18, 2018
IPv6 Backbone Router IPv6 Backbone Router
draft-ietf-6lo-backbone-router-03 draft-ietf-6lo-backbone-router-04
Abstract Abstract
This specification proposes an update to IPv6 Neighbor Discovery, to This specification proposes an update to IPv6 Neighbor Discovery, to
enhance the operation of IPv6 over wireless links that exhibit lossy enhance the operation of IPv6 over wireless links that exhibit lossy
multicast support, and enable a large degree of scalability by multicast support, and enable a large degree of scalability by
splitting the broadcast domains. A higher speed backbone federates splitting the broadcast domains. A broadcast-efficient backbone
multiple wireless links to form a large MultiLink Subnet. Backbone running classical IPv6 Neighbor Discovery federates multiple wireless
Routers acting as Layer-3 Access Point route packets to registered links to form a large MultiLink Subnet, but the broadcast domain does
nodes, where an classical Layer-2 Access Point would bridge. not need to extend to the wireless links for the purpose of ND
Conversely, wireless nodes register or are proxy-registered to the operation. Backbone Routers placed at the wireless edge of the
Backbone Router to setup routing services in a fashion that is backbone proxy the ND operation and route packets from/to registered
nodes, and wireless nodes register or are proxy-registered to the
Backbone Router to setup proxy services in a fashion that is
essentially similar to a classical Layer-2 association. essentially similar to a classical Layer-2 association.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 15, 2017. This Internet-Draft will expire on January 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Applicability and Requirements Served . . . . . . . . . . . . 5 2. Applicability and Requirements Served . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Backbone Router Routing Operations . . . . . . . . . . . . . 10 5. Backbone Router Routing Operations . . . . . . . . . . . . . 9
5.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 10 5.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 10
5.2. Over the LLN Link . . . . . . . . . . . . . . . . . . . . 12 5.2. Over the LLN Link . . . . . . . . . . . . . . . . . . . . 11
6. BackBone Router Proxy Operations . . . . . . . . . . . . . . 13 6. BackBone Router Proxy Operations . . . . . . . . . . . . . . 13
6.1. Registration and Binding State Creation . . . . . . . . . 16 6.1. Registration and Binding State Creation . . . . . . . . . 15
6.2. Defending Addresses . . . . . . . . . . . . . . . . . . . 17 6.2. Defending Addresses . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 18 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 20
11.3. External Informative References . . . . . . . . . . . . 24 11.3. External Informative References . . . . . . . . . . . . 23
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 24 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 24
A.1. Requirements Related to Mobility . . . . . . . . . . . . 24 A.1. Requirements Related to Mobility . . . . . . . . . . . . 24
A.2. Requirements Related to Routing Protocols . . . . . . . . 25 A.2. Requirements Related to Routing Protocols . . . . . . . . 25
A.3. Requirements Related to the Variety of Low-Power Link A.3. Requirements Related to the Variety of Low-Power Link
types . . . . . . . . . . . . . . . . . . . . . . . . . . 26 types . . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.4. Requirements Related to Proxy Operations . . . . . . . . 26 A.4. Requirements Related to Proxy Operations . . . . . . . . 26
A.5. Requirements Related to Security . . . . . . . . . . . . 27 A.5. Requirements Related to Security . . . . . . . . . . . . 27
A.6. Requirements Related to Scalability . . . . . . . . . . . 28 A.6. Requirements Related to Scalability . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Classical IPv6 Neighbor Discovery [RFC4862] operations are reactive One of the key services provided by IEEE std. 802.1 [IEEEstd8021]
and rely heavily on multicast operations to locate a correspondent. Ethernet Bridging is an efficient and reliable broadcast service, and
When this was designed, it was a natural match for the transparent multiple applications and protocols have been built that heavily
bridging operation of Ethernet. Access Points defined by IEEE std depends on that feature for their core operation. But a wide range
802.11 [IEEEstd80211] effectively act as bridges, but, in order to of wireless networks do not provide the solid and cheap broadcast
protect the medium, they do not implement transparent bridging. capabilities of Ethernet Bridging, and protocols designed for bridged
Instead, a so-called association process is used to register networks that rely on broadcast often exhibit disappointing
proactively the MAC addresses of the wireless STAs to the APs. behaviours when applied unmodified to a wireless medium.
Sadly, the IPv6 ND operation was not adapted to match that model.
Though in most cases, including Low-Power ones, IEEE std 802.11 is
operated as a wireless extension to an Ethernet bridged domain, the
impact of radio broadcasts for IPv6 [RFC2460] multicast operations,
in particular related to the power consumption of battery-operated
devices, lead the community to rethink the plain layer-2 approach and
consider splitting the broadcast domain between the wired and the
wireless access links. To that effect, the current IEEE std 802.11
specifications require the capability to perform ARP and ND proxy
[RFC4389] functions at the Access Points (APs), but rely on snooping
for acquiring the related state, which is unsatisfactory in a lossy
and mobile environments.
Without a proxy, any IP multicast that circulates in the bridged IEEE std. 802.11 [IEEEstd80211] Access Points (APs) deployed in an
domain ends up broadcasted by the Access Points to all STAs, Extended Service Set (ESS) effectively act as bridges, but, in order
including Low-Power battery-operated ones. With an incorrect or to ensure a solid connectivity to the devices and protect the medium
missing state in the proxy, a packet may not be delivered to the against harmful broadcasts, they refrain from relying on broadcast-
destination, which may have operational impacts depending on the intensive protocols such as Transparent Bridging on the wireless
criticality of the packet. side. Instead, an association process is used to register
proactively the MAC addresses of the wireless device (STA) to the AP,
and then the APs proxy the bridging operation and cancel the
broadcasts.
Some messages are lost for the lack of retries, regardless of their Classical IPv6 [RFC8200] Neighbor Discovery [RFC4862] Protocol (NDP)
degree of criticality; it results for instance that Duplicate Address operations are reactive and rely heavily on multicast operations to
Detection (DAD) as defined in [RFC4862] is mostly broken over Wi-Fi locate an on-link correspondent and ensure address uniqueness, which
[I-D.yourtchenko-6man-dad-issues]. is a pillar that sustains the whole IP architecture. When the
Duplicate Address Detection [RFC4862] (DAD) mechanism was designed,
it was a natural match with the efficient broadcast operation of
Ethernet Bridging, but with the unreliable broadcast that is typical
of wireless media, DAD is bound to fail to discover duplications
[I-D.yourtchenko-6man-dad-issues]. In other words, because the
broadcast service is unreliable, DAD appears to work on wireless
media not because address duplication is detected and solved as
designed, but because the duplication is a very rare event as a side
effect of the sheer amount of entropy in 64-bits Interface IDs.
On the other hand, IPv6 multicast messages are processed by most if In the real world, IPv6 multicast messages are effectively broadcast,
not all wireless nodes over the fabric even when very few if any of so they are processed by most if not all wireless nodes over the ESS
the nodes is effectively listening to the multicast address. It fabric even when very few if any of the nodes is effectively
results that a simple Neighbor Solicitation (NS) message [RFC4861], listening to the multicast address. It results that a simple
that is supposedly targeted to a very small group of nodes, ends up Neighbor Solicitation (NS) lookup message [RFC4861], that is
polluting the whole wireless bandwidth across the fabric supposedly targeted to a very small group of nodes, ends up polluting
[I-D.vyncke-6man-mcast-not-efficient]. the whole wireless bandwidth across the fabric
[I-D.vyncke-6man-mcast-not-efficient]. In other words, the reactive
IPv6 ND operation leads to undesirable power consumption in battery-
operated devices.
It appears that in a variety of Wireless Local Area Networks (WLANs) The inefficiencies of using radio broadcasts to support IPv6 NDP lead
and Wireless Personal Area Networks (WPANs), the decision to leverage the community to consider (again) splitting the broadcast domain
the broadcast support of a particular link should be left to Layer-3 between the wired and the wireless access links. One classical way
based on the criticality of the message and the number of interested to achieve this is to split the subnet in multiple ones, and at the
listeners on that link, for the lack of capability to indicate that extreme provide a /64 per wireless device. Another is to proxy the
criticality to the lower layer. To achieve this, the operation at Layer-3 protocols that rely on broadcast operation at the boundary of
the Access Point cannot be a Layer-2 bridge operation, but that of a the wired and wireless domains, effectively emulating the Layer-2
Layer-3 router; the concept of MultiLink Subnet (MLSN) must be association at layer-3. To that effect, the current IEEE std. 802.11
reintroduced, with IPv6 backbone routers (6BBRs) interconnecting the specifications require the capability to perform ARP and ND proxy
various links and routing within the subnet. For link-scope [RFC4389] functions at the Access Points (APs).
multicast operations, a 6BBR participates to MLD on its access links
and a multicast routing protocol is setup between the 6BBRs over the
backbone of the MLSN.
As the network scales up, none of the approaches of using either But for the lack a comprehensive specification for the ND proxy and
broadcast or N*unicast for a multicast packet is really satisfying in particular the lack of an equivalent to an association process,
and the protocols themselves need to be adapted to reduce their use implementations have to rely on snooping for acquiring the related
of multicast. state, which is unsatisfactory in a lossy and mobile conditions.
With snooping, a state (e.g. a new IPv6 address) may not be
discovered or a change of state (e.g. a movement) may be missed,
leading to unreliable connectivity.
One degree of improvement can be achieved by changing the tuning of In the context of IEEE std. 802.15.4 [IEEEstd802154], the step of
the protocol parameters and operational practices, such as suggested considering the radio as a medium that is different from Ethernet was
in Reducing energy consumption of Router Advertisements [RFC7772] already taken with the publication of Neighbor Discovery Optimization
(RA). This works enables to lower the rate of RA messages but does for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
not solve the problem associated with multicast NS and NA messages, [RFC6775]. RFC 6775 is updated as [I-D.ietf-6lo-rfc6775-update]; the
which are a lot more frequent in large-scale radio environments with update includes changes that are required by this document.
mobile devices which exhibit intermittent access patterns and short-
lived IPv6 addresses.
In the context of IEEE std 802.15.4 [IEEEstd802154], the more drastic This specification applies that same thinking to other wireless links
step of considering the radio as a medium that is different from such as Low-Power IEEE std. 802.11 (Wi-Fi) and IEEE std. 802.15.1
Ethernet because of the impact of multicast, was already taken with
the adoption of Neighbor Discovery Optimization for IPv6 over Low-
Power Wireless Personal Area Networks (6LoWPANs) [RFC6775]. This
specification applies that same thinking to other wireless links such
as Low-Power IEEE std 802.11 (Wi-Fi) and IEEE std 802.15.1
(Bluetooth) [IEEEstd802151], and extends [RFC6775] to enable proxy (Bluetooth) [IEEEstd802151], and extends [RFC6775] to enable proxy
operation by the 6BBR so as to decouple the broadcast domain in the operation by the 6BBR so as to decouple the broadcast domain in the
backbone from the wireless links. The proxy operation can be backbone from the wireless links. The proxy operation can be
maintained asynchronous so that low-power nodes or nodes that are maintained asynchronous so that low-power nodes or nodes that are
deep in a mesh do not need to be bothered synchronously when a lookup deep in a mesh do not need to be bothered synchronously when a lookup
is performed for their addresses, effectively implementing the ND is performed for their addresses, effectively implementing the ND
contribution to the concept of a Sleep Proxy contribution to the concept of a Sleep Proxy
[I-D.nordmark-6man-dad-approaches]. [I-D.nordmark-6man-dad-approaches].
RFC 6775 is updated as [I-D.ietf-6lo-rfc6775-update]; the update
includes changes that are required by this document, so it is a
prerequisite.
DHCPv6 [RFC3315] is still a viable option in Low power and Lossy
Network (LLN) to assign IPv6 global addresses. However, the IETF
standard that supports address assignment specifically for LLNs is
6LoWPAN ND [RFC6775], which is a mix of IPv6 stateless
autoconfiguration mechanism (SLAAC) [RFC4862] and a new registration
process for ND. This specification introduces a Layer-3 association
process based on 6LoWPAN ND that maintains a proxy state in the 6BBR
to keep the LLN nodes reachable and protect their addresses through
sleeping periods.
A number of use cases, including the Industrial Internet, require a
large scale deployment of monitoring sensors that can only be
realized in a cost-effective fashion with wireless technologies.
Mesh networks are deployed when simpler hub-and-spoke topologies are
not sufficient for the expected size, throughput, and density.
Meshes imply the routing of packets, operated at either Layer-2 or
Layer-3. For routing over a mesh at Layer-3, the IETF has designed
the IPv6 Routing Protocol over LLN (RPL) [RFC6550]. 6LoWPAN ND was
designed as a stand-alone mechanism separately from RPL, and the
interaction between the 2 protocols was not defined. This
specification details how periodic updates from RPL can be used by
the RPL root to renew the association of the RPL node to the 6BBR on
its behalf so as to maintain the proxy operation active for that
node.
This document suggests a limited evolution to [RFC6775] so as to
allow operation of a 6LoWPAN ND node while a routing protocol (in
first instance RPL) is present and operational. It also suggests a
more generalized use of the information in the ARO option of the ND
messages outside the strict LLN domain, for instance over a
federating backbone.
2. Applicability and Requirements Served 2. Applicability and Requirements Served
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 IEEE std [RFC6775] can be extended to other types of links beyond IEEE std.
802.15.4 for which it was defined. The registration technique is 802.15.4 for which it was defined. The registration technique is
beneficial when the Link-Layer technique used to carry IPv6 multicast beneficial when the Link-Layer technique used to carry IPv6 multicast
packets is not sufficiently efficient in terms of delivery ratio or packets is not sufficiently efficient in terms of delivery ratio or
energy consumption in the end devices, in particular to enable energy consumption in the end devices, in particular to enable
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 classical ND ([RFC4861], the multicast operations that are related to classical ND ([RFC4861],
[RFC4862]) and plague the wireless medium. [RFC4862]) and plague the wireless medium.
This specification updates and generalizes 6LoWPAN ND to a broader This specification updates and generalizes 6LoWPAN ND to a broader
range of Low power and Lossy Networks (LLNs) with a solid support for range of Low power and Lossy Networks (LLNs) with a solid support for
Duplicate Address Detection (DAD) and address lookup that does not Duplicate Address Detection (DAD) and address lookup that does not
require broadcasts over the LLNs. The term LLN is used loosely in require broadcasts over the LLNs. The term LLN is used loosely in
this specification to cover multiple types of WLANs and WPANs, this specification to cover multiple types of WLANs and WPANs,
including Low-Power Wi-Fi, BLUETOOTH(R) Low Energy, IEEE std 802.11AH including Low-Power Wi-Fi, BLUETOOTH(R) Low Energy, IEEE std.
and IEEE std 802.15.4 wireless meshes, so as to address the 802.11AH and IEEE std. 802.15.4 wireless meshes, so as to address the
requirements listed in Appendix A.3 requirements listed in Appendix A.3
The scope of this draft is a Backbone Link that federates multiple The scope of this draft is a Backbone Link that federates multiple
LLNs as a single IPv6 MultiLink Subnet. Each LLN in the subnet is LLNs as a single IPv6 MultiLink Subnet. Each LLN in the subnet is
anchored at an IPv6 Backbone Router (6BBR). The Backbone Routers anchored at an IPv6 Backbone Router (6BBR). The Backbone Routers
interconnect the LLNs over the Backbone Link and emulate that the LLN interconnect the LLNs over the Backbone Link and emulate that the LLN
nodes are present on the Backbone using proxy-ND operations. This nodes are present on the Backbone using proxy-ND operations. This
specification extends IPv6 ND over the backbone to discriminate specification extends IPv6 ND over the backbone to discriminate
address movement from duplication and eliminate stale state in the address movement from duplication and eliminate stale state in the
backbone routers and backbone nodes once a LLN node has roamed. This backbone routers and backbone nodes once a LLN node has roamed. This
way, mobile nodes may roam rapidly from a 6BBR to the next and way, mobile nodes may roam rapidly from a 6BBR to the next and
requirements in Appendix A.1 are met. requirements in Appendix A.1 are met.
skipping to change at page 6, line 35 skipping to change at page 5, line 43
In the context of the the TimeSlotted Channel Hopping (TSCH) mode of In the context of the the TimeSlotted Channel Hopping (TSCH) mode of
[IEEEstd802154], the 6TiSCH architecture [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 A.2. in Appendix A.2.
In the case of Low-Power IEEE std 802.11, a 6BBR may be collocated In the case of Low-Power IEEE std. 802.11, a 6BBR may be collocated
with a standalone AP or a CAPWAP [RFC5415] wireless controller, and with a standalone AP or a CAPWAP [RFC5415] wireless controller, and
the wireless client (STA) leverages this specification to register the wireless client (STA) leverages this specification to register
its IPv6 address(es) to the 6BBR over the wireless medium. In the its IPv6 address(es) to the 6BBR over the wireless medium. In the
case of a 6TiSCH LLN mesh, the RPL root is collocated with a 6LoWPAN case of a 6TiSCH LLN mesh, the RPL root is collocated with a 6LoWPAN
Border Router (6LBR), and either collocated with or connected to the Border Router (6LBR), and either collocated with or connected to the
6BBR over an IPv6 Link. The 6LBR leverages this specification to 6BBR over an IPv6 Link. The 6LBR leverages this specification to
register the LLN nodes on their behalf to the 6BBR. In the case of register the LLN nodes on their behalf to the 6BBR. In the case of
BTLE, the 6BBR is collocated with the router that implements the BTLE BTLE, the 6BBR is collocated with the router that implements the BTLE
central role as discussed in section 2.2 of [RFC7668]. central role as discussed in section 2.2 of [RFC7668].
skipping to change at page 19, line 20 skipping to change at page 19, line 11
Kudos to Eric Levy-Abegnoli who designed the First Hop Security Kudos to Eric Levy-Abegnoli who designed the First Hop Security
infrastructure at Cisco. infrastructure at Cisco.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-6lo-rfc6775-update] [I-D.ietf-6lo-rfc6775-update]
Thubert, P., Nordmark, E., and S. Chakrabarti, "An Update Thubert, P., Nordmark, E., and S. Chakrabarti, "An Update
to 6LoWPAN ND", draft-ietf-6lo-rfc6775-update-00 (work in to 6LoWPAN ND", draft-ietf-6lo-rfc6775-update-06 (work in
progress), December 2016. progress), June 2017.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>. 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<http://www.rfc-editor.org/info/rfc4429>. <http://www.rfc-editor.org/info/rfc4429>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
skipping to change at page 20, line 23 skipping to change at page 20, line 11
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>. <http://www.rfc-editor.org/info/rfc6550>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>. <http://www.rfc-editor.org/info/rfc6775>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<http://www.rfc-editor.org/info/rfc8200>.
11.2. Informative References 11.2. Informative References
[I-D.chakrabarti-nordmark-6man-efficient-nd] [I-D.chakrabarti-nordmark-6man-efficient-nd]
Chakrabarti, S., Nordmark, E., Thubert, P., and M. Chakrabarti, S., Nordmark, E., Thubert, P., and M.
Wasserman, "IPv6 Neighbor Discovery Optimizations for Wasserman, "IPv6 Neighbor Discovery Optimizations for
Wired and Wireless Networks", draft-chakrabarti-nordmark- Wired and Wireless Networks", draft-chakrabarti-nordmark-
6man-efficient-nd-07 (work in progress), February 2015. 6man-efficient-nd-07 (work in progress), February 2015.
[I-D.delcarpio-6lo-wlanah] [I-D.delcarpio-6lo-wlanah]
Vega, L., Robles, I., and R. Morabito, "IPv6 over Vega, L., Robles, I., and R. Morabito, "IPv6 over
802.11ah", draft-delcarpio-6lo-wlanah-01 (work in 802.11ah", draft-delcarpio-6lo-wlanah-01 (work in
progress), October 2015. progress), October 2015.
[I-D.ietf-6lo-6lobac]
Lynn, K., Martocci, J., Neilson, C., and S. Donaldson,
"Transmission of IPv6 over MS/TP Networks", draft-ietf-
6lo-6lobac-06 (work in progress), October 2016.
[I-D.ietf-6lo-ap-nd] [I-D.ietf-6lo-ap-nd]
Sarikaya, B., Thubert, P., and M. Sethi, "Address Sarikaya, B., Thubert, P., and M. Sethi, "Address
Protected Neighbor Discovery for Low-power and Lossy Protected Neighbor Discovery for Low-power and Lossy
Networks", draft-ietf-6lo-ap-nd-00 (work in progress), Networks", draft-ietf-6lo-ap-nd-02 (work in progress), May
November 2016. 2017.
[I-D.ietf-6lo-dect-ule]
Mariager, P., Petersen, J., Shelby, Z., Logt, M., and D.
Barthel, "Transmission of IPv6 Packets over DECT Ultra Low
Energy", draft-ietf-6lo-dect-ule-09 (work in progress),
December 2016.
[I-D.ietf-6lo-nfc] [I-D.ietf-6lo-nfc]
Choi, Y., Youn, J., and Y. Hong, "Transmission of IPv6 Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi,
Packets over Near Field Communication", draft-ietf-6lo- "Transmission of IPv6 Packets over Near Field
nfc-05 (work in progress), October 2016. Communication", draft-ietf-6lo-nfc-07 (work in progress),
June 2017.
[I-D.ietf-6man-rs-refresh] [I-D.ietf-6man-rs-refresh]
Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6
Neighbor Discovery Optional RS/RA Refresh", draft-ietf- Neighbor Discovery Optional RS/RA Refresh", draft-ietf-
6man-rs-refresh-02 (work in progress), October 2016. 6man-rs-refresh-02 (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-11 (work
in progress), June 2016. in progress), January 2017.
[I-D.ietf-6tisch-terminology] [I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terminology in IPv6 over the TSCH mode of IEEE "Terminology in IPv6 over the TSCH mode of IEEE
802.15.4e", draft-ietf-6tisch-terminology-08 (work in 802.15.4e", draft-ietf-6tisch-terminology-09 (work in
progress), December 2016. progress), June 2017.
[I-D.ietf-bier-architecture] [I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-ietf-bier-architecture-05 (work in Replication", draft-ietf-bier-architecture-07 (work in
progress), October 2016. progress), June 2017.
[I-D.ietf-ipv6-multilink-subnets] [I-D.ietf-ipv6-multilink-subnets]
Thaler, D. and C. Huitema, "Multi-link Subnet Support in Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in
progress), July 2002. progress), July 2002.
[I-D.nordmark-6man-dad-approaches] [I-D.nordmark-6man-dad-approaches]
Nordmark, E., "Possible approaches to make DAD more robust Nordmark, E., "Possible approaches to make DAD more robust
and/or efficient", draft-nordmark-6man-dad-approaches-02 and/or efficient", draft-nordmark-6man-dad-approaches-02
(work in progress), October 2015. (work in progress), October 2015.
skipping to change at page 22, line 11 skipping to change at page 21, line 45
Yourtchenko, "Why Network-Layer Multicast is Not Always Yourtchenko, "Why Network-Layer Multicast is Not Always
Efficient At Datalink Layer", draft-vyncke-6man-mcast-not- Efficient At Datalink Layer", draft-vyncke-6man-mcast-not-
efficient-01 (work in progress), February 2014. efficient-01 (work in progress), February 2014.
[I-D.yourtchenko-6man-dad-issues] [I-D.yourtchenko-6man-dad-issues]
Yourtchenko, A. and E. Nordmark, "A survey of issues Yourtchenko, A. and E. Nordmark, "A survey of issues
related to IPv6 Duplicate Address Detection", draft- related to IPv6 Duplicate Address Detection", draft-
yourtchenko-6man-dad-issues-01 (work in progress), March yourtchenko-6man-dad-issues-01 (work in progress), March
2015. 2015.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <http://www.rfc-editor.org/info/rfc3315>.
[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 24, line 5 skipping to change at page 23, line 35
[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>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy [RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
Consumption of Router Advertisements", BCP 202, RFC 7772, Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016, DOI 10.17487/RFC7772, February 2016,
<http://www.rfc-editor.org/info/rfc7772>. <http://www.rfc-editor.org/info/rfc7772>.
[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt,
M., and D. Barthel, "Transmission of IPv6 Packets over
Digital Enhanced Cordless Telecommunications (DECT) Ultra
Low Energy (ULE)", RFC 8105, DOI 10.17487/RFC8105, May
2017, <http://www.rfc-editor.org/info/rfc8105>.
[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S.
Donaldson, "Transmission of IPv6 over Master-Slave/Token-
Passing (MS/TP) Networks", RFC 8163, DOI 10.17487/RFC8163,
May 2017, <http://www.rfc-editor.org/info/rfc8163>.
11.3. External Informative References 11.3. External Informative References
[IEEEstd8021]
IEEE standard for Information Technology, "IEEE Standard
for Information technology-- Telecommunications and
information exchange between systems Local and
metropolitan area networks Part 1: Bridging and
Architecture".
[IEEEstd80211] [IEEEstd80211]
IEEE standard for Information Technology, "IEEE Standard IEEE standard for Information Technology, "IEEE Standard
for Information technology-- Telecommunications and for Information technology-- Telecommunications and
information exchange between systems Local and information exchange between systems Local and
metropolitan area networks-- Specific requirements Part metropolitan area networks-- Specific requirements Part
11: Wireless LAN Medium Access Control (MAC) and Physical 11: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications". Layer (PHY) Specifications".
[IEEEstd802151] [IEEEstd802151]
IEEE standard for Information Technology, "IEEE Standard IEEE standard for Information Technology, "IEEE Standard
skipping to change at page 26, line 9 skipping to change at page 26, line 13
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 IEEE std 802.15.4 6LoWPAN ND [RFC6775] was defined with a focus on IEEE std. 802.15.4
and in 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 [RFC8163], DECT Ultra Low Energy [RFC8105], Near Field
[I-D.ietf-6lo-dect-ule], Near Field Communication [I-D.ietf-6lo-nfc], Communication [I-D.ietf-6lo-nfc], IEEE std. 802.11ah
IEEE std 802.11ah [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 Narrowband
Narrowband Powerline Communication Networks 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 802.15.4, matching at least the LLN links
for which an "IPv6 over foo" specification exists, as well as Low- for which an "IPv6 over foo" specification exists, as well as Low-
Power Wi-Fi. Power Wi-Fi.
skipping to change at page 27, line 50 skipping to change at page 28, line 8
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 IEEE std 802.15.4 frame. secured IEEE std. 802.15.4 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 CCM* for use
 End of changes. 39 change blocks. 
170 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/