Federated:

A subnet that comprises a backbone, and one or more (wireless) access links, is said to be federated into one MLSN. The ND proxy operation of 6BBRs over the backbone extends IPv6 ND operation over the access links.

Sleep Proxy:

A 6BBR acts as a Sleep Proxy if it answers IPv6 ND NSs over the backbone on behalf of the Registering Node that is in a sleep state and that cannot answer in due time.

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 link-layer address as the Target Link-Layer Address (TLLA) in the proxied Neighbor Advertisements (NAs) over the backbone and routes at the network layer between the federated links.

Bridging Proxy:

A Bridging Proxy provides IPv6 ND proxy functions while preserving forwarding continuity at the link layer. In that case, the link-layer address and the mobility of the Registering Node is visible across the bridged backbone. The Bridging Proxy advertises the link-layer address of the Registering Node in the TLLAO in the proxied NAs over the backbone, and it proxies ND for all unicast addresses including link-local addresses. Instead of replying on behalf of the Registering Node, a Bridging Proxy will preferably forward the NS(Lookup) and Neighbor Unreachability Detection (NUD) messages that target the Registered Address to the Registering Node as unicast frames, so it can respond in its own.

Binding Table:

The Binding Table is an abstract database that is maintained by the 6BBR to store the state associated with its registrations.

Binding:

A Binding is an abstract state associated to one registration; in other words, it's associated to one entry in the Binding Table.

6BBR:

6LoWPAN Backbone Router

6LBR:

6LoWPAN Border Router

6LN:

6LoWPAN Node

6LR:

6LoWPAN Router

AP:

Access Point

ARO:

Address Registration Option

DAC:

Duplicate Address Confirmation

DAD:

Duplicate Address Detection

DAR:

Duplicate Address Request

DODAG:

Destination-Oriented Directed Acyclic Graph

EARO:

Extended Address Registration Option

EDAC:

Extended Duplicate Address Confirmation

EDAR:

Extended Duplicate Address Request

ESS:

Extended Service Set

LLA:

Link-Layer Address

LLN:

Low-Power and Lossy Network

MLSN:

Multi-Link Subnet

MTU:

Maximum Transmission Unit

NA:

Neighbor Advertisement

NCE:

Neighbor Cache Entry

ND:

Neighbor Discovery

NS:

Neighbor Solicitation

NUD:

Neighbor Unreachability Detection

ODAD:

Optimistic DAD

RA:

Router Advertisement

ROVR:

Registration Ownership Verifier

RPL:

Routing Protocol for LLNs

RS:

Router Solicitation

SLLAO:

Source Link-Layer Address Option

SNMA:

Solicited-Node Multicast Address

STA:

Station

TID:

Transaction ID

TLLAO:

Target Link-Layer Address Option

Classical IPv6 ND:

"Neighbor Discovery for IP version 6 (IPv6)" [RFC 4861], "IPv6 Stateless Address Autoconfiguration" [RFC 4862], and "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC 4429];

IPv6 ND over multiple links:

"Neighbor Discovery Proxies (ND Proxy)" [RFC 4389] and "Multi-Link Subnet Issues" [RFC 4903];

6LoWPAN:

"Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing" [RFC 6606]; and

6LoWPAN ND:

Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC 6775], "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC 8505], and "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" [RFC 8928].

                 |
              +-----+               +-----+       +-----+ IPv6
    (default) |     |    (optional) |     |       |     | Node
       Router |     |          6LBR |     |       |     | or
              +-----+               +-----+       +-----+ 6LN
                 |  Backbone Side      |             |
     ----+-------+-----------------+---+-------------+----+-----
         |                         |                      |
      +------+                 +------+                +------+
      | 6BBR |                 | 6BBR |                | 6BBR |
      |      |                 |      |                |      |
      +------+                 +------+                +------+
         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  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
    

• MLSN functions (provided by the 6BBR on the backbone) performed on behalf of Registered Nodes
• Routing Registrar services that reduce multicast within the LLN:
  • - Binding Table management
  • - failover, e.g., due to mobility

• Creates a new entry in a Binding Table for a newly Registered Address and ensures that the address is not duplicated over the backbone.
• Advertises a Registered Address over the backbone using an NA message as either unsolicited or a response to an NS message. This includes joining the multicast group associated to the SNMA derived from the Registered Address, as specified in Section 7.2.1 of RFC 4861, over the backbone.
• The 6BBR MAY respond immediately as a proxy in lieu of the Registering Node, e.g., if the Registering Node has a sleep 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 response. It is preferred, though, that the 6BBR checks whether the Registering Node is still responsive on the Registered Address. To that effect:

  - as a Bridging Proxy:

  the 6BBR forwards the multicast DAD and address lookup messages as a unicast link-layer frame to the link-layer address of the Registering Node that matches the target in the ND message; the Neighbor Unreachability Detection (NUD) message is unicast and is forwarded as is. In all cases, the goal is 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.
