6lo P. Thubert, Ed.
Internet-Draft Cisco Systems
Updates: 4861, 8505 (if approved) C. Perkins
Intended status: Standards Track Futurewei
Expires: June 8, 2019 E. Levy-Abegnoli
Cisco Systems
December 5, 2018

IPv6 Backbone Router


Backbone Routers are RFC8505 Routing Registrars that provide proxy services for IPv6 Neighbor Discovery. Backbone Routers federate multiple wireless Links over a Backbone Link to form a MultiLink Subnet. Backbone Routers placed along the wireless edge of the Backbone handle IPv6 Neighbor Discovery, and route packets on behalf of registered nodes.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on June 8, 2019.

Copyright Notice

Copyright (c) 2018 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 of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Introduction

IEEE STD. 802.1 Ethernet Bridging provides an efficient and reliable broadcast service; 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 economical fashion; protocols designed for bridged networks that rely on multicast and broadcast often exhibit disappointing behaviours when employed unmodified on a local wireless medium (see [I-D.ietf-mboned-ieee802-mcast-problems]).

Wi-Fi Access Points (APs) deployed in an Extended Service Set (ESS) act as Ethernet Bridges [IEEEstd8021], with the interesting caveat that the bridging state is populated proactively at the association time. This ensures a solid connectivity to the node (STA) and protects the wireless medium against the 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 APs subsequently proxies the bridging operation and does not need to forward the broadcast lookups over the radio.

Like Transparent Bridging, the operations of the IPv6 [RFC8200] Neighbor Discovery [RFC4861] [RFC4862] Protocol (IPv6 ND) are reactive and rely heavily on multicast transmissions to locate an on-link correspondent and ensure the uniqueness of an Address. The mechanism for Duplicate Address Detection (DAD) [RFC4862] was also designed as a natural match with the efficient broadcast operation of Ethernet Bridging. However, since broadcast can be unreliable over wireless media, DAD often fails to discover duplications [I-D.yourtchenko-6man-dad-issues]. A conflict of IPv6 Address is still a very rare event, not because Address duplications are detected and solved as designed, but because of the sheer entropy of the 64-bit Interface IDs.

IPv6 multicast messages are typically broadcast over the wireless medium; they are processed by most if not all the wireless nodes over the subnet - e.g., the ESS fabric - even when very few if any of the nodes is subscribed to the multicast flow. The IPv6 ND Neighbor Solicitation (NS) [RFC4861] is such a message; NS messages are used for DAD and Address lookup, and are frequently observed in a situation of mobility and when a node wakes up and reconnects to the wireless network. The NS message is targeted to a Sollicitated-Node Multicast Address (SNMA) [RFC4291] and should in theory only reach a very small group of nodes; but since Layer-3 multicast messages are effectively broadcasted at Layer-2, the volume of Address lookups and DADs over a large fabric can effectively consume bandwidth to the point that it becomes detrimental to unicast traffic (see [I-D.ietf-mboned-ieee802-mcast-problems]).

Additionally, wireless nodes that do not belong to the SNMA group still have to keep their radio awake and listen to broadcasted NS messages, which is a total waste of energy for them. In order to control their power consumption, battery-operated nodes such as IOT sensors and smartphones may then elect to blindly ignore a portion of the broadcasts, which tends to make the Layer-3 protocol operations even less reliable.

These problems can be alleviated by a reduction of IPv6 ND broadcasts over wireless access links. One classical way to achieve this to split the broadcast domains and route between subnets, possibly by assigning a /64 prefix to each wireless node (see [RFC8273]).

Another way is to proxy the Layer-3 protocols that rely on broadcast operations at the boundary of the wired and wireless domains, in a fashion similar to the Layer-2 association but at layer-3. To that effect, IEEE 802.11 requires ARP and proxy-ND [RFC4389] services at the Access Points (APs), and this specification is a possible response to that requirement.

IPv6 proxy-ND services can be obtained automatically by snooping the IPV6 ND protocol (see [I-D.bi-savi-wlan]). Proprietary techniques for IPv6 ND and DHCP snooping are effectively deployed, and though snooping is really useful to cancel undesirable broadcast transmissions, it has also proven to be unreliable; An IPv6 Address may not be discovered immediately due to a packet loss, or a silent node that does not use the Address for a while; a change of state (e.g. due a movement) may be missed or misordered, leading to unreliable connectivity and a partial knowledge of the state of the network.

