IPv6 Mesh over BLUETOOTH(R) Low Energy Using the Internet Protocol Support Profile (IPSP)
Extracted elements (26)
A multilink subnet model was chosen over per-link subnets because implementing a separate subnet on each peripheral-central link and routing between them was considered excessively complex for constrained IoT nodes. The benefits of a single multilink subnet outweigh the drawbacks identified in RFC 4903.
The 6CO is not needed when context is pre-provisioned or provided by out-of-band means, since the in-band indication would be superfluous. The 6LBR MAY include a 6CO matching each advertised prefix only when in-band signaling is desired.
The RFC 7668 header compression optimizations that exploited the star topology and ARO cannot be generalized to a mesh topology; only a subset (link-local interactions, first hop from a 6LN, last hop toward a 6LN) remains directly applicable.
A Bluetooth LE 6LN link-local address only needs to be unique between the two communicating nodes (e.g., 6LN and 6LR), not across the entire multilink subnet; therefore EDAR/EDAC exchange for link-local address DAD is not required.
If a 6LN registers multiple addresses not based on its Bluetooth device address using the same compression context, header compression efficiency may decrease, since only the latest registered address can be fully elided.
RFC 7668 was specifically developed for star topology Bluetooth LE networks and its functionality is insufficient and would fail to enable IPv6 mesh over Bluetooth LE links; this document extends RFC 7668 with mesh-specific mechanisms.
A Bluetooth LE 6LN MUST register its non-link-local addresses with its routers by sending a Neighbor Solicitation (NS) with the Extended Address Registration Option (EARO) and process the Neighbor Advertisement (NA) accordingly.
A router MUST fully elide the destination IPv6 address when transmitting to a neighboring 6LN if the destination is the latest address registered by the 6LN with EARO for the indicated context (DAC=1, DAM=11).
A router MUST keep track of neighboring multicast listeners and MUST NOT forward multicast packets to neighbors that have not registered as listeners for the destination multicast groups.
Header compression as defined in RFC 6282 is REQUIRED as the basis for IPv6 header compression on top of Bluetooth LE; all headers MUST be compressed according to RFC 6282 encoding formats.
If a cryptographic ID is used in the ROVR field, address registration and multihop DAD formats and procedures defined in RFC 8928 MUST be used unless an alternative mechanism offering equivalent protection is employed.
Implementations MUST either support the features in Sections 8.1 and 8.2 of RFC 6775 (as updated by RFC 8505) for prefix/context distribution and multihop DAD, or provide a substitute mechanism offering equivalent functionality.
IPv6 mesh over Bluetooth LE links MUST follow a route-over approach. The route-over functionality defined in RFC 6775 is essential to enabling the multilink subnet model.
Routers SHALL NOT use multicast Neighbor Solicitations to discover other routers' link-layer addresses, since the Bluetooth LE link layer does not natively support multicast.
The route-over functionality of RFC 6775 and RFC 8505 MUST be supported for neighbor discovery in IPv6 mesh over Bluetooth LE links.
When a 6LN transmits a packet with a non-link-local source address registered via EARO, the source address MUST be fully elided if it is the latest registered address for the indicated prefix (SAC=1, SAM=11).
When transmitting 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), and MUST fully elide the destination address if it is the link-local address based on the neighbor's device address (DAC=0, DAM=11).
6LoWPAN fragmentation is not used for IPv6 mesh over Bluetooth LE links; instead, Bluetooth LE's L2CAP fragmentation and reassembly is relied upon to handle PDUs larger than the basic link MTU.
IPv6 forwarding devices in the mesh MUST implement both IPSP Node and Router roles, while simpler leaf-only nodes need only implement the IPSP Node role. A device may simultaneously act as a Bluetooth LE central and peripheral.
The MTU size for IPv6 mesh over Bluetooth LE links is 1280 octets. Bluetooth 4.2 defines a default MTU of 251 bytes; excluding the 4-byte L2CAP header, 247 bytes are available above L2CAP, and IPSP negotiates a link-layer connection providing at least 1280 octets for the IPv6 layer.
The ROVR field in EARO is by default filled with the 48-bit Bluetooth device address converted to 64-bit Modified EUI-64 format. Optionally, a cryptographic ID per RFC 8928 MAY be placed in the ROVR field instead.
The routing protocol required for IPv6 mesh over BLE introduces additional opportunities for threats and attacks. RFC 7416 provides a systematic overview of threats against RPL (failures to authenticate, integrity attacks, availability attacks) whose guidance is applicable when RPL is used, and may partly apply to other routing protocols as well.
The ROVR can be derived from the Bluetooth device address, but such a ROVR can be spoofed; any node on the subnet aware of a registered-address-to-ROVR mapping could perform address theft and impersonation attacks. Use of Address Protected Neighbor Discovery (RFC 8928) provides protection against such attacks.
A 6LR begins in the IPSP Node role only. Upon establishing a connection with an existing router and receiving a Router Advertisement, it configures its own interface address, transitions to router mode, and starts operating as an IPSP Router. A 6LBR, by contrast, uses both IPSP Node and IPSP Router roles from initialization.
Non-link-local destination address compression toward a 6LN: if the first 48 bits of the IID match those of the latest registered address but it is not the latest, the last 16 bits SHALL be carried inline (DAC=1, DAM=10); if the first 48 bits do not match, the 64-bit IID SHALL be fully carried inline (DAC=1, DAM=01).
Non-link-local source address compression: if the first 48 bits of the IID match the latest registered address but the address is not the latest, the last 16 bits SHALL be carried inline (SAC=1, SAM=10); if the first 48 bits do not match, the full 64-bit IID SHALL be carried inline (SAC=1, SAM=01).