< draft-ietf-6lo-btle-06.txt		draft-ietf-6lo-btle-07.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 13, 2015 Nokia		Expires: July 20, 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 9, 2015		January 16, 2015
	Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy		Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy
	draft-ietf-6lo-btle-06		draft-ietf-6lo-btle-07
	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 13, 2015.		This Internet-Draft will expire on July 20, 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 27 ¶		skipping to change at page 8, line 27 ¶
	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. A 64-bit Interface Identifier (IID) is
	formed from 48-bit Bluetooth device address by inserting two octets,		formed from 48-bit Bluetooth device address by inserting two octets,
	with hexadecimal values of 0xFF and 0xFE in the middle of the 48-bit		with hexadecimal values of 0xFF and 0xFE in the middle of the 48-bit
	Bluetooth device address as shown in Figure 4. In the Figure letter		Bluetooth device address as shown in Figure 4. In the Figure letter
	'b' represents a bit from Bluetooth device address.		'b' represents a bit from Bluetooth device address, copied as is
			without any changes on any bit.
	|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 10, line 11 ¶		skipping to change at page 10, line 11 ¶
	'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless		'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
	Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor		Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor
	discovery approach as adapted for use in several 6LoWPAN topologies,		discovery approach as adapted for use in several 6LoWPAN topologies,
	including the mesh topology. Bluetooth LE does not support mesh		including the mesh topology. Bluetooth LE does not support mesh
	networks and hence only those aspects that apply to a star topology		networks and hence only those aspects that apply to a star topology
	are considered.		are considered.
	The following aspects of the Neighbor Discovery optimizations		The following aspects of the Neighbor Discovery optimizations
	[RFC6775] are applicable to Bluetooth LE 6LNs:		[RFC6775] are applicable to Bluetooth LE 6LNs:
	1. A Bluetooth LE 6LN SHOULD NOT register its IID for link-local		1. A Bluetooth LE 6LN SHOULD NOT register its link-local address. A
	address. A Bluetooth LE 6LN MUST register its IIDs for non-link-		Bluetooth LE 6LN MUST register its non-link-local addresses with the
	local addresses with the 6LBR by sending a Neighbor Solicitation (NS)		6LBR by sending a Neighbor Solicitation (NS) message with the Address
	message with the Address Registration Option (ARO) and process the		Registration Option (ARO) and process the Neighbor Advertisement (NA)
	Neighbor Advertisement (NA) accordingly. The NS with the ARO option		accordingly. The NS with the ARO option MUST be sent irrespective of
	MUST be sent irrespective of the method used to generate the IID. If		the method used to generate the IID. If the 6LN registers for a same
	the 6LN registers multiple IIDs per IPv6 prefix available on a link,		compression context multiple addresses that are not based on
	the 6LBR will not be able to fully elide IID on downlink packets		Bluetooth device address, the 6LN and 6LBR will be unable to compress
	(6LBR has to send IID bits inline).		IID 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
End of changes. 6 change blocks.
	14 lines changed or deleted		15 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/