RFC 8929

IPv6 Backbone Router

📅 published November 2020, from ietf

RFC 8929: IPv6 Backbone Router ✨

Internet Engineering Task Force (IETF) 🌸 P. Thubert, Ed. from Cisco Systems, C.E. Perkins from Blue Meadow Networking, and E. Levy-Abegnoli from Cisco Systems 💖 wrote this one, and it dropped in November 2020 📅 as a Standards Track document 🔥. It updates RFC 6775 and RFC 8505 🦋, which means it adds to those specs rather than replacing them. The ISSN is 2070-1721 ✨, and it's listed as Request for Comments: 8929 💅.

Abstract

okay so this doc updates RFCs 6775 and 8505 🎀 so that Routing Registrars called "Backbone Routers" can handle proxy services for IPv6 Neighbor Discovery 🧚. These Backbone Routers sit along the wireless edge of a backbone and team up multiple wireless links into one single Multi-Link Subnet (MLSN) 💜. It's giving unified subnet energy, periodt 💅✨.

Status of This Memo

this is an Internet Standards Track document 🌈. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. If you want more on Internet Standards, check Section 2 of RFC 7841 📚.

Info about the current status, any errata, and how to give feedback lives at https://www.rfc-editor.org/info/rfc8929 🔗.

Copyright (c) 2020 IETF Trust and the persons identified as the document authors 💖. All rights reserved ✨.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication 📜. Please actually read these, bestie, because they explain your rights and restrictions 🙈. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Simplified BSD License 🍓.

Table of Contents

   1.  Introduction
   2.  Terminology
     2.1.  Requirements Language
     2.2.  New Terms
     2.3.  Abbreviations
     2.4.  Background
   3.  Overview
     3.1.  Updating RFCs 6775 and 8505
     3.2.  Access Link
     3.3.  Route-Over Mesh
     3.4.  The Binding Table
     3.5.  Primary and Secondary 6BBRs
     3.6.  Using Optimistic DAD
   4.  Multi-Link Subnet Considerations
   5.  Optional 6LBR Serving the Multi-Link Subnet
   6.  Using IPv6 ND over the Backbone Link
   7.  Routing Proxy Operations
   8.  Bridging Proxy Operations
   9.  Creating and Maintaining a Binding
     9.1.  Operations on a Binding in Tentative State
     9.2.  Operations on a Binding in Reachable State
     9.3.  Operations on a Binding in Stale State
   10. Registering Node Considerations
   11. Security Considerations
   12. Protocol Constants
   13. IANA Considerations
   14. Normative References
   15. Informative References
   Appendix A.  Possible Future Extensions
   Appendix B.  Applicability and Requirements Served
   Acknowledgments
   Authors' Addresses

1. Introduction 🦋

okay so Ethernet bridging (IEEE Std 802.1 [IEEEstd8021Q]) gives you an efficient and reliable broadcast service for wired networks 🔌, and so many apps and protocols are built on it that they literally depend on it for their core operation 💀. The problem is that Low-Power and Lossy Networks (LLNs) and local wireless networks usually can't offer that broadcast magic affordably 😭.

So protocols designed for bridged networks that lean on multicast and broadcast tend to act pretty disappointing when you drop them unmodified onto a local wireless medium (see [MCAST-PROBLEMS]) 🙈.

Wi-Fi [IEEEstd80211] Access Points (APs) in an Extended Service Set (ESS) act as Ethernet bridges [IEEEstd8021Q] 🌸, and the bridging state gets set up at association time 💜. That keeps the end node (the Wi-Fi Station (STA)) connected and protects the wireless medium from broadcast-heavy transparent bridging [IEEEstd8021Q] reactive lookups 🛡️. In other words, association is how the STA's link-layer address gets registered with the AP 🫶. The AP then proxies the bridging operation so it doesn't have to forward broadcast lookups over the radio ✨.

Same vibe as transparent bridging: IPv6 [RFC8200] Neighbor Discovery (IPv6 ND) [RFC4861] [RFC4862] is a reactive protocol 🔥. It uses multicast transmissions to find an on-link correspondent and make sure an IPv6 address is unique 🎀. The Duplicate Address Detection (DAD) [RFC4862] mechanism was designed around the efficient broadcast of Ethernet bridging 💅. But broadcast can be unreliable over wireless, so DAD often fails to catch duplicates [DAD-ISSUES] 😭. Honestly, IPv6 addresses rarely conflict mostly because of the entropy in the 64-bit Interface IDs, not because IPv6 ND DAD and resolution work perfectly 🌈.

The Neighbor Solicitation (NS) [RFC4861] message handles DAD and address lookup when a node moves or wakes up and reconnects to the wireless network 🧚. The NS message targets a Solicited-Node Multicast Address (SNMA) [RFC4291] and should, in theory, only reach a tiny group of nodes ⭐. But in reality, IPv6 multicast gets broadcast on the wireless medium, so most wireless nodes on the subnet (e.g., the ESS fabric) process it no matter how few of them subscribed to the SNMA 💀. So IPv6 ND lookups and DADs over a big wireless network and/or LLN can eat up enough bandwidth to seriously degrade unicast traffic 😭🔥.

Also, since IPv6 ND messages sent to the SNMA group get broadcast at the radio link layer, wireless nodes that aren't in the SNMA group still have to keep their radio on to hear multicast NS messages 🔋. That's a waste of energy for them 😩. To save power, some battery-operated devices like Internet of Things (IoT) sensors and smartphones ignore some of the broadcasts 📱, which makes IPv6 ND even less reliable 🙈.

These problems can be eased by cutting down IPv6 ND broadcasts over wireless access links 💖. People have done this by splitting broadcast domains and routing between subnets 🦋. At the extreme, you can give each wireless node its own /64 prefix (see [RFC8273]) 🌈. But deploying one large subnet can still be attractive, since it avoids renumbering when lots of devices move around inside a bounded area 👑.

One way to cut IPv6 ND broadcast propagation in the wireless domain while keeping one large subnet is to form a Multi-Link Subnet (MLSN) 💜. Every link in the MLSN, the backbone included, is its own broadcast domain ✨. The key thing about MLSNs is that link-local unicast traffic, link-scope multicast, and traffic with a hop limit of 1 won't reach nodes in the same subnet on a different link 🙈. That can cause surprising behavior in software that assumes a subnet lives entirely on one link 💀.

This spec looks at a special kind of MLSN with a central backbone that federates edge (LLN) links 🌸, where each link protects itself against rogue access and tampering or replaying of packets 🛡️. Specifically, classical IPv6 ND on the backbone requires that all nodes are trusted and that rogue access to the backbone is prevented at all times (see Section 11) 🔒.

In that topology, ND proxies can sit at the boundary between the edge links and the backbone 🧚. They handle IPv6 ND on behalf of Registered Nodes and forward IPv6 packets back and forth 💅. The ND proxy keeps IPv6 ND going beyond the backbone and lets any pair of nodes in the MLSN talk using Global or Unique Local Addresses ✨.

