path: root/doc/rfc/rfc9159.txt

Internet Engineering Task Force (IETF)                          C. Gomez
Request for Comments: 9159                                 S.M. Darroudi
Category: Standards Track           Universitat Politecnica de Catalunya
ISSN: 2070-1721                                            T. Savolainen
                                                            Unaffiliated
                                                               M. Spoerk
                                           Graz University of Technology
                                                           December 2021


   IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol
                         Support Profile (IPSP)

Abstract

   RFC 7668 describes the adaptation of IPv6 over Low-Power Wireless
   Personal Area Network (6LoWPAN) techniques to enable IPv6 over
   Bluetooth Low Energy (Bluetooth LE) networks that follow the star
   topology.  However, recent Bluetooth specifications allow the
   formation of extended topologies as well.  This document specifies
   mechanisms that are needed to enable IPv6 mesh over Bluetooth LE
   links established by using the Bluetooth Internet Protocol Support
   Profile (IPSP).  This document does not specify the routing protocol
   to be used in an IPv6 mesh over Bluetooth LE links.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc9159.

Copyright Notice

   Copyright (c) 2021 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 Revised BSD License text as described in Section 4.e of the
   Trust Legal Provisions and are provided without warranty as described
   in the Revised BSD License.

Table of Contents

   1.  Introduction
     1.1.  Terminology and Requirements Language
   2.  Bluetooth LE Networks and the IPSP
   3.  Specification of IPv6 Mesh over Bluetooth LE Links
     3.1.  Protocol Stack
     3.2.  Subnet Model
     3.3.  Link Model
       3.3.1.  Stateless Address Autoconfiguration
       3.3.2.  Neighbor Discovery
       3.3.3.  Header Compression
       3.3.4.  Unicast and Multicast Mapping
   4.  IANA Considerations
   5.  Security Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Appendix A.  Bluetooth LE Connection Establishment Example
   Appendix B.  Node-Joining Procedure
   Acknowledgements
   Contributors
   Authors' Addresses

1.  Introduction

   Bluetooth Low Energy (hereinafter, Bluetooth LE) was first introduced
   in the Bluetooth 4.0 specification.  Bluetooth LE (which has been
   marketed as Bluetooth Smart) is a low-power wireless technology
   designed for short-range control and monitoring applications.
   Bluetooth LE is currently implemented in a wide range of consumer
   electronics devices, such as smartphones and wearable devices.  Given
   the high potential of this technology for the Internet of Things, the
   Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have
   produced specifications in order to enable IPv6 over Bluetooth LE,
   such as the Internet Protocol Support Profile (IPSP) [IPSP] and RFC
   7668 [RFC7668], respectively.  Bluetooth 4.0 only supports Bluetooth
   LE networks that follow the star topology.  As a consequence, RFC
   7668 [RFC7668] was specifically developed and optimized for that type
   of network topology.  However, the functionality described in RFC
   7668 [RFC7668] is not sufficient and would fail to enable an IPv6
   mesh over Bluetooth LE links.  This document specifies mechanisms
   that are needed to enable IPv6 mesh over Bluetooth LE links.  This
   document does not specify the routing protocol to be used in an IPv6
   mesh over Bluetooth LE links.

1.1.  Terminology and Requirements Language

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

   The terms "6LoWPAN Node" (6LN), "6LoWPAN Router" (6LR), and "6LoWPAN
   Border Router" (6LBR) are defined as in [RFC6775], with an addition
   that Bluetooth LE central and Bluetooth LE peripheral (see Section 2)
   can both be adopted by a 6LN, a 6LR, or a 6LBR.

