< draft-ietf-6lo-blemesh-06.txt		draft-ietf-6lo-blemesh-07.txt >
	6Lo Working Group C. Gomez		6Lo Working Group C. Gomez
	Internet-Draft S. Darroudi		Internet-Draft S. Darroudi
	Intended status: Standards Track Universitat Politecnica de Catalunya		Intended status: Standards Track Universitat Politecnica de Catalunya
	Expires: March 31, 2020 T. Savolainen		Expires: June 16, 2020 T. Savolainen
	DarkMatter		DarkMatter
	M. Spoerk		M. Spoerk
	Graz University of Technology		Graz University of Technology
	September 28, 2019		December 14, 2019
	IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP		IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
	draft-ietf-6lo-blemesh-06		draft-ietf-6lo-blemesh-07
	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 specifies		formation of extended topologies as well. This document specifies
	mechanisms that are needed to enable IPv6 mesh over Bluetooth Low		mechanisms that are needed to enable IPv6 mesh over Bluetooth Low
	Energy links established by using the Bluetooth Internet Protocol		Energy links established by using the Bluetooth Internet Protocol
	Support Profile. This document does not specify the routing protocol		Support Profile. This document does not specify the routing protocol
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 https://datatracker.ietf.org/drafts/current/.		Drafts is at https://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 March 31, 2020.		This Internet-Draft will expire on June 16, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 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
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 25 ¶		skipping to change at page 2, line 25 ¶
	1.1. Terminology and Requirements Language . . . . . . . . . . 3		1.1. Terminology and Requirements Language . . . . . . . . . . 3
	2. Bluetooth LE Networks and the IPSP . . . . . . . . . . . . . 3		2. Bluetooth LE Networks and the IPSP . . . . . . . . . . . . . 3
	3. Specification of IPv6 mesh over Bluetooth LE links . . . . . 4		3. Specification of IPv6 mesh over Bluetooth LE links . . . . . 4
	3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4		3.1. Protocol stack . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Subnet model . . . . . . . . . . . . . . . . . . . . . . 5
	3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Link model . . . . . . . . . . . . . . . . . . . . . . . 6
	3.3.1. Stateless address autoconfiguration . . . . . . . . . 6		3.3.1. Stateless address autoconfiguration . . . . . . . . . 6
	3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 6		3.3.2. Neighbor Discovery . . . . . . . . . . . . . . . . . 6
	3.3.3. Header compression . . . . . . . . . . . . . . . . . 7		3.3.3. Header compression . . . . . . . . . . . . . . . . . 7
	3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 8		3.3.4. Unicast and multicast mapping . . . . . . . . . . . . 8
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9		6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
	8. Appendix A: Bluetooth LE connection establishment example . . 10		8. Appendix A: Bluetooth LE connection establishment example . . 10
	9. Appendix B: Node joining procedure . . . . . . . . . . . . . 13		9. Appendix B: Node joining procedure . . . . . . . . . . . . . 12
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
	10.1. Normative References . . . . . . . . . . . . . . . . . . 13		10.1. Normative References . . . . . . . . . . . . . . . . . . 13
	10.2. Informative References . . . . . . . . . . . . . . . . . 14		10.2. Informative References . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	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
	skipping to change at page 3, line 45 ¶		skipping to change at page 3, line 45 ¶
	establishment of a link layer connection for transporting IPv6		establishment of a link layer connection for transporting IPv6
	packets. The IPSP defines the Node and Router roles for devices that		packets. The IPSP defines the Node and Router roles for devices that
	consume/originate IPv6 packets and for devices that can route IPv6		consume/originate IPv6 packets and for devices that can route IPv6
	packets, respectively. Consistently with Bluetooth 4.1 and		packets, respectively. Consistently with Bluetooth 4.1 and
	subsequent Bluetooth versions (e.g. Bluetooth 4.2 [BTCorev4.2] or		subsequent Bluetooth versions (e.g. Bluetooth 4.2 [BTCorev4.2] or
	subsequent), a device may implement both roles simultaneously.		subsequent), a device may implement both roles simultaneously.
	This document assumes a mesh network composed of Bluetooth LE links,		This document assumes a mesh network composed of Bluetooth LE links,
	where link layer connections are established between neighboring		where link layer connections are established between neighboring
	IPv6-enabled devices (see Section 3.3.2, item 3.b)). The IPv6		IPv6-enabled devices (see Section 3.3.2, item 3.b)). The IPv6
	forwarding devices of the mesh have to implement both Node and Router		forwarding devices of the mesh have to implement both IPSP Node and
	roles, while simpler leaf-only nodes can implement only the Node		Router roles, while simpler leaf-only nodes can implement only the
	role. In an IPv6 mesh over Bluetooth LE links, a node is a neighbor		Node role. In an IPv6 mesh over Bluetooth LE links, a node is a
	of another node, and vice versa, if a link layer connection has been		neighbor of another node, and vice versa, if a link layer connection
	established between both by using the IPSP functionality for		has been established between both by using the IPSP functionality for
	discovery and link layer connection establishment for IPv6 packet		discovery and link layer connection establishment for IPv6 packet
	transport.		transport.
	3. Specification of IPv6 mesh over Bluetooth LE links		3. Specification of IPv6 mesh over Bluetooth LE links
	3.1. Protocol stack		3.1. Protocol stack
	Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth		Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth
	LE links. There are two main differences with the IPv6 over		LE links. 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
	skipping to change at page 6, line 14 ¶		skipping to change at page 6, line 14 ¶
	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 in an IPv6 mesh over Bluetooth LE		6LN, 6LR and 6LBR IPv6 addresses in an IPv6 mesh over Bluetooth LE
	links are configured as per section 3.2.2 of RFC 7668.		links are configured as per section 3.2.2 of RFC 7668.
	Multihop DAD functionality as defined in section 8.2 of RFC 6775 and		Multihop DAD functionality as defined in section 8.2 of RFC 6775 and
	updated by RFC 8505, or some substitute mechanism (see section		updated by RFC 8505, or some substitute mechanism (see section
	3.3.2), MUST be supported.		3.3.2), MAY 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], subsequently updated by		Personal Area Networks (6LoWPANs)' [RFC6775], subsequently updated by
	'Registration Extensions for IPv6 over Low-Power Wireless Personal		'Registration Extensions for IPv6 over Low-Power Wireless Personal
	Area Network (6LoWPAN) Neighbor Discovery' [RFC8505], describes the		Area Network (6LoWPAN) Neighbor Discovery' [RFC8505], describes the
	neighbor discovery functionality adapted for use in several 6LoWPAN		neighbor discovery functionality adapted for use in several 6LoWPAN
	topologies, including the mesh topology. The route-over		topologies, including the mesh topology. The route-over
	functionality of RFC 6775 and RFC 8505 MUST be supported.		functionality of RFC 6775 and RFC 8505 MUST be supported.
	The following aspects of the Neighbor Discovery optimizations for		The following aspects of the Neighbor Discovery optimizations for
	6LoWPAN [RFC6775],[RFC8505] are applicable to Bluetooth LE 6LNs:		6LoWPAN [RFC6775],[RFC8505] are applicable to Bluetooth LE 6LNs:
	1. A Bluetooth LE host MUST register its non-link-local addresses		1. A Bluetooth LE 6LN SHOULD register its non-link-local addresses
	with its routers by sending a Neighbor Solicitation (NS) message with		with its routers by sending a Neighbor Solicitation (NS) message with
	the Extended Address Registration Option (EARO) and process the		the Extended Address Registration Option (EARO) and process the
	Neighbor Advertisement (NA) accordingly. The NS with the EARO option		Neighbor Advertisement (NA) accordingly. Note that in some cases
	MUST be sent irrespective of the method used to generate the IID.		(e.g. very short-lived connections) it may not be worthwhile for a
	The EARO option includes a Registration Ownership Verifier (ROVR)		6LN to send an NS with EARO for registering its address. The EARO
	field [RFC8505]. In the case of Bluetooth LE, by default the ROVR		option includes a Registration Ownership Verifier (ROVR) field
	field is filled with the 48-bit device address used by the Bluetooth		[RFC8505]. In the case of Bluetooth LE, by default the ROVR field is
	LE node converted into 64-bit Modified EUI-64 format [RFC4291].		filled with the 48-bit device address used by the Bluetooth LE node
	Optionally, a cryptographic ID (see [I-D.ietf-6lo-ap-nd] MAY be		converted into 64-bit Modified EUI-64 format [RFC4291]. Optionally,
	placed in the ROVR field. If a cryptographic ID is used, address		a cryptographic ID (see [I-D.ietf-6lo-ap-nd] MAY be placed in the
	registration and multihop DAD formats and procedures defined in		ROVR field. If a cryptographic ID is used, address registration and
	[I-D.ietf-6lo-ap-nd] MUST be used, unless an alternative mechanism		multihop DAD formats and procedures defined in [I-D.ietf-6lo-ap-nd]
	offering equivalent protection is used. As per RFC 8505, a 6LN MUST		MUST be used, unless an alternative mechanism offering equivalent
	NOT register its link-local address.		protection is used. As per RFC 8505, a 6LN MUST NOT register its
			link-local address.
	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.		compression efficiency will decrease.
	2. For sending Router Solicitations and processing Router		2. For sending Router Solicitations and processing Router
	Advertisements the Bluetooth LE hosts MUST, respectively, follow		Advertisements the Bluetooth LE hosts MUST, respectively, follow
	Sections 5.3 and 5.4 of [RFC6775], and Section 5.6 of [RFC8505].		Sections 5.3 and 5.4 of [RFC6775], and Section 5.6 of [RFC8505].
	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
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 28 ¶
	IPSP Router. A 6LBR uses the IPSP Router role since the 6LBR is		IPSP Router. A 6LBR uses the IPSP Router role since the 6LBR is
	initialized. See an example in the Appendix.		initialized. See an example in the Appendix.
	4. Border router behavior is described in Section 7 of RFC 6775, and		4. Border router behavior is described in Section 7 of RFC 6775, and
	updated by RFC 8505.		updated by RFC 8505.
	RFC 6775 defines substitutable mechanisms for distributing prefixes		RFC 6775 defines substitutable mechanisms for distributing prefixes
	and context information (section 8.1 of RFC 6775), as well as for		and context information (section 8.1 of RFC 6775), as well as for
	Duplicate Address Detection across a route-over 6LoWPAN (section 8.2		Duplicate Address Detection across a route-over 6LoWPAN (section 8.2
	of RFC 6775). RFC 8505 updates those mechanisms and the related		of RFC 6775). RFC 8505 updates those mechanisms and the related
	message formats. Implementations of this specification MUST support		message formats. Implementations of this specification MAY support
	the features described in sections 8.1 and 8.2 of RFC 6775, as		the features described in sections 8.1 and 8.2 of RFC 6775, as
	updated by RFC 8505, unless some alternative ("substitute") from some		updated by RFC 8505, unless some alternative ("substitute") from some
	other specification is supported by the implementation.		other specification is supported by the implementation.
	3.3.3. Header compression		3.3.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 as the basis for IPv6 header compression on top of Bluetooth		REQUIRED as the basis for IPv6 header compression on top of Bluetooth
	LE. All headers MUST be compressed according to RFC 6282 [RFC6282]		LE. All headers MUST be compressed according to RFC 6282 [RFC6282]
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	Option (PIO) [RFC4861] for use in stateless address		Option (PIO) [RFC4861] for use in stateless address
	autoconfiguration. Note that 6CO is not needed for context-based		autoconfiguration. Note that 6CO is not needed for context-based
	compression when a single prefix is used in the network.		compression when a single prefix is used in the network.
	The specific optimizations of RFC 7668 for header compression, which		The specific optimizations of RFC 7668 for header compression, which
	exploited the star topology and ARO (note that the latter has been		exploited the star topology and ARO (note that the latter has been
	updated by EARO as per RFC 8505), cannot be generalized in an IPv6		updated by EARO as per RFC 8505), cannot be generalized in an IPv6
	mesh over Bluetooth LE links. Still, a subset of those optimizations		mesh over Bluetooth LE links. Still, a subset of those optimizations
	can be applied in some cases in such a network. These cases comprise		can be applied in some cases in such a network. These cases comprise
	link-local interactions, non-link-local packet transmissions		link-local interactions, non-link-local packet transmissions
	originated and performed by a 6LN, and non-link-local packets		originated by a 6LN, and non-link-local packets intended for a 6LN
	intended for a 6LN that are originated or forwarded by a neighbor of		that are originated or forwarded by a neighbor of that 6LN. For the
	that 6LN. For the rest of packet transmissions, context- based		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
	address if it is the link-local address based on the neighbor's		address if it is the link-local address based on the neighbor's
	Bluetooth device address (DAC=0, DAM=11).		Bluetooth device address (DAC=0, DAM=11).
	A 6LN SHOULD register its non-link-local address with EARO in the		When a 6LN transmits a packet, with a non-link-local source address
	next-hop router. Note that in some cases (e.g. very short-lived		that the 6LN has registered with EARO in the next-hop router for the
	connections) it may not be worthwhile for a 6LN to send an NS with		indicated prefix, the source address MUST be fully elided if it is
	EARO for registering its address. When a 6LN transmits a packet,		the latest address that the 6LN has registered for the indicated
	with a non-link-local source address that the 6LN has registered with		prefix (SAC=1, SAM=11). If the source non-link-local address is not
	EARO in the next-hop router for the indicated prefix, the source		the latest registered by the 6LN, then the 64 bits of the IID SHALL
	address MUST be fully elided if it is the latest address that the 6LN		be fully carried in-line (SAC=1, SAM=01) or if the first 48 bits of
	has registered for the indicated prefix (SAC=1, SAM=11). If the		the IID match with the latest address registered by the 6LN, then the
	source non-link-local address is not the latest registered by the		last 16 bits of the IID SHALL be carried in-line (SAC=1, SAM=10).
	6LN, then the 64 bits of the IID SHALL be fully carried in-line
	(SAC=1, SAM=01) or if the first 48 bits of the IID match with the
	latest address registered by the 6LN, then the last 16 bits of the
	IID SHALL be carried in-line (SAC=1, SAM=10).
	When a router transmits a packet to a neighboring 6LN, with a non-		When a router transmits a packet to a neighboring 6LN, with a non-
	link-local destination address, the router MUST fully elide the		link-local destination address, the router MUST fully elide the
	destination IPv6 address if the destination address is the latest		destination IPv6 address if the destination address is the latest
	registered by the 6LN with EARO for the indicated context (DAC=1,		registered by the 6LN with EARO for the indicated context (DAC=1,
	DAM=11). If the destination address is a non-link-local address and		DAM=11). If the destination address is a non-link-local address and
	not the latest registered, then the 6LN MUST either include the IID		not the latest registered, then the 6LN MUST either include the IID
	part fully in-line (DAM=01) or, if the first 48 bits of the IID match		part fully in-line (DAM=01) or, if the first 48 bits of the IID match
	to the latest registered address, then elide those 48 bits (DAM=10).		to the latest registered address, then elide those 48 bits (DAM=10).
End of changes. 13 change blocks.
	43 lines changed or deleted		39 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/