draft-ietf-6lo-backbone-router-16.txt   draft-ietf-6lo-backbone-router-17.txt 
6lo P.T. Thubert, Ed. 6lo P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6775, 8505 (if approved) C.E. Perkins Updates: 6775, 8505 (if approved) C.E. Perkins
Intended status: Standards Track Blue Meadow Networking Intended status: Standards Track Blue Meadow Networking
Expires: 11 August 2020 E.L.A. Levy-Abegnoli Expires: 23 August 2020 E. Levy-Abegnoli
Cisco Systems Cisco Systems
8 February 2020 20 February 2020
IPv6 Backbone Router IPv6 Backbone Router
draft-ietf-6lo-backbone-router-16 draft-ietf-6lo-backbone-router-17
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 11 August 2020. This Internet-Draft will expire on 23 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 14 skipping to change at page 2, line 14
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Updating RFC 6775 and RFC 8505 . . . . . . . . . . . . . 10 3.1. Updating RFC 6775 and RFC 8505 . . . . . . . . . . . . . 10
3.2. Access Link . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Access Link . . . . . . . . . . . . . . . . . . . . . . . 10
3.3. Route-Over Mesh . . . . . . . . . . . . . . . . . . . . . 12 3.3. Route-Over Mesh . . . . . . . . . . . . . . . . . . . . . 12
3.4. The Binding Table . . . . . . . . . . . . . . . . . . . . 14 3.4. The Binding Table . . . . . . . . . . . . . . . . . . . . 13
3.5. Primary and Secondary 6BBRs . . . . . . . . . . . . . . . 15 3.5. Primary and Secondary 6BBRs . . . . . . . . . . . . . . . 14
3.6. Using Optimistic DAD . . . . . . . . . . . . . . . . . . 16 3.6. Using Optimistic DAD . . . . . . . . . . . . . . . . . . 15
4. Multi-Link Subnet Considerations . . . . . . . . . . . . . . 16 4. Multi-Link Subnet Considerations . . . . . . . . . . . . . . 15
5. Optional 6LBR serving the Multi-Link Subnet . . . . . . . . . 17 5. Optional 6LBR serving the Multi-Link Subnet . . . . . . . . . 16
6. Using IPv6 ND Over the Backbone Link . . . . . . . . . . . . 18 6. Using IPv6 ND Over the Backbone Link . . . . . . . . . . . . 17
7. Routing Proxy Operations . . . . . . . . . . . . . . . . . . 18 7. Routing Proxy Operations . . . . . . . . . . . . . . . . . . 18
8. Bridging Proxy Operations . . . . . . . . . . . . . . . . . . 19 8. Bridging Proxy Operations . . . . . . . . . . . . . . . . . . 20
9. Creating and Maintaining a Binding . . . . . . . . . . . . . 20 9. Creating and Maintaining a Binding . . . . . . . . . . . . . 21
9.1. Operations on a Binding in Tentative State . . . . . . . 22 9.1. Operations on a Binding in Tentative State . . . . . . . 22
9.2. Operations on a Binding in Reachable State . . . . . . . 23 9.2. Operations on a Binding in Reachable State . . . . . . . 23
9.3. Operations on a Binding in Stale State . . . . . . . . . 24 9.3. Operations on a Binding in Stale State . . . . . . . . . 24
10. Registering Node Considerations . . . . . . . . . . . . . . . 25 10. Registering Node Considerations . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 26 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 26
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
15. Normative References . . . . . . . . . . . . . . . . . . . . 26 15. Normative References . . . . . . . . . . . . . . . . . . . . 27
16. Informative References . . . . . . . . . . . . . . . . . . . 28 16. Informative References . . . . . . . . . . . . . . . . . . . 28
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 . . . . . . . 31
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.
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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.
Additional benefits are discussed in Appendix B.
2. Terminology 2. Terminology
2.1. BCP 14 2.1. BCP 14
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: A subnet that comprises a Backbone and one or more Federated: A subnet that comprises a Backbone and one or more
(wireless) access links, is said to be federated into one Multi- (wireless) access links, is said to be federated into one Multi-
Link Subnet. The proxy-ND operation of 6BBRs over the Backbone Link Subnet. The proxy-ND operation of 6BBRs over the Backbone
and the access links provides the appearance of a subnet for IPv6 extends IPv6 ND operation over the access links.
ND.
Sleeping Proxy: A 6BBR acts as a Sleeping Proxy if it answers ND Sleeping Proxy: A 6BBR acts as a Sleeping Proxy if it answers ND
Neighbor Solicitations over the Backbone on behalf of the Neighbor Solicitations over the Backbone on behalf of the
Registering Node which might be in a sleep state in a low power Registering Node which might be in a sleep state in a low power
network. The Sleeping Proxy that is also a Bridging Proxy will network. The Sleeping Proxy that is also a Bridging Proxy will
preferably forward the relevant messages to the Registering Node preferably forward the relevant messages to the Registering Node
as unicast frames in accord to the duty cycle of the Registering as unicast frames in accord to the duty cycle of the Registering
Node and let it respond. Node and let it respond.
Routing Proxy: A Routing Proxy provides IPv6 ND proxy functions and Routing Proxy: A Routing Proxy provides IPv6 ND proxy functions and
skipping to change at page 11, line 26 skipping to change at page 11, line 10
+------+ +------+ +------+ +------+ +------+ +------+
(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
whole subnet, and EDAR / EDAC messages are used in combination with
DAD to enable coexistence with IPv6 ND over the backbone.
The RS sent initially by the 6LN(STA) is transmitted as a multicast
but since it is intercepted by the 6BBR, it is never effectively
broadcast. The multiple arrows associated to the ND messages on the
Backbone denote a real Layer 2 broadcast.
6LN(STA) 6BBR(AP) 6LBR default GW 6LN(STA) 6BBR(AP) 6LBR default GW
| | | | | | | |
| LLN Access Link | IPv6 Backbone (e.g., Ethernet) | | LLN Access Link | IPv6 Backbone (e.g., Ethernet) |
| | | | | | | |
| RS(multicast) | | | | RS(multicast) | | |
|---------------->| | | |---------------->| | |
| RA(PIO, Unicast)| | | | RA(PIO, Unicast)| | |
|<----------------| | | |<----------------| | |
| NS(EARO) | | | | NS(EARO) | | |
|---------------->| | | |---------------->| | |
skipping to change at page 12, line 44 skipping to change at page 11, line 49
| IPv6 Packets in optimistic mode | | IPv6 Packets in optimistic mode |
|<---------------------------------------------------->| |<---------------------------------------------------->|
| | | | | |
| | | |
| NA(EARO) |<DAD timeout> | NA(EARO) |<DAD timeout>
|<----------------| |<----------------|
| | | |
Figure 3: Initial Registration Flow to a 6BBR acting as Routing Proxy Figure 3: Initial Registration Flow to a 6BBR acting as Routing Proxy
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
DAD to enable coexistence with IPv6 ND over the backbone.
The RS sent initially by the 6LN(STA) is transmitted as a multicast
but since it is intercepted by the 6BBR, it is never effectively
broadcast. The multiple arrows associated to the ND messages on the
Backbone denote a real Layer 2 broadcast.
3.3. Route-Over Mesh 3.3. Route-Over Mesh
A more complex Multi-Link Subnet topology occurs when the wireless A more complex Multi-Link Subnet topology occurs when the wireless
network appears as a Layer 3 Mesh network as shown in Figure 4. A network appears as a Layer 3 Mesh network as shown in Figure 4. A
so-called Route-Over routing protocol exposes routes between 6LRs so-called Route-Over routing protocol exposes routes between 6LRs
towards both 6LRs and 6LNs, and a 6LBR acts as Root of the Layer 3 towards both 6LRs and 6LNs, and a 6LBR acts as Root of the Layer 3
Mesh network and proxy-registers the LLN addresses to the 6BBR. Mesh network and proxy-registers the LLN addresses to the 6BBR.
| |
+-----+ +-----+ +-----+ IPv6 +-----+ +-----+ +-----+ IPv6
skipping to change at page 16, line 38 skipping to change at page 15, line 38
connectivity to the registered node. As shown in Figure 3, if the connectivity to the registered node. As shown in Figure 3, if the
6BBR is aware of the Link-Layer Address (LLA) of a router, then the 6BBR is aware of the Link-Layer Address (LLA) of a router, then the
6BBR sends a Router Solicitation (RS), using the Registered Address 6BBR sends a Router Solicitation (RS), using the Registered Address
as the IP Source Address, to the known router(s). The RS is sent as the IP Source Address, to the known router(s). The RS is sent
without a Source LLA Option (SLLAO), to avoid invalidating a without a Source LLA Option (SLLAO), to avoid invalidating a
preexisting NCE in the router. preexisting NCE in the router.
Following ODAD, the router may then send a unicast RA to the Following ODAD, the router may then send a unicast RA to the
Registered Address, and it may resolve that Address using an Registered Address, and it may resolve that Address using an
NS(Lookup) message. In response, the 6BBR sends an NA with an EARO NS(Lookup) message. In response, the 6BBR sends an NA with an EARO
and the Override (O) flag [RFC4861] that is not set. The router can and the Override flag [RFC4861] that is not set. The router can then
then determine the freshest EARO in case of conflicting NA(EARO) determine the freshest EARO in case of conflicting NA(EARO) messages,
messages, using the method described in section 5.2.1 of [RFC8505]. using the method described in section 5.2.1 of [RFC8505]. If the
If the NA(EARO) is the freshest answer, the default router creates a NA(EARO) is the freshest answer, the default router creates a Binding
Binding with the SLLAO of the 6BBR (in Routing Proxy mode) or that of with the SLLAO of the 6BBR (in Routing Proxy mode) or that of the
the Registering Node (in Bridging Proxy mode) so that traffic from/to Registering Node (in Bridging Proxy mode) so that traffic from/to the
the Registered Address can flow immediately. Registered Address can flow immediately.
4. Multi-Link Subnet Considerations 4. Multi-Link Subnet Considerations
The Backbone and the federated LLN Links are considered as different The Backbone and the federated LLN Links are considered as different
links in the Multi-Link Subnet, even if multiple LLNs are attached to links in the Multi-Link Subnet, even if multiple LLNs are attached to
the same 6BBR. ND messages are link-scoped and are not forwarded by the same 6BBR. ND messages are link-scoped and are not forwarded by
the 6BBR between the backbone and the LLNs though some packets may be the 6BBR between the backbone and the LLNs though some packets may be
reinjected in Bridging Proxy mode (see Section 8). reinjected in Bridging Proxy mode (see Section 8).
Nodes located inside the subnet do not perform the IPv6 Path MTU Nodes located inside the subnet do not perform the IPv6 Path MTU
skipping to change at page 18, line 10 skipping to change at page 17, line 10
Note that if Link Local addresses are registered, then the scope of Note that if Link Local addresses are registered, then the scope of
uniqueness on which the address duplication is checked is the total uniqueness on which the address duplication is checked is the total
collection of links that the 6LBR serves as opposed to the sole link collection of links that the 6LBR serves as opposed to the sole link
on which the Link Local address is assigned. on which the Link Local address is assigned.
6. Using IPv6 ND Over the Backbone Link 6. Using IPv6 ND Over the Backbone Link
On the Backbone side, the 6BBR MUST join the SNMA group corresponding On the Backbone side, the 6BBR MUST join the SNMA group corresponding
to a Registered Address as soon as it creates a Binding for that to a Registered Address as soon as it creates a Binding for that
Address, and maintain that SNMA membership as long as it maintains Address, and maintain that SNMA membership as long as it maintains
the registration. the registration. The 6BBR uses either the SNMA or plain unicast to
defend the Registered Addresses in its Binding Table over the
The 6BBR uses either the SNMA or plain unicast to defend the Backbone (as specified in [RFC4862]). The 6BBR advertises and
Registered Addresses in its Binding Table over the Backbone (as defends the Registered Addresses over the Backbone Link using RS,
specified in [RFC4862]). NS(DAD) and NA messages with the Registered Address as the Source or
Target address, respectively.
The 6BBR advertises and defends the Registered Addresses over the
Backbone Link using RS, NS(DAD) and NA messages with the Registered
Address as the Source or Target address, respectively.
The 6BBR MUST place an EARO in the IPv6 ND messages that it generates The 6BBR MUST place an EARO in the IPv6 ND messages that it generates
on behalf of the Registered Node. Note that an NS(DAD) does not on behalf of the Registered Node. Note that an NS(DAD) does not
contain an SLLAO and cannot be confused with a proxy registration contain an SLLAO and cannot be confused with a proxy registration
such as performed by a 6LBR. such as performed by a 6LBR.
An NA message generated in response to an NS(DAD) MUST have the IPv6 ND operates as follows on the backbone:
Override flag set and a status of 1 (Duplicate) or 3 (Moved) in the
EARO. An NA message generated in response to an NS(Lookup) or an * Section 7.2.8 of [RFC4861] specifies that an NA message generated
NS(NUD) MUST NOT have the Override flag set. as a proxy does not have the Override flag set in order to ensure
that if the real owner is present on the link, its own NA will
take precedence, and that this NA does not update the NCE for the
real owner if one exists.
* A node that receives multiple NA messages updates an existing NCE
only if the Override flag is set; otherwise the node will probe
the cached address.
* When an NS(DAD) is received for a tentative address, which means
that 2 nodes form the same address at nearly the same time,
section 5.4.3 of [RFC4862] cannot sort out the first come and the
address is abandoned.
* In any fashion, [RFC4862] indicates that a node never responds to
a Neighbor Solicitation for a tentative address.
This specification adds information about proxied addresses that
helps sort out a duplication (different ROVR) from a movement (same
ROVR, different TID), and in the latter case the older registration
from the fresher one (by comparing TIDs).
When a Registering Node moves from one 6BBR to the next, the new 6BBR
sends NA messages to update the NCE in node over the backbone. The
6BBR may set the Override flag in the NA messages if it is known that
the Registering Node will not connect directly to the backbone (e.g.,
the Registering Node is attached using a different type of
interface).
A node that supports this specification and that receives multiple NA
messages with an EARO option and the same ROVR MUST favor the NA with
the freshest EARO over the others.
When the Binding is in Tentative state:
* an NS(DAD) that indicates a duplication can still not be asserted
for first come, but the situation can be avoided using a 6LBR on
the backbone that will serialize the order of appearance of the
address and ensure first-come/first-serve.
* an NS or an NA that denotes an older registration for the same
Registered Node is not interpreted as a duplication as specified
in section 5.4.3 and 5.4.4 of [RFC4862], respectively.
When the Binding is no more in Tentative state:
* an NS or an NA with an EARO that denotes a duplicate registration
(different ROVR) is answered with an NA message that carries an
EARO with a status of 1 (Duplicate), unless the received message
is an NA that carries an EARO with a status of 1.
In any state:
* an NS or an NA with an EARO that denotes an older registration
(same ROVR) is answered with an NA message that carries an EARO
with a status of 3 (Moved) to ensure that the stale state is
removed rapidly.
This behavior is specified in more details in Section 9.
This specification enables proxy operation for the IPv6 ND resolution This specification enables proxy operation for the IPv6 ND resolution
of LLN devices and a prefix that is used across a Multi-Link Subnet of LLN devices and a prefix that is used across a Multi-Link Subnet
MAY be advertised as on-link over the Backbone. This is done for MAY be advertised as on-link over the Backbone. This is done for
backward compatibility with existing IPv6 hosts by setting the L flag backward compatibility with existing IPv6 hosts by setting the L flag
in the Prefix Information Option (PIO) of RA messages [RFC4861]. in the Prefix Information Option (PIO) of RA messages [RFC4861].
For movement involving a slow reattachment, the NUD procedure defined For movement involving a slow reattachment, the NUD procedure defined
in [RFC4861] may time out too quickly. Nodes on the backbone SHOULD in [RFC4861] may time out too quickly. Nodes on the backbone SHOULD
support [RFC7048] whenever possible. support [RFC7048] whenever possible.
skipping to change at page 19, line 25 skipping to change at page 19, line 31
When operating as a Routing Proxy, the 6BBR MUST use its Layer 2 When operating as a Routing Proxy, the 6BBR MUST use its Layer 2
Address on its Backbone Interface in the SLLAO of the RS messages and Address on its Backbone Interface in the SLLAO of the RS messages and
the TLLAO of the NA messages that it generates to advertise the the TLLAO of the NA messages that it generates to advertise the
Registered Addresses. Registered Addresses.
For each Registered Address, multiple peers on the Backbone may have For each Registered Address, multiple peers on the Backbone may have
resolved the Address with the 6BBR MAC Address, maintaining that resolved the Address with the 6BBR MAC Address, maintaining that
mapping in their Neighbor Cache. The 6BBR SHOULD maintain a list of mapping in their Neighbor Cache. 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 new the Registered Address. If that Registered Address moves to another
6BBR, the previous 6BBR SHOULD unicast a gratuitous NA with the 6BBR, the previous 6BBR SHOULD unicast a gratuitous NA to each such
Override flag set to each such peer, to supply the LLA of the new peer, to supply the LLA of the new 6BBR in the TLLA option for the
6BBR in the TLLA option for the Address. A 6BBR that does not Address. A 6BBR that does not maintain this list MAY multicast a
maintain this list MAY multicast a gratuitous NA with the Override gratuitous NA message; this NA will possibly hit all the nodes on the
flag; this NA will possibly hit all the nodes on the Backbone, Backbone, whether or not they maintain an NCE for the Registered
whether or not they maintain an NCE for the Registered Address. Address. In either case, the 6BBR MAY set the Override flag if it is
known that the Registered Node cannot attach to the backbone, so as
to avoid interruptions and save probing flows in the future.
If a correspondent fails to receive the gratuitous NA, it will keep If a correspondent fails to receive the gratuitous NA, it will keep
sending traffic to a 6BBR to which the node was previously sending traffic to a 6BBR to which the node was previously
registered. Since the previous 6BBR removed its Host route to the registered. Since the previous 6BBR removed its Host route to the
Registered Address, it will look up the address over the backbone, Registered Address, it will look up the address over the backbone,
resolve the address with the LLA of the new 6BBR, and forward the resolve the address with the LLA of the new 6BBR, and forward the
packet to the correct 6BBR. The previous 6BBR SHOULD also issue a packet to the correct 6BBR. The previous 6BBR SHOULD also issue a
redirect message [RFC4861] to update the cache of the correspondent. redirect message [RFC4861] to update the cache of the correspondent.
8. Bridging Proxy Operations 8. Bridging Proxy Operations
skipping to change at page 20, line 24 skipping to change at page 20, line 35
The Registering Node's Layer 2 address is found in the SLLA of the The Registering Node's Layer 2 address is found in the SLLA of the
registration NS(EARO), and maintained in the Binding Table. registration NS(EARO), and maintained in the Binding Table.
The Multi-Link Subnet prefix SHOULD NOT be advertised as on-link in The Multi-Link Subnet prefix SHOULD NOT be advertised as on-link in
RA messages sent towards the LLN. If a destination address is seen RA messages sent towards the LLN. If a destination address is seen
as on-link, then a 6LN may use NS(Lookup) messages to resolve that as on-link, then a 6LN may use NS(Lookup) messages to resolve that
address. In that case, the 6BBR MUST either answer the NS(Lookup) address. In that case, the 6BBR MUST either answer the NS(Lookup)
message directly or reinject the message on the backbone, either as a message directly or reinject the message on the backbone, either as a
Layer 2 unicast or a multicast. Layer 2 unicast or a multicast.
If the Registering Node owns the Registered Address, then its If the Registering Node owns the Registered Address, meaning that the
mobility does not impact existing NCEs over the Backbone. Otherwise, Registering Node is the Registered Node, then its mobility does not
when the 6LN selects another Registering Node, the new Registering impact existing NCEs over the Backbone. In a network where proxy
Node SHOULD send a multicast NA with the Override flag set to fix the registrations are used, meaning that the Registering Node acts on
existing NCEs across the Backbone. behalf of the Registered Node, if the Registered Node selects a new
Registering Node then the existing NCEs across the Backbone pointing
at the old Registering Node must be updated. In that case, the 6BBR
SHOULD attempt to fix the existing NCEs across the Backbone pointing
at other 6BBRs using NA messages as described in Section 7.
This method can fail if the multicast message is not received; one or This method can fail if the multicast message is not received; one or
more correspondent nodes on the Backbone might maintain an stale NCE, more correspondent nodes on the Backbone might maintain an stale NCE,
and packets to the Registered Address may be lost. When this and packets to the Registered Address may be lost. When this
condition happens, it is eventually discovered and resolved using NUD condition happens, it is eventually discovered and resolved using NUD
as defined in [RFC4861]. as defined in [RFC4861].
9. Creating and Maintaining a Binding 9. Creating and Maintaining a Binding
Upon receiving a registration for a new Address (i.e., an NS(EARO) Upon receiving a registration for a new Address (i.e., an NS(EARO)
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: Acting as a 6BBR, the 6LR operation is modified as follows:
* Acting as Bridging Proxy the 6LR MUST proxy ND over the backbone
for registered Link-Local addresses.
* EDAR and EDAC messages SHOULD carry a SLLAO and a TLLAO, * EDAR and EDAC messages SHOULD carry a SLLAO and a TLLAO,
respectively. respectively.
* A Bridging Proxy MAY register Link Local addresses at the 6BBR and
proxy ND for these addresses over the backbone.
* 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
skipping to change at page 22, line 5 skipping to change at page 22, line 20
If a registration is received for an existing Binding and a If a registration is received for an existing Binding and a
registration Lifetime of zero, then the Binding is removed, and the registration Lifetime of zero, then the Binding is removed, and the
6BBR returns an NA(EARO) back to the Registering Node with a status 6BBR returns an NA(EARO) back to the Registering Node with a status
of 0 (Success). An implementation of a Routing Proxy that removes a of 0 (Success). An implementation of a Routing Proxy that removes a
binding MUST remove the associated Host route pointing on the binding MUST remove the associated Host route pointing on the
registering node. It MAY preserve a temporary state in order to registering node. It MAY preserve a temporary state in order to
forward packets in flight. The state may be a NCE formed based on a forward packets in flight. The state may be a NCE formed based on a
received NA message, or a Binding in Stale state and pointing at the received NA message, or a Binding in Stale state and pointing at the
new 6BBR on the backbone. new 6BBR on the backbone.
The implementation should also use REDIRECT messages as specified in The old 6BBR SHOULD also use REDIRECT messages as specified in
[RFC4861] to update the correspondents for the Registered Address, [RFC4861] to update the correspondents for the Registered Address,
pointing the new 6BBR. pointing to 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:
* 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 that indicates an existing registration owned by a different
registration owned by a different Registering Node. In that case, Registering Node (different ROVR). An NA MUST be sent back to the
an NA MUST be sent back to the Registering Node with a status of 1 Registering Node with a status of 1 (Duplicate). This behavior
(Duplicate) in the EARO. This behavior might be overriden by might be overridden by 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]).
* The Binding MUST be removed if an NS(DAD) message is received over
the Backbone for the Registered Address with no EARO, or
containing an EARO with a different ROVR that indicates a
tentative registration by a different Registering Node. In that
case, an NA MUST be sent back to the Registering Node with a
status of 1 (Duplicate). This behavior might be overridden 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]).
* An NS(DAD) with no EARO or with an EARO that indicates a duplicate * The Binding MUST be removed if an NA or an NS(DAD) message is
registration (i.e., different ROVR) MUST be answered with an NA received over the Backbone for the Registered Address containing
message containing an EARO with a status of 1 (Duplicate) and the an EARO with a that indicates a fresher registration ([RFC8505])
Override flag not set. This behavior might be overriden by for the same Registering Node (same ROVR). A status of 3 is
policy, in particular if the registration is not trusted. returned in the NA(EARO) back to the Registering Node.
* The Binding MUST be removed if an NA message is received over the
Backbone for the Registered Address containing an EARO with a
status of 3 (Moved), or an NS(DAD) with an EARO that indicates a
fresher registration ([RFC8505]) for the same Registered Node
(i.e., same ROVR). A status of 3 is returned in the NA(EARO) back
to the Registering Node.
* NS(DAD) and NA messages containing an EARO that indicates a * The Binding MUST be kept unchanged if an NA or an NS(DAD) message
registration for the same Registered Node that is not as fresh as is received over the Backbone for the Registered Address
this SHOULD be answered with an NA message containing an EARO with containing an EARO with a that indicates an older registration
a status of 3 (Moved) in order to clean up the situation ([RFC8505]) for the same Registering Node (same ROVR). The
immediately. message SHOULD be answered with an NA that carries an EARO with a
status of 3 (Moved) and the Override flag not set. This behavior
might be overridden by policy, in particular if the registration
is not trusted.
* Other NS(DAD) and NA messages from the Backbone are ignored. * Other NS(DAD) and NA messages from the Backbone are ignored.
* 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). If optimistic DAD is Override flag not set (see Section 3.6). If optimistic DAD is
disabled, then they SHOULD be queued to be answered when the disabled, then they SHOULD be queued to be answered when the
Binding goes to Reachable state. 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 not set over
backbone (see Section 7 and Section 8). the backbone (see Section 7 and Section 8).
9.2. Operations on a Binding in Reachable State 9.2. Operations on a Binding in Reachable State
The Reachable state covers an active registration after a successful The Reachable state covers an active registration after a successful
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:
* 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 but fresher TID). A status
is returned in an asynchronous NA(EARO) to the Registering Node. of 4 (Removed) is returned in an asynchronous NA(EARO) to the
Based on configuration, an implementation may delay this operation Registering Node. Based on configuration, an implementation may
by a timer with a short setting, e.g., a few seconds to a minute, delay this operation by a timer with a short setting, e.g., a few
in order to a allow for a parallel registration to reach this seconds to a minute, in order to a allow for a parallel
node, in which case the NA might be ignored. registration to reach this node, in which case the NA might be
ignored.
* 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
message containing an EARO with a status of 1 (Duplicate) and the
Override flag not set.
* 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).
* 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
message containing an EARO with a status of 1 (Duplicate) and the
Override flag not set, unless the received message is an NA that
carries an EARO with a status of 1, in which case the node
refrains from answering.
* Other NS(DAD) and NA messages from the Backbone are ignored. * Other NS(DAD) and NA messages from the Backbone are ignored.
* 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
skipping to change at page 25, line 17 skipping to change at page 25, line 34
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
NS(EARO) message with the R flag set. NS(EARO) message with the R flag set.
The Registering Node may be the 6LN owning the IPv6 Address, or a The Registering Node may be the 6LN owning the IPv6 Address, or a
6LBR that performs the registration on its behalf in a Route-Over 6LBR that performs the registration on its behalf in a Route-Over
mesh. mesh.
The Registering Node SHOULD register all of its IPv6 Addresses to its The Registering Node MUST register all of its IPv6 Addresses to its
6LR, which is the 6BBR when they are connected at Layer 2. Failure 6LR, which is the 6BBR when they are connected at Layer 2. Failure
to register an address may result in the address being unreachable by to register an address may result in the address being unreachable by
other parties if the 6BBR cancels the NS(Lookup) over the LLN or to other parties if the 6BBR cancels the NS(Lookup) over the LLN or to
selected LLN nodes that are known to register their addresses. selected LLN nodes that are known to register their addresses.
The Registering Node MUST refrain from using multicast NS(Lookup) The Registering Node MUST refrain from using multicast NS(Lookup)
when the destination is not known as on-link, e.g., if the prefix is when the destination is not known as on-link, e.g., if the prefix is
advertised in a PIO with the L flag that is not set. In that case, advertised in a PIO with the L flag that is not set. In that case,
the Registering Node sends its packets directly to its 6LR. the Registering Node sends its packets directly to its 6LR.
skipping to change at page 29, line 34 skipping to change at page 30, line 9
Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6 Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6
Neighbor Discovery Optional RS/RA Refresh", Work in Neighbor Discovery Optional RS/RA Refresh", Work in
Progress, Internet-Draft, draft-ietf-6man-rs-refresh-02, Progress, Internet-Draft, draft-ietf-6man-rs-refresh-02,
31 October 2016, <https://tools.ietf.org/html/draft-ietf- 31 October 2016, <https://tools.ietf.org/html/draft-ietf-
6man-rs-refresh-02>. 6man-rs-refresh-02>.
[I-D.ietf-6lo-ap-nd] [I-D.ietf-6lo-ap-nd]
Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
"Address Protected Neighbor Discovery for Low-power and "Address Protected Neighbor Discovery for Low-power and
Lossy Networks", Work in Progress, Internet-Draft, draft- Lossy Networks", Work in Progress, Internet-Draft, draft-
ietf-6lo-ap-nd-13, 6 January 2020, ietf-6lo-ap-nd-19, 6 February 2020,
<https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-13>. <https://tools.ietf.org/html/draft-ietf-6lo-ap-nd-19>.
[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", Work in Progress, Internet-Draft, of IEEE 802.15.4", Work in Progress, Internet-Draft,
draft-ietf-6tisch-architecture-28, 29 October 2019, draft-ietf-6tisch-architecture-28, 29 October 2019,
<https://tools.ietf.org/html/draft-ietf-6tisch- <https://tools.ietf.org/html/draft-ietf-6tisch-
architecture-28>. 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.
 End of changes. 33 change blocks. 
107 lines changed or deleted 173 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/