• Delivers packets arriving from the LLN, using Neighbor Solicitation messages to look up the destination over the backbone.
• Forwards or bridges packets between the LLN and the backbone.
• Verifies liveness for a registration, when needed.

• The EARO [RFC 8505] is used in IPv6 ND exchanges over the backbone between the 6BBRs to help distinguish duplication from movement. Extended Duplicate Address Messages (EDAR and EDAC) may also be used to communicate with a 6LBR, if one is present. Address duplication is detected using the ROVR field. Conflicting registrations to different 6BBRs for the same Registered Address are resolved using the TID field, which forms an order of registrations.
• The LLA that the 6BBR advertises for the Registered Address on behalf of the Registered Node over the backbone can belong to the Registering Node; in that case, the 6BBR (acting as a Bridging Proxy (see Section 8)) bridges the unicast packets. Alternatively, the LLA can be that of the 6BBR on the backbone interface, in which case, the 6BBR (acting as a Routing Proxy (see Section 7)) receives the unicast packets at Layer 3 and routes over.

• De-registrations (newer TID, same ROVR, null Lifetime) are accepted with a status code of 4 ("Removed"); the entry is deleted.
• Newer registrations (newer TID, same ROVR, non-null Lifetime) are accepted with a status code of 0 ("Success"); the Binding is updated with the new TID, the Registration Lifetime, and the Registering Node. In Tentative state, the EDAC response is held and may be overwritten; in other states, the Registration Lifetime timer is restarted, and the entry is placed in Reachable state.
• Identical registrations (same TID, same ROVR) from the same Registering Node are accepted with a status code of 0 ("Success"). In Tentative state, the response is held and may be overwritten, but the response is eventually produced, carrying the result of the DAD process.
• Older registrations (older TID, same ROVR) from the same Registering Node are discarded.
• Identical and older registrations (not-newer TID, same ROVR) from a different Registering Node are rejected with a status code of 3 ("Moved"); this may be rate-limited to avoid undue interference.
• Any registration for the same address but with a different ROVR is rejected with a status code of 1 ("Duplicate Address").

• Section 7.2.8 of RFC 4861 specifies that an NA message generated 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 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 two nodes form the same address at nearly the same time, the node that first claimed the address cannot be detected per Section 5.4.3 of RFC 4862, and the address is abandoned.
• In any case, [RFC 4862] indicates that a node never responds to a Neighbor Solicitation for a tentative address.

• 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-served.
• an NS or an NA that denotes an older registration for the same Registered Node is not interpreted as a duplication as specified in Sections 5.4.3 and 5.4.4 of [RFC 4862], respectively.

• 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 code of 1 ("Duplicate Address"), unless the received message is an NA that carries an EARO with a status code of 1 ("Duplicate Address").

• 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 code of 3 ("Moved") to ensure that the Stale state is removed rapidly.

• Acting as a Bridging Proxy, the 6LR MUST ND proxy over the backbone for registered link-local addresses.
• EDAR and EDAC messages SHOULD carry an SLLAO and a TLLAO, respectively.
• An EDAC message with a status code of 9 ("6LBR Registry Saturated") is assimilated as a status code of 0 ("Success") if a following DAD process protects the address against duplication.

• The Binding MUST be removed if an NA message is received over the backbone for the Registered Address with no EARO or with an EARO that indicates an existing registration owned by a different Registering Node (different ROVR). In that case, an NA is sent back to the Registering Node with a status code of 1 ("Duplicate Address") to indicate that the Binding has been rejected. This behavior might be overridden by policy, in particular if the registration is trusted, e.g., based on the validation of the ROVR field (see [RFC 8928]).
• The Binding MUST be removed if an NS(DAD) message is received over the backbone for the Registered Address with no EARO or with an EARO that has a different ROVR that indicates a tentative registration by a different Registering Node. In that case, an NA is sent back to the Registering Node with a status code of 1 ("Duplicate Address"). This behavior might be overridden by policy, in particular if the registration is trusted, e.g., based on the validation of the ROVR field (see [RFC 8928]).
• The Binding MUST be removed if an NA or an NS(DAD) message is received over the backbone for the Registered Address and contains an EARO that indicates a fresher registration [RFC 8505] for the same Registering Node (same ROVR). In that case, an NA MUST be sent back to the Registering Node with a status code of 3 ("Moved").
• The Binding MUST be kept unchanged if an NA or an NS(DAD) message is received over the backbone for the Registered Address and contains an EARO that indicates an older registration [RFC 8505] for the same Registering Node (same ROVR). The message is answered with an NA that carries an EARO with a status code 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.
• NS(Lookup) and NS(NUD) messages SHOULD be optimistically answered with an NA message containing an EARO with a status code of 0 ("Success") and the Override flag not set (see Section 3.6). If optimistic DAD is disabled, then they SHOULD be queued to be answered when the Binding goes to Reachable state.