With this specification, a wireless node proactively registers its IPv6 Addresses using a NS(EARO) as specified in [RFC8505] to an IPv6 Backbone Router (6BBR). The 6BBR is a Routing Registrar per [RFC8505]. It is also a Border Router that performs the IPv6 proxy Neighbor Discovery operations on its Backbone interface on behalf of the 6LNs that are registered on its LLN interfaces. This effectively recreates at Layer-3 the equivalent of an association such as found in IEEE STD. 802.11 for the purpose of providing reachability to the registered Addresses without the need of a broadcast lookup over the wireless medium. Additional benefits are discussed in Appendix A.

2. Terminology

2.1. BCP 14

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.

2.2. References

In this document, readers will encounter terms and concepts that are discussed in the following documents:

2.3. New Terms

This document also introduces the following terminology:


A subnet that is partitionned over a Backbone and one or more (wireless) access links, is said to be federated into one MultiLink Subnet by the proxy-ND operation of 6BBRs located at the edge of the Backbone and the access links and providing a semblance of a non-partitionned subnet for IPv6 ND over the Backbone.
Sleeping Proxy

A 6BBR acts as a Sleeping Proxy if it answers ND Neighbor Solicitation over the Backbone on behalf of the Registered Node.
Unicasting Proxy

A Unicasting Proxy forwards NS messages to the Registering Node, transforming Layer-2 multicast into unicast.
Routing Proxy

A Routing Proxy advertises its own MAC Address as the TLLA in the proxied NAs over the Backbone, as opposed to that of the node that performs the registration.
Bridging Proxy

A Bridging Proxy advertises the MAC Address of the node that performs the registration as the TLLA in the proxied NAs over the Backbone. In that case, the MAC Address and the mobility of 6LN is still visible across the bridged Backbone fabric.
Primary 6BBR

The 6BBR that will defend a Registered Address for the purpose of DAD over the Backbone.
Secondary 6BBR

A 6BBR other than the Primary 6BBR to which an Address is registered. A Secondary Router MAY advertise the Address over the Backbone and proxy for it.

2.4. Acronym Definitions

This document uses the following acronyms:

6LoWPAN Backbone Router
6LoWPAN Border Router
6LoWPAN Node
6LoWPAN Router
Capability Indication Option
(Extended) Address Registration Option -- (E)ARO
(Extended) Duplicate Address Request -- (E)DAR
(Extended) Duplicate Address Confirmation -- (E)DAC
Duplicate Address Detection
Destination-Oriented Directed Acyclic Graph
Low-Power and Lossy Network
Neighbor Advertisement
Neighbor Cache Entry
Neighbor Discovery
Neighbor Discovery Protocol
Neighbor Solicitation
Registration Ownership Verifier (pronounced rover)
IPv6 Routing Protocol for LLNs (pronounced ripple) [RFC6550]
Router Advertisement
Router Solicitation
Transaction ID (a sequence counter in the EARO)

3. Overview

A 6BBR provides proxy-ND services to 6LNs attached to an LLN that is anchored at the 6BBR; this way, a subnet that is located on a Backbone can be extended in the LLN as a MultiLink Subnet. The LLN may be a hub-and-spoke network, a mesh-under or a route-over network.

The proxy-ND operation can co-exist with IPv6 ND over the Backbone. The proxy state can be distributed across multiple 6BBR attached to a same Backbone. A 6LN may move freely from an LLN anchored at one 6BBR to an LLN anchored at another 6BBR on the same Backbone and retain any or all of the IPv6 Addresses that the 6LN has formed.

The registration to a proxy service is done via a NS/NA(EARO) exchange. The 6BBR operation resembles that of a Mobile IPv6 (MIPv6) Home Agent. The combination if a 6BBR and a MIPv6 HA enables a full mobility support for 6LNs, inside and outside the links that form the subnet.

            |     | Gateway (default) Router
            |     |
               |           Backbone Link
         |                         |                      |
      +------+                 +------+                +------+
      | 6BBR |                 | 6BBR |                | 6BBR |
      |      |                 |      |                |      |
      +------+                 +------+                +------+
         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                        LLN                      LLN


Figure 1: Backbone Link and Backbone Routers

Each Backbone Router (6BBR) maintains an abstract Binding Table of its Registered Nodes. The Binding Tables form a distributed database of 6LNs that reside on the LLNs or on the IPv6 Backbone, and use an extension to IPv6 ND to exchange that information across the Backbone. In that process:

3.1. Access Link