2.  Bluetooth LE Networks and the IPSP

   Bluetooth LE defines two Generic Access Profile (GAP) roles of
   relevance herein: the Bluetooth LE central role and the Bluetooth LE
   peripheral role.  In Bluetooth 4.0, a device in the central role,
   which is called "central" from now on, was able to manage multiple
   simultaneous connections with a number of devices in the peripheral
   role, called "peripherals" hereinafter.  Bluetooth 4.1 (now
   deprecated) introduced the possibility for a peripheral to be
   connected to more than one central simultaneously, therefore allowing
   extended topologies beyond the star topology for a Bluetooth LE
   network [BTCorev4.1].  In addition, a device may simultaneously be a
   central in a set of link-layer connections, as well as a peripheral
   in others.

   On the other hand, the IPSP enables discovery of IP-enabled devices
   and the establishment of a link-layer connection for transporting
   IPv6 packets.  The IPSP defines the Node and Router roles for devices
   that consume/originate IPv6 packets and for devices that can route
   IPv6 packets, respectively.  Consistent with Bluetooth 4.1, Bluetooth
   4.2 [BTCorev4.2], and subsequent Bluetooth versions, a device may
   implement both roles simultaneously.

   This document assumes a mesh network composed of Bluetooth LE links,
   where link-layer connections are established between neighboring
   IPv6-enabled devices (see Section 3.3.2, item 3.b, and an example in
   Appendix A).  The IPv6 forwarding devices of the mesh have to
   implement both IPSP Node and Router roles, while simpler leaf-only
   nodes can implement only the Node role.  In an IPv6 mesh over
   Bluetooth LE links, a node is a neighbor of another node, and vice
   versa, if a link-layer connection has been established between both
   by using the IPSP functionality for discovery and link-layer
   connection establishment for IPv6 packet transport.

3.  Specification of IPv6 Mesh over Bluetooth LE Links

3.1.  Protocol Stack

   Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth
   LE links.  The core Bluetooth LE protocol stack comprises two main
   sections: the Controller and the Host.  The former includes the
   Physical Layer and the Link Layer, whereas the latter is composed of
   the Logical Link Control and Adaptation Protocol (L2CAP), the
   Attribute Protocol (ATT), and the Generic Attribute Profile (GATT).
   The Host and the Controller sections are connected by means of the
   Host-Controller Interface (HCI).  A device that supports the IPSP
   Node role instantiates one Internet Protocol Support Service (IPSS),
   which runs atop GATT.  The protocol stack shown in Figure 1 shows two
   main differences with the IPv6 over Bluetooth LE stack in [RFC7668]:

   a)  the adaptation layer below IPv6 (labeled as "6Lo for IPv6 mesh
       over Bluetooth LE") is now adapted for IPv6 mesh over Bluetooth
       LE links, and

   b)  the protocol stack for IPv6 mesh over Bluetooth LE links includes
       IPv6 routing functionality.


                          +------------------------------------+
                          |             Application            |
             +---------+  +------------------------------------+
             |  IPSS   |  |            UDP/TCP/other           |
             +---------+  +------------------------------------+
             |  GATT   |  |             IPv6  |routing|        |
             +---------+  +------------------------------------+
             |  ATT    |  | 6Lo for IPv6 mesh over Bluetooth LE|
             +---------+--+------------------------------------+
             |                 Bluetooth LE L2CAP              |
     HCI - - +-------------------------------------------------+ - -
             |               Bluetooth LE Link Layer           |
             +-------------------------------------------------+
             |             Bluetooth LE Physical Layer         |
             +-------------------------------------------------+

       Figure 1: Protocol Stack for IPv6 Mesh over Bluetooth LE Links

   Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes.
   Excluding the L2CAP header of 4 bytes, a protocol data unit (PDU)
   size of 247 bytes is available for the layer above L2CAP.  (Note:
   Earlier Bluetooth LE versions offered a maximum amount of 23 bytes
   for the layer atop L2CAP.)  The L2CAP provides a fragmentation and
   reassembly solution for transmitting or receiving larger PDUs.  At
   each link, the IPSP defines means for negotiating a link-layer
   connection that provides an MTU of 1280 octets or higher for the IPv6
   layer [IPSP].  As per the present specification, the MTU size for
   IPv6 mesh over BLE links is 1280 octets.

   Similarly to [RFC7668], fragmentation functionality from 6LoWPAN
   standards is not used for IPv6 mesh over Bluetooth LE links.
   Bluetooth LE's fragmentation support provided by L2CAP is used.