The 6LoWPAN Backbone Router (6BBR) is a Routing Registrar [RFC8505] that provides ND proxy services 👑. A 6BBR acting as a Bridging Proxy gives an ND proxy function with Layer 2 continuity, and it can be collocated with a Wi-Fi AP as prescribed by IEEE Std 802.11 [IEEEstd80211] 📡. A 6BBR acting as a Routing Proxy works with any type of LLN, including LLNs that can't be bridged onto the backbone, like IEEE Std 802.15.4 [IEEEstd802154] 🦋.

You can figure out which address to proxy by snooping the IPv6 ND protocol (see [SAVI-WLAN]), but that's been found to be unreliable 😬. An IPv6 address might not show up right away because of packet loss, or because a "silent" node isn't using one of its addresses at the moment 🙈. A change of state (like movement) might get missed or arrive out of order, which leads to flaky connectivity and an incomplete picture of the network 💀.

With this spec, the address to proxy is signaled explicitly through a registration process 🎀. A 6LoWPAN Node (6LN) registers all of its IPv6 addresses using NS messages with an Extended Address Registration Option (EARO) as specified in [RFC8505] 💖, sending them to the 6LoWPAN Router (6LR) it's directly attached to 🧚. If the 6LR is a 6BBR, the 6LN is both the Registered Node and the Registering Node 🌸. If not, the 6LoWPAN Border Router (6LBR) serving the LLN proxies the registration to the 6BBR 🫶. In that case, the 6LN is the Registered Node and the 6LBR is the Registering Node ✨. The 6BBR does IPv6 ND operations on its backbone interface on behalf of the 6LNs that have Registered Addresses on its LLN interfaces, with no broadcast needed over the wireless medium 🔥.

A Registering Node that lives on the backbone doesn't register to the SNMA groups tied to its Registered Addresses 🙅. Instead it defers to the 6BBR to answer, or better yet forward the matching multicast packets to it as unicast 💅.

2. Terminology 💜

2.1. Requirements Language ✨

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀.

<!-- Part 1 of 9 ends here. More parts follow. -->

2.2. New Terms ✨

okay so this section introduces some brand new terms, and you're gonna need all of them to follow the rest of the spec 🫶

  • Federated: when a subnet has a backbone plus one or more (wireless) access links, it's said to be federated into one MLSN 🌸 The ND proxy stuff that 6BBRs do over the backbone is what stretches IPv6 ND out over those access links. iconic teamwork ✨
  • Sleep Proxy: a 6BBR becomes a Sleep Proxy when it answers IPv6 ND NSs over the backbone for a Registering Node that's asleep and can't reply in time 💤 it's basically covering for its sleepy bestie 😭
  • Routing Proxy: a Routing Proxy does IPv6 ND proxy stuff so MLSN can work over federated links that might not be bridge-compatible 🦋 it puts its own link-layer address in the TLLA of the proxied NAs sent over the backbone, and then it routes at the network layer between the federated links. main character routing energy 👑
  • Bridging Proxy: a Bridging Proxy also does IPv6 ND proxy stuff, but it keeps forwarding continuity at the link layer 🌈 so the link-layer address and the mobility of the Registering Node stay visible across the bridged backbone. it puts the Registering Node's link-layer address in the TLLAO of the proxied NAs over the backbone, and it proxies ND for all unicast addresses, link-local ones included 💅 instead of replying for the Registering Node, a Bridging Proxy will preferably forward the NS(Lookup) and Neighbor Unreachability Detection (NUD) messages aimed at the Registered Address to the Registering Node as unicast frames, so the node can respond in its own voice 🎀
  • Binding Table: an abstract database the 6BBR keeps to store the state tied to its registrations 🍓
  • Binding: an abstract state tied to one registration. in other words, one entry in the Binding Table ⭐

2.3. Abbreviations

this section has all the abbreviations we'll be using, so bookmark it bestie 🧚

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

2.4. Background

this doc throws around ideas from a bunch of other specs, so here's the homework list 📚 you'll bump into these concepts:

  • Classical IPv6 ND: "Neighbor Discovery for IP version 6 (IPv6)" [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], and "Optimistic Duplicate Address Detection (DAD) for IPv6" [RFC4429] 💜
  • IPv6 ND over multiple links: "Neighbor Discovery Proxies (ND Proxy)" [RFC4389] and "Multi-Link Subnet Issues" [RFC4903] 🌈
  • 6LoWPAN: "Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606]; and 🌸
  • 6LoWPAN ND: Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC6775], "Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery" [RFC8505], and "Address-Protected Neighbor Discovery for Low-Power and Lossy Networks" [RFC8928] 🫶

3. Overview

this section and its subsections are a non-normative, high-level tour of how the 6BBR works 🦋 the normative stuff comes later, so don't panic yet 💖

Figure 1 shows a Backbone Link that federates a bunch of LLNs as one single IPv6 subnet, with several 6BBRs giving ND proxy services to their attached LLNs 🌸

                |
             +-----+               +-----+       +-----+ 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

            Figure 1: Backbone Link and Backbone Routers

the LLN might be a hub-and-spoke access link like (Low-Power) IEEE Std 802.11 (Wi-Fi) [IEEEstd80211] and IEEE Std 802.15.1 (Bluetooth) [IEEEstd802151], or it might be a mesh-under or a route-over network [RFC8505] 🕸️ the proxy state can be spread across multiple 6BBRs attached to the same backbone 🧚

the main features of a 6BBR go like this 💅

  • 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

each Backbone Router (6BBR) keeps a data structure for its Registered Addresses, called a Binding Table 🍓 the abstract data stored in the Binding Table includes the Registered Address; anchor info on the Registering Node like the connecting interface, its link-local address, and its link-layer address (LLA) on that interface; the EARO, including ROVR and TID; a state that can be Reachable, Tentative, or Stale; and other info, like a trust level that may be configured, e.g., to protect a server 🛡️ all the Binding Tables from every 6BBR on a backbone together form a distributed database of Registered Nodes that live in the LLNs or on the IPv6 Backbone 🌟

unless it's configured otherwise, a 6BBR does the following:

  • Creates a new entry in a Binding Table for a newly Registered Address, and makes sure that address isn't duplicated over the backbone 💖
  • Advertises a Registered Address over the backbone using an NA message, either unsolicited or as a response to an NS message. this includes joining the multicast group tied to the SNMA derived from the Registered Address, as specified in Section 7.2.1 of [RFC4861], 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 doesn't want to interrupt, or if the 6BBR has a recent state that's deemed fresh enough to permit the proxied response 😴 it's 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 first of these functions lets the 6BBR be a Routing Registrar for each of its attached LLNs 👑 the rest are the 6BBRs' border-router jobs, the stuff that federates the Multi-Link IPv6 Subnet 🌸

the operation of IPv6 ND and ND proxy are not mutually exclusive on the backbone. so nodes on the backbone using IPv6 ND can transparently interact with 6LNs that rely on a 6BBR to ND proxy for them, whether those 6LNs are reachable over an LLN or directly attached to the backbone 🫶

