draft-ietf-6lo-btle-08.txt   draft-ietf-6lo-btle-09.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: August 17, 2015 Nokia Expires: August 22, 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
February 13, 2015 February 18, 2015
Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy
draft-ietf-6lo-btle-08 draft-ietf-6lo-btle-09
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 August 17, 2015. This Internet-Draft will expire on August 22, 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 8, line 4 skipping to change at page 7, line 52
6LoWPAN can function [IPSP], including handling the link-layer 6LoWPAN can function [IPSP], including handling the link-layer
fragmentation required on Bluetooth LE, as described in Section 2.4. fragmentation required on Bluetooth LE, as described in Section 2.4.
While Bluetooth LE protocols, such as L2CAP, utilize little-endian While Bluetooth LE protocols, such as L2CAP, utilize little-endian
byte orderering, IPv6 packets MUST be transmitted in big endian order byte orderering, IPv6 packets MUST be transmitted in big endian order
(network byte order). (network byte order).
This specification requires IPv6 header compression format specified This specification requires IPv6 header compression format specified
in RFC 6282 to be used [RFC6282]. It is assumed that the IPv6 in RFC 6282 to be used [RFC6282]. It is assumed that the IPv6
payload length can be inferred from the L2CAP header length and the payload length can be inferred from the L2CAP header length and the
IID value inferred from the link-layer address with help of Neighbor possibly elided IPv6 address can be inferred from the link-layer
Cache, if elided from compressed packet header. address, at the time of Bluetooth LE connection establishment, from
the HCI Connection Handle during connection, and from context if any.
Bluetooth LE connections used to build a star topology are point-to- Bluetooth LE connections used to build a star topology are point-to-
point in nature, as Bluetooth broadcast features are not used for point in nature, as Bluetooth broadcast features are not used for
IPv6 over Bluetooth LE. 6LN-to-6LN communications, e.g. using link- IPv6 over Bluetooth LE. 6LN-to-6LN communications, e.g. using link-
local addresses, need to be bridged by the 6LBR. The 6LBR ensures local addresses, need to be bridged by the 6LBR. The 6LBR ensures
address collisions do not occur (see Section 3.2.2). address collisions do not occur (see Section 3.2.2).
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.
skipping to change at page 9, line 28 skipping to change at page 9, line 28
software responsible of discovery of IP-enabled Bluetooth LE nodes software responsible of discovery of IP-enabled Bluetooth LE nodes
and of starting Bluetooth LE connection establishment procedures. and of starting Bluetooth LE connection establishment procedures.
This approach increases complexity of 6LBR, but reduces power This approach increases complexity of 6LBR, but reduces power
consumption on both 6LN and 6LBR at link establishment phase by consumption on both 6LN and 6LBR at link establishment phase by
reducing number of mandatory packet transmissions. reducing number of mandatory packet transmissions.
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. A 6LN can also use a randomly
generated IID (see Section 3.2.2) can be used instead, for example, generated IID (see Section 3.2.2), for example, as discussed in
as discussed in [I-D.ietf-6man-default-iids]. The non-link-local [I-D.ietf-6man-default-iids], or use alternatice schemes such as
addresses 6LN generates must be registered with 6LBR as described in Cryptographically Generated Addresses (CGA) [RFC3972], privacy
Section 3.2.2. extensions [RFC4941], Hash-Based Addresses (HBA, [RFC5535]), or
DHCPv6 [RFC3315]. The non-link-local addresses 6LN generates must be
registered with 6LBR as described in Section 3.2.2.
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 31 skipping to change at page 10, line 33
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
top of Bluetooth LE. All headers MUST be compressed according to RFC top of Bluetooth LE. All headers MUST be compressed according to RFC
6282 [RFC6282] encoding formats. 6282 [RFC6282] encoding formats.
The Bluetooth LE's star topology structure and ARO can be exploited The Bluetooth LE's star topology structure and ARO can be exploited
in order to provide a mechanism for IID compression. The following in order to provide a mechanism for address compression. The
text describes the principles of IPv6 address compression on top of following text describes the principles of IPv6 address compression
Bluetooth LE. on top of Bluetooth LE.
The ARO option requires use of EUI-64 identifier [RFC6775]. In the The ARO option requires use of EUI-64 identifier [RFC6775]. In the
case of Bluetooth LE, the field SHALL be filled with the 48-bit case of Bluetooth LE, the field SHALL be filled with the 48-bit
device address used by the Bluetooth LE node converted into 64-bit device address used by the Bluetooth LE node converted into 64-bit
Modified EUI-64 format [RFC4291]. Modified EUI-64 format [RFC4291].
To enable efficient header compression, the 6LBR MUST include 6LoWPAN To enable efficient header compression, the 6LBR MUST include 6LoWPAN
Context Option (6CO) [RFC6775] for all prefixes the 6LBR advertises Context Option (6CO) [RFC6775] for all prefixes the 6LBR advertises
in Router Advertisements for use in stateless address in Router Advertisements for use in stateless address
autoconfiguration. autoconfiguration.
skipping to change at page 14, line 5 skipping to change at page 14, line 9
Key management in Bluetooth LE is provided by the Security Manager Key management in Bluetooth LE is provided by the Security Manager
Protocol (SMP), as defined in [BTCorev4.1]. Protocol (SMP), as defined in [BTCorev4.1].
The IPv6 link-local address configuration described in Section 3.2.1 The IPv6 link-local address configuration described in Section 3.2.1
strictly binds the privacy level of IPv6 link-local address to the strictly binds the privacy level of IPv6 link-local address to the
privacy level device has selected for the Bluetooth LE. This means privacy level device has selected for the Bluetooth LE. This means
that a device using Bluetooth privacy features will retain the same that a device using Bluetooth privacy features will retain the same
level of privacy with generated IPv6 link-local addresses. level of privacy with generated IPv6 link-local addresses.
Respectively, device not using privacy at Bluetooth level will not Respectively, device not using privacy at Bluetooth level will not
have privacy at IPv6 link-local address either. For non-link local have privacy at IPv6 link-local address either. For non-link local
addresses implementations have a choice to support addresses implementations have a choice to support, for example,
[I-D.ietf-6man-default-iids]. [I-D.ietf-6man-default-iids], [RFC3972], [RFC4941] or [RFC5535].
6. Additional contributors 6. Additional contributors
Kanji Kerai, Jari Mutikainen, David Canfeng-Chen and Minjun Xi from Kanji Kerai, Jari Mutikainen, David Canfeng-Chen and Minjun Xi from
Nokia have contributed significantly to this document. Nokia have contributed significantly to this document.
7. Acknowledgements 7. Acknowledgements
The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are
registred trademarks owned by Bluetooth SIG, Inc. registred trademarks owned by Bluetooth SIG, Inc.
skipping to change at page 15, line 37 skipping to change at page 15, line 42
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-02 (work in progress), draft-ietf-6man-default-iids-02 (work in progress),
January 2015. 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.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[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
Host Configuration Protocol (DHCP) version 6", RFC 3633, Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003. December 2003.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535, June
2009.
Authors' Addresses Authors' Addresses
Johanna Nieminen Johanna Nieminen
Nokia Nokia
Email: johannamaria.nieminen@gmail.com Email: johannamaria.nieminen@gmail.com
Teemu Savolainen Teemu Savolainen
Nokia Nokia
Visiokatu 3 Visiokatu 3
 End of changes. 12 change blocks. 
16 lines changed or deleted 33 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/