3.2.  Subnet Model

   For IPv6 mesh over Bluetooth LE links, a multilink model has been
   chosen, as further illustrated in Figure 2.  As IPv6 over Bluetooth
   LE is intended for constrained nodes and for Internet of Things use
   cases and environments, the complexity of implementing a separate
   subnet on each peripheral-central link and routing between the
   subnets appears to be excessive.  In this specification, the benefits
   of treating the collection of point-to-point links between a central
   and its connected peripherals as a single multilink subnet rather
   than a multiplicity of separate subnets are considered to outweigh
   the multilink model's drawbacks as described in [RFC4903].  With the
   multilink subnet model, the routers have to take on the
   responsibility of tracking the multicast state and forwarding
   multicast in a loop-free manner.  Note that the route-over
   functionality defined in [RFC6775] is essential to enabling the
   multilink subnet model for IPv6 mesh over Bluetooth LE links.

                                                          /
                                                         /
            6LR           6LN        6LN                /
               \             \          \              /
                \             \          \            /
       6LN ----- 6LR --------- 6LR ------ 6LBR ----- |  Internet
        <--Link--> <---Link--->/<--Link->/           |
                              /         /             \
                  6LN ---- 6LR ----- 6LR               \
                                                        \
                                                         \

     <------------ Subnet -----------------><---- IPv6 connection -->
                                                  to the Internet

       Figure 2: Example of an IPv6 Mesh over a Bluetooth LE Network
                         Connected to the Internet

   One or more 6LBRs are connected to the Internet. 6LNs are connected
   to the network through a 6LR or a 6LBR.  Note that in some scenarios
   and/or for some time intervals, a 6LR may remain at the edge of the
   network (e.g., the top left node in Figure 2).  This may happen when
   a 6LR has no neighboring 6LNs.  A single global unicast prefix is
   used on the whole subnet.

   IPv6 mesh over Bluetooth LE links MUST follow a route-over approach.
   This document does not specify the routing protocol to be used in an
   IPv6 mesh over Bluetooth LE links.

3.3.  Link Model

3.3.1.  Stateless Address Autoconfiguration

   6LN, 6LR, and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE
   links are configured as per Section 3.2.2 of [RFC7668].

   Multihop Duplicate Address Detection (DAD) functionality as defined
   in Section 8.2 of [RFC6775] and updated by [RFC8505], or some
   substitute mechanism (see Section 3.3.2), MAY be supported.