the registration mechanism [RFC8505] used to learn addresses to be proxied may coexist in a 6BBR with a proprietary snooping or the traditional bridging functionality of an AP, so it can support legacy LLN nodes that don't support this spec 🧚

the registration to a proxy service uses an NS/NA exchange with EARO. the 6BBR operation looks a lot like a Mobile IPv6 (MIPv6) [RFC6275] Home Agent (HA) 🏠 the combo of a 6BBR and a MIPv6 HA gives full mobility support for 6LNs, inside and outside the links that form the subnet 🌈

6BBRs do IPv6 ND functions over the backbone like this:

  • The EARO [RFC8505] is used in IPv6 ND exchanges over the backbone between the 6BBRs to help tell duplication apart 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. 🦋✨

3.1. Updating RFCs 6775 and 8505 🎀

okay so this spec adds the EARO as a possible option in RS, NS(DAD), and NA messages over the backbone 🦋 this doc tells 6BBRs how to use those ND messages on the backbone, at a high level in Section 6 and in more detail in Section 9 💅

✨ Note: [RFC8505] requires that the registration NS(EARO) contain a Source Link-Layer Address Option (SLLAO). [RFC4862] requires that the NS(DAD) be sent from the unspecified address for which there cannot be an SLLAO. Consequently, an NS(DAD) cannot be confused with a registration. 🙈

okay so this spec allows a 6LBR to be deployed on the backbone where EDAR and EDAC messages coexist with classical ND 🌈 it also adds the ability to insert IPv6 ND options in the EDAR and EDAC messages 🧚 a 6BBR acting as a 6LR for the Registered Address can insert an SLLAO in the EDAR to the 6LBR so it doesn't cause a multicast NS(lookup) to come back 😭 this lets the 6LBR store the link-layer address tied to the Registered Address on a link and act as a mapping server, as described in [UNICAST-LOOKUP] 💖

this spec also allows an address to be registered to more than one 6BBR 💜 so a 6LBR deployed on the backbone MUST be capable of maintaining state for each of the 6BBRs that have registered with the same TID and same ROVR 🔥

the simplest MLSN topology from the Layer 3 perspective is when the wireless network shows up as a single-hop hub-and-spoke network, as shown in Figure 2 ✨ the Layer 2 operation may be effectively hub-and-spoke (e.g., Wi-Fi) or mesh-under, with a Layer 2 protocol handling the complex topology 🦋

                 |
              +-----+               +-----+       +-----+ IPv6
    (default) |     |    (optional) |     |       |     | Node
       Router |     |          6LBR |     |       |     | or
              +-----+               +-----+       +-----+ 6LN
                 |  Backbone Side      |             |
     ----+-------+-----------------+---+-------------+----+-----
         |                         |                      |
      +------+                 +------+                +------+
      | 6BBR |                 | 6BBR |                | 6BBR |
      | 6LR  |                 | 6LR  |                | 6LR  |
      +------+                 +------+                +------+
   (6LN) (6LN) (6LN)       (6LN) (6LN) (6LN)          (6LN) (6LN)

                    Figure 2: Access Link Use Case

Figure 3 shows a flow where a 6LN forms an IPv6 address and registers it to a 6BBR acting as a 6LR [RFC8505] 🎀 the 6BBR applies Optimistic Duplicate Address Detection (ODAD) (see Section 3.6) to the Registered Address so connectivity works while the message flow is still in progress 💅

       6LN(STA)         6BBR(AP)          6LBR          default GW
         |                 |                |                   |
         | LLN Access Link |  IPv6 Backbone  (e.g., Ethernet)   |
         |                 |                |                   |
         |  RS(multicast)  |                |                   |
         |---------------->|                |                   |
         | RA(PIO, Unicast)|                |                   |
         |<----------------|                |                   |
         |   NS(EARO)      |                |                   |
         |---------------->|                |                   |
         |                 |  Extended DAR  |                   |
         |                 |--------------->|                   |
         |                 |  Extended DAC  |                   |
         |                 |<---------------|                   |
         |                 |                                    |
         |                 |     NS-DAD(EARO, multicast)        |
         |                 |-------->                           |
         |                 |----------------------------------->|
         |                 |                                    |
         |                 |      RS(no SLLAO, for ODAD)        |
         |                 |----------------------------------->|
         |                 | if (no fresher Binding) NS(Lookup) |
         |                 |                   <----------------|
         |                 |<-----------------------------------|
         |                 |      NA(SLLAO, not(O), EARO)       |
         |                 |----------------------------------->|
         |                 |           RA(unicast)              |
         |                 |<-----------------------------------|
         |                 |                                    |
         |           IPv6 Packets in Optimistic Mode            |
         |<---------------------------------------------------->|
         |                 |                                    |
         |                 |
         |  NA(EARO)       |<DAD timeout>
         |<----------------|
         |                 |

   Figure 3: Initial Registration Flow to a 6BBR Acting as a Routing
                                Proxy

in this example a 6LBR is deployed on the Backbone Link to serve the whole subnet, and EDAR/EDAC messages are used together with DAD so they can coexist with IPv6 ND over the backbone 🧚

the RS the 6LN sends first (e.g., from a Wi-Fi STA) goes out as a multicast, but since the 6BBR intercepts it, it's never actually broadcast 🙈 the multiple arrows on the ND messages over the backbone mean a real Layer 2 broadcast 🦋

3.3. Route-Over Mesh 🍓

a more complex MLSN topology happens when the wireless network shows up as a Layer 3 mesh network, as shown in Figure 4 💜 a so-called route-over routing protocol exposes routes between 6LRs towards both 6LRs and 6LNs, and a 6LBR acts as the Root of the Layer 3 mesh network and proxy-registers the LLN addresses to the 6BBR 👑

                 |
              +-----+               +-----+       +-----+ IPv6
    (default) |     |    (optional) |     |       |     | Node
       Router |     |          6LBR |     |       |     | or
              +-----+               +-----+       +-----+ 6LN
                 |  Backbone Side      |             |
     ----+-------+-----------------+---+-------------+----+-----
         |                         |                      |
      +------+                 +------+                +------+
      | 6BBR |                 | 6BBR |                | 6BBR |
      +------+                 +------+                +------+
          |                        |                       |
      +------+                 +------+                +------+
      | 6LBR |                 | 6LBR |                | 6LBR |
      +------+                 +------+                +------+
     (6LN) (6LR) (6LN)       (6LR) (6LN) (6LR)      (6LR) (6LR)(6LN)
  (6LN)(6LR) (6LR) (6LN)   (6LN) (6LR)(6LN) (6LR)  (6LR)  (6LR) (6LN)
    (6LR)(6LR) (6LR)         (6LR)  (6LR)(6LN)    (6LR) (6LR)(6LR)
  (6LR)  (6LR)    (6LR)   (6LR) (6LN)(6LR) (6LR)    (6LR) (6LR) (6LR)
  (6LN) (6LN)(6LN) (6LN) (6LN)       (6LN) (6LN)  (6LN)  (6LN) (6LN)

                  Figure 4: Route-Over Mesh Use Case