This specification also applies to (hub-and-spoke) Access Links such as (Low-Power) IEEE STD. 802.11 (Wi-Fi) [IEEEstd80211] and IEEE STD. 802.15.1 (Bluetooth) [IEEEstd802151]. Figure 2 illustrates an ODAD-complient (see Section 3.8) example of a 6LN that forms an IPv6 Address and registers it to a 6BBR acting as a 6LR [RFC8505].

    6LoWPAN Node        6BBR          6LBR            default     
       (STA)            (AP)                           Router
         |(Wireless) LLN |       IPv6 ND Backbone        |
         |               |         (Ethernet)            | 
         |       RS      |              |                |
         |-------------->|              |                |
         |  (multicast)  |              |                | 
         |               |              |                | 
         |  RA(PIO)      |              |                |
         |<--------------|              |                |
         | (L2 unicast)  |              |                |
         |               |              |                |
         |  NS(EARO)     |              |                |
         |-------------->|              |                |
         | (optimistic)  |              |                | 
         |               | Extended DAR |                |
         |               |------------->|                |
         |               | Extended DAC |                |
         |               |<-------------|                |
         |               |         NS-DAD(EARO)          |
         |               |------------------------------>| 
         |               |------->   (multicast)         | 
         |               |--------------------->         | 
         |               |   RS(no SLLAO, for ODAD)      |
         |               |------------------------------>|
         |               |   (if no BCE) NS-LOOKUP       |
         |               |<------------------------------|
         |               |    NA(SLLAO, not(O), EARO)    |
         |               |------------------------------>|
         |               |         RA(unicast)           |
         |               |<------------------------------|
         |               |              |                | 
         |         IPv6 Packets in optimistic mode       |
         |               |              |                | 
         |  NA(EARO)     |DAD <timeout> |                |
         |<--------------|              |                |
         |               |              |                |

Figure 2: Initial Registration Flow to a 6BBR acting as Routing Proxy

3.2. Route-Over Mesh

In the case of a Route-Over Mesh, e.g., using RPL [RFC6550], the 6TiSCH architecture suggests to collocate the RPL root with a 6LoWPAN Border Router (6LBR), which is either collocated with or connected to the 6BBR over an IPv6 Link.

Figure 3 illustrates the initial IPv6 signaling that enables a 6LN to form a Global or a Unique-Local Address and register it to the 6LBR using [RFC8505]. The 6LBR also leverages [RFC8505] to register the 6LNs on their behalf to the 6BBR and obtain proxy-ND services.

    6LoWPAN Node        6LR             6LBR            6BBR
    (mesh leaf)     (mesh router)   (mesh root)
         |               |               |               |
         |  6LoWPAN ND   |6LoWPAN ND+RPL | 6LoWPAN ND    | IPv6 ND
         |   LLN link    |Route-Over mesh|Ethernet/serial| Backbone
         |               |               |/Internal call | 
         |  IPv6 ND RS   |               |               |
         |-------------->|               |               |
         |----------->   |               |               |
         |------------------>            |               |
         |  IPv6 ND RA   |               |               |
         |<--------------|               |               |
         |               |    <once>     |               |
         |  NS(EARO)     |               |               |
         |-------------->|               |               |
         | 6LoWPAN ND    | Extended DAR  |               |
         |               |-------------->|               |
         |               |               |  NS(EARO)     |
         |               |               |-------------->|
         |               |               |  (proxied)    | NS-DAD
         |               |               |               |------>
         |               |               |               | (EARO)
         |               |               |               | 
         |               |               |  NA(EARO)     |<timeout>
         |               |               |<--------------|
         |               | Extended DAC  |               |
         |               |<--------------|               |
         |  NA(EARO)     |               |               |
         |<--------------|               |               |
         |               |               |               |

Figure 3: Initial Registration Flow over Route-Over Mesh

3.3. MultiLink Subnet Consistency

The Backbone and the federated LLN Links are considered as different Links in the MultiLink Subnet, even if multiple LLNs are attached to a same 6BBR. Multicast ND messages are link-scoped and MUST NOT be forwarded across the Backbone Routers.

A prefix that is used across a MultiLink Subnet may still be advertised as on-link over the Backbone, by setting the "L" bit in the Prefix Information Option (PIO) in RA messages ([RFC4861]), in order to support classical IPv6 hosts; but the MultiLink Subnet prefix MUST be advertised as not-onlink in RAs sent towards the LLN.

Nodes located inside the subnet will not perform the IPv6 Path MTU Discovery [RFC8201] between one another. For that reason, the MTU must have a same value on the Backbone and all attached LLNs. To achieve this, the 6BBR MUST use the same MTU value that is used in RAs over the Backbone in the RAs that it transmits towards the LLN links.

3.4. Registering Node