3.3.2.  Neighbor Discovery

   "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
   Personal Area Networks (6LoWPANs)" [RFC6775], subsequently updated by
   "Registration Extensions for IPv6 over Low-Power Wireless Personal
   Area Network (6LoWPAN) Neighbor Discovery" [RFC8505], describes the
   neighbor discovery functionality adapted for use in several 6LoWPAN
   topologies, including the mesh topology.  The route-over
   functionality of [RFC6775] and [RFC8505] MUST be supported.

   The following aspects of the Neighbor Discovery optimizations for
   6LoWPAN [RFC6775] [RFC8505] are applicable to Bluetooth LE 6LNs:

   1.  A Bluetooth LE 6LN MUST register its non-link-local addresses
       with its routers by sending a Neighbor Solicitation (NS) message
       with the Extended Address Registration Option (EARO) and process
       the Neighbor Advertisement (NA) accordingly.  The EARO option
       includes a Registration Ownership Verifier (ROVR) field
       [RFC8505].  In the case of Bluetooth LE, by default, the ROVR
       field is filled with the 48-bit device address used by the
       Bluetooth LE node converted into 64-bit Modified EUI-64 format
       [RFC4291].  Optionally, a cryptographic ID (see RFC 8928
       [RFC8928]) MAY be placed in the ROVR field.  If a cryptographic
       ID is used, address registration and multihop DAD formats and
       procedures defined in [RFC8928] MUST be used unless an
       alternative mechanism offering equivalent protection is used.

       As per [RFC8505], a 6LN link-local address does not need to be
       unique in the multilink subnet.  A link-local address only needs
       to be unique from the perspective of the two nodes that use it to
       communicate (e.g., the 6LN and the 6LR in an NS/NA exchange).
       Therefore, the exchange of Extended Duplicate Address Request
       (EDAR) and Extended Duplicate Address Confirmation (EDAC)
       messages between the 6LR and a 6LBR, which ensures that an
       address is unique across the domain covered by the 6LBR, does not
       need to take place for link-local addresses.

       If the 6LN registers multiple addresses that are not based on the
       Bluetooth device address using the same compression context, the
       header compression efficiency may decrease, since only the last
       registered address can be fully elided (see Section 3.2.4 of
       [RFC7668]).

   2.  For sending Router Solicitations and processing Router
       Advertisements, the hosts that participate in an IPv6 mesh over
       BLE MUST, respectively, follow Sections 5.3 and 5.4 of [RFC6775],
       and Section 5.6 of [RFC8505].

   3.  The router behavior for 6LRs and 6LBRs is described in Section 6
       of [RFC6775] and updated by [RFC8505].  However, as per this
       specification:

       a.  Routers SHALL NOT use multicast NSs to discover other
           routers' link-layer addresses.

       b.  As per Section 6.2 of [RFC6775], in a dynamic configuration
           scenario, a 6LR comes up as a non-router and waits to receive
           a Router Advertisement for configuring its own interface
           address first before setting its interfaces to advertising
           interfaces and turning into a router.  In order to support
           such an operation in an IPv6 mesh over Bluetooth LE links, a
           6LR first uses the IPSP Node role only.  Once the 6LR has
           established a connection with another node currently running
           as a router and receives a Router Advertisement from that
           router, the 6LR configures its own interface address, turns
           into a router, and runs as an IPSP Router.  In contrast with
           a 6LR, a 6LBR uses the IPSP Router role since the 6LBR is
           initialized; that is, the 6LBR uses both the IPSP Node and
           IPSP Router roles at all times.  See an example in
           Appendix B.

   4.  Border router behavior is described in Section 7 of [RFC6775] and
       updated by [RFC8505].

       [RFC6775] defines substitutable mechanisms for distributing
       prefixes and context information (Section 8.1 of [RFC6775]), as
       well as for duplicate address detection across a route-over
       6LoWPAN (Section 8.2 of [RFC6775]).  [RFC8505] updates those
       mechanisms and the related message formats.  Implementations of
       this specification MUST either support the features described in
       Sections 8.1 and 8.2 of [RFC6775], as updated by [RFC8505] or
       some alternative ("substitute") mechanism.

