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

                          IPv6 Backbone Router
                   draft-ietf-6lo-backbone-router-09
                   draft-ietf-6lo-backbone-router-10

Abstract

   Backbone Routers are RFC8505 Routing Registrars that provide

   This document updates RFC 4861 and RFC 8505 in order to enable proxy
   services for IPv6 Neighbor Discovery.  Backbone Routers federate
   multiple wireless Links over a Discovery by Routing Registrars called
   Backbone Link to form a MultiLink
   Subnet. Routers.  Backbone Routers are placed along the wireless
   edge of the
   Backbone handle IPv6 Neighbor Discovery, a Backbone, and route packets on behalf
   of registered nodes. federate multiple wireless links to form a
   single MultiLink Subnet.

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, July 20, 2019.

Copyright Notice

   Copyright (c) 2018 2019 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  BCP 14  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  References  New Terms . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.3.  New Terms .  Acronym Definitions . . . . . . . . . . . . . . . . . . .   6
     2.4.  References  . . . .   5
     2.4.  Acronym Definitions . . . . . . . . . . . . . . . . . . .   6   7
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1.  Access Link . . . . . . . . . .  Updating RFC 6775 and RFC 8505  . . . . . . . . . . . . .   9
     3.2.  Route-Over Mesh .  Access Link . . . . . . . . . . . . . . . . . . . .  10
     3.3.  MultiLink Subnet Consistency . . .  10
     3.3.  Route-Over Mesh . . . . . . . . . . .  11
     3.4.  Registering Node . . . . . . . . . .  11
     3.4.  The Binding Table . . . . . . . . . .  11
     3.5.  Using IPv6 ND Over the Backbone Link . . . . . . . . . .  12
     3.6.  Routing Proxy Operations  .
     3.5.  Primary and Secondary 6BBRs . . . . . . . . . . . . . . .  13
     3.7.  Bridging Proxy Operations
     3.6.  Using Optimistic DAD  . . . . . . . . . . . . . . . . .  14
     3.8.  Leveraging Optimistic DAD .  13
   4.  MultiLink Subnet Considerations . . . . . . . . . . . . . . .  14
   4.  Updating RFC 4861 .
   5.  Optional 6LBR serving the MultiLink Subnet  . . . . . . . . .  14
   6.  Using IPv6 ND Over the Backbone Link  . . . . . . . . . . . .  15
   5.  Updating RFC 8505 . . . .
   7.  Routing Proxy Operations  . . . . . . . . . . . . . . . . . .  15
   6.  6BBR detailed
   8.  Bridging Proxy Operations . . . . . . . . . . . . . . . . . .  15
     6.1.  Primary  16
   9.  Creating and Secondary  6BBRs  . Maintaining a Binding  . . . . . . . . . . . . .  16
     6.2.  17
     9.1.  Operation on a Binding Table . . . . . . in Tentative State . . . . . . . .  19
     9.2.  Operation on a Binding in Reachable State . . . . . . . .  16
     6.3.  Registration and  20
     9.3.  Operation on a Binding Table Entry Creation in Stale State . . . . . .  17
     6.4.  Defending Addresses . . . .  21
   10. Registering Node Considerations . . . . . . . . . . . . . . .  18
   7.  21
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  20
   8.  22
   12. Protocol Constants  . . . . . . . . . . . . . . . . . . . . .  20
   9.  22
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  20
   10. Future Work . . . . . . . . . . . . . . . . . . . . . . . . .  20
   11.  23
   14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  20
   12.  23
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     12.1.  23
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     12.2.  23
     15.2.  Informative References . . . . . . . . . . . . . . . . .  22
     12.3.  External Informative References  24
   Appendix A.  Possible Future Extensions . . . . . . . . . . . .  24 .  27
   Appendix A. B.  Applicability and Requirements Served  . . . . . . .  25  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26  29

1.  Introduction

   IEEE STD. 802.1 [IEEEstd8021] Ethernet Bridging provides an efficient
   and reliable broadcast service; 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 economical fashion; fashion.

   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
   [I-D.ietf-mboned-ieee802-mcast-problems]).

   Wi-Fi [IEEEstd80211] Access Points (APs) deployed in an Extended
   Service Set (ESS) act as Ethernet Bridges [IEEEstd8021], with the
   interesting caveat
   property that the bridging state is populated proactively established at the association time. time of
   association.  This ensures a solid connectivity to the node (STA) and
   protects the wireless medium against the broadcast-
   intensive broadcast-intensive Transparent
   Bridging reactive lookups. Lookups.  In other words, the association process
   is used to register the MAC Address of the STA to the AP.  The APs AP
   subsequently proxies the bridging operation and does not need to
   forward the broadcast lookups Lookups over the radio.

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

   The IPv6 ND Neighbor Solicitation (NS) [RFC4861] message is such a message; NS messages are used for
   DAD and Address lookup, and are frequently observed in a
   situation of mobility and address Lookup when a node moves, or wakes up and reconnects
   to the wireless network.  The NS message is targeted to a Sollicitated-Node Solicited-
   Node Multicast Address (SNMA) [RFC4291] and should in theory only
   reach a very small group of nodes; but since Layer-3 nodes.  But in reality, IPv6 multicast
   messages are
   effectively broadcasted at Layer-2, typically broadcast on the wireless medium, and so they
   are processed by most of the wireless nodes over the subnet (e.g.,
   the volume ESS fabric) regardless of Address lookups how few of the nodes are subscribed to
   the SNMA.  As a result, IPv6 ND address Lookups and DADs over a large fabric
   wireless and/or a LowPower Lossy Network (LLN) can effectively consume enough
   bandwidth to the
   point that it becomes detrimental cause a substantial degradation to the unicast traffic (see
   [I-D.ietf-mboned-ieee802-mcast-problems]).

   Additionally,
   service.

   Because IPv6 ND messages sent to the SNMA group are broadcasted at
   the radio MAC Layer, wireless nodes that do not belong to the SNMA
   group still have to keep their radio awake and turned on to listen to broadcasted multicast
   NS messages, which is a total waste of energy for them.  In order to
   control
   reduce their power consumption, certain battery-operated nodes devices such
   as IOT IoT sensors and smartphones may then elect to blindly ignore a portion some of the broadcasts, which tends to make the Layer-3 protocol making
   IPv6 ND operations even less reliable.

   These problems can be alleviated by a reduction of reducing the IPv6 ND broadcasts
   over wireless access links.  One classical way to achieve this to
   split  This has been done by splitting the
   broadcast domains and route routes between subnets, possibly or even 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
   domains the Layer-2 association but at layer-3.  To Layer-3 protocols that
   effect, rely on MAC Layer broadcast
   operations.  For instance, IEEE 802.11 [IEEEstd80211] requires situates proxy-
   ARP (IPv4) and proxy-ND
   [RFC4389] services (IPv6) functions at the Access Points (APs), (APs).
   The 6BBR provides a proxy-ND function and this specification
   is can be extended for proxy-
   ARP in a possible response to that requirement. continuation specification.

   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 have been used; although snooping is really useful to cancel does eliminate
   undesirable broadcast transmissions, it has also proven been found to be unreliable;
   unreliable.  An IPv6 Address address may not be discovered immediately due to
   a packet loss, or if a silent "silent" node that does is not use the Address for a while; a currently using one of
   its addresses.  A change of state (e.g.  due a to movement) may be
   missed or misordered, leading to unreliable connectivity and a partial
   incomplete knowledge of the state of the network.

   With this specification,

   This specification defines the 6BBR as a wireless Routing Registrar [RFC8505]
   that provide proxy services for IPv6 Neighbor Discovery.  Backbone
   Routers federate multiple LLNs over a Backbone Link to form a
   MultiLink Subnet (MLSN).  Backbone Routers placed along the LLN edge
   of the Backbone handle IPv6 Neighbor Discovery, and forward packets
   on behalf of registered nodes.

   An LLN node proactively (6LN) registers all its IPv6 Addresses using a an NS(EARO)
   as specified in [RFC8505] to an IPv6
   Backbone Router (6BBR). the 6BBR.  The 6BBR is a Routing Registrar per
   [RFC8505].  It is also a Border
   Router that performs the IPv6 proxy Neighbor Discovery (IPv6 ND) operations on
   its Backbone interface on behalf of the 6LNs that are have registered
   addresses 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 interfaces without the need of a broadcast lookup over
   the wireless medium.  Additional benefits are discussed in
   Appendix A. B.

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] [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  New Terms

   This document introduces the following documents:

   o  "Neighbor Discovery Proxies (proxy-ND)" [RFC4389]

   o  "Optimistic Duplicate Address Detection" [RFC4429], and

   o  "Neighbor Discovery for IP version 6" [RFC4861],

   o  "IPv6 Stateless Address Autoconfiguration" [RFC4862],

   o  "MultiLink Subnet Issues" [RFC4903],

   o  "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
      Overview, Assumptions, Problem Statement, and Goals" [RFC4919],

   o  Neighbor Discovery Optimization for Low-Power and Lossy Networks
      [RFC6775],

   o  ,"Mobility Support in IPv6" [RFC6275],

   o  "Problem Statement and Requirements for IPv6 over Low-Power
      Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], and
      mostly

   o  "Registration Extensions for 6LoWPAN Neighbor Discovery"
      [RFC8505].