A Registering Node MUST implement [RFC6775] as updated by [RFC8505] in order to interact with a 6BBR. As such, it does not depend on multicast RAs to discover the 6LR(s).

The Registering Node MUST accept multicast RAs, but those are expected to be rare within in the LLN is the best practices ([RFC7772]) are followed.

The Registering Node SHOULD comply with the Simple Procedures for Detecting Network Attachment in IPv6 (DNA procedures) to assert movements, and support Packet-Loss Resiliency for Router Solicitations in order to make the unicast RS messages more reliable.

The Registering Node signals that it requires IPv6 proxy-ND services from a 6BBR by registering the corresponding IPv6 Address with an NS(EARO) message with the 'R' flag set ([RFC8505]). It may be the actual owner of the IPv6 Address or a 6LBR that performs the registration on its behalf in a Route-Over mesh.

The Registering Node SHOULD register all of its Global Unicast and Unique-Local IPv6 Addresses to the 6BBRs. Failure to register a subset of Addresses may result in those Addresses being unreachable by other parties if the 6BBR cancels the NS(LOOKUP) over the LLN or to selected LLN nodes that are known to register their addresses.

3.5. Using IPv6 ND Over the Backbone Link

On the Backbone side, the 6BBR MUST join the SNMA group that corresponds to a Registered Address as soon as it creates an entry for that Address, and conserve its SNMA membership as long as it maintains the associated entry. The 6BBR uses either the SNMA or plain unicast to defend the Registered Addresses in its Binding Table over the Backbone.

The 6BBR advertises and defends the Registered Addresses over the Backbone using the IPv6 ND protocol [RFC4861]. It MUST uses an EARO in the NS(DAD) and NA messages that it generates over the Backbone Link for the Registered Address. A NA message generated in response to a NS(LOOKUP) MUST NOT have the override (O) bit set. A proxied NS MUST NOT contain an SLLAO to avoid the confusion with a registration.

A 6BBR may asynchronously update the NCEs in correspondent nodes over the Backbone, e.g., in case of a movement. This is achieved using a gratuitous NA with the override (O) bit set, that may be sent unicast to each individual correspondent, or multicast to all nodes (more in Section 3.7 and Section 3.6).

A 6LBR may optionally be deployed over the Backbone. When that is the case, the 6BBR uses an EDAR/EDAC echange to check for duplication or movement as prescribed in [RFC8505]. If this registration is duplicate or not the freshest, then the 6LBR replies with a status code of 1 ("Duplicate Address") or 3 ("Moved"), respectively. If this registration is the freshest, then the 6LBR replies with a status code of 0; in that case, if there was an existing registration on an old 6BBR, then the 6LBR also sends an asynchronous EDAC with a status of 4 ("Removed") to the old 6BBR. Note that an alternate protocol such as LISP may be used to provide an equivalent service.

Nodes implementing this specification is expected to co-exist on a same Backbone Link with nodes implementing classical IPv6 ND [RFC4861] and snooping [I-D.bi-savi-wlan]. It results that the fact that there is a 6LBR or an alternate protocol that is deployed on the Backbone does not mean that all IPv6 addresses are known there; the fact that a unicast DAD succeeds with the 6LBR does not mean that the address is not duplicate, and, unless administratively overridden, 6BBRs must still perform classical IPv6 ND DAD after an EDAC with a status code of 0.

For slow movements, the Neighbor Unreachability Detection (NUD) procedure defined in [RFC4861] may time out too quickly, and the support of [RFC7048] is recommended for all nodes in the subnet.

3.6. Routing Proxy Operations

When operating as a Routing Proxy, the 6BBR MUST use the Layer-2 Address on its Backbone Interface in the TLLA and SLLA options, when present, of the RS, NS and NA messages that it generates to advertise the Registered Addresses. In that case, the MAC Addresses of the 6LNs do not need to be visible at Layer-2 over the Backbone to maintain end-to-end IP connectivity, but the NCEs of the correspondents must be updated when the owner registers to a different 6BBR.

This technique is useful when the churn on the Backbone fabric associated to wireless mobility becomes expensive, e.g., when the Layer-2 topology is virtualized over a wide area IP underlay. 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 SLLA option in the NS(EARO) messages.

This technique is also useful when the LLN uses a MAC address format that is different from that on the Backbone (e.g., EUI-64 vs. EUI-48).