3.3.3.  Header Compression

   Header compression as defined in RFC 6282 [RFC6282], which specifies
   the compression format for IPv6 datagrams on top of IEEE 802.15.4, is
   REQUIRED as the basis for IPv6 header compression on top of Bluetooth
   LE.  All headers MUST be compressed according to RFC 6282 [RFC6282]
   encoding formats.

   To enable efficient header compression, when the 6LBR sends a Router
   Advertisement, it MAY include a 6LoWPAN Context Option (6CO)
   [RFC6775] matching each address prefix advertised via a Prefix
   Information Option (PIO) [RFC4861] for use in stateless address
   autoconfiguration.  Note that 6CO is not needed for context-based
   compression when the context is pre-provisioned or provided by out-
   of-band means as, in these cases, the in-band indication (6CO)
   becomes superfluous.

   The specific optimizations of [RFC7668] for header compression, which
   exploited the star topology and Address Registration Option (ARO)
   (note that the latter has been updated by EARO as per [RFC8505]),
   cannot be generalized in an IPv6 mesh over Bluetooth LE links.
   Still, a subset of those optimizations can be applied in some cases
   in such a network.  These cases comprise link-local interactions,
   non-link-local packet transmissions originated by a 6LN (i.e., the
   first hop from a 6LN), and non-link-local packets intended for a 6LN
   that are originated or forwarded by a neighbor of that 6LN (i.e., the
   last hop toward a 6LN).  For all other packet transmissions, context-
   based compression MAY be used.

   When a device transmits a packet to a neighbor, the sender MUST fully
   elide the source Interface Identifier (IID) if the source IPv6
   address is the link-local address based on the sender's Bluetooth
   device address (SAC=0, SAM=11).  The sender also MUST fully elide the
   destination IPv6 address if it is the link-local address based on the
   neighbor's Bluetooth device address (DAC=0, DAM=11).

   When a 6LN transmits a packet with a non-link-local source address
   that the 6LN has registered with EARO in the next-hop router for the
   indicated prefix, the source address MUST be fully elided if it is
   the latest address that the 6LN has registered for the indicated
   prefix (SAC=1, SAM=11).  If the source non-link-local address is not
   the latest registered by the 6LN and the first 48 bits of the IID
   match the latest address are registered by the 6LN, then the last 16
   bits of the IID SHALL be carried inline (SAC=1, SAM=10).  Otherwise,
   if the first 48 bits of the IID do not match, then the 64 bits of the
   IID SHALL be fully carried inline (SAC=1, SAM=01).

   When a router transmits a packet to a neighboring 6LN with a non-
   link-local destination address, the router MUST fully elide the
   destination IPv6 address if the destination address is the latest
   registered by the 6LN with EARO for the indicated context (DAC=1,
   DAM=11).  If the destination address is a non-link-local address and
   not the latest registered and if the first 48 bits of the IID match
   those of the latest registered address, then the last 16 bits of the
   IID SHALL be carried inline (DAC=1, DAM=10).  Otherwise, if the first
   48 bits of the IID do not match, then the 64 bits of the IID SHALL be
   fully carried in-line (DAC=1, DAM=01).

3.3.4.  Unicast and Multicast Mapping

   The Bluetooth LE Link Layer does not support multicast.  Hence,
   traffic is always unicast between two Bluetooth LE neighboring nodes.
   If a node needs to send a multicast packet to several neighbors, it
   has to replicate the packet and unicast it on each link.  However,
   this may not be energy efficient, and particular care must be taken
   if the node is battery powered.  A router (i.e., a 6LR or a 6LBR)
   MUST keep track of neighboring multicast listeners, and it MUST NOT
   forward multicast packets to neighbors that have not registered as
   listeners for multicast groups to which the packets are destined.

4.  IANA Considerations

   This document has no IANA actions.

5.  Security Considerations

   The security considerations in [RFC7668] apply.

   IPv6 mesh over BLE requires a routing protocol to find end-to-end
   paths.  Unfortunately, the routing protocol may generate additional
   opportunities for threats and attacks to the network.

   RFC 7416 [RFC7416] provides a systematic overview of threats and
   attacks on the IPv6 Routing Protocol for Low-Power and Lossy Networks
   (RPL), as well as countermeasures.  In that document, described
   threats and attacks comprise threats due to failures to authenticate,
   threats due to failure to keep routing information, threats and
   attacks on integrity, and threats and attacks on availability.
   Reported countermeasures comprise confidentiality attack, integrity
   attack, and availability attack countermeasures.

   While this specification does not state the routing protocol to be
   used in IPv6 mesh over Bluetooth LE links, the guidance of [RFC7416]
   is useful when RPL is used in such scenarios.  Furthermore, such
   guidance may partly apply for other routing protocols as well.

   The ROVR can be derived from the Bluetooth device address.  However,
   such a ROVR can be spoofed; therefore, any node connected to the
   subnet and aware of a registered-address-to-ROVR mapping could
   perform address theft and impersonation attacks.  Use of Address
   Protected Neighbor Discovery [RFC8928] provides protection against
   such attacks.

6.  References