2.3.  New Terms

   This document also introduces the following terminology:

   Federated

         A subnet that is partitionned over a Backbone terminology:

   Federated

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

   Sleeping Proxy

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

   Unicasting

   Routing Proxy

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

         A provides IPv6 ND proxy functions and enables
         the MLSN operation over federated links that may not be
         compatible for bridging.  The Routing Proxy advertises its own
         MAC Address as the TLLA in the proxied NAs over the Backbone, as opposed to that of
         and routes at the
         node that performs Network Layer between the registration. federated links.

   Bridging Proxy

         A Bridging Proxy provides IPv6 ND proxy functions while
         preserving forwarding continuity at the MAC Layer.  The
         Bridging Proxy advertises the MAC Address of the node that
         performs the registration Registering
         Node 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 Backbone, and the 6BR may be configured to
         proxy for Link Local Addresses.

   Binding Table

         The 6BBR Binding Table is an abstract database that will defend a Registered Address for the purpose
         of DAD over the Backbone.

   Secondary  6BBR

         A 6BBR other than is maintained by
         the Primary 6BBR to which an Address is
         registered.  A Secondary Router MAY advertise store the Address over state associated with its registrations.

   Binding

         A Binding is an abstract state associated to one registration,
         in other words one entry in the Backbone and proxy for it.

2.4. Binding Table.

2.3.  Acronym Definitions

   This document uses the following acronyms:

   6BBR: 6LoWPAN Backbone Router

   6LBR: 6LoWPAN Border Router

   6LN:  6LoWPAN Node

   6LR:  6LoWPAN Router

   6CIO: Capability Indication Option

   EARO: (Extended) Address Registration Option -- (E)ARO

   EDAR: (Extended) Duplicate Address Request -- (E)DAR

   EDAC: (Extended) Duplicate Address Confirmation -- (E)DAC

   DAD:  Duplicate Address Detection

   DODAG:  Destination-Oriented Directed Acyclic Graph

   IPv6 ND:  IPv6 Neighbor Discovery

   LLN:  Low-Power and Lossy Network

   NA:   Neighbor Advertisement

   NCE:  Neighbor Cache Entry

   ND:   Neighbor Discovery

   NDP:  Neighbor Discovery Protocol

   NS:   Neighbor Solicitation

   ROVR: Registration Ownership Verifier (pronounced rover)

   RPL:  IPv6 Routing Protocol for LLNs (pronounced ripple) [RFC6550]

   RA:   Router Advertisement

   RS:   Router Solicitation

   TID:  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;

2.4.  References

   In this way, a subnet document, readers will encounter terms and concepts that is located on a
   Backbone can be extended are
   discussed 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 following documents:

   o  "Neighbor Discovery for IP version 6" [RFC4861], "IPv6 Stateless
      Address Autoconfiguration" [RFC4862] and "Optimistic Duplicate
      Address Detection" [RFC4429],

   o  "Neighbor Discovery Proxies (proxy-ND)" [RFC4389] and "MultiLink
      Subnet Issues" [RFC4903],

   o  "Problem Statement and Requirements for 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 Low-Power
      Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], and
   retain any or all of the IPv6 Addresses that the 6LN has formed.

   The registration to a proxy service is done via

   o  Neighbor Discovery Optimization for Low-Power and Lossy Networks
      [RFC6775] and "Registration Extensions for 6LoWPAN Neighbor
      Discovery" [RFC8505].

3.  Overview

   Figure 1 illustrates backbone link federating a NS/NA(EARO)
   exchange.  The 6BBR operation resembles that collection of LLNs as
   a Mobile single IPv6 (MIPv6)
   [RFC6275] Home Agent.  The combination if a 6BBR and a MIPv6 HA
   enables Subnet, with a full mobility support for 6LNs, inside and outside the
   links that form the subnet. number of 6BBRs providing proxy-ND
   services to their attached LLNs.

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

         LLN                        LLN                      LLN

               Figure 1: Backbone Link and Backbone Routers

   Each Backbone Router (6BBR) maintains an abstract Binding Table of
   its

   The LLN may be a hub-and-spoke access link such as (Low-Power) IEEE
   STD. 802.11 (Wi-Fi) [IEEEstd80211] and IEEE STD. 802.15.1 (Bluetooth)
   [IEEEstd802151], or a Mesh-Under or a Route-Over network [RFC8505].
   The proxy state can be distributed across multiple 6BBRs attached to
   the same Backbone.

   The main features of a 6BBR are as follows:

   o  Multilink-subnet functions (provided by the 6BBR on the backbone)
      performed on behalf of registered 6LNs, and

   o  Routing registrar services that reduce multicast within the LLN:

      *  Binding Table management

      *  failover, e.g., due to mobility

   Each Backbone Router (6BBR) maintains a data structure for its
   Registered Nodes. Nodes called a Binding Table.  The combined Binding Tables
   of all the 6BBRs on a backbone form a distributed database of 6LNs
   that reside on in the LLNs or on the IPv6 Backbone, Backbone.

   Unless otherwise configured, a 6BBR does the following:

   o  Create a new entry in a Binding Table for a new Registered Address
      and use an
   extension to IPv6 ND to exchange ensure that information across the
   Backbone.  In that process:

      The Extended Address Registration Option (EARO) defined in
      [RFC8505] is used in the ND exchanges not duplicated over the Backbone between
      the 6BBRs to help distinguish duplication from movement.
      Optionally, Extended Duplicate Address Messages (EDAR and EDAC)
      can also be used between the 6BBR and

   o  Defend a 6LBR if one is present on
      the Backbone. Registered Address duplication is detected using over the ROVR
      field, and conflicting registrations to different 6BBRs by a same
      owner 6LR are resolved Backbone using the TID field.

      The Link Layer Address (LLA) that the 6BBR advertises for the
      Registered Address NA messages on
      behalf of the sleeping 6LN

   o  Advertise a Registered Node Address over the Backbone may be that of the Registering Node; in that case, the
      6BBR needs using NA
      messages, asynchronously or as a response to bridge the unicast a Neighbor
      Solicitation messages.

   o  Deliver packets (Bridging Proxy).
      Alternatively, the LLA can be that arriving from the LLN, using Neighbor Solicitation
      messages to look up the destination over the Backbone.

   o  Forward or bridge packets between the LLN and the Backbone.

   o  Verify liveness for a registration, when needed.

   The first of these functions enables the 6BBR on to fulfill its role as
   a Routing Registrar for each of its attached LLNs.  The remaining
   functions fulfill the Backbone
      interface, in which case role of the 6BBRs receives at Layer-2 and and
      needs as the border routers
   connecting the Multi-link IPv6 subnet to route at Layer-3 the unicast packets (Routing Proxy).
      This is discussed in more details Internet.

   The proxy-ND operation can co-exist with IPv6 ND over the Backbone.

   The 6BBR may co-exist with a proprietary snooping or a traditional
   bridging functionality in Section 3.6 and Section 3.7,
      respectively.