For each Registered Address, multiple peer Nodes on the Backbone may have resolved the Address with the 6BBR MAC Address, maintaining that mapping in their Neighbor cache. The 6BBR SHOULD maintain a list of the peers on the Backbone which have associated its MAC Address with the Registered Address. If that Registered Address moves from an old to a new 6BBR, the old 6BBR SHOULD unicast a gratuitous NA with the Override (O) bit set to each such peer, to supply the LLA of the new 6BBR in the TLLA option for the Address.

If the 6BBR fails to maintain this list, then it MAY send the gratuitous NA with the Override (O) bit set as a multicast message that will possibly hit all the nodes on the Backbone, whether they maintain an NCE or not for the Registered Address.

If a correspondent fails to receive the gratuitous NA, it will keep sending traffic to a 6BBR to which the node was previously registered. That old 6BBR having removed its host route to the Registered Address, it will look it up over the backbone, resolve the with the LLA of the new 6BBR, and forward the packet to the correct 6BBR. The old 6BBR SHOULD also issue a redirect message [RFC4861] is order to update the cache of the correspondent.

3.7. Bridging Proxy Operations

A Bridging Proxy can be implemented in a Layer-3 switch, or in a wireless Access Point or wireless Controller that acts as a Layer-2 Bridge for unicast packets from/to the Registered Address. The Bridging Proxy appears as an IPv6 Host on the Backbone whereas the Routing Proxy described in Section 3.6 is an IPv6 router operating as a border router between Links of a MultiLink Subnet.

When operating as a Bridging Proxy, the 6BBR MUST use the Registering Node's Layer-2 Address in the TLLA and SLLA options, when present, of, respectively, the RS, NS and NA messages that it generates to advertise the Registered Addresses. The Registering Node's Layer-2 address is found in the SLLA of the registration NS(EARO), and maintained in the abstract Binding Table.

If the Registering Node is the owner of the Registered Address, then its mobility does not impact existing NCEs over the Backbone. If it is not, then when the 6LN selects another Registering Node, the new Registering Node SHOULD send a multicast NA with the Override (O) bit set to fix the existing NCEs across the Backbone. This method may fail if the multicast message is not received, in which case one or more correspondent nodes on the Backbone may maintain an obsolete NCE and traffic to the Registered Address may be lost for a while. When this condition happens, it is eventually be discovered and solved through the Neighbor Unreachability Detection (NUD) procedure defined in [RFC4861].

3.8. Leveraging Optimistic DAD

The Optimistic Duplicate Address Detection (ODAD) specification details how an IPv6 Address can be used before a Duplicate Address Detection (DAD) is complete.

ODAD provides a set of rules that guarantee that this behavior may not harm an existing state should the new Address effectively be a duplicate. This specification leverages ODAD to avoid delays in installing the Neighbor Cache Entry (NCE) in the 6BBRs and the default router in order to obtain immediate connectivity to the registered node.

This specification RECOMMENDS to support ODAD to create an optimistic proxy state in the 6BBR until DAD is completed over the Backbone. As shown in Figure 2, if the 6BBR is aware of the Link-Layer Address (LLA) of a router, then the 6BBR sends a Router Sollicitation (RS), sourced with the Registered Address, to the known router(s). The RS MUST be sent without a Source LLA Option (SLLAO), to ensure that a preexisting NCE in the router is not affected.

Following the ODAD flows, the router may then send a unicast RA to the Registered Address, and in the process of doing so, it may resolve it using an NS(LOOKUP) message. In response, the 6BBR sends a NA with the override (O) bit that is not set (per [RFC4429]), and an EARO option. If the router supports this specification, then it can determine the freshest EARO option in case of a conflicting NA(EARO) messages, using section 5.2.1 of [RFC8505]. If the NA(EARO) is the freshest or only answer then the default router creates a BCE with the SLLAO of the 6BBR (in Routing Proxy mode) or that of the Registering Node (in Bridging Proxy mode) and traffic from/to the Registered Address can flow immediately.

4. Updating RFC 4861

This specification adds the EARO as a possible option in RS, NS(DAD) and NA messages over the backbone. Note that [RFC8505] requires that the registration NS(EARO) contains an SLLAO. Note that an NS(DAD) does not contain an SLLAO and thus cannot be confused with a registration.

5. Updating RFC 8505

This specification adds the capability to insert IPv6 ND options in the EDAR and EDAC messages. In particular, a 6BBR acting as a 6LR for the Registered Address can insert an SLLAO in the EDAR to the 6LBR in order to avoid a lookup back.

6. 6BBR detailed Operations

By default, a 6BBR operates as a Sleeping Proxy, as follows:

