draft-ietf-6lo-btle-07.txt   draft-ietf-6lo-btle-08.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: July 20, 2015 Nokia Expires: August 17, 2015 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
January 16, 2015 February 13, 2015
Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy
draft-ietf-6lo-btle-07 draft-ietf-6lo-btle-08
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 47 skipping to change at page 1, line 47
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 July 20, 2015. This Internet-Draft will expire on August 17, 2015.
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 3, line 43 skipping to change at page 3, line 43
Bluetooth LE is designed for transferring small amounts of data Bluetooth LE is designed for transferring small amounts of data
infrequently at modest data rates at a very low cost per bit. infrequently at modest data rates at a very low cost per bit.
Bluetooth Special Interest Group (Bluetooth SIG) has introduced two Bluetooth Special Interest Group (Bluetooth SIG) has introduced two
trademarks, Bluetooth Smart for single-mode devices (a device that trademarks, Bluetooth Smart for single-mode devices (a device that
only supports Bluetooth LE) and Bluetooth Smart Ready for dual-mode only supports Bluetooth LE) and Bluetooth Smart Ready for dual-mode
devices (devices that support both Bluetooth and Bluetooth LE). In devices (devices that support both Bluetooth and Bluetooth LE). In
the rest of the document, the term Bluetooth LE refers to both types the rest of the document, the term Bluetooth LE refers to both types
of devices. of devices.
Bluetooth LE was introduced in Bluetooth 4.0 and further enhanced in Bluetooth LE was introduced in Bluetooth 4.0, enhanced in Bluetooth
Bluetooth 4.1 [BTCorev4.1]. Bluetooth SIG has also published 4.1 [BTCorev4.1], and developed even further in successive versions.
Internet Protocol Support Profile (IPSP) [IPSP], which includes Bluetooth SIG has also published Internet Protocol Support Profile
Internet Protocol Support Service (IPSS). The IPSP enables discovery (IPSP) [IPSP], which includes Internet Protocol Support Service
of IP-enabled devices and establishment of link-layer connection for (IPSS). The IPSP enables discovery of IP-enabled devices and
transporting IPv6 packets. IPv6 over Bluetooth LE is dependent on establishment of link-layer connection for transporting IPv6 packets.
both Bluetooth 4.1 and IPSP 1.0 or newer. IPv6 over Bluetooth LE is dependent on both Bluetooth 4.1 and IPSP
1.0 or newer.
Devices such as mobile phones, notebooks, tablets and other handheld Devices such as mobile phones, notebooks, tablets and other handheld
computing devices which will include Bluetooth 4.1 chipsets will also computing devices which will include Bluetooth 4.1 chipsets will also
have the low-energy functionality of Bluetooth. Bluetooth LE will have the low-energy functionality of Bluetooth. Bluetooth LE will
also be included in many different types of accessories that also be included in many different types of accessories that
collaborate with mobile devices such as phones, tablets and notebook collaborate with mobile devices such as phones, tablets and notebook
computers. An example of a use case for a Bluetooth LE accessory is computers. An example of a use case for a Bluetooth LE accessory is
a heart rate monitor that sends data via the mobile phone to a server a heart rate monitor that sends data via the mobile phone to a server
on the Internet. on the Internet.
skipping to change at page 5, line 47 skipping to change at page 5, line 47
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]. The random
device addresses are generated as defined in the Bluetooth device addresses are generated as defined in the Bluetooth
specification. These random device addresses have a very small specification. In random addresses all 48 bits are randomized.
chance of being in conflict, as Bluetooth LE does not support random These random device addresses have a very small chance of being in
device address collision avoidance or detection. conflict, as Bluetooth LE does not support random device address
collision avoidance or detection.
2.4. Bluetooth LE packets sizes and MTU 2.4. Bluetooth LE packets sizes and MTU
Optimal MTU defined for L2CAP fixed channels over Bluetooth LE is 27 Optimal MTU defined for L2CAP fixed channels over Bluetooth LE is 27
bytes including the L2CAP header of four bytes. Default MTU for bytes including the L2CAP header of four bytes. Default MTU for
Bluetooth LE is hence defined to be 27 bytes. Therefore, excluding Bluetooth LE is hence defined to be 27 bytes. Therefore, excluding
L2CAP header of four bytes, protocol data unit (PDU) size of 23 bytes L2CAP header of four bytes, protocol data unit (PDU) size of 23 bytes
is available for upper layers. In order to be able to transmit IPv6 is available for upper layers. In order to be able to transmit IPv6
packets of 1280 bytes or larger, link layer fragmentation and packets of 1280 bytes or larger, link layer fragmentation and
reassembly solution is provided by the L2CAP layer. The IPSP defines reassembly solution is provided by the L2CAP layer. The IPSP defines
skipping to change at page 8, line 23 skipping to change at page 8, line 23
After the peripheral and central have connected at the Bluetooth LE After the peripheral and central have connected at the Bluetooth LE
level, the link can be considered up and IPv6 address configuration level, the link can be considered up and IPv6 address configuration
and transmission can begin. and transmission can begin.
3.2.1. Stateless address autoconfiguration 3.2.1. 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 underlying (see Section 2.3) that were used for establishing underlying
Bluetooth LE connection. A 64-bit Interface Identifier (IID) is Bluetooth LE connection. Following guidance of [RFC7136], a 64-bit
formed from 48-bit Bluetooth device address by inserting two octets, Interface Identifier (IID) is formed from 48-bit Bluetooth device
with hexadecimal values of 0xFF and 0xFE in the middle of the 48-bit address by inserting two octets, with hexadecimal values of 0xFF and
Bluetooth device address as shown in Figure 4. In the Figure letter 0xFE in the middle of the 48-bit Bluetooth device address as shown in
'b' represents a bit from Bluetooth device address, copied as is Figure 4. In the Figure letter 'b' represents a bit from Bluetooth
without any changes on any bit. device address, copied as is without any changes on any bit. This
means that no bit in IID indicates whether the 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 4: Formation of IID from Bluetooth device adddress Figure 4: Formation of IID from Bluetooth device adddress
The IID is then appended with prefix fe80::/64, as described in RFC The IID is then appended with prefix fe80::/64, as described in RFC
skipping to change at page 9, line 34 skipping to change at page 9, line 34
After link-local address configuration, 6LN sends Router Solicitation After link-local address configuration, 6LN sends Router Solicitation
messages as described in [RFC4861] Section 6.3.7. messages as described in [RFC4861] Section 6.3.7.
For non-link-local addresses a 64-bit IID MAY be formed by utilizing For non-link-local addresses a 64-bit IID MAY be formed by utilizing
the 48-bit Bluetooth device address. Alternatively, a randomly the 48-bit Bluetooth device address. Alternatively, a randomly
generated IID (see Section 3.2.2) can be used instead, for example, generated IID (see Section 3.2.2) can be used instead, for example,
as discussed in [I-D.ietf-6man-default-iids]. The non-link-local as discussed in [I-D.ietf-6man-default-iids]. The non-link-local
addresses 6LN generates must be registered with 6LBR as described in addresses 6LN generates must be registered with 6LBR as described in
Section 3.2.2. Section 3.2.2.
Only if the Bluetooth device address is known to be a public address
the "Universal/Local" bit can be set to 1 [RFC4291].
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 2.2) the 6LBR MUST the link model of the Bluetooth LE (see Section 2.2) 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
[RFC4861]. This will cause 6LNs to always send packets to the 6LBR, [RFC4861]. This will cause 6LNs to always send packets to the 6LBR,
including the case when the destination is another 6LN using the same including the case when the destination is another 6LN using the same
prefix. prefix.
skipping to change at page 10, line 19 skipping to change at page 10, line 16
[RFC6775] are applicable to Bluetooth LE 6LNs: [RFC6775] are applicable to Bluetooth LE 6LNs:
1. A Bluetooth LE 6LN SHOULD NOT register its link-local address. A 1. A Bluetooth LE 6LN SHOULD NOT register its link-local address. A
Bluetooth LE 6LN MUST register its non-link-local addresses with the Bluetooth LE 6LN MUST register its non-link-local addresses with the
6LBR by sending a Neighbor Solicitation (NS) message with the Address 6LBR by sending a Neighbor Solicitation (NS) message with the Address
Registration Option (ARO) and process the Neighbor Advertisement (NA) Registration Option (ARO) and process the Neighbor Advertisement (NA)
accordingly. The NS with the ARO option MUST be sent irrespective of accordingly. The NS with the ARO option MUST be sent irrespective of
the method used to generate the IID. If the 6LN registers for a same the method used to generate the IID. If the 6LN registers for a same
compression context multiple addresses that are not based on compression context multiple addresses that are not based on
Bluetooth device address, the 6LN and 6LBR will be unable to compress Bluetooth device address, the 6LN and 6LBR will be unable to compress
IID and hence have to send IID bits inline. IIDs and hence have to send IID bits inline.
2. For sending Router Solicitations and processing Router 2. For sending Router Solicitations and processing Router
Advertisements the Bluetooth LE 6LNs MUST, respectively, follow Advertisements the Bluetooth LE 6LNs MUST, respectively, follow
Sections 5.3 and 5.4 of the [RFC6775]. Sections 5.3 and 5.4 of the [RFC6775].
3.2.3. Header compression 3.2.3. Header compression
Header compression as defined in RFC 6282 [RFC6282], which specifies Header compression as defined in RFC 6282 [RFC6282], which specifies
the compression format for IPv6 datagrams on top of IEEE 802.15.4, is the compression format for IPv6 datagrams on top of IEEE 802.15.4, is
REQUIRED in this document as the basis for IPv6 header compression on REQUIRED in this document as the basis for IPv6 header compression on
skipping to change at page 15, line 36 skipping to change at page 15, line 21
[RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
September 2011. September 2011.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power "Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012. November 2012.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, February 2014.
8.2. Informative References 8.2. Informative References
[I-D.ietf-6man-default-iids] [I-D.ietf-6man-default-iids]
Gont, F., Cooper, A., Thaler, D., and W. Will, Gont, F., Cooper, A., Thaler, D., and W. Will,
"Recommendation on Stable IPv6 Interface Identifiers", "Recommendation on Stable IPv6 Interface Identifiers",
draft-ietf-6man-default-iids-01 (work in progress), draft-ietf-6man-default-iids-02 (work in progress),
October 2014. January 2015.
[IEEE802-2001] [IEEE802-2001]
Institute of Electrical and Electronics Engineers (IEEE), Institute of Electrical and Electronics Engineers (IEEE),
"IEEE 802-2001 Standard for Local and Metropolitan Area "IEEE 802-2001 Standard for Local and Metropolitan Area
Networks: Overview and Architecture", 2002. Networks: Overview and Architecture", 2002.
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with
CBC-MAC (CCM)", RFC 3610, September 2003. CBC-MAC (CCM)", RFC 3610, September 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
 End of changes. 11 change blocks. 
26 lines changed or deleted 30 lines changed or added

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