[6lo] Protocol Action: 'IPv6 over BLUETOOTH(R) Low Energy' to Proposed Standard (draft-ietf-6lo-btle-17.txt)

[The IESG <[e-mail]>]

The IESG has approved the following document:
- 'IPv6 over BLUETOOTH(R) Low Energy'
  (draft-ietf-6lo-btle-17.txt) as Proposed Standard

This document is the product of the IPv6 over Networks of
Resource-constrained Nodes Working Group.

The IESG contact persons are Brian Haberman and Terry Manderson.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-6lo-btle/




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)