A 6BBR may act as a Sleeping Proxy only for a Registered Address that is REACHABLE, or TENTATIVE in which case the answer is delayed. In any other state, the Sleeping Proxy operates as a Unicasting Proxy.

The 6BBR does not act on ND Messages over the Backbone unless they are relevant to a Registered Node on the LLN side, saving wireless interference. On the LLN side, the prefixes associated to the MultiLink Subnet are presented as not on-link, so Address resolution for other hosts do not occur.

As a Unicasting Proxy, the 6BBR forwards NS lookup messages to the Registering Node, transforming Layer-2 multicast into unicast. This is not possible in UNREACHABLE state, so the NS messages are multicasted, and rate-limited. Retries are possible, using an exponential back-off to protect the medium. In other states, the messages are forwarded to the Registering Node as unicast Layer-2 messages. In TENTATIVE state, the NS message is either held till DAD completes, or dropped if DAD does not complete.

6.1. Primary and Secondary 6BBRs

A 6BBR MAY be primary or secondary. The primary is the Backbone router that has the highest EUI-64 Address of all the 6BBRs that share a registration for a same Registered Address, with the same ROVR and same Transaction ID, the EUI-64 Address being considered as an unsigned 64bit integer. A given 6BBR can be primary for a given Address and secondary for another Address, regardless of whether or not the Addresses belong to the same 6LN. The primary Backbone Router is in charge of protecting the Address for DAD over the Backbone. Any of the Primary and Secondary 6BBR may claim the Address over the Backbone, since they are all capable to route from the Backbone to the 6LN; the Address appears on the Backbone as an anycast Address.

6.2. Binding Table

Each 6BBR maintains a Binding Table, using IPv6 ND over the Backbone to detect duplication. Another document [RFC8505] provides details about how the EARO is used between 6LRs and 6LBRs by way of DAR/DAC messages within the LLN. Addresses in a LLN that can be reachable from the Backbone by way of a 6BBR MUST be registered to that 6BBR.

A false positive duplicate detection may arise over the Backbone, for instance if a 6LN's Registered Address is registered to more than one LBR, or if the 6LN has moved. Both situations are handled by the 6BBR transparently to the 6LN. In the former case, one LBR becomes primary to defend the Address over the Backbone while the others become secondary and may still forward packets. In the latter case the LBR that receives the newest registration becomes primary because of the TID.

Only one 6LN may register a given Address at a particular 6BBR. However, that Registered Address may be registered to Multiple 6BBRs for higher availability.

Over the LLN, Binding Table management is as follows:

6.3. Registration and Binding Table Entry Creation

Upon receiving a registration for a new Address with an NS(EARO) with the 'R' bit set, the 6BBR performs DAD over the Backbone, placing the new Address as target in the NS(DAD) message. The EARO from the registration MUST be placed unchanged in the NS(DAD) message, and an Neighbor Cache entry created in TENTATIVE state for a duration of TENTATIVE_DURATION. The NS(DAD) message is sent multicast over the Backbone to the SNMA associated with the registered Address, unless that operation is known to be costly, and the 6BBR has an indication from another source (such as a Neighbor Cache entry) that the Registered Address was known on the Backbone; in the latter case, an NS(DAD) message may be sent as a Layer-2 unicast to the MAC Address that was associated with the Registered Address.

In TENTATIVE state after EARO with 'R' bit set:

  1. The entry is removed if an NA is received over the Backbone for the Registered Address with no EARO, or containing an EARO with a status of 1 (duplicate) that indicates an existing registration for another 6LN. The ROVR and TID fields in the EARO received over the Backbone are ignored. A status of 1 is returned in the EARO of the NA back to the Registering Node;
  2. The entry is also removed if an NA with an ARO option with a status of 3 (moved), or a NS with an ARO option that indicates a newer registration for the same Registered Node, is received over the Backbone for the Registered Address. A status of 3 is returned in the NA(EARO) back to the Registering Node;
  3. When a registration is updated but not deleted, e.g. from a newer registration, the DAD process on the Backbone continues and the running timers are not restarted;
  4. Other NS (including DAD with no EARO) and NA from the Backbone are not acknowledged in TENTATIVE state. To cover legacy 6LNs that do not support ODAD, the list of their origins MAY be stored and then, if the TENTATIVE_DURATION timer elapses, the 6BBR MAY send each such legacy 6LN a unicast NA.
  5. When the TENTATIVE_DURATION timer elapses, a status 0 (success) is returned in a NA(EARO) back to the Registering Node(s), and the entry goes to REACHABLE state for the Registration Lifetime. The 6BBR MUST send a multicast NA(EARO) to the SNMA associated to the Registered Address over the Backbone with the Override bit set so as to take over the binding from other 6BBRs.

