draft-ietf-6lo-backbone-router-07.txt   draft-ietf-6lo-backbone-router-08.txt 
6lo P. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft cisco Internet-Draft cisco
Intended status: Standards Track C. Perkins Intended status: Standards Track C. Perkins
Expires: March 7, 2019 Futurewei Expires: April 25, 2019 Futurewei
September 3, 2018 October 22, 2018
IPv6 Backbone Router IPv6 Backbone Router
draft-ietf-6lo-backbone-router-07 draft-ietf-6lo-backbone-router-08
Abstract Abstract
Backbone Routers placed at the wireless edge of a backbone link Backbone Routers running IPv6 Neighbor Discovery can manage multiple
interconnect multiple wireless links at Layer-3 to form a large wireless links to form a large MultiLink Subnet, but it is more
MultiLink Subnet, so that the broadcast domain of the backbone does efficient if IPv6 Neighbor Discovery packets are not broadcast over
not extend to the wireless links. Wireless nodes register or are the wireless links. This specification specifies proxy operations
proxy-registered to a Backbone Router to establish IPv6 Neighbor for IPv6 Neighbor Discovery on behalf of devices located on
Discovery proxy services, and the Backbone Router takes care of the broadcast-inefficient wireless networks. Backbone Routers placed
ND operation on behalf of registered nodes and ensures and routes along the wireless edge of the backbone handle IPv6 Neighbor
towards the registered addresses over the wireless interface. Discovery, and route packets on behalf of registered nodes. Wireless
nodes register, or are registered by proxy, to a Backbone Router to
establish proxy services in a fashion similar to 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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 7, 2019. This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 16
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 . . . . . . . . . . . . 4 2. Applicability and Requirements Served . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Backbone Router Routing Operations . . . . . . . . . . . . . 8 5. Backbone Router Routing Operations . . . . . . . . . . . . . 8
5.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 9 5.1. Over the Backbone Link . . . . . . . . . . . . . . . . . 8
5.2. Over the LLN Link . . . . . . . . . . . . . . . . . . . . 10 5.2. Proxy Operations Over the LLN Interface . . . . . . . . . 9
5.2.1. Routing Proxy Operations . . . . . . . . . . . . . . 10
5.2.2. Bridging Proxy Operations . . . . . . . . . . . . . . 10
6. Backbone Router Proxy Operations . . . . . . . . . . . . . . 11 6. Backbone Router Proxy Operations . . . . . . . . . . . . . . 11
6.1. Registration and Binding State Creation . . . . . . . . . 14 6.1. Primary and Secondary BBRs . . . . . . . . . . . . . . . 12
6.2. Defending Addresses . . . . . . . . . . . . . . . . . . . 15 6.2. Binding Table . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6.3. Registration and Binding Table Entry Creation . . . . . . 13
6.4. Defending Addresses . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 16 8. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 10. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 16
11.3. External Informative References . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 12.3. External Informative References . . . . . . . . . . . . 19
Appendix A. Changes from revision 07 to revision 08 . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
One of the key services provided by IEEE STD. 802.1 [IEEEstd8021] IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient
Ethernet Bridging is an efficient and reliable broadcast service, and and reliable broadcast service; applications and protocols have been
multiple applications and protocols have been built that heavily built that heavily depend on that feature for their core operation.
depend on that feature for their core operation. Unfortunately, a Unfortunately, many wireless networks do not economically provide the
wide range of wireless networks do not provide economical broadcast broadcast capabilities of Ethernet Bridging; protocols designed for
capabilities of Ethernet Bridging; protocols designed for bridged bridged networks that rely on broadcast often exhibit disappointing
networks that rely on broadcast often exhibit disappointing behaviours when applied unmodified to a wireless medium (see
behaviours when applied unmodified to a wireless medium. [I-D.ietf-mboned-ieee802-mcast-problems]).
Wi-Fi [IEEEstd80211] Access Points (APs) deployed in an Extended WiFi [IEEEstd80211] Access Points (APs) deployed in an Extended
Service Set (ESS) act as bridges. However, in order to ensure a Service Set (ESS) act as bridges. In order to ensure a solid
solid connectivity to the devices and protect the medium against connectivity to the devices and protect the medium against harmful
harmful broadcasts, they refrain from relying on broadcast-intensive broadcasts, they refrain from relying on broadcast-intensive
protocols such as Transparent Bridging on the wireless side. protocols such as Transparent Bridging on the wireless side.
Instead, an association process is used to register proactively the Instead, an association process is used to register the MAC addresses
MAC addresses of the wireless device (STA) to the AP. Then, the APs of the wireless device (STA) to the AP. The APs subsequently proxy
proxy the bridging operation and cancel the broadcasts. the bridging operation and eliminate the broadcasts.
The IPv6 [RFC8200] Neighbor Discovery [RFC4861] [RFC4862] Protocol The IPv6 [RFC8200] Neighbor Discovery [RFC4861] [RFC4862] Protocol
(NDP) operations are reactive and rely heavily on multicast (IPv6 ND) operations are reactive and rely heavily on multicast
transmissions to locate an on-link correspondent and ensure address transmissions to locate an on-link correspondent and ensure address
uniqueness. When the Duplicate Address Detection [RFC4862] (DAD) uniqueness. Duplicate Address Detection [RFC4862] (DAD) mechanism
mechanism was designed, it was a natural match with the efficient was designed as a natural match with the efficient broadcast
broadcast operation of Ethernet Bridging. However, since broadcast operation of Ethernet Bridging. However, since broadcast can be
can be unreliable over wireless media, DAD often fails to discover unreliable over wireless media, DAD often fails to discover
duplications [I-D.yourtchenko-6man-dad-issues]. DAD usually appears duplications [I-D.yourtchenko-6man-dad-issues]. DAD usually appears
to work on wireless media, not because address duplication is to work on wireless media, not because address duplication is
detected and solved as designed, but because the use of 64-bit detected and solved as designed, but because the use of 64-bit
Interface IDs makes duplication into a very rare event. Interface IDs makes duplication into a very rare event.
IPv6 multicast messages are usually broadcast over the wireless IPv6 multicast messages are typically broadcast over the wireless
medium. They are processed by most if not all wireless nodes over medium. They are processed by most if not all wireless nodes over
the ESS fabric even when very few if any of the nodes are subscribed the ESS fabric even when very few if any of them are subscribed to
to the multicast address. Consequently a simple Neighbor the multicast address. A simple Neighbor Solicitation (NS)
Solicitation (NS) lookup message [RFC4861], that is supposedly [RFC4861], that is supposedly targeted to a small group of nodes, can
targeted to a very small group of nodes, can consume the whole congest the wireless bandwidth
wireless bandwidth across the fabric [I-D.ietf-mboned-ieee802-mcast-problems]. The IPv6 ND operation
[I-D.vyncke-6man-mcast-not-efficient]. The reactive IPv6 ND leads to undesirable power consumption in battery-operated devices.
operation leads to undesirable power consumption in battery-operated
devices.
The inefficiencies of using radio broadcasts to support IPv6 NDP These problems suggest restricting IPv6 ND broadcasts over wireless
suggest restricting broadcast transmissions over the wireless access access links, which can be done by dividing up the subnet. Another
links. This can be done by splitting the subnet in multiple ones,
and in extreme cases providing a /64 per wireless device. Another
way is to take over (proxy) the Layer-3 protocols that rely on way is to take over (proxy) the Layer-3 protocols that rely on
broadcast operation at the boundary of the wired and wireless broadcast operation at the boundary of the wired and wireless
domains, emulating the Layer-2 association at Layer-3. Indeed, the domains, emulating the Layer-2 association at layer-3. For instance,
IEEE STD. 802.11 [IEEEstd80211] specifications require ARP and ND IEEE 802.11 [IEEEstd80211] specifies ARP and ND proxy [RFC4389]
proxy [RFC4389] functions at the Access Points (APs) but the services at the Access Points (APs).
specification for the ND proxy operations is still missing.
Current devices rely on snooping for detecting association state, Current devices rely on snooping for detecting association state,
which is unsatisfactory in a lossy and mobile conditions. With which is failure-prone in lossy and mobile conditions. With
snooping, a state (e.g. a new IPv6 address) may not be discovered or 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 a change of state (e.g. a movement) may be missed, leading to
unreliable connectivity. unreliable connectivity.
WPAN devices (i.e., those implementing IEEE STD. 802.15.4 WPAN devices (i.e., those implementing IEEE STD. 802.15.4
[IEEEstd802154]) can make use of Neighbor Discovery Optimization for [IEEEstd802154]) can make use of Neighbor Discovery Optimization for
IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
[RFC6775] which treats the wireless medium as different from [RFC6775] which treats the wireless medium as different from
Ethernet. RFC 6775 is updated as [I-D.ietf-6lo-rfc6775-update]; the Ethernet. RFC 6775 is updated as [I-D.ietf-6lo-rfc6775-update]; the
update includes changes that are required by this document. update includes changes that are required by this document.
This specification applies 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 operation by
the 6BBR. The proxy operation on the BBR eliminates the need for
low-power nodes or nodes that are deep in a mesh to respond
synchronously when a lookup is performed for their addresses. This
provides the function of a Sleep Proxy for ND
[I-D.nordmark-6man-dad-approaches].
2. Applicability and Requirements Served 2. Applicability and Requirements Served
Efficiency aware IPv6 Neighbor Discovery Optimizations
[I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND
[RFC6775] can be extended to other types of links beyond IEEE STD.
802.15.4 for which it was defined. The registration technique is
beneficial when the Link-Layer technique used to carry IPv6 multicast
packets has poor delivery ratio or requires high energy consumption
in the end devices, all the more in use cases that involve mobility.
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 support for range of Low power and Lossy Networks (LLNs) with 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. including Low-Power Wi-Fi, BLUETOOTH(R) Low Energy, IEEE STD.
802.11AH 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 B.3 of [I-D.ietf-6lo-rfc6775-update] requirements listed in Appendix B.3 of [I-D.ietf-6lo-rfc6775-update]
"Requirements Related to the Variety of Low-Power Link types". "Requirements Related to the Variety of Low-Power Link types".
The scope of this draft is a Backbone that enable the federation of For the TimeSlotted Channel Hopping (TSCH) mode of [IEEEstd802154],
multiple LLNs into a IPv6 MultiLink Subnet. Each LLN in the subnet the 6TiSCH architecture [I-D.ietf-6tisch-architecture] describes how
is anchored at an IPv6 Backbone Router (6BBR). The Backbone Routers a 6LoWPAN ND host could connect to the Internet via a RPL mesh
interconnect the LLNs and advertise the addresses of the LLN nodes Network, but doing so requires extensions to the 6LOWPAN ND protocol
using proxy-ND operations. This specification extends IPv6 ND over to support mobility and reachability in a secure and manageable
the backbone to distinguish address movement from duplication and environment. The extensions detailed in this document also work for
eliminate stale state in the backbone routers and backbone nodes once the 6TiSCH architecture, serving the requirements listed in
a LLN node has roamed. In this way, mobile nodes may roam rapidly Appendix B.2 of [I-D.ietf-6lo-rfc6775-update] "Requirements Related
from one 6BBR to the next and requirements in Appendix B.1 of to Routing Protocols".
[I-D.ietf-6lo-rfc6775-update]"Requirements Related to Mobility" are
This specification also applies to wireless links such as Low-Power
IEEE STD. 802.11 (Wi-Fi) and IEEE STD. 802.15.1 (Bluetooth)
[IEEEstd802151]. It makes use of extensions to [RFC6775] to enable
proxy operation by the 6BBR, as specified in
[I-D.ietf-6lo-rfc6775-update]. The BBR proxy operations eliminate
the need for wireless nodes to respond synchronously when a lookup is
performed for their addresses. This provides the function of a Sleep
Proxy for ND [I-D.nordmark-6man-dad-approaches].
This draft establishes a Backbone that treats multiple LLNs as a
single IPv6 MultiLink Subnet. Each LLN in the subnet is anchored at
an IPv6 Backbone Router (6BBR). The Backbone Routers interconnect
the LLNs and advertise the addresses of the 6LNs using proxy-ND
operations. This specification extends IPv6 ND over the backbone to
distinguish address movement from duplication and eliminate stale
state in the backbone routers and backbone nodes once a 6LN has
roamed. In this way, mobile nodes may roam rapidly from one 6BBR to
the next and requirements in Appendix B.1 of
[I-D.ietf-6lo-rfc6775-update] "Requirements Related to Mobility" are
met. met.
This specification can be used by any wireless node to associate at This specification enables any 6LN to register its IPv6 addresses and
Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing thereby obtain routing services including proxy-ND operations over
services including proxy-ND operations over the backbone, providing a the backbone, providing a solution to the requirements expressed in
solution to the requirements expressed in Appendix B.4 of Appendix B.4 of [I-D.ietf-6lo-rfc6775-update] "Requirements Related
[I-D.ietf-6lo-rfc6775-update] "Requirements Related to Proxy to Proxy Operations".
Operations".
The Link Layer Address (LLA) that is returned as Target LLA (TLLA) in The Link Layer Address (LLA) that is returned as Target LLA (TLLA) in
Neighbor Advertisements (NA) messages by the 6BBR on behalf of the Neighbor Advertisements (NA) messages by the 6BBR on behalf of the
Registered Node over the backbone may be that of the Registering Registered Node over the backbone may be that of the Registering
Node. In that case, the 6BBR needs to bridge the unicast packets Node. In that case, the 6BBR needs to bridge the unicast packets
(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). The
latter case, the 6BBR maintains the list of correspondents to which IPv6 ND operation is minimized as the number of 6LNs grows in the
it has advertised its own MAC address on behalf of the LLN node. The
IPv6 ND operation is minimized as the number of nodes scale up in the
LLN. This meets the requirements in Appendix B.6 of LLN. This meets the requirements in Appendix B.6 of
[I-D.ietf-6lo-rfc6775-update] "Requirements Related to Scalability", [I-D.ietf-6lo-rfc6775-update] "Requirements Related to Scalability",
as long has the 6BBRs are dimensioned for the number of registrations as long has the 6BBRs are dimensioned for the number of registrations
that each needs to support. that each needs to support.
For the TimeSlotted Channel Hopping (TSCH) mode of [IEEEstd802154],
the 6TiSCH architecture [I-D.ietf-6tisch-architecture] describes how
a 6LoWPAN ND host could connect to the Internet via a RPL mesh
Network, but doing so requires additions to the 6LOWPAN ND protocol
to support mobility and reachability in a secure and manageable
environment. This document details such additions for the 6TiSCH
architecture, and serves the requirements listed in Appendix B.2 of
[I-D.ietf-6lo-rfc6775-update] "Requirements Related to Routing
Protocols".
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. Then with a standalone AP or a CAPWAP [RFC5415] wireless controller. Then
the wireless client (STA) makes use of this specification to register the wireless client (STA) makes use of 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 RPL, the RPL root is collocated with a 6LoWPAN Border Router
Border Router (6LBR), and either collocated with or connected to the (6LBR), and either collocated with or connected to the 6BBR over an
6BBR over an IPv6 Link. The 6LBR makes use of this specification to IPv6 Link. The 6LBR makes use of this specification to register the
register the LLN nodes on their behalf to the 6BBR. In the case of 6LNs on their behalf to the 6BBR.
BTLE, the 6BBR is collocated with the router that implements the BTLE
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] .
Readers are expected to be familiar with all the terms and concepts In this document, readers will encounter terms and concepts that are
that are discussed in "Neighbor Discovery for IP version 6" discussed in the following documents:
[RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862],
"IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
Neighbor Discovery Optimization for Low-power and Lossy Networks
[RFC6775] and "Multi-link Subnet Support in IPv6" o "Neighbor Discovery for IP version 6" [RFC4861],
[I-D.ietf-ipv6-multilink-subnets].
Readers would benefit from reading "Multi-Link Subnet Issues" o "IPv6 Stateless Address Autoconfiguration" [RFC4862],
[RFC4903], ,"Mobility Support in IPv6" [RFC6275], "Neighbor Discovery
Proxies (ND Proxy)" [RFC4389] and "Optimistic Duplicate Address
Detection" [RFC4429] prior to this specification for a clear
understanding of the art in ND-proxying and binding.
Additionally, this document uses terminology from [RFC7102], o "Multi-Link Subnet Issues" [RFC4903],
[I-D.ietf-6lo-rfc6775-update] and [I-D.ietf-6tisch-terminology], and
introduces the following terminology: o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
Overview, Assumptions, Problem Statement, and Goals" [RFC4919],
o Neighbor Discovery Optimization for Low-power and Lossy Networks
[RFC6775],
o ,"Mobility Support in IPv6" [RFC6275],
o "Neighbor Discovery Proxies (ND Proxy)" [RFC4389]
o "Optimistic Duplicate Address Detection" [RFC4429], and
o "Registration Extensions for 6LoWPAN Neighbor Discovery"
[I-D.ietf-6lo-rfc6775-update]
This document also uses terminology from [RFC7102] and
[I-D.ietf-6lo-rfc6775-update], and introduces the following
terminology:
Sleeping Proxy Sleeping Proxy
A 6BBR acts as a Sleeping Proxy if it answers ND Neighbor A 6BBR acts as a Sleeping Proxy if it answers ND Neighbor
Solicitation over the backbone on behalf of the Registered Solicitation over the backbone on behalf of the Registered
Node. Node.
Unicasting Proxy Unicasting Proxy
A Unicasting Proxy forwards NS messages to the Registering A Unicasting Proxy forwards NS messages to the Registering
Node, transforming Layer-2 multicast into unicast. Node, transforming Layer-2 multicast into unicast.
Routing proxy Routing proxy
A routing proxy advertises its own MAC address, as opposed to A routing proxy advertises its own MAC address as the TLLA in
that of the node that performs the registration, as the TLLA in the proxied NAs over the backbone, as opposed to that of the
the proxied NAs over the backbone. node that performs the registration.
Bridging proxy Bridging proxy
A Bridging proxy advertises the MAC address of the node that A Bridging proxy advertises the MAC address of the node that
performs the registration as the TLLA in the proxied NAs over performs the registration as the TLLA in the proxied NAs over
the backbone. In that case, the MAC address and the mobility the backbone. In that case, the MAC address and the mobility
of the node is still visible across the bridged backbone of 6LN is still visible across the bridged backbone fabric.
fabric.
Primary BBR Primary BBR
The BBR that will defend a Registered Address for the purpose The BBR that will defend a Registered Address for the purpose
of DAD over the backbone. of DAD over the backbone.
Secondary BBR Secondary BBR
A BBR other than the Primary BBR to which an address is A BBR other than the Primary BBR to which an address is
registered. A Secondary Router MAY advertise the address over registered. A Secondary Router MAY advertise the address over
the backbone and proxy for it. the backbone and proxy for it.
4. Overview 4. Overview
An LLN node can move freely from an LLN anchored at a Backbone Router The services specified in this document assist a 6LN to move freely
to an LLN anchored at another Backbone Router on the same backbone from an LLN anchored at one 6BBR to an LLN anchored at another 6BBR
and keep any or all of the IPv6 addresses that it has formed. on the same backbone and keep any or all of the IPv6 addresses that
the 6LN has formed.
| |
+-----+ +-----+
| | Gateway (default) Router | | Gateway (default) Router
| | | |
+-----+ +-----+
| |
| Backbone Link | Backbone Link
+--------------------+------------------+ +-------------------------+----------------------+
| | | | | |
+-----+ +-----+ +-----+ +------+ +------+ +------+
| | Backbone | | Backbone | | Backbone | 6BBR | | 6BBR | | 6BBR |
| | router | | router | | router | | | | | |
+-----+ +-----+ +-----+ +------+ +------+ +------+
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 o o o o o o o o o o o o
LLN LLN LLN LLN LLN LLN
Figure 1: Backbone Link and Backbone Routers Figure 1: Backbone Link and Backbone Routers
Each Backbone Router (6BBR) maintains a Binding Table of its Each Backbone Router (6BBR) maintains a Binding Table of its
Registered Nodes. The Binding Table operates as a distributed Registered Nodes. The Binding Tables form a distributed database of
database of wireless Nodes whether they reside on the LLNs or on the wireless 6LNs that reside on the LLNs or on the backbone, and use an
backbone, and use an extension to the Neighbor Discovery Protocol to extension to IPv6 ND to exchange that information across the Backbone
exchange that information across the Backbone as with IPv6 ND. as described below.
The Extended Address Registration Option (EARO) defined in The Extended Address Registration Option (EARO) defined in
[I-D.ietf-6lo-rfc6775-update] is used to enable the registration for [I-D.ietf-6lo-rfc6775-update] is used in the ND exchanges over the
routing and proxy options in the ND exchanges over the backbone backbone between the 6BBRs to enable the registration for routing and
between the 6BBRs to disambiguate duplication from movement. proxy services, as well as distinguish duplication from movement.
Address duplication is detected using the ROVR field in the EARO,
which is a generalization of the EUI-64 that allows different types
of unique IDs beyond the name space derived from the MAC addresses.
First-Come First-Serve rules apply, whether the duplication happens
between LLN nodes as represented by their respective 6BBRs, or
between an LLN node and a node that defends its address over the
backbone with IPv6 ND and does not include the EARO.
In case of conflicting registrations to multiple 6BBRs from a same Address duplication is detected using the ROVR field in the EARO. In
node, a sequence counter called Transaction ID (TID) in the EARO case of conflicting registrations to multiple 6BBRs from the same
enables 6BBRs to determine the latest registration for that node. node, the Transaction ID (TID) in the EARO enables 6BBRs to determine
Registrations with a same TID are compatible and maintained, but, in the latest registration for that 6LN.
case of different TIDs, only the freshest registration is maintained
and the stale state is eliminated. The EARO also transports a 'R'
flag to be used by a 6LN when registering, to indicate that this 6LN
is not a router and that it will not handle its own reachability.
With this specification, Backbone Routers perform a ND proxy 6BBRs perform ND proxy operations over the backbone, on behalf of
operation over the Backbone Link on behalf of their Registered Nodes. their Registered Nodes. Registration to a proxy service is done via
The registration to the proxy service is done with a NS/NA(EARO) a NS/NA(EARO) exchange. 6BBR operation resembles that of a Mobile
exchange. The EARO with a 'R' flag is used in this specification to IPv6 (MIPv6) [RFC6275] Home Agent. This enables mobility support for
request the 6BBR to perform this proxy operation. The Backbone 6LNs; if they move outside of the network delimited by the Backbone
Router operation is essentially similar to that of a Mobile IPv6 link, then they make use of a Home Agent. Home Agent functionality
(MIPv6) [RFC6275] Home Agent. This enables mobility support for LLN can easily be collocated with a 6BBR on the same backbone interface
nodes that would move outside of the network delimited by the of a router.
Backbone link attach to a Home Agent from that point on. This also
enables collocation of Home Agent functionality within Backbone
Router functionality on the same backbone interface of a router.
Further specification may extend this be allowing the 6BBR to
redistribute host routes in routing protocols that would operate over
the backbone, or in MIPv6 or the Locator/ID Separation Protocol
(LISP) [RFC6830] to support mobility on behalf of the nodes, etc...
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 mandates that an address
is TENTATIVE should not be associated to a Source Link-Layer Address that is TENTATIVE should not be associated to a Source Link-Layer
Option in a Neighbor Solicitation message. This specification makes Address Option in a Neighbor Solicitation message. This
use of ODAD to create a temporary proxy state in the 6BBR till DAD is specification makes use of ODAD to create a temporary proxy state in
completed over the backbone. This way, the specification enables to the 6BBR until DAD is completed over the backbone. This way, the
distribute proxy states across multiple 6BBR and co-exist with IPv6 specification allows proxy state distribution across multiple 6BBR
ND over the backbone. and co-existence with IPv6 ND over the backbone.
5. Backbone Router Routing Operations 5. Backbone Router Routing Operations
| |
+-----+ +-----+
| | Gateway (default) Router | | Gateway (default) Router
| | | |
+-----+ +-----+
| /64 | /64
| Backbone Link | Backbone Link
+-------------------+-------------------+ +-------------------+-------------------+
| /64 | /64 | /64 | /64 | /64 | /64
+-----+ +-----+ +-----+ +------+ +------+ +------+
| | Backbone | | Backbone | | Backbone | 6BBR | | 6BBR | | 6BBR |
| | router | | router | | router | | | | | |
+-----+ +-----+ +-----+ +------+ +------+ +------+
o N * /128 o M * /128 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 o o o o o o
LLN: N*/128 LLN: M*/128 LLN: P*/128
Figure 2: Example Routing Configuration for 3 LLNs in the ML Subnet Figure 2: Example Routing Configuration for 3 LLNs in the ML Subnet
5.1. Over the Backbone Link 5.1. Over the Backbone Link
A 6BBR is a specific kind of Border Router that performs proxy A 6BBR is a specific kind of Border Router that performs proxy
Neighbor Discovery on its backbone interface on behalf of the nodes Neighbor Discovery on its backbone interface on behalf of registered
that it has discovered on its LLN interfaces. 6LNs on its LLN interfaces.
Some restrictions of the attached LLNs will apply to the backbone.
In particular, the MTU MUST be set to the same value on the backbone
and all attached LLNs. The scalability of the whole subnet requires
that broadcast operations are avoided as much as possible on the
backbone as well. Unless configured otherwise, in the RAs that it
sends towards the LLN links, the Backbone Router MUST use the same
MTU that it learns from RAs over the backbone.
On the backbone side, the 6BBR behaves like any other IPv6 router. On the backbone side, the 6BBR advertises the prefixes of the LLNs
It advertises on the backbone the prefixes of the LLNs for which it for which it serves as a proxy. Some restrictions of the attached
serves as a proxy. LLNs will apply to the backbone. In particular, the MTU SHOULD be
set to the same value on the backbone and all attached LLNs. The
scalability of the multilink subnet [RFC4903] requires that broadcast
operations are avoided as much as possible on the backbone as well.
The 6BBR uses an EARO in the NS-DAD and the multicast NA messages The 6BBR uses an EARO in the NS-DAD and the multicast NA messages
that it generates over the Backbone Link on behalf of a Registered that it generates over the Backbone Link on behalf of a Registered
Node, and it places an EARO in its unicast NA messages, if and only Node. The 6BBR places an EARO in its unicast NA messages, if and
if the NS/NA that stimulates it had an EARO in it and the 'R' bit only if the NS/NA that stimulates it had an EARO in it and the 'R'
set. bit set.
The 6BBR SHOULD use unicast or solicited-node multicast address The 6BBR SHOULD use unicast or the solicited-node multicast address
(SNMA) [RFC4291] to defend its Registered Addresses over the (SNMA) [RFC4291] to defend its Registered Addresses in its Binding
backbone. In particular, the 6BBR MUST join the SNMA group that Table over the backbone. In particular, the 6BBR MUST join the SNMA
corresponds to a Registered Address as soon as it creates an entry group that corresponds to a Registered Address as soon as it creates
for that address, and as long as it maintains that entry. an entry for that address, and maintain its SNMA membership as long
as it maintains that entry.
Optimistic DAD (ODAD) [RFC4429] SHOULD be supported by the 6BBRs in Optimistic DAD (ODAD) [RFC4429] SHOULD be supported by the 6BBRs in
their proxy activity over the backbone. A node supporting ODAD MUST their proxy activity over the backbone. A 6BBR supporting ODAD MUST
join the SNMA of a Tentative address. join the SNMA of a Tentative address.
A 6BBR in Routing Proxy mode advertises the Registered IPv6 Address A 6BBR in Routing Proxy mode MAY advertise the Registered IPv6
with the 6BBR Link Layer Address, and updates Neighbor Cache Entries Address with the 6BBR Link Layer Address, and update Neighbor Cache
(NCE) in correspondent nodes over the backbone, using gratuitous Entries (NCE) in correspondent nodes over the backbone, using
NA(Override). This method may fail if the multicast message is not gratuitous NA(Override). This method may fail if the multicast
properly received, and correspondent nodes may maintain an incorrect message is not received, and correspondent nodes may maintain an
neighbor state, which they will eventually discover through Neighbor incorrect neighbor state, which they will eventually discover through
Unreachability Detection (NUD). For slow movements, the NUD Neighbor Unreachability Detection (NUD). For slow movements, the NUD
procedure defined in [RFC4861] may time out too quickly, and the procedure defined in [RFC4861] may time out too quickly, and the
support of [RFC7048] is recommended in all nodes in the network. support of [RFC7048] is recommended in all 6LNs in the network.
Since the MultiLink Subnet may grow to contain many nodes, multicast Multicast should be avoided as much as possible even on the backbone
should be avoided as much as possible even on the backbone. Though [I-D.ietf-mboned-ieee802-mcast-problems]. Although hosts can
hosts can participate using legacy IPv6 ND, all nodes connected to participate using legacy IPv6 ND, all 6LNs connected to the backbone
the backbone SHOULD support [I-D.ietf-6man-rs-refresh], which also SHOULD support [I-D.ietf-6man-rs-refresh], which also requires the
requires the support of [RFC7559]. support of [RFC7559].
5.2. Over the LLN Link 5.2. Proxy Operations Over the LLN Interface
BBRs and LLN hosts on the LLN follow [RFC6775] and do not depend on 6LNs on the LLN follow [RFC6775] and do not depend on multicast RAs
multicast RAs to discover routers. LLN nodes SHOULD accept multicast to discover routers. 6LNs SHOULD accept multicast RAs [RFC7772], but
RAs [RFC7772], but those are rare on the LLN link. Nodes SHOULD those are expected to be rare within in the LLN. Nodes SHOULD follow
follow the Simple Procedures for Detecting Network Attachment in IPv6 the Simple Procedures for Detecting Network Attachment in IPv6
[RFC6059] (DNA procedures) to assert movements, and to support the [RFC6059] (DNA procedures) to assert movements, and support Packet-
Packet-Loss Resiliency for Router Solicitations [RFC7559] to make the Loss Resiliency for Router Solicitations [RFC7559] to make the
unicast RS more reliable. unicast RS more reliable.
LLN node signals that it requires IPv6 ND proxy services from a 6BBR A 6LN signals that it requires IPv6 ND proxy services from a 6BBR by
by registering the corresponding IPv6 Address with an NS(EARO) registering the corresponding IPv6 Address with an NS(EARO) message
message with the 'R' flag set. The LLN node that performs the with the 'R' flag set. The 6LN that performs the registration (the
registration (the Registering Node) may be the owner of the IPv6 Registering Node) may be the owner of the IPv6 Address (the
Address (the Registered Node) or a 6LBR that performs the Registered Node) or a 6LBR that performs the registration on its
registration on its behalf. behalf.
5.2.1. Routing Proxy Operations
When operating as a Routing Proxy, the BBR installs host routes When operating as a Routing Proxy, the BBR installs host routes
(/128) to the Registered Addresses over the LLN links, via the (/128) to the Registered Addresses within the LLN, via the
Registering Node as identified by the Source Address and the SLLA Registering Node as identified by the Source Address and the SLLA
option in the NS(EARO) messages. In that case, the MAC address of option in the NS(EARO) messages. In that case, the MAC address of
the node is not visible at Layer-2 over the backbone and the bridging the 6LN is not visible at Layer-2 over the backbone. The 6BBR
fabric is not aware of the addresses of the LLN devices and their installs a host route towards the Registered Node over the interface
mobility. The 6BBR installs a connected host route towards the toward the 6LN, and routes unicast packets to the 6LN.
registered node over the interface to the node, and acts as a Layer-3
router for unicast packets to the node.
In that mode, the 6BBR handles the ND protocol over the backbone on The Routing Proxy 6BBR handles the ND protocol over the backbone on
behalf of the Registered Nodes, using its own MAC address in the TLLA behalf of the Registered Nodes, using its own MAC address in the TLLA
and SLLA options in proxied NS and NA messages. For each Registered and SLLA options in proxied NS and NA messages. For each Registered
Address, multiple peer Nodes on the backbone may have resolved the Address, multiple peer Nodes on the backbone may have resolved the
address with the 6BBR MAC address and store that mapping in their address with the 6BBR MAC address, maintaining that mapping in their
Neighbor cache. Neighbor cache.
For each Registered Address, the 6BBR SHOULD maintain a list of the For each Registered Address, the 6BBR SHOULD maintain a list of the
peers on the backbone which have associated its MAC address with the peers on the backbone which have associated its MAC address with the
Registered Address. If that Registered Address moves to a different Registered Address. If that Registered Address moves to a different
6BBR, the first 6BBR SHOULD unicast a gratuitous NA(Override) to each 6BBR, the first 6BBR SHOULD unicast a gratuitous NA(Override) to each
such peer, to supply the MAC address of the new 6BBR in the TLLA such peer, to supply the MAC address of the new 6BBR in the TLLA
option for the Address. option for the Address.
5.2.2. Bridging Proxy Operations
A Bridging Proxy can be implemented in a Layer-3 switch, or in a A Bridging Proxy can be implemented in a Layer-3 switch, or in a
wireless Access Point that acts as an IPv6 Host. In the latter case, wireless Access Point that acts as an IPv6 Host. In the latter case,
the SLLA option in the proxied NA messages is that of the Registering the SLLA option in the proxied NA messages is that of the Registering
Node, and the 6BBR acts as a Layer-2 bridge for unicast packets to Node, and the 6BBR acts as a Layer-2 bridge for unicast packets to
the Registered Address. The MAC address in the S/TLLA is that of the the Registered Address. The MAC address in the S/TLLA is that of the
Registering Node, which is not necessarily the Registered Node. When Registering Node, which is not necessarily the Registered Node. When
a device moves within a LLN mesh, it may attach to a different 6LBR a 6LN moves within a LLN mesh, it may attach to a different 6LBR
acting as Registering Node, and the MAC address advertised over the acting as Registering Node, and the MAC address advertised over the
backbone will change. backbone might change.
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/TLLA option Registering Node does not change, as indicated by the S/TLLA 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 LLA of the peer's Nodes on the backbone. On the other hand, if the LLA
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 affected 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 affected Neighbor Caches over the backbone.
6. Backbone Router Proxy Operations 6. Backbone Router Proxy Operations
This specification enables a Backbone Router to proxy Neighbor The LLNs attached to each 6BBR are considered different Links in a
Discovery operations over the backbone on behalf of the nodes that multi-link subnet. The prefix that is used may still be advertised
are registered to it, allowing any node on the backbone to reach a as on-link on the backbone to support legacy 6LNs. Multicast ND
Registered Node as if it was on-link. The backbone and the LLNs are messages are link-scoped and not forwarded across the backbone
considered different Links in a MultiLink subnet but the prefix that routers.
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
across the backbone routers.
By default, a 6BBR operates as a Sleeping Proxy, as follows: By default, a 6BBR operates as a Sleeping Proxy, as follows:
o Create a new entry in a Binding Table for a new Registered Address o Create a new entry in a Binding Table for a new Registered Address
and ensure that the address is not a duplicate over the backbone and ensure that the address is not a duplicate over the backbone
o Defend a Registered Address over the backbone using NA messages o Defend a Registered Address over the backbone using NA messages
with the Override bit set on behalf of the sleeping node with the Override bit set on behalf of the sleeping 6LN
o Advertise a Registered Address over the backbone using NA o Advertise a Registered Address over the backbone using NA
messages, asynchronously or as a response to a Neighbor messages, asynchronously or as a response to a Neighbor
Solicitation messages. Solicitation messages.
o To deliver packets arriving from the LLN, use Neighbor o To deliver packets arriving from the LLN, use Neighbor
Solicitation messages to look up the destination over the Solicitation messages to look up the destination over the
backbone. backbone.
o Forward packets between the LLN and the backbone. o Forward packets between the LLN and the backbone.
skipping to change at page 12, line 36 skipping to change at page 11, line 46
The 6BBR does not act on ND Messages over the backbone unless they The 6BBR does not act on ND Messages over the backbone unless they
are relevant to a Registered Node on the LLN side, saving wireless are relevant to a Registered Node on the LLN side, saving wireless
interference. On the LLN side, the prefixes associated to the interference. On the LLN side, the prefixes associated to the
MultiLink Subnet are presented as not on-link, so address resolution MultiLink Subnet are presented as not on-link, so address resolution
for other hosts do not occur. for other hosts do not occur.
As a Unicasting Proxy, the 6BBR forwards NS lookup messages to the As a Unicasting Proxy, the 6BBR forwards NS lookup messages to the
Registering Node, transforming Layer-2 multicast into unicast. This Registering Node, transforming Layer-2 multicast into unicast. This
is not possible in UNREACHABLE state, so the NS messages are is not possible in UNREACHABLE state, so the NS messages are
multicasted, and rate-limited with an exponential back-off to protect multicasted, and rate-limited. Retries are possible, using an
the medium. In other states, the messages are forwarded to the exponential back-off to protect the medium. In other states, the
Registering Node as unicast Layer-2 messages. In TENTATIVE state, messages are forwarded to the Registering Node as unicast Layer-2
the NS message is either held till DAD completes, or dropped. messages. In TENTATIVE state, the NS message is either held till DAD
completes, or dropped if DAD does not complete.
The draft introduces the optional concept of primary and secondary
BBRs. The primary is the backbone router that has the highest EUI-64
address of all the 6BBRs that share a registration for a same
Registered Address, with the same ROVR and same Transaction ID, the
EUI-64 address being considered as an unsigned 64bit integer. A
given 6BBR can be primary for a given address and secondary for
another address, regardless on whether or not the addresses belong to
the same node. The primary Backbone Router is in charge of
protecting the address for DAD over the Backbone. Any of the Primary
and Secondary 6BBR may claim the address over the backbone, since
they are all capable to route from the backbone to the LLN node; the
address appears on the backbone as an anycast address.
The Backbone Routers maintain a distributed binding table, using IPv6 6.1. Primary and Secondary BBRs
ND over the backbone to detect duplication. This specification
requires that:
1. Addresses in a LLN that can be reachable from the backbone by way A 6BBR MAY be primary or secondary. The primary is the backbone
of a 6BBR MUST be registered to that 6BBR. router that has the highest EUI-64 address of all the 6BBRs that
share a registration for a same Registered Address, with the same
ROVR and same Transaction ID, the EUI-64 address being considered as
an unsigned 64bit integer. A given 6BBR can be primary for a given
address and secondary for another address, regardless of whether or
not the addresses belong to the same 6LN. The primary Backbone
Router is in charge of protecting the address for DAD over the
Backbone. Any of the Primary and Secondary 6BBR may claim the
address over the backbone, since they are all capable to route from
the backbone to the 6LN; the address appears on the backbone as an
anycast address.
2. A Registered Node MUST include the EARO in the NS message when 6.2. Binding Table
registering its addresses to a 6LR. The 6LR MUST forward the
EARO unchanged to the 6LBR in the DAR/DAC exchange. The 6LBR
MUST propagate the EARO unchanged to 6BBR.
3. The 6LR MUST respond with the same EARO in the NA, except for the Each 6BBR maintains a Binding Table, using IPv6 ND over the backbone
status field. to detect duplication. Another document
[I-D.ietf-6lo-rfc6775-update] provides details about how the EARO is
used between 6LRs and 6LBRs by way of DAR/DAC messages within the
LLN. Addresses in a LLN that can be reachable from the backbone by
way of a 6BBR MUST be registered to that 6BBR.
A false positive duplicate detection may arise over the backbone, for A false positive duplicate detection may arise over the backbone, for
instance if the Registered Address is registered to more than one instance if a 6LN's Registered Address is registered to more than one
LBR, or if the node has moved. Both situations are handled by the LBR, or if the 6LN has moved. Both situations are handled by the
6BBR transparently to the node. In the former case, one LBR becomes 6BBR transparently to the 6LN. In the former case, one LBR becomes
primary to defend the address over the backbone while the others primary to defend the address over the backbone while the others
become secondary and may still forward packets. In the latter case become secondary and may still forward packets. In the latter case
the LBR that receives the newest registration becomes primary. the LBR that receives the newest registration becomes primary because
of the TID.
Only one node may register a given Address at a particular 6BBR. Only one 6LN may register a given Address at a particular 6BBR.
However, that Registered Address may be registered to Multiple 6BBRs However, that Registered Address may be registered to Multiple 6BBRs
for higher availability. for higher availability.
Over the LLN, Binding Table management is as follows: Over the LLN, Binding Table management is as follows:
De-registrations (newer TID, same ROVR, null Lifetime) are De-registrations (newer TID, same ROVR, null Lifetime) are
accepted and acknowledged with a status of 4; the entry is accepted and acknowledged with a status of 4 (TBD); the entry is
deleted; deleted;
Newer registrations (newer TID, same ROVR, non-null Lifetime) are Newer registrations (newer TID, same ROVR, non-null Lifetime) are
acknowledged with a status of 0 (success); the binding is updated acknowledged with a status of 0 (success); the binding is updated
with the new TID, the Registration Lifetime and the Registering with the new TID, the Registration Lifetime and the Registering
Node; in TENTATIVE state the acknowledgement is held and may be Node; in TENTATIVE state the acknowledgement is held and may be
overwritten; in other states the Registration-Lifetime timer is overwritten; in other states the Registration-Lifetime timer is
restarted and the entry is placed in REACHABLE state. restarted and the entry is placed in REACHABLE state.
Identical registrations (same TID, same ROVR) from a same Identical registrations (same TID, same ROVR) from a same
skipping to change at page 14, line 14 skipping to change at page 13, line 24
Older registrations (older TID, same ROVR) from a Registering Node Older registrations (older TID, same ROVR) from a Registering Node
are ignored; are ignored;
Identical and older registrations (not-newer TID, same ROVR) from Identical and older registrations (not-newer TID, same ROVR) from
a different Registering Node are acknowledged with a status of 3 a different Registering Node are acknowledged with a status of 3
(moved); this may be rate limited to protect the medium; (moved); this may be rate limited to protect the medium;
Any registration for a different Registered Node (different ROVR) Any registration for a different Registered Node (different ROVR)
are acknowledged with a status of 1 (duplicate). are acknowledged with a status of 1 (duplicate).
6.1. Registration and Binding State Creation 6.3. Registration and Binding Table Entry Creation
Upon receiving a registration for a new address with an NS(EARO) with Upon receiving a registration for a new address with an NS(EARO) with
the 'R' bit set, the 6BBR performs DAD over the backbone, placing the the 'R' bit set, the 6BBR performs DAD over the backbone, placing the
new address as target in the NS-DAD message. The EARO from the new address as target in the NS-DAD message. The EARO from the
registration MUST be placed unchanged in the NS-DAD message, and an registration MUST be placed unchanged in the NS-DAD message, and an
Neighbor Cache entry created in TENTATIVE state for a duration of Neighbor Cache entry created in TENTATIVE state for a duration of
TENTATIVE_DURATION. The NS-DAD message is sent multicast over the TENTATIVE_DURATION. The NS-DAD message is sent multicast over the
backbone to the SNMA associated with the registered address, unless backbone to the SNMA associated with the registered address, unless
that operation is known to be costly, and the 6BBR has an indication that operation is known to be costly, and the 6BBR has an indication
from another source (such as a Neighbor Cache entry) that the from another source (such as a Neighbor Cache entry) that the
Registered Address was known on the backbone; in the latter case, an Registered Address was known on the backbone; in the latter case, an
NS-DAD message may be sent as a Layer-2 unicast to the MAC Address NS-DAD message may be sent as a Layer-2 unicast to the MAC Address
that was associated with the Registered Address. that was associated with the Registered Address.
In TENTATIVE state after EARO with 'R' bit set: In TENTATIVE state after EARO with 'R' bit set:
1. The entry is removed if an NA is received over the backbone for 1. The entry is removed if an NA is received over the backbone for
the Registered Address with no EARO, or with an EARO with a the Registered Address with no EARO, or containing an EARO with a
status of 1 (duplicate) that indicates an existing registration status of 1 (duplicate) that indicates an existing registration
for another LLN node. The ROVR and TID fields in the EARO for another 6LN. The ROVR and TID fields in the EARO received
received over the backbone are ignored. A status of 1 is over the backbone are ignored. A status of 1 is returned in the
returned in the EARO of the NA back to the Registering Node; EARO of the NA back to the Registering Node;
2. The entry is also removed if an NA with an ARO option with a 2. The entry is also removed if an NA with an ARO option with a
status of 3 (moved), or a NS-DAD with an ARO option that status of 3 (moved), or a NS with an ARO option that indicates a
indicates a newer registration for the same Registered Node, is newer registration for the same Registered Node, is received over
received over the backbone for the Registered Address. A status the backbone for the Registered Address. A status of 3 is
of 3 is returned in the NA(EARO) back to the Registering Node; returned in the NA(EARO) back to the Registering Node;
3. When a registration is updated but not deleted, e.g. from a newer 3. When a registration is updated but not deleted, e.g. from a newer
registration, the DAD process on the backbone continues and the registration, the DAD process on the backbone continues and the
running timers are not restarted; running timers are not restarted;
4. Other NS (including DAD with no EARO) and NA from the backbone 4. Other NS (including DAD with no EARO) and NA from the backbone
are not acknowledged in TENTATIVE state. To cover legacy nodes are not acknowledged in TENTATIVE state. To cover legacy 6LNs
that do not support ODAD, the list of their origins MAY be stored that do not support ODAD, the list of their origins MAY be stored
and then, if the TENTATIVE_DURATION timer elapses, the 6BBR MAY and then, if the TENTATIVE_DURATION timer elapses, the 6BBR MAY
send each such legacy node a unicast NA. send each such legacy 6LN a unicast NA.
5. When the TENTATIVE_DURATION timer elapses, a status 0 (success) 5. When the TENTATIVE_DURATION timer elapses, a status 0 (success)
is returned in a NA(EARO) back to the Registering Node(s), and is 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 6BBR MUST send a multicast NA(EARO) to the SNMA associated to The 6BBR MUST send a multicast NA(EARO) to the SNMA associated to
the Registered Address over the backbone with the Override bit the Registered Address over the backbone with the Override bit
set so as to take over the binding from other 6BBRs. set so as to take over the binding from other 6BBRs.
6.2. Defending Addresses 6.4. 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 function of o If the 6BBR is primary, or does not support the function of
primary, it MUST defend that address over the backbone upon primary, it MUST defend that address over the backbone upon
receiving NS-DAD, either if the NS does not carry an EARO, or if receiving NS, either if the NS does not carry an EARO, or if an
an EARO is present that indicates a different Registering Node EARO is present that indicates a different Registering Node
(different ROVR). The 6BBR sends a NA message with the Override (different ROVR). The 6BBR sends a NA message with the Override
bit set and the NA carries an EARO if and only if the NS-DAD did bit set and the NA carries an EARO if and only if the NS-DAD did
so. When present, the EARO in the NA(Override) that is sent in so. When present, the EARO in the NA(Override) that is sent in
response to the NS-DAD(EARO) carries a status of 1 (duplicate), response to the NS(EARO) carries a status of 1 (duplicate), and
and the ROVR and TID fields in the EARO are obfuscated with null the ROVR and TID fields in the EARO are obfuscated with null or
or random values to avoid network scanning and impersonation random values to avoid network scanning and impersonation attacks.
attacks.
o If the 6BBR receives an NS-DAD(EARO) for a newer registration, the o If the 6BBR receives an NS(EARO) for a newer registration, the
6BBR updates the entry and the routing state to forward packets to 6BBR updates the entry and the routing state to forward packets to
the new 6BBR, but keeps the entry REACHABLE. Afterwards, the 6BBR the new 6BBR, but keeps the entry REACHABLE. Afterwards, the 6BBR
MAY use REDIRECT messages to reroute traffic for the Registered MAY use REDIRECT messages to reroute traffic for the Registered
Address to the new 6BBR. Address to the new 6BBR.
o If the 6BBR receives an NA(EARO) for a newer registration, the o If the 6BBR receives an NA(EARO) for a newer registration, the
6BBR removes its entry and sends a NA(EARO) with a status of 3 6BBR removes its entry and sends a NA(EARO) with a status of 3
(MOVED) to the Registering Node, if the Registering Node is (MOVED) to the Registering Node, if the Registering Node is
different from the Registered Node. The 6BBR cleans up existing different from the Registered Node. The 6BBR cleans up existing
Neighbor Cache Entries in peer nodes as discussed in Section 5.1, Neighbor Cache entries in peer nodes as discussed in Section 5.1,
by unicasting to each such peer, or one broadcast NA(Override). by unicasting to each such peer, or one broadcast NA(Override).
o If the 6BBR receives a NS(LOOKUP) for a Registered Address, it o If the 6BBR receives 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
reasons. reasons.
The STALE state enables tracking of the backbone peers that have a The STALE state enables tracking of the backbone peers that have a
Neighbor Cache entry pointing to this 6BBR in case the Registered Neighbor Cache entry pointing to this 6BBR in case the Registered
Address shows up later. If the Registered Address is claimed by Address shows up later. If the Registered Address is claimed by
another node on the backbone, with an NS-DAD or an NA, the 6BBR does another 6LN on the backbone, with an NS-DAD or an NA, the 6BBR does
not defend the address. In STALE state: not defend the address. In STALE state:
o If STALE_DURATION elapses, the 6BBR removes the entry. o If STALE_DURATION elapses, the 6BBR removes the entry.
o Upon receiving an NA(Override) the 6BBR removes its entry and o Upon receiving an NA(Override) the 6BBR removes its entry and
sends a NA(EARO) with a status of 4 (removed) to the Registering sends a NA(EARO) with a status of 4 (removed) to the Registering
Node. Node.
o If the 6BBR receives a NS(LOOKUP) for a Registered Address, the o If the 6BBR receives 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
skipping to change at page 16, line 33 skipping to change at page 15, line 43
indicate liveness of the Registered Node, if they are different indicate liveness of the Registered Node, if they are different
nodes. nodes.
7. Security Considerations 7. Security Considerations
This specification applies to LLNS in which the link layer is This specification applies to LLNS in which the link layer is
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, the LLN Backbone Link or MAC sublayer cryptography. In particular, the LLN
MAC is required to provide secure unicast to/from the Backbone Router MAC is required to provide secure unicast to/from the Backbone Router
and secure Broadcast from the Backbone Router in a way that prevents and secure Broadcast from the Backbone Router in a way that prevents
tempering with or replaying the RA messages. tampering 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. Additional protection against address
additional protection against address theft such as provided by theft is provided by [I-D.ietf-6lo-ap-nd], which guarantees the
[I-D.ietf-6lo-ap-nd], which guarantees the ownership of the ROVR. ownership of the ROVR.
When the ownership of the ROVR cannot be assessed, this specification When the ownership of the ROVR cannot be assessed, this specification
limits the cases where the ROVR and the TID are multicasted, and limits the cases where the ROVR 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.
8. 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
skipping to change at page 17, line 4 skipping to change at page 16, line 16
limits the cases where the ROVR and the TID are multicasted, and limits the cases where the ROVR 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.
8. 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
9. IANA Considerations 9. IANA Considerations
This document has no request to IANA. This document has no request to IANA.
10. Acknowledgments 10. Future Work
Future documents may extend this specification by allowing the 6BBR
to redistribute host routes in routing protocols that would operate
over the backbone, or in MIPv6, or FMIP, or the Locator/ID Separation
Protocol (LISP) [RFC6830] to support mobility on behalf of the 6LNs,
etc...
11. Acknowledgments
Kudos to Eric Levy-Abegnoli who designed the First Hop Security Kudos to Eric Levy-Abegnoli who designed the First Hop Security
infrastructure at Cisco. infrastructure at Cisco.
11. References 12. References
11.1. Normative References 12.1. Normative References
[I-D.ietf-6lo-rfc6775-update] [I-D.ietf-6lo-rfc6775-update]
Thubert, P., Nordmark, E., Chakrabarti, S., and C. Thubert, P., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for 6LoWPAN Neighbor Perkins, "Registration Extensions for 6LoWPAN Neighbor
Discovery", draft-ietf-6lo-rfc6775-update-21 (work in Discovery", draft-ietf-6lo-rfc6775-update-21 (work in
progress), June 2018. progress), June 2018.
[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,
skipping to change at page 18, line 10 skipping to change at page 17, line 28
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>. <https://www.rfc-editor.org/info/rfc4862>.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, Detecting Network Attachment in IPv6", RFC 6059,
DOI 10.17487/RFC6059, November 2010, DOI 10.17487/RFC6059, November 2010,
<https://www.rfc-editor.org/info/rfc6059>. <https://www.rfc-editor.org/info/rfc6059>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012,
<https://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,
<https://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200, (IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>. <https://www.rfc-editor.org/info/rfc8200>.
11.2. Informative References 12.2. Informative References
[I-D.chakrabarti-nordmark-6man-efficient-nd]
Chakrabarti, S., Nordmark, E., Thubert, P., and M.
Wasserman, "IPv6 Neighbor Discovery Optimizations for
Wired and Wireless Networks", draft-chakrabarti-nordmark-
6man-efficient-nd-07 (work in progress), February 2015.
[I-D.delcarpio-6lo-wlanah]
Vega, L., Robles, I., and R. Morabito, "IPv6 over
802.11ah", draft-delcarpio-6lo-wlanah-01 (work in
progress), October 2015.
[I-D.ietf-6lo-ap-nd] [I-D.ietf-6lo-ap-nd]
Thubert, P., Sarikaya, B., and M. Sethi, "Address Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
Protected Neighbor Discovery for Low-power and Lossy "Address Protected Neighbor Discovery for Low-power and
Networks", draft-ietf-6lo-ap-nd-07 (work in progress), Lossy Networks", draft-ietf-6lo-ap-nd-08 (work in
September 2018. progress), October 2018.
[I-D.ietf-6lo-nfc]
Choi, Y., Hong, Y., Youn, J., Kim, D., and J. Choi,
"Transmission of IPv6 Packets over Near Field
Communication", draft-ietf-6lo-nfc-10 (work in progress),
July 2018.
[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-14 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-15 (work
in progress), April 2018. in progress), October 2018.
[I-D.ietf-6tisch-terminology]
Palattella, M., Thubert, P., Watteyne, T., and Q. Wang,
"Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e",
draft-ietf-6tisch-terminology-10 (work in progress), March
2018.
[I-D.ietf-bier-architecture]
Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and
S. Aldrin, "Multicast using Bit Index Explicit
Replication", draft-ietf-bier-architecture-08 (work in
progress), September 2017.
[I-D.ietf-ipv6-multilink-subnets] [I-D.ietf-mboned-ieee802-mcast-problems]
Thaler, D. and C. Huitema, "Multi-link Subnet Support in Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in Zuniga, "Multicast Considerations over IEEE 802 Wireless
progress), July 2002. Media", draft-ietf-mboned-ieee802-mcast-problems-02 (work
in progress), August 2018.
[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]
Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets
over IEEE 1901.2 Narrowband Powerline Communication
Networks", draft-popa-6lo-6loplc-ipv6-over-
ieee19012-networks-00 (work in progress), March 2014.
[I-D.vyncke-6man-mcast-not-efficient]
Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A.
Yourtchenko, "Why Network-Layer Multicast is Not Always
Efficient At Datalink Layer", draft-vyncke-6man-mcast-not-
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.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<https://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,
<https://www.rfc-editor.org/info/rfc3971>. <https://www.rfc-editor.org/info/rfc3971>.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>. <https://www.rfc-editor.org/info/rfc3972>.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
skipping to change at page 20, line 49 skipping to change at page 19, line 15
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Ed., "Control And Provisioning of Wireless Access Points Ed., "Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification", RFC 5415, (CAPWAP) Protocol Specification", RFC 5415,
DOI 10.17487/RFC5415, March 2009, DOI 10.17487/RFC5415, March 2009,
<https://www.rfc-editor.org/info/rfc5415>. <https://www.rfc-editor.org/info/rfc5415>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>. 2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>. <https://www.rfc-editor.org/info/rfc6830>.
[RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability [RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability
Detection Is Too Impatient", RFC 7048, Detection Is Too Impatient", RFC 7048,
DOI 10.17487/RFC7048, January 2014, DOI 10.17487/RFC7048, January 2014,
<https://www.rfc-editor.org/info/rfc7048>. <https://www.rfc-editor.org/info/rfc7048>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>. 2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<https://www.rfc-editor.org/info/rfc7217>.
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
over ITU-T G.9959 Networks", RFC 7428,
DOI 10.17487/RFC7428, February 2015,
<https://www.rfc-editor.org/info/rfc7428>.
[RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss [RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss
Resiliency for Router Solicitations", RFC 7559, Resiliency for Router Solicitations", RFC 7559,
DOI 10.17487/RFC7559, May 2015, DOI 10.17487/RFC7559, May 2015,
<https://www.rfc-editor.org/info/rfc7559>. <https://www.rfc-editor.org/info/rfc7559>.
[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
<https://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,
<https://www.rfc-editor.org/info/rfc7772>. <https://www.rfc-editor.org/info/rfc7772>.
[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, 12.3. External Informative References
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, <https://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, <https://www.rfc-editor.org/info/rfc8163>.
11.3. External Informative References
[IEEEstd8021] [IEEEstd8021]
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 Part 1: Bridging and metropolitan area networks Part 1: Bridging and
Architecture". Architecture".
[IEEEstd80211] [IEEEstd80211]
IEEE standard for Information Technology, "IEEE Standard IEEE standard for Information Technology, "IEEE Standard
skipping to change at page 22, line 41 skipping to change at page 20, line 27
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)".
[IEEEstd802154] [IEEEstd802154]
IEEE standard for Information Technology, "IEEE Standard IEEE standard for Information Technology, "IEEE Standard
for Local and metropolitan area networks -- Part 15.4: for Local and metropolitan area networks -- Part 15.4:
Low-Rate Wireless Personal Area Networks (LR-WPANs)". Low-Rate Wireless Personal Area Networks (LR-WPANs)".
Authors' Addresses Appendix A. Changes from revision 07 to revision 08
This section lists the changes between draft-ietf-6lo-backbone-router
revisions ...-07.txt and ...-08.txt.
o Reorganized the order of presentation of some sections so that
related material is closer together.
o Added "Future Work" section.
o Added this section detailing recent changes.
o Used '6LN' when LLN node is meant.
o Updated bibliographic citations.
Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254 MOUGINS - Sophia Antipolis 06254
FRANCE FRANCE
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Charles E. Perkins Charles E. Perkins
Futurewei Futurewei
2330 Central Expressway 2330 Central Expressway
Santa Clara 95050 Santa Clara 95050
United States of America United States of America
Email: charliep@computer.org Email: charliep@computer.org
 End of changes. 107 change blocks. 
436 lines changed or deleted 351 lines changed or added

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