• The Binding MUST be removed if an NA or an NS(DAD) message is received over the backbone for the Registered Address and contains an EARO that indicates a fresher registration [RFC 8505] for the same Registered Node (i.e., same ROVR but fresher TID). A status code of 4 ("Removed") is returned in an asynchronous NA(EARO) to the Registering Node. Based on configuration, an implementation may delay this operation by a timer with a short setting, e.g., a few seconds to a minute, in order to allow for a parallel registration to reach this node, in which case the NA might be ignored.
• NS(DAD) and NA messages containing an EARO that indicates a registration for the same Registered Node that is not as fresh as this Binding MUST be answered with an NA message containing an EARO with a status code 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 code of 1 ("Duplicate Address") and the Override flag not set, unless the received message is an NA that carries an EARO with a status code of 1 ("Duplicate Address"), in which case the node refrains from answering.
• Other NS(DAD) and NA messages from the backbone are ignored.
• NS(Lookup) and NS(NUD) messages SHOULD be answered with an NA message containing an EARO with a status code of 0 ("Success") and the Override flag not set. The 6BBR MAY check whether the Registering Node is still available using a NUD procedure over the LLN prior to answering; this behavior depends on the use case and is subject to configuration.

• The Binding MUST be removed if an NA or an NS(DAD) message is received over the backbone for the Registered Address with no EARO or with an EARO that indicates either a fresher registration for the same Registered Node or a duplicate registration. A status code of 4 ("Removed") MAY be returned in an asynchronous NA(EARO) to the Registering Node.
• NS(DAD) and NA messages containing an EARO that indicates a 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 status code of 3 ("Moved").
• If the 6BBR receives an NS(Lookup) or an NS(NUD) message for the Registered Address, the 6BBR MUST attempt a NUD procedure as specified in [RFC 7048] to the Registering Node, targeting the Registered Address, prior to answering. If the NUD procedure succeeds, the operation in Reachable state applies. If the NUD fails, the 6BBR refrains from answering.
• Other NS(DAD) and NA messages from the backbone are ignored.

• Any node that can send a packet on the backbone can take over any address, including addresses of LLN nodes, by claiming it with an NA 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 an 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 on 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, by stealing an address or the role of a router.

• The protection is based on a proof of ownership encoded in the ROVR field, and it 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 it does not extend over the backbone since the 6BBR cannot provide the proof of ownership when it defends the address.

Zero-trust security for ND flows within the whole subnet:

the increased security that [RFC 8928] 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 (Source Address Validation Improvement (SAVI)), as long as 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 NS(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.

TENTATIVE_DURATION:

800 milliseconds

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC4291]

R. Hinden, and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006,
<https://www.rfc-editor.org/info/rfc4291>.

[RFC4429]

N. Moore, "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<https://www.rfc-editor.org/info/rfc4429>.

[RFC4861]

T. Narten, E. Nordmark, W. Simpson, and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.

[RFC4862]

S. Thomson, T. Narten, and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007,
<https://www.rfc-editor.org/info/rfc4862>.

[RFC6059]

S. Krishnan, and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, DOI 10.17487/RFC6059, November 2010,
<https://www.rfc-editor.org/info/rfc6059>.

[RFC6775]

Z. Shelby, S. Chakrabarti, E. Nordmark, and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012,
<https://www.rfc-editor.org/info/rfc6775>.

[RFC7048]

E. Nordmark, and I. Gashinsky, "Neighbor Unreachability Detection Is Too Impatient", RFC 7048, DOI 10.17487/RFC7048, January 2014,
<https://www.rfc-editor.org/info/rfc7048>.

[RFC7559]

S. Krishnan, D. Anipko, 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]

A. Yourtchenko, 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>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8200]

S. Deering, and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.

[RFC8201]

J. McCann, S. Deering, J. Mogul, and R. Hinden, "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.

[RFC8505]

P. Thubert, E. Nordmark, S. Chakrabarti, and C. Perkins, "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
<https://www.rfc-editor.org/info/rfc8505>.

[6TiSCH]

Cisco Systems, Inc, , "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Internet-Draft draft-ietf-6tisch-architecture-29, August 2020,
<https://tools.ietf.org/html/draft-ietf-6tisch-architecture-29>.

[DAD-APPROACHES]