6.1.  Normative References

   [BTCorev4.2]
              Bluetooth, "Core Specification 4.2", 2 December 2014,
              <https://www.bluetooth.com/specifications/specs/core-
              specification-4-2/>.

   [IPSP]     Bluetooth, "Internet Protocol Support Profile 1.0", 16
              December 2014,
              <https://www.bluetooth.com/specifications/specs/internet-
              protocol-support-profile-1-0/>.

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

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291, February
              2006, <https://www.rfc-editor.org/info/rfc4291>.

   [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>.

   [RFC6282]  Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
              Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
              DOI 10.17487/RFC6282, September 2011,
              <https://www.rfc-editor.org/info/rfc6282>.

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

   [RFC7668]  Nieminen, J., Savolainen, T., Isomaki, M., Patil, B.,
              Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low
              Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015,
              <https://www.rfc-editor.org/info/rfc7668>.

   [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>.

   [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>.

   [RFC8928]  Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik,
              "Address-Protected Neighbor Discovery for Low-Power and
              Lossy Networks", RFC 8928, DOI 10.17487/RFC8928, November
              2020, <https://www.rfc-editor.org/info/rfc8928>.

6.2.  Informative References

   [BTCorev4.1]
              Bluetooth, "Core Specification 4.1", 3 December 2013,
              <https://www.bluetooth.com/specifications/specs/core-
              specification-4-1/>.

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

   [RFC7416]  Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
              and M. Richardson, Ed., "A Security Threat Analysis for
              the Routing Protocol for Low-Power and Lossy Networks
              (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
              <https://www.rfc-editor.org/info/rfc7416>.

Appendix A.  Bluetooth LE Connection Establishment Example

   This appendix provides an example of Bluetooth LE connection
   establishment and use of IPSP roles in an IPv6 mesh over BLE that
   uses dynamic configuration.  The example follows text in
   Section 3.3.2, item 3.b.

   The example assumes a network with one 6LBR, two 6LRs, and three
   6LNs, as shown in Figure 3.  Connectivity between the 6LNs and the
   6LBR is only possible via the 6LRs.

   The following text describes the different steps in the example as
   time evolves.  Note that other sequences of events that may lead to
   the same final scenario are also possible.

   At the beginning, the 6LBR starts running as an IPSP router, whereas
   the rest of devices are not yet initialized (Step 1).  Next, the 6LRs
   start running as IPSP nodes, i.e., they use Bluetooth LE
   advertisement packets to announce their presence and support of IPv6
   capabilities (Step 2).  The 6LBR (already running as an IPSP router)
   discovers the presence of the 6LRs and establishes one Bluetooth LE
   connection with each 6LR (Step 3).  After establishment of those
   link-layer connections (and after reception of Router Advertisements
   from the 6LBR), the 6LRs start operating as routers and also initiate
   the IPSP Router role (Step 4).  (Note: whether the IPSP Node role is
   kept running simultaneously is an implementation decision).  Then,
   6LNs start running the IPSP Node role (Step 5).  Finally, the 6LRs
   discover the presence of the 6LNs and establish connections with the
   latter (Step 6).


   Step 1
   ******
                                        6LBR
                                   (IPSP: Router)


                              6LR                 6LR
                      (not initialized)     (not initialized)



                6LN                 6LN                  6LN
       (not initialized)      (not initialized)     (not initialized)

   Step 2
   ******
                                        6LBR
                                   (IPSP: Router)


                              6LR                 6LR
                         (IPSP: Node)         (IPSP: Node)



                6LN                 6LN                  6LN
       (not initialized)      (not initialized)     (not initialized)

   Step 3
   ******

                                        6LBR
                                   (IPSP: Router)
     Bluetooth LE connection -->   /            \
                                  /              \
                              6LR                 6LR
                         (IPSP: Node)         (IPSP: Node)



                6LN                 6LN                  6LN
       (not initialized)      (not initialized)     (not initialized)

   Step 4
   ******

                                        6LBR
                                   (IPSP: Router)
                                   /            \
                                  /              \
                              6LR                 6LR
                         (IPSP: Router)      (IPSP: Router)



                6LN                 6LN                  6LN
       (not initialized)      (not initialized)     (not initialized)

   Step 5
   ******

                                        6LBR
                                   (IPSP: Router)
                                   /            \
                                  /              \
                              6LR                 6LR
                         (IPSP: Router)      (IPSP: Router)



                6LN                   6LN                6LN
            (IPSP: Node)         (IPSP: Node)        (IPSP: Node)

   Step 6
   ******

                                        6LBR
                                   (IPSP: Router)
                                   /            \
                                  /              \
                              6LR                 6LR
                        (IPSP: Router)       (IPSP: Router)
                         /           \       /            \
                        /             \     /              \
                       /               \   /                \
                    6LN                 6LN                  6LN
               (IPSP: Node)         (IPSP: Node)         (IPSP: Node)

       Figure 3: Example of Connection Establishment and Use of IPSP
               Roles in an IPv6 Mesh over Bluetooth LE Links

Appendix B.  Node-Joining Procedure

   This appendix provides a diagram that illustrates the node-joining
   procedure.  First of all, the joining node advertises its presence in
   order to allow establishment of Bluetooth LE connections with
   neighbors that already belong to a network.  The neighbors typically
   run as a 6LR or as a 6LBR.  After Bluetooth LE connection
   establishment, the joining node starts acting as a 6LN.

   Figure 4 shows the sequence of messages that are exchanged by the 6LN
   and a neighboring 6LR that already belongs to the network after the
   establishment of a Bluetooth LE connection between both devices.
   Initially, the 6LN sends a Router Solicitation (RS) message (1).
   Then, the 6LR replies with an RA, which includes the PIO (2).  After
   discovering the non-link-local prefix in use in the network, the 6LN
   creates its non-link-local address and registers that address with
   EARO (3) in the 6LR, and then multihop DAD is performed (4).  The
   next step is the transmission of the NA message sent by the 6LR in
   response to the NS previously sent by the 6LN (5).  If the non-link-
   local address of the 6LN has been successfully validated, the 6LN can
   operate as a member of the network it has joined.

               (1)                 6LN ----(RS)-------> 6LR
               (2)                 6LN <---(RA-PIO)---- 6LR
               (3)                 6LN ----(NS-EARO)--> 6LR
               (4)                 [Multihop DAD procedure]
               (5)                 6LN <---(NA)-------- 6LR

           Figure 4: Message Exchange Diagram for a Joining Node

Acknowledgements

   The Bluetooth, Bluetooth Smart, and Bluetooth Smart Ready marks are
   registered trademarks owned by Bluetooth SIG, Inc.

   The authors of this document are grateful to all authors of
   [RFC7668], since this document borrows many concepts (albeit with
   necessary extensions) from [RFC7668].

   The authors also thank Alain Michaud, Mark Powell, Martin Turon,
   Bilhanan Silverajan, Rahul Jadhav, Pascal Thubert, Acee Lindem,
   Catherine Meadows, and Dominique Barthel for their reviews and
   comments, which helped improve the document.

   Carles Gomez has been supported in part by the Spanish Government
   Ministerio de Economia y Competitividad through projects
   TEC2012-32531, TEC2016-79988-P, PID2019-106808RA-I00, and FEDER and
   Secretaria d'Universitats i Recerca del Departament d'Empresa i
   Coneixement de la Generalitat de Catalunya 2017 through grant SGR
   376.

Contributors

   Carlo Alberto Boano (Graz University of Technology) contributed to
   the design and validation of this document.

Authors' Addresses

   Carles Gomez
   Universitat Politecnica de Catalunya
   C/Esteve Terradas, 7
   08860 Castelldefels
   Spain

   Email: carlesgo@entel.upc.edu


   Seyed Mahdi Darroudi
   Universitat Politecnica de Catalunya
   C/Esteve Terradas, 7
   08860 Castelldefels
   Spain

   Email: sm.darroudi@entel.upc.edu


   Teemu Savolainen
   Unaffiliated

   Email: tsavo.stds@gmail.com


   Michael Spoerk
   Graz University of Technology
   Inffeldgasse 16/I
   8010 Graz
   Austria

   Email: michael.spoerk@tugraz.at