< draft-gomez-6lo-blemesh-01.txt		draft-gomez-6lo-blemesh-02.txt >
	6Lo Working Group C. Gomez		6Lo Working Group C. Gomez
	Internet-Draft S. Darroudi		Internet-Draft S. Darroudi
	Intended status: Standards Track UPC/i2cat		Intended status: Standards Track UPC/i2cat
	Expires: January 6, 2017 T. Savolainen		Expires: May 4, 2017 T. Savolainen
	Nokia		Nokia
	July 5, 2016		October 31, 2016
	IPv6 over BLUETOOTH(R) Low Energy Mesh Networks		IPv6 Mesh over Bluetooth(R) Low Energy using IPSP
	draft-gomez-6lo-blemesh-01		draft-gomez-6lo-blemesh-02
	Abstract		Abstract
	RFC 7668 describes the adaptation of 6LoWPAN techniques to enable		RFC 7668 describes the adaptation of 6LoWPAN techniques to enable
	IPv6 over Bluetooth low energy networks that follow the star		IPv6 over Bluetooth low energy networks that follow the star
	topology. However, recent Bluetooth specifications allow the		topology. However, recent Bluetooth specifications allow the
	formation of extended topologies as well. This document defines how		formation of extended topologies as well. This document specifies
	IPv6 is transported over Bluetooth low energy mesh networks.		the mechanisms needed to enable IPv6 over mesh networks composed of
			Bluetooth low energy links established by using the Bluetooth
			Internet Protocol Support Profile.
	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 January 6, 2017.		This Internet-Draft will expire on May 4, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology and Requirements Language . . . . . . . . . . 3		1.1. Terminology and Requirements Language . . . . . . . . . . 3
	2. Bluetooth LE Mesh Networks . . . . . . . . . . . . . . . . . 3		2. Bluetooth LE Networks and the IPSP . . . . . . . . . . . . . 3
	3. Specification of IPv6 over Bluetooth LE mesh networks . . . . 3		3. Specification of IPv6 mesh over Bluetooth LE networks . . . . 3
	3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 3		3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 5		3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 5
	3.3.1. Stateless address autoconfiguration . . . . . . . . . 5		3.3.1. Stateless address autoconfiguration . . . . . . . . . 5
	3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 5		3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 5
	3.3.3. Header compression . . . . . . . . . . . . . . . . . 6		3.3.3. Header compression . . . . . . . . . . . . . . . . . 6
	3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 7		3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 7
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	7.1. Normative References . . . . . . . . . . . . . . . . . . 8		7.1. Normative References . . . . . . . . . . . . . . . . . . 9
	7.2. Informative References . . . . . . . . . . . . . . . . . 9		7.2. Informative References . . . . . . . . . . . . . . . . . 9
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	Bluetooth low energy (hereinafter, Bluetooth LE) was first introduced		Bluetooth low energy (hereinafter, Bluetooth LE) was first introduced
	in the Bluetooth 4.0 specification. Bluetooth LE (which has been		in the Bluetooth 4.0 specification. Bluetooth LE (which has been
	marketed as Bluetooth Smart) is a low-power wireless technology		marketed as Bluetooth Smart) is a low-power wireless technology
	designed for short-range control and monitoring applications.		designed for short-range control and monitoring applications.
	Bluetooth LE is currently implemented in a wide range of consumer		Bluetooth LE is currently implemented in a wide range of consumer
	electronics devices, such as smartphones and wearable devices. Given		electronics devices, such as smartphones and wearable devices. Given
	the high potential of this technology for the Internet of Things, the		the high potential of this technology for the Internet of Things, the
	Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have		Bluetooth Special Interest Group (Bluetooth SIG) and the IETF have
	produced specifications in order to enable IPv6 over Bluetooth LE,		produced specifications in order to enable IPv6 over Bluetooth LE,
	such as the Internet Protocol Support Profile (IPSP) [IPSP], and RFC		such as the Internet Protocol Support Profile (IPSP) [IPSP], and RFC
	7668, respectively. Bluetooth 4.0 only supports Bluetooth LE		7668, respectively. Bluetooth 4.0 only supports Bluetooth LE
	networks that follow the star topology. In consequence, RFC 7668 was		networks that follow the star topology. In consequence, RFC 7668 was
	specifically developed and optimized for that type of network		specifically developed and optimized for that type of network
	topology. However, subsequent Bluetooth specifications allow the		topology. However, subsequent Bluetooth specifications allow the
	formation of extended topologies [BTCorev4.1], such as the mesh		formation of extended topologies [BTCorev4.1], such as the mesh
	topology. The functionality described in RFC 7668 is not sufficient		topology. The functionality described in RFC 7668 is not sufficient
	and would fail to enable IPv6 over Bluetooth LE mesh networks. This		and would fail to enable IPv6 over mesh networks composed of
	document specifies the mechanisms needed to enable IPv6 over		Bluetooth LE links. This document specifies the mechanisms needed to
	Bluetooth LE mesh networks. This specification also allows to run		enable IPv6 over mesh networks composed of Bluetooth LE links. This
	IPv6 over Bluetooth LE star topology networks, albeit without all the		specification also allows to run IPv6 over Bluetooth LE star topology
	topology-specific optimizations contained in RFC 7668.		networks, albeit without all the topology-specific optimizations
			contained in RFC 7668.
	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 6LoWPAN Node (6LN), 6LoWPAN Router (6LR) and 6LoWPAN Border		The terms 6LoWPAN Node (6LN), 6LoWPAN Router (6LR) and 6LoWPAN Border
	Router (6LBR) are defined as in [RFC6775], with an addition that		Router (6LBR) are defined as in [RFC6775], with an addition that
	Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can		Bluetooth LE central and Bluetooth LE peripheral (see Section 2) can
	both be adopted by a 6LN, a 6LR or a 6LBR.		both be adopted by a 6LN, a 6LR or a 6LBR.
	2. Bluetooth LE Mesh Networks		2. Bluetooth LE Networks and the IPSP
	Bluetooth LE defines two Generic Access Profile (GAP) roles of		Bluetooth LE defines two Generic Access Profile (GAP) roles of
	relevance herein: the Bluetooth LE central role and the Bluetooth LE		relevance herein: the Bluetooth LE central role and the Bluetooth LE
	peripheral role. A device in the central role, which is called		peripheral role. A device in the central role, which is called
	central from now on, has traditionally been able to manage multiple		central from now on, has traditionally been able to manage multiple
	simultaneous connections with a number of devices in the peripheral		simultaneous connections with a number of devices in the peripheral
	role, called peripherals hereinafter. Bluetooth 4.1 introduced the		role, called peripherals hereinafter. Bluetooth 4.1 introduced the
	possibility for a peripheral to be connected to more than one central		possibility for a peripheral to be connected to more than one central
	simultaneously, therefore allowing extended topologies beyond the		simultaneously, therefore allowing extended topologies beyond the
	star topology for a Bluetooth LE network. In addition, a device may		star topology for a Bluetooth LE network. In addition, a device may
	simultaneously be a central in a set of link layer connections, as		simultaneously be a central in a set of link layer connections, as
	well as a peripheral in others. On the other hand, the IPSP enables		well as a peripheral in others. On the other hand, the IPSP enables
	discovery of IP-enabled devices and the establishment of a link layer		discovery of IP-enabled devices and the establishment of a link layer
	connection for transporting IPv6 packets. The IPSP defines the Node		connection for transporting IPv6 packets. The IPSP defines the Node
	and Router roles for devices that consume/originate IPv6 packets and		and Router roles for devices that consume/originate IPv6 packets and
	for devices that can route IPv6 packets, respectively. Consistently		for devices that can route IPv6 packets, respectively. Consistently
	with Bluetooth 4.1, a device may implement both roles simultaneously.		with Bluetooth 4.1, a device may implement both roles simultaneously.
	This document assumes a Bluetooth LE mesh network whereby link layer		This document assumes a mesh network composed of Bluetooth LE links,
	connections have been established between neighboring IPv6-enabled		where link layer connections have been established between
	devices. In an IPv6-enabled Bluetooth LE mesh network, a node is a		neighboring IPv6-enabled devices. The IPv6 forwarding devices of the
	neighbor of another node, and vice versa, if a link layer connection		mesh have to implement both Node and Router roles, while simpler
	has been established between both by using the IPSP functionality for		leaf-only nodes can implement only the Node role. In an IPv6-enabled
	discovery and link layer connection establishment for IPv6 packet		mesh of Bluetooth LE links, a node is a neighbor of another node, and
	transport.		vice versa, if a link layer connection has been established between
			both by using the IPSP functionality for discovery and link layer
	3. Specification of IPv6 over Bluetooth LE mesh networks		connection establishment for IPv6 packet transport.
			3. Specification of IPv6 mesh over Bluetooth LE networks
	3.1. Protocol stack		3.1. Protocol stack
	Figure 1 illustrates the protocol stack for IPv6-enabled Bluetooth LE		Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth
	mesh networks. There are two main differences with the IPv6 over		LE networks. There are two main differences with the IPv6 over
	Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6		Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6
	(labelled as "6Lo for Bluetooth LE mesh") is now adapted for		(labelled as "6Lo for mesh of Bluetooth LE") is now adapted for mesh
	Bluetooth LE mesh networks, and b) the protocol stack for IPv6 over		networks of Bluetooth LE links, and b) the protocol stack for IPv6
	Bluetooth LE mesh networks includes IPv6 routing functionality.		mesh networks of Bluetooth LE links includes IPv6 routing
			functionality.
	+----------------------------+		+------------------------------------+
	| Application |		| Application |
	+---------+ +----------------------------+		+---------+ +------------------------------------+
	| IPSS | | UDP/TCP/other |		| IPSS | | UDP/TCP/other |
	+---------+ +----------------------------+		+---------+ +------------------------------------+
	| GATT | | IPv6 |routing| |		| GATT | | IPv6 |routing| |
	+---------+ +----------------------------+		+---------+ +------------------------------------+
	| ATT | | 6Lo for Bluetooth LE Mesh |		| ATT | | 6Lo for IPv6 mesh over Bluetooh LE |
	+---------+--+----------------------------+		+---------+--+------------------------------------+
	| Bluetooth LE L2CAP |		| Bluetooth LE L2CAP |
	- - +-----------------------------------------+- - - HCI		- - +-------------------------------------------------+- - - HCI
	| Bluetooth LE Link Layer |		| Bluetooth LE Link Layer |
	+-----------------------------------------+		+-------------------------------------------------+
	| Bluetooth LE Physical |		| Bluetooth LE Physical |
	+-----------------------------------------+		+-------------------------------------------------+
	Figure 1: Protocol stack for IPv6-enabled Bluetooth LE mesh networks		Figure 1: Protocol stack for IPv6 mesh over Bluetooth LE.
	3.2. Subnet model		3.2. Subnet model
	For IPv6-based Bluetooth LE mesh networks, a multilink model has been		For IPv6 mesh over Bluetooth LE, a multilink model has been chosen,
	chosen, as further illustrated in Figure 2. As IPv6 over Bluetooth		as further illustrated in Figure 2. As IPv6 over Bluetooth LE is
	LE is intended for constrained nodes, and for Internet of Things use		intended for constrained nodes, and for Internet of Things use cases
	cases and environments, the complexity of implementing a separate		and environments, the complexity of implementing a separate subnet on
	subnet on each peripheral-central link and routing between the		each peripheral-central link and routing between the subnets appears
	subnets appears to be excessive. In this specification, the benefits		to be excessive. In this specification, the benefits of treating the
	of treating the collection of point-to-point links between a central		collection of point-to-point links between a central and its
	and its connected peripherals as a single multilink subnet rather		connected peripherals as a single multilink subnet rather than a
	than a multiplicity of separate subnets are considered to outweigh		multiplicity of separate subnets are considered to outweigh the
	the multilink model's drawbacks as described in [RFC4903].		multilink model's drawbacks as described in [RFC4903].
	/		/
	.--------------------------------. /		.--------------------------------. /
	/ 6LR 6LN 6LN \ /		/ 6LR 6LN 6LN \ /
	/ \ \ \ \ /		/ \ \ \ \ /
	| \ \ \ | /		| \ \ \ | /
	| 6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet		| 6LN ----- 6LR --------- 6LR ------ 6LBR ----- | Internet
	| <--Link--> <---Link--->/<--Link->/ | |		| <--Link--> <---Link--->/<--Link->/ | |
	\ / / / \		\ / / / \
	\ 6LN ---- 6LR ----- 6LR / \		\ 6LN ---- 6LR ----- 6LR / \
	'--------------------------------' \		'--------------------------------' \
	\		\
	<------------ Subnet -----------------><---- IPv6 connection -->		<------------ Subnet -----------------><---- IPv6 connection -->
	to the Internet		to the Internet
	Figure 2: Example of an IPv6-based Bluetooth LE mesh network		Figure 2: Example of an IPv6 mesh over a Bluetooth LE network
	connected to the Internet		connected to the Internet
	One or more 6LBRs are connected to the Internet. 6LNs are connected		One or more 6LBRs are connected to the Internet. 6LNs are connected
	to the network through a 6LR or a 6LBR. A prefix is used on the		to the network through a 6LR or a 6LBR. A prefix is used on the
	whole subnet.		whole subnet.
	IPv6-enabled Bluetooth LE mesh networks MUST follow a route-over		IPv6 mesh networks over Bluetooth LE MUST follow a route-over
	approach. This document does not specify the routing protocol to be		approach. This document does not specify the routing protocol to be
	used in an IPv6-enabled Bluetooth LE mesh network.		used in an IPv6 mesh over Bluetooth LE.
	3.3. Link model		3.3. Link model
	3.3.1. Stateless address autoconfiguration		3.3.1. Stateless address autoconfiguration
	6LN, 6LR and 6LBR IPv6 addresses of a Bluetooth LE mesh network are		6LN, 6LR and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE
	configured as per section 3.2.2 of RFC 7668.		are configured as per section 3.2.2 of RFC 7668.
	Multihop DAD functionality as defined in section 8.2 of RFC 6775, or		Multihop DAD functionality as defined in section 8.2 of RFC 6775, or
	some substitute mechanism (see section 3.3.2), MUST be supported.		some substitute mechanism (see section 3.3.2), MUST be supported.
	3.3.2. Neighbor Discovery		3.3.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. The route-over functionality of RFC		including the mesh topology. The route-over functionality of RFC
	skipping to change at page 6, line 18 ¶		skipping to change at page 6, line 18 ¶
	Address Registration Option (ARO) and process the Neighbor		Address Registration Option (ARO) and process the Neighbor
	Advertisement (NA) accordingly. The NS with the ARO option MUST be		Advertisement (NA) accordingly. The NS with the ARO option MUST be
	sent irrespective of the method used to generate the IID. The ARO		sent irrespective of the method used to generate the IID. The ARO
	option requires use of an EUI-64 identifier [RFC6775]. In the case		option requires use of an EUI-64 identifier [RFC6775]. In the case
	of Bluetooth LE, the field SHALL be filled with the 48-bit device		of Bluetooth LE, the field SHALL be filled with the 48-bit device
	address used by the Bluetooth LE node converted into 64-bit Modified		address used by the Bluetooth LE node converted into 64-bit Modified
	EUI-64 format [RFC4291].		EUI-64 format [RFC4291].
	If the 6LN registers for a same compression context multiple		If the 6LN registers for a same compression context multiple
	addresses that are not based on Bluetooth device address, the header		addresses that are not based on Bluetooth device address, the header
	compression efficiency will decrease (see the next subsection).		compression efficiency will decrease.
	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. The router behavior for 6LRs and 6LBRs is described in Section 6		3. The router behavior for 6LRs and 6LBRs is described in Section 6
	of RFC 6775. However, as per this specification, routers SHALL NOT		of RFC 6775. However, as per this specification, routers SHALL NOT
	use multicast NSs to discover other routers' link layer addresses.		use multicast NSs to discover other routers' link layer addresses.
	4. Border router behavior is described in Section 7 of RFC 6775.		4. Border router behavior is described in Section 7 of RFC 6775.
	skipping to change at page 7, line 6 ¶		skipping to change at page 7, line 6 ¶
	LE. All headers MUST be compressed according to RFC 6282 [RFC6282]		LE. All headers MUST be compressed according to RFC 6282 [RFC6282]
	encoding formats.		encoding formats.
	To enable efficient header compression, when the 6LBR sends a Router		To enable efficient header compression, when the 6LBR sends a Router
	Advertisement it MUST include a 6LoWPAN Context Option (6CO)		Advertisement it MUST include a 6LoWPAN Context Option (6CO)
	[RFC6775] matching each address prefix advertised via a Prefix		[RFC6775] matching each address prefix advertised via a Prefix
	Information Option (PIO) [RFC4861] for use in stateless address		Information Option (PIO) [RFC4861] for use in stateless address
	autoconfiguration.		autoconfiguration.
	The specific optimizations of RFC 7668 for header compression, which		The specific optimizations of RFC 7668 for header compression, which
	exploit the star topology and ARO, cannot be generalized in a		exploit the star topology and ARO, cannot be generalized in a mesh
	Bluetooth LE mesh network. Still, a subset of those optimizations		network composed of Bluetooth LE links. Still, a subset of those
	can be applied in some cases in a Bluetooth LE mesh network. In		optimizations can be applied in some cases in such a network. In
	particular, the latter comprise link-local interactions, non-link-		particular, the latter comprise link-local interactions, non-link-
	local packet transmissions originated and performed by a 6LN, and		local packet transmissions originated and performed by a 6LN, and
	non-link-local packet transmissions originated by a 6LN neighbor and		non-link-local packet transmissions originated by a 6LN neighbor and
	sent to a 6LN. For the rest of packet transmissions, context-based		sent to a 6LN. For the rest of packet transmissions, context-based
	compression MAY be used.		compression MAY be used.
	When a device transmits a packet to a neighbor, the sender MUST fully		When a device transmits a packet to a neighbor, the sender MUST fully
	elide the source IID if the source IPv6 address is the link-local		elide the source IID if the source IPv6 address is the link-local
	address based on the sender's Bluetooth device address (SAC=0,		address based on the sender's Bluetooth device address (SAC=0,
	SAM=11). The sender also MUST fully elide the destination IPv6		SAM=11). The sender also MUST fully elide the destination IPv6
	skipping to change at page 8, line 13 ¶		skipping to change at page 8, line 13 ¶
	listeners for multicast groups the packets belong to.		listeners for multicast groups the packets belong to.
	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 security considerations in RFC 7668 apply.		The security considerations in RFC 7668 apply.
	IPv6-enabled Bluetooth LE mesh networks require a routing protocol to		IPv6 mesh networks over Bluetooth LE require a routing protocol to
	find end-to-end paths. Unfortunately, the routing protocol may		find end-to-end paths. Unfortunately, the routing protocol may
	generate additional opportunities for threats and attacks to the		generate additional opportunities for threats and attacks to the
	network.		network.
	RFC 7416 [RFC 7416] provides a systematic overview of threats and		RFC 7416 [RFC 7416] provides a systematic overview of threats and
	attacks on the IPv6 Routing Protocol for Low-Power and Lossy Networks		attacks on the IPv6 Routing Protocol for Low-Power and Lossy Networks
	(RPL), as well as countermeasures. While this specification does not		(RPL), as well as countermeasures. In that document, described
	state the routing protocol to be used in IPv6-enabled Bluetooth LE		threats and attacks comprise threats due to failures to authenticate,
	mesh networks, the guidance of RFC 7416 is useful when RPL is used in		threats due to failure to keep routing information, threats and
	such scenarios. Furthermore, such guidance may partly apply for		attacks on integrity, and threats and attacks on availability.
	other routing protocols as well.		Reported countermeasures comprise confidentiality attack, integrity
			attack, and availability attack countermeasures.
			While this specification does not state the routing protocol to be
			used in IPv6 mesh over Bluetooth LE networks, the guidance of RFC
			7416 is useful when RPL is used in such scenarios. Furthermore, such
			guidance may partly apply for other routing protocols as well.
	6. Acknowledgements		6. Acknowledgements
	The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are		The Bluetooth, Bluetooth Smart and Bluetooth Smart Ready marks are
	registered trademarks owned by Bluetooth SIG, Inc.		registered trademarks owned by Bluetooth SIG, Inc.
	The authors of this document are grateful to all RFC 7668 authors,		The authors of this document are grateful to all RFC 7668 authors,
	since this document borrows many concepts (albeit, with necessary		since this document borrows many concepts (albeit, with necessary
	extensions) from RFC 7668.		extensions) from RFC 7668.
			The authors also thank Alain Michaud, Mark Powell and Martin Turon
			for their comments, which helped improve the document.
	Carles Gomez has been supported in part by the Spanish Government		Carles Gomez has been supported in part by the Spanish Government
	Ministerio de Economia y Competitividad through project		Ministerio de Economia y Competitividad through project
	TEC2012-32531, and FEDER.		TEC2012-32531, and FEDER.
	7. References		7. References
	7.1. Normative References		7.1. Normative References
	[BTCorev4.1]		[BTCorev4.1]
	Bluetooth Special Interest Group, "Bluetooth Core		Bluetooth Special Interest Group, "Bluetooth Core
	Specification Version 4.1", December 2013,		Specification Version 4.1", December 2013,
	<https://www.bluetooth.org/en-us/specification/adopted-		<https://www.bluetooth.org/en-us/specification/adopted-
	specifications>.		specifications>.
	[IPSP] Bluetooth Special Interest Group, "Bluetooth Internet		[IPSP] Bluetooth Special Interest Group, "Bluetooth Internet
	Protocol Support Profile Specification Version 1.0.0",		Protocol Support Profile Specification Version 1.0.0",
	skipping to change at page 10, line 4 ¶		skipping to change at page 10, line 12 ¶
	DOI 10.17487/RFC4903, June 2007,		DOI 10.17487/RFC4903, June 2007,
	<http://www.rfc-editor.org/info/rfc4903>.		<http://www.rfc-editor.org/info/rfc4903>.
	[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,		[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
	and M. Richardson, Ed., "A Security Threat Analysis for		and M. Richardson, Ed., "A Security Threat Analysis for
	the Routing Protocol for Low-Power and Lossy Networks		the Routing Protocol for Low-Power and Lossy Networks
	(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,		(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
	<http://www.rfc-editor.org/info/rfc7416>.		<http://www.rfc-editor.org/info/rfc7416>.
	Authors' Addresses		Authors' Addresses
	Carles Gomez		Carles Gomez
	Universitat Politecnica de Catalunya/Fundacio i2cat		Universitat Politecnica de Catalunya/Fundacio 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
	Seyed Mahdi Darroudi		Seyed Mahdi Darroudi
	Universitat Politecnica de Catalunya/Fundacio i2cat		Universitat Politecnica de Catalunya/Fundacio i2cat
	C/Esteve Terradas, 7		C/Esteve Terradas, 7
	Castelldefels 08860		Castelldefels 08860
	Spain		Spain
	Email: s.darroudi2014@yahoo.com		Email: sm.darroudi@entel.upc.edu
	Teemu Savolainen		Teemu Savolainen
	Nokia		Nokia Technologies
	Visiokatu 3		Hatanpaan valtatie 30
	Tampere 33720		Tampere 33100
	Finland		Finland
	Email: teemu.savolainen@nokia.com		Email: teemu.savolainen@nokia.com
End of changes. 30 change blocks.
	78 lines changed or deleted		92 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/