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)
