< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/