3.1. an Access Link

   This specification also applies Point, in order 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 support legacy
   nodes that do not support this specification.  In the case, the co-
   existing function may turn multicastsinto a series of unicast to the
   legacy nodes.

   The registration to a 6LN that forms proxy service uses an NS/NA(EARO) exchange.
   The 6BBR operation resembles that of a Mobile IPv6
   Address and registers it to (MIPv6) [RFC6275]
   Home Agent (HA).  The combination of a 6BBR acting as and a 6LR [RFC8505].

       6LoWPAN Node        6BBR          6LBR            default
          (STA)            (AP)                           Router
            |(Wireless) LLN | MIPv6 HA enables
   full mobility support for 6LNs, inside and outside the links that
   form the subnet.

   The 6BBRs use the Extended Address Registration Option (EARO) defined
   in [RFC8505] as follows:

   o  The EARO is used in the IPv6 ND exchanges over the 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],
      between the
   6TiSCH architecture [I-D.ietf-6tisch-architecture] suggests 6BBRs to
   collocate the RPL root help distinguish duplication from movement.
      Extended Duplicate Address Messages (EDAR and EDAC) MAY also be
      used with a 6LoWPAN Border Router (6LBR), which 6LBR, if one is
   either collocated with or connected to the 6BBR over an IPv6 Link.

   Figure 3 illustrates present, and the initial IPv6 signaling that enables a 6LN to
   form a Global or a Unique-Local 6BBR.  Address and register it
      duplication is detected using the ROVR field.  Conflicting
      registrations to different 6BBRs for the 6LBR same 6LR address are
      resolved using [RFC8505]. the TID field.

   o  The 6LBR also leverages [RFC8505] to register Link Layer Address (LLA) that the
   6LNs 6BBR advertises for the
      Registered Address on their behalf to of the 6BBR and obtain proxy-ND services.

       6LoWPAN Registered 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 the
      Backbone and can belong to the federated LLN Links are considered as different
   Links Registering Node; in that case, the MultiLink Subnet, even if multiple LLNs are attached to
      6BBR (acting as a same 6BBR.  Multicast ND messages are link-scoped and MUST NOT be
   forwarded across Bridging Proxy (see Section 8)) bridges the Backbone Routers.

   A prefix that is used across a MultiLink Subnet may still be
   advertised as on-link over
      unicast packets.  Alternatively, the Backbone, by setting LLA can be that of the "L" bit in 6BBR
      on the Prefix Information Option (PIO) in RA messages ([RFC4861]), Backbone interface, in
   order to support classical IPv6 hosts; but which case the MultiLink Subnet
   prefix MUST be advertised 6BBR (acting 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
      Routing Proxy(see Section 7)) receives the Backbone unicast packets at
      Layer-2 and all attached LLNs.  To
   achieve this, the 6BBR MUST use routes them.

3.1.  Updating RFC 6775 and RFC 8505

   This specification adds the same MTU value that is used EARO as a possible option in
   RAs RS, NS(DAD)
   and NA messages over the Backbone in the RAs backbone.  [RFC8505] requires 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
   registration NS(EARO) contains an SLLAO.  This specification details
   the 6LR(s).

   The Registering Node MUST accept multicast RAs, but use of those are
   expected to be rare within in messages over the LLN backbone.

   Note: [RFC6775] requires that the registration NS(EARO) contains an
   SLLAO and [RFC4862] that the NS(DAD) is sent from the best practices
   ([RFC7772]) are followed.

   The Registering Node SHOULD comply unspecified
   address for which there cannot be a SLLAO.  Consequently, an NS(DAD)
   cannot be confused with a registration.

   This specification adds the Simple Procedures for
   Detecting Network Attachment in IPv6 [RFC6059] (DNA procedures) capability to
   assert movements, and support Packet-Loss Resiliency for Router
   Solicitations [RFC7559] insert IPv6 ND options in order to make
   the unicast RS messages more
   reliable.

   The Registering Node signals that it requires IPv6 proxy-ND services
   from EDAR and EDAC messages.  In particular, a 6BBR by registering acting as a 6LR
   for the corresponding IPv6 Registered Address with can insert an
   NS(EARO) message with the 'R' flag set ([RFC8505]).  It may be SLLAO in the
   actual owner of EDAR to 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 order to register avoid 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 Lookup back.

3.2.  Access Link

   On the Backbone side, the 6BBR MUST join the SNMA group that
   corresponds to

   Figure 2 illustrates a Registered Address as soon as it creates flow where 6LN forms an entry
   for that Address, IPv6 Address and conserve its SNMA membership as long as
   registers it
   maintains the associated entry.  The to a 6BBR uses either acting as a 6LR [RFC8505].  The 6BBRs applies
   ODAD (see Section 3.6) to the SNMA or
   plain unicast registered address to defend enable
   connectivity while the Registered Addresses message flow is still in its Binding
   Table over the Backbone.

   The 6BBR advertises and defends the Registered Addresses over the
   Backbone using progress.  In that
   example, a 6LBR is deployed on the IPv6 ND protocol [RFC4861].  It MUST uses an EARO
   in backbone link to serve the NS(DAD) whole
   subnet, and NA EDAR / EDAC messages that it generates over the Backbone
   Link for the Registered Address.  A NA message generated are used in response
   to a NS(LOOKUP) MUST NOT have the override (O) bit set.  A proxied NS
   MUST NOT contain an SLLAO combination with DAD to avoid the confusion
   enable coexistence with a registration.

   A 6BBR may asynchronously update the NCEs in correspondent nodes IPv6 ND over the Backbone, e.g., in case of a movement.  This is achieved using backbone.

          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 2: Initial Registration Flow to a
   gratuitous NA with the override (O) bit set, 6BBR acting as Routing Proxy

3.3.  Route-Over Mesh

   Figure 3 illustrates IPv6 signaling that may be sent unicast enables a 6LN to each individual correspondent, form a
   Global or multicast to all nodes (more in
   Section 3.7 a Unique-Local Address and Section 3.6).

   A 6LBR may optionally be deployed over register it to the Backbone.  When 6LBR that is
   serves its LLN using [RFC8505].  The 6LBR (acting as Registering
   Node) proxies the case, registration to the 6BBR uses an EDAR/EDAC echange 6BBR, using [RFC8505] to check for duplication
   or movement as prescribed in [RFC8505].  If this registration is
   duplicate or not
   register the freshest, then addresses the 6LBR replies with a status
   code of 1 ("Duplicate Address") or 3 ("Moved"), respectively.  If
   this registration is 6LN (Registered Node) on its behalf to the freshest, then
   6BBR, and obtain proxy-ND services from the 6BBR.

       6LoWPAN Node        6LR             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 [RFC6830] may be used to provide an equivalent
   service.

   Nodes implementing this specification is expected to co-exist on a
   same            6BBR
       (mesh leaf)     (mesh router)   (mesh root)
            |               |               |               |
            |  6LoWPAN ND   |6LoWPAN ND     | 6LoWPAN ND    | IPv6 ND
            |   LLN link    |Route-Over mesh|Ethernet/serial| Backbone Link with nodes implementing classical
            |               |               |/Internal call |
            |  IPv6 ND
   [RFC4861] 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

   As a non-normative example of a Route-Over Mesh, the 6TiSCH
   architecture [I-D.ietf-6tisch-architecture] suggests using RPL
   [RFC6550] and snooping [I-D.bi-savi-wlan].  It results that collocating the fact
   that there is RPL root with a 6LBR or an alternate protocol that serves the
   LLN, and is deployed on either collocated with or connected to the
   Backbone does not mean that all 6BBR over an
   IPv6 addresses are known there; the
   fact that Link.

3.4.  The Binding Table

   Addresses in a unicast DAD succeeds with the 6LBR does not mean LLN that are reachable from the
   address is not duplicate, and, unless administratively overridden,
   6BBRs Backbone by way of the
   6BBR function must still perform classical IPv6 ND DAD after be registered to that 6BBR, using an EDAC NS(EARO) 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 R flag set [RFC8505].  A 6BBR maintains a state for all nodes its active
   registrations in an abstract Binding Table.

   An entry in the subnet.

3.6.  Routing Proxy Operations

   When operating as Binding Table Entry is called a Routing Proxy, the 6BBR MUST use the Layer-2
   Address on its Backbone Interface "Binding".  A Binding
   may be in the TLLA and SLLA options, when
   present, Tentative, Reachable or Stale state.

   The 6BBR uses a combination of the RS, NS [RFC8505] 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 IPv6 ND over the
   Backbone to
   maintain end-to-end IP connectivity, but the NCEs of the
   correspondents must be updated when advertise the owner registers to registration and avoid a
   different 6BBR.

   This technique is useful when the churn on the Backbone fabric
   associated to wireless mobility becomes expensive, e.g., when duplication.
   Conflicting registrations are solved by the
   Layer-2 topology is virtualized over a wide area IP underlay.  In
   order 6BBRs transparently to maintain IP connectivity,
   the 6BBR installs Registering Nodes.

   Only one 6LN may register a connected host
   route to given Address, but the Registered Address on may be
   registered to Multiple 6BBRs for higher availability.

   Over the LLN interface, via the
   Registering Node LLN, Binding Table management is as identified by the Source Address and the SLLA
   option in follows:

   o  De-registrations (newer TID, same ROVR, null Lifetime) are
      accepted with a status of 4 ("Removed"); the NS(EARO) messages.

   This technique entry is also useful when the LLN uses deleted;

   o  Newer registrations (newer TID, same ROVR, non-null Lifetime) are
      accepted with a MAC address format
   that status of 0 (Success); the Binding is different from that on updated with
      the Backbone (e.g., EUI-64 vs. EUI-
   48).

   For each Registered Address, multiple peer Nodes on new TID, the Backbone Registration Lifetime and the Registering Node;
      in Tentative state the EDAC response is held and may
   have resolved be
      overwritten; in other states the Address with Registration Lifetime timer is
      restarted and the 6BBR MAC Address, maintaining that
   mapping entry is placed in their Neighbor cache.  The 6BBR SHOULD maintain Reachable state.

   o  Identical registrations (same TID, same ROVR) from a list same
      Registering Node are accepted with a status of 0 (Success).  In
      Tentative state, the peers on response is held and may be overwritten, but
      the Backbone which have associated its MAC Address with response MUST be eventually produced, carrying the Registered Address.  If that Registered Address moves result of
      the DAD process;

   o  Older registrations (older TID, same ROVR) from an old
   to a new 6BBR, the old 6BBR SHOULD unicast same
      Registering Node are discarded;

   o  Identical and older registrations (not-newer TID, same ROVR) from
      a gratuitous NA different Registering Node are rejected with the
   Override (O) bit set to each such peer, to supply the LLA a status of the new
   6BBR in the TLLA option 3
      (Moved); this may be rate limited to avoid undue interference;

   o  Any registration for the Address.

   If the 6BBR fails same address but with a different ROVR is
      rejected with a status of 1 (Duplicate).

