IPv6 Operations N. Elkins
Internet-Draft Inside Products, Inc.
Intended status: Informational M. P. Tahiliani
Expires: 2 December 2024 R. Mohan
S. B. Nidamboor
T. Sankpal
NITK Surathkal
31 May 2024
IPv6 Over Bluetooth for Power Affluent Devices
draft-elkins-v6ops-ipv6blt-00
Abstract
IPv6 over Bluetooth enables devices to communicate using the IPv6
protocol stack over Bluetooth wireless connections, expanding the
range of networking options available to devices with Bluetooth
capability. RFC 7668 and RFC 9159 describe IPv6 over Bluetooth for
Bluetooth Low Energy devices. However, the potential of this
technology has yet to be fully explored. This document proposes
using this technology for power affluent devices with optional header
compression and discusses some use cases.
About This Document
This note is to be removed before publishing as an RFC.
The latest revision of this draft can be found at
https://mrakshith21.github.io/draft-ipv6-over-bluetooth/draft-elkins-
v6ops-ipv6blt.html. Status information for this document may be
found at https://datatracker.ietf.org/doc/draft-elkins-v6ops-
ipv6blt/.
Discussion of this document takes place on the IPv6 Operations
Working Group mailing list (mailto:v6ops@ietf.org), which is archived
at https://mailarchive.ietf.org/arch/browse/v6ops/. Subscribe at
https://www.ietf.org/mailman/listinfo/v6ops/.
Source for this draft and an issue tracker can be found at
https://github.com/mrakshith21/draft-ipv6-over-bluetooth.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 December 2024.
Copyright Notice
Copyright (c) 2024 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
2. Terminology
3. Use cases
3.1. Disaster recovery
3.2. Chat application
3.3. IoT Gateways
4. Relevant Technology
4.1. GATT
4.2. IPv6 over Bluetooth networks and the IPSP
4.3. Address Configuration
4.4. Header Compression
4.5. Shortwave radio
5. Implementation Considerations
6. Common Implementation Details of IPv6 over Bluetooth
6.1. Architecture
6.2. Components
6.2.1. Driver
6.2.2. Packet Processing Application
6.2.3. Libraries
6.2.4. Bluetooth packet layout
7. Conventions and Definitions
8. Security Considerations
9. IANA Considerations
10. References
10.1. Normative References
10.2. Informative References
Acknowledgments
Authors' Addresses
1. Introduction
Bluetooth is a low-power wireless technology designed for short-range
control and monitoring applications. The IETF has developed
specifications for IPv6 over BLE devices to enhance IoT capabilities,
outlined in RFC 7668 [RFC7668]. This RFC primarily addresses star
topology, while RFC 9159 [RFC9159] extends IPv6 mesh networking
capabilities over BLE links. Despite its focus on low-power devices,
IPv6 over BLE can be extended to power affluent platforms like
Windows, Linux, Android OS, and iPhone running on personal computers
and mobile phones.
By adhering to the Internet Protocol Support Profile (IPSP) published
by the Bluetooth SIG, devices such as personal computers and
smartphones can harness IPv6 over Bluetooth, presenting an
alternative connectivity solution. This integration amalgamates the
benefits of the robust addressing of IPv6 and routing capabilities
with Bluetooth.
Adding the IPv6 over Bluetooth functionality depends on the design
and flexibility of the operating system. However, the adaptation
layer need not be built from scratch since the Bluetooth L2CAP
Protocol supports fragmentation and reassembly. This document
discusses a few use cases of this technology in disaster recovery,
near-field chat, and IoT gateways. It also presents common
implementation details of IPv6 over Bluetooth and key considerations.
2. Terminology
Throughout this document, these terms have specific meanings:
* The term Bluetooth refers to Bluetooth Low Energy unless otherwise
specified.
* The term power affluent refers to devices that are not resource-
constrained. A few examples are smartphones, laptops, personal
computers, etc.
* The term node refers to a power-affluent device part of the IPv6
over Bluetooth network.
3. Use cases
IPv6 over Bluetooth is an alternate technology for connecting devices
while using the vast features of IP as well as the low-powered
interface of Bluetooth. By developing implementations of the IPv6
over Bluetooth stack on different operating systems, we can
facilitate the use of this technology for power-affluent devices and
explore its potential. This section discusses some use cases.
3.1. Disaster recovery
In a disaster area where traditional means of communication like the
Internet and cables are damaged or unavailable, establishing
connectivity between devices can be critical for coordination, rescue
efforts, and communication with survivors. This also applies to
cases where the Internet is shut down. In such a situation, IPv6
over Bluetooth can form a network of connected devices.
We assume that devices are Bluetooth enabled and in Bluetooth range
to form a network of Bluetooth devices. As described in RFC 9159
[RFC9159] IPv6 over Bluetooth for Mesh Networks, devices can then
take up roles similar to a 6LN or 6LR. In other words, some devices
act as nodes, and some as routers. Note that routers forward packets
only within the network. If the Internet is accessible for some
devices, they can act as 6LBR or border routers. With the IPv6 over
Bluetooth layer available on the devices, applications can continue
to use IP while the actual communication uses Bluetooth. This idea
can be backed by the fact that Bluetooth is available not only on PCs
but also on mobile phones, which leads to a network with more links.
3.2. Chat application
Bluetooth chat gained prominence through Bridgefy during the Hong
Kong protests when the Internet was shut down. IPv6 over Bluetooth
offers an enhanced alternative, allowing any network application,
including chat apps, to operate similarly as on IPv6. Chat
applications can be used to establish local networks via IPv6 over
Bluetooth in remote areas or emergencies where Internet access is
unavailable.
Devices need to advertise and register themselves in the network to
be discovered. Sending a message to a nearby device would take a
single hop. However, if a message is to be sent to a farther device,
it would include multiple hops across routers. Users can participate
in public and private chat. This can be particularly useful in
relaying emergency information or in crowded places with a poor
Internet connection to communicate within a group.
3.3. IoT Gateways
Use cases in building management, healthcare, workplaces,
manufacturing, logistics, and hospitality have introduced low-power
IoT devices into their environments. These devices typically do not
support IP-based interfaces. Hence, gateway functions need to allow
these devices to communicate with the applications that manage them.
IoT gateways provide various functionalities depending on the kind of
devices they are connected to and their functionality. For example,
authentication and authorization of application clients that will
access the device, interfaces that allow for bi-directional
communication to non-IP devices, and one or more channels to process
requests, responses, and asymmetric communications with the non-IP
radio resources (access points) in the system, and so on. IoT
networks use customized gateways that communicate with each other and
external networks to fulfill the required functionality.
IPv6 over Bluetooth can be used in IoT networks wherein multiple IoT
gateways communicate with each other and a central router using IPv6
over Bluetooth Low Energy (BLE). The topology consists of IoT
devices connected to local gateways, which relay data to the central
router for external connectivity.
IoT Gateway 1
|
|
IoT Gateway 2 --- Border Router ------------- Internet
|
|
IoT Gateway 3
Figure 1: Multiple IoT gateways connected through a border router
4. Relevant Technology
GATT (Generic ATTribute Profile) defines how two Bluetooth Low Energy
devices transfer messages between each other. It uses a generic data
protocol called the Attribute Protocol (ATT), which is used to store
services and characteristics in a simple lookup table with 16-bit IDs
(UUIDs). GATT transactions in BLE are based on high-level, nested
objects called Profiles, Services, Characteristics, and Control
Points. A service can have one or more characteristics, and each
service distinguishes itself from other services using a unique
numeric ID called a UUID, which can be either 16-bit (for officially
adopted BLE Services) or 128-bit (for custom services). The lowest
level concept in GATT transactions is the Characteristic, which
encapsulates a single data point. Each characteristic distinguishes
itself via a pre-defined 16-bit or 128-bit UUID.
4.2. IPv6 over Bluetooth networks and the IPSP
As per RFC 9159 [RFC9159], for IPv6 over BLE mesh networks, a
multilink model is chosen. The network consists of nodes 6LN (node),
6LR (router), and 6LBR (border router). A 6LN is a peripheral node
that connects to the network through a 6LR or a 6LBR. A 6LR connects
6LNs to other 6LRs or 6LBR. One or more 6LBRs are connected to the
Internet. A router can manage connections with several peripheral
devices, while a peripheral is usually connected only to a central
node. A single global unicast prefix is used on the whole subnet.
The IPSP enables the 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.
4.3. Address Configuration
RFC 7668 [RFC7668] specifies a stateless address autoconfiguration
scheme for all nodes in the network. An IPv6 link-local address is
assigned to the Bluetooth interface based on the 48-bit Bluetooth
device address. A 64-bit address is generated from the Bluetooth
address, which is prepended with fe80::/64. Mechanisms for
registering a non-link local address and multiple addresses are also
provided.
4.4. Header Compression
Since BLE communication aims to conserve power, IPv6 over BLE
involves header compression to reduce the size of IPv6 packets. This
compression is based on the 6LoWPAN IPv6 header compression specified
in RFC 6282 [RFC6282]. However, since the document focuses mainly on
IPv6 over Bluetooth for power-affluent devices, header compression is
optional, though it is provided in the implementation.
4.5. Shortwave radio
Amateur or shortwave radio is a viable alternative for long-range
communication, particularly in remote or disaster-affected areas.
These radios utilize radio waves that can travel vast distances by
bouncing off the ionosphere. The distance covered by these signals
can vary based on the frequency used. Various frequencies are
designated for emergency communication, including those used by
medical relief operations, state police, fire departments, and
maritime weather alerts. However, these frequencies can differ from
country to country.
Setting up a personal computer as a shortwave radio transmitter or
receiver is feasible. A possible solution involves the draft "A
Method for Deriving Stable IPv6 Interface Identifiers from Amateur
Radio Callsigns." by E. Pratten, which outlines a method to generate
IPv6 addresses for amateur radio nodes or stations. By configuring
devices with these designated IPv6 addresses to communicate over
shortwave radio and leveraging local connectivity via IPv6 over
Bluetooth, it is possible to extend Internet connectivity to remote
areas.
5. Implementation Considerations
The following describes a list of points to consider while developing
an IPv6 over Bluetooth implementation:
* Header compression can be optional and determined by the
application using IPv6 over Bluetooth. Correspondingly, the
application can make use of the 6LowPAN library if needed. If an
Internet-based application uses IPv6 over Bluetooth for
communication, header compression may be avoided.
* Traditionally, Bluetooth MAC addresses has been used to generate
IPv6 addresses. However, this method has not been promoted
recently. Thus, any relevant method can be used. The address
generation is beyond the scope of this draft.
* Devices must enforce IPv6 over IPv4 since the technology only
transmits IPv6 packets over Bluetooth.
* Selection of devices as routers or border routers is a crucial
challenge. The border router must ensure that devices in its
domain have unique addresses. The network must also have an IPv6
prefix, which is to be determined.
* Packet delivery cannot be guaranteed since devices may sometimes
go out of Bluetooth range.
6. Common Implementation Details of IPv6 over Bluetooth
In this section, we describe common implementation details of IPv6
over Bluetooth.
*Note*: Exact implementation details may vary across different
operating systems. This section only describes a general
architecture and its components.
6.1. Architecture
The following components are necessary for an implementation:
* A driver or kernel-level module
* A packet processing application
Additionally, the following libraries will be needed to support the
functionality of the packet-processing app:
* A driver interoperability library
* A Bluetooth GATT library
* A 6LoWPAN library
Figure 2 illustrates the system architecture for this solution.
+--------------+
| 6LoWPAN |
| library |
+--------------+
|
|
|
+----------------+ +---------------+ +----------------+
| Driver interop | | Packet | | Bluetooth GATT |
| library |--| processing |---| library |
+----------------+ | application | +----------------+
| +---------------+ |
+------------------+ |
User mode | |
-----------------------------|----------------------|-------------
Kernel mode | |
| |
+--------------+ | +--------------+
| UDP | | | Bluetooth LE |
+--------------+ +-----------------+ +--------------+
| IPv6 | | Driver or kernel| | Bluetooth |
+--------------+ | module | | L2CAP |
|Wi-Fi/Ethernet| +-----------------+ +--------------+
+--------------+
Figure 2: Architecture
The architecture consists of components operating in the user and
kernel modes.
6.2. Components
The following describes the functionalities of the components
specified in the architecture in detail.
The driver is the component that operates in the kernel mode. The
following operations are to be supported by the driver - Filters
outgoing IPv6 packets. - Push a given IPv6 packet embedded in a
Bluetooth packet into the network stack for an appropriate
application to consume.
6.2.2. Packet Processing Application
The packet processing application, working with the driver, is an
essential component that bridges the transition of the packet from
the IP layer to Bluetooth and vice versa. The following operations
are to be supported by the packet processing application:
* Obtain IPv6 address to be used in the IPv6 over Bluetooth network
* Scan for nearby Bluetooth devices
* Communicate with the driver to receive intercepted IPv6 packets
and send them over Bluetooth. Send IPv6 packets received over
Bluetooth to the driver for inbound injection. If an inbound
packet is not for the device, it may be forwarded it to the router
application (if running) for further transmission.
* Use libraries, such as a 6LowPAN library for address and header
compression and a driver interface library to communicate with the
driver.
6.2.3. Libraries
* A driver interoperability library: This is an interface used by
the packet processing application to communicate with the driver.
* A Bluetooth GATT library: The packet processing application
initiates a GATT application, which acts as a server or client.
It supports the Internet Protocol Support Service (IPSP). A node
communicates with another node by writing an IPv6 packet to a
characteristic of the IPSP in the GATT application.
* A 6LoWPAN library: This is used for header compression and
decompression.
6.2.4. Bluetooth packet layout
An IPv6 over BLE packet consists of an IPv6 packet embedded in a
Bluetooth packet. A sample packet captured from a Windows
implementation is shown in Figure 3. Only the data within the
Bluetooth Attribute Protocol is shown in detail for this discussion.
+--------------------------------------------+
| Bluetooth HCI |
+--------------------------------------------+
| Bluetooth L2CAP Protocol |
+--------------------------------------------+
| Bluetooth Attribute Protocol |
+--------------------------------------------+
| > Opcode: Write Command (0x52) |
+--------------------------------------------+
| > Handle: 0x0018 |
+--------------------------------------------+
| > Value: IPv6 Packet |
+--------------------------------------------+
| > IPv6 Header |
+--------------------------------------------+
| > UDP Header |
+--------------------------------------------+
| > Data: Hello World |
+--------------------------------------------+
Figure 3: Packet layout
7. Conventions and Definitions
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.
8. Security Considerations
The security considerations specified in RFC 7668 [RFC7668] also
applies for IPv6 over Bluetooth in power-affluent devices. RFC 7416
[RFC7416] provides an overview of such threats. Notably, the routing
protocol poses opportunities for threats and attacks. Considering
that devices are not resource constrained, the scale of threats can
only increase.
9. IANA Considerations
This document has no IANA actions.
10. References
10.1. Normative References
[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/rfc/rfc2119>.
[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/rfc/rfc8174>.
10.2. Informative References
[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/rfc/rfc6282>.
[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/rfc/rfc7416>.
[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/rfc/rfc7668>.
[RFC9159] Gomez, C., Darroudi, S.M., Savolainen, T., and M. Spoerk,
"IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet
Protocol Support Profile (IPSP)", RFC 9159,
DOI 10.17487/RFC9159, December 2021,
<https://www.rfc-editor.org/rfc/rfc9159>.
Acknowledgments
The authors would like to acknowledge the developer of
IPv6OverBluetoothLowEnergyMesh (https://github.com/uwbiot/
IPv6OverBluetoothLowEnergyMesh), Duncan MacMichael, for his
contribution of a Windows implementation for IPv6 over Bluetooth.
Authors' Addresses
Nalini Elkins
Inside Products, Inc.
Email: nalini.elkins@insidethestack.com
USA
Mohit P. Tahiliani
NITK Surathkal
Email: tahiliani@nitk.edu.in
India
Rakshith Mohan
NITK Surathkal
Email: rakshith21mohan@gmail.com
India
Shrinidhi Ballal Nidamboor
NITK Surathkal
Email: ballalshrinidhi@gmail.com
India
Tejas Sankpal
NITK Surathkal
Email: tejas@gmail.com
India