summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc9159.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc9159.txt')
-rw-r--r--doc/rfc/rfc9159.txt739
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