3.5.  Primary and Secondary 6BBRs

   A same address may be successfully registered to maintain this list, then it MAY send more than one 6BBR,
   in which case the
   gratuitous Registering Node uses the same EARO in all the
   parallel registrations.  To allow for this, ND(DAD) and NA messages
   with the Override (O) bit set an EARO that indicate an identical Binding in another 6BBR (same
   Registered address, same TID, same ROVR) as a multicast message silently ignored.

   A 6BBR MAY be primary or secondary.  The primary is the 6BBR that will possibly hit all has
   the nodes on highest EUI-64 Address of all the Backbone, whether they
   maintain an NCE or not 6BBRs that share a registration
   for the same Registered Address.

   If a correspondent fails to receive Address, with the gratuitous NA, it will keep
   sending traffic to a 6BBR to which same ROVR and same
   Transaction ID, the node was previously
   registered.  That old EUI-64 Address being considered as an unsigned
   64bit integer.  A given 6BBR having removed its host route to the
   Registered can be primary for a given Address and
   secondary for another Address, it will look it up over regardless of whether or not the backbone, resolve
   Addresses belong to the
   with same 6LN.

   In the LLA of following sections, is is expected that an NA is sent over the new 6BBR, and forward
   backbone only if the packet to node is primary or does not support the correct
   6BBR.  The old concept
   of primary.  More than one 6BBR SHOULD also claiming or defending an address
   generates unwanted traffic but no reachability issue a redirect message [RFC4861] is
   order since all 6BBRs
   provide reachability from the Backbone to update the cache of the correspondent.

3.7.  Bridging Proxy Operations

   A Bridging Proxy 6LN.

3.6.  Using Optimistic DAD

   Optimistic Duplicate Address Detection [RFC4429] (ODAD) specifies how
   an IPv6 Address can be implemented in a Layer-3 switch, or in a
   wireless Access Point or wireless Controller used before completion of Duplicate Address
   Detection (DAD).  ODAD guarantees that acts as this behavior will not cause
   harm if the new Address is a Layer-2
   Bridge duplicate.

   Support for unicast packets from/to ODAD avoids delays in installing the Registered Address.  The
   Bridging Proxy appears as an IPv6 Host on Neighbor Cache Entry
   (NCE) in the Backbone whereas 6BBRs and the
   Routing Proxy described default router, enabling immediate
   connectivity to the registered node.  As shown in Section 3.6 Figure 2, if the
   6BBR is an IPv6 router operating as
   a border router between Links aware of the Link-Layer Address (LLA) of a MultiLink Subnet.

   When operating as a Bridging Proxy, router, then the
   6BBR MUST use sends a Router Solicitation (RS), using the Registering
   Node's Layer-2 Registered Address in the TLLA and SLLA options, when present,
   of, respectively,
   as the RS, NS and NA messages that it generates IP Source Address, to
   advertise the Registered Addresses. known router(s).  The Registering Node's Layer-2
   address is found RS MUST be
   sent without a Source LLA Option (SLLAO), to avoid invalidating a
   preexisting NCE in the SLLA of router.

   Following ODAD, the registration NS(EARO), router may then send a unicast RA to the
   Registered Address, and
   maintained in it may resolve that Address using an
   NS(Lookup) message.  In response, the abstract Binding Table.

   If 6BBR sends an NA with an EARO
   and the Registering Node Override (O) flag [RFC4861] that is not set.  The router can
   then determine the owner freshest EARO in case of a conflicting NA(EARO)
   messages, using the Registered Address, then
   its mobility does not impact existing NCEs over the Backbone. method described in section 5.2.1 of [RFC8505].
   If it the NA(EARO) is not, then when the 6LN selects another Registering Node, freshest answer, the new
   Registering Node SHOULD send default router creates a multicast NA
   Binding with the Override (O) bit
   set to fix the existing NCEs across the Backbone.  This method may
   fail if SLLAO of the multicast message is not received, in which case one 6BBR (in Routing Proxy mode) or
   more correspondent nodes on that of
   the Backbone may maintain an obsolete NCE
   and Registering Node (in Bridging Proxy mode) so that traffic to from/to
   the Registered Address may be lost for a while.  When
   this condition happens, it is eventually be discovered can flow immediately.

4.  MultiLink Subnet Considerations

   The Backbone and solved
   through the Neighbor Unreachability Detection (NUD) procedure defined federated LLN Links are considered as different
   links in [RFC4861].

