< draft-ietf-6lowpan-btle-11.txt		draft-ietf-6lowpan-btle-12.txt >
	6LoWPAN Working Group J. Nieminen, Ed.		6LoWPAN Working Group J. Nieminen, Ed.
	Internet-Draft T. Savolainen, Ed.		Internet-Draft T. Savolainen, Ed.
	Intended status: Standards Track M. Isomaki		Intended status: Standards Track M. Isomaki
	Expires: April 15, 2013 Nokia		Expires: August 16, 2013 Nokia
	B. Patil		B. Patil
	Z. Shelby		Z. Shelby
	Sensinode		Sensinode
	C. Gomez		C. Gomez
	Universitat Politecnica de		Universitat Politecnica de
	Catalunya/i2CAT		Catalunya/i2CAT
	October 12, 2012		February 12, 2013
	Transmission of IPv6 Packets over BLUETOOTH Low Energy		Transmission of IPv6 Packets over BLUETOOTH Low Energy
	draft-ietf-6lowpan-btle-11		draft-ietf-6lowpan-btle-12
	Abstract		Abstract
	BLUETOOTH Low Energy is a low power air interface technology defined		BLUETOOTH Low Energy is a low power air interface technology defined
	by the BLUETOOTH Special Interest Group (BT-SIG). The standard		by the BLUETOOTH Special Interest Group (BT-SIG). The standard
	BLUETOOTH radio has been widely implemented and available in mobile		BLUETOOTH radio has been widely implemented and available in mobile
	phones, notebook computers, audio headsets and many other devices.		phones, notebook computers, audio headsets and many other devices.
	The low power version of BLUETOOTH is a new specification that		The low power version of BLUETOOTH is a new specification that
	enables the use of this air interface with devices such as sensors,		enables the use of this air interface with devices such as sensors,
	smart meters, appliances, etc. The low power variant of BLUETOOTH is		smart meters, appliances, etc. The low power variant of BLUETOOTH is
	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 April 15, 2013.		This Internet-Draft will expire on August 16, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 35 ¶		skipping to change at page 3, line 35 ¶
	defined in the RFC 4944 can be applied to the transmission of IPv6 on		defined in the RFC 4944 can be applied to the transmission of IPv6 on
	BT-LE links. This document specifies the details of IPv6		BT-LE links. This document specifies the details of IPv6
	transmission over BT-LE links.		transmission over BT-LE links.
	1.1. Terminology and Requirements Language		1.1. Terminology and Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	The terms 6LN, 6LR and 6LBR are defined as in [I-D.ietf-6lowpan-nd],		The terms 6LN, 6LR and 6LBR are defined as in [RFC6775], with an
	with an addition that BT-LE master and BT-LE slave can both be either		addition that BT-LE master and BT-LE slave can both be either 6LN or
	6LN or 6LBR.		6LBR.
	2. BLUETOOTH Low Energy		2. BLUETOOTH Low Energy
	BT-LE is designed for transferring small amounts of data infrequently		BT-LE is designed for transferring small amounts of data infrequently
	at modest data rates at a very low cost per bit. BLUETOOTH Special		at modest data rates at a very low cost per bit. BLUETOOTH Special
	Interest Group has introduced two trademarks, BLUETOOTH Smart for		Interest Group has introduced two trademarks, BLUETOOTH Smart for
	single-mode devices (a device that only supports BT-LE) and BLUETOOTH		single-mode devices (a device that only supports BT-LE) and BLUETOOTH
	Smart Ready for dual-mode devices. In the rest of the draft, the		Smart Ready for dual-mode devices. In the rest of the draft, the
	term BT-LE refers to both types of devices.		term BT-LE refers to both types of devices.
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 13 ¶
	payload size (i.e. IPv6 datagram size) of 65535 bytes per L2CAP PDU.		payload size (i.e. IPv6 datagram size) of 65535 bytes per L2CAP PDU.
	The rest of the L2CAP modes allow a maximum payload size that ranges		The rest of the L2CAP modes allow a maximum payload size that ranges
	between 65527 and 65533 bytes per L2CAP PDU. Appendix A describes		between 65527 and 65533 bytes per L2CAP PDU. Appendix A describes
	FAR operation and five L2CAP Modes.		FAR operation and five L2CAP Modes.
	3. Specification of IPv6 over BLUETOOTH Low Energy		3. Specification of IPv6 over BLUETOOTH Low Energy
	BT-LE technology sets strict requirements for low power consumption		BT-LE technology sets strict requirements for low power consumption
	and thus limits the allowed protocol overhead. 6LoWPAN standards		and thus limits the allowed protocol overhead. 6LoWPAN standards
	[RFC4944], [I-D.ietf-6lowpan-nd] and [RFC6282] provide useful generic		[RFC4944], [RFC6775], and [RFC6282] provide useful functionality for
	functionality like header compression (see Section 3.2.3), link-local		reducing overhead which can be applied to BT-LE. This functionality
	IPv6 addresses, Neighbor Discovery (see Section 3.2.2) and stateless		comprises of link-local IPv6 addresses and stateless IPv6 address
	IPv6 address autoconfiguration (see Section 3.2.1) for reducing the		autoconfiguration (see Section 3.2.1), Neighbor Discovery (see
	overhead in 802.15.4 networks. This functionality can be partly		Section 3.2.2) and header compression (see Section 3.2.3).
	applied to BT-LE.
	A significant difference between IEEE 802.15.4 and BT-LE is that the		A significant difference between IEEE 802.15.4 and BT-LE is that the
	former supports both star and mesh topology (and requires a routing		former supports both star and mesh topology (and requires a routing
	protocol), whereas BT-LE does not currently support the formation of		protocol), whereas BT-LE does not currently support the formation of
	multihop networks at the link layer. In consequence, the mesh header		multihop networks at the link layer. In consequence, the mesh header
	defined in [RFC4944] for mesh under routing MUST NOT be used in BT-LE		defined in [RFC4944] for mesh under routing MUST NOT be used in BT-LE
	networks. In addition, a BT-LE node MUST NOT play the role of a		networks. In addition, a BT-LE node MUST NOT play the role of a
	6LoWPAN Router (6LR).		6LoWPAN Router (6LR).
	3.1. Protocol stack		3.1. Protocol stack
	skipping to change at page 9, line 7 ¶		skipping to change at page 9, line 7 ¶
	network is out of scope of this document, but can be, for example,		network is out of scope of this document, but can be, for example,
	accomplished via DHCPv6 Prefix Delegation [RFC3633] or by using		accomplished via DHCPv6 Prefix Delegation [RFC3633] or by using
	Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to the link		Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to the link
	model of the BT-LE (see Section 2.2) the 6LBR MUST set the "on-link"		model of the BT-LE (see Section 2.2) the 6LBR MUST set the "on-link"
	flag (L) to zero in the Prefix Information Option [RFC4861]. This		flag (L) to zero in the Prefix Information Option [RFC4861]. This
	will cause 6LNs to always send packets to the 6LBR, including the		will cause 6LNs to always send packets to the 6LBR, including the
	case when the destination is another 6LN using the same prefix.		case when the destination is another 6LN using the same prefix.
	3.2.2. Neighbor discovery		3.2.2. Neighbor discovery
	'Neighbor Discovery Optimization for Low Power and Lossy Networks'		'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
	[I-D.ietf-6lowpan-nd] describes the neighbor discovery approach as		Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor
	adapted for use in several 6LoWPAN topologies, including the mesh		discovery approach as adapted for use in several 6LoWPAN topologies,
	topology. BT-LE does not support mesh networks and hence only those		including the mesh topology. BT-LE does not support mesh networks
	aspects that apply to a star topology are considered.		and hence only those aspects that apply to a star topology are
			considered.
	The following aspects of the Neighbor Discovery optimizations		The following aspects of the Neighbor Discovery optimizations
	[I-D.ietf-6lowpan-nd] are applicable to BT-LE 6LNs:		[RFC6775] are applicable to BT-LE 6LNs:
	1. A BT-LE 6LN MUST register its address with the 6LBR by sending a		1. A BT-LE 6LN MUST register its address with the 6LBR by sending a
	Neighbor Solicitation (NS) message with the ARO option and process		Neighbor Solicitation (NS) message with the ARO option and process
	the Neighbor Advertisement (NA) accordingly. The NS with the ARO		the Neighbor Advertisement (NA) accordingly. The NS with the ARO
	option SHOULD be sent irrespective of whether the IID is derived from		option SHOULD be sent irrespective of whether the IID is derived from
	the unique 48 bit BT-LE device address or the IID is a random value		the unique 48 bit BT-LE device address or the IID is a random value
	that is generated as per the privacy extensions for stateless address		that is generated as per the privacy extensions for stateless address
	autoconfiguration [RFC4941]. Although RFC 4941 [RFC4941] permits the		autoconfiguration [RFC4941]. Although RFC 4941 [RFC4941] permits the
	use of deprecated addresses for old connections, in this		use of deprecated addresses for old connections, in this
	specification we mandate that one interface MUST NOT use more than		specification we mandate that one interface MUST NOT use more than
	one IID at any one time.		one IID at any one time.
	2. For sending Router Solicitations and processing Router		2. For sending Router Solicitations and processing Router
	Advertisements the BT-LE 6LNs MUST, respectively, follow Sections 5.3		Advertisements the BT-LE 6LNs MUST, respectively, follow Sections 5.3
	and 5.4 of the [I-D.ietf-6lowpan-nd].		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
	top of BT-LE. All headers MUST be compressed according to RFC 6282		top of BT-LE. All headers MUST be compressed according to RFC 6282
	[RFC6282] encoding formats. The BT-LE's star topology structure can		[RFC6282] encoding formats. The BT-LE's star topology structure can
	be exploited in order to provide a mechanism for IID compression.		be exploited in order to provide a mechanism for IID compression.
	The following text describes the principles of IPv6 address		The following text describes the principles of IPv6 address
	skipping to change at page 13, line 10 ¶		skipping to change at page 13, line 10 ¶
	Samita Chakrabarti, Erik Nordmark, and Marcel De Kogel have provided		Samita Chakrabarti, Erik Nordmark, and Marcel De Kogel have provided
	valuable feedback for this draft.		valuable feedback for this draft.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[BTCorev4.0]		[BTCorev4.0]
	BLUETOOTH Special Interest Group, "BLUETOOTH Specification		BLUETOOTH Special Interest Group, "BLUETOOTH Specification
	Version 4.0", June 2010.		Version 4.0", June 2010.
	[I-D.ietf-6lowpan-nd]
	Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
	Discovery Optimization for Low Power and Lossy Networks
	(6LoWPAN)", draft-ietf-6lowpan-nd-21 (work in progress),
	August 2012.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet		[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
	Networks", RFC 2464, December 1998.		Networks", RFC 2464, December 1998.
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, February 2006.		Architecture", RFC 4291, February 2006.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	skipping to change at page 13, line 40 ¶		skipping to change at page 13, line 34 ¶
	Address Autoconfiguration", RFC 4862, September 2007.		Address Autoconfiguration", RFC 4862, 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.
	[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,
			"Neighbor Discovery Optimization for IPv6 over Low-Power
			Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
			November 2012.
	8.2. Informative References		8.2. Informative References
	[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.
End of changes. 12 change blocks.
	27 lines changed or deleted		26 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/