draft-ietf-6lo-backbone-router-02.txt   draft-ietf-6lo-backbone-router-03.txt 
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft cisco Internet-Draft cisco
Intended status: Standards Track September 19, 2016 Intended status: Standards Track January 11, 2017
Expires: March 23, 2017 Expires: July 15, 2017
IPv6 Backbone Router IPv6 Backbone Router
draft-ietf-6lo-backbone-router-02 draft-ietf-6lo-backbone-router-03
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 higher speed backbone federates
multiple wireless links to form a large MultiLink Subnet. Backbone multiple wireless links to form a large MultiLink Subnet. Backbone
Routers acting as Layer-3 Access Point route packets to registered Routers acting as Layer-3 Access Point route packets to registered
nodes, where an classical Layer-2 Access Point would bridge. nodes, where an classical Layer-2 Access Point would bridge.
Conversely, wireless nodes register to the Backbone Router to setup Conversely, wireless nodes register or are proxy-registered to the
routing services in a fashion that is essentially similar to a Backbone Router to setup routing services in a fashion that is
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 March 23, 2017. This Internet-Draft will expire on July 15, 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. Applicability and Requirements Served . . . . . . . . . . . . 5 2. Applicability and Requirements Served . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. New Types And Formats . . . . . . . . . . . . . . . . . . . . 11 5. Backbone Router Routing Operations . . . . . . . . . . . . . 10
5.1. Transaction ID . . . . . . . . . . . . . . . . . . . . . 11 5.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 10
5.2. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 11 5.2. Over the LLN Link . . . . . . . . . . . . . . . . . . . . 12
5.3. The Enhanced Address Registration Option (EARO) . . . . . 12 6. BackBone Router Proxy Operations . . . . . . . . . . . . . . 13
6. Backbone Router Routing Operations . . . . . . . . . . . . . 14 6.1. Registration and Binding State Creation . . . . . . . . . 16
6.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 14 6.2. Defending Addresses . . . . . . . . . . . . . . . . . . . 17
6.2. Over the LLN Link . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. BackBone Router Proxy Operations . . . . . . . . . . . . . . 17 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 18
7.1. Registration and Binding State Creation . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
7.2. Defending Addresses . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 20
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 11.3. External Informative References . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 A.1. Requirements Related to Mobility . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 24 A.2. Requirements Related to Routing Protocols . . . . . . . . 25
12.3. External Informative References . . . . . . . . . . . . 28
Appendix A. Requirements . . . . . . . . . . . . . . . . . . . . 29
A.1. Requirements Related to Mobility . . . . . . . . . . . . 29
A.2. Requirements Related to Routing Protocols . . . . . . . . 29
A.3. Requirements Related to the Variety of Low-Power Link A.3. Requirements Related to the Variety of Low-Power Link
types . . . . . . . . . . . . . . . . . . . . . . . . . . 30 types . . . . . . . . . . . . . . . . . . . . . . . . . . 26
A.4. Requirements Related to Proxy Operations . . . . . . . . 31 A.4. Requirements Related to Proxy Operations . . . . . . . . 26
A.5. Requirements Related to Security . . . . . . . . . . . . 31 A.5. Requirements Related to Security . . . . . . . . . . . . 27
A.6. Requirements Related to Scalability . . . . . . . . . . . 33 A.6. Requirements Related to Scalability . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 33 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
Classical IPv6 Neighbor Discovery [RFC4862] operations are reactive Classical IPv6 Neighbor Discovery [RFC4862] operations are reactive
and rely heavily on multicast operations to locate a correspondent. and rely heavily on multicast operations to locate a correspondent.
When this was designed, it was a natural match for the transparent When this was designed, it was a natural match for the transparent
bridging operation of Ethernet. IEEE 802.11 Access Points IEEE802.11 bridging operation of Ethernet. Access Points defined by IEEE std
[IEEE80211] effectively act as bridges, but, in order to protect the 802.11 [IEEEstd80211] effectively act as bridges, but, in order to
medium, they do not implement transparent bridging. Instead, a so- protect the medium, they do not implement transparent bridging.
called association process is used to register proactively the MAC Instead, a so-called association process is used to register
addresses of the wireless STAs to the APs. Sadly, the IPv6 ND proactively the MAC addresses of the wireless STAs to the APs.
operation was not adapted to match that model. Sadly, the IPv6 ND operation was not adapted to match that model.
Though in most cases, including Low-Power ones, IEEE802.11 is Though in most cases, including Low-Power ones, IEEE std 802.11 is
operated as a wireless extension to an Ethernet bridged domain, the operated as a wireless extension to an Ethernet bridged domain, the
impact of radio broadcasts for IPv6 [RFC2460] multicast operations, impact of radio broadcasts for IPv6 [RFC2460] multicast operations,
in particular related to the power consumption of battery-operated in particular related to the power consumption of battery-operated
devices, lead the community to rethink the plain layer-2 approach and devices, lead the community to rethink the plain layer-2 approach and
consider splitting the broadcast domain between the wired and the consider splitting the broadcast domain between the wired and the
wireless access links. To that effect, the current IEEE802.11 wireless access links. To that effect, the current IEEE std 802.11
specifications require the capability to perform ARP and ND proxy specifications require the capability to perform ARP and ND proxy
[RFC4389] functions at the Access Points (APs), but rely on snooping [RFC4389] functions at the Access Points (APs), but rely on snooping
for acquiring the related state, which is unsatisfactory in a lossy for acquiring the related state, which is unsatisfactory in a lossy
and mobile environments. and mobile environments.
Without a proxy, any IP multicast that circulates in the bridged Without a proxy, any IP multicast that circulates in the bridged
domain ends up broadcasted by the Access Points to all STAs, domain ends up broadcasted by the Access Points to all STAs,
including Low-Power battery-operated ones. With an incorrect or including Low-Power battery-operated ones. With an incorrect or
missing state in the proxy, a packet may not be delivered to the missing state in the proxy, a packet may not be delivered to the
destination, which may have operational impacts depending on the destination, which may have operational impacts depending on the
skipping to change at page 4, line 21 skipping to change at page 4, line 16
One degree of improvement can be achieved by changing the tuning of One degree of improvement can be achieved by changing the tuning of
the protocol parameters and operational practices, such as suggested the protocol parameters and operational practices, such as suggested
in Reducing energy consumption of Router Advertisements [RFC7772] in Reducing energy consumption of Router Advertisements [RFC7772]
(RA). This works enables to lower the rate of RA messages but does (RA). This works enables to lower the rate of RA messages but does
not solve the problem associated with multicast NS and NA messages, not solve the problem associated with multicast NS and NA messages,
which are a lot more frequent in large-scale radio environments with which are a lot more frequent in large-scale radio environments with
mobile devices which exhibit intermittent access patterns and short- mobile devices which exhibit intermittent access patterns and short-
lived IPv6 addresses. lived IPv6 addresses.
In the context of IEEE802.15.4 [IEEE802154], the more drastic step of In the context of IEEE std 802.15.4 [IEEEstd802154], the more drastic
considering the radio as a medium that is different from Ethernet step of considering the radio as a medium that is different from
because of the impact of multicast, was already taken with the Ethernet because of the impact of multicast, was already taken with
adoption of Neighbor Discovery Optimization for IPv6 over Low-Power the adoption of Neighbor Discovery Optimization for IPv6 over Low-
Wireless Personal Area Networks (6LoWPANs) [RFC6775]. This Power Wireless Personal Area Networks (6LoWPANs) [RFC6775]. This
specification applies that same thinking to other wireless links such specification applies that same thinking to other wireless links such
as Low-Power IEEE802.11 (Wi-Fi) and IEEE802.15.1 (Bluetooth) as Low-Power IEEE std 802.11 (Wi-Fi) and IEEE std 802.15.1
[IEEE802151], and extends [RFC6775] to enable proxy operation by the (Bluetooth) [IEEEstd802151], and extends [RFC6775] to enable proxy
6BBR so as to decouple the broadcast domain in the backbone from the operation by the 6BBR so as to decouple the broadcast domain in the
wireless links. The proxy operation can be maintained asynchronous backbone from the wireless links. The proxy operation can be
so that low-power nodes or nodes that are deep in a mesh do not need maintained asynchronous so that low-power nodes or nodes that are
to be bothered synchronously when a lookup is performed for their deep in a mesh do not need to be bothered synchronously when a lookup
addresses, effectively implementing the ND contribution to the is performed for their addresses, effectively implementing the ND
concept of a Sleep Proxy [I-D.nordmark-6man-dad-approaches]. contribution to the concept of a Sleep Proxy
[I-D.nordmark-6man-dad-approaches].
RFC 6775 is now being updated as [I-D.thubert-6lo-rfc6775-update]; RFC 6775 is updated as [I-D.ietf-6lo-rfc6775-update]; the update
this upodate duplicates some text from this document, and the intent includes changes that are required by this document, so it is a
to migrate what is common to the update document once it is adopted. prerequisite.
DHCPv6 [RFC3315] is still a viable option in Low power and Lossy DHCPv6 [RFC3315] is still a viable option in Low power and Lossy
Network (LLN) to assign IPv6 global addresses. However, the IETF Network (LLN) to assign IPv6 global addresses. However, the IETF
standard that supports address assignment specifically for LLNs is standard that supports address assignment specifically for LLNs is
6LoWPAN ND [RFC6775], which is a mix of IPv6 stateless 6LoWPAN ND [RFC6775], which is a mix of IPv6 stateless
autoconfiguration mechanism (SLAAC) [RFC4862] and a new registration autoconfiguration mechanism (SLAAC) [RFC4862] and a new registration
process for ND. This specification introduces a Layer-3 association process for ND. This specification introduces a Layer-3 association
process based on 6LoWPAN ND that maintains a proxy state in the 6BBR process based on 6LoWPAN ND that maintains a proxy state in the 6BBR
to keep the LLN nodes reachable and protect their addresses through to keep the LLN nodes reachable and protect their addresses through
sleeping periods. sleeping periods.
skipping to change at page 5, line 28 skipping to change at page 5, line 24
allow operation of a 6LoWPAN ND node while a routing protocol (in allow operation of a 6LoWPAN ND node while a routing protocol (in
first instance RPL) is present and operational. It also suggests a first instance RPL) is present and operational. It also suggests a
more generalized use of the information in the ARO option of the ND more generalized use of the information in the ARO option of the ND
messages outside the strict LLN domain, for instance over a messages outside the strict LLN domain, for instance over a
federating backbone. 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 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. [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, IEEE802.11AH and including Low-Power Wi-Fi, BLUETOOTH(R) Low Energy, IEEE std 802.11AH
IEEE802.15.4 wireless meshes, so as to address the requirements and IEEE std 802.15.4 wireless meshes, so as to address the
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
skipping to change at page 6, line 29 skipping to change at page 6, line 26
(Bridging proxy), or that of the 6BBR on the backbone, in which case (Bridging proxy), or that of the 6BBR on the backbone, in which case
the 6BBRs needs to route the unicast packets (Routing proxy). In the the 6BBRs needs to route the unicast packets (Routing proxy). In the
latter case, the 6BBR may maintain the list of correspondents to latter case, the 6BBR may maintain the list of correspondents to
which it has advertised its own MAC address on behalf of the LLN node which it has advertised its own MAC address on behalf of the LLN node
and the IPv6 ND operation is minimized as the number of nodes scale and the IPv6 ND operation is minimized as the number of nodes scale
up in the LLN. This enables to meet the requirements in Appendix A.6 up in the LLN. This enables to meet the requirements in Appendix A.6
as long has the 6BBRs are dimensioned for the number of registration as long has the 6BBRs are dimensioned for the number of registration
that each needs to support. that each needs to support.
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.
In the case of Low-Power IEEE802.11, a 6BBR may be collocated with a In the case of Low-Power IEEE std 802.11, a 6BBR may be collocated
standalone AP or a CAPWAP [RFC5415] wireless controller, and the with a standalone AP or a CAPWAP [RFC5415] wireless controller, and
wireless client (STA) leverages this specification to register its the wireless client (STA) leverages this specification to register
IPv6 address(es) to the 6BBR over the wireless medium. In the case its IPv6 address(es) to the 6BBR over the wireless medium. In the
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].
3. Terminology 3. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 7, line 26 skipping to change at page 7, line 20
Neighbor Discovery Optimization for Low-power and Lossy Networks Neighbor Discovery Optimization for Low-power and Lossy Networks
[RFC6775] and "Multi-link Subnet Support in IPv6" [RFC6775] and "Multi-link Subnet Support in IPv6"
[I-D.ietf-ipv6-multilink-subnets]. [I-D.ietf-ipv6-multilink-subnets].
Readers would benefit from reading "Multi-Link Subnet Issues" Readers would benefit from reading "Multi-Link Subnet Issues"
[RFC4903], ,"Mobility Support in IPv6" [RFC6275], "Neighbor Discovery [RFC4903], ,"Mobility Support in IPv6" [RFC6275], "Neighbor Discovery
Proxies (ND Proxy)" [RFC4389] and "Optimistic Duplicate Address Proxies (ND Proxy)" [RFC4389] and "Optimistic Duplicate Address
Detection" [RFC4429] prior to this specification for a clear Detection" [RFC4429] prior to this specification for a clear
understanding of the art in ND-proxying and binding. understanding of the art in ND-proxying and binding.
Additionally, this document uses terminology from [RFC7102] and Additionally, this document uses terminology from [RFC7102],
[I-D.ietf-6tisch-terminology], and introduces the following [I-D.ietf-6lo-rfc6775-update] and [I-D.ietf-6tisch-terminology], and
terminology: introduces the following terminology:
LLN Low Power Lossy Network. Used loosely in this specification to
represent WLANs and WPANs. See [RFC4919]
Backbone This is an IPv6 transit link that interconnects 2 or more
Backbone Routers. It is expected to be deployed as a high
speed backbone in order to federate a potentially large set of
LLNS. Also referred to as a LLN backbone or Backbone network.
Backbone Router An IPv6 router that federates the LLN using a
Backbone link as a backbone. A BBR acts as a 6LoWPAN Border
Routers (6LBR) and an Energy Aware Default Router (NEAR).
Extended LLN This is the aggregation of multiple LLNs as defined in
[RFC4919], interconnected by a Backbone Link via Backbone
Routers, and forming a single IPv6 MultiLink Subnet.
Registration The process during which a wireless Node registers its
address(es) with the Border Router so the 6BBR can proxy ND for
it over the backbone.
Binding The state in the 6BBR that associates an IP address with a
MAC address, a port and some other information about the node
that owns the IP address.
Registered Node The node for which the registration is performed,
which owns the fields in the EARO option.
Registering Node The node that performs the registration to the
6BBR, either for one of its own addresses, in which case it is
Registered Node and indicates its own MAC Address as SLLA in
the NS(ARO), or on behalf of a Registered Node that is
reachable over a LLN mesh. In the latter case, if the
Registered Node is reachable from the 6BBR over a Mesh-Under
mesh, the Registering Node indicates the MAC Address of the
Registered Node as SLLA in the NS(ARO). Otherwise, it is
expected that the Registered Device is reachable over a Route-
Over mesh from the Registering Node, in which case the SLLA in
the NS(ARO) is that of the Registering Node, which causes it to
attract the packets from the 6BBR to the Registered Node and
route them over the LLN.
Registered Address The address owned by the Registered Node node
that is being registered.
Sleeping Proxy A 6BBR acts as a Sleeping Proxy if it answers ND Sleeping Proxy A 6BBR acts as a Sleeping Proxy if it answers ND
Neighbor Solicitation over the backbone on behalf of the Neighbor Solicitation over the backbone on behalf of the
Registered Node whenever possible. This is the default mode Registered Node whenever possible. This is the default mode
for this specification but it may be overridden, for instance for this specification but it may be overridden, for instance
by configuration, into Unicasting Proxy. by configuration, into Unicasting Proxy.
Unicasting Proxy As a Unicasting Proxy, the 6BBR forwards NS Unicasting Proxy As a Unicasting Proxy, the 6BBR forwards NS
messages to the Registering Node, transforming Layer-2 messages to the Registering Node, transforming Layer-2
multicast into unicast whenever possible. multicast into unicast whenever possible.
skipping to change at page 10, line 12 skipping to change at page 9, line 9
Figure 1: Backbone Link and Backbone Routers Figure 1: Backbone Link and Backbone Routers
The Backbone Routers maintain an abstract Binding Table of their The Backbone Routers maintain an abstract Binding Table of their
Registered Nodes. The Binding Table operates as a distributed Registered Nodes. The Binding Table operates as a distributed
database of all the wireless Nodes whether they reside on the LLNs or database of all the wireless Nodes whether they reside on the LLNs or
on the backbone, and use an extension to the Neighbor Discovery on the backbone, and use an extension to the Neighbor Discovery
Protocol to exchange that information across the Backbone in the Protocol to exchange that information across the Backbone in the
classical ND reactive fashion. classical ND reactive fashion.
The Address Registration Option (ARO) defined in [RFC6775] is The Extended Address Registration Option (ARO) defined in
extended to enable the registration for routing and proxy Neighbor [I-D.ietf-6lo-rfc6775-update] is used to enable the registration for
Discovery operations by the 6BBR, and the Extended ARO (EARO) option routing and proxy Neighbor Discovery operations by the 6BBR, and the
is included in the ND exchanges over the backbone between the 6BBRs Extended ARO (EARO) option is included in the ND exchanges over the
to sort out duplication from movement. backbone between the 6BBRs to sort out duplication from movement.
Address duplication is sorted out with the Owner Unique-ID field in Address duplication is sorted out with the Owner Unique-ID field in
the EARO, which is a generalization of the EUI-64 that allows the EARO, which is a generalization of the EUI-64 that allows
different types of unique IDs beyond the name space derived from the different types of unique IDs beyond the name space derived from the
MAC addresses. First-Come First-Serve rules apply, whether the MAC addresses. First-Come First-Serve rules apply, whether the
duplication happens between LLN nodes as represented by their duplication happens between LLN nodes as represented by their
respective 6BBRs, or between an LLN node and a classical node that respective 6BBRs, or between an LLN node and a classical node that
defends its address over the backbone with classical ND and does not defends its address over the backbone with classical ND and does not
include the EARO option. include the EARO option.
skipping to change at page 11, line 8 skipping to change at page 10, line 7
The Optimistic Duplicate Address Detection [RFC4429] (ODAD) The Optimistic Duplicate Address Detection [RFC4429] (ODAD)
specification details how an address can be used before a Duplicate specification details how an address can be used before a Duplicate
Address Detection (DAD) is complete, and insists that an address that Address Detection (DAD) is complete, and insists that an address that
is TENTATIVE should not be associated to a Source Link-Layer Address is TENTATIVE should not be associated to a Source Link-Layer Address
Option in a Neighbor Solicitation message. This specification Option in a Neighbor Solicitation message. This specification
leverages ODAD to create a temporary proxy state in the 6BBR till DAD leverages ODAD to create a temporary proxy state in the 6BBR till DAD
is completed over the backbone. This way, the specification enables is completed over the backbone. This way, the specification enables
to distribute proxy states across multiple 6BBR and co-exist with to distribute proxy states across multiple 6BBR and co-exist with
classical ND over the backbone. classical ND over the backbone.
5. New Types And Formats 5. Backbone Router Routing Operations
5.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.
5.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.sarikaya-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.
5.3. The Enhanced Address Registration Option (EARO)
With the ARO option defined in 6LoWPAN ND [RFC6775], the address
being registered and its owner can be uniquely identified and matched
with the Binding Table entries of each Backbone Router.
The Enhanced Address Registration Option (EARO) is intended to be
used as a replacement to the ARO option within Neighbor Discovery NS
and NA messages between a LLN node and its 6LoWPAN Router (6LR), as
well as in Duplicate Address Request (DAR) and the Duplicate Address
Confirmation (DAC) messages between 6LRs and 6LBRs in LLNs meshes
such as 6TiSCH networks.
An NS message with an EARO option is a registration if and only if it
also carries an SLLAO option. The AERO option also used in NS and NA
messages between Backbone Routers over the backbone link to sort out
the distributed registration state, and in that case, it does not
carry the SLLAO option and is not confused with a registration.
The EARO extends the ARO and is recognized by the setting of the TID
bit. A node that supports this specification MUST always use an EARO
as a replacement to an ARO in its registration to a router. This is
harmless since the TID bit and fields are reserved in [RFC6775] are
ignored by a legacy router. A router that supports this
specification answers to an ARO with an ARO and to an EARO with an
EARO.
This specification changes the behavior of the peers in a
registration flows. To enable backward compatibility, a node that
registers to a router that is not known to support this specification
MUST behave as prescribed by [RFC6775]. Once the router is known to
support this specification, the node MUST obey this specification.
When using the EARO option, the address being registered is found in
the Target Address field of the NS and NA messages. This differs
from 6LoWPAN ND [RFC6775] which specifies that the address being
registered is the source of the NS.
The reason for this change is to enable proxy-registrations on behalf
of other nodes in Route-Over meshes, for instance to enable that a
RPL root registers addresses on behalf LLN nodes that are deeper in a
6TiSCH mesh. In that case, the Registering Node MUST indicate its
own address as source of the ND message and its MAC address in the
Source Link-Layer Address Option (SLLAO), since it still expects to
get the packets and route them down the mesh. But the Registered
Address belongs to another node, the Registered Node, and that
address is indicated in the Target Address field of the NS message.
One way of achieving all the above is for a node to first register an
address that it owns in order to validate that the router supports
this specification, placing the same address in the Source and Target
Address fields of the NS message. The node may for instance register
an address that is based on EUI-64. For such address, DAD is not
required and using the SLLAO option in the NS is actually more
amenable with older ND specifications such as ODAD [RFC4429].
Once that first registration is complete, the node knows from the
setting of the TID in the response whether the router supports this
specification. If this is verified, the node may register other
addresses that it owns, or proxy-register addresses on behalf some
another node, indicating those addresses being registered in the
Target Address field of the NS messages, while using one of its own,
already registered, addresses as source.
The format of the EARO option is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length = 2 | Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |T| TID | Registration Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Owner Unique ID (EUI-64 or equivalent) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: EARO
Option Fields
Type:
Length: 2
Status: OK=0; Duplicate=1; Full=2; Moved=3; Removed=4;
Reserved: This field is unused. It MUST be initialized to zero by
the sender and MUST be ignored by the receiver.
T: One bit flag. Set if the next octet is a used as a TID.
TID: 1-byte integer; a transaction id that is maintained by the node
and incremented with each transaction. it is recommended that the
node maintains the TID in a persistent storage.
Registration Lifetime: 16-bit integer; expressed in minutes. 0
means that the registration has ended and the state should be
removed.
Owner Unique Identifier: A globally unique identifier for the node
associated. This can be the EUI-64 derived IID of an interface,
or some provable ID obtained cryptographically.
6. Backbone Router Routing Operations
| |
+-----+ +-----+
| | Other (default) Router | | Other (default) Router
| | | |
+-----+ +-----+
| /64 | /64
| Backbone Link | Backbone Link
+-------------------+-------------------+ +-------------------+-------------------+
| /64 | /64 | /64 | /64 | /64 | /64
skipping to change at page 14, line 42 skipping to change at page 10, line 30
| | router | | router | | router | | router | | router | | router
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
o N*/128 o o o M*/128 o o P*/128 o N*/128 o o o M*/128 o o P*/128
o o o o o o o o o o o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o o o o o o o
o o o o o o o o o o o o o o
LLN LLN LLN LLN LLN LLN
Figure 3: Routing Configuration in the ML Subnet Figure 2: Routing Configuration in the ML Subnet
6.1. Over the Backbone Link 5.1. Over the Backbone Link
The Backbone Router is a specific kind of Border Router that performs The Backbone Router is a specific kind of Border Router that performs
proxy Neighbor Discovery on its backbone interface on behalf of the proxy Neighbor Discovery on its backbone interface on behalf of the
nodes that it has discovered on its LLN interfaces. nodes that it has discovered on its LLN interfaces.
The backbone is expected to be a high speed, reliable Backbone link, The backbone is expected to be a high speed, reliable Backbone link,
with affordable and reliable multicast capabilities, such as a with affordable and reliable multicast capabilities, such as a
bridged Ethernet Network, and to allow a full support of classical ND bridged Ethernet Network, and to allow a full support of classical ND
as specified in [RFC4861] and subsequent RFCs. In other words, the as specified in [RFC4861] and subsequent RFCs. In other words, the
backbone is not a LLN. backbone is not a LLN.
skipping to change at page 16, line 14 skipping to change at page 12, line 5
defined in [RFC4861] may be too impatient, and the support of defined in [RFC4861] may be too impatient, and the support of
[RFC7048] is recommended in all nodes in the network. [RFC7048] is recommended in all nodes in the network.
Since the MultiLink Subnet may grow very large in terms of individual Since the MultiLink Subnet may grow very large in terms of individual
IPv6 addresses, multicasts should be avoided as much as possible even IPv6 addresses, multicasts should be avoided as much as possible even
on the backbone. Though it is possible for plain hosts to on the backbone. Though it is possible for plain hosts to
participate with legacy IPv6 ND support, the support by all nodes participate with legacy IPv6 ND support, the support by all nodes
connected to the backbone of [I-D.ietf-6man-rs-refresh] is connected to the backbone of [I-D.ietf-6man-rs-refresh] is
recommended, and this implies the support of [RFC7559] as well. recommended, and this implies the support of [RFC7559] as well.
6.2. Over the LLN Link 5.2. Over the LLN Link
As a router, the Nodes and Backbone Router operation on the LLN As a router, the Nodes and Backbone Router operation on the LLN
follows [RFC6775]. Per that specification, LLN Hosts generally do follows [RFC6775]. Per that specification, LLN Hosts generally do
not depend on multicast RAs to discover routers. It is still not depend on multicast RAs to discover routers. It is still
generally required for LLN nodes to accept multicast RAs [RFC7772], generally required for LLN nodes to accept multicast RAs [RFC7772],
but those are rare on the LLN link. Nodes are expected to follow the but those are rare on the LLN link. Nodes are expected to follow the
Simple Procedures for Detecting Network Attachment in IPv6 [RFC6059] Simple Procedures for Detecting Network Attachment in IPv6 [RFC6059]
(DNA procedures) to assert movements, and to support the Packet-Loss (DNA procedures) to assert movements, and to support the Packet-Loss
Resiliency for Router Solicitations [RFC7559] to make the unicast RS Resiliency for Router Solicitations [RFC7559] to make the unicast RS
more reliable. more reliable.
skipping to change at page 17, line 23 skipping to change at page 13, line 14
If a registration moves from one 6BBR to the next, but the If a registration moves from one 6BBR to the next, but the
Registering Node does not change, as indicated by the S/TLLAO option Registering Node does not change, as indicated by the S/TLLAO option
in the ND exchanges, there is no need to update the Neighbor Caches in the ND exchanges, there is no need to update the Neighbor Caches
in the peers Nodes on the backbone. On the other hand, if the LLAO in the peers Nodes on the backbone. On the other hand, if the LLAO
changes, the 6BBR SHOULD inform all the relevant peers as described changes, the 6BBR SHOULD inform all the relevant peers as described
above, to update the impacted Neighbor Caches. In the same fashion, above, to update the impacted Neighbor Caches. In the same fashion,
if the Registering Node changes with a new registration, the 6BBR if the Registering Node changes with a new registration, the 6BBR
SHOULD also update the impacted Neighbor Caches over the backbone. SHOULD also update the impacted Neighbor Caches over the backbone.
7. BackBone Router Proxy Operations 6. BackBone Router Proxy Operations
This specification enables a Backbone Router to proxy Neighbor This specification enables a Backbone Router to proxy Neighbor
Discovery operations over the backbone on behalf of the nodes that Discovery operations over the backbone on behalf of the nodes that
are registered to it, allowing any node on the backbone to reach a are registered to it, allowing any node on the backbone to reach a
Registered Node as if it was on-link. The backbone and the LLNs are Registered Node as if it was on-link. The backbone and the LLNs are
considered different Links in a MultiLink subnet but the prefix that considered different Links in a MultiLink subnet but the prefix that
is used may still be advertised as on-link on the backbone to support is used may still be advertised as on-link on the backbone to support
legacy nodes; multicast ND messages are link-scoped and not forwarded legacy nodes; multicast ND messages are link-scoped and not forwarded
across the backbone routers. across the backbone routers.
skipping to change at page 20, line 18 skipping to change at page 16, line 5
same Registering Node are ignored; same Registering Node are ignored;
identical and older registrations (not-newer TID, same OUID) from identical and older registrations (not-newer TID, same OUID) from
a different Registering Node are responded immediately with a a different Registering Node are responded immediately with a
status of 3 (moved); this may be rate limited to protect the status of 3 (moved); this may be rate limited to protect the
medium; medium;
and any registration for a different Registered Node (different and any registration for a different Registered Node (different
OUID) are responded immediately with a status of 1 (duplicate). OUID) are responded immediately with a status of 1 (duplicate).
7.1. Registration and Binding State Creation 6.1. Registration and Binding State Creation
Upon a registration for a new address with an NS(EARO), the 6BBR Upon a registration for a new address with an NS(EARO), the 6BBR
performs a DAD operation over the backbone placing the new address as performs a DAD operation over the backbone placing the new address as
target in the NS-DAD message. The EARO from the registration MUST be target in the NS-DAD message. The EARO from the registration MUST be
placed unchanged in the NS-DAD message, and an entry is created in placed unchanged in the NS-DAD message, and an entry is created in
TENTATIVE state for a duration of TENTATIVE_DURATION. The NS-DAD TENTATIVE state for a duration of TENTATIVE_DURATION. The NS-DAD
message is sent multicast over the backbone to the SNMA address message is sent multicast over the backbone to the SNMA address
associated with the registered address. If that operation is known associated with the registered address. If that operation is known
to be costly, and the 6BBR has an indication from another source to be costly, and the 6BBR has an indication from another source
(such as a NCE) that the Registered Address was present on the (such as a NCE) that the Registered Address was present on the
skipping to change at page 21, line 20 skipping to change at page 17, line 7
do not support ODAD. do not support ODAD.
o When the TENTATIVE_DURATION timer elapses, a status 0 (success) is o When the TENTATIVE_DURATION timer elapses, a status 0 (success) is
returned in a NA(EARO) back to the Registering Node(s), and the returned in a NA(EARO) back to the Registering Node(s), and the
entry goes to REACHABLE state for the Registration Lifetime; the entry goes to REACHABLE state for the Registration Lifetime; the
DAD process is successful and the 6BBR MUST send a multicast DAD process is successful and the 6BBR MUST send a multicast
NA(EARO) to the SNMA associated to the Registered Address over the NA(EARO) to the SNMA associated to the Registered Address over the
backbone with the Override bit set so as to take over the binding backbone with the Override bit set so as to take over the binding
from other 6BBRs. from other 6BBRs.
7.2. Defending Addresses 6.2. Defending Addresses
If a 6BBR has an entry in REACHABLE state for a Registered Address: If a 6BBR has an entry in REACHABLE state for a Registered Address:
o If the 6BBR is primary, or does not support the concept, it MUST o If the 6BBR is primary, or does not support the concept, it MUST
defend that address over the backbone upon an incoming NS-DAD, defend that address over the backbone upon an incoming NS-DAD,
either if the NS does not carry an EARO, or if an EARO is present either if the NS does not carry an EARO, or if an EARO is present
that indicates a different Registering Node (different OUID). The that indicates a different Registering Node (different OUID). The
6BBR sends a NA message with the Override bit set and the NA 6BBR sends a NA message with the Override bit set and the NA
carries an EARO option if and only if the NS-DAD did so. When carries an EARO option if and only if the NS-DAD did so. When
present, the EARO in the NA(O) that is sent in response to the NS- present, the EARO in the NA(O) that is sent in response to the NS-
skipping to change at page 21, line 46 skipping to change at page 17, line 33
registration, the 6BBR updates the entry and the routing state to registration, the 6BBR updates the entry and the routing state to
forward packets to the new 6BBR, but keeps the entry REACHABLE. forward packets to the new 6BBR, but keeps the entry REACHABLE.
In that phase, it MAY use REDIRECT messages to reroute traffic for In that phase, it MAY use REDIRECT messages to reroute traffic for
the Registered Address to the new 6BBR. the Registered Address to the new 6BBR.
o If the 6BBR receives an NA(EARO) that reflect a newer o If the 6BBR receives an NA(EARO) that reflect a newer
registration, the 6BBR removes its entry and sends a NA(AERO) with registration, the 6BBR removes its entry and sends a NA(AERO) with
a status of 3 (moved) to the Registering Node, if the Registering a status of 3 (moved) to the Registering Node, if the Registering
Node is different from the Registered Node. If necessary, the Node is different from the Registered Node. If necessary, the
6BBR cleans up ND cache in peers nodes as discussed in 6BBR cleans up ND cache in peers nodes as discussed in
Section 6.1, by sending a series of unicast to the impacted nodes, Section 5.1, by sending a series of unicast to the impacted nodes,
or one broadcast NA(O) to all-nodes. or one broadcast NA(O) to all-nodes.
o If the 6BBR received a NS(LOOKUP) for a Registered Address, it o If the 6BBR received a NS(LOOKUP) for a Registered Address, it
answers immediately with an NA on behalf of the Registered Node, answers immediately with an NA on behalf of the Registered Node,
without polling it. There is no need of an EARO in that exchange. without polling it. There is no need of an EARO in that exchange.
o When the Registration-Lifetime timer elapses, the entry goes to o When the Registration-Lifetime timer elapses, the entry goes to
STALE state for a duration of STABLE_STALE_DURATION in LLNs that STALE state for a duration of STABLE_STALE_DURATION in LLNs that
keep stable addresses such as LWPANs, and UNSTABLE_STALE_DURATION keep stable addresses such as LWPANs, and UNSTABLE_STALE_DURATION
in LLNs where addresses are renewed rapidly, e.g. for privacy in LLNs where addresses are renewed rapidly, e.g. for privacy
skipping to change at page 22, line 31 skipping to change at page 18, line 20
o If the 6BBR received a NS(LOOKUP) for a Registered Address, the o If the 6BBR received a NS(LOOKUP) for a Registered Address, the
6BBR MUST send an NS(NUD) following rules in [RFC7048] to the 6BBR MUST send an NS(NUD) following rules in [RFC7048] to the
registering Node targeting the Registered Address prior to registering Node targeting the Registered Address prior to
answering. If the NUD succeeds, the operation in REACHABLE state answering. If the NUD succeeds, the operation in REACHABLE state
applies. If the NUD fails, the 6BBR refrains from answering the applies. If the NUD fails, the 6BBR refrains from answering the
lookup. The NUD expected to be mapped by the Registering Node lookup. The NUD expected to be mapped by the Registering Node
into a liveliness validation of the Registered Node if they are in into a liveliness validation of the Registered Node if they are in
fact different nodes. fact different nodes.
8. Security Considerations 7. Security Considerations
This specification expects that the link layer is sufficiently This specification expects that the link layer is sufficiently
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.
9. Protocol Constants 8. Protocol Constants
This Specification uses the following constants: This Specification uses the following constants:
TENTATIVE_DURATION: 800 milliseconds TENTATIVE_DURATION: 800 milliseconds
STABLE_STALE_DURATION: 24 hours STABLE_STALE_DURATION: 24 hours
UNSTABLE_STALE_DURATION: 5 minutes UNSTABLE_STALE_DURATION: 5 minutes
DEFAULT_NS_POLLING: 3 times DEFAULT_NS_POLLING: 3 times
10. IANA Considerations 9. IANA Considerations
This document requires the following additions:
Address Registration Option Status Values Registry
+--------+----------------------------------------------------------+
| Status | Description |
+--------+----------------------------------------------------------+
| 3 | Moved: The registration fails because it is not the |
| | freshest. |
| | |
| 4 | Removed: The binding state was removed |
+--------+----------------------------------------------------------+
IANA is required to change the registry accordingly
Table 1: New ARO Status values This document has no request to IANA.
11. Acknowledgments 10. Acknowledgments
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.
12. References 11. References
12.1. Normative References 11.1. Normative References
[I-D.ietf-6lo-rfc6775-update]
Thubert, P., Nordmark, E., and S. Chakrabarti, "An Update
to 6LoWPAN ND", draft-ietf-6lo-rfc6775-update-00 (work in
progress), December 2016.
[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 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
skipping to change at page 24, line 41 skipping to change at page 20, line 23
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>.
12.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] [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-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-05 (work in progress), Energy", draft-ietf-6lo-dect-ule-09 (work in progress),
May 2016. December 2016.
[I-D.ietf-6lo-nfc] [I-D.ietf-6lo-nfc]
Hong, Y. and J. Youn, "Transmission of IPv6 Packets over Choi, Y., Youn, J., and Y. Hong, "Transmission of IPv6
Near Field Communication", draft-ietf-6lo-nfc-04 (work in Packets over Near Field Communication", draft-ietf-6lo-
progress), July 2016. nfc-05 (work in progress), October 2016.
[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-01 (work in progress), March 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-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.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.
[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]
Sethi, M., Thubert, P., and B. Sarikaya, "Address
Protected Neighbor Discovery for Low-power and Lossy
Networks", draft-sarikaya-6lo-ap-nd-04 (work in progress),
August 2016.
[I-D.thubert-6lo-rfc6775-update]
Thubert, P., Nordmark, E., and S. Chakrabarti, "An Update
to 6LoWPAN ND", draft-thubert-6lo-rfc6775-update-00 (work
in progress), May 2016.
[I-D.vyncke-6man-mcast-not-efficient] [I-D.vyncke-6man-mcast-not-efficient]
Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A.
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
skipping to change at page 28, line 25 skipping to change at page 24, line 5
[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>.
12.3. External Informative References 11.3. External Informative References
[IEEE80211] [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".
[IEEE802151] [IEEEstd802151]
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
15.1: Wireless Medium Access Control (MAC) and Physical 15.1: Wireless Medium Access Control (MAC) and Physical
Layer (PHY) Specifications for Wireless Personal Area Layer (PHY) Specifications for Wireless Personal Area
Networks (WPANs)". Networks (WPANs)".
[IEEE802154] [IEEEstd802154]
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 6LoWPAN Node may change its point of attachment to a 6LR, say nodes a 6LoWPAN Node 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 6LR-a, 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 still 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. a 6LR and restore reachability in a timely fashion.
skipping to change at page 30, line 35 skipping to change at page 26, line 9
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 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 32, line 27 skipping to change at page 27, line 50
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 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. 51 change blocks. 
350 lines changed or deleted 135 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/