3.8.  Leveraging Optimistic DAD

   The Optimistic Duplicate Address Detection [RFC4429] (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 MultiLink Subnet, even if multiple LLNs are attached to avoid delays in
   installing
   the Neighbor Cache Entry (NCE) in the 6BBRs same 6BBR.  ND messages are link-scoped and are not forwarded by
   the
   default router in order to obtain immediate connectivity to 6BBR between the
   registered node.

   This specification RECOMMENDS to support ODAD to create an optimistic
   proxy state backbone and the LLNs though some packets may be
   reinjected in Bridging Proxy mode (see Section 8).

   Nodes located inside the 6BBR until DAD is completed over subnet do not perform the Backbone.  As
   shown in Figure 2, if the 6BBR is aware of the Link-Layer Address
   (LLA) of a router, then IPv6 Path MTU
   Discovery [RFC8201].  For that reason, the 6BBR sends MTU must have a Router Sollicitation (RS),
   sourced with same value
   on the Registered Address, to Backbone and all attached LLNs.  To achieve this, the known router(s).  The RS 6BBR
   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, use the router may then send a unicast RA to same MTU value in RAs over the Registered Address, Backbone and in the process of doing so, it may
   resolve RAs
   that it using an NS(LOOKUP) message.  In response, the 6BBR sends
   a NA with transmits towards the override (O) bit that is not set (per [RFC4429]), and
   an EARO option.  If LLN links.

5.  Optional 6LBR serving the router supports this specification, then it MultiLink Subnet

   A 6LBR can determine be deployed to serve the freshest EARO option whole MLSN.  It may be attached
   to the backbone, in which case of a conflicting
   NA(EARO) messages, using it can be discovered by its capability
   advertisement (see section 5.2.1 4.3. of [RFC8505].  If the NA(EARO) [RFC8505]) in RA messages.

   When a 6LBR is present, the freshest or only answer then the default router creates a BCE 6BBR uses an EDAR/EDAC message exchange
   with the SLLAO of the 6BBR (in Routing Proxy mode) 6LBR to check for duplication or that movement.  This is done
   prior to the NS(DAD) process, which may be avoided of the
   Registering Node (in Bridging Proxy mode) and traffic from/to 6LBR
   already maintains a conflicting state for the Registered Address can flow immediately.

4.  Updating RFC 4861 Address.

   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 enables an SLLAO.  Note address to be registered to more than
   one 6BBR.  It results that an NS(DAD)
   does not contain an SLLAO and thus cannot a 6LBR MUST be confused capable to maintain a state
   for each of the 6BBR having registered with a
   registration.

5.  Updating RFC 8505

   This specification adds same TID and same ROVR.

   If this registration is duplicate or not the capability to insert IPv6 ND options in freshest, then the EDAR and 6LBR
   replies with an EDAC messages.  In particular, message with a 6BBR acting as status code of 1 ("Duplicate
   Address") or 3 ("Moved"), respectively.  If this registration is the
   freshest, then the 6LBR replies with a 6LR status code of 0.  In that
   case, if this registration is fresher than an existing registration
   for another 6BBR, then the Registered Address can insert 6LBR also sends an asynchronous EDAC with
   a status of 4 ("Removed") to that other 6BBR.

   The EDAC message SHOULD carry the SLLAO used in NS messages by the
   6BBR for that Binding, and the EDAR to message SHOULD carry the
   6LBR in order to avoid a lookup back.

6.  6BBR detailed Operations

   By default, TLLAO
   associated with the currently accepted registration.  This enables a
   6BBR operates as a Sleeping Proxy, as follows:

   o  Create a to locate the new entry in position of a Binding Table for mobile 6LN in the case of a new Registered Address
   Routing Proxy operation, and ensure that opens the Address is not a duplicate over capability for the Backbone

   o  Defend 6LBR to
   serve as a Registered Address over the Backbone using NA messages
      with mapping server in the Override bit set on behalf future.

   Note that if Link Local addresses are registered, then the scope of
   uniqueness on which the sleeping 6LN

   o  Advertise a Registered Address over address duplication is checked is the Backbone using NA
      messages, asynchronously or as a response to a Neighbor
      Solicitation messages.

   o  To deliver packets arriving from total
   collection of links that the LLN, use Neighbor
      Solicitation messages 6LBR serves as opposed to look up the destination over the
      Backbone.

   o  Forward packets between the LLN and the Backbone.

   o  Verify liveliness when needed for a stale registration.

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

   The 6BBR does not act on assigned.

6.  Using IPv6 ND Messages over Over the Backbone unless they
   are relevant to a Registered Node on the LLN side, saving wireless
   interference. Link

   On the LLN Backbone side, the prefixes associated to 6BBR MUST join the
   MultiLink Subnet are presented as not on-link, so SNMA group corresponding
   to a Registered Address resolution
   for other hosts do not occur.

   As as soon as it creates a Unicasting Proxy, Binding for that
   Address, and maintain that SNMA membership as long as it maintains
   the registration.

   The 6BBR forwards NS lookup messages uses either the SNMA or plain unicast to defend the
   Registering Node, transforming Layer-2 multicast into unicast.  This
   is not possible
   Registered Addresses in UNREACHABLE state, so its Binding Table over the NS messages are
   multicasted, Backbone (as
   specified in [RFC4862]).

   The 6BBR advertises and rate-limited.  Retries are possible, using an
   exponential back-off to protect defends the medium.  In other states, Registered Addresses over the
   Backbone Link using RS, NS(DAD) and NA messages are forwarded to with the Registering Node Registered
   Address 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 Source or secondary. Target address, respectively.

   The primary is 6BBR MUST place an EARO in the Backbone
   router IPv6 ND messages that has the highest EUI-64 Address it generates
   on behalf of all the 6BBRs Registered Node.  Note that
   share an NS(DAD) does not
   contain an SLLAO and cannot be confused with a proxy registration for
   such as performed by a same Registered Address, with 6LBR.

   An NA message generated in response to an NS(DAD) MUST have the same
   ROVR
   Override flag set 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 status of whether 1 (Duplicate) or
   not the Addresses belong to 3 (Moved) in the same 6LN.  The primary Backbone
   Router is
   EARO.  An NA message generated in charge of protecting response to an NS(Lookup) or an
   NS(NUD) MUST NOT have the Address Override flag set.

   This specification enables proxy operation for DAD over the
   Backbone.  Any IPv6 ND resolution
   of the Primary LLN devices 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 prefix that is used across a MultiLink Subnet
   MAY be advertised as on-link over the Backbone
   to detect duplication.  Another document [RFC8505] provides details
   about how the EARO Backbone.  This is used between 6LRs and 6LBRs done for
   backward compatibility with existing IPv6 hosts by way of DAR/DAC
   messages within setting the LLN.  Addresses L flag
   in a LLN that can be reachable
   from the Backbone by way Prefix Information Option (PIO) of RA messages [RFC4861].

   For movement involving a 6BBR MUST be registered to that 6BBR.

   A false positive duplicate detection slow reattachment, the Neighbor
   Unreachability Detection (NUD) defined in [RFC4861] may arise over time out too
   quickly.  Nodes on the Backbone, backbone SHOULD support [RFC7048] whenever
   possible.

7.  Routing Proxy Operations

   A Routing Proxy provides IPv6 ND proxy functions 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 Global and
   Unique Local addresses between the
   6BBR transparently to LLN and the 6LN. 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 former case, one LBR becomes
   primary to defend MAC addresses of the Address 6LNs
   are visible at Layer-2 over the Backbone while the others
   become secondary and may still forward packets.  In Backbone.  It is thus useful when the latter case
   messaging over the LBR Backbone that receives the newest registration is associated to wireless mobility
   becomes primary because
   of expensive, e.g., when the TID.

   Only one 6LN may register Layer-2 topology is virtualized
   over a given Address at wide area IP underlay.

   This mode is definitely required when the LLN uses a particular 6BBR.
   However, MAC address
   format that Registered Address is different from that on the Backbone (e.g., EUI-64 vs.
   EUI-48).  Since a 6LN may not be registered able to Multiple 6BBRs
   for higher availability.

   Over resolve an arbitrary
   destination in the LLN, Binding Table management is MLSN directly, the MLSN prefix MUST NOT be
   advertised as follows:

      De-registrations (newer TID, same ROVR, null Lifetime) are
      accepted and acknowledged with on-link in RA messages sent towards the LLN.

   In order to maintain IP connectivity, the 6BBR installs a status of 4 (TBD); connected
   Host route to the entry is
      deleted;

      Newer registrations (newer TID, same ROVR, non-null Lifetime) are
      acknowledged with a status of 0 (success); the binding is updated
      with the new TID, Registered Address on the Registration Lifetime and LLN interface, via the
   Registering
      Node; in TENTATIVE state the acknowledgement is held and may be
      overwritten; in other states Node as identified by the Registration-Lifetime timer is
      restarted Source Address and the entry is placed SLLA
   option in REACHABLE state.

      Identical registrations (same TID, same ROVR) from a same
      Registering Node are acknowledged with the NS(EARO) messages.

   When operating as a status of 0 (success).
      If they are not identical, an error SHOULD be logged.  In
      TENTATIVE state, Routing Proxy, the response is held and may be overwritten, but
      it 6BBR MUST be eventually produced and it carries use its Layer-2
   Address on its Backbone Interface in the result SLLAO of the
      DAD process;

      Older registrations (older TID, same ROVR) from a Registering Node
      are ignored;

      Identical RS messages and older registrations (not-newer TID, same ROVR) from
      a different Registering Node are acknowledged with a status
   the TLLAO of 3
      (moved); this may be rate limited the NA messages that it generates to protect advertise the medium;

      Any registration for a different
   Registered Node (different ROVR)
      are acknowledged Addresses.

   For each Registered Address, multiple peers 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 status list of 1 (duplicate).

6.3.  Registration and Binding Table Entry Creation

   Upon receiving a registration for a new
   the peers on the Backbone which have associated its MAC Address with an NS(EARO) with
   the 'R' bit set, Registered Address.  If that Registered Address moves to a new
   6BBR, the previous 6BBR performs DAD over SHOULD unicast a gratuitous NA with the Backbone, placing
   Override flag set to each such peer, to supply the
   new Address as target in the NS(DAD) message.  The EARO from LLA of the
   registration MUST be placed unchanged new
   6BBR in the NS(DAD) message, and an
   Neighbor Cache entry created in TENTATIVE state TLLA option for a duration of
   TENTATIVE_DURATION.  The NS(DAD) message is sent multicast over the
   Backbone to the SNMA associated Address.  A 6BBR that does not
   maintain this list MAY multicast a gratuitous NA with the registered Address, unless
   that operation is known to be costly, and Override
   flag; this NA will possibly hit all the 6BBR has nodes on the Backbone,
   whether or not they maintain an indication
   from another source (such as a Neighbor Cache entry) that NCE for the Registered Address was known on the Backbone; in Address.

   If a correspondent fails to receive the latter case, an
   NS(DAD) message may be sent as gratuitous NA, it will keep
   sending traffic to a Layer-2 unicast 6BBR to which the MAC Address
   that node was associated with previously
   registered.  Since the Registered Address.

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

   1.  The entry is previous 6BBR removed if an NA is received over the Backbone for its Host route to 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 Address, it will look up the EARO received address over the Backbone are ignored.  A status of 1 is returned in backbone,
   resolve the
       EARO address with the LLA of the NA back new 6BBR, and forward the
   packet to the Registering Node;

   2. correct 6BBR.  The entry is previous 6BBR SHOULD also removed if an NA with an ARO option with issue a
       status
   redirect message [RFC4861] to update the cache of 3 (moved), or a NS with an ARO option that indicates a
       newer registration for the same Registered Node, is received over correspondent.

8.  Bridging Proxy Operations

   A Bridging Proxy provides IPv6 ND proxy functions between the Backbone for LLN and
   the Registered Address.  A status of 3 is
       returned in backbone while preserving the NA(EARO) back to forwarding continuity at the Registering Node;

   3.  When a registration is updated but not deleted, e.g. from MAC
   Layer.  It acts as a newer
       registration, the DAD process Layer-2 Bridge for all types unicast packets
   including link-scoped, and appears as an IPv6 Host on the Backbone continues and Backbone.

   The Bridging Proxy registers any Binding including for a Link-Local
   address to the
       running timers are not restarted;

   4.  Other NS (including DAD with no EARO) 6LBR (if present) and NA from defends it over the Backbone
       are not acknowledged backbone in TENTATIVE state.
   IPv6 ND procedures.

   To cover legacy 6LNs
       that do not support ODAD, achieve this, the list of their origins MAY be stored Bridging Proxy intercepts the IPv6 ND messages
   and then, if may reinject them on the TENTATIVE_DURATION timer elapses, other side, respond directly or drop
   them.  For instance, an ND(Lookup) from the 6BBR MAY
       send each such legacy 6LN backbone that matches a
   Binding can be responded directly, or turned into a unicast NA.

   5.  When on the TENTATIVE_DURATION timer elapses, a status 0 (success)
       is returned in a NA(EARO) back
   LLN side to let the Registering Node(s), and
       the entry goes to REACHABLE state for 6LN respond.

   As a Bridging Proxy, the Registration Lifetime.
       The 6BBR MUST send a multicast NA(EARO) to the SNMA associated to use the Registered Registering Node's Layer-2
   Address over in the Backbone with SLLAO of the Override bit
       set so as NS/RS messages and the TLLAO of the NA
   messages that it generates to take over advertise the binding from other 6BBRs.

6.4.  Defending Addresses

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

   o  If the 6BBR Addresses.
   The Registering Node's Layer-2 address is primary, or does not support found in the function SLLA of
      primary, it MUST defend the
   registration NS(EARO), and maintained in the Binding Table.

   The MultiLink Subnet 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 over
   address.  In that case, the Backbone upon
      receiving NS, 6BBR MUST either if answer directly to the NS does not carry an EARO,
   NS(Lookup) message or if an
      EARO is present that indicates reinject the message on the backbone, either as
   a different Layer-2 unicast or a multicast.

   If the Registering Node
      (different ROVR).  The 6BBR sends owns the Registered Address, then its
   mobility does not impact existing NCEs over the Backbone.  Otherwise,
   when the 6LN selects another Registering Node, the new Registering
   Node SHOULD send a multicast NA message with the Override
      bit flag set and the NA carries an EARO if and only if to fix the NS(DAD) did
      so.  When present,
   existing NCEs across the EARO in Backbone.  This method can fail if the NA(Override) that
   multicast message is sent in
      response to not received; one or more correspondent nodes on
   the NS(EARO) carries a status of 1 (duplicate), Backbone might maintain an stale NCE, and packets to the ROVR
   Registered Address may be lost.  When this condition happens, it is
   eventually be discovered and TID fields resolved using Neighbor Unreachability
   Detection (NUD) as defined in the EARO are obfuscated with null or
      random values to avoid network scanning [RFC4861].

9.  Creating and impersonation attacks.

   o  If the 6BBR receives an NS(EARO) Maintaining a Binding

   Upon receiving a registration for a newer registration, new Address (i.e., an NS(EARO)
   with the
      6BBR updates R flag set), the entry 6BBR creates a Binding and the routing state to forward packets operates as a
   6LR according to [RFC8505], interacting with the new 6BBR, but keeps the entry REACHABLE.  Afterwards, the 6BBR
      MAY use REDIRECT messages to reroute traffic for 6LBR if one is
   present.

   An implementation of a Routing Proxy that creates a Binding MUST also
   create an associated Host route pointing on the Registered
      Address to registering node in
   the new 6BBR.

   o  If LLN interface from which the 6BBR receives an NA(EARO) for registration was received.

   The 6LR operation is modified as follows:

   o  EDAR and EDAC messages SHOULD carry a newer registration, SLLAO and a TLLAO,
      respectively.

   o  A Bridging Proxy MAY register Link Local addresses to the 6BBR removes its entry and sends a NA(EARO)
      proxy ND for those addresses over the backbone.

   o  An EDAC message with a status of 3
      (MOVED) to the Registering Node, if the Registering Node 9 (6LBR Registry Saturated) is
      different from
      assimilated as a status of 0 if a following DAD process protects
      the Registered Node.  The 6BBR cleans up existing
      Neighbor Cache entries in peer address against duplication.

   This specification enables nodes as discussed in Section 3.5,
      by unicasting on a Backbone Link to each co-exist along
   with nodes implementing IPv6 ND [RFC4861] as well as other non-
   normative specifications such peer, or one broadcast NA(Override).

   o  If as [I-D.bi-savi-wlan].  It is possible
   that not all IPv6 addresses on the 6BBR receives a NS(LOOKUP) Backbone are registered and known
   to the 6LBR, and an EDAR/EDAC echange with the 6LBR might succeed
   even for a Registered Address, it
      answers immediately with duplicate address.  Consequently, and unless
   administratively overridden, the 6BBR still needs to perform IPv6 ND
   DAD over the backbone after an NA on behalf EDAC with a status code of 0 or 9.

   For the Registered Node,
      without polling it.  There DAD operation, the Binding is no need of an EARO placed in that exchange.

   o  When the Registration-Lifetime timer elapses, the entry goes to
      STALE Tentative state for a
   duration of STABLE_STALE_DURATION in LLNs that
      keep stable Addresses such as LWPANs, TENTATIVE_DURATION, and UNSTABLE_STALE_DURATION
      in LLNs where Addresses are renewed rapidly, e.g. for privacy
      reasons.

   The STALE state enables tracking of an NS(DAD) message is sent as a
   multicast message over the Backbone peers that have a
   Neighbor Cache entry pointing to this 6BBR in case the Registered SNMA associated with the
   registered Address shows up later. [RFC4862].  The EARO from the registration MUST be
   placed unchanged in the NS(DAD) message.

   If a registration is received for an existing Binding with a non-null
   Registration Lifetime and the Registered Address registration is claimed by
   another 6LN on fresher (same ROVR,
   fresher TID), then the Backbone, Binding is updated, with an NS(DAD) or an NA, the 6BBR does
   not defend new Registration
   Lifetime, TID, and possibly Registering Node.  In Tentative state
   (see Section 9.1), the Address. current DAD operation continues as it was.  In STALE state:

   o  If STALE_DURATION elapses,
   other states (see Section 9.2 and Section 9.3 ), the 6BBR removes Binding is
   placed in Reachable state for the entry.

   o  Upon receiving an NA(Override) Registration Lifetime, and the 6BBR removes its entry and
      sends a
   returns an NA(EARO) to the Registering Node with a status of 4 (removed) 0
   (Success).

   Upon a registration that is identical (same ROVR, TID, and
   Registering Node), the 6BBR returns an NA(EARO) back to the
   Registering
      Node.

   o Node with a status of 0 (Success).  A registration that
   is not as fresh (same ROVR, older TID) is ignored.

   If the 6BBR receives a NS(LOOKUP) registration is received for an existing Binding and a Registered Address,
   registration Lifetime of zero, then the Binding is removed, and the
   6BBR MUST send returns an NS(NUD) following rules in [RFC7048] NA(EARO) back to the Registering Node targeting the Registered Address prior to
      answering.  If with a status
   of 0 (Success).  An implementation of a Routing Proxy that removes a
   binding MUST remove the NUD succeeds, associated Host route pointing on the operation
   registering node.  It MAY preserve a temporary state in order to
   forward packets in REACHABLE flight.  The state
      applies.  If the NUD fails, may be a NCE formed based on a
   received NA message, or a Binding in Stale state and pointing at the
   new 6BBR refrains from answering on the
      lookup. backbone.

   The NUD SHOULD be used by the Registering Node implementation should also use REDIRECT messages as specified in
   [RFC4861] to
      indicate liveness of update the correspondents for the Registered Node, if they are different
      nodes.

7.  Security Considerations

   This specification applies to LLNS Address,
   pointing the new 6BBR.

9.1.  Operation on a Binding in which Tentative State

   The Tentative state covers a DAD period over the link layer backbone during
   which an address being registered is
   protected, either by means of physical or IP security checked for the
   Backbone Link or MAC sublayer cryptography.  In particular, the LLN
   MAC duplication using
   procedures defined in [RFC4862].

   For a Binding in Tentative state:

   o  The Binding MUST be removed if an NA message is required to provide secure unicast to/from received over the
      Backbone Router
   and secure Broadcast from for the Backbone Router in a way that prevents
   tampering Registered Address with no EARO, or replaying the RA messages.

   The use containing an
      EARO with a status of EUI-64 for forming 1 (Duplicate) that indicates an existing
      registration owned by a different Registering Node.  In that case,
      an NA MUST be sent back to the Interface ID Registering Node with a status of 1
      (Duplicate) 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 EARO.  This behavior might be overriden by [I-D.ietf-6lo-ap-nd], which guarantees the
   ownership of
      policy, in particular if the ROVR.

   When registration is trusted, e.g., based
      on the ownership validation of the ROVR cannot field (see [I-D.ietf-6lo-ap-nd]).

   o  An NS(DAD) with no EARO or with an EARO that indicates a duplicate
      registration (i.e. different ROVR) MUST 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 answered with an Address.

8.  Protocol Constants

   This Specification uses NA
      message containing an EARO with a status of 1 (Duplicate) and the following constants:

   TENTATIVE_DURATION:        800 milliseconds

   STABLE_STALE_DURATION:     24 hours

   UNSTABLE_STALE_DURATION:   5 minutes

   DEFAULT_NS_POLLING:        3 times

9.  IANA Considerations
      Override flag not set.  This document has no request to IANA.

10.  Future Work

   Future documents may extend this specification behavior might be overriden by allowing the 6BBR
   to redistribute host routes
      policy, in routing protocols that would operate particular if the registration is not trusted.

   o  The Binding MUST be removed if an NA message is received over the Backbone, or in MIPv6, or FMIP,
      Backbone for the Registered Address containing an EARO with a
      status of 3 (Moved), or an NS(DAD) with an EARO that indicates a
      fresher registration ([RFC8505]) for the Locator/ID Separation
   Protocol (LISP) [RFC6830] to support mobility on behalf same Registered Node
      (i.e. same ROVR).  A status of 3 is returned in the 6LNs,
   etc...

11.  Acknowledgments

   Many thanks NA(EARO) back
      to Dorothy Stanley, Thomas Watteyne the Registering Node.

   o  NS(DAD) and Jerome Henry for
   their various contributions.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words NA messages containing an EARO that indicates a
      registration for use the same Registered Node that is not as fresh as
      this SHOULD be answered with an NA message containing an EARO with
      a status of 3 (Moved) in RFCs order to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4291]  Hinden, R. clean up the situation
      immediately.

   o  Other NS(DAD) and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

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

   [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,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., NA messages from the Backbone are ignored.

   o  NS(Lookup) and T. Jinmei, "IPv6 Stateless
              Address Autoconfiguration", RFC 4862,
              DOI 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4862>.

   [RFC6059]  Krishnan, S. NS(NUD) messages SHOULD be optimistically answered
      with an NA message containing an EARO with a status of 0 and G. Daley, "Simple Procedures for
              Detecting Network Attachment 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.

   When the TENTATIVE_DURATION timer elapses, the Binding is placed in IPv6", RFC 6059,
              DOI 10.17487/RFC6059, November 2010,
              <https://www.rfc-editor.org/info/rfc6059>.

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

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

   [RFC8174]  Leiba, B., "Ambiguity the 6BBR returns
   an NA(EARO) to the Registering Node with a status of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8200]  Deering, S. 0 (Success).

   The 6BBR also attempts to take over any existing Binding from other
   6BBRs and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", STD 86, RFC 8200,
              DOI 10.17487/RFC8200, July 2017,
              <https://www.rfc-editor.org/info/rfc8200>.

   [RFC8201]  McCann, J., Deering, S., Mogul, J., to update existing NCEs in backbone nodes.  This is done by
   sending an NA message with an EARO and the Override flag set over the
   backbone (see Section 7 and Section 8).

9.2.  Operation on a Binding in Reachable State

   The Reachable state covers an active registration after a successful
   DAD process.

   An NS(DAD) with no EARO or with an EARO that indicates a duplicate 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.

   For a Binding in Reachable state:

   o  The Binding MUST be removed if an NA or an NS(DAD) message is
      received over the Backbone for the Registered Address containing
      an EARO that indicates a fresher registration ([RFC8505]) for the
      same Registered Node (i.e. same ROVR).  A status 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 small timer in order to a allow for a parallel registration
      to arrive to this node, in which case the NA might be ignored.

   o  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 of 1 (Duplicate) and the
      Override flag not set.

   o  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 of 3 (Moved).

   o  Other NS(DAD) and NA messages from the Backbone are ignored.

   o  NS(Lookup) and NS(NUD) messages SHOULD be answered with an NA
      message containing an EARO with a status of 0 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 behaviour 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.

9.3.  Operation on a Binding in Stale State

   The Stale state enables tracking of the Backbone peers that have a
   NCE 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.

   For a Binding in Stale state:

   o  The Binding MUST be removed if an NA or an NS(DAD) message is
      received over the Backbone for the Registered Address containing
      no EARO or an EARO that indicates either a fresher registration
      for the same Registered Node or a duplicate registration.  A
      status of 4 (Removed) MAY be returned in an asynchronous NA(EARO)
      to the Registering Node.

   o  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 of 3 (Moved).

   o  If the 6BBR receives an NS(Lookup) or an NS(NUD) message for the
      Registered Address, the 6BBR MUST attempts 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.

   o  Other NS(DAD) and R. Hinden, Ed.,
              "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
              DOI 10.17487/RFC8201, July 2017,
              <https://www.rfc-editor.org/info/rfc8201>. NA messages from the Backbone are ignored.

   When the STALE_DURATION timer elapses, the Binding MUST be removed.

10.  Registering Node Considerations

   A Registering Node MUST implement [RFC8505]  Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
              Perkins, "Registration Extensions for in order to interact with
   a 6BBR (which acts as a routing registrar).  Following [RFC8505], the
   Registering Node signals that it requires IPv6 proxy-ND services from
   a 6BBR by registering the corresponding IPv6 Address using an
   NS(EARO) message with the R flag set.

   The Registering Node may be the 6LN owning 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 IPv6 Addresses to its
   6LR, which is the 6BBR when they are connected at Layer-2.  Failure
   to register an address may result in the address being unreachable by
   other parties if the 6BBR cancels the NS(Lookup) over Low-Power
              Wireless Personal Area Network (6LoWPAN) Neighbor
              Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
              <https://www.rfc-editor.org/info/rfc8505>.

12.2.  Informative References

   [I-D.bi-savi-wlan]
              Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution the LLN or to
   selected LLN nodes that are known to register their addresses.

   The Registering Node MUST refrain from using multicast NS(Lookup)
   when the destination is not known as on-link, e.g., if the prefix is
   advertised in a PIO with the L flag that is not set.  In that case,
   the Registering Node sends its packets directly to its 6LR.

   The Registering Node SHOULD also follow [RFC7772] in order to limit
   the use of multicast RAs.  It SHOULD also implement Simple Procedures
   for
              WLAN", draft-bi-savi-wlan-16 (work Detecting Network Attachment in progress), November
              2018.

   [I-D.ietf-6lo-ap-nd]
              Thubert, P., Sarikaya, B., Sethi, M., IPv6 [RFC6059] (DNA procedures)
   to detect movements, and R. Struik,
              "Address Protected Neighbor Discovery support Packet-Loss Resiliency for Low-power and
              Lossy Networks", draft-ietf-6lo-ap-nd-08 (work Router
   Solicitations [RFC7559] in
              progress), October 2018.

   [I-D.ietf-6man-rs-refresh]
              Nordmark, E., Yourtchenko, A., and S. Krishnan, "IPv6
              Neighbor Discovery Optional RS/RA Refresh", draft-ietf-
              6man-rs-refresh-02 (work order to improve reliability for the
   unicast RS messages.

11.  Security Considerations

   This specification applies to LLNs in progress), October 2016.

   [I-D.ietf-6tisch-architecture]
              Thubert, P., "An Architecture which the link layer is
   protected, either by means of physical or IP security for IPv6 the
   Backbone Link or MAC-layer security.  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.

   A possible attack over the TSCH mode backbone can be done by sending an NS with
   an EARO and expecting the NA(EARO) back to contain the TID and ROVR
   fields of IEEE 802.15.4", draft-ietf-6tisch-architecture-17 (work the existing state.  With that information, the attacker
   can easily increase the TID and take over the Binding.
   [I-D.ietf-6lo-ap-nd] guarantees the ownership of a registered address
   based on a proof-of-ownership encoded in progress), November 2018.

   [I-D.ietf-mboned-ieee802-mcast-problems]
              Perkins, C., McBride, M., Stanley, D., Kumari, W., the ROVR field and J.
              Zuniga, "Multicast protects
   against address theft and impersonation.

