doc: Add RFC documents

1 files changed, 739 insertions, 0 deletions

diff --git a/doc/rfc/rfc9159.txt b/doc/rfc/rfc9159.txt
new file mode 100644
index 0000000..b159c15
--- /dev/null
+++ b/doc/rfc/rfc9159.txt
@@ -0,0 +1,739 @@
+
+
+
+
+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