< draft-ietf-6lo-btle-00.txt		draft-ietf-6lo-btle-01.txt >
	6Lo Working Group J. Nieminen, Ed.		6Lo Working Group J. Nieminen
	Internet-Draft T. Savolainen, Ed.		Internet-Draft T. Savolainen
	Intended status: Standards Track M. Isomaki		Intended status: Standards Track M. Isomaki
	Expires: May 11, 2014 Nokia		Expires: November 3, 2014 Nokia
	B. Patil		B. Patil
	AT&T		AT&T
	Z. Shelby		Z. Shelby
	Sensinode		Arm
	C. Gomez		C. Gomez
	Universitat Politecnica de		Universitat Politecnica de Catalunya/i2CAT
	Catalunya/i2CAT		May 2, 2014
	November 7, 2013
	Transmission of IPv6 Packets over BLUETOOTH Low Energy		Transmission of IPv6 Packets over BLUETOOTH(R) Low Energy
	draft-ietf-6lo-btle-00		draft-ietf-6lo-btle-01
	Abstract		Abstract
	BLUETOOTH Low Energy is a low power air interface technology defined		Bluetooth Smart is the brand name for the low energy feature in the
	by the BLUETOOTH Special Interest Group (BT-SIG). The standard		Bluetooth specification defined by the Bluetooth Special Interest
	BLUETOOTH radio has been widely implemented and available in mobile		Group. The standard Bluetooth radio has been widely implemented and
	phones, notebook computers, audio headsets and many other devices.		available in mobile phones, notebook computers, audio headsets and
	The low power version of BLUETOOTH is a new specification that		many other devices. The low power version of Bluetooth is a
	enables the use of this air interface with devices such as sensors,		specification that enables the use of this air interface with devices
	smart meters, appliances, etc. The low power variant of BLUETOOTH is		such as sensors, smart meters, appliances, etc. The low power
	currently specified in the revision 4.0 of the BLUETOOTH		variant of Bluetooth is standardized since the revision 4.0 of the
	specifications (BLUETOOTH 4.0). This document describes how IPv6 is		Bluetooth specifications, although version 4.1 or newer is required
	transported over BLUETOOTH Low Energy using 6LoWPAN techniques.		for IPv6. This document describes how IPv6 is transported over
			Bluetooth Low Energy using 6LoWPAN techniques.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 May 11, 2014.		This Internet-Draft will expire on November 3, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the
			Copyright (c) 2014 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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology and Requirements Language . . . . . . . . . . 3		1.1. Terminology and Requirements Language . . . . . . . . . . 3
	2. BLUETOOTH Low Energy . . . . . . . . . . . . . . . . . . . . . 3		2. Bluetooth Low Energy . . . . . . . . . . . . . . . . . . . . 3
	2.1. BLUETOOTH Low Energy stack . . . . . . . . . . . . . . . . 4		2.1. Bluetooth Low Energy stack . . . . . . . . . . . . . . . 4
	2.2. Link layer roles and topology . . . . . . . . . . . . . . 4		2.2. Link layer roles and topology . . . . . . . . . . . . . . 4
	2.3. BT-LE device addressing . . . . . . . . . . . . . . . . . 5		2.3. Bluetooth LE device addressing . . . . . . . . . . . . . 5
	2.4. BT-LE packets sizes and MTU . . . . . . . . . . . . . . . 5		2.4. Bluetooth LE packets sizes and MTU . . . . . . . . . . . 5
	3. Specification of IPv6 over BLUETOOTH Low Energy . . . . . . . 6		3. Specification of IPv6 over Bluetooth Low Energy . . . . . . . 6
	3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Link model . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2.1. Stateless address autoconfiguration . . . . . . . . . 8		3.2.1. Stateless address autoconfiguration . . . . . . . . . 8
	3.2.2. Neighbor discovery . . . . . . . . . . . . . . . . . . 9		3.2.2. Neighbor discovery . . . . . . . . . . . . . . . . . 8
	3.2.3. Header compression . . . . . . . . . . . . . . . . . . 9		3.2.3. Header compression . . . . . . . . . . . . . . . . . 9
	3.2.4. Unicast and Multicast address mapping . . . . . . . . 10		3.2.3.1. Remote destination example . . . . . . . . . . . 10
	3.3. Internet connectivity scenarios . . . . . . . . . . . . . 11		3.2.4. Unicast and Multicast address mapping . . . . . . . . 11
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		3.3. Internet connectivity scenarios . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	6. Additional contributors . . . . . . . . . . . . . . . . . . . 12		5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		6. Additional contributors . . . . . . . . . . . . . . . . . . . 13
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . . 13		8.1. Normative References . . . . . . . . . . . . . . . . . . 13
	Appendix A. BLUETOOTH Low Energy fragmentation and L2CAP Modes . 14		8.2. Informative References . . . . . . . . . . . . . . . . . 14
	Appendix B. BLUETOOTH Low Energy L2CAP Channel ID Usage for		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	6LoWPAN/IPv6 . . . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	BLUETOOTH Low Energy (BT-LE) is a radio technology targeted for		Bluetooth low energy (LE) is a radio technology targeted for devices
	devices that operate with coin cell batteries or minimalistic power		that operate with coin cell batteries or minimalistic power sources,
	sources, which means that low power consumption is essential. BT-LE		which means that low power consumption is essential. Bluetooth LE is
	is an especially attractive technology for Internet of Things		an especially attractive technology for Internet of Things
	applications, such as health monitors, environmental sensing,		applications, such as health monitors, environmental sensing,
	proximity applications and many others.		proximity applications and many others.
	Considering the potential for the exponential growth in the number of		Considering the potential for the exponential growth in the number of
	sensors and Internet connected devices and things, IPv6 is an ideal		sensors and Internet connected devices and things, IPv6 is an ideal
	protocol due to the large address space it provides. In addition,		protocol due to the large address space it provides. In addition,
	IPv6 provides tools for stateless address autoconfiguration, which is		IPv6 provides tools for stateless address autoconfiguration, which is
	particularly suitable for sensor network applications and nodes which		particularly suitable for sensor network applications and nodes which
	have very limited processing power or lack a full-fledged operating		have very limited processing power or lack a full-fledged operating
	system.		system.
	RFC 4944 [RFC4944] specifies the transmission of IPv6 over IEEE		RFC 4944 [RFC4944] specifies the transmission of IPv6 over IEEE
	802.15.4. The BT-LE link in many respects has similar		802.15.4. The Bluetooth LE link in many respects has similar
	characteristics to that of IEEE 802.15.4. Many of the mechanisms		characteristics to that of IEEE 802.15.4. Many of the mechanisms
	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		Bluetooth LE links. This document specifies the details of IPv6
	transmission over BT-LE links.		transmission over Bluetooth 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 [RFC6775], with an		The terms 6LN, 6LR and 6LBR are defined as in [RFC6775], with an
	addition that BT-LE master and BT-LE slave can both be either 6LN or		addition that Bluetooth LE central and Bluetooth LE peripheral can
	6LBR.		both be either 6LN or 6LBR.
	2. BLUETOOTH Low Energy		2. Bluetooth Low Energy
	BT-LE is designed for transferring small amounts of data infrequently		Bluetooth LE is designed for transferring small amounts of data
	at modest data rates at a very low cost per bit. BLUETOOTH Special		infrequently at modest data rates at a very low cost per bit.
	Interest Group has introduced two trademarks, BLUETOOTH Smart for		Bluetooth Special Interest Group (Bluetooth SIG) has introduced two
	single-mode devices (a device that only supports BT-LE) and BLUETOOTH		trademarks, Bluetooth Smart for single-mode devices (a device that
	Smart Ready for dual-mode devices. In the rest of the draft, the		only supports Bluetooth LE) and Bluetooth Smart Ready for dual-mode
	term BT-LE refers to both types of devices.		devices. In the rest of the document, the term Bluetooth LE refers
			to both types of devices.
			Bluetooth LE was introduced in Bluetooth 4.0 and further enhanced in
			Bluetooth 4.1 [BTCorev4.1]. Bluetooth SIG will also publish Internet
			Protocol Support Profile (IPSP) [IPSP], which includes Internet
			Protocol Support Service (IPSS) and that enables discovery of IP-
			enabled devices and establishment of link-layer connection for
			transporting IPv6 packets. IPv6 over Bluetooth LE is dependent on
			both Bluetooth 4.1 and IPSP.
	BT-LE is an integral part of the BT 4.0 specification [BTCorev4.0].
	Devices such as mobile phones, notebooks, tablets and other handheld		Devices such as mobile phones, notebooks, tablets and other handheld
	computing devices which include BT 4.0 chipsets also have the low-		computing devices which will include Bluetooth 4.1 chipsets will also
	energy functionality of BLUETOOTH. BT-LE is also included in many		have the low-energy functionality of Bluetooth. Bluetooth LE will
	different types of accessories that collaborate with mobile devices		also be included in many different types of accessories that
	such as phones, tablets and notebook computers. An example of a use		collaborate with mobile devices such as phones, tablets and notebook
	case for a BT-LE accessory is a heart rate monitor that sends data		computers. An example of a use case for a Bluetooth LE accessory is
	via the mobile phone to a server on the Internet.		a heart rate monitor that sends data via the mobile phone to a server
			on the Internet.
	2.1. BLUETOOTH Low Energy stack		2.1. Bluetooth Low Energy stack
	The lower layer of the BT-LE stack consists of the Physical (PHY) and		The lower layer of the Bluetooth LE stack consists of the Physical
	the Link Layer (LL). The Physical Layer transmits and receives the		(PHY) and the Link Layer (LL). The Physical Layer transmits and
	actual packets. The Link Layer is responsible for providing medium		receives the actual packets. The Link Layer is responsible for
	access, connection establishment, error control and flow control.		providing medium access, connection establishment, error control and
	The upper layer consists of the Logical Link Control and Adaptation		flow control. The upper layer consists of the Logical Link Control
	Protocol (L2CAP), Generic Attribute protocol (GATT) and Generic		and Adaptation Protocol (L2CAP), Attribute Protocol (ATT), Generic
	Access Profile (GAP) as shown in Figure 1. GATT and BT-LE profiles		Attribute Profile (GATT) and Generic Access Profile (GAP) as shown in
	together enable the creation of applications in a standardized way		Figure 1. The device internal Host Controller Interface (HCI)
	without using IP. L2CAP provides multiplexing capability by		separates the lower layers, often implemented in the Bluetooth
	multiplexing the data channels from the above layers. L2CAP also		controller, from higher layers, often implemented in the host stack.
	provides fragmentation and reassembly for large data packets.		GATT and Bluetooth LE profiles together enable the creation of
			applications in a standardized way without using IP. L2CAP provides
			multiplexing capability by multiplexing the data channels from the
			above layers. L2CAP also provides fragmentation and reassembly for
			large data packets.
	+----------------------------------------+------------------+		+-------------------------------------------------+
	| Applications |		| Applications |
	+----------------------------------------+------------------+		+---------------------------------------+---------+
	| Generic Attribute Profile | Generic Access |		| Generic Attribute Profile | Generic |
	+----------------------------------------+ Profile |		+--------------------+------------------+ Access |
	| Attribute Protocol |Security Manager | |		| Attribute Protocol | Security Manager | Profile |
	+--------------------+-------------------+------------------+		+--------------------+------------------+---------+
	| Logical Link Control and Adaptation |		| Logical Link Control and Adaptation Protocol |
	+--------------------+-------------------+------------------+		- - -+-----------------------+-------------------------+- - - HCI
	| Host Controller Interface |		| Link Layer | Direct Test Mode |
	+--------------------+-------------------+------------------+		+-------------------------------------------------+
	| Link Layer | Direct Test Mode |		| Physical Layer |
	+--------------------+-------------------+------------------+		+-------------------------------------------------+
	| Physical Layer |
	+--------------------+-------------------+------------------+
	Figure 1: BT-LE Protocol Stack		Figure 1: Bluetooth LE Protocol Stack
	2.2. Link layer roles and topology		2.2. Link layer roles and topology
	BT-LE defines two Link Layer roles: the BT-LE master role and the		Bluetooth LE defines two Link Layer roles: the Bluetooth LE central
	BT-LE slave role. A device in the master role, which is called		role and the Bluetooth LE peripheral role. A device in the central
	master from now on, can manage multiple simultaneous connections with		role, which is called central from now on, has traditionally been
	a number of devices in the slave role, called slaves from now on. A		able to manage multiple simultaneous connections with a number of
	slave can only be connected to a single master. Hence, a BT-LE		devices in the peripheral role, called peripherals from now on. A
	network (i.e. a BT-LE piconet) follows a star topology shown in the		peripheral is commonly connected to a single central, but since
	Figure 2. This specification primarily addresses the situation where		Bluetooth 4.1 can also connect to multiple centrals. In this
	the slave is a 6LN but not a 6LBR at the IPv6 level.		document for IPv6 networking purposes the Bluetooth LE network (i.e.
			a Bluetooth LE piconet) follows a star topology shown in the
	[BT-LE slave]-----\ /-----[BT-LE slave]		Figure 2, where the router typically implements the Bluetooth LE
	\ /		central role and nodes Bluetooth LE peripheral roles. In the future
	[BT-LE slave]-----+[BT-LE Master]+-----[BT-LE slave]		mesh networking may be defined for IPv6 over Bluetooth LE.
	/ \
	[BT-LE slave]-----/ \-----[BT-LE slave]
	Figure 2: BT-LE Star Topology		Node --. .-- Node
			\ /
			Node ---- Router ---- Node
			/ \
			Node --' '-- Node
	A master is assumed to be less constrained than a slave. Hence, in		Figure 2: Bluetooth LE Star Topology
	the primary scenario master and slave will act as 6LoWPAN Border
	Router (6LBR) and a 6LoWPAN Node (6LN), respectively.
	In BT-LE, communication only takes place between a master and a		In Bluetooth LE a central is assumed to be less constrained than a
	slave. Hence, in a BT-LE network using IPv6, a radio hop is		peripheral. Hence, in the primary deployment scenario central and
	equivalent to an IPv6 link and vice versa.		peripheral will act as 6LoWPAN Border Router (6LBR) and a 6LoWPAN
			Node (6LN), respectively.
	2.3. BT-LE device addressing		In Bluetooth LE, direct communication only takes place between a
			central and a peripheral. Hence, in a Bluetooth LE network using
			IPv6, a radio hop is equivalent to an IPv6 link and vice versa.
	Every BT-LE device is identified by a 48-bit device address. The		2.3. Bluetooth LE device addressing
	BLUETOOTH specification describes the device address of a BTLE device
	as:"Devices are identified using a device address. Device addresses
	may be either a public device address or a random device address."
	[BTCorev4.0]. The public device addresses are based on the IEEE 802-
	2001 standard [IEEE802-2001]. The random device addresses are
	generated as defined in the BLUETOOTH specification. The device
	addresses are always unique within a BT-LE piconet, but the random
	addresses are not guaranteed to be globally unique.
	2.4. BT-LE packets sizes and MTU		Every Bluetooth LE device is identified by a 48-bit device address.
			The Bluetooth specification describes the device address of a
			Bluetooth LE device as:"Devices are identified using a device
			address. Device addresses may be either a public device address or a
			random device address." [BTCorev4.1]. The public device addresses
			are based on the IEEE 802-2001 standard [IEEE802-2001]. The random
			device addresses are generated as defined in the Bluetooth
			specification. The device addresses are always unique within a
			Bluetooth LE piconet, but the random addresses are not guaranteed to
			be globally unique.
	Maximum size of the payload in the BT-LE data channel PDU is 27		2.4. Bluetooth LE packets sizes and MTU
	bytes. Depending on the L2CAP mode in use, the amount of data
	available for transporting bytes in the single BT-LE data channel PDU
	ranges between 19 and 27 octets. For power efficient communication
	between two BT-LE nodes, data and its header should fit in a single
	BT-LE data channel PDU. However, IPv6 requires support for an MTU of
	1280 bytes. An inherent function of the BT-LE L2CAP layer, called
	Fragmentation and Recombination (FAR), can assist in transferring
	IPv6 packets that do not fit in a single BT-LE data channel PDU.
	The maximum IPv6 datagram size that can be transported by L2CAP		Optimal MTU defined for L2CAP fixed channels over Bluetooth LE is 27
	depends on the L2CAP mode. The Basic L2CAP Mode allows a maximum		bytes including the L2CAP header of four bytes. Default MTU for
	payload size (i.e. IPv6 datagram size) of 65535 bytes per L2CAP PDU.		Bluetooth LE is hence defined to be 27 bytes. Therefore, excluding
			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
			packets of 1280 bytes or larger, link layer fragmentation and
			reassembly solution is provided by the L2CAP layer. The IPSP defines
			means for negotiating up a link-layer connection that provides MTU of
			1280 bytes or higher for the IPv6 layer [IPSP].
	The rest of the L2CAP modes allow a maximum payload size that ranges		3. Specification of IPv6 over Bluetooth Low Energy
	between 65527 and 65533 bytes per L2CAP PDU. Appendix A describes
	FAR operation and five L2CAP Modes.
	3. Specification of IPv6 over BLUETOOTH Low Energy		Before any IP-layer communications can take place over Bluetooth LE,
			Bluetooth LE enabled nodes such as 6LNs and 6LBRs have to find each
			other and establish a suitable link-layer connection. The discovery
			and Bluetooth LE connection setup procedures are documented by
			Bluetooth SIG in the IPSP specification [IPSP], and hence are out of
			scope of this document. The IPSP depends on Bluetooth version 4.1,
			and hence both Bluetooth version 4.1 or newer and IPSP are required
			for IPv6 communications.
	BT-LE technology sets strict requirements for low power consumption		Bluetooth LE technology sets strict requirements for low power
	and thus limits the allowed protocol overhead. 6LoWPAN standards		consumption and thus limits the allowed protocol overhead. 6LoWPAN
	[RFC4944], [RFC6775], and [RFC6282] provide useful functionality for		standards [RFC6775], and [RFC6282] provide useful functionality for
	reducing overhead which can be applied to BT-LE. This functionality		reducing overhead which can be applied to Bluetooth LE. This
	comprises of link-local IPv6 addresses and stateless IPv6 address		functionality comprises of link-local IPv6 addresses and stateless
	autoconfiguration (see Section 3.2.1), Neighbor Discovery (see		IPv6 address autoconfiguration (see Section 3.2.1), Neighbor
	Section 3.2.2) and header compression (see Section 3.2.3).		Discovery (see Section 3.2.2) and header compression (see
			Section 3.2.3).
	A significant difference between IEEE 802.15.4 and BT-LE is that the		A significant difference between IEEE 802.15.4 and Bluetooth LE is
	former supports both star and mesh topology (and requires a routing		that the former supports both star and mesh topology (and requires a
	protocol), whereas BT-LE does not currently support the formation of		routing protocol), whereas Bluetooth LE does not currently support
	multihop networks at the link layer. In consequence, the mesh header		the formation of multihop networks at the link layer.
	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
	6LoWPAN Router (6LR).
	3.1. Protocol stack		3.1. Protocol stack
	In order to enable transmission of IPv6 packets over BT-LE, a new		Figure 3 illustrates IPv6 over Bluetooth LE stack including the
	fixed L2CAP Channel Identifier (Channel ID) is to be reserved for		Internet Protocol Support Service. UDP and TCP are provided as
	IPv6 traffic by the BT-SIG. Until the Channel ID is reserved,		examples of transport protocols, but the stack can be used by any
	prototype implementations can be implemented as is described in the		other upper layer protocol capable of running atop of IPv6. The
	Appendix B.		6LoWPAN runs on top of Bluetooth LE L2CAP layer.
	Figure 3 illustrates IPv6 over BT-LE stack. UDP and TCP are provided
	as examples of transport protocols, but the stack can be used by any
	other upper layer protocol capable of running atop of IPv6.
	+----------------------------+		+---------+ +----------------------------+
	| UDP/TCP/other |		| IPSS | | UDP/TCP/other |
	+----------------------------+		+---------+ +----------------------------+
	| IPv6 |		| GATT | | IPv6 |
	+----------------------------+		+---------+ +----------------------------+
	| 6LoWPAN adapted to BT-LE |		| ATT | | 6LoWPAN adapted to LE |
	+----------------------------+		+---------+--+----------------------------+
	| BT-LE L2CAP |		| Bluetooth LE L2CAP |
	+----------------------------+		- - +-----------------------------------------+- - - HCI
	| BT-LE Link Layer |		| Bluetooth LE Link Layer |
	+----------------------------+		+-----------------------------------------+
	| BT-LE Physical |		| Bluetooth LE Physical |
	+----------------------------+		+-----------------------------------------+
	Figure 3: IPv6 over BT-LE Stack		Figure 3: IPv6 over Bluetooth LE Stack
	3.2. Link model		3.2. Link model
	The concept of IPv6 link (layer 3) and the physical link (combination		The concept of IPv6 link (layer 3) and the physical link (combination
	of PHY and MAC) needs to be clear and the relationship has to be well		of PHY and MAC) needs to be clear and the relationship has to be well
	understood in order to specify the addressing scheme for transmitting		understood in order to specify the addressing scheme for transmitting
	IPv6 packets over the BT-LE link. RFC 4861 [RFC4861] defines a link		IPv6 packets over the Bluetooth LE link. RFC 4861 [RFC4861] defines
	as "a communication facility or medium over which nodes can		a link as "a communication facility or medium over which nodes can
	communicate at the link layer, i.e., the layer immediately below		communicate at the link layer, i.e., the layer immediately below
	IPv6."		IPv6."
	In the case of BT-LE, L2CAP is an adaptation layer that supports the		In the case of Bluetooth LE, 6LoWPAN layer is adapted to support
	transmission of IPv6 packets. L2CAP also provides multiplexing		transmission of IPv6 packets over Bluetooth LE. The IPSP defines all
	capability in addition to FAR functionality. This specification		steps required for setting up the Bluetooth LE connection over which
	requires that FAR functionality MUST be provided in the L2CAP layer.		6LoWPAN can function [IPSP], including handling the link-layer
	The L2CAP channel characteristics for the transmission of IPv6		fragmentation required on Bluetooth LE, as described in Section 2.4.
	packets on top of BT-LE are the following:
	MTU: Equal to or greater than 1280 bytes
	Flush Timeout: 0xFFFF (Infinite)
	QoS: Best Effort
	Mode: Basic Mode
	Since FAR in BT-LE is a function of the L2CAP layer, fragmentation		This specification also assumes the IPv6 header compression format
	functionality as defined in RFC 4944 [RFC4944] MUST NOT be used in		specified in RFC 6282 is used [RFC6282]. It is also assumed that the
	BT-LE networks. This specification also assumes the IPv6 header		IPv6 payload length can be inferred from the L2CAP header length and
	compression format specified in RFC 6282 [RFC6282]. It is also		the IID value inferred from the link-layer address with help of
	assumed that the IPv6 payload length can be inferred from the L2CAP		Neighbor Cache, if elided from compressed packet.
	header length and the IID value inferred, with help of Neighbor
	Cache, from the link-layer address.
	The BT-LE link between two communicating nodes can be considered to		The Bluetooth LE link between two communicating nodes can be
	be a point-to-point or point-to-multipoint link. When one of the		considered to be a point-to-point or point-to-multipoint link. When
	communicating nodes is in the role of a master, then the link can be		one of the communicating nodes is simultaneously connected to
	viewed as a point-to-multipoint link from the master point of view.		multiple nodes, the link can be viewed as a point-to-multipoint link
	However, due to BT-LE star topology, each branch of the star is		from the particular node point of view. However, due to Bluetooth LE
	considered to be an individual link and thus the slaves cannot		star topology, each branch of the star is considered to be an
	directly hear each other and also cannot talk to each other with		individual link and thus only two nodes can directly talk to each
	link-local addresses. The master ensures address collisions do not		other. Node-to-node communications, e.g. using link-local addresses,
	occur (see Section 3.2.2).		need to be bridged by the 6LBR. The 6LBR ensures address collisions
			do not occur (see Section 3.2.2).
	After the slave and master have connected at the BT-LE level, the		After the peripheral and central have connected at the Bluetooth LE
	link can be considered up and IPv6 address configuration and		level, the link can be considered up and IPv6 address configuration
	transmission can begin.		and transmission can begin.
	3.2.1. Stateless address autoconfiguration		3.2.1. Stateless address autoconfiguration
	A BT-LE 6LN performs stateless address autoconfiguration as per RFC		A Bluetooth LE 6LN performs stateless address autoconfiguration as
	4862 [RFC4862]. A 64-bit Interface identifier (IID) for a BT-LE		per RFC 4862 [RFC4862]. A 64-bit Interface identifier (IID) for a
	interface MAY be formed by utilizing the 48-bit BLUETOOTH device		Bluetooth LE interface MAY be formed by utilizing the 48-bit
	address (see Section 2.3) as defined in RFC 2464 "IPv6 over Ethernet"		Bluetooth device address (see Section 2.3) as defined in RFC 2464
	specification [RFC2464]. Alternatively, a randomly generated IID		"IPv6 over Ethernet" specification [RFC2464]. Alternatively, a
	(see Section 3.2.2), MAY be used instead. In the case of randomly		randomly generated IID (see Section 3.2.2) can be used instead, for
	generated IID or randomly generated BLUETOOTH device address, the		example, as discussed in [I-D.ietf-6man-default-iids]. In the case
	"Universal/Local" bit MUST be set to 0 [RFC4291]. Only if the		of randomly generated IID or randomly generated Bluetooth device
	BLUETOOTH device address is known to be a public address the		address, the "Universal/Local" bit MUST be set to 0 [RFC4291]. Only
			if the Bluetooth device address is known to be a public address the
	"Universal/Local" bit can be set to 1.		"Universal/Local" bit can be set to 1.
	As defined in RFC 4291 [RFC4291], the IPv6 link-local address for a		As defined in RFC 4291 [RFC4291], the IPv6 link-local address for a
	BT-LE node is formed by appending the IID, to the prefix FE80::/64,		Bluetooth LE node is formed by appending the IID, to the prefix
	as depicted in Figure 4.		FE80::/64, as depicted in Figure 4.
	10 bits 54 bits 64 bits		10 bits 54 bits 64 bits
	+----------+-----------------+----------------------+		+----------+-----------------+----------------------+
	|1111111010| zeros | Interface Identifier |		|1111111010| zeros | Interface Identifier |
	+----------+-----------------+----------------------+		+----------+-----------------+----------------------+
	Figure 4: IPv6 link-local address in BT-LE		Figure 4: IPv6 link-local address in Bluetooth LE
	The tool for a 6LBR to obtain an IPv6 prefix for numbering the BT-LE		The tool for a 6LBR to obtain an IPv6 prefix for numbering the
	network is out of scope of this document, but can be, for example,		Bluetooth LE network is out of scope of this document, but can be,
	accomplished via DHCPv6 Prefix Delegation [RFC3633] or by using		for example, accomplished via DHCPv6 Prefix Delegation [RFC3633] or
	Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to the link		by using Unique Local IPv6 Unicast Addresses (ULA) [RFC4193]. Due to
	model of the BT-LE (see Section 2.2) the 6LBR MUST set the "on-link"		the link model of the Bluetooth LE (see Section 2.2) the 6LBR MUST
	flag (L) to zero in the Prefix Information Option [RFC4861]. This		set the "on-link" flag (L) to zero in the Prefix Information Option
	will cause 6LNs to always send packets to the 6LBR, including the		[RFC4861]. This will cause 6LNs to always send packets to the 6LBR,
	case when the destination is another 6LN using the same prefix.		including the 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 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. BT-LE does not support mesh networks		including the mesh topology. Bluetooth LE does not support mesh
	and hence only those aspects that apply to a star topology are		networks and hence only those aspects that apply to a star topology
	considered.		are considered.
	The following aspects of the Neighbor Discovery optimizations		The following aspects of the Neighbor Discovery optimizations
	[RFC6775] are applicable to BT-LE 6LNs:		[RFC6775] are applicable to Bluetooth LE 6LNs:
	1. A BT-LE 6LN MUST register its address with the 6LBR by sending a		1. A Bluetooth LE 6LN MUST register its addresses with the 6LBR by
	Neighbor Solicitation (NS) message with the ARO option and process		sending a Neighbor Solicitation (NS) message with the Address
	the Neighbor Advertisement (NA) accordingly. The NS with the ARO		Registration Option (ARO) and process the Neighbor Advertisement (NA)
	option SHOULD be sent irrespective of whether the IID is derived from		accordingly. The NS with the ARO option SHOULD be sent irrespective
	the unique 48 bit BT-LE device address or the IID is a random value		of the method used to generate the IID. The 6LN MUST register only
	that is generated as per the privacy extensions for stateless address		one IPv6 address per IPv6 prefix available on a link.
	autoconfiguration [RFC4941]. Although RFC 4941 [RFC4941] permits the
	use of deprecated addresses for old connections, in this
	specification we mandate that one interface MUST NOT use more than
	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 Bluetooth LE 6LNs MUST, respectively, follow
	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
	top of BT-LE. All headers MUST be compressed according to RFC 6282		top of Bluetooth LE. All headers MUST be compressed according to RFC
	[RFC6282] encoding formats. The BT-LE's star topology structure can		6282 [RFC6282] encoding formats.
	be exploited in order to provide a mechanism for IID compression.
	The following text describes the principles of IPv6 address
	compression on top of BT-LE.
	In a link-local communication, both the IPv6 source and destination		The Bluetooth LE's star topology structure and ARO can be exploited
	addresses MUST be elided [RFC6282], since the node knows that the		in order to provide a mechanism for IID compression. The following
	packet is destined for it even if the packet does not have		text describes the principles of IPv6 address compression on top of
	destination IPv6 address. On the other hand, a node SHALL learn the		Bluetooth LE.
	IID of the other endpoint of each L2CAP connection it participates
	in. By exploiting this information, a node that receives a data		The ARO option requires use of EUI-64 identifier [RFC6775]. In the
	channel PDU containing an IPv6 packet (or a part of it) can infer the		case of Bluetooth LE, the field SHALL be filled with the 48-bit
	corresponding IPv6 source address. A node MUST maintain a Neighbor		device address used by the Bluetooth LE node converted into 64-bit
	Cache, in which the entries include both the IID of the neighbor and		Modified EUI-64 format [RFC4291].
	the Device Address that identifies the neighbor. For the type of
	communication considered in this paragraph, the following settings		When a 6LN is sending a packet to or through a 6LBR, it MUST fully
	MUST be used in the IPv6 compressed header: CID=0, SAC=0, SAM=11,		elide the source address if the source IPv6 address is currently
	DAC=0, DAM=11.		registed with ARO to the 6LBR and the 6LN has registered only one
			address for the indicated prefix. That is, if SAC=0 and SAM=11 the
			6LN MUST have registered the source link-local IPv6 address it is
			using using ARO, and if SAC=1 and SAM=11 the 6LN MUST have registered
			the source IPv6 address with the prefix related to compression
			context identified with Context Identifier Extension. The
			destination IPv6 address MUST be fully elided if the destination
			address is the same address to which the 6LN has succesfully
			registered its source IPv6 address with ARO (set DAC=0, DAM=11). The
			destination IPv6 address MUST be fully or partially elided if the
			destination address has prefix for which context has been set up, for
			example, DAC=0 and DAM=01 when destination is link-local, and DAC=1
			and DAM=01 with Context Identifier Extension if compression context
			has been configured for the used destination.
			When a 6LBR is transmitting packets to 6LN, it MUST fully elide the
			source IID if the source IPv6 address is the one 6LN has used to
			register its address with ARO (set SAC=0, SAM=11), and it MUST elide
			the source prefix or address if a compression context related to the
			IPv6 source address has been set up. The 6LBR also MUST elide the
			destination IPv6 address if it is currently registered by the 6LN
			with ARO and thus 6LN can determine it based on indication of link-
			local prefix (DAC=0) or indication of other prefix (DAC=1 with
			Context Identifier Extension).
			3.2.3.1. Remote destination example
	When a 6LN transmits an IPv6 packet to a remote destination using		When a 6LN transmits an IPv6 packet to a remote destination using
	global Unicast IPv6 addresses, if a context is defined for the prefix		global Unicast IPv6 addresses, if a context is defined for the prefix
	of the 6LNs global IPv6 address, the 6LN MUST indicate this context		of the 6LNs global IPv6 address, the 6LN has to indicate this context
	in the corresponding source fields of the compressed IPv6 header as		in the corresponding source fields of the compressed IPv6 header as
	per Section 3.1 of RFC 6282 [RFC6282], and MUST elide the IPv6 source		per Section 3.1 of RFC 6282 [RFC6282], and has to elide the IPv6
	address. For this, the 6LN MUST use the following settings in the		source address previously registered with ARO. For this, the 6LN
	IPv6 compressed header: CID=1, SAC=1, SAM=11. In this case, the 6LBR		MUST use the following settings in the IPv6 compressed header: CID=1,
	can infer the elided IPv6 source address since 1) the 6LBR has		SAC=1, SAM=11. In this case, the 6LBR can infer the elided IPv6
	previously assigned the prefix to the 6LNs; and 2) the 6LBR maintains		source address since 1) the 6LBR has previously assigned the prefix
	a Neighbor Cache that relates the Device Address and the IID of the		to the 6LNs; and 2) the 6LBR maintains a Neighbor Cache that relates
	corresponding slave. If a context is defined for the IPv6		the Device Address and the IID the device has registered with ARO.
	destination address, the 6LN MUST also indicate this context in the		If a context is defined for the IPv6 destination address, the 6LN has
	corresponding destination fields of the compressed IPv6 header, and		to also indicate this context in the corresponding destination fields
	MUST elide the prefix of the destination IPv6 address. For this, the		of the compressed IPv6 header, and elide the prefix of the
	6LN MUST set the DAM field of the compressed IPv6 header as DAM=01		destination IPv6 address. For this, the 6LN MUST set the DAM field
	(if the context covers a 64-bit prefix) or as DAM=11 (if the context		of the compressed IPv6 header as DAM=01 (if the context covers a
	covers a full, 128-bit address). CID and DAC MUST be set to CID=1		64-bit prefix) or as DAM=11 (if the context covers a full, 128-bit
	and DAC=1. Note that when a context is defined for the IPv6		address). CID and DAC MUST be set to CID=1 and DAC=1. Note that
	destination address, the 6LBR can infer the elided destination prefix		when a context is defined for the IPv6 destination address, the 6LBR
	by using the context.		can infer the elided destination prefix by using the context.
	When a 6LBR receives an IPv6 packet sent by a remote node outside the		When a 6LBR receives an IPv6 packet sent by a remote node outside the
	BT-LE network, and the destination of the packet is a 6LN, if a		Bluetooth LE network, and the destination of the packet is a 6LN, if
	context is defined for the prefix of the 6LN's global IPv6 address,		a context is defined for the prefix of the 6LN's global IPv6 address,
	the 6LBR MUST indicate this context in the corresponding destination		the 6LBR has to indicate this context in the corresponding
	fields of the compressed IPv6 header, and MUST elide the IPv6		destination fields of the compressed IPv6 header. The 6LBR has to
	destination address of the packet before forwarding it to the 6LN.		elide the IPv6 destination address of the packet before forwarding
	For this, the 6LBR MUST set the DAM field of the IPv6 compressed		it, if the IPv6 destination address is inferable by the 6LN. For
	header as DAM=11. CID and DAC MUST be set to CID=1 and DAC=1. If a		this, the 6LBR will set the DAM field of the IPv6 compressed header
			as DAM=11. CID and DAC needs to be set to CID=1 and DAC=1. If a
	context is defined for the prefix of the IPv6 source address, the		context is defined for the prefix of the IPv6 source address, the
	6LBR MUST indicate this context in the source fields of the		6LBR needs to indicate this context in the source fields of the
	compressed IPv6 header, and MUST elide that prefix as well. For		compressed IPv6 header, and elide that prefix as well. For this, the
	this, the 6LBR MUST set the SAM field of the IPv6 compressed header		6LBR needs to set the SAM field of the IPv6 compressed header as
	as SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the		SAM=01 (if the context covers a 64-bit prefix) or SAM=11 (if the
	context covers a full, 128-bit address). CID and SAC MUST be set to		context covers a full, 128-bit address). CID and SAC are to be set
	CID=1 and SAC=1.		to CID=1 and SAC=1.
	3.2.4. Unicast and Multicast address mapping		3.2.4. Unicast and Multicast address mapping
	The BT-LE link layer does not support multicast. Hence traffic is		The Bluetooth LE link layer does not support multicast. Hence
	always unicast between two BT-LE nodes. Even in the case where a		traffic is always unicast between two Bluetooth LE nodes. Even in
	master is attached to multiple slaves, the master cannot do a		the case where a 6LBR is attached to multiple 6LNs, the 6LBR cannot
	multicast to all the connected slaves. If the master needs to send a		do a multicast to all the connected 6LNs. If the 6LBR needs to send
	multicast packet to all its slaves, it has to replicate the packet		a multicast packet to all its 6LNs, it has to replicate the packet
	and unicast it on each link. However, this may not be energy-		and unicast it on each link. However, this may not be energy-
	efficient and particular care must be taken if the master is battery-		efficient and particular care must be taken if the master is battery-
	powered. In the opposite direction, a slave can only transmit data		powered. In the opposite direction, a 6LN can only transmit data to
	to a single destination (i.e. the master). Hence, when a slave needs		a single destination (i.e. the 6LBR). Hence, when a 6LN needs to
	to transmit an IPv6 multicast packet, the slave will unicast the		transmit an IPv6 multicast packet, the 6LN will unicast the
	corresponding BT-LE packet to the master. As described in the		corresponding Bluetooth LE packet to the 6LBR. The 6LBR will then
	Section 3.2 the master will not forward link-local multicast messages		forward the multicast packet to other 6LNs. To avoid excess unwanted
	to other slaves connected to the master.		multicast traffic being sent to 6LNs, the 6LBR SHOULD implement MLD
			Snooping feature [RFC4541].
	3.3. Internet connectivity scenarios		3.3. Internet connectivity scenarios
	In a typical scenario, the BT-LE network is connected to the Internet		In a typical scenario, the Bluetooth LE network is connected to the
	as shown in the Figure 5.		Internet as shown in the Figure 5.
	A degenerate scenario can be imagined where a slave is acting as 6LBR
	and providing Internet connectivity for the master. How the master
	could then further provide Internet connectivity to other slaves,
	possibly connected to the master, is out of the scope of this
	document.
	6LN		6LN
	\ ____________		\ ____________
	\ / \		\ / \
	6LN ---- 6LBR --- | Internet |		6LN ---- 6LBR ----- | Internet |
	/ \____________/		/ \____________/
	/		/
	6LN		6LN
	<-- BT-LE -->		<-- Bluetooth LE -->
	Figure 5: BT-LE network connected to the Internet		Figure 5: Bluetooth LE network connected to the Internet
	In some scenarios, the BT-LE network may transiently or permanently		In some scenarios, the Bluetooth LE network may transiently or
	be an isolated network as shown in the Figure 6.		permanently be an isolated network as shown in the Figure 6.
	6LN 6LN		6LN 6LN
	\ /		\ /
	\ /		\ /
	6LN --- 6LBR --- 6LN		6LN --- 6LBR --- 6LN
	/ \		/ \
	/ \		/ \
	6LN 6LN		6LN 6LN
	<------ BT-LE ----->		<--- Bluetooth LE --->
	Figure 6: Isolated BT-LE network
			Figure 6: Isolated Bluetooth LE network
			It is also possible to have point-to-point connection between two
			6LNs, one of which being central and another being peripheral.
			Similarly, it is possible to have point-to-point connections between
			two 6LBRs, one of which being central and another being peripheral.
			At this point in time mesh networking with Bluetooth LE is not
			specified.
	In the isolated network scenario communications between 6LN and 6LBR		In the isolated network scenario communications between 6LN and 6LBR
	can use IPv6 link-local methodology, but for communications between		can use IPv6 link-local methodology, but for communications between
	different slaves, the master has to act as 6LBR, number the network		different 6LNs, the 6LBR has to number the network with ULA prefix
	with ULA prefix [RFC4193], and route packets between slaves.		[RFC4193], and route packets between 6LNs.
	4. IANA Considerations		4. IANA Considerations
	There are no IANA considerations related to this document.		There are no IANA considerations related to this document.
	5. Security Considerations		5. Security Considerations
	The transmission of IPv6 over BT-LE links has similar requirements		The transmission of IPv6 over Bluetooth LE links has similar
	and concerns for security as for IEEE 802.15.4. IPv6 over BT-LE		requirements and concerns for security as for IEEE 802.15.4.
	SHOULD be protected by using BT-LE Link Layer security.		Bluetooth LE Link Layer security considerations are covered by the
			IPSP [IPSP].
	BT-LE Link Layer supports encryption and authentication by using the		Bluetooth LE Link Layer supports encryption and authentication by
	Counter with CBC-MAC (CCM) mechanism [RFC3610] and a 128-bit AES		using the Counter with CBC-MAC (CCM) mechanism [RFC3610] and a
	block cipher. Upper layer security mechanisms may exploit this		128-bit AES block cipher. Upper layer security mechanisms may
	functionality when it is available. (Note: CCM does not consume		exploit this functionality when it is available. (Note: CCM does not
	bytes from the maximum per-packet L2CAP data size, since the link		consume bytes from the maximum per-packet L2CAP data size, since the
	layer data unit has a specific field for them when they are used.)		link layer data unit has a specific field for them when they are
			used.)
	Key management in BT-LE is provided by the Security Manager Protocol		Key management in Bluetooth LE is provided by the Security Manager
	(SMP), as defined in [BTCorev4.0].		Protocol (SMP), as defined in [BTCorev4.1].
	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.
	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.
			Authors would like to give special acknowledgements for Krishna
			Shingala, Frank Berntsen, and Bluetooth SIG's Internet Working Group
			for providing significant feedback and improvement proposals for this
			document.
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[BTCorev4.0]		[BTCorev4.1]
	BLUETOOTH Special Interest Group, "BLUETOOTH Specification		Bluetooth Special Interest Group, "Bluetooth Core
	Version 4.0", June 2010.		Specification Version 4.1", December 2013.
			[IPSP] Bluetooth Special Interest Group, "Bluetooth Internet
			Protocol Support Profile Specification - REFERENCE TO BE
			UPDATED ONCE IPSP IS PUBLISHED", 2014.
	[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.
			[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
			"Considerations for Internet Group Management Protocol
			(IGMP) and Multicast Listener Discovery (MLD) Snooping
			Switches", RFC 4541, May 2006.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless		[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
	Address Autoconfiguration", RFC 4862, September 2007.		Address Autoconfiguration", RFC 4862, September 2007.
	[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	"Transmission of IPv6 Packets over IEEE 802.15.4
	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,		[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.
	8.2. Informative References		8.2. Informative References
			[I-D.ietf-6man-default-iids]
			Gont, F., Cooper, A., Thaler, D., and W. Will,
			"Recommendation on Stable IPv6 Interface Identifiers",
			draft-ietf-6man-default-iids-00 (work in progress),
			January 2014.
	[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
	Host Configuration Protocol (DHCP) version 6", RFC 3633,		Host Configuration Protocol (DHCP) version 6", RFC 3633,
	December 2003.		December 2003.
	[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		[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
	Extensions for Stateless Address Autoconfiguration in		"Transmission of IPv6 Packets over IEEE 802.15.4
	IPv6", RFC 4941, September 2007.		Networks", RFC 4944, September 2007.
	Appendix A. BLUETOOTH Low Energy fragmentation and L2CAP Modes
	This section provides an overview of Fragmentation and Recombination
	(FAR) method and L2CAP modes in BT-LE. FAR is an L2CAP mechanism, in
	which an L2CAP entity can take the (large) upper layer PDU, prepend
	the L2CAP header (4 bytes in the Basic L2CAP mode) and break the
	resulting L2CAP PDU into fragments which can then be directly
	encapsulated into Data channel PDUs. There are bits in the Data
	channel PDUs which identify whether the payload is a complete L2CAP
	PDU or the first of a set of fragments, or one of the rest of the
	fragments.
	There are five L2CAP modes defined in the BT 4.0 spec. These modes
	are: Retransmission Mode (a Go-Back-N mechanism is used), Enhanced
	Retransmission Mode (includes selective NAK among others), Flow
	Control Mode (PDUs are numbered, but there are no retransmissions),
	Streaming Mode (PDUs are numbered, but there are no ACKs of any kind)
	and Basic L2CAP Mode.
	Appendix B. BLUETOOTH Low Energy L2CAP Channel ID Usage for 6LoWPAN/
	IPv6
	The BT-LE Logical Link Control and Adaptation Protocol (L2CAP) uses
	Channel Identifiers (IDs) to distinguish the upper layer protocol
	carried on top of it. Two devices exchanging IPv6/6LoWPAN packets
	need to use a common Channel ID to be able to send and receive the
	packets correctly over L2CAP. It is also important that they avoid
	using Channel ID's that conflict with other L2CAP usages. For the
	initial use of IPv6/6LoWPAN over BT-LE L2CAP, implementers are
	recommended to use Channel ID 0x3E from the BLUETOOTH Special
	Interest Group reserved space (BLUETOOTH 4.0 Logical Link Control and
	Adaptation Protocol Specification -part, table 2.1 [BTCorev4.0]). As
	the IPv6/6LoWPAN use becomes more widely adopted, the BT SIG may
	allocate 0x3E or some other Channel ID exclusively for IPv6/6LoWPAN.
	Any such BT SIG allocation will deprecate the recommendation given in
	this Appendix, and a new RFC will be published at the time of
	allocation that will update this RFC and specify the allocated value.
	The initial implementers are thus recommended to keep their Channel
	ID usage capability flexible to potential future changes.
	Authors' Addresses		Authors' Addresses
	Johanna Nieminen (editor)		Johanna Nieminen
	Nokia		Nokia
	Itaemerenkatu 11-13		Itamerenkatu 11-13
	FI-00180 Helsinki		Helsinki 00180
	Finland		Finland
	Email: johannamaria.nieminen@gmail.com		Email: johannamaria.nieminen@gmail.com
			Teemu Savolainen
	Teemu Savolainen (editor)
	Nokia		Nokia
	Hermiankatu 12 D		Hermiankatu 12 D
	FI-33720 Tampere		Tampere 33720
	Finland		Finland
	Email: teemu.savolainen@nokia.com		Email: teemu.savolainen@nokia.com
	Markus Isomaki		Markus Isomaki
	Nokia		Nokia
	Keilalahdentie 2-4		Keilalahdentie 2-4
	FI-02150 Espoo		Espoo 02150
	Finland		Finland
	Email: markus.isomaki@nokia.com		Email: markus.isomaki@nokia.com
	Basavaraj Patil		Basavaraj Patil
	AT&T		AT&T
	1410 E. Renner Road		1410 E. Renner Road
	Richardson, TX 75082		Richardson, TX 75082
	USA		USA
	Email: basavaraj.patil@att.com		Email: basavaraj.patil@att.com
	Zach Shelby		Zach Shelby
	Sensinode		Arm
	Hallituskatu 13-17D		Hallituskatu 13-17D
	FI-90100 Oulu		Oulu 90100
	Finland		Finland
	Email: zach.shelby@sensinode.com		Email: zach.shelby@arm.com
	Carles Gomez		Carles Gomez
	Universitat Politecnica de Catalunya/i2CAT		Universitat Politecnica de Catalunya/i2CAT
	C/Esteve Terradas, 7		C/Esteve Terradas, 7
	Castelldefels 08860		Castelldefels 08860
	Spain		Spain
	Email: carlesgo@entel.upc.edu		Email: carlesgo@entel.upc.edu
End of changes. 85 change blocks.
	407 lines changed or deleted		412 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/