< draft-ietf-6lo-btle-15.txt   draft-ietf-6lo-btle-16.txt >
6Lo Working Group J. Nieminen 6Lo Working Group J. Nieminen
Internet-Draft T. Savolainen Internet-Draft T. Savolainen
Intended status: Standards Track M. Isomaki Intended status: Standards Track M. Isomaki
Expires: January 21, 2016 Nokia Expires: January 24, 2016 Nokia
B. Patil B. Patil
AT&T AT&T
Z. Shelby Z. Shelby
Arm Arm
C. Gomez C. Gomez
Universitat Politecnica de Catalunya/i2CAT Universitat Politecnica de Catalunya/i2CAT
July 20, 2015 July 23, 2015
IPv6 over BLUETOOTH(R) Low Energy IPv6 over BLUETOOTH(R) Low Energy
draft-ietf-6lo-btle-15 draft-ietf-6lo-btle-16
Abstract Abstract
Bluetooth Smart is the brand name for the Bluetooth low energy Bluetooth Smart is the brand name for the Bluetooth low energy
feature in the Bluetooth specification defined by the Bluetooth feature in the Bluetooth specification defined by the Bluetooth
Special Interest Group. The standard Bluetooth radio has been widely Special Interest Group. The standard Bluetooth radio has been widely
implemented and available in mobile phones, notebook computers, audio implemented and available in mobile phones, notebook computers, audio
headsets and many other devices. The low power version of Bluetooth headsets and many other devices. The low power version of Bluetooth
is a specification that enables the use of this air interface with is a specification that enables the use of this air interface with
devices such as sensors, smart meters, appliances, etc. The low devices such as sensors, smart meters, appliances, etc. The low
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 21, 2016. This Internet-Draft will expire on January 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Requirements Language . . . . . . . . . . 3 1.1. Terminology and Requirements Language . . . . . . . . . . 3
2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . 3 2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . 3
2.1. Bluetooth LE stack . . . . . . . . . . . . . . . . . . . 4 2.1. Bluetooth LE stack . . . . . . . . . . . . . . . . . . . 4
2.2. Link layer roles and topology . . . . . . . . . . . . . . 5 2.2. Link layer roles and topology . . . . . . . . . . . . . . 5
2.3. Bluetooth LE device addressing . . . . . . . . . . . . . 6 2.3. Bluetooth LE device addressing . . . . . . . . . . . . . 6
2.4. Bluetooth LE packet sizes and MTU . . . . . . . . . . . . 6 2.4. Bluetooth LE packet sizes and MTU . . . . . . . . . . . . 6
3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 6 3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 7
3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 7 3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 7
3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. IPv6 subnet model and Internet connectivity . . . . . 9 3.2.1. IPv6 subnet model and Internet connectivity . . . . . 9
3.2.2. Stateless address autoconfiguration . . . . . . . . . 10 3.2.2. Stateless address autoconfiguration . . . . . . . . . 10
3.2.3. Neighbor discovery . . . . . . . . . . . . . . . . . 12 3.2.3. Neighbor discovery . . . . . . . . . . . . . . . . . 12
3.2.4. Header compression . . . . . . . . . . . . . . . . . 13 3.2.4. Header compression . . . . . . . . . . . . . . . . . 13
3.2.4.1. Remote destination example . . . . . . . . . . . 14 3.2.4.1. Remote destination example . . . . . . . . . . . 14
3.2.4.2. Example of registration of multiple-addresses . . 15 3.2.4.2. Example of registration of multiple-addresses . . 15
3.2.5. Unicast and Multicast address mapping . . . . . . . . 15 3.2.5. Unicast and Multicast address mapping . . . . . . . . 16
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Additional contributors . . . . . . . . . . . . . . . . . . . 17 6. Additional contributors . . . . . . . . . . . . . . . . . . . 17
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 18
8.2. Informative References . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Bluetooth Smart is the brand name for the Bluetooth low energy Bluetooth Smart is the brand name for the Bluetooth low energy
feature (hereinafter, Bluetooth LE) in the Bluetooth specification feature (hereinafter, Bluetooth LE) in the Bluetooth specification
defined by the Bluetooth Special Interest Group. Bluetooth LE is a defined by the Bluetooth Special Interest Group. Bluetooth LE is a
radio technology targeted for devices that operate with very low radio technology targeted for devices that operate with very low
capacity (e.g., coin cell) batteries or minimalistic power sources, capacity (e.g., coin cell) batteries or minimalistic power sources,
which means that low power consumption is essential. Bluetooth LE is which means that low power consumption is essential. Bluetooth LE is
skipping to change at page 6, line 15 skipping to change at page 6, line 15
Nevertheless, two peripherals may communicate through the central by Nevertheless, two peripherals may communicate through the central by
using IP routing functionality per this specification. using IP routing functionality per this specification.
2.3. Bluetooth LE device addressing 2.3. Bluetooth LE device addressing
Every Bluetooth LE device is identified by a 48-bit device address. Every Bluetooth LE device is identified by a 48-bit device address.
The Bluetooth specification describes the device address of a The Bluetooth specification describes the device address of a
Bluetooth LE device as:"Devices are identified using a device Bluetooth LE device as:"Devices are identified using a device
address. Device addresses may be either a public device address or a address. Device addresses may be either a public device address or a
random device address." [BTCorev4.1]. The public device addresses random device address." [BTCorev4.1]. The public device addresses
are based on the IEEE 802-2001 standard [IEEE802-2001]. The random are based on the IEEE 802-2001 standard [IEEE802-2001]. Random
device addresses are generated as defined in the Bluetooth device addresses and Bluetooth LE privacy feature are described in
specification. New addresses are typically generated each time a Bluetooth Generic Access Profile specification sections 10.8 and
device is powered on. In random addresses all 48 bits are 10.7, respectively [BTCorev4.1]. There are two types of random
randomized. Bluetooth LE does not support device address collision device addresses: static and private addresses. The private
avoidance or detection. However, these 48 bit random device addresses are further divided into two sub-types: resolvable or non-
addresses have a very small probability of being in conflict within a resolvable addresses, which are explained in depth in the referenced
typical deployment. Bluetooth specification. Once a static address is initialized, it
does not change until the device is power cycled. The static address
can be initialized to a new value after each power cycle, but that is
not mandatory. Recommended time interval before randomizing new
private address is 15 minutes, as determined by timer
T_GAP(private_addr_int) at Bluetooth Generic Access Profile
Table 17.1. The selection of which device address types are used is
implementation and deployment specific. In random addresses first 46
bits are randomized and last 2 bits indicate the random address type.
Bluetooth LE does not support device address collision avoidance or
detection. However, these 48 bit random device addresses have a very
small probability of being in conflict within a typical deployment.
2.4. Bluetooth LE packet sizes and MTU 2.4. Bluetooth LE packet sizes and MTU
The optimal MTU defined for L2CAP fixed channels over Bluetooth LE is The optimal MTU defined for L2CAP fixed channels over Bluetooth LE is
27 octets including the L2CAP header of 4 octets. The default MTU 27 octets including the L2CAP header of 4 octets. The default MTU
for Bluetooth LE is hence defined to be 27 octets. Therefore, for Bluetooth LE is hence defined to be 27 octets. Therefore,
excluding the L2CAP header of 4 octets, a protocol data unit (PDU) excluding the L2CAP header of 4 octets, a protocol data unit (PDU)
size of 23 octets is available for upper layers. In order to be able size of 23 octets is available for upper layers. In order to be able
to transmit IPv6 packets of 1280 octets or larger, a link layer to transmit IPv6 packets of 1280 octets or larger, a link layer
fragmentation and reassembly solution is provided by the L2CAP layer. fragmentation and reassembly solution is provided by the L2CAP layer.
skipping to change at page 10, line 49 skipping to change at page 10, line 49
<--------- Subnet ----------> <--------- Subnet ---------->
Figure 5: Isolated Bluetooth LE network Figure 5: Isolated Bluetooth LE network
3.2.2. Stateless address autoconfiguration 3.2.2. Stateless address autoconfiguration
At network interface initialization, both 6LN and 6LBR SHALL generate At network interface initialization, both 6LN and 6LBR SHALL generate
and assign to the Bluetooth LE network interface IPv6 link-local and assign to the Bluetooth LE network interface IPv6 link-local
addresses [RFC4862] based on the 48-bit Bluetooth device addresses addresses [RFC4862] based on the 48-bit Bluetooth device addresses
(see Section 2.3) that were used for establishing the underlying (see Section 2.3) that were used for establishing the underlying
Bluetooth LE connection. Following the guidance of [RFC7136], a Bluetooth LE connection. A 6LN and a 6LBR are RECOMMENDED to use
64-bit Interface Identifier (IID) is formed from the 48-bit Bluetooth random Bluetooth device addresses. A 6LN SHOULD pick a different
device address by inserting two octets, with hexadecimal values of Bluetooth device address for every Bluetooth LE connection with a
0xFF and 0xFE in the middle of the 48-bit Bluetooth device address as 6LBR, and a 6LBR SHOULD periodically change its random Bluetooth
shown in Figure 6. In the Figure letter 'b' represents a bit from device address. Following the guidance of [RFC7136], a 64-bit
the Bluetooth device address, copied as is without any changes on any Interface Identifier (IID) is formed from the 48-bit Bluetooth device
address by inserting two octets, with hexadecimal values of 0xFF and
0xFE in the middle of the 48-bit Bluetooth device address as shown in
Figure 6. In the Figure letter 'b' represents a bit from the
Bluetooth device address, copied as is without any changes on any
bit. This means that no bit in the IID indicates whether the bit. This means that no bit in the IID indicates whether the
underlying Bluetooth device address is public or random. underlying Bluetooth device address is public or random.
|0 1|1 3|3 4|4 6| |0 1|1 3|3 4|4 6|
|0 5|6 1|2 7|8 3| |0 5|6 1|2 7|8 3|
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
|bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb|bbbbbbbbbbbbbbbb| |bbbbbbbbbbbbbbbb|bbbbbbbb11111111|11111110bbbbbbbb|bbbbbbbbbbbbbbbb|
+----------------+----------------+----------------+----------------+ +----------------+----------------+----------------+----------------+
Figure 6: Formation of IID from Bluetooth device adddress Figure 6: Formation of IID from Bluetooth device adddress
skipping to change at page 11, line 44 skipping to change at page 12, line 4
Figure 7: IPv6 link-local address in Bluetooth LE Figure 7: IPv6 link-local address in Bluetooth LE
A 6LN MUST join the all-nodes multicast address. There is no need A 6LN MUST join the all-nodes multicast address. There is no need
for 6LN to join the solicited-node multicast address, since 6LBR will for 6LN to join the solicited-node multicast address, since 6LBR will
know device addresses and hence link-local addresses of all connected know device addresses and hence link-local addresses of all connected
6LNs. The 6LBR will ensure no two devices with the same Bluetooth LE 6LNs. The 6LBR will ensure no two devices with the same Bluetooth LE
device address are connected at the same time. Detection of device address are connected at the same time. Detection of
duplicate link-local addresses is performed by the process on the duplicate link-local addresses is performed by the process on the
6LBR responsible for the discovery of IP-enabled Bluetooth LE nodes 6LBR responsible for the discovery of IP-enabled Bluetooth LE nodes
and for starting Bluetooth LE connection establishment procedures. and for starting Bluetooth LE connection establishment procedures.
This approach increases the complexity of 6LBR, but reduces power This approach increases the complexity of 6LBR, but reduces power
consumption on both 6LN and 6LBR in the link establishment phase by consumption on both 6LN and 6LBR in the link establishment phase by
reducing the number of mandatory packet transmissions. reducing the number of mandatory packet transmissions.
After link-local address configuration, the 6LN sends Router After link-local address configuration, the 6LN sends Router
Solicitation messages as described in [RFC4861] Section 6.3.7. Solicitation messages as described in [RFC4861] Section 6.3.7.
For non-link-local addresses, 6LNs SHOULD NOT be configured to embed For non-link-local addresses, 6LNs SHOULD NOT be configured to embed
the Bluetooth device address in the IID by default. Alternative the Bluetooth device address in the IID by default. Alternative
schemes such as Cryptographically Generated Addresses (CGA) schemes such as Cryptographically Generated Addresses (CGA)
[RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBA, [RFC3972], privacy extensions [RFC4941], Hash-Based Addresses (HBA,
[RFC5535]), DHCPv6 [RFC3315], or static, semantically opaque addreses [RFC5535]), DHCPv6 [RFC3315], or static, semantically opaque addreses
[RFC7217] SHOULD be used by default. In situations where the [RFC7217] SHOULD be used by default. In situations where the
Bluetooth device address is known to be randomly generated and/or the Bluetooth device address is known to be a random device address (i.e.
header compression benefits of embedding the device address in the a static or private device address) and/or the header compression
IID are required to support deployment constraints, 6LNs MAY form a benefits of embedding the device address in the IID are required to
64-bit IID by utilizing the 48-bit Bluetooth device address. The support deployment constraints, 6LNs MAY form a 64-bit IID by
non-link-local addresses that a 6LN generates MUST be registered with utilizing the 48-bit Bluetooth device address. The non-link-local
the 6LBR as described in Section 3.2.3. addresses that a 6LN generates MUST be registered with the 6LBR as
described in Section 3.2.3.
The tool for a 6LBR to obtain an IPv6 prefix for numbering the The tool for a 6LBR to obtain an IPv6 prefix for numbering the
Bluetooth LE network is out of scope of this document, but can be, Bluetooth LE network is out of scope of this document, but can be,
for example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or for example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or
by using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to by using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to
the link model of the Bluetooth LE (see Section 3.2.1) the 6LBR MUST the link model of the Bluetooth LE (see Section 3.2.1) the 6LBR MUST
set the "on-link" flag (L) to zero in the Prefix Information Option set the "on-link" flag (L) to zero in the Prefix Information Option
in Neighbor Discovery messages[RFC4861] (see Section 3.2.3). This in Neighbor Discovery messages[RFC4861] (see Section 3.2.3). This
will cause 6LNs to always send packets to the 6LBR, including the will cause 6LNs to always send packets to the 6LBR, including the
case when the destination is another 6LN using the same prefix. case when the destination is another 6LN using the same prefix.
skipping to change at page 18, line 11 skipping to change at page 18, line 21
Specification Version 4.1", December 2013, Specification Version 4.1", December 2013,
<https://www.bluetooth.org/en-us/specification/adopted- <https://www.bluetooth.org/en-us/specification/adopted-
specifications>. specifications>.
[IPSP] Bluetooth Special Interest Group, "Bluetooth Internet [IPSP] Bluetooth Special Interest Group, "Bluetooth Internet
Protocol Support Profile Specification Version 1.0.0", Protocol Support Profile Specification Version 1.0.0",
December 2014, <https://www.bluetooth.org/en- December 2014, <https://www.bluetooth.org/en-
us/specification/adopted-specifications>. us/specification/adopted-specifications>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>. 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>. <http://www.rfc-editor.org/info/rfc4861>.
 End of changes. 12 change blocks. 
30 lines changed or deleted 49 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/