Figure 5 shows IPv6 signaling where a 6LN (the Registered Node) forms a Global or a Unique Local Address and registers it to the 6LBR that serves its LLN, using [RFC8505] and a neighboring 6LR as relay 🌈 the 6LBR (the Registering Node) then proxies the registration [RFC8505] to the 6BBR so it can get ND proxy services from the 6BBR ✨

the RS the 6LN sends first is transmitted as a multicast and stays within 1-hop broadcast range, where hopefully a 6LR is found 🦋 the 6LR is expected to already be connected to the LLN and able to reach the 6LBR, which may be multiple hops away, using unicast messages 💅

    6LoWPAN Node        6LR             6LBR            6BBR
    (mesh leaf)     (mesh router)   (mesh root)
         |               |               |               |
         |  6LoWPAN ND   |6LoWPAN ND     | 6LoWPAN ND    | IPv6 ND
         |   LLN Link    |Route-Over Mesh|Ethernet/Serial| Backbone
         |               |               |/Internal Call |
         |  IPv6 ND RS   |               |               |
         |-------------->|               |               |
         |----------->   |               |               |
         |------------------>            |               |
         |  IPv6 ND RA   |               |               |
         |<--------------|               |               |
         |               |               |               |
         |  NS(EARO)     |               |               |
         |-------------->|               |               |
         | 6LoWPAN ND    | Extended DAR  |               |
         |               |-------------->|               |
         |               |               |  NS(EARO)     |
         |               |               |-------------->|
         |               |               |  (proxied)    | NS-DAD
         |               |               |               |------>
         |               |               |               | (EARO)
         |               |               |               |
         |               |               |  NA(EARO)     |<timeout>
         |               |               |<--------------|
         |               | Extended DAC  |               |
         |               |<--------------|               |
         |  NA(EARO)     |               |               |
         |<--------------|               |               |
         |               |               |               |

       Figure 5: Initial Registration Flow over Route-Over Mesh

as a non-normative example of a route-over mesh 🧚 the IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) architecture [6TiSCH] suggests using the RPL [RFC6550] and collocating the RPL root with a 6LBR that serves the LLN 💖 the 6LBR is also either collocated with or directly connected to the 6BBR over an IPv6 link 🫶

3.4. The Binding Table 🦋

okay so any address in an LLN that's reachable from the backbone through the 6BBR function must be registered to that 6BBR, using an NS(EARO) with the R flag set [RFC8505] 💌. The 6BBR replies with an NA(EARO) and keeps track of the registration in an abstract Binding Table 📋.

An entry in the Binding Table is called a "Binding" 🎀. A Binding may be in Tentative, Reachable, or Stale state, and it's giving very much "the vibe shifts over time" 🌸.

The 6BBR uses a mix of [RFC8505] and IPv6 ND over the backbone to advertise the registration and avoid a duplication 🙈. If there are conflicting registrations, the 6BBRs sort it out on their own, so the Registering Nodes never even notice 🫶.

Only one 6LN may register a given address, but that address can be registered to multiple 6BBRs for higher availability 🧚. Iconic redundancy behavior 👑.

Over the LLN, here's how Binding Table management goes 💅:

  • De-registrations (newer TID, same ROVR, null Lifetime) are accepted with a status code of 4 ("Removed"), and the entry gets deleted 🗑️. Bye bye 👋.
  • Newer registrations (newer TID, same ROVR, non-null Lifetime) are accepted with a status code of 0 ("Success") ✨. The Binding gets updated with the new TID, the Registration Lifetime, and the Registering Node. If the Binding is in Tentative state, the EDAC response is held and may be overwritten. In other states, the Registration Lifetime timer restarts and the entry goes to 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 🥀. Not the freshest, sorry bestie.
  • 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") 🚫. Address already taken, periodt 💀.

The operation of the Binding Table is specified in detail in Section 9 📖.

3.5. Primary and Secondary 6BBRs 👑

A Registering Node MAY register the same address to more than one 6BBR 🫧. When it does, the Registering Node uses the same EARO in all the parallel registrations. On the other hand, 6LoWPAN ND has no provision for a 6LN (acting as Registered Node) to select its 6LBR (acting as Registering Node), so it can't select more than one either 🤷‍♀️. To make this work, NS(DAD) and NA messages with an EARO received over the backbone that indicate an identical Binding in another 6BBR (same Registered Address, same TID, same ROVR) are silently ignored, except for the purpose of selecting the primary 6BBR for that registration 🤫.

A 6BBR may be either primary or secondary 🌈. The primary is the 6BBR with the highest 64-bit Extended Unique Identifier (EUI-64) address out of all the 6BBRs that share a registration for the same Registered Address, with the same ROVR and same Transaction ID. The EUI-64 address is treated as an unsigned 64-bit integer 🔢. A given 6BBR can be primary for one address and secondary for another, regardless of whether or not those addresses belong to the same 6LN 🦋.

In the following sections, it is expected that an NA will be sent over the backbone only if the node is primary or doesn't support the concept of primary 🎯. More than one 6BBR claiming or defending an address creates unwanted traffic, but there's no reachability issue, since all 6BBRs provide reachability from the backbone to the 6LN ✨.

If a Registering Node loses connectivity to its 6BBR, or to one of the 6BBRs it registered an address with, it retries the registration to the (one or more) available 6BBR(s) 🔄. When it does that, the Registering Node MUST increment the TID. This forces the state to migrate to the new 6BBR, and it forces a reselection of the primary 6BBR if the lost node was the primary one 💅.

3.6. Using Optimistic DAD 🌟

ODAD [RFC4429] specifies how an IPv6 address can be used before DAD completes 🚀. The good news is that ODAD guarantees this behavior won't cause harm if the new address turns out to be a duplicate 🫶.

Supporting ODAD avoids delays in installing the Neighbor Cache Entry (NCE) in the 6BBRs and the default router, which gives the Registered Node immediate connectivity 🌸. As shown in Figure 3, if the 6BBR knows the LLA of a router, the 6BBR sends a Router Solicitation (RS) to the known router(s), using the Registered Address as the IP Source Address 📡. The RS is sent without an SLLAO, so it doesn't invalidate a preexisting NCE in the router 🙅‍♀️.

After ODAD, the router may send a unicast RA to the Registered Address, and it may resolve that address using an NS(Lookup) message 🔍. In response, the 6BBR sends an NA with an EARO and the Override flag [RFC4861] not set. The router can then figure out the freshest EARO when there are conflicting NA(EARO) messages, using the method described in Section 5.2.1 of [RFC8505] 🧠. If the NA(EARO) is the freshest answer, the default router creates a Binding with the SLLAO of the 6BBR (in Routing Proxy mode) or with that of the Registering Node (in Bridging Proxy mode), so traffic to and from the Registered Address can flow immediately 🎉.

The backbone and the federated LLN links are considered different links in the MLSN, even if multiple LLNs are attached to the same 6BBR 🧩. ND messages are link-scoped and aren't forwarded by the 6BBR between the backbone and the LLNs, though some packets may be reinjected in Bridging Proxy mode (see Section 8) 🔁.

