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
- 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
- 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 |
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 [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.
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 [RFC 4903
]. 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 [RFC 6775
] 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
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.
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
"[Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)
]" [RFC 6775
], subsequently updated by "[Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery
]" [RFC 8505
], 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
The following aspects of the Neighbor Discovery optimizations for 6LoWPAN [RFC 6775
] [RFC 8505
] are applicable to Bluetooth LE 6LNs:
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 [RFC 8505]. 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 [RFC 4291]. Optionally, a cryptographic ID (see [RFC 8928]) 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 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 RFC 7668).
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 [RFC 6775], and Section 5.6 of RFC 8505.
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:
Routers SHALL NOT use multicast NSs to discover other routers' link-layer addresses.
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 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.
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
], 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
] encoding formats.
To enable efficient header compression, when the 6LBR sends a Router Advertisement, it MAY
include a 6LoWPAN Context Option (6CO) [RFC 6775
] matching each address prefix advertised via a Prefix Information Option (PIO) [RFC 4861
] 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 [RFC 7668
] for header compression, which exploited the star topology and Address Registration Option (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
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).
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.