Technical Summary
Bluetooth Low Energy (BT-LE) is a low power air interface technology
defined by the Bluetooth Special Interest Group (BT SIG). While
Bluetooth has been widely implemented, the low power version of
Bluetooth is a new specification and enables the use of this air
interface with devices such as sensors, smart meters, appliances, etc.
The low power variant of Bluetooth is commonly specified in revision
4.0 of the Bluetooth specifications and commonly referred to as
Bluetooth 4.0. The BT SIG has issued subsequent updates (to date,
Bluetooth 4.1 and 4.2). This document describes how IPv6 is transported
over Bluetooth Low Energy 4.1 using 6LoWPAN techniques.
Working Group Summary
This document represents the consensus of the 6Lo WG on how to apply
the technology developed originally for IEEE 802.15.4 applied to BT-LE.
This document initially appeared in the 6LoWPAN WG, the predecessor to
the 6Lo WG, and made it all the way to approval at the IESG (last ballot
comment: 2013-03-07). There is still one outstanding DISCUSS the
clearing of which required some work by the Bluetooth SIG. That initial
version of the draft used a fixed L2CAP channel ID. In this 2 year
hiatus, the BT SIG had a policy change, so instead of assigning the
fixed channel ID, they defined the Internet Protocol Support Profile
(IPSP) 1.0. IPSP uses Connection-oriented Channels and negotiation of
dynamic channel ID. This enabled a simplification in the draft as
shown by the diff between versions 00 and 01:
http://tools.ietf.org/wg/6lo/draft-ietf-6lo-btle/draft-ietf-6lo-btle-01-from-00.diff.html
This support from BT SIG should address the remaining DISCUSS on the
original document. This document depends on IPSP 1.0, which requires
Bluetooth 4.1 or newer. Since these changes were significant, the
document went back to the working group, including the corresponding
last call. There were few comments this time around (including Dave
Thaler, Carsten Bormann and this shepherd). The document is improved as
compared to the first time it went to IESG.
One point worth noting is that there was a thread discussing whether
we'd use 64-bit IID's for this draft. This is a more general point that
would apply to more than just this draft, so it quickly became more a
discussion of https://tools.ietf.org/html/rfc7421 than a discussion of
this particular draft. In keeping with rfc7421's advice and per
preference expressed by several WG members as well as guidance by Ole
Troan (6man co-chair), we stuck to 64-bit IID's. It may be a worthwhile
goal to go revise that part of the IPv6 addressing architecture, but
"that's not a problem that should be solved in an IP over foo
document" (Ole Troan).
Document Quality
The document is a product of the 6Lo (and 6LoWPAN) working group and has
been reviewed by a small number of working group members. It has also
been reviewed within the Bluetooth SIG (including its Internet Working
Group). As far as it is known to this Shepherd, so far it has been
implemented by several companies (one implementation has been
demonstrated in the hallway of the IETF 83 meeting). The authors are
aware of several other companies that have implemented (including
Nordic: http://www.nordicsemi.com/eng/News/News-releases/Product-
Related-News/Nordic-Semiconductor-IPv6-over-Bluetooth-Smart-protocol-
stack-for-nRF51-Series-SoCs-enables-small-low-cost-ultra-low-power-
Internet-of-Things-applications and also in Bluez). The Bluetooth 4.1
specification and thus BT-LE itself is implemented widely (e.g., in the
many current phones, tablets and laptops), so it is important to agree
on an IP-over-foo specification for this link layer.
Personnel
Gabriel Montenegro is the Document Shepherd.
Brian Haberman is the Responsible Area Director.
RFC Editor Note
In Section 5:
OLD
For non-link local
addresses implementations have a choice to support, for example,
[I-D.ietf-6man-default-iids], [RFC3315], [RFC3972], [RFC4941],
[RFC5535], or [RFC7217].
NEW
For non-link local
addresses, implementations are recommended not to embed
the Bluetooth device address in the IID by default and instead
support, for example,
[RFC3315], [RFC3972], [RFC4941],
[RFC5535], or [RFC7217].
(Insert RFC Editor Note here or remove section)