Legacy nodes on the backbone expect the subnet to be deployed within a single link, with a common Maximum Transmission Unit (MTU) for intra-subnet communication: the Link MTU 📏. They won't perform the IPv6 Path MTU Discovery [RFC8201] for a destination within the subnet 🙃. That's why the MTU MUST have the same value on the backbone and on all federated LLNs in the MLSN 💯. As a consequence, the 6BBR MUST use the same MTU value in RAs over the backbone and in the RAs it transmits toward the LLN links 🫧.

A 6LBR can be deployed to serve the whole MLSN, as shown in Figure 4 🏰. It may be attached to the backbone, in which case it can be discovered through its capability advertisement (see Section 4.3 of [RFC8505]) in RA messages 🔎.

When a 6LBR is present, the 6BBR uses an EDAR/EDAC message exchange with the 6LBR to check whether the new registration is a duplication or a movement 🕵️‍♀️. This happens before the NS(DAD) process, which may be skipped if the 6LBR already maintains a conflicting state for the Registered Address ⏭️.

If the registration is a duplicate or isn't the freshest, the 6LBR replies with an EDAC message carrying a status code of 1 ("Duplicate Address") or 3 ("Moved"), respectively 🙅. If the registration is the freshest, the 6LBR replies with a status code of 0 ("Success") 🥇. In that case, if this registration is fresher than an existing registration for another 6BBR, the 6LBR also sends an asynchronous EDAC with a status code of 4 ("Removed") to the older 6BBR 💫.

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 Link-Layer Address Option (TLLAO) associated with the currently accepted registration. This lets a 6BBR find the new position of a mobile 6LN in the case of a Routing Proxy operation, and it opens the door for the 6LBR to act as a mapping server in the future 🗺️✨.

Note that if link-local addresses are registered, the scope of uniqueness used to check address duplication is the total collection of links the 6LBR serves, not just the single link where the link-local address is assigned 🔗💜.

Okay so on the backbone side 🌸 the 6BBR MUST join the SNMA group for a Registered Address as soon as it creates a Binding for that address, and it has to stay in that SNMA group for as long as it keeps the registration alive 🫶 The 6BBR can use either the SNMA or plain unicast to defend the Registered Addresses in its Binding Table over the backbone (as specified in [RFC4862]) 💅 It advertises and defends those addresses over the Backbone Link using RS, NS(DAD), and NA messages, with the Registered Address as the Source or Target Address.

The 6BBR MUST place an EARO in the IPv6 ND messages it generates on behalf of the Registered Node 🎀 Heads up 🙈 an NS(DAD) doesn't contain an SLLAO, so it can't get mixed up with a proxy registration like the ones a 6LBR does.

IPv6 ND works like this on the backbone:

  • Section 7.2.8 of [RFC4861] says that an NA message generated as a proxy does not have the Override flag set. The point is that if the real owner is on the link, its own NA takes precedence, and this NA doesn't update the NCE for the real owner if one exists 👑
  • A node that gets multiple NA messages only updates an existing NCE if the Override flag is set. Otherwise, it probes the cached address 🔍
  • When an NS(DAD) arrives for a tentative address (which means two nodes formed the same address at nearly the same time), the node that claimed the address first can't be detected per Section 5.4.3 of [RFC4862], and the address is abandoned 💀
  • Anyway, [RFC4862] says 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). In the movement case, the older registration gets sorted out from the fresher one by comparing TIDs ✨

When a Registering Node moves from one 6BBR to the next, the 6BBRs send NA messages over the backbone to update existing NCEs. A node that receives multiple NA messages with an EARO option and the same ROVR MUST favor the NA with the freshest EARO over the others 🦋

The new 6BBR MAY set the Override flag in the NA messages if it does not compete with the Registering Node for the NCE in backbone nodes. This is assured if the Registering Node is attached via an interface that cannot be bridged onto the backbone, which makes it impossible for the Registering Node to defend its own addresses there. This may also be signaled by the Registering Node through a protocol extension that is not in scope for this specification 🧚

When the Binding is in Tentative state, the 6BBR acts as follows:

  • 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 [RFC4862], respectively.

When the Binding is no longer in Tentative state, the 6BBR acts as follows:

  • 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") 😤

In any state, the 6BBR acts as follows:

  • 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 🧹

This behavior is specified in more detail in Section 9 📖

This specification enables proxy operation for the IPv6 ND resolution of LLN devices, and a prefix that is used across an MLSN MAY be advertised as on-link over the backbone. This is done for backward compatibility with existing IPv6 hosts by setting the L flag in the Prefix Information Option (PIO) of RA messages [RFC4861] 🍓

For movement involving a slow reattachment, the NUD procedure defined in [RFC4861] may timeout too quickly. Nodes on the backbone SHOULD support [RFC7048] whenever possible ⏱️

7. Routing Proxy Operations 🦋

A Routing Proxy provides IPv6 ND proxy functions for Global and Unique Local Addresses between the LLN and the backbone, but not for link-local addresses. It operates as an IPv6 border router and provides a full link-layer isolation 🏰

In this mode, it is not required that the link-layer addresses of the 6LNs be visible at Layer 2 over the backbone. So it's useful when the messaging over the backbone that is associated with wireless mobility gets expensive, e.g., when the Layer 2 topology is virtualized over a wide area IP underlay 💸

This mode is definitely required when the LLN uses a link-layer address format that is different from the one on the backbone (e.g., EUI-64 versus EUI-48). Since a 6LN may not be able to resolve an arbitrary destination in the MLSN directly, a prefix that is used across a MLSN MUST NOT be advertised as on-link in RA messages sent towards the LLN 🚫

In order to maintain IP connectivity, the 6BBR installs a connected host route to the Registered Address on the LLN interface, via the Registering Node as identified by the source address and the SLLAO in the NS(EARO) messages 🛤️

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 the TLLAO of the NA messages that it generates to advertise the Registered Addresses 🪪

For each Registered Address, multiple peers on the backbone may have resolved the address with the 6BBR link-layer address, maintaining that mapping in their Neighbor Cache. The 6BBR SHOULD maintain a list of the peers on the backbone that have associated its link-layer address with the Registered Address. If that Registered Address moves to another 6BBR, the previous 6BBR SHOULD unicast a gratuitous NA to each such peer, to supply the LLA of the new 6BBR in the TLLAO for the address 📬 A 6BBR that does not maintain this list MAY multicast a gratuitous NA message. This NA will possibly hit all the nodes on the backbone, whether or not they maintain an NCE for the Registered Address 📣 In either case, the 6BBR MAY set the Override flag if it is known that the Registered Node cannot attach to the backbone. This will avoid interruptions and save probing flows in the future 🙌

If a correspondent fails to receive the gratuitous NA, it will keep sending traffic to a 6BBR to which the node was previously registered. Since the previous 6BBR removed its host route to the Registered Address, it will look up the address over the backbone, 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 redirect message [RFC4861] to update the cache of the correspondent 🧭

8. Bridging Proxy Operations 💅

