IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging
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 Lossy Networks (LLNs) and local wireless networks generally
do not provide the broadcast capabilities of Ethernet Bridging in an
As a result, protocols designed for bridged networks that rely
on multicast and broadcast often exhibit disappointing behaviours
when employed unmodified on a local wireless medium (see
Wi-Fi [IEEEstd80211] Access Points (APs)
deployed in an Extended Service Set (ESS) act as Ethernet Bridges
[IEEEstd8021], with the property that the bridging
state is established at the time of association. This ensures
connectivity to the end node (the Wi-Fi STA) and protects the wireless medium
against broadcast-intensive Transparent Bridging reactive Lookups.
In other words, the association process is used to register the MAC
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, IPv6 [RFC8200]
Neighbor Discovery [RFC4861] [RFC4862]
Protocol (IPv6 ND) 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) [RFC4862] was designed for
the efficient broadcast operation of Ethernet Bridging.
Since broadcast can be unreliable over wireless media, DAD often
fails to discover duplications
[I-D.yourtchenko-6man-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 succesful operation of the IPv6 ND duplicate address detection and resolution mechanisms.¶
The IPv6 ND Neighbor Solicitation (NS) [RFC4861] 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) [RFC4291] 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, and 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 and/or a LowPower Lossy Network (LLN) can consume enough
bandwidth to cause a substantial degradation to the unicast traffic
Because IPv6 ND messages sent to the SNMA group are broadcast at the
radio MAC 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 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 by assigning
a /64 prefix to each wireless node (see [RFC8273]).
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, 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, 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 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 [RFC8505] that provides proxy-ND services.
A 6BBR acting as a Bridging Proxy provides a proxy-ND function with Layer-2 continuity and can be
collocated with a Wi-Fi Access Point (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 for can be obtained by snooping the
IPV6 ND protocol (see [I-D.bi-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 its IPv6 Addresses using NS messages with an Extended Address Registration Option (EARO) as specified in [RFC8505] 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 Neighbor Discovery (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 to it as unicast the corresponding multicast packets.¶