6.4. Defending Addresses

If a 6BBR has an entry in REACHABLE state for a Registered Address:

The STALE state enables tracking of the Backbone peers that have a Neighbor Cache entry pointing to this 6BBR in case the Registered Address shows up later. 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. In STALE state:

7. Security Considerations

This specification applies to LLNS in which the link layer is protected, either by means of physical or IP security for the Backbone Link or MAC sublayer cryptography. In particular, the LLN MAC is required to provide secure unicast to/from the Backbone Router and secure Broadcast from the Backbone Router in a way that prevents tampering with or replaying the RA messages.

The use of EUI-64 for forming the Interface ID in the link local Address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and Address privacy techniques. Additional protection against Address theft is provided by [I-D.ietf-6lo-ap-nd], which guarantees the ownership of the ROVR.

When the ownership of the ROVR cannot be assessed, this specification limits the cases where the ROVR and the TID are multicasted, and obfuscates them in responses to attempts to take over an Address.

8. Protocol Constants

This Specification uses the following constants:

800 milliseconds
24 hours
5 minutes
3 times

9. IANA Considerations

This document has no request to IANA.

10. Future Work

Future documents may extend this specification by allowing the 6BBR to redistribute host routes in routing protocols that would operate over the Backbone, or in MIPv6, or FMIP, or the Locator/ID Separation Protocol (LISP) to support mobility on behalf of the 6LNs, etc...

11. Acknowledgments

Many thanks to Dorothy Stanley, Thomas Watteyne and Jerome Henry for their various contributions.

12. References

12.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007.
[RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, DOI 10.17487/RFC6059, November 2010.
[RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017.
[RFC8201] McCann, J., Deering, S., Mogul, J. and R. Hinden, "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017.
[RFC8505] Thubert, P., Nordmark, E., Chakrabarti, S. 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.

12.2. Informative References

[I-D.bi-savi-wlan] Bi, J., Wu, J., Wang, Y. and T. Lin, "A SAVI Solution for WLAN", Internet-Draft draft-bi-savi-wlan-16, November 2018.
[I-D.ietf-6lo-ap-nd] Thubert, P., Sarikaya, B., Sethi, M. and R. Struik, "Address Protected Neighbor Discovery for Low-power and Lossy Networks", Internet-Draft draft-ietf-6lo-ap-nd-08, October 2018.
[I-D.ietf-6man-rs-refresh] Nordmark, E., Yourtchenko, A. and S. Krishnan, "IPv6 Neighbor Discovery Optional RS/RA Refresh", Internet-Draft draft-ietf-6man-rs-refresh-02, October 2016.
[I-D.ietf-6tisch-architecture] Thubert, P., "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Internet-Draft draft-ietf-6tisch-architecture-17, November 2018.
[I-D.ietf-mboned-ieee802-mcast-problems] Perkins, C., McBride, M., Stanley, D., Kumari, W. and J. Zuniga, "Multicast Considerations over IEEE 802 Wireless Media", Internet-Draft draft-ietf-mboned-ieee802-mcast-problems-04, November 2018.
[I-D.nordmark-6man-dad-approaches] Nordmark, E., "Possible approaches to make DAD more robust and/or efficient", Internet-Draft draft-nordmark-6man-dad-approaches-02, October 2015.
[I-D.yourtchenko-6man-dad-issues] Yourtchenko, A. and E. Nordmark, "A survey of issues related to IPv6 Duplicate Address Detection", Internet-Draft draft-yourtchenko-6man-dad-issues-01, March 2015.
[RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005.
[RFC4389] Thaler, D., Talwar, M. and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2006.
[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, DOI 10.17487/RFC4903, June 2007.
[RFC4919] Kushalnagar, N., Montenegro, G. and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007.
[RFC5415] Calhoun, P., Montemurro, M. and D. Stanley, "Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification", RFC 5415, DOI 10.17487/RFC5415, March 2009.
[RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2011.
[RFC6606] Kim, E., Kaspar, D., Gomez, C. 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.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013.
[RFC7048] Nordmark, E. and I. Gashinsky, "Neighbor Unreachability Detection Is Too Impatient", RFC 7048, DOI 10.17487/RFC7048, January 2014.
[RFC7559] Krishnan, S., Anipko, D. and D. Thaler, "Packet-Loss Resiliency for Router Solicitations", RFC 7559, DOI 10.17487/RFC7559, May 2015.
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy Consumption of Router Advertisements", BCP 202, RFC 7772, DOI 10.17487/RFC7772, February 2016.
[RFC8273] Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017.

12.3. External Informative References

[IEEEstd8021] IEEE standard for Information Technology, "IEEE Standard for Information technology -- Telecommunications and information exchange between systems Local and metropolitan area networks Part 1: Bridging and Architecture"
[IEEEstd80211] IEEE standard for Information Technology, "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"
[IEEEstd802151] IEEE standard for Information Technology, "IEEE Standard for Information Technology - Telecommunications and Information Exchange Between Systems - Local and Metropolitan Area Networks - Specific Requirements. - Part 15.1: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Wireless Personal Area Networks (WPANs)"
[IEEEstd802154] IEEE standard for Information Technology, "IEEE Standard for Local and metropolitan area networks -- Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs)"

Appendix A. Applicability and Requirements Served

This document specifies proxy-ND functions that can be used to federate an IPv6 Backbone Link and multiple IPv6 LLNs into a single MultiLink Subnet. The proxy-ND functions enable IPv6 ND services for Duplicate Address Detection (DAD) and Address lookup that do not require broadcasts over the LLNs.

The term LLN is used loosely to cover multiple types 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, so as to address the requirements listed in Appendix B.3 of [RFC8505] "Requirements Related to Various Low-Power Link Types".

Each LLN in the subnet is anchored at an IPv6 Backbone Router (6BBR). The Backbone Routers interconnect the LLNs and advertise the Addresses of the 6LNs over the Backbone Link using proxy-ND operations.

This specification updates IPv6 ND over the Backbone to distinguish Address movement from duplication and eliminate stale state in the Backbone routers and Backbone nodes once a 6LN has roamed. In this way, mobile nodes may roam rapidly from one 6BBR to the next and requirements in Appendix B.1 of [RFC8505] "Requirements Related to Mobility" are met.

Any 6LN may register its IPv6 Addresses and thereby obtain proxy-ND services over the Backbone, providing a solution to the requirements expressed in Appendix B.4 of [RFC8505] "Requirements Related to Proxy Operations".

The IPv6 ND operation is minimized as the number of 6LNs grows in the LLN. This meets the requirements in Appendix B.6 of [RFC8505] "Requirements Related to Scalability", as long has the 6BBRs are dimensioned for the number of registrations that each needs to support.

In the case of a (Low-Power) Wi-Fi access link, a 6BBR may be collocated with the Access Point (AP), or with a Fabric Edge (FE) or a CAPWAP [RFC5415] Wireless LAN Controller (WLC). In that case, the wireless client (STA) is the 6LN [RFC8505] that makes use of this specification to register its IPv6 Address(es) to the 6BBR acting as Routing Registrar. The 6LBR can be centralized and either connected to the Backbone Link or reachable over IP. The 6BBR proxy-ND operations eliminate the need for wireless nodes to respond synchronously when a lookup is performed for their IPv6 Addresses. This provides the function of a Sleep Proxy for ND [I-D.nordmark-6man-dad-approaches].

For the TimeSlotted Channel Hopping (TSCH) mode of [IEEEstd802154], the 6TiSCH architecture describes how a 6LoWPAN ND host could connect to the Internet via a RPL mesh Network, but doing so requires 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 Appendix B.2 of [RFC8505] "Requirements Related to Routing Protocols".

The registration mechanism may be seen as a more reliable alternate to snooping [I-D.bi-savi-wlan]. It can be noted that registration and snooping are not mutually exclusive. Snooping may be used in conjunction with the registration for nodes that do not register their IPv6 Addresses. 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 this assumption, the 6BBR can possibly cancel all undesirable multicast NS messages that would otherwise have been delivered to that node.

The scalability of the MultiLink Subnet [RFC4903] requires that multicast/broadcast operations are avoided as much as possible even on the Backbone [I-D.ietf-mboned-ieee802-mcast-problems]. Although hosts can connect to the Backbone using classical IPv6 ND operations, multicast RAs can be saved by using [I-D.ietf-6man-rs-refresh], which also requires the support of [RFC7559].

Authors' Addresses

Pascal Thubert (editor) Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 MOUGINS - Sophia Antipolis, 06254 FRANCE Phone: +33 497 23 26 34 EMail: pthubert@cisco.com
Charles E. Perkins Futurewei 2330 Central Expressway Santa Clara, 95050 United States of America EMail: charliep@computer.org
Eric Levy-Abegnoli Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 MOUGINS - Sophia Antipolis, 06254 FRANCE Phone: +33 497 23 26 20 EMail: elevyabe@cisco.com