A Bridging Proxy provides IPv6 ND proxy functions between the LLN and the backbone while preserving the forwarding continuity at the link layer. It acts as a Layer 2 bridge for all types of unicast packets, including link-scoped ones, and it appears as an IPv6 Host on the backbone 🌉

The Bridging Proxy registers any Binding, including a link-local address, to the 6LBR (if present), and defends it over the backbone in IPv6 ND procedures 🛡️

To achieve this, the Bridging Proxy intercepts the IPv6 ND messages and may reinject them on the other side, respond directly, or drop them. For instance, an NS(Lookup) from the backbone that matches a Binding can be responded to directly, or turned into a unicast on the LLN side to let the 6LN respond 🎭

As a Bridging Proxy, the 6BBR MUST use the Registering Node's Layer 2 address in the SLLAO of the NS/RS messages and the TLLAO of the NA messages that it generates to advertise the Registered Addresses. The Registering Node's Layer 2 address is found in the SLLAO of the registration NS(EARO) and maintained in the Binding Table 🗂️

The MLSN prefix SHOULD NOT be advertised as on-link in 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 address. In that case, the 6BBR MUST either answer the NS(Lookup) message directly or reinject the message on the backbone, as either a Layer 2 unicast or a multicast 🔁

If the Registering Node owns the Registered Address, meaning that the Registering Node is the Registered Node, then its mobility does not impact existing NCEs over the backbone 🌷 In a network where proxy registrations are used, meaning that the Registering Node acts on 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 more correspondent nodes on the backbone might maintain a stale NCE, and packets to the Registered Address may be lost. When this condition happens, it is eventually discovered and resolved using NUD as defined in [RFC4861] 😭

9. Creating and Maintaining a Binding ✨

Okay bestie, so this is where the 6BBR actually makes a Binding 💖 When a registration comes in for a brand new address (that's an NS(EARO) with the R flag set 🎀), the 6BBR creates the Binding and runs as a 6LR following [RFC8505]. It also talks to the 6LBR if there's one 🫶

An implementation of a Routing Proxy that creates a Binding MUST also create an associated host route pointing to the Registering Node in the LLN interface from which the registration was received. 🌸

When the 6LR is acting as a 6BBR, its job gets a glow-up 💅 Here's what changes:

  • 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. 🔥

This specification lets nodes on a Backbone Link coexist with nodes implementing IPv6 ND [RFC4861], as well as other non-normative specifications such as [SAVI-WLAN]. Iconic behavior, honestly 👑 It's possible that not all IPv6 addresses on the backbone are registered and known to the 6LBR, and an EDAR/EDAC exchange with the 6LBR might succeed even for a duplicate address. 😭 So the 6BBR still needs to perform IPv6 ND DAD over the backbone after an EDAC with a status code of 0 ("Success") or 9 ("6LBR Registry Saturated"). Double-checking is the move 🧚

For the DAD operation, the Binding is placed in Tentative state for a duration of TENTATIVE_DURATION (Section 12). An NS(DAD) message is sent as a multicast message over the backbone to the SNMA associated with the Registered Address [RFC4862]. The EARO from the registration MUST be placed unchanged in the NS(DAD) message. 💜 No edits allowed, the EARO stays exactly as it arrived.

If a registration is received for an existing Binding with a non-null Registration Lifetime and the registration is fresher (same ROVR, fresher TID), then the Binding is updated with the new Registration Lifetime, TID, and possibly Registering Node. 🍓 In Tentative state (see Section 9.1), the current DAD operation continues unaltered. In other states (see Sections 9.2 and 9.3), the Binding is placed in Reachable state for the Registration Lifetime, and the 6BBR returns an NA(EARO) to the Registering Node with a status code of 0 ("Success"). ✨

Upon a registration that is identical (same ROVR, TID, and Registering Node), the 6BBR does not alter its current state. In Reachable state, it returns an NA(EARO) back to the Registering Node with a status code of 0 ("Success"). A registration that is not as fresh (same ROVR, older TID) is ignored. 🙈 Old news, bestie.

If a registration is received for an existing Binding and a Registration Lifetime of 0, then the Binding is removed, and the 6BBR returns an NA(EARO) back to the Registering Node with a status code of 0 ("Success"). An implementation of a Routing Proxy that removes a Binding MUST remove the associated host route pointing on the Registering Node. 🧹 Clean up after yourself!!

The old 6BBR removes its Binding Table entry and notifies the Registering Node with a status code of 3 ("Moved") if a new 6BBR claims a fresher registration (same ROVR, fresher TID) for the same address. 🦋 Bye bye, era over. The old 6BBR MAY preserve a temporary state in order to forward packets in flight. That state may be, for instance, an NCE that was formed when an NA message was received. It may also be a Binding Table entry in Stale state, pointing at the new 6BBR on the backbone, or any other abstract cache entry that can be used to resolve the link-layer address of the new 6BBR. 🌈 Packets in flight deserve a safe landing. The old 6BBR SHOULD also use REDIRECT messages pointing at the new 6BBR to update the correspondents of the Registered Address, as specified in [RFC4861]. 💅

9.1. Operations on a Binding in Tentative State

The Tentative state covers a DAD period over the backbone, during which an address being registered is checked for duplication using the procedures defined in [RFC4862]. It's the probation phase, lowkey 🧐

For a Binding in Tentative state:

  • 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 [RFC8928]). 🚫 Not you stealing someone's address!
  • 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 [RFC8928]). 💀
  • 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 [RFC8505] 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"). 🦋 Moving on, fresh start!
  • 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 [RFC8505] 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. 🙄 Not our problem.
  • 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. ✨ Speedy but still careful!

When the TENTATIVE_DURATION (Section 12) timer elapses, the Binding is placed in Reachable state for the Registration Lifetime, and the 6BBR returns an NA(EARO) to the Registering Node with a status code of 0 ("Success"). Main character moment 👑

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 sending an NA message with an EARO and the Override flag not set over the backbone (see Sections 7 and 8). 🧚 Glow-up for the whole network.

9.2. Operations on a Binding in Reachable State

The Reachable state covers an active registration after a successful DAD process. It's giving settled and secure 🌸

If the Registration Lifetime is of a long duration, an implementation might be configured to reassess the availability of the Registering Node at a lower period, using a NUD procedure as specified in [RFC7048]. If the NUD procedure fails, the Binding SHOULD be placed in Stale state immediately. 🔍 Checking the vibes regularly.

For a Binding in 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 [RFC8505] 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. ⏳ A little grace period, because timing is everything.
  • 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"). 🦋 Outdated, sorry not sorry.
  • 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. 🚫 Hard no on the copycat energy.
  • 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. 🧐

When the Registration Lifetime timer elapses, the Binding is placed in Stale state for a duration of STALE_DURATION (Section 12). Time to chill for a bit 🌙

9.3. Operations on a Binding in Stale State

The Stale state lets the 6BBR keep track of the backbone peers that have an NCE pointing to this 6BBR, in case the Registered Address shows up later. Memory like an elephant 🐘💜

If the Registered Address is claimed by another 6LN on the backbone, with an NS(DAD) or an NA, the 6BBR does not defend the address. Not my circus, not my monkeys 🙈

