| Internet-Draft | IPv6 mesh over Bluetooth LE | December 2020 |
| Gomez, et al. | Expires 10 June 2021 | [Page] |
RFC 7668 describes the adaptation of 6LoWPAN techniques to enable IPv6 over Bluetooth low energy 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 Low Energy links established by using the Bluetooth Internet Protocol Support Profile. This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 10 June 2021.¶
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
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.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 RFC 2119 [RFC2119], RFC 8174 [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.¶
Bluetooth LE defines two Generic Access Profile (GAP) roles of relevance herein: the Bluetooth LE central role and the Bluetooth LE peripheral role. A device in the central role, which is called central from now on, has traditionally been 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. 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. Consistently with Bluetooth 4.1 and subsequent Bluetooth versions (e.g. Bluetooth 4.2 [BTCorev4.2] or subsequent), 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.¶
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 RFC 7668: a) the adaptation layer below IPv6 (labelled 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 Bluetooh LE |
+---------+--+------------------------------------+
| Bluetooth LE L2CAP |
HCI - - +-------------------------------------------------+ - -
| Bluetooth LE Link Layer |
+-------------------------------------------------+
| Bluetooth LE Physical Layer |
+-------------------------------------------------+
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]. For the sake of lightweight implementation and operation, an MTU of 1280 octets is RECOMMENDED for IPv6 mesh over BLE links. The link-layer MTU is negotiated separately for each direction. Implementations that require an equal link-layer MTU for the two directions SHALL use the smallest of the possibly different MTU values.¶
Note that this specification allows using different MTUs in different links. If an implementation requires use of the same MTU on every one of its links, and a new node with a smaller MTU is added to the network, a renegotiation of one or more links can occur. In the worst case, the renegotiations could cascade network-wide. In that case, implementers need to assess the impact of such phenomenon.¶
Similarly to RFC 7668, 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 when necessary.¶
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]. Note that the route-over functionality defined in [RFC6775] is essential to enable 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
One or more 6LBRs are connected to the Internet. 6LNs are connected to the network through a 6LR or a 6LBR. 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.¶
6LN, 6LR, and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE links are configured as per section 3.2.2 of RFC 7668.¶
Multihop Duplicate Address Detection (DAD) functionality as defined in section 8.2 of RFC 6775 and updated by RFC 8505, or some substitute mechanism (see section 3.3.2), MAY be supported.¶
'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 RFC 6775 and RFC 8505 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 SHOULD 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. Note that in some cases (e.g., very short-lived connections) it may not be worthwhile for a 6LN to send an NS with EARO for registering its address. However, the consequences of not registering the address (including non-reachability of the 6LN, and absence of DAD) need to be carefully considered. 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 RFC 8928 MUST be used, unless an alternative mechanism offering equivalent protection is used. As per RFC 8505, a 6LN MUST NOT register its link-local address.¶
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 RFC 7668).¶
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 RFC 6775, and updated by RFC 8505. 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 RFC 6775, 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 be advertising interfaces and turning into a router. In order to support such 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, it turns into a router, and it 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 RFC 6775, and updated by RFC 8505.¶
RFC 6775 defines substitutable mechanisms for distributing prefixes and context information (section 8.1 of RFC 6775), as well as for Duplicate Address Detection across a route-over 6LoWPAN (section 8.2 of RFC 6775). RFC 8505 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 RFC 6775, as updated by RFC 8505, or some alternative ("substitute") mechanism.¶
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 context is pre-provisioned or provided by out-of-band means.¶
The specific optimizations of RFC 7668 for header compression, which exploited the star topology and ARO (note that the latter has been updated by EARO as per RFC 8505), 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 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 with the latest address registered by the 6LN, then the last 16 bits of the IID SHALL be carried in-line (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 in-line (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 the first 48 bits of the IID match to those of the latest registered address, then the last 16 bits of the IID SHALL be carried in-line (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).¶
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.¶
There are no IANA considerations related to this document.¶
The security considerations in RFC 7668 apply.¶
IPv6 mesh over Bluetooth LE links 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 RFC 7416 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, and 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 RFC 8928 [RFC8928] provides protection against such attacks.¶
Carlo Alberto Boano (Graz University of Technology) contributed to the design and validation of this document.¶
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 RFC 7668 authors, since this document borrows many concepts (albeit, with necessary extensions) from RFC 7668.¶
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.¶
This appendix provides an example of Bluetooth LE connection establishment and use of IPSP roles in an IPv6 mesh over Bluetooth LE links 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 as time evolves, in the example. 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), Step 4, the 6LRs start operating as routers, and also initiate the IPSP Router role (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 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)
This appendix provides a diagram that illustrates the node joining procedure. First of all, the joining node advertises its presence in order to allow establishing Bluetooth LE connections with neighbors that already belong to a network. The latter 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 an 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, registers that address with EARO (3) in the 6LR, and 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