12.  Protocol Constants

   This Specification uses the following constants:

   TENTATIVE_DURATION:       800 milliseconds

   STALE_DURATION:           see below

   In LLNs with long-lived Addresses such as LPWANs, STALE_DURATION
   SHOULD be configured with a relatively long value, by default 24
   hours.  In LLNs where addresses are renewed rapidly, e.g. for privacy
   reasons, STALE_DURATION SHOULD be configured with a relatively long
   value, by default 5 minutes.

13.  IANA Considerations over IEEE 802 Wireless
              Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work
              in progress), November 2018.

   [I-D.nordmark-6man-dad-approaches]
              Nordmark, E., "Possible approaches

   This document has no request to make DAD more robust
              and/or efficient", draft-nordmark-6man-dad-approaches-02
              (work in progress), October 2015.

   [I-D.yourtchenko-6man-dad-issues]
              Yourtchenko, A. and E. Nordmark, "A survey of issues
              related IANA.

14.  Acknowledgments

   Many thanks to IPv6 Duplicate Address Detection", draft-
              yourtchenko-6man-dad-issues-01 (work in progress), March
              2015.

   [RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., Dorothy Stanley, Thomas Watteyne and P. Nikander,
              "SEcure Neighbor Discovery (SEND)", Jerome Henry for
   their various contributions.

15.  References

15.1.  Normative References

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

   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)", 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 3972, 4291, DOI 10.17487/RFC3972, March 2005,
              <https://www.rfc-editor.org/info/rfc3972>.

   [RFC4389]  Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
              Proxies (ND Proxy)", 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

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

   [RFC4903]  Thaler, D., "Multi-Link Subnet Issues",
              <https://www.rfc-editor.org/info/rfc4429>.

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

   [RFC4919]  Kushalnagar, N., Montenegro, G.,
              <https://www.rfc-editor.org/info/rfc4861>.

   [RFC4862]  Thomson, S., Narten, T., and C. Schumacher, T. Jinmei, "IPv6
              over Low-Power Wireless Personal Area Networks (6LoWPANs):
              Overview, Assumptions, Problem Statement, and Goals", Stateless
              Address Autoconfiguration", RFC 4919, 4862,
              DOI 10.17487/RFC4919, August 10.17487/RFC4862, September 2007,
              <https://www.rfc-editor.org/info/rfc4919>.

   [RFC5415]  Calhoun, P.,
              <https://www.rfc-editor.org/info/rfc4862>.

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

   [RFC6550]  Winter, T., Ed., Montemurro, M., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and D. Stanley,
              Ed., "Control And Provisioning of Wireless Access Points
              (CAPWAP) R. Alexander, "RPL: IPv6 Routing Protocol Specification", for
              Low-Power and Lossy Networks", RFC 5415, 6550,
              DOI 10.17487/RFC5415, 10.17487/RFC6550, March 2009,
              <https://www.rfc-editor.org/info/rfc5415>.

   [RFC6275]  Perkins, C., 2012,
              <https://www.rfc-editor.org/info/rfc6550>.

   [RFC6775]  Shelby, Z., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <https://www.rfc-editor.org/info/rfc6275>.

   [RFC6606]  Kim, Chakrabarti, S., Nordmark, E., Kaspar, D., Gomez, C., and C.
              Bormann, "Problem
              Statement and Requirements "Neighbor Discovery Optimization for IPv6 over
              Low-Power Wireless Personal Area Network (6LoWPAN) Routing", Networks (6LoWPANs)",
              RFC 6606, 6775, DOI 10.17487/RFC6606, May 10.17487/RFC6775, November 2012,
              <https://www.rfc-editor.org/info/rfc6606>.

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

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

   [RFC7559]

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

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

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

   [RFC8505]  Thubert, P., Ed., 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,
              <https://www.rfc-editor.org/info/rfc8505>.