For a Binding in Stale state:

  • 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. 💀 Bye, bye, binding.
  • 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 [RFC7048] 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. 🔍 Prove you're still here, then we'll talk.
  • Other NS(DAD) and NA messages from the backbone are ignored. 🫶

When the STALE_DURATION (Section 12) timer elapses, the Binding MUST be removed. 🥀 And that's the end of the road for this one, periodt 💅

10. Registering Node Considerations ✨

okay so a Registering Node MUST implement [RFC8505] if it wants to talk to a 6BBR (the one acting as the Routing Registrar) 🫶 Following [RFC8505], the Registering Node tells the 6BBR "hey, I need IPv6 ND proxy services" by registering its IPv6 address with an NS(EARO) message that has the R flag set 🦋

The Registering Node can be the 6LN that owns the address, or it can be a 6LBR doing the registering on the 6LN's behalf in a route-over mesh 🌸

A 6LN MUST register all of its IPv6 addresses with its 6LR. When they're connected at Layer 2, that 6LR is the 6BBR 💅 If you skip registering an address, it might end up unreachable for other parties. 😭 For example, that happens if the 6BBR only passes the NS(Lookup) from the backbone to the LLN nodes that didn't register their addresses. Yikes!

The Registering Node MUST refrain from using multicast NS(Lookup) when the destination isn't known to be on-link. An example is when the prefix is advertised in a PIO with the L flag not set 🙈 In that situation, the Registering Node sends its packets straight to its 6LR. Main character behavior, no cap ✨

The Registering Node SHOULD also follow BCP 202 [RFC7772] to limit how much multicast RAs get used 🧚 It SHOULD also implement "Simple Procedures for Detecting Network Attachment in IPv6" [RFC6059] (the DNA procedures) so it can detect movement, and it can support "Packet-Loss Resiliency for Router Solicitations" [RFC7559] to make the unicast RS messages more reliable 🔥

11. Security Considerations 🔐

okay bestie, this section is serious, so get comfy 💀 The procedures in this document change the mechanisms used for IPv6 ND and DAD, and they should not affect other parts of IPv6 or higher-level-protocol operation. So the main attacks in play are the ones that try to block Neighbor Discovery or forcibly claim an address that another node is trying to use. Without cryptographic protection at higher layers, that second kind can be a huge deal, because the attacker can read all the "stolen" traffic that was headed to the target 😭

This specification applies to LLNs and a backbone where each individual link is protected against rogue access. On the LLN, a node that attaches to the network gets authenticated, and transmissions are encrypted at the link layer, both on the LLN side and the backbone side. This uses the physical security and access control measures that are usually applied there. So packets may neither be forged nor overheard 🛡️

In particular, the LLN link layer is required to provide secure unicast to and from the Backbone Router, and secure broadcast from the routers. It has to do this in a way that stops anyone from tampering with or replaying the ND messages 🫣

For the IPv6 ND operation over the backbone, unless classical ND is disabled (for example, by configuration), the classical ND messages are interpreted as coming from the address owner. They take precedence over the 6BBR, which is only a proxy 👑

So the security threats detailed in Section 11.1 of [RFC4861] fully apply to this specification too. Here's the tea:

  • 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 that has the Override bit set. The real owner then stops receiving its packets. 💀
  • Any node that can send a packet on the backbone can forge traffic and pretend it's coming from an address it doesn't own, even if it never claimed that address using ND. 🙈
  • Any node that can send a packet on the backbone can present itself as a preferred router to intercept all outgoing traffic on the subnet. It can even advertise 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 on all the intercepted traffic, by stealing an address or the role of a router. 👀

This means any rogue access to the backbone must be prevented at all times, and nodes attached to the backbone must be fully trusted and never compromised. No exceptions, periodt 💅

Using address registration as the sole ND mechanism on a link, and pairing it with [RFC8928], guarantees ownership of a Registered Address within that link ✨

  • The protection is based on a proof of ownership encoded in the ROVR field. It protects against address theft and impersonation by a 6LN, because the 6LR can challenge the Registered Node to prove ownership. 🦋
  • The protection covers the full LLN when the link is an LLN link. It does not extend over the backbone, though, because the 6BBR can't provide the proof of ownership when it defends the address. 🥺

There's also a possible attack over the backbone. The attacker sends an NS with an EARO and expects the NA(EARO) that comes back to contain the TID and ROVR fields of the existing state. With that info, the attacker can easily increase the TID and take over the Binding 😤

If classical ND is disabled on the backbone, and the use of [RFC8928] and a 6LBR are mandated, the network gets some awesome new perks 🌈

  • Zero-trust security for ND flows within the whole subnet: the extra security [RFC8928] provides on the LLN also applies to the backbone. It becomes impossible for an attached node to claim an address that belongs to another node using ND. The network can also filter packets that weren't 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 is known to the 6LBR and available to the default router. With that info, the router doesn't need to send a multicast NS(Lookup) when there's a Neighbor Cache miss for an incoming packet. That multicast is a source of remote DoS attacks against the network, so skipping it is iconic 🙌
  • 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 at detecting duplicates on large Wi-Fi infrastructures, because wireless broadcast is unreliable. Using a 6LBR enables a unicast lookup instead 📶
  • Less Layer 2 churn on the backbone: with the Routing Proxy approach, the link-layer addresses of the LLN devices and their mobility aren't visible on the backbone. Only the link-layer addresses of the 6BBR and backbone nodes are visible at Layer 2 there. This is mandatory for LLNs that can't be bridged on the backbone, and it's useful in any case to scale down and stabilize the forwarding tables at Layer 2. It also avoids the gratuitous frames that usually get broadcast to fix the transparent bridging tables when a wireless node roams from one AP to the next 🦋

This specification introduces a 6BBR, which is a router on the path of the LLN traffic, and a 6LBR, which is used for the lookup. Both could be juicy targets for an attacker 👀 A compromised 6BBR can accept a registration but then block the traffic or refrain from proxying. A compromised 6LBR may unduly accept a transfer of ownership of an address, or block a newcomer by faking that its address is a duplicate. But those attacks are also possible in a classical network from a compromised default router and a DHCP server, respectively, and they can be prevented using the same methods 🙌

A possible attack over the LLN can still happen by compromising a 6LR. A compromised 6LR may modify the ROVR of EDAR messages in flight and transfer 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 itself or to an attached 6LN. So 6LRs, as well as 6LBRs and 6BBRS, must still be fully trusted and never compromised 🫶

This specification mandates that the 6LBR on the backbone gets checked before the classical DAD runs, in case the address already exists. This may delay the DAD operation, so it should be protected by a short timer, on the order of 100 ms or less. That's only a small extra delay compared to the 1 s wait of the DAD operation ⏱️

12. Protocol Constants 🎀

this specification uses the following constant, no drama:

TENTATIVE_DURATION:  800 milliseconds

