Ethernet bridging per IEEE Std 802.1 [IEEEstd8021Q
] provides an efficient and reliable broadcast service for wired networks; applications and protocols have been built that heavily depend on that feature for their core operation. Unfortunately, Low-Power and Lossy Networks (LLNs) and local wireless networks generally do not provide the broadcast capabilities of Ethernet bridging in an economical fashion.
As a result, protocols designed for bridged networks that rely on multicast and broadcast often exhibit disappointing behaviors when employed unmodified on a local wireless medium (see [MCAST-PROBLEMS
] Access Points (APs) deployed in an Extended Service Set (ESS) act as Ethernet bridges [IEEEstd8021Q
], with the property that the bridging state is established at the time of association. This ensures connectivity to the end node (the Wi-Fi Station (STA)) and protects the wireless medium against broadcast-intensive transparent bridging [IEEEstd8021Q
] reactive lookups. In other words, the association process is used to register the link-layer address of the STA to the AP. The AP subsequently proxies the bridging operation and does not need to forward the broadcast lookups over the radio.
In the same way as transparent bridging, the IPv6 [RFC 8200
] Neighbor Discovery (IPv6 ND) protocol [RFC 4861
] [RFC 4862
] is a reactive protocol, based on multicast transmissions to locate an on-link correspondent and ensure the uniqueness of an IPv6 address. The mechanism for Duplicate Address Detection (DAD) [RFC 4862
] was designed for the efficient broadcast operation of Ethernet bridging. Since broadcast can be unreliable over wireless media, DAD often fails to discover duplications [DAD-ISSUES
]. In practice, the fact that IPv6 addresses very rarely conflict is mostly attributable to the entropy of the 64-bit Interface IDs as opposed to the successful operation of the IPv6 ND DAD and resolution mechanisms.
The IPv6 ND Neighbor Solicitation (NS) [RFC 4861
] message is used for DAD and address lookup when a node moves or wakes up and reconnects to the wireless network. The NS message is targeted to a Solicited-Node Multicast Address (SNMA) [RFC 4291
] and should, in theory, only reach a very small group of nodes. But, in reality, IPv6 multicast messages are typically broadcast on the wireless medium, so they are processed by most of the wireless nodes over the subnet (e.g., the ESS fabric) regardless of how few of the nodes are subscribed to the SNMA. As a result, IPv6 ND address lookups and DADs over a large wireless network and/or LLN can consume enough bandwidth to cause a substantial degradation to the unicast traffic service.
Because IPv6 ND messages sent to the SNMA group are broadcast at the radio link layer, wireless nodes that do not belong to the SNMA group still have to keep their radio turned on to listen to multicast NS messages, which is a waste of energy for them. In order to reduce their power consumption, certain battery-operated devices such as Internet of Things (IoT) sensors and smartphones ignore some of the broadcasts, making IPv6 ND operations even less reliable.
These problems can be alleviated by reducing the IPv6 ND broadcasts over wireless access links. This has been done by splitting the broadcast domains and routing between subnets. At the extreme, this can be done by assigning a /64 prefix to each wireless node (see [RFC 8273
]). But deploying a single large subnet can still be attractive to avoid renumbering in situations that involve large numbers of devices and mobility within a bounded area.
A way to reduce the propagation of IPv6 ND broadcast in the wireless domain while preserving a large single subnet is to form a Multi-Link Subnet (MLSN). Each link in the MLSN, including the backbone, is its own broadcast domain. A key property of MLSNs is that link-local unicast traffic, link-scope multicast, and traffic with a hop limit of 1 will not transit to nodes in the same subnet on a different link, which is something that may produce unexpected behavior in software that expects a subnet to be entirely contained within a single link.
This specification considers a special type of MLSN with a central backbone that federates edge (LLN) links, with each link providing its own protection against rogue access and tempering or replaying packets. In particular, the use of classical IPv6 ND on the backbone requires that the all nodes are trusted and that rogue access to the backbone is prevented at all times (see Section 11
In that particular topology, ND proxies can be placed at the boundary of the edge links and the backbone to handle IPv6 ND on behalf of Registered Nodes and to forward IPv6 packets back and forth. The ND proxy enables the continuity of IPv6 ND operations beyond the backbone and enables communication using Global or Unique Local Addresses between any pair of nodes in the MLSN.
The 6LoWPAN Backbone Router (6BBR) is a Routing Registrar [RFC 8505
] that provides ND proxy services. A 6BBR acting as a Bridging Proxy provides an ND proxy function with Layer 2 continuity and can be collocated with a Wi-Fi AP as prescribed by IEEE Std 802.11 [IEEEstd80211
]. A 6BBR acting as a Routing Proxy is applicable to any type of LLN, including LLNs that cannot be bridged onto the backbone, such as IEEE Std 802.15.4 [IEEEstd802154
Knowledge of which address to proxy can be obtained by snooping the IPv6 ND protocol (see [SAVI-WLAN
]), but it has been found to be unreliable. An IPv6 address may not be discovered immediately due to a packet loss or if a "silent" node is not currently using one of its addresses. A change of state (e.g., due to movement) may be missed or misordered, leading to unreliable connectivity and incomplete knowledge of the state of the network.
With this specification, the address to be proxied 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 [RFC 8505
] to a 6LoWPAN Router (6LR) to which it is directly attached. If the 6LR is a 6BBR, then the 6LN is both the Registered Node and the Registering Node. If not, then the 6LoWPAN Border Router (6LBR) that serves 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 performs IPv6 ND operations on its backbone interface on behalf of the 6LNs that have Registered Addresses on its LLN interfaces, without the need of a broadcast over the wireless medium.
A Registering Node that resides on the backbone does not register to the SNMA groups associated to its Registered Addresses and defers to the 6BBR to answer or preferably forward the corresponding multicast packets to it as unicast.