15.2.  Informative References

   [I-D.bi-savi-wlan]
              Bi, J., Wu, J., Wang, Y., and T. Lin, "A SAVI Solution for
              WLAN", draft-bi-savi-wlan-16 (work in progress), November
              2018.

   [I-D.ietf-6lo-ap-nd]
              Thubert, P., Sethi, M., Struik, R., and B. Sarikaya,
              "Address Protected Neighbor Discovery for Low-power and
              Lossy Networks", draft-ietf-6lo-ap-nd-09 (work in
              progress), December 2018.

   [I-D.ietf-6man-rs-refresh]
              Nordmark, E., Yourtchenko, A., and S. Krishnan, S., Anipko, "IPv6
              Neighbor Discovery Optional RS/RA Refresh", draft-ietf-
              6man-rs-refresh-02 (work in progress), October 2016.

   [I-D.ietf-6tisch-architecture]
              Thubert, P., "An Architecture for IPv6 over the TSCH mode
              of IEEE 802.15.4", draft-ietf-6tisch-architecture-19 (work
              in progress), December 2018.

   [I-D.ietf-mboned-ieee802-mcast-problems]
              Perkins, C., McBride, M., Stanley, D., Kumari, W., and D. Thaler, "Packet-Loss
              Resiliency for Router Solicitations", RFC 7559,
              DOI 10.17487/RFC7559, May 2015,
              <https://www.rfc-editor.org/info/rfc7559>.

   [RFC7772] J.
              Zuniga, "Multicast Considerations over IEEE 802 Wireless
              Media", draft-ietf-mboned-ieee802-mcast-problems-04 (work
              in progress), November 2018.

   [I-D.nordmark-6man-dad-approaches]
              Nordmark, E., "Possible approaches to make DAD more robust
              and/or efficient", draft-nordmark-6man-dad-approaches-02
              (work in progress), October 2015.

   [I-D.yourtchenko-6man-dad-issues]
              Yourtchenko, A. and L. Colitti, "Reducing Energy
              Consumption E. Nordmark, "A survey of Router Advertisements", BCP 202, RFC 7772,
              DOI 10.17487/RFC7772, February 2016,
              <https://www.rfc-editor.org/info/rfc7772>.

   [RFC8273]  Brzozowski, J. and G. Van de Velde, "Unique issues
              related to IPv6 Prefix
              per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
              <https://www.rfc-editor.org/info/rfc8273>.

