IPv6 over BLUETOOTH(R) Low Energy
Extracted elements (28)
6LoWPAN fragmentation features are not used because Bluetooth LE's L2CAP layer already provides link-layer fragmentation and reassembly, making a duplicate mechanism at the 6LoWPAN layer unnecessary.
A multilink subnet model was chosen over per-link subnets because the complexity of separate subnets and inter-subnet routing was considered excessive for constrained IoT nodes. The benefits outweigh the multilink model's drawbacks as described in RFC 4903.
Duplicate link-local address detection is performed by the 6LBR at connection establishment rather than via DAD packets. This increases 6LBR complexity but reduces power consumption on both 6LN and 6LBR by eliminating mandatory DAD packet transmissions.
IPv6 over Bluetooth LE requires Bluetooth 4.1 or newer and IPSP 1.0 or newer. Bluetooth 4.0 devices do not support IPv6 because version 4.1 is required for the necessary capabilities.
A 6LN MUST join the all-nodes multicast address. There is no need for a 6LN to join the solicited-node multicast address, since the 6LBR tracks all connected 6LN device and link-local addresses.
A Bluetooth LE 6LN MUST NOT register its link-local address using ARO. It MUST register non-link-local addresses and process the resulting Neighbor Advertisement accordingly.
All non-link-local addresses generated by a 6LN MUST be registered with the 6LBR via a Neighbor Solicitation with Address Registration Option (ARO), regardless of how the IID was generated.
Both 6LN and 6LBR SHALL generate and assign link-local addresses based on the 48-bit Bluetooth device addresses used during connection establishment. The same link-local address SHALL be used for the lifetime of the Bluetooth LE L2CAP channel.
For non-link-local addresses, 6LNs SHOULD NOT embed the Bluetooth device address in the IID by default; alternatives such as CGAs, privacy extensions, HBAs, DHCPv6, or semantically opaque addresses SHOULD be used instead.
IPv6 packets MUST be transmitted in big-endian order (network byte order) over Bluetooth LE, even though Bluetooth LE protocols such as L2CAP use little-endian byte ordering.
The 6LBR MUST ignore 6LNs whose Bluetooth LE device address is the same as the 6LBR's own, and MUST maintain at most one connection per Bluetooth LE device address at any given time, to avoid addressing conflicts.
The 6LBR MUST include a 6LoWPAN Context Option (6CO) matching each advertised prefix in Router Advertisements to enable efficient header compression on Bluetooth LE.
The 6LBR MUST set the 'on-link' flag (L) to zero in the Prefix Information Option in Neighbor Discovery messages, causing 6LNs to always send packets to the 6LBR, including when the destination is another 6LN using the same prefix.
The 6LBR MUST track multicast listeners at Bluetooth LE link-level granularity and MUST NOT forward multicast packets to 6LNs that have not registered as listeners for the relevant multicast groups.
The IPv6 header compression format specified in RFC 6282 MUST be used, and all headers MUST be compressed according to the encoding formats described therein.
Use of a 1280-octet MTU is RECOMMENDED to avoid the need for Path MTU Discovery procedures, even though the IPSP allows negotiating larger MTUs. Implementations requiring equal MTU in both directions SHALL use the smallest of the two negotiated values.
IPv6 link-local addresses derived from Bluetooth device addresses reveal exactly as much information as the underlying device address. Devices using Bluetooth privacy features (random private addresses) have corresponding privacy in their link-local addresses; those without privacy at the Bluetooth level also lack it at the IPv6 layer.
Bluetooth LE Link Layer does not support multicast. The 6LBR must replicate multicast packets and unicast them individually to each interested 6LN. 6LNs transmitting multicast packets unicast them to the 6LBR.
Header compression on Bluetooth LE uses RFC 6282 IPHC encoding. Source and destination addresses can be fully elided based on ARO registration state: SAC=1/SAM=11 elides the latest registered non-link-local source; DAC=0/DAM=11 elides the 6LBR's link-local destination address.
IPv6 over Bluetooth LE uses a 6LoWPAN adaptation layer running on top of Bluetooth LE L2CAP, with the GATT stack running in parallel for IPSS discovery. The stack requires Bluetooth 4.1 or newer and IPSP 1.0 or newer.
The ARO EUI-64 field SHALL be filled with the 48-bit Bluetooth device address converted to 64-bit Modified EUI-64 format as per RFC 4291, enabling the 6LBR to correlate device addresses with registered IIDs.
The Bluetooth LE network is modeled as a multilink subnet: all peripheral-to-central point-to-point links share a single /64 IPv6 prefix, with the 6LBR acting as router. Link-local multicast is confined to individual Bluetooth LE connections, so 6LN-to-6LN link-local communication is not possible.
The Bluetooth LE network uses a star topology where the central acts as a 6LoWPAN Border Router (6LBR) and peripherals act as 6LoWPAN Nodes (6LNs). Direct communication only occurs between central and peripheral; peripheral-to-peripheral traffic is routed through the central via IP routing.
A malicious 6LN may attempt denial-of-service attacks such as packet flooding. Mitigations include not bridging link-local multicast between Bluetooth LE links and rate-limiting per-6LN traffic using Bluetooth LE L2CAP credit-based flow control.
Bluetooth LE Link Layer provides encryption and authentication using Counter with CBC-MAC (CCM) with a 128-bit AES cipher. Key management is handled by the Security Manager Protocol (SMP). CCM overhead does not consume per-packet L2CAP data space.
The Direct Test Mode lacks security mechanisms for communication between the upper tester and the device under test; however, exploitation requires physical wired access to the device under test.
A 64-bit Interface Identifier (IID) is formed from the 48-bit Bluetooth device address by inserting 0xFF and 0xFE in the middle, following RFC 7136. No bit transformation is applied; public and random addresses are treated identically in the IID.
The IPv6 link-local address is formed by prepending fe80::/64 to the IID derived from the Bluetooth device address. The same link-local address SHALL be used for the lifetime of the Bluetooth LE L2CAP channel.