, "Possible approaches to make DAD more robust and/or efficient", Internet-Draft draft-nordmark-6man-dad-approaches-02, October 2015,
<https://tools.ietf.org/html/draft-nordmark-6man-dad-approaches-02>.

[DAD-ISSUES]

, and , "A survey of issues related to IPv6 Duplicate Address Detection", Internet-Draft draft-yourtchenko-6man-dad-issues-01, March 2015,
<https://tools.ietf.org/html/draft-yourtchenko-6man-dad-issues-01>.

[IEEEstd80211]

IEEE, "IEEE Standard for Information technology--Telecommunications and information exchange between systems Local and metropolitan area networks--Specific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE 802.11-2012, DOI 10.1109/ieeestd.2016.7786995, December 2016,
<https://ieeexplore.ieee.org/document/7786995>.

[IEEEstd802151]

IEEE, "IEEE Standard for Information technology--Local and metropolitan area networks--Specific requirements--Part 15.1a: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications for Wireless Personal Area Networks (WPAN)", IEEE 802.15.1-2005, DOI 10.1109/ieeestd.2005.96290, June 2005,
<https://ieeexplore.ieee.org/document/1490827>.

[IEEEstd802154]

IEEE, "IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)", IEEE 802.15.4-2011, DOI 10.1109/ieeestd.2011.6012487, September 2011,
<https://ieeexplore.ieee.org/document/6012487>.

[IEEEstd8021Q]

IEEE, "IEEE Standard for Local and Metropolitan Area Networks--Bridges and Bridged Networks", IEEE 802.1Q-2018, DOI 10.1109/IEEESTD.2018.8403927, July 2018,
<https://ieeexplore.ieee.org/document/8403927>.

[MCAST-PROBLEMS]

SIGFOX, , , , , and , "Multicast Considerations over IEEE 802 Wireless Media", Internet-Draft draft-ietf-mboned-ieee802-mcast-problems-12, October 2020,
<https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-12>.

[RFC4271]

Y. Rekhter, T. Li, and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.

[RFC4389]

D. Thaler, M. Talwar, and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2006,
<https://www.rfc-editor.org/info/rfc4389>.

[RFC4903]

D. Thaler, "Multi-Link Subnet Issues", RFC 4903, DOI 10.17487/RFC4903, June 2007,
<https://www.rfc-editor.org/info/rfc4903>.

[RFC5340]

R. Coltun, D. Ferguson, J. Moy, and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.

[RFC5415]

P. Calhoun, M. Montemurro, and D. Stanley, "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]

C. Perkins, D. Johnson, and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011,
<https://www.rfc-editor.org/info/rfc6275>.

[RFC6550]

T. Winter, P. Thubert, A. Brandt, J. Hui, R. Kelsey, P. Levis, K. Pister, R. Struik, JP. Vasseur, and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>.

[RFC6606]

E. Kim, D. Kaspar, C. Gomez, 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]

D. Farinacci, V. Fuller, D. Meyer, and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013,
<https://www.rfc-editor.org/info/rfc6830>.

[RFC7432]

A. Sajassi, R. Aggarwal, N. Bitar, A. Isaac, J. Uttaro, J. Drake, and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015,
<https://www.rfc-editor.org/info/rfc7432>.

[RFC8273]

J. Brzozowski, 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>.

[RFC8928]

P Thubert, B Sarikaya, M Sethi, and R Struik, "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November 2020,
<https://www.rfc-editor.org/info/rfc8928>.

[RIFT]

Yandex, , , , , and , "RIFT: Routing in Fat Trees", Internet-Draft draft-ietf-rift-rift-12, May 2020,
<https://tools.ietf.org/html/draft-ietf-rift-rift-12>.

[RPL-LEAVES]

Sandelman Software Works, , and , "Routing for RPL Leaves", Internet-Draft draft-ietf-roll-unaware-leaves-23, November 2020,
<https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-23>.

[RS-REFRESH]

, , and , "IPv6 Neighbor Discovery Optional RS/RA Refresh", Internet-Draft draft-ietf-6man-rs-refresh-02, October 2016,
<https://tools.ietf.org/html/draft-ietf-6man-rs-refresh-02>.

[SAVI-WLAN]

New H3C Technologies Co. Ltd, , , , and , "A SAVI Solution for WLAN", Internet-Draft draft-bi-savi-wlan-20, November 2020,
<https://tools.ietf.org/html/draft-bi-savi-wlan-20>.

[UNICAST-LOOKUP]

Cisco Systems, Inc, , and , "IPv6 Neighbor Discovery Unicast Lookup", Internet-Draft draft-thubert-6lo-unicast-lookup-00, January 2019,
<https://tools.ietf.org/html/draft-thubert-6lo-unicast-lookup-00>.

Pascal Thubert

Charles E. Perkins

Eric Levy-Abegnoli