draft-ietf-6lo-backbone-router-15.txt   draft-ietf-6lo-backbone-router-16.txt 
6lo P. Thubert, Ed. 6lo P.T. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6775, 8505 (if approved) C. Perkins Updates: 6775, 8505 (if approved) C.E. Perkins
Intended status: Standards Track Futurewei Intended status: Standards Track Blue Meadow Networking
Expires: August 10, 2020 E. Levy-Abegnoli Expires: 11 August 2020 E.L.A. Levy-Abegnoli
Cisco Systems Cisco Systems
February 7, 2020 8 February 2020
IPv6 Backbone Router IPv6 Backbone Router
draft-ietf-6lo-backbone-router-15 draft-ietf-6lo-backbone-router-16
Abstract Abstract
This document updates RFC 6775 and RFC 8505 in order to enable proxy This document updates RFC 6775 and RFC 8505 in order to enable proxy
services for IPv6 Neighbor Discovery by Routing Registrars called services for IPv6 Neighbor Discovery by Routing Registrars called
Backbone Routers. Backbone Routers are placed along the wireless Backbone Routers. Backbone Routers are placed along the wireless
edge of a Backbone, and federate multiple wireless links to form a edge of a Backbone, and federate multiple wireless links to form a
single Multi-Link Subnet. single Multi-Link Subnet.
Status of This Memo Status of This Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 August 10, 2020. This Internet-Draft will expire on 11 August 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6
2.4. References . . . . . . . . . . . . . . . . . . . . . . . 7 2.4. References . . . . . . . . . . . . . . . . . . . . . . . 7
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Updating RFC 6775 and RFC 8505 . . . . . . . . . . . . . 11 3.1. Updating RFC 6775 and RFC 8505 . . . . . . . . . . . . . 10
3.2. Access Link . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Access Link . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Route-Over Mesh . . . . . . . . . . . . . . . . . . . . . 13 3.3. Route-Over Mesh . . . . . . . . . . . . . . . . . . . . . 12
3.4. The Binding Table . . . . . . . . . . . . . . . . . . . . 15 3.4. The Binding Table . . . . . . . . . . . . . . . . . . . . 14
3.5. Primary and Secondary 6BBRs . . . . . . . . . . . . . . . 16 3.5. Primary and Secondary 6BBRs . . . . . . . . . . . . . . . 15
3.6. Using Optimistic DAD . . . . . . . . . . . . . . . . . . 17 3.6. Using Optimistic DAD . . . . . . . . . . . . . . . . . . 16
4. Multi-Link Subnet Considerations . . . . . . . . . . . . . . 17 4. Multi-Link Subnet Considerations . . . . . . . . . . . . . . 16
5. Optional 6LBR serving the Multi-Link Subnet . . . . . . . . . 18 5. Optional 6LBR serving the Multi-Link Subnet . . . . . . . . . 17
6. Using IPv6 ND Over the Backbone Link . . . . . . . . . . . . 19 6. Using IPv6 ND Over the Backbone Link . . . . . . . . . . . . 18
7. Routing Proxy Operations . . . . . . . . . . . . . . . . . . 19 7. Routing Proxy Operations . . . . . . . . . . . . . . . . . . 18
8. Bridging Proxy Operations . . . . . . . . . . . . . . . . . . 20 8. Bridging Proxy Operations . . . . . . . . . . . . . . . . . . 19
9. Creating and Maintaining a Binding . . . . . . . . . . . . . 21 9. Creating and Maintaining a Binding . . . . . . . . . . . . . 20
9.1. Operations on a Binding in Tentative State . . . . . . . 23 9.1. Operations on a Binding in Tentative State . . . . . . . 22
9.2. Operations on a Binding in Reachable State . . . . . . . 24 9.2. Operations on a Binding in Reachable State . . . . . . . 23
9.3. Operations on a Binding in Stale State . . . . . . . . . 25 9.3. Operations on a Binding in Stale State . . . . . . . . . 24
10. Registering Node Considerations . . . . . . . . . . . . . . . 25 10. Registering Node Considerations . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 27 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 26
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 15. Normative References . . . . . . . . . . . . . . . . . . . . 26
15.1. Normative References . . . . . . . . . . . . . . . . . . 27 16. Informative References . . . . . . . . . . . . . . . . . . . 28
15.2. Informative References . . . . . . . . . . . . . . . . . 29 Appendix A. Possible Future Extensions . . . . . . . . . . . . . 30
Appendix A. Possible Future Extensions . . . . . . . . . . . . . 31 Appendix B. Applicability and Requirements Served . . . . . . . 31
Appendix B. Applicability and Requirements Served . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient
and reliable broadcast service for wired networks; applications and and reliable broadcast service for wired networks; applications and
protocols have been built that heavily depend on that feature for protocols have been built that heavily depend on that feature for
their core operation. Unfortunately, Low-Power Lossy Networks (LLNs) their core operation. Unfortunately, Low-Power Lossy Networks (LLNs)
and local wireless networks generally do not provide the broadcast and local wireless networks generally do not provide the broadcast
capabilities of Ethernet Bridging in an economical fashion. capabilities of Ethernet Bridging in an economical fashion.
As a result, protocols designed for bridged networks that rely on As a result, protocols designed for bridged networks that rely on
multicast and broadcast often exhibit disappointing behaviours when multicast and broadcast often exhibit disappointing behaviours when
employed unmodified on a local wireless medium (see employed unmodified on a local wireless medium (see
[I-D.ietf-mboned-ieee802-mcast-problems]). [I-D.ietf-mboned-ieee802-mcast-problems]).
Wi-Fi [IEEEstd80211] Access Points (APs) deployed in an Extended Wi-Fi [IEEEstd80211] Access Points (APs) deployed in an Extended
Service Set (ESS) act as Ethernet Bridges [IEEEstd8021], with the Service Set (ESS) act as Ethernet Bridges [IEEEstd8021], with the
property that the bridging state is established at the time of property that the bridging state is established at the time of
association. This ensures connectivity to the end node (the Wi-Fi association. This ensures connectivity to the end node (the Wi-Fi
STA) and protects the wireless medium against broadcast-intensive STA) and protects the wireless medium against broadcast-intensive
Transparent Bridging reactive Lookups. Transparent Bridging reactive Lookups. In other words, the
association process is used to register the MAC Address of the STA to
In other words, the association process is used to register the MAC the AP. The AP subsequently proxies the bridging operation and does
Address of the STA to the AP. The AP subsequently proxies the not need to forward the broadcast Lookups over the radio.
bridging operation and does not need to forward the broadcast Lookups
over the radio.
In the same way as Transparent Bridging, IPv6 [RFC8200] Neighbor In the same way as Transparent Bridging, IPv6 [RFC8200] Neighbor
Discovery [RFC4861] [RFC4862] Protocol (IPv6 ND) is a reactive Discovery [RFC4861] [RFC4862] Protocol (IPv6 ND) is a reactive
protocol, based on multicast transmissions to locate an on-link protocol, based on multicast transmissions to locate an on-link
correspondent and ensure the uniqueness of an IPv6 address. The correspondent and ensure the uniqueness of an IPv6 address. The
mechanism for Duplicate Address Detection (DAD) [RFC4862] was mechanism for Duplicate Address Detection (DAD) [RFC4862] was
designed for the efficient broadcast operation of Ethernet Bridging. designed for the efficient broadcast operation of Ethernet Bridging.
Since broadcast can be unreliable over wireless media, DAD often Since broadcast can be unreliable over wireless media, DAD often
fails to discover duplications [I-D.yourtchenko-6man-dad-issues]. In fails to discover duplications [I-D.yourtchenko-6man-dad-issues]. In
practice, the fact that IPv6 addresses very rarely conflict is mostly practice, the fact that IPv6 addresses very rarely conflict is mostly
skipping to change at page 4, line 35 skipping to change at page 4, line 33
incomplete knowledge of the state of the network. incomplete knowledge of the state of the network.
This specification defines the 6BBR as a Routing Registrar [RFC8505] This specification defines the 6BBR as a Routing Registrar [RFC8505]
that provides proxy services for IPv6 Neighbor Discovery. As that provides proxy services for IPv6 Neighbor Discovery. As
represented in Figure 1, Backbone Routers federate multiple LLNs over represented in Figure 1, Backbone Routers federate multiple LLNs over
a Backbone Link to form a Multi-Link Subnet (MLSN). The MLSN breaks a Backbone Link to form a Multi-Link Subnet (MLSN). The MLSN breaks
the Layer 2 continuity and splits the broadcast domain, in a fashion the Layer 2 continuity and splits the broadcast domain, in a fashion
that each Link, including the backbone, is its own broadcast domain. that each Link, including the backbone, is its own broadcast domain.
This means that devices that rely on a link-scope multicast on the This means that devices that rely on a link-scope multicast on the
backbone will only reach other nodes on the backbone but not LLN backbone will only reach other nodes on the backbone but not LLN
nodes. The same goes a packet that is sent with a hop limit of 1 or nodes. A key property of MLSNs is that link-local traffic and
using a Link-Local destination address. This packet may reach other traffic with a hop limit of 1 will not transit to nodes in the same
nodes on the backbone but not LLN Nodes. In order to enable the subnet on a different link, something that may produce unexpected
continuity of IPv6 ND operations beyond the backbone, and enable behavior in software that expects a subnet to be entirely contained
communication using Global or Unique Local Addresses between any pair within a single link. In order to enable the continuity of IPv6 ND
of nodes in the MLSN, Backbone Routers placed along the LLN edge of operations beyond the backbone, and enable communication using Global
the Backbone handle IPv6 ND on behalf of Registered Nodes and forward or Unique Local Addresses between any pair of nodes in the MLSN,
IPv6 packets back and forth. Backbone Routers placed along the LLN edge of the Backbone handle
IPv6 ND on behalf of Registered Nodes and forward IPv6 packets back
and forth.
A 6LoWPAN node (6LN) registers all its IPv6 Addresses using an A 6LoWPAN node (6LN) registers all its IPv6 Addresses using an
NS(EARO) as specified in [RFC8505] to the 6BBR. The 6BBR is also a NS(EARO) as specified in [RFC8505] to the 6BBR. The 6BBR is also a
Border Router that performs IPv6 Neighbor Discovery (IPv6 ND) Border Router that performs IPv6 Neighbor Discovery (IPv6 ND)
operations on its Backbone interface on behalf of the 6LNs that have operations on its Backbone interface on behalf of the 6LNs that have
registered addresses on its LLN interfaces without the need of a registered addresses on its LLN interfaces without the need of a
broadcast over the wireless medium. A 6LN that resides on the broadcast over the wireless medium. A 6LN that resides on the
backbone does not register to the SNMA groups associated to its backbone does not register to the SNMA groups associated to its
Registered Addresses and defers to the 6BBR to answer or preferably Registered Addresses and defers to the 6BBR to answer or preferably
forward to it as unicast the corresponding multicast packets. forward to it as unicast the corresponding multicast packets.
skipping to change at page 5, line 23 skipping to change at page 5, line 21
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2.2. New Terms 2.2. New Terms
This document introduces the following terminology: This document introduces the following terminology:
Federated Federated: A subnet that comprises a Backbone and one or more
(wireless) access links, is said to be federated into one Multi-
A subnet that comprises a Backbone and one or more (wireless) Link Subnet. The proxy-ND operation of 6BBRs over the Backbone
access links, is said to be federated into one Multi-Link and the access links provides the appearance of a subnet for IPv6
Subnet. The proxy-ND operation of 6BBRs over the Backbone and ND.
the access links provides the appearance of a subnet for IPv6
ND.
Sleeping Proxy
A 6BBR acts as a Sleeping Proxy if it answers ND Neighbor
Solicitations over the Backbone on behalf of the Registering
Node which might be in a sleep state in a low power network.
The Sleeping Proxy that is also a Bridging Proxy will
preferably forward the relevant messages to the Registering
Node as unicast frames in accord to the duty cycle of the
Registering Node and let it respond.
Routing Proxy
A Routing Proxy provides IPv6 ND proxy functions and enables
the MLSN operation over federated links that may not be
compatible for bridging. The Routing Proxy advertises its own
MAC Address as the Target Link Layer Address (TLLA) in the
proxied NAs over the Backbone, and routes at the Network Layer
between the federated links.
Bridging Proxy Sleeping Proxy: A 6BBR acts as a Sleeping Proxy if it answers ND
A Bridging Proxy provides IPv6 ND proxy functions while Neighbor Solicitations over the Backbone on behalf of the
preserving forwarding continuity at the MAC Layer. The Registering Node which might be in a sleep state in a low power
Bridging Proxy advertises the MAC Address of the Registering network. The Sleeping Proxy that is also a Bridging Proxy will
Node as the TLLA in the proxied NAs over the Backbone. In that preferably forward the relevant messages to the Registering Node
case, the MAC Address and the mobility of 6LN is still visible as unicast frames in accord to the duty cycle of the Registering
across the bridged Backbone, and the 6BBR may be configured to Node and let it respond.
proxy for Link Local Addresses.
Binding Table Routing Proxy: A Routing Proxy provides IPv6 ND proxy functions and
enables the MLSN operation over federated links that may not be
compatible for bridging. The Routing Proxy advertises its own MAC
Address as the Target Link Layer Address (TLLA) in the proxied NAs
over the Backbone, and routes at the Network Layer between the
federated links.
The Binding Table is an abstract database that is maintained by Bridging Proxy: A Bridging Proxy provides IPv6 ND proxy functions
the 6BBR to store the state associated with its registrations. while preserving forwarding continuity at the MAC Layer. The
Bridging Proxy advertises the MAC Address of the Registering Node
as the TLLA in the proxied NAs over the Backbone. In that case,
the MAC Address and the mobility of 6LN is still visible across
the bridged Backbone, and the 6BBR may be configured to proxy for
Link Local Addresses.
Binding Binding Table: The Binding Table is an abstract database that is
maintained by the 6BBR to store the state associated with its
registrations.
A Binding is an abstract state associated to one registration, Binding: A Binding is an abstract state associated to one
in other words one entry in the Binding Table. registration, in other words one entry in the Binding Table.
2.3. Abbreviations 2.3. Abbreviations
This document uses the following abbreviations: This document uses the following abbreviations:
6BBR: 6LoWPAN Backbone Router 6BBR: 6LoWPAN Backbone Router
6LBR: 6LoWPAN Border Router
6LBR: 6LoWPAN Border Router
6LN: 6LoWPAN Node 6LN: 6LoWPAN Node
6LR: 6LoWPAN Router 6LR: 6LoWPAN Router
6CIO: Capability Indication Option
6CIO: Capability Indication Option
ARO: Address Registration Option ARO: Address Registration Option
DAC: Duplicate Address Confirmation DAC: Duplicate Address Confirmation
DAD: Duplicate Address Detection DAD: Duplicate Address Detection
DAR: Duplicate Address Request DAR: Duplicate Address Request
EARO: Extended Address Registration Option
EARO: Extended Address Registration Option EDAC: Extended Duplicate Address Confirmation
EDAR: Extended Duplicate Address Request
EDAC: Extended Duplicate Address Confirmation
EDAR: Extended Duplicate Address Request
DODAG: Destination-Oriented Directed Acyclic Graph DODAG: Destination-Oriented Directed Acyclic Graph
ID: Identifier ID: Identifier
LLN: Low-Power and Lossy Network LLN: Low-Power and Lossy Network
NA: Neighbor Advertisement
NA: Neighbor Advertisement MAC: Medium Access Control
NCE: Neighbor Cache Entry NCE: Neighbor Cache Entry
ND: Neighbor Discovery
ND: Neighbor Discovery
NDP: Neighbor Discovery Protocol NDP: Neighbor Discovery Protocol
NS: Neighbor Solicitation
NS: Neighbor Solicitation
NS(DAD): NDP NS message used for the purpose of duplication NS(DAD): NDP NS message used for the purpose of duplication
avoidance (multicast) avoidance (multicast)
NS(Lookup): NDP NS message used for the purpose of address NS(Lookup): NDP NS message used for the purpose of address
resolution (multicast) resolution (multicast)
NS(NUD): NDP NS message used for the purpose of unreachability NS(NUD): NDP NS message used for the purpose of unreachability
detection (unicast) detection (unicast)
NUD: Neighbor Unreachability Detection NUD: Neighbor Unreachability Detection
ROVR: Registration Ownership Verifier
ROVR: Registration Ownership Verifier
RPL: IPv6 Routing Protocol for LLNs RPL: IPv6 Routing Protocol for LLNs
RA: Router Advertisement
RA: Router Advertisement RS: Router Solicitation
SNMA: Solicited-Node Multicast Address
RS: Router Solicitation
SNMA: Solicited-Node Multicast Address
LLA: Link Layer Address (aka MAC address) LLA: Link Layer Address (aka MAC address)
SLLA: Source Link Layer Address
SLLA: Source Link Layer Address TLLA: Target Link Layer Address
TLLA: Target Link Layer Address
TID: Transaction ID TID: Transaction ID
2.4. References 2.4. References
In this document, readers will encounter terms and concepts that are In this document, readers will encounter terms and concepts that are
discussed in the following documents: discussed in the following documents:
o "Neighbor Discovery for IP version 6" [RFC4861], "IPv6 Stateless * "Neighbor Discovery for IP version 6" [RFC4861], "IPv6 Stateless
Address Autoconfiguration" [RFC4862] and "Optimistic Duplicate Address Autoconfiguration" [RFC4862] and "Optimistic Duplicate
Address Detection" [RFC4429], Address Detection" [RFC4429],
o "Neighbor Discovery Proxies (proxy-ND)" [RFC4389] and "Multi-Link * "Neighbor Discovery Proxies (proxy-ND)" [RFC4389] and "Multi-Link
Subnet Issues" [RFC4903], Subnet Issues" [RFC4903],
o "Problem Statement and Requirements for IPv6 over Low-Power * "Problem Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], and Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], and
o Neighbor Discovery Optimization for Low-Power and Lossy Networks * Neighbor Discovery Optimization for Low-Power and Lossy Networks
[RFC6775] and "Registration Extensions for 6LoWPAN Neighbor [RFC6775] and "Registration Extensions for 6LoWPAN Neighbor
Discovery" [RFC8505]. Discovery" [RFC8505].
3. Overview 3. Overview
This section and its subsections present a non-normative high level This section and its subsections present a non-normative high level
view of the operation of the 6BBR. The following sections cover the view of the operation of the 6BBR. The following sections cover the
normative part. Figure 1 illustrates a backbone link that federates normative part. Figure 1 illustrates a backbone link that federates
a collection of LLNs as a single IPv6 Subnet, with a number of 6BBRs a collection of LLNs as a single IPv6 Subnet, with a number of 6BBRs
providing proxy-ND services to their attached LLNs. providing proxy-ND services to their attached LLNs.
skipping to change at page 9, line 24 skipping to change at page 8, line 24
| 6BBR | | 6BBR | | 6BBR | | 6BBR | | 6BBR | | 6BBR |
| | | | | | | | | | | |
+------+ +------+ +------+ +------+ +------+ +------+
o Wireless side o o o o o o o Wireless side 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 o o o o o o o o o o o o o o o o o o LLN 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
Figure 1: Backbone Link and Backbone Routers Figure 1: Backbone Link and Backbone Routers
The main features of a 6BBR are as follows: The main features of a 6BBR are as follows:
o Multi-Link-subnet functions (provided by the 6BBR on the backbone) * Multi-Link-subnet functions (provided by the 6BBR on the backbone)
performed on behalf of registered 6LNs, and performed on behalf of registered 6LNs, and
o Routing registrar services that reduce multicast within the LLN: * Routing registrar services that reduce multicast within the LLN:
* Binding Table management
* failover, e.g., due to mobility * Binding Table management
* failover, e.g., due to mobility
Each Backbone Router (6BBR) maintains a data structure for its Each Backbone Router (6BBR) maintains a data structure for its
Registered Addresses called a Binding Table. The combined Binding Registered Addresses called a Binding Table. The combined Binding
Tables of all the 6BBRs on a backbone form a distributed database of Tables of all the 6BBRs on a backbone form a distributed database of
6LNs that reside in the LLNs or on the IPv6 Backbone. 6LNs that reside in the LLNs or on the IPv6 Backbone.
Unless otherwise configured, a 6BBR does the following: Unless otherwise configured, a 6BBR does the following:
o Create a new entry in a Binding Table for a new Registered Address * Create a new entry in a Binding Table for a new Registered Address
and ensure that the Address is not duplicated over the Backbone and ensure that the Address is not duplicated over the Backbone.
o Advertise a Registered Address over the Backbone using an * Advertise a Registered Address over the Backbone using an
unsolicited NA message, asynchronously or as a response to a NS unsolicited NA message, asynchronously or as a response to a NS
message. This includes joining the multicast group associated to message. This includes joining the multicast group associated to
the SNMA derived from the Registered Address as specified in the SNMA derived from the Registered Address as specified in
section 7.2.1. of [RFC4861] over the Backbone. section 7.2.1. of [RFC4861] over the Backbone.
o The 6BBR may respond immediately as a Proxy in lieu of the * The 6BBR may respond immediately as a Proxy in lieu of the
Registering Node, e.g., if the Registering Node has a sleeping Registering Node, e.g., if the Registering Node has a sleeping
cycle that the 6BBR does not want to interrupt, and if the 6BR has cycle that the 6BBR does not want to interrupt, or if the 6BBR has
a recent state that is deemed fresh enough to permit the proxied a recent state that is deemed fresh enough to permit the proxied
response. It is preferred, though, that the 6BBR checks whether response. It is preferred, though, that the 6BBR checks whether
the Registering Node is still responsive on the Registered the Registering Node is still responsive on the Registered
Address. to that effect: Address. To that effect:
* as a Bridging Proxy, the 6BBR forwards the multicast DAD and
Address Lookup messages as a unicast MAC-Layer frames to the
MAC address of the Registering Node that matches the Target in
the ND message, and forwards as is the unicast Neighbor
Unreachability Detection (NUD) messages, so as to let the
Registering Node answer with the ND Message and options that it
sees fit;
* as a Routing Proxy, the 6BBR checks the liveliness of the - as a Bridging Proxy:
Registering Node, e.g., using a NUD verification, before the 6BBR forwards the multicast DAD and Address Lookup messages
answering on its behalf. as a unicast MAC-Layer frames to the MAC address of the
Registering Node that matches the Target in the ND message, and
forwards as is the unicast Neighbor Unreachability Detection
(NUD) messages, so as to let the Registering Node answer with
the ND Message and options that it sees fit;
- as a Routing Proxy:
the 6BBR checks the liveliness of the Registering Node, e.g.,
using a NUD verification, before answering on its behalf.
o Deliver packets arriving from the LLN, using Neighbor Solicitation * Deliver packets arriving from the LLN, using Neighbor Solicitation
messages to look up the destination over the Backbone. messages to look up the destination over the Backbone.
o Forward or bridge packets between the LLN and the Backbone. * Forward or bridge packets between the LLN and the Backbone.
o Verify liveness for a registration, when needed. * Verify liveness for a registration, when needed.
The first of these functions enables the 6BBR to fulfill its role as The first of these functions enables the 6BBR to fulfill its role as
a Routing Registrar for each of its attached LLNs. The remaining a Routing Registrar for each of its attached LLNs. The remaining
functions fulfill the role of the 6BBRs as the border routers functions fulfill the role of the 6BBRs as the border routers
connecting the Multi-link IPv6 subnet to the Internet. connecting the Multi-link IPv6 subnet to the Internet.
The operation of IPv6 ND and of proxy-ND are not mutually exclusive The operation of IPv6 ND and of proxy-ND are not mutually exclusive
on the Backbone, meaning that nodes attached to the Backbone and on the Backbone, meaning that nodes attached to the Backbone and
using IPv6 ND can transparently interact with 6LNs that rely on a using IPv6 ND can transparently interact with 6LNs that rely on a
6BBR to proxy ND for them, whether the 6LNs are reachable over an LLN 6BBR to proxy ND for them, whether the 6LNs are reachable over an LLN
skipping to change at page 11, line 8 skipping to change at page 10, line 8
The registration to a proxy service uses an NS/NA(EARO) exchange. The registration to a proxy service uses an NS/NA(EARO) exchange.
The 6BBR operation resembles that of a Mobile IPv6 (MIPv6) [RFC6275] The 6BBR operation resembles that of a Mobile IPv6 (MIPv6) [RFC6275]
Home Agent (HA). The combination of a 6BBR and a MIPv6 HA enables Home Agent (HA). The combination of a 6BBR and a MIPv6 HA enables
full mobility support for 6LNs, inside and outside the links that full mobility support for 6LNs, inside and outside the links that
form the subnet. form the subnet.
The 6BBRs use the Extended Address Registration Option (EARO) defined The 6BBRs use the Extended Address Registration Option (EARO) defined
in [RFC8505] as follows: in [RFC8505] as follows:
o The EARO is used in the IPv6 ND exchanges over the Backbone * The EARO is used in the IPv6 ND exchanges over the Backbone
between the 6BBRs to help distinguish duplication from movement. between the 6BBRs to help distinguish duplication from movement.
Extended Duplicate Address Messages (EDAR and EDAC) may also be Extended Duplicate Address Messages (EDAR and EDAC) may also be
used between a 6LBR, if one is present, and the 6BBR. Address used between a 6LBR, if one is present, and the 6BBR. Address
duplication is detected using the ROVR field. Conflicting duplication is detected using the ROVR field. Conflicting
registrations to different 6BBRs for the same Registered Address registrations to different 6BBRs for the same Registered Address
are resolved using the TID field. are resolved using the TID field.
o The Link Layer Address (LLA) that the 6BBR advertises for the * The Link Layer Address (LLA) that the 6BBR advertises for the
Registered Address on behalf of the Registered Node over the Registered Address on behalf of the Registered Node over the
Backbone can belong to the Registering Node; in that case, the Backbone can belong to the Registering Node; in that case, the
6BBR (acting as a Bridging Proxy (see Section 8)) bridges the 6BBR (acting as a Bridging Proxy (see Section 8)) bridges the
unicast packets. Alternatively, the LLA can be that of the 6BBR unicast packets. Alternatively, the LLA can be that of the 6BBR
on the Backbone interface, in which case the 6BBR (acting as a on the Backbone interface, in which case the 6BBR (acting as a
Routing Proxy(see Section 7)) receives the unicast packets at Routing Proxy(see Section 7)) receives the unicast packets at
Layer 3 and routes over. Layer 3 and routes over.
3.1. Updating RFC 6775 and RFC 8505 3.1. Updating RFC 6775 and RFC 8505
skipping to change at page 12, line 19 skipping to change at page 11, line 19
+-----+ +-----+ +-----+ 6LN +-----+ +-----+ +-----+ 6LN
| Backbone side | | | Backbone side | |
----+-------+-----------------+---+-------------+----+----- ----+-------+-----------------+---+-------------+----+-----
| | | | | |
+------+ +------+ +------+ +------+ +------+ +------+
| 6BBR | | 6BBR | | 6BBR | | 6BBR | | 6BBR | | 6BBR |
| 6LR | | 6LR | | 6LR | | 6LR | | 6LR | | 6LR |
+------+ +------+ +------+ +------+ +------+ +------+
(6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN)
Figure 2: Access Link Use case Figure 2: Access Link Use case
Figure 3 illustrates a flow where 6LN forms an IPv6 Address and Figure 3 illustrates a flow where 6LN forms an IPv6 Address and
registers it to a 6BBR acting as a 6LR [RFC8505]. The 6BBR applies registers it to a 6BBR acting as a 6LR [RFC8505]. The 6BBR applies
ODAD (see Section 3.6) to the registered address to enable ODAD (see Section 3.6) to the registered address to enable
connectivity while the message flow is still in progress. connectivity while the message flow is still in progress.
In this example, a 6LBR is deployed on the backbone link to serve the In this example, a 6LBR is deployed on the backbone link to serve the
whole subnet, and EDAR / EDAC messages are used in combination with whole subnet, and EDAR / EDAC messages are used in combination with
DAD to enable coexistence with IPv6 ND over the backbone. DAD to enable coexistence with IPv6 ND over the backbone.
skipping to change at page 14, line 26 skipping to change at page 13, line 26
| | | | | |
+------+ +------+ +------+ +------+ +------+ +------+
| 6LBR | | 6LBR | | 6LBR | | 6LBR | | 6LBR | | 6LBR |
+------+ +------+ +------+ +------+ +------+ +------+
(6LN) (6LR) (6LN) (6LR) (6LN) (6LR) (6LR) (6LR)(6LN) (6LN) (6LR) (6LN) (6LR) (6LN) (6LR) (6LR) (6LR)(6LN)
(6LN)(6LR) (6LR) (6LN) (6LN) (6LR)(6LN) (6LR) (6LR) (6LR) (6LN) (6LN)(6LR) (6LR) (6LN) (6LN) (6LR)(6LN) (6LR) (6LR) (6LR) (6LN)
(6LR)(6LR) (6LR) (6LR) (6LR)(6LN) (6LR) (6LR)(6LR) (6LR)(6LR) (6LR) (6LR) (6LR)(6LN) (6LR) (6LR)(6LR)
(6LR) (6LR) (6LR) (6LR) (6LN)(6LR) (6LR) (6LR) (6LR) (6LR) (6LR) (6LR) (6LR) (6LR) (6LN)(6LR) (6LR) (6LR) (6LR) (6LR)
(6LN) (6LN)(6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN)(6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN) (6LN)
Figure 4: Route-Over Mesh Use case Figure 4: Route-Over Mesh Use case
Figure 5 illustrates IPv6 signaling that enables a 6LN (the Figure 5 illustrates IPv6 signaling that enables a 6LN (the
Registered Node) to form a Global or a Unique-Local Address and Registered Node) to form a Global or a Unique-Local Address and
register it to the 6LBR that serves its LLN using [RFC8505]. The register it to the 6LBR that serves its LLN using [RFC8505]. The
6LBR (the Registering Node) then proxies the [RFC8505] registration 6LBR (the Registering Node) then proxies the [RFC8505] registration
to the 6BBR to obtain proxy-ND services from the 6BBR. to the 6BBR to obtain proxy-ND services from the 6BBR.
As above, the RS sent initially by the 6LN(STA) is a transmitted as a As above, the RS sent initially by the 6LN(STA) is a transmitted as a
multicast but since it is intercepted by the 6BBR, it is never multicast but since it is intercepted by the 6BBR, it is never
effectively broadcast, and the multiple arrows associated to the ND effectively broadcast, and the multiple arrows associated to the ND
skipping to change at page 15, line 36 skipping to change at page 14, line 36
| | | | (EARO) | | | | (EARO)
| | | | | | | |
| | | NA(EARO) |<timeout> | | | NA(EARO) |<timeout>
| | |<--------------| | | |<--------------|
| | Extended DAC | | | | Extended DAC | |
| |<--------------| | | |<--------------| |
| NA(EARO) | | | | NA(EARO) | | |
|<--------------| | | |<--------------| | |
| | | | | | | |
Figure 5: Initial Registration Flow over Route-Over Mesh Figure 5: Initial Registration Flow over Route-Over Mesh
As a non-normative example of a Route-Over Mesh, the 6TiSCH As a non-normative example of a Route-Over Mesh, the 6TiSCH
architecture [I-D.ietf-6tisch-architecture] suggests using the RPL architecture [I-D.ietf-6tisch-architecture] suggests using the RPL
[RFC6550] routing protocol and collocating the RPL root with a 6LBR [RFC6550] routing protocol and collocating the RPL root with a 6LBR
that serves the LLN. The 6LBR is also either collocated with or that serves the LLN. The 6LBR is also either collocated with or
directly connected to the 6BBR over an IPv6 Link. directly connected to the 6BBR over an IPv6 Link.
3.4. The Binding Table 3.4. The Binding Table
Addresses in an LLN that are reachable from the Backbone by way of Addresses in an LLN that are reachable from the Backbone by way of
skipping to change at page 16, line 15 skipping to change at page 15, line 15
The 6BBR uses a combination of [RFC8505] and IPv6 ND over the The 6BBR uses a combination of [RFC8505] and IPv6 ND over the
Backbone to advertise the registration and avoid a duplication. Backbone to advertise the registration and avoid a duplication.
Conflicting registrations are solved by the 6BBRs, transparently to Conflicting registrations are solved by the 6BBRs, transparently to
the Registering Nodes. the Registering Nodes.
Only one 6LN may register a given Address, but the Address may be Only one 6LN may register a given Address, but the Address may be
registered to Multiple 6BBRs for higher availability. registered to Multiple 6BBRs for higher availability.
Over the LLN, Binding Table management is as follows: Over the LLN, Binding Table management is as follows:
o De-registrations (newer TID, same ROVR, null Lifetime) are * De-registrations (newer TID, same ROVR, null Lifetime) are
accepted with a status of 4 ("Removed"); the entry is deleted; accepted with a status of 4 ("Removed"); the entry is deleted;
o Newer registrations (newer TID, same ROVR, non-null Lifetime) are * Newer registrations (newer TID, same ROVR, non-null Lifetime) are
accepted with a status of 0 (Success); the Binding is updated with accepted with a status of 0 (Success); the Binding is updated with
the new TID, the Registration Lifetime and the Registering Node; the new TID, the Registration Lifetime and the Registering Node;
in Tentative state the EDAC response is held and may be in Tentative state the EDAC response 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.
o Identical registrations (same TID, same ROVR) from the same * Identical registrations (same TID, same ROVR) from the same
Registering Node are accepted with a status of 0 (Success). In Registering Node are accepted with a status of 0 (Success). In
Tentative state, the response is held and may be overwritten, but Tentative state, the response is held and may be overwritten, but
the response is eventually produced, carrying the result of the the response is eventually produced, carrying the result of the
DAD process; DAD process;
o Older registrations (older TID, same ROVR) from the same * Older registrations (older TID, same ROVR) from the same
Registering Node are discarded; Registering Node are discarded;
o 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 rejected with a status of 3
o a different Registering Node are rejected with a status of 3
(Moved); this may be rate limited to avoid undue interference; (Moved); this may be rate limited to avoid undue interference;
o Any registration for the same address but with a different ROVR is * Any registration for the same address but with a different ROVR is
rejected with a status of 1 (Duplicate). rejected with a status of 1 (Duplicate).
The operation of the Binding Table is specified in detail in The operation of the Binding Table is specified in detail in
Section 9. Section 9.
3.5. Primary and Secondary 6BBRs 3.5. Primary and Secondary 6BBRs
The same address may be successfully registered to more than one The same address may be successfully registered to more than one
6BBR, in which case the Registering Node uses the same EARO in all 6BBR, in which case the Registering Node uses the same EARO in all
the parallel registrations. To allow for this, ND(DAD) and NA the parallel registrations. To allow for this, ND(DAD) and NA
skipping to change at page 21, line 49 skipping to change at page 20, line 49
with the R flag set), the 6BBR creates a Binding and operates as a with the R flag set), the 6BBR creates a Binding and operates as a
6LR according to [RFC8505], interacting with the 6LBR if one is 6LR according to [RFC8505], interacting with the 6LBR if one is
present. present.
An implementation of a Routing Proxy that creates a Binding MUST also An implementation of a Routing Proxy that creates a Binding MUST also
create an associated Host route pointing to the registering node in create an associated Host route pointing to the registering node in
the LLN interface from which the registration was received. the LLN interface from which the registration was received.
The 6LR operation is modified as follows: The 6LR operation is modified as follows:
o EDAR and EDAC messages SHOULD carry a SLLAO and a TLLAO, * EDAR and EDAC messages SHOULD carry a SLLAO and a TLLAO,
respectively. respectively.
o A Bridging Proxy MAY register Link Local addresses at the 6BBR and * A Bridging Proxy MAY register Link Local addresses at the 6BBR and
proxy ND for these addresses over the backbone. proxy ND for these addresses over the backbone.
o An EDAC message with a status of 9 (6LBR Registry Saturated) is * An EDAC message with a status of 9 (6LBR Registry Saturated) is
assimilated as a status of 0 if a following DAD process protects assimilated as a status of 0 if a following DAD process protects
the address against duplication. the address against duplication.
This specification enables nodes on a Backbone Link to co-exist along This specification enables nodes on a Backbone Link to co-exist along
with nodes implementing IPv6 ND [RFC4861] as well as other non- with nodes implementing IPv6 ND [RFC4861] as well as other non-
normative specifications such as [I-D.bi-savi-wlan]. It is possible normative specifications such as [I-D.bi-savi-wlan]. It is possible
that not all IPv6 addresses on the Backbone are registered and known that not all IPv6 addresses on the Backbone are registered and known
to the 6LBR, and an EDAR/EDAC echange with the 6LBR might succeed to the 6LBR, and an EDAR/EDAC echange with the 6LBR might succeed
even for a duplicate address. Consequently, and unless even for a duplicate address. Consequently, and unless
administratively overridden, the 6BBR still needs to perform IPv6 ND administratively overridden, the 6BBR still needs to perform IPv6 ND
skipping to change at page 23, line 17 skipping to change at page 22, line 17
pointing the new 6BBR. pointing the new 6BBR.
9.1. Operations on a Binding in Tentative State 9.1. Operations on a Binding in Tentative State
The Tentative state covers a DAD period over the backbone during The Tentative state covers a DAD period over the backbone during
which an address being registered is checked for duplication using which an address being registered is checked for duplication using
procedures defined in [RFC4862]. procedures defined in [RFC4862].
For a Binding in Tentative state: For a Binding in Tentative state:
o The Binding MUST be removed if an NA message is received over the * The Binding MUST be removed if an NA message is received over the
Backbone for the Registered Address with no EARO, or containing an Backbone for the Registered Address with no EARO, or containing an
EARO with a status of 1 (Duplicate) that indicates an existing EARO with a status of 1 (Duplicate) that indicates an existing
registration owned by a different Registering Node. In that case, registration owned by a different Registering Node. In that case,
an NA MUST be sent back to the Registering Node with a status of 1 an NA MUST be sent back to the Registering Node with a status of 1
(Duplicate) in the EARO. This behavior might be overriden by (Duplicate) in the EARO. This behavior might be overriden by
policy, in particular if the registration is trusted, e.g., based policy, in particular if the registration is trusted, e.g., based
on the validation of the ROVR field (see [I-D.ietf-6lo-ap-nd]). on the validation of the ROVR field (see [I-D.ietf-6lo-ap-nd]).
o An NS(DAD) with no EARO or with an EARO that indicates a duplicate * An NS(DAD) with no EARO or with an EARO that indicates a duplicate
registration (i.e., different ROVR) MUST be answered with an NA registration (i.e., different ROVR) MUST be answered with an NA
message containing an EARO with a status of 1 (Duplicate) and the message containing an EARO with a status of 1 (Duplicate) and the
Override flag not set. This behavior might be overriden by Override flag not set. This behavior might be overriden by
policy, in particular if the registration is not trusted. policy, in particular if the registration is not trusted.
o The Binding MUST be removed if an NA message is received over the * The Binding MUST be removed if an NA message is received over the
Backbone for the Registered Address containing an EARO with a Backbone for the Registered Address containing an EARO with a
status of 3 (Moved), or an NS(DAD) with an EARO that indicates a status of 3 (Moved), or an NS(DAD) with an EARO that indicates a
fresher registration ([RFC8505]) for the same Registered Node fresher registration ([RFC8505]) for the same Registered Node
(i.e., same ROVR). A status of 3 is returned in the NA(EARO) back (i.e., same ROVR). A status of 3 is returned in the NA(EARO) back
to the Registering Node. to the Registering Node.
o NS(DAD) and NA messages containing an EARO that indicates a * NS(DAD) and NA messages containing an EARO that indicates a
registration for the same Registered Node that is not as fresh as registration for the same Registered Node that is not as fresh as
this SHOULD be answered with an NA message containing an EARO with this SHOULD be answered with an NA message containing an EARO with
a status of 3 (Moved) in order to clean up the situation a status of 3 (Moved) in order to clean up the situation
immediately. immediately.
o Other NS(DAD) and NA messages from the Backbone are ignored. * Other NS(DAD) and NA messages from the Backbone are ignored.
o NS(Lookup) and NS(NUD) messages SHOULD be optimistically answered * NS(Lookup) and NS(NUD) messages SHOULD be optimistically answered
with an NA message containing an EARO with a status of 0 and the with an NA message containing an EARO with a status of 0 and the
Override flag not set (see Section 3.6). Override flag not set (see Section 3.6). If optimistic DAD is
disabled, then they SHOULD be queued to be answered when the
o If optimistic DAD is disabled, then they SHOULD be queued to be Binding goes to Reachable state.
answered when the Binding goes to Reachable state.
When the TENTATIVE_DURATION (Section 12) timer elapses, the Binding When the TENTATIVE_DURATION (Section 12) timer elapses, the Binding
is placed in Reachable state for the Registration Lifetime, and the is placed in Reachable state for the Registration Lifetime, and the
6BBR returns an NA(EARO) to the Registering Node with a status of 0 6BBR returns an NA(EARO) to the Registering Node with a status of 0
(Success). (Success).
The 6BBR also attempts to take over any existing Binding from other The 6BBR also attempts to take over any existing Binding from other
6BBRs and to update existing NCEs in backbone nodes. This is done by 6BBRs and to update existing NCEs in backbone nodes. This is done by
sending an NA message with an EARO and the Override flag set over the sending an NA message with an EARO and the Override flag set over the
backbone (see Section 7 and Section 8). backbone (see Section 7 and Section 8).
skipping to change at page 24, line 28 skipping to change at page 23, line 28
DAD process. DAD process.
If the Registration Lifetime is of a long duration, an implementation If the Registration Lifetime is of a long duration, an implementation
might be configured to reassess the availability of the Registering might be configured to reassess the availability of the Registering
Node at a lower period, using a NUD procedure as specified in Node at a lower period, using a NUD procedure as specified in
[RFC7048]. If the NUD procedure fails, the Binding SHOULD be placed [RFC7048]. If the NUD procedure fails, the Binding SHOULD be placed
in Stale state immediately. in Stale state immediately.
For a Binding in Reachable state: For a Binding in Reachable state:
o The Binding MUST be removed if an NA or an NS(DAD) message is * The Binding MUST be removed if an NA or an NS(DAD) message is
received over the Backbone for the Registered Address containing received over the Backbone for the Registered Address containing
an EARO that indicates a fresher registration ([RFC8505]) for the an EARO that indicates a fresher registration ([RFC8505]) for the
same Registered Node (i.e., same ROVR). A status of 4 (Removed) same Registered Node (i.e., same ROVR). A status of 4 (Removed)
is returned in an asynchronous NA(EARO) to the Registering Node. is returned in an asynchronous NA(EARO) to the Registering Node.
Based on configuration, an implementation may delay this operation Based on configuration, an implementation may delay this operation
by a timer with a short setting, e.g., a few seconds to a minute, by a timer with a short setting, e.g., a few seconds to a minute,
in order to a allow for a parallel registration to reach this in order to a allow for a parallel registration to reach this
node, in which case the NA might be ignored. node, in which case the NA might be ignored.
o An NS(DAD) with no EARO or with an EARO that indicates a duplicate * An NS(DAD) with no EARO or with an EARO that indicates a duplicate
registration (i.e., different ROVR) MUST be answered with an NA registration (i.e., different ROVR) MUST be answered with an NA
message containing an EARO with a status of 1 (Duplicate) and the message containing an EARO with a status of 1 (Duplicate) and the
Override flag not set. Override flag not set.
o NS(DAD) and NA messages containing an EARO that indicates a * NS(DAD) and NA messages containing an EARO that indicates a
registration for the same Registered Node that is not as fresh as registration for the same Registered Node that is not as fresh as
this binding MUST be answered with an NA message containing an this binding MUST be answered with an NA message containing an
EARO with a status of 3 (Moved). EARO with a status of 3 (Moved).
o Other NS(DAD) and NA messages from the Backbone are ignored. * Other NS(DAD) and NA messages from the Backbone are ignored.
o NS(Lookup) and NS(NUD) messages SHOULD be answered with an NA * NS(Lookup) and NS(NUD) messages SHOULD be answered with an NA
message containing an EARO with a status of 0 and the Override message containing an EARO with a status of 0 and the Override
flag not set. The 6BBR MAY check whether the Registering Node is flag not set. The 6BBR MAY check whether the Registering Node is
still available using a NUD procedure over the LLN prior to still available using a NUD procedure over the LLN prior to
answering; this behaviour depends on the use case and is subject answering; this behaviour depends on the use case and is subject
to configuration. to configuration.
When the Registration Lifetime timer elapses, the Binding is placed When the Registration Lifetime timer elapses, the Binding is placed
in Stale state for a duration of STALE_DURATION (Section 12). in Stale state for a duration of STALE_DURATION (Section 12).
9.3. Operations on a Binding in Stale State 9.3. Operations on a Binding in Stale State
The Stale state enables tracking of the Backbone peers that have a The Stale state enables tracking of the Backbone peers that have a
NCE pointing to this 6BBR in case the Registered Address shows up NCE pointing to this 6BBR in case the Registered Address shows up
later. later.
If the Registered Address is claimed by another 6LN on the Backbone, If the Registered Address is claimed by another 6LN on the Backbone,
with an NS(DAD) or an NA, the 6BBR does not defend the Address. with an NS(DAD) or an NA, the 6BBR does not defend the Address.
For a Binding in Stale state: For a Binding in Stale state:
o The Binding MUST be removed if an NA or an NS(DAD) message is * The Binding MUST be removed if an NA or an NS(DAD) message is
received over the Backbone for the Registered Address containing received over the Backbone for the Registered Address containing
no EARO or an EARO that indicates either a fresher registration no EARO or an EARO that indicates either a fresher registration
for the same Registered Node or a duplicate registration. A for the same Registered Node or a duplicate registration. A
status of 4 (Removed) MAY be returned in an asynchronous NA(EARO) status of 4 (Removed) MAY be returned in an asynchronous NA(EARO)
to the Registering Node. to the Registering Node.
o NS(DAD) and NA messages containing an EARO that indicates a * NS(DAD) and NA messages containing an EARO that indicates a
registration for the same Registered Node that is not as fresh as registration for the same Registered Node that is not as fresh as
this MUST be answered with an NA message containing an EARO with a this MUST be answered with an NA message containing an EARO with a
status of 3 (Moved). status of 3 (Moved).
o If the 6BBR receives an NS(Lookup) or an NS(NUD) message for the * If the 6BBR receives an NS(Lookup) or an NS(NUD) message for the
Registered Address, the 6BBR MUST attempt a NUD procedure as Registered Address, the 6BBR MUST attempt a NUD procedure as
specified in [RFC7048] to the Registering Node, targeting specified in [RFC7048] to the Registering Node, targeting the
Registered Address, prior to answering. If the NUD procedure
o the Registered Address, prior to answering. If the NUD procedure
succeeds, the operation in Reachable state applies. If the NUD succeeds, the operation in Reachable state applies. If the NUD
fails, the 6BBR refrains from answering. fails, the 6BBR refrains from answering.
o Other NS(DAD) and NA messages from the Backbone are ignored. * Other NS(DAD) and NA messages from the Backbone are ignored.
When the STALE_DURATION (Section 12) timer elapses, the Binding MUST When the STALE_DURATION (Section 12) timer elapses, the Binding MUST
be removed. be removed.
10. Registering Node Considerations 10. Registering Node Considerations
A Registering Node MUST implement [RFC8505] in order to interact with A Registering Node MUST implement [RFC8505] in order to interact with
a 6BBR (which acts as a routing registrar). Following [RFC8505], the a 6BBR (which acts as a routing registrar). Following [RFC8505], the
Registering Node signals that it requires IPv6 proxy-ND services from Registering Node signals that it requires IPv6 proxy-ND services from
a 6BBR by registering the corresponding IPv6 Address using an a 6BBR by registering the corresponding IPv6 Address using an
skipping to change at page 26, line 34 skipping to change at page 25, line 40
for Detecting Network Attachment in IPv6 [RFC6059] (DNA procedures) for Detecting Network Attachment in IPv6 [RFC6059] (DNA procedures)
to detect movements, and support Packet-Loss Resiliency for Router to detect movements, and support Packet-Loss Resiliency for Router
Solicitations [RFC7559] in order to improve reliability for the Solicitations [RFC7559] in order to improve reliability for the
unicast RS messages. unicast RS messages.
11. Security Considerations 11. Security Considerations
This specification applies to LLNs and a backbone in which the This specification applies to LLNs and a backbone in which the
individual links are protected against rogue access, e.g., by individual links are protected against rogue access, e.g., by
authenticating a node that attaches to the network and encrypting at authenticating a node that attaches to the network and encrypting at
the MAC layer the transmissions that may be overheard. the MAC layer the transmissions that may be overheard. In
particular, the LLN MAC is required to provide secure unicast to/from
In particular, the LLN MAC is required to provide secure unicast to/ the Backbone Router and secure Broadcast from the Backbone Router in
from the Backbone Router and secure Broadcast from the Backbone a way that prevents tampering with or replaying the RA messages.
Router in a way that prevents tampering with or replaying the RA
messages.
[I-D.ietf-6lo-ap-nd] guarantees the ownership of a registered address [I-D.ietf-6lo-ap-nd] guarantees the ownership of a registered address
based on a proof-of-ownership encoded in the ROVR field and protects based on a proof-of-ownership encoded in the ROVR field and protects
against address theft and impersonation inside the LLN, because the against address theft and impersonation inside the LLN, because the
6LR can challenge the Registered Node for a proof-of-ownership. This 6LR can challenge the Registered Node for a proof-of-ownership. This
method does not extend over the backbone since the 6BBR cannot method does not extend over the backbone since the 6BBR cannot
provide the proof-of-ownership. A possible attack over the backbone provide the proof-of-ownership. A possible attack over the backbone
can be done by sending an NS with an EARO and expecting the NA(EARO) can be done by sending an NS with an EARO and expecting the NA(EARO)
back to contain the TID and ROVR fields of the existing state. With back to contain the TID and ROVR fields of the existing state. With
that information, the attacker can easily increase the TID and take that information, the attacker can easily increase the TID and take
over the Binding. over the Binding.
12. Protocol Constants 12. Protocol Constants
This Specification uses the following constants: This Specification uses the following constants:
TENTATIVE_DURATION: 800 milliseconds TENTATIVE_DURATION: 800 milliseconds
STALE_DURATION: see below STALE_DURATION: see below
In LLNs with long-lived Addresses such as LPWANs, STALE_DURATION In LLNs with long-lived Addresses such as LPWANs, STALE_DURATION
SHOULD be configured with a relatively long value to cover an SHOULD be configured with a relatively long value to cover an
interval when the address may be reused, and before it is safe to interval when the address may be reused, and before it is safe to
expect that the address was definitively released. A good default expect that the address was definitively released. A good default
value can be 24 hours. In LLNs where addresses are renewed rapidly, value can be 24 hours. In LLNs where addresses are renewed rapidly,
e.g., for privacy reasons, STALE_DURATION SHOULD be configured with a e.g., for privacy reasons, STALE_DURATION SHOULD be configured with a
relatively shorter value, by default 5 minutes. relatively shorter value, by default 5 minutes.
13. IANA Considerations 13. IANA Considerations
This document has no request to IANA. This document has no request to IANA.
14. Acknowledgments 14. Acknowledgments
Many thanks to Dorothy Stanley, Thomas Watteyne and Jerome Henry for Many thanks to Dorothy Stanley, Thomas Watteyne and Jerome Henry for
their various contributions. Also many thanks to Timothy Winters and their various contributions. Also many thanks to Timothy Winters and
Erik Nordmark for their help, review and support in preparation to Erik Nordmark for their help, review and support in preparation to
the IESG cycle, and to Kyle Rose, Elwyn Davies and Dominique Barthel the IESG cycle, and to Kyle Rose, Elwyn Davies and Dominique Barthel
for their useful contributions during the IESG review process. for their useful contributions through the IETF last call and IESG
process.
15. References
15.1. Normative References 15. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>. 2006, <https://www.rfc-editor.org/info/rfc4291>.
skipping to change at page 29, line 11 skipping to change at page 28, line 11
"Path MTU Discovery for IP version 6", STD 87, RFC 8201, "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>. <https://www.rfc-editor.org/info/rfc8201>.
[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
Perkins, "Registration Extensions for IPv6 over Low-Power Perkins, "Registration Extensions for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Neighbor Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
15.2. Informative References 16. Informative References
[I-D.bi-savi-wlan] [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
WLAN", draft-bi-savi-wlan-18 (work in progress), November 2006, <https://www.rfc-editor.org/info/rfc4389>.
2019.
[I-D.ietf-6lo-ap-nd] [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, DOI 10.17487/RFC4903, June 2007,
"Address Protected Neighbor Discovery for Low-power and <https://www.rfc-editor.org/info/rfc4903>.
Lossy Networks", draft-ietf-6lo-ap-nd-13 (work in
progress), January 2020. [RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Ed., "Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification", RFC 5415,
DOI 10.17487/RFC5415, March 2009,
<https://www.rfc-editor.org/info/rfc5415>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
[RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss
Resiliency for Router Solicitations", RFC 7559,
DOI 10.17487/RFC7559, May 2015,
<https://www.rfc-editor.org/info/rfc7559>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016,
<https://www.rfc-editor.org/info/rfc7772>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>.
[I-D.yourtchenko-6man-dad-issues]
Yourtchenko, A. and E. Nordmark, "A survey of issues
related to IPv6 Duplicate Address Detection", Work in
Progress, Internet-Draft, draft-yourtchenko-6man-dad-
issues-01, 3 March 2015, <https://tools.ietf.org/html/
draft-yourtchenko-6man-dad-issues-01>.
[I-D.nordmark-6man-dad-approaches]
Nordmark, E., "Possible approaches to make DAD more robust
and/or efficient", Work in Progress, Internet-Draft,
draft-nordmark-6man-dad-approaches-02, 19 October 2015,
<https://tools.ietf.org/html/draft-nordmark-6man-dad-
approaches-02>.
[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", Work in
6man-rs-refresh-02 (work in progress), October 2016. Progress, Internet-Draft, draft-ietf-6man-rs-refresh-02,
31 October 2016, <https://tools.ietf.org/html/draft-ietf-
6man-rs-refresh-02>.
[I-D.ietf-6lo-ap-nd]
Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and
Lossy Networks", Work in Progress, Internet-Draft, draft-
ietf-6lo-ap-nd-13, 6 January 2020,
<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-13>.
[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-28 (work of IEEE 802.15.4", Work in Progress, Internet-Draft,
in progress), October 2019. draft-ietf-6tisch-architecture-28, 29 October 2019,
<https://tools.ietf.org/html/draft-ietf-6tisch-
architecture-28>.
[I-D.ietf-mboned-ieee802-mcast-problems] [I-D.ietf-mboned-ieee802-mcast-problems]
Perkins, C., McBride, M., Stanley, D., Kumari, W., and J. Perkins, C., McBride, M., Stanley, D., Kumari, W., and J.
Zuniga, "Multicast Considerations over IEEE 802 Wireless Zuniga, "Multicast Considerations over IEEE 802 Wireless
Media", draft-ietf-mboned-ieee802-mcast-problems-11 (work Media", Work in Progress, Internet-Draft, draft-ietf-
in progress), December 2019. mboned-ieee802-mcast-problems-11, 11 December 2019,
<https://tools.ietf.org/html/draft-ietf-mboned-ieee802-
mcast-problems-11>.
[I-D.nordmark-6man-dad-approaches] [I-D.bi-savi-wlan]
Nordmark, E., "Possible approaches to make DAD more robust Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for
and/or efficient", draft-nordmark-6man-dad-approaches-02 WLAN", Work in Progress, Internet-Draft, draft-bi-savi-
(work in progress), October 2015. wlan-18, 17 November 2019,
<https://tools.ietf.org/html/draft-bi-savi-wlan-18>.
[I-D.thubert-6lo-unicast-lookup] [I-D.thubert-6lo-unicast-lookup]
Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery
Unicast Lookup", draft-thubert-6lo-unicast-lookup-00 (work Unicast Lookup", Work in Progress, Internet-Draft, draft-
in progress), January 2019. thubert-6lo-unicast-lookup-00, 25 January 2019,
<https://tools.ietf.org/html/draft-thubert-6lo-unicast-
[I-D.yourtchenko-6man-dad-issues] lookup-00>.
Yourtchenko, A. and E. Nordmark, "A survey of issues
related to IPv6 Duplicate Address Detection", draft-
yourtchenko-6man-dad-issues-01 (work in progress), March
2015.
[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 30, line 40 skipping to change at page 30, line 47
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)".
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April
2006, <https://www.rfc-editor.org/info/rfc4389>.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
DOI 10.17487/RFC4903, June 2007,
<https://www.rfc-editor.org/info/rfc4903>.
[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
Ed., "Control And Provisioning of Wireless Access Points
(CAPWAP) Protocol Specification", RFC 5415,
DOI 10.17487/RFC5415, March 2009,
<https://www.rfc-editor.org/info/rfc5415>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
Statement and Requirements for IPv6 over Low-Power
Wireless Personal Area Network (6LoWPAN) Routing",
RFC 6606, DOI 10.17487/RFC6606, May 2012,
<https://www.rfc-editor.org/info/rfc6606>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.
[RFC7559] Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss
Resiliency for Router Solicitations", RFC 7559,
DOI 10.17487/RFC7559, May 2015,
<https://www.rfc-editor.org/info/rfc7559>.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy
Consumption of Router Advertisements", BCP 202, RFC 7772,
DOI 10.17487/RFC7772, February 2016,
<https://www.rfc-editor.org/info/rfc7772>.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
<https://www.rfc-editor.org/info/rfc8273>.
Appendix A. Possible Future Extensions Appendix A. Possible Future Extensions
With the current specification, the 6LBR is not leveraged to avoid With the current specification, the 6LBR is not leveraged to avoid
multicast NS(Lookup) on the Backbone. This could be done by adding a multicast NS(Lookup) on the Backbone. This could be done by adding a
lookup procedure in the EDAR/EDAC exchange. lookup procedure in the EDAR/EDAC exchange.
By default the specification does not have a trust model, e.g., By default the specification does not have a trust model, e.g.,
whereby nodes that associate their address with a proof-of-ownership whereby nodes that associate their address with a proof-of-ownership
[I-D.ietf-6lo-ap-nd] should be more trusted than nodes that do not. [I-D.ietf-6lo-ap-nd] should be more trusted than nodes that do not.
Such a trust model and related signaling could be added in the future Such a trust model and related signaling could be added in the future
skipping to change at page 32, line 51 skipping to change at page 32, line 16
"Requirements Related to Scalability", as long has the 6BBRs are "Requirements Related to Scalability", as long has the 6BBRs are
dimensioned for the number of registrations that each needs to dimensioned for the number of registrations that each needs to
support. support.
In the case of a Wi-Fi access link, a 6BBR may be collocated with the In the case of a Wi-Fi access link, a 6BBR may be collocated with the
Access Point (AP), or with a Fabric Edge (FE) or a CAPWAP [RFC5415] Access Point (AP), or with a Fabric Edge (FE) or a CAPWAP [RFC5415]
Wireless LAN Controller (WLC). In those cases, the wireless client Wireless LAN Controller (WLC). In those cases, the wireless client
(STA) is the 6LN that makes use of [RFC8505] to register its IPv6 (STA) is the 6LN that makes use of [RFC8505] to register its IPv6
Address(es) to the 6BBR acting as Routing Registrar. The 6LBR can be Address(es) to the 6BBR acting as Routing Registrar. The 6LBR can be
centralized and either connected to the Backbone Link or reachable centralized and either connected to the Backbone Link or reachable
over IP. over IP. The 6BBR proxy-ND operations eliminate the need for
wireless nodes to respond synchronously when a Lookup is performed
The 6BBR proxy-ND operations eliminate the need for wireless nodes to for their IPv6 Addresses. This provides the function of a Sleep
respond synchronously when a Lookup is performed for their IPv6 Proxy for ND [I-D.nordmark-6man-dad-approaches].
Addresses. This provides the function of a Sleep Proxy for ND
[I-D.nordmark-6man-dad-approaches].
For the TimeSlotted Channel Hopping (TSCH) mode of [IEEEstd802154], For the TimeSlotted Channel Hopping (TSCH) mode of [IEEEstd802154],
the 6TiSCH architecture [I-D.ietf-6tisch-architecture] describes how the 6TiSCH architecture [I-D.ietf-6tisch-architecture] describes how
a 6LoWPAN ND host could connect to the Internet via a RPL mesh a 6LoWPAN ND host could connect to the Internet via a RPL mesh
Network, but doing so requires extensions to the 6LOWPAN ND protocol Network, but doing so requires extensions to the 6LOWPAN ND protocol
to support mobility and reachability in a secure and manageable to support mobility and reachability in a secure and manageable
environment. The extensions detailed in this document also work for environment. The extensions detailed in this document also work for
the 6TiSCH architecture, serving the requirements listed in the 6TiSCH architecture, serving the requirements listed in
Appendix B.2 of [RFC8505] "Requirements Related to Routing Appendix B.2 of [RFC8505] "Requirements Related to Routing
Protocols". Protocols".
skipping to change at page 33, line 43 skipping to change at page 33, line 6
can connect to the Backbone using IPv6 ND operations, multicast RAs can connect to the Backbone using IPv6 ND operations, multicast RAs
can be saved by using [I-D.ietf-6man-rs-refresh], which also requires can be saved by using [I-D.ietf-6man-rs-refresh], which also requires
the support of [RFC7559]. the support of [RFC7559].
Authors' Addresses 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 06254 MOUGINS - Sophia Antipolis
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 Blue Meadow Networking
2330 Central Expressway Saratoga, 95070
Santa Clara 95050
United States of America United States of America
Email: charliep@computer.org Email: charliep@computer.org
Eric Levy-Abegnoli Eric Levy-Abegnoli
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254 06254 MOUGINS - Sophia Antipolis
FRANCE France
Phone: +33 497 23 26 20 Phone: +33 497 23 26 20
Email: elevyabe@cisco.com Email: elevyabe@cisco.com
 End of changes. 100 change blocks. 
309 lines changed or deleted 270 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/