In LLNs with long-lived addresses, like Low-Power WAN (LPWANs), STALE_DURATION SHOULD be configured with a relatively long value. That covers the interval when an address might get reused, and before it's safe to assume the address was definitively released. A good default is 24 hours 🌙 In LLNs where addresses get renewed rapidly, e.g., for privacy reasons, STALE_DURATION SHOULD be configured with a relatively shorter value, which is 5 minutes by default ⭐

13. IANA Considerations 🧚

This document has no IANA actions. Nothing to register here, so IANA can take the day off 💜

14. Normative References ✨

okay bestie, these are the receipts 🧾 the spec leans on these to work, so they're the ones you actually need to read 💅

15. Informative References 🧚

these are the extra reads for the curious ones, the deep-dive playlist 🎀

Appendix A. Possible Future Extensions 🔮

okay so, with the current spec the 6LBR is NOT being leveraged to avoid multicast NS(Lookup) on the backbone 🙈 but it could be! the fix is adding a lookup procedure into the EDAR/EDAC exchange. future-us problem, but still iconic 💅

by default there's no fine-grained trust model, which is lowkey a vibe check. every node that can authenticate to the LLN link layer or attach to the backbone is equally trusted 😬 it would be SO desirable to have a stronger authorization model, like nodes that tie their address to a proof of ownership [RFC8928] getting more trust than nodes that don't ✨ that kind of trust model and its signaling could be added later to override the default and favor the trusted nodes. main character energy for the trusted ones 👑

as an alternate to the ND Proxy operation, the registration can be redistributed as a host route in a routing protocol that runs over the backbone 🦋 this is already happening in IoT networks [RPL-LEAVES] and Data Center Routing [RIFT], and it could be extended to other protocols too, like BGP [RFC4271] and OSPFv3 [RFC5340]. the registration may also get advertised in an overlay protocol such as Mobile IPv6 (MIPv6) [RFC6275], the Locator/ID Separation Protocol (LISP) [RFC6830], or Ethernet VPN (EVPN) [RFC7432] 🌈

Appendix B. Applicability and Requirements Served 🎀

so this part is about where all of this actually slays. this document specifies ND proxy functions that can be used to federate an IPv6 Backbone Link and multiple IPv6 LLNs into a single MLSN 🧚 the ND proxy functions enable IPv6 ND services for DAD and address lookup that do not require broadcasts over the LLNs. no broadcast drama, periodt 🙌

the term LLN covers a bunch of WLANs and WPANs, including (Low-Power) Wi-Fi, BLUETOOTH(R) Low Energy, IEEE Std 802.11ah and IEEE Std 802.15.4 wireless meshes, and the types of networks listed in "Requirements Related to Various Low-Power Link Types" (see Appendix B.3 of [RFC8505]) 📡

each LLN in the subnet is attached to a 6BBR 💖 the Backbone Routers interconnect the LLNs and advertise the addresses of the 6LNs over the Backbone Link using ND proxy operations ✨

this spec updates IPv6 ND over the backbone so it can tell address movement apart from duplication, and it gets rid of Stale state in the backbone routers and backbone nodes once a 6LN has roamed 🦋 so mobile nodes can roam rapidly from one 6BBR to the next, and the requirements are met per "Requirements Related to Mobility" (see Appendix B.1 of [RFC8505]). the roaming girlies are eating 🍓

a 6LN can register its IPv6 addresses and thereby get ND proxy services over the backbone, meeting the requirements expressed in "Requirements Related to Proxy Operations" (see Appendix B.4 of [RFC8505]. 🫶

the negative impact of the IPv6 ND-related broadcasts can be limited to one of the federated links, which means the number of 6LNs can grow 📈 the Routing Proxy operation avoids exposing the link-layer addresses of the 6LNs onto the backbone, keeping the Layer 2 topology simple and stable 🌸 this meets the requirements in "Requirements Related to Scalability" (see Appendix B.6 of [RFC8505]), as long as the 6BBRs are dimensioned for the number of registrations that each one needs to support. big if, big responsibility 💅

in the case of a Wi-Fi access link, a 6BBR may be collocated with the AP, a Fabric Edge (FE), or a Control and Provisioning of Wireless Access Points (CAPWAP) [RFC5415] Wireless LAN Controller (WLC) 🎀 in those cases, the wireless client (STA) is the 6LN that uses [RFC8505] to register its IPv6 address(es) to the 6BBR acting as the Routing Registrar. the 6LBR can be centralized and either connected to the Backbone Link or reachable over IP 🌐 the 6BBR ND proxy operations remove the need for wireless nodes to respond synchronously when a lookup is performed for their IPv6 addresses. that's literally the function of a Sleep Proxy for ND [DAD-APPROACHES] 😴

for the Time-Slotted Channel Hopping (TSCH) mode of [IEEEstd802154], the 6TiSCH architecture [6TiSCH] describes how a 6LoWPAN ND host could connect to the Internet via a RPL mesh network. but doing so needs extensions to the 6LOWPAN ND protocol to support mobility and reachability in a secure and manageable environment 🧐 the extensions detailed in this document also work for the 6TiSCH architecture, serving the requirements listed in "Requirements Related to Routing Protocols" (see Appendix B.2 of [RFC8505]) 🔥

the registration mechanism can be seen as a more reliable alternate to snooping [SAVI-WLAN] ✨ registration and snooping are not mutually exclusive though! snooping can be used alongside registration for nodes that don't register their IPv6 addresses, so it's a team effort 🫶 the 6BBR assumes that if a node registers at least one IPv6 address to it, then the node registers all of its addresses to the 6BBR. with that assumption, the 6BBR can possibly cancel all the undesirable multicast NS messages that would otherwise have been delivered to that node 🙈

scalability of the MLSN [RFC4903] requires avoiding multicast/broadcast operations as much as possible, even on the backbone [MCAST-PROBLEMS] 😭 hosts can connect to the backbone using IPv6 ND operations, but multicast RAs can be saved by using [RS-REFRESH], which also requires support of [RFC7559]. less noise, more slay 📢

Acknowledgments 🫶

many thanks to Dorothy Stanley, Thomas Watteyne, and Jerome Henry for their various contributions 💜 also, many thanks to Timothy Winters and Erik Nordmark for their help, review, and support in preparing for the IESG cycle, and to Kyle Rose, Elwyn Davies, Barry Leiba, Mirja Kühlewind, Alvaro Retana, Roman Danyliw, and especially Dominique Barthel and Benjamin Kaduk for their useful contributions through the IETF Last Call and IESG process 🌈 the whole squad showed up for this one ✨

Authors' Addresses 🖊️

Pascal Thubert (editor)
Cisco Systems, Inc.
Building D
45 Allee des Ormes - BP1200
06254 MOUGINS - Sophia Antipolis
France

Phone: +33 497 23 26 34
Email: pthubert@cisco.com


Charles E. Perkins
Blue Meadow Networking
Saratoga, CA 95070
United States of America

Email: charliep@computer.org


Eric Levy-Abegnoli
Cisco Systems, Inc.
Building D
45 Allee des Ormes - BP1200
06254 MOUGINS - Sophia Antipolis
France

Phone: +33 497 23 26 20
Email: elevyabe@cisco.com
📦 where this page comes from