12.3.  External Informative References Duplicate Address Detection", draft-
              yourtchenko-6man-dad-issues-01 (work in progress), March
              2015.

   [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)". Networks (LR-WPANs)".

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

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

   [RFC5415]  Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley,
              Ed., "Control And Provisioning of Wireless Access Points
              (CAPWAP) Protocol Specification", RFC 5415,
              DOI 10.17487/RFC5415, March 2009,
              <https://www.rfc-editor.org/info/rfc5415>.

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

   [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,
              <https://www.rfc-editor.org/info/rfc6606>.

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

   [RFC7559]  Krishnan, S., Anipko, D., and D. Thaler, "Packet-Loss
              Resiliency for Router Solicitations", RFC 7559,
              DOI 10.17487/RFC7559, May 2015,
              <https://www.rfc-editor.org/info/rfc7559>.

   [RFC7772]  Yourtchenko, A. and L. Colitti, "Reducing Energy
              Consumption of Router Advertisements", BCP 202, RFC 7772,
              DOI 10.17487/RFC7772, February 2016,
              <https://www.rfc-editor.org/info/rfc7772>.

   [RFC8273]  Brzozowski, J. and G. Van de Velde, "Unique IPv6 Prefix
              per Host", RFC 8273, DOI 10.17487/RFC8273, December 2017,
              <https://www.rfc-editor.org/info/rfc8273>.

Appendix A.  Possible Future Extensions

   With the current specification, the 6LBR is not leveraged to avoid
   multicast NS(Lookup) on the Backbone.  This could be done by adding a
   lookup procedure in the EDAR/EDAC exchange.

   By default the specification does not have a trust model, e.g.,
   whereby nodes that associate their address with a proof-of-ownership
   [I-D.ietf-6lo-ap-nd] should be more trusted than nodes that do not.
   Such a trust model and related signaling could be added in the future
   to override the default operation and favor trusted nodes.

   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) [RFC6830] to support mobility on behalf of the 6LNs,
   etc...  LISP may also be used to provide an equivalent to the EDAR/
   EDAC exchange using a Map Server / Map Resolver as a replacement to
   the 6LBR.

Appendix B.  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 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. STD
   802.11ah and IEEE STD. 802.15.4 STD.802.15.4 wireless meshes, so as to
   address meeting the
   requirements listed in Appendix B.3 of [RFC8505] "Requirements
   Related to Various Low-Power Link Types".

   Each LLN in the subnet is anchored attached 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

   A 6LN may can register its IPv6 Addresses and thereby obtain proxy-ND
   services over the Backbone, providing a solution to meeting the requirements expressed in
   Appendix B.4 of [RFC8505] [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, those cases, the wireless client
   (STA) is the 6LN [RFC8505] that makes use of this
   specification [RFC8505] 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 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 [I-D.ietf-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

   Scalability of the MultiLink Subnet [RFC4903] requires that avoidance of
   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