draft-ietf-6lo-backbone-router-18.txt   draft-ietf-6lo-backbone-router-19.txt 
6lo P. 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: 3 September 2020 E. Levy-Abegnoli Expires: 4 September 2020 E. Levy-Abegnoli
Cisco Systems Cisco Systems
2 March 2020 3 March 2020
IPv6 Backbone Router IPv6 Backbone Router
draft-ietf-6lo-backbone-router-18 draft-ietf-6lo-backbone-router-19
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 3 September 2020. This Internet-Draft will expire on 4 September 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 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Access Link . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Route-Over Mesh . . . . . . . . . . . . . . . . . . . . . 13 3.3. Route-Over Mesh . . . . . . . . . . . . . . . . . . . . . 13
3.4. The Binding Table . . . . . . . . . . . . . . . . . . . . 14 3.4. The Binding Table . . . . . . . . . . . . . . . . . . . . 14
3.5. Primary and Secondary 6BBRs . . . . . . . . . . . . . . . 15 3.5. Primary and Secondary 6BBRs . . . . . . . . . . . . . . . 15
3.6. Using Optimistic DAD . . . . . . . . . . . . . . . . . . 16 3.6. Using Optimistic DAD . . . . . . . . . . . . . . . . . . 16
4. Multi-Link Subnet Considerations . . . . . . . . . . . . . . 16 4. Multi-Link Subnet Considerations . . . . . . . . . . . . . . 17
5. Optional 6LBR serving the Multi-Link Subnet . . . . . . . . . 17 5. Optional 6LBR serving the Multi-Link Subnet . . . . . . . . . 17
6. Using IPv6 ND Over the Backbone Link . . . . . . . . . . . . 18 6. Using IPv6 ND Over the Backbone Link . . . . . . . . . . . . 18
7. Routing Proxy Operations . . . . . . . . . . . . . . . . . . 20 7. Routing Proxy Operations . . . . . . . . . . . . . . . . . . 20
8. Bridging Proxy Operations . . . . . . . . . . . . . . . . . . 21 8. Bridging Proxy Operations . . . . . . . . . . . . . . . . . . 21
9. Creating and Maintaining a Binding . . . . . . . . . . . . . 22 9. Creating and Maintaining a Binding . . . . . . . . . . . . . 22
9.1. Operations on a Binding in Tentative State . . . . . . . 23 9.1. Operations on a Binding in Tentative State . . . . . . . 23
9.2. Operations on a Binding in Reachable State . . . . . . . 24 9.2. Operations on a Binding in Reachable State . . . . . . . 24
9.3. Operations on a Binding in Stale State . . . . . . . . . 25 9.3. Operations on a Binding in Stale State . . . . . . . . . 25
10. Registering Node Considerations . . . . . . . . . . . . . . . 26 10. Registering Node Considerations . . . . . . . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 27 12. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 29
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
15. Normative References . . . . . . . . . . . . . . . . . . . . 28 15. Normative References . . . . . . . . . . . . . . . . . . . . 30
16. Informative References . . . . . . . . . . . . . . . . . . . 29 16. Informative References . . . . . . . . . . . . . . . . . . . 31
Appendix A. Possible Future Extensions . . . . . . . . . . . . . 32 Appendix A. Possible Future Extensions . . . . . . . . . . . . . 34
Appendix B. Applicability and Requirements Served . . . . . . . 33 Appendix B. Applicability and Requirements Served . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
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 4, line 16 skipping to change at page 4, line 16
over wireless access links. This has been done by splitting the over wireless access links. This has been done by splitting the
broadcast domains and routing between subnets, at the extreme by broadcast domains and routing between subnets, at the extreme by
assigning a /64 prefix to each wireless node (see [RFC8273]). But assigning a /64 prefix to each wireless node (see [RFC8273]). But
deploying a single large subnet can still be attractive to avoid deploying a single large subnet can still be attractive to avoid
renumbering in situations that involve large numbers of devices and renumbering in situations that involve large numbers of devices and
mobility within a bounded area. mobility within a bounded area.
A way to reduce the propagation of IPv6 ND broadcast in the wireless A way to reduce the propagation of IPv6 ND broadcast in the wireless
domain while preserving a large single subnet is to form a Multi-Link domain while preserving a large single subnet is to form a Multi-Link
Subnet (MLSN). Each Link in the MLSN, including the backbone, is its Subnet (MLSN). Each Link in the MLSN, including the backbone, is its
own broadcast domain. A key property of MLSNs is that link-local own broadcast domain. A key property of MLSNs is that Link-Local
unicast traffic, link-scope multicast, and traffic with a hop limit unicast traffic, link-scope multicast, and traffic with a hop limit
of 1 will not transit to nodes in the same subnet on a different of 1 will not transit to nodes in the same subnet on a different
link, something that may produce unexpected behavior in software that link, something that may produce unexpected behavior in software that
expects a subnet to be entirely contained within a single link. expects a subnet to be entirely contained within a single link.
This specification considers a special type of MLSN with a central This specification considers a special type of MLSN with a central
backbone that federates edge (LLN) links, each Link providing its own backbone that federates edge (LLN) links, each Link providing its own
protection against rogue access and tempering or replaying packets. protection against rogue access and tempering or replaying packets.
In particular, the use of classical IPv6 ND on the backbone requires
that the all nodes are trusted and that rogue access to the backbone
is prevented at all times (see Section 11).
In that particular topology, ND proxies can be placed at the boundary In that particular topology, ND proxies can be placed at the boundary
of the edge links and the backbone to handle IPv6 ND on behalf of of the edge links and the backbone to handle IPv6 ND on behalf of
Registered Nodes and forward IPv6 packets back and forth. The ND Registered Nodes and forward IPv6 packets back and forth. The ND
proxy enables the continuity of IPv6 ND operations beyond the proxy enables the continuity of IPv6 ND operations beyond the
backbone, and enables communication using Global or Unique Local backbone, and enables communication using Global or Unique Local
Addresses between any pair of nodes in the MLSN. Addresses between any pair of nodes in the MLSN.
The 6LoWPAN Backbone Router (6BBR) is a Routing Registrar [RFC8505] The 6LoWPAN Backbone Router (6BBR) is a Routing Registrar [RFC8505]
that provides proxy-ND services. A 6BBR acting as a Bridging Proxy that provides proxy-ND services. A 6BBR acting as a Bridging Proxy
provides a proxy-ND function with Layer-2 continuity and can be provides a proxy-ND function with Layer-2 continuity and can be
skipping to change at page 15, line 46 skipping to change at page 15, line 46
(Moved); this may be rate limited to avoid undue interference; (Moved); this may be rate limited to avoid undue interference;
* 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 A Registering Node MAY register the same address 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. On the other hand, there is no provision
messages with an EARO that indicate an identical Binding in another in 6LoWPAN ND for a 6LN (acting as Registered Node) to select its
6BBR (same Registered address, same TID, same ROVR) are silently 6LBR (acting as Registering Node), so it cannot select more than one
ignored but for the purpose of selecting the primary 6BBR for that either. To allow for this, NS(DAD) and NA messages with an EARO
registration. received over the backbone that indicate an identical Binding in
another 6BBR (same Registered address, same TID, same ROVR) are
silently ignored but for the purpose of selecting the primary 6BBR
for that registration.
A 6BBR may be either primary or secondary. The primary is the 6BBR A 6BBR may be either primary or secondary. The primary is the 6BBR
that has the highest EUI-64 Address of all the 6BBRs that share a that has the highest EUI-64 Address of all the 6BBRs that share a
registration for the same Registered Address, with the same ROVR and registration for the same Registered Address, with the same ROVR and
same Transaction ID, the EUI-64 Address being considered as an same Transaction ID, the EUI-64 Address being considered as an
unsigned 64bit integer. A given 6BBR can be primary for a given unsigned 64bit integer. A given 6BBR can be primary for a given
Address and secondary for another Address, regardless of whether or Address and secondary for another Address, regardless of whether or
not the Addresses belong to the same 6LN. not the Addresses belong to the same 6LN.
In the following sections, is is expected that an NA is sent over the In the following sections, it is expected that an NA is sent over the
backbone only if the node is primary or does not support the concept backbone only if the node is primary or does not support the concept
of primary. More than one 6BBR claiming or defending an address of primary. More than one 6BBR claiming or defending an address
generates unwanted traffic but no reachability issue since all 6BBRs generates unwanted traffic but no reachability issue since all 6BBRs
provide reachability from the Backbone to the 6LN. provide reachability from the Backbone to the 6LN.
If a Registering Node loses connectivity to its or one of the 6BBRs
to which it registered an address, it retries the registration to the
(one or more) available 6BBR(s). When doing that, the Registering
Node MUST increment the TID in order to force the migration of the
state to the new 6BBR, and the reselection of the primary 6BBR if it
is the node that was lost.
3.6. Using Optimistic DAD 3.6. Using Optimistic DAD
Optimistic Duplicate Address Detection [RFC4429] (ODAD) specifies how Optimistic Duplicate Address Detection [RFC4429] (ODAD) specifies how
an IPv6 Address can be used before completion of Duplicate Address an IPv6 Address can be used before completion of Duplicate Address
Detection (DAD). ODAD guarantees that this behavior will not cause Detection (DAD). ODAD guarantees that this behavior will not cause
harm if the new Address is a duplicate. harm if the new Address is a duplicate.
Support for ODAD avoids delays in installing the Neighbor Cache Entry Support for ODAD avoids delays in installing the Neighbor Cache Entry
(NCE) in the 6BBRs and the default router, enabling immediate (NCE) in the 6BBRs and the default router, enabling immediate
connectivity to the registered node. As shown in Figure 3, if the connectivity to the registered node. As shown in Figure 3, if the
skipping to change at page 17, line 42 skipping to change at page 18, line 5
a status of 4 ("Removed") to that other 6BBR. a status of 4 ("Removed") to that other 6BBR.
The EDAR message SHOULD carry the SLLAO used in NS messages by the The EDAR message SHOULD carry the SLLAO used in NS messages by the
6BBR for that Binding, and the EDAC message SHOULD carry the Target 6BBR for that Binding, and the EDAC message SHOULD carry the Target
Link Layer Address Option (TLLAO) associated with the currently Link Layer Address Option (TLLAO) associated with the currently
accepted registration. This enables a 6BBR to locate the new accepted registration. This enables a 6BBR to locate the new
position of a mobile 6LN in the case of a Routing Proxy operation, position of a mobile 6LN in the case of a Routing Proxy operation,
and opens the capability for the 6LBR to serve as a mapping server in and opens the capability for the 6LBR to serve as a mapping server in
the future. the future.
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 6BBR uses either the SNMA or plain unicast to the registration. The 6BBR uses either the SNMA or plain unicast to
defend the Registered Addresses in its Binding Table over the defend the Registered Addresses in its Binding Table over the
Backbone (as specified in [RFC4862]). The 6BBR advertises and Backbone (as specified in [RFC4862]). The 6BBR advertises and
defends the Registered Addresses over the Backbone Link using RS, defends the Registered Addresses over the Backbone Link using RS,
skipping to change at page 22, line 21 skipping to change at page 22, line 25
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.
Acting as a 6BBR, 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 * Acting as Bridging Proxy the 6LR MUST proxy ND over the backbone
for registered Link-Local addresses. 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.
* 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-
skipping to change at page 27, line 20 skipping to change at page 27, line 20
The Registering Node SHOULD also follow BCP 202 [RFC7772] in order to The Registering Node SHOULD also follow BCP 202 [RFC7772] in order to
limit the use of multicast RAs. It SHOULD also implement Simple limit the use of multicast RAs. It SHOULD also implement Simple
Procedures 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 procedures) to detect movements, and support Packet-Loss Resiliency
for Router Solicitations [RFC7559] in order to improve reliability for Router Solicitations [RFC7559] in order to improve reliability
for the unicast RS messages. for the 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, 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. In the MAC layer the transmissions so packets may neither be overheard
particular, the LLN MAC is required to provide secure unicast to/from or nor forged. In particular, the LLN MAC is required to provide
the Backbone Router and secure Broadcast from the Backbone Router in secure unicast to/from the Backbone Router and secure broadcast from
a way that prevents tampering with or replaying the RA messages. the routers in a way that prevents tampering with or replaying the ND
messages.
[I-D.ietf-6lo-ap-nd] guarantees the ownership of a registered address For the IPv6 ND operation over the backbone, and unless the classical
based on a proof-of-ownership encoded in the ROVR field and protects ND is disabled (e.g., by configuration), the classical ND messages
against address theft and impersonation inside the LLN, because the are interpreted as emitted by the address owner and have precedence
6LR can challenge the Registered Node for a proof-of-ownership. This over the 6BBR that is only a proxy. It results that the security
method does not extend over the backbone since the 6BBR cannot threats that are detailed in section 11.1 of [RFC4861] fully apply to
provide the proof-of-ownership. A possible attack over the backbone this specification as well. In very short:
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 * Any node that can send a packet on the backbone can take over any
that information, the attacker can easily increase the TID and take address including addresses of LLN nodes by claiming it with an NA
over the Binding. message and the Override bit set. This means that the real owner
will stop receiving its packets.
* Any node that can send a packet on the backbone can forge traffic
and pretend it is issued from a address that it does not own, even
if it did not claim the address using ND.
* Any node that can send a packet on the backbone can present itself
as a preferred router to intercept all traffic outgoing the
subnet. It may even expose a prefix on the subnet as not-on-link
and intercept all the traffic within the subnet.
* If the rogue can receive a packet from the backbone it can also
snoop all the intercepted traffic, be it by stealing an address or
the role of a router.
This means that any rogue access to the backbone must be prevented at
all times, and that nodes that are attached to the backbone must be
fully trusted / never compromised.
Using address registration as the sole ND mechanism on a link and
coupling it with [I-D.ietf-6lo-ap-nd] guarantees the ownership of a
registered address within that link. The protection is based on a
proof-of-ownership encoded in the ROVR field and protects against
address theft and impersonation by a 6LN, because the 6LR can
challenge the Registered Node for a proof-of-ownership.
The protection extends to the full LLN in the case of an LLN Link,
but does not extend over the backbone since the 6BBR cannot provide
the proof-of-ownership when it defends the address.
A possible attack over the backbone 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 that information, the attacker
can easily increase the TID and take over the Binding.
If the classical ND is disabled on the backbone and the use of
[I-D.ietf-6lo-ap-nd] and a 6LBR are mandated, the network will
benefit from the following new advantages:
Zero-trust security for ND flows within the whole subnet: the
increased security that [I-D.ietf-6lo-ap-nd] provides on the LLN
will also apply to the backbone; it becomes impossible for an
attached node to claim an address that belongs to another node
using ND, and the network can filter packets that are not
originated by the owner of the source address (SAVI), as long as
that the routers are known and trusted.
Remote ND DoS attack avoidance: the complete list of addresses in
the network will be known to the 6LBR and available to the default
router; with that information the router does not need to send a
multicast NA(Lookup) in case of a Neighbor Cache miss for an
incoming packet, which is a source of remote DoS attack against
the network
Less IPv6 ND-related multicast on the backbone: DAD and NS(Lookup)
become unicast queries to the 6LBR
Better DAD operation on wireless: DAD has been found to fail to
detect duplications on large Wi-Fi infrastructures due to the
unreliable broadcast operation on wireless; using a 6LBR enables a
unicast lookup
Less Layer-2 churn on the backbone: Using the Routing Proxy
approach, the Link-Layer address of the LLN devices and their
mobility are not visible in the backbone; only the Link-Layer
addresses of the 6BBR and backbone nodes are visible at Layer 2 on
the backbone. This is mandatory for LLNs that cannot be bridged
on the backbone, and useful in any case to scale down, stabilize
the forwarding tables at Layer 2 and avoid the gratuitous frames
that are typically broadcasted to fix the transparent bridging
tables when a wireless node roams from an AP to the next.
This specification introduce a 6BBR that is a router on the path of
the LLN traffic and a 6LBR that is used for the lookup. They could
be interesting targets for an attacker, but not more than a default
router and a DHCP server, respectively, which already exist in
classical networks, and can be defended using the same methods.
A possible attack over the LLN can still be done by compromising a
6LR. A compromised 6LR may modify the ROVR of EDAR messages in
flight and transfer the ownership of the Registered Address to itself
or a tier. It may also claim that a ROVR was validated when it
really wasn't, and reattribute an address to self or to an attached
6LN. This means that 6LRs, as well as 6LBRs and 6BBRS must still be
fully trusted / never compromised.
This specification mandates to check on the 6LBR on the backbone
before doing the classical DAD, in case the address already exists.
This may delay the DAD operation and should be protected by a short
timer, in the order of 100ms or less, which will only represent a
small extra delay versus the 1s wait of the DAD operation.
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
skipping to change at page 28, line 14 skipping to change at page 30, line 14
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, Barry Leiba, Mirja
for their useful contributions through the IETF last call and IESG Kühlewind, Alvaro Retana, Roman Danyliw and very especially
process. Dominique Barthel and Benjamin Kaduk for their useful contributions
through the IETF last call and IESG process.
15. 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
 End of changes. 19 change blocks. 
42 lines changed or deleted 149 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/