< draft-ietf-6lo-blemesh-07.txt		draft-ietf-6lo-blemesh-08.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: June 16, 2020 T. Savolainen		Expires: April 10, 2021 T. Savolainen
	DarkMatter		DarkMatter
	M. Spoerk		M. Spoerk
	Graz University of Technology		Graz University of Technology
	December 14, 2019		October 7, 2020
	IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP		IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
	draft-ietf-6lo-blemesh-07		draft-ietf-6lo-blemesh-08
	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 June 16, 2020.		This Internet-Draft will expire on April 10, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2020 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 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 . . . . . . . . . . . . . . . . . . . . . 8		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
	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 . . . . . . . . . . . . . 12		9. Appendix B: Node joining procedure . . . . . . . . . . . . . 13
	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
	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. As a consequence, RFC 7668
	specifically developed and optimized for that type of network		was specifically developed and optimized for that type of network
	topology. However, the functionality described in RFC 7668 is not		topology. However, the functionality described in RFC 7668 is not
	sufficient and would fail to enable an IPv6 mesh over Bluetooth LE		sufficient and would fail to enable an IPv6 mesh over Bluetooth LE
	links. This document specifies mechanisms that are needed to enable		links. This document specifies mechanisms that are needed to enable
	IPv6 mesh over Bluetooth LE links. This document does not specify		IPv6 mesh over Bluetooth LE links. This document does not specify
	the routing protocol to be used in an IPv6 mesh over Bluetooth LE		the routing protocol to be used in an IPv6 mesh over Bluetooth LE
	links.		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",
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 33 ¶
	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 (now deprecated)		role, called peripherals hereinafter. Bluetooth 4.1 (now deprecated)
	introduced the possibility for a peripheral to be connected to more		introduced the possibility for a peripheral to be connected to more
	than one central simultaneously, therefore allowing extended		than one central simultaneously, therefore allowing extended
	topologies beyond the star topology for a Bluetooth LE network. In		topologies beyond the star topology for a Bluetooth LE network. In
	addition, a device may simultaneously be a central in a set of link		addition, a device may simultaneously be a central in a set of link
	layer connections, as well as a peripheral in others. On the other		layer connections, as well as a peripheral in others.
	hand, the IPSP enables discovery of IP-enabled devices and the
	establishment of a link layer connection for transporting IPv6		On the other hand, the IPSP enables discovery of IP-enabled devices
	packets. The IPSP defines the Node and Router roles for devices that		and the establishment of a link layer connection for transporting
	consume/originate IPv6 packets and for devices that can route IPv6		IPv6 packets. The IPSP defines the Node and Router roles for devices
	packets, respectively. Consistently with Bluetooth 4.1 and		that consume/originate IPv6 packets and for devices that can route
			IPv6 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 IPSP Node and		forwarding devices of the mesh have to implement both IPSP Node and
	Router roles, while simpler leaf-only nodes can implement only the		Router roles, while simpler leaf-only nodes can implement only the
	Node role. In an IPv6 mesh over Bluetooth LE links, a node is a		Node role. In an IPv6 mesh over Bluetooth LE links, a node is a
	neighbor of another node, and vice versa, if a link layer connection		neighbor of another node, and vice versa, if a link layer connection
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 45 ¶
	Figure 1: Protocol stack for IPv6 mesh over Bluetooth LE links.		Figure 1: Protocol stack for IPv6 mesh over Bluetooth LE links.
	Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes.		Bluetooth 4.2 defines a default MTU for Bluetooth LE of 251 bytes.
	Excluding the L2CAP header of 4 bytes, a protocol data unit (PDU)		Excluding the L2CAP header of 4 bytes, a protocol data unit (PDU)
	size of 247 bytes is available for the layer above L2CAP. (Note:		size of 247 bytes is available for the layer above L2CAP. (Note:
	earlier Bluetooth LE versions offered a maximum amount of 23 bytes		earlier Bluetooth LE versions offered a maximum amount of 23 bytes
	for the layer atop L2CAP.) The L2CAP provides a fragmentation and		for the layer atop L2CAP.) The L2CAP provides a fragmentation and
	reassembly solution for transmitting or receiving larger PDUs. At		reassembly solution for transmitting or receiving larger PDUs. At
	each link, the IPSP defines means for negotiating a link-layer		each link, the IPSP defines means for negotiating a link-layer
	connection that provides an MTU of 1280 octets or higher for the IPv6		connection that provides an MTU of 1280 octets or higher for the IPv6
	layer [IPSP]. The link-layer MTU is negotiated separately for each		layer [IPSP]. For the sake of lightweight implementation and
			operation, an MTU of 1280 octets is RECOMMENDED for IPv6 mesh over
			BLE links. The link-layer MTU is negotiated separately for each
	direction. Implementations that require an equal link-layer MTU for		direction. Implementations that require an equal link-layer MTU for
	the two directions SHALL use the smallest of the possibly different		the two directions SHALL use the smallest of the possibly different
	MTU values.		MTU values.
	Note that this specification allows using different MTUs in different		Note that this specification allows using different MTUs in different
	links. If an implementation requires use of the same MTU on every		links. If an implementation requires use of the same MTU on every
	one of its links, and a new node with a smaller MTU is added to the		one of its links, and a new node with a smaller MTU is added to the
	network, a renegotiation of one or more links can occur. In the		network, a renegotiation of one or more links can occur. In the
	worst case, the renegotiations could cascade network-wide. In that		worst case, the renegotiations could cascade network-wide. In that
	case, implementers need to assess the impact of such phenomenon.		case, implementers need to assess the impact of such phenomenon.
	skipping to change at page 5, line 44 ¶		skipping to change at page 5, line 49 ¶
	'--------------------------------' \		'--------------------------------' \
	\		\
	<------------ Subnet -----------------><---- IPv6 connection -->		<------------ Subnet -----------------><---- IPv6 connection -->
	to the Internet		to the Internet
	Figure 2: Example of an IPv6 mesh over a Bluetooth LE 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 single Global Unicast
	whole subnet.		prefix is used on the whole subnet.
	IPv6 mesh over Bluetooth LE links MUST follow a route-over approach.		IPv6 mesh over Bluetooth LE links MUST follow a route-over approach.
	This document does not specify the routing protocol to be used in an		This document does not specify the routing protocol to be used in an
	IPv6 mesh over Bluetooth LE links.		IPv6 mesh over Bluetooth LE links.
	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
	skipping to change at page 6, line 46 ¶		skipping to change at page 6, line 50 ¶
	[RFC8505]. In the case of Bluetooth LE, by default the ROVR field is		[RFC8505]. In the case of Bluetooth LE, by default the ROVR field is
	filled with the 48-bit device address used by the Bluetooth LE node		filled with the 48-bit device address used by the Bluetooth LE node
	converted into 64-bit Modified EUI-64 format [RFC4291]. Optionally,		converted into 64-bit Modified EUI-64 format [RFC4291]. Optionally,
	a cryptographic ID (see [I-D.ietf-6lo-ap-nd] MAY be placed in the		a cryptographic ID (see [I-D.ietf-6lo-ap-nd] MAY be placed in the
	ROVR field. If a cryptographic ID is used, address registration and		ROVR field. If a cryptographic ID is used, address registration and
	multihop DAD formats and procedures defined in [I-D.ietf-6lo-ap-nd]		multihop DAD formats and procedures defined in [I-D.ietf-6lo-ap-nd]
	MUST be used, unless an alternative mechanism offering equivalent		MUST be used, unless an alternative mechanism offering equivalent
	protection is used. As per RFC 8505, a 6LN MUST NOT register its		protection is used. As per RFC 8505, a 6LN MUST NOT register its
	link-local address.		link-local address.
	If the 6LN registers for a same compression context multiple		If the 6LN registers multiple addresses that are not based on
	addresses that are not based on Bluetooth device address, the header		Bluetooth device address using the same compression context, the
	compression efficiency will decrease.		header 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
	of RFC 6775, and updated by RFC 8505. However, as per this		of RFC 6775, and updated by RFC 8505. However, as per this
	specification: a) Routers SHALL NOT use multicast NSs to discover		specification: a) Routers SHALL NOT use multicast NSs to discover
	other routers' link layer addresses. b) As per section 6.2 of RFC		other routers' link layer addresses. b) As per section 6.2 of RFC
	6775, in a dynamic configuration scenario, a 6LR comes up as a non-		6775, in a dynamic configuration scenario, a 6LR comes up as a non-
	router and waits to receive a Router Advertisement for configuring		router and waits to receive a Router Advertisement for configuring
	its own interface address first, before setting its interfaces to be		its own interface address first, before setting its interfaces to be
	advertising interfaces and turning into a router. In order to		advertising interfaces and turning into a router. In order to
	support such operation in an IPv6 mesh over Bluetooth LE links, a 6LR		support such operation in an IPv6 mesh over Bluetooth LE links, a 6LR
	first uses the IPSP Node role only. Once the 6LR has established a		first uses the IPSP Node role only. Once the 6LR has established a
	connection with another node previously running as a router, and		connection with another node currently running as a router, and
	receives a Router Advertisement from that router, the 6LR configures		receives a Router Advertisement from that router, the 6LR configures
	its own interface address, it turns into a router, and it runs as an		its own interface address, it turns into a router, and it runs as an
	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
	skipping to change at page 8, line 6 ¶		skipping to change at page 8, line 12 ¶
	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 by a 6LN, and non-link-local packets intended for a 6LN		originated by a 6LN, and non-link-local packets intended for a 6LN
	that are originated or forwarded by a neighbor of that 6LN. For the		that are originated or forwarded by a neighbor of that 6LN. For all
	rest of packet transmissions, context-based compression MAY be used.		other packet transmissions, context-based 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).
	When a 6LN transmits a packet, with a non-link-local source address		When a 6LN transmits a packet, with a non-link-local source address
	that the 6LN has registered with EARO in the next-hop router for the		that the 6LN has registered with EARO in the next-hop router for the
	skipping to change at page 14, line 47 ¶		skipping to change at page 15, line 8 ¶
	[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>.
	[I-D.ietf-6lo-ap-nd]		[I-D.ietf-6lo-ap-nd]
	Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,		Thubert, P., Sarikaya, B., Sethi, M., and R. Struik,
	"Address Protected Neighbor Discovery for Low-power and		"Address Protected Neighbor Discovery for Low-power and
	Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in		Lossy Networks", draft-ietf-6lo-ap-nd-23 (work in
	progress), April 2019.		progress), April 2020.
	[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,		[RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
	DOI 10.17487/RFC4903, June 2007,		DOI 10.17487/RFC4903, June 2007,
	<https://www.rfc-editor.org/info/rfc4903>.		<https://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,
	<https://www.rfc-editor.org/info/rfc7416>.		<https://www.rfc-editor.org/info/rfc7416>.
End of changes. 15 change blocks.
	26 lines changed or deleted		29 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/