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