< draft-ietf-6lo-plc-03.txt		draft-ietf-6lo-plc-04.txt >
	6Lo Working Group J. Hou		6Lo Working Group J. Hou
	Internet-Draft B. Liu		Internet-Draft B. Liu
	Intended status: Standards Track Huawei Technologies		Intended status: Standards Track Huawei Technologies
	Expires: October 31, 2020 Y-G. Hong		Expires: December 5, 2020 Y-G. Hong
	ETRI		ETRI
	X. Tang		X. Tang
	SGEPRI		SGEPRI
	C. Perkins		C. Perkins
	April 29, 2020		June 3, 2020
	Transmission of IPv6 Packets over PLC Networks		Transmission of IPv6 Packets over PLC Networks
	draft-ietf-6lo-plc-03		draft-ietf-6lo-plc-04
	Abstract		Abstract
	Power Line Communication (PLC), namely using the electric-power lines		Power Line Communication (PLC), namely using the electric-power lines
	for indoor and outdoor communications, has been widely applied to		for indoor and outdoor communications, has been widely applied to
	support Advanced Metering Infrastructure (AMI), especially smart		support Advanced Metering Infrastructure (AMI), especially smart
	meters for electricity. The inherent advantage of existing		meters for electricity. The inherent advantage of existing
	electricity infrastructure facilitates the expansion of PLC		electricity infrastructure facilitates the expansion of PLC
	deployments, and moreover, a wide variety of accessible devices		deployments, and moreover, a wide variety of accessible devices
	raises the potential demand of IPv6 for future applications. This		raises the potential demand of IPv6 for future applications. This
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 October 31, 2020.		This Internet-Draft will expire on December 5, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 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
	skipping to change at page 6, line 47 ¶		skipping to change at page 6, line 47 ¶
	The Maximum Transmission Unit (MTU) of the MAC layer determines		The Maximum Transmission Unit (MTU) of the MAC layer determines
	whether fragmentation and reassembly are needed at the adaptation		whether fragmentation and reassembly are needed at the adaptation
	layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or		layer of IPv6 over PLC. IPv6 requires an MTU of 1280 octets or
	greater; thus for a MAC layer with MTU lower than this limit,		greater; thus for a MAC layer with MTU lower than this limit,
	fragmentation and reassembly at the adaptation layer are required.		fragmentation and reassembly at the adaptation layer are required.
	The IEEE 1901.1 MAC supports upper layer packets up to 2031 octets.		The IEEE 1901.1 MAC supports upper layer packets up to 2031 octets.
	The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the		The IEEE 1901.2 MAC layer supports the MTU of 1576 octets (the
	original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]).		original value of 1280 bytes was updated in 2015 [IEEE_1901.2a]).
	Though fragmentation and reassembly are not needed in these two		Though these two technologies can support IPv6 natively without
	technologies, other 6lo functions like header compression are still		fragmentation and reassembly, it is possible to configure a smaller
	applicable and useful, particularly in high-noise communication		MTU in high-noise communication environment. Thus the 6lo functions,
	environments.		including header compression, fragmentation and reassembly, are still
			applicable and useful.
	The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting		The MTU for ITU-T G.9903 is 400 octets, insufficient for supporting
	IPv6's MTU. For this reason, fragmentation and reassembly as per		IPv6's MTU. For this reason, fragmentation and reassembly as per
	[RFC4944] MUST be enabled for G.9903-based networks.		[RFC4944] MUST be enabled for G.9903-based networks.
	3.4. Routing Protocol		3.4. Routing Protocol
	Routing protocols suitable for use in PLC networks include:		Routing protocols suitable for use in PLC networks include:
	o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550]		o RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550]
	skipping to change at page 7, line 43 ¶		skipping to change at page 7, line 43 ¶
	the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based		the IEEE 1901.2 standard refers to ITU-T G.9903 for LOAD-based
	networks.		networks.
	4. IPv6 over PLC		4. IPv6 over PLC
	6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provides useful		6LoWPAN standards [RFC4944], [RFC6775], and [RFC6282] provides useful
	functionality including link-local IPv6 addresses, stateless address		functionality including link-local IPv6 addresses, stateless address
	auto-configuration, neighbor discovery and header compression.		auto-configuration, neighbor discovery and header compression.
	However, due to the different characteristics of the PLC media, the		However, due to the different characteristics of the PLC media, the
	6LoWPAN adaptation layer cannot perfectly fulfill the requirements.		6LoWPAN adaptation layer cannot perfectly fulfill the requirements.
	Besides, some of the features like fragmentation and reassembly are		These considerations suggest the need for a dedicated adaptation
	redudant to some PLC technologies. These considerations suggest the		layer for PLC, which is detailed in the following subsections.
	need for a dedicated adaptation layer for PLC, which is detailed in
	the following subsections.
	4.1. Stateless Address Autoconfiguration		4.1. Stateless Address Autoconfiguration
	To obtain an IPv6 Interface Identifier (IID), a PLC device performs		To obtain an IPv6 Interface Identifier (IID), a PLC device performs
	stateless address autoconfiguration [RFC4944]. The autoconfiguration		stateless address autoconfiguration [RFC4944]. The autoconfiguration
	can be based on either a long or short link-layer address.		can be based on either a long or short link-layer address.
	The IID can be based on the device's 48-bit MAC address or its EUI-64		The IID can be based on the device's 48-bit MAC address or its EUI-64
	identifier [EUI-64]. A 48-bit MAC address MUST first be extended to		identifier [EUI-64]. A 48-bit MAC address MUST first be extended to
	a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth		a 64-bit Interface ID by inserting 0xFFFE at the fourth and fifth
	skipping to change at page 8, line 38 ¶		skipping to change at page 8, line 38 ¶
	be set to zero. In order to avoid any ambiguity in the derived		be set to zero. In order to avoid any ambiguity in the derived
	Interface ID, these two bits MUST NOT be used to generate the PANID		Interface ID, these two bits MUST NOT be used to generate the PANID
	(for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). In		(for IEEE 1901.2 and ITU-T G.9903) or NID (for IEEE 1901.1). In
	other words, the PANID or NID MUST always be chosen so that these		other words, the PANID or NID MUST always be chosen so that these
	bits are zeros.		bits are zeros.
	For privacy reasons, the IID derived by the MAC address SHOULD only		For privacy reasons, the IID derived by the MAC address SHOULD only
	be used for link-local address configuration. A PLC host SHOULD use		be used for link-local address configuration. A PLC host SHOULD use
	the IID derived by the link-layer short address to configure the IPv6		the IID derived by the link-layer short address to configure the IPv6
	address used for communication with the public network; otherwise,		address used for communication with the public network; otherwise,
	the host's MAC address is exposed.		the host's MAC address is exposed. Implementations should look at
			[RFC8064] as well, in order to generate a stable IPv6 address using
			an opaque IID.
	4.2. IPv6 Link Local Address		4.2. IPv6 Link Local Address
	The IPv6 link-local address [RFC4291] for a PLC interface is formed		The IPv6 link-local address [RFC4291] for a PLC interface is formed
	by appending the IID, as defined above, to the prefix FE80::/64 (see		by appending the IID, as defined above, to the prefix FE80::/64 (see
	Figure 2). Implementations should look at [RFC8064] as well, in		Figure 2).
	order to generate a stable IPv6 link-local address using an opaque
	IID.
	10 bits 54 bits 64 bits		10 bits 54 bits 64 bits
	+----------+-----------------------+----------------------------+		+----------+-----------------------+----------------------------+
	|1111111010| (zeros) | Interface Identifier |		|1111111010| (zeros) | Interface Identifier |
	+----------+-----------------------+----------------------------+		+----------+-----------------------+----------------------------+
	Figure 2: IPv6 Link Local Address for a PLC interface		Figure 2: IPv6 Link Local Address for a PLC interface
	4.3. Unicast Address Mapping		4.3. Unicast Address Mapping
	skipping to change at page 12, line 19 ¶		skipping to change at page 12, line 19 ¶
	power lines, PLC Data Link layer provides the function of		power lines, PLC Data Link layer provides the function of
	segmentation and reassembly. A Segment Control Field is defined in		segmentation and reassembly. A Segment Control Field is defined in
	the MAC frame header regardless of whether segmentation is required.		the MAC frame header regardless of whether segmentation is required.
	The number of data octets of the PHY payload can change dynamically		The number of data octets of the PHY payload can change dynamically
	based on channel conditions, thus the MAC payload segmentation in the		based on channel conditions, thus the MAC payload segmentation in the
	MAC sublayer is enabled and guarantees a reliable one-hop data		MAC sublayer is enabled and guarantees a reliable one-hop data
	transmission. Fragmentation and reassembly is still required at the		transmission. Fragmentation and reassembly is still required at the
	adaptation layer, if the MAC layer cannot support the minimum MTU		adaptation layer, if the MAC layer cannot support the minimum MTU
	demanded by IPv6, which is 1280 octets.		demanded by IPv6, which is 1280 octets.
	In IEEE 1901.1 and IEEE 1901.2, since the MAC layer supports payloads		In IEEE 1901.1 and IEEE 1901.2, the MAC layer supports payloads as
	of 2031 octets and 1576 octets respectively, fragmentation is not		big as 2031 octets and 1576 octets respectively. However when the
	needed for IPv6 packet transmission. The fragmentation and		channel condition is noisy, it is possible to configure smaller MTU
	reassembly defined in [RFC4944] SHOULD NOT be used in the 6lo		at the MAC layer. If the configured MTU is smaller than 1280
	adaptation layer of IEEE 1901.2.		octects, the fragmentation and reassembly defined in [RFC4944] MUST
			be used.
	In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets,		In ITU-T G.9903, the maximum MAC payload size is fixed to 400 octets,
	so to cope with the required MTU of 1280 octets by IPv6,		so to cope with the required MTU of 1280 octets by IPv6,
	fragmentation and reassembly at 6lo adaptation layer MUST be provided		fragmentation and reassembly at 6lo adaptation layer MUST be provided
	referring to [RFC4944].		referring to [RFC4944].
	5. Internet Connectivity Scenarios and Topologies		5. Internet Connectivity Scenarios and Topologies
	The network model can be simplified to two kinds of network devices:		The network model can be simplified to two kinds of network devices:
	PAN Coordinator (PANC) and PAN Device. The PANC is the primary		PAN Coordinator (PANC) and PAN Device. The PANC is the primary
	skipping to change at page 14, line 15 ¶		skipping to change at page 14, line 15 ¶
	PLC Device		PLC Device
	\ +---------		\ +---------
	PLC Device \ /		PLC Device \ /
	\ \ +		\ \ +
	\ \ |		\ \ |
	PLC Device -- PANC ===========+ Internet		PLC Device -- PANC ===========+ Internet
	/ / |		/ / |
	/ / +		/ / +
	PLC Device---PLC Device / \		PLC Device---PLC Device / \
	/ +---------		/ +---------
	PAN Device---PAN Device		PLC Device---PLC Device
	<------------------------->		<------------------------->
	PLC subnet (IPv6 over PLC)		PLC subnet (IPv6 over PLC)
	Figure 6: PLC Tree Network connected to the Internet		Figure 6: PLC Tree Network connected to the Internet
	Mesh networking in PLC is of great potential applications and has		Mesh networking in PLC is of great potential applications and has
	been studied for several years. By connecting all nodes with their		been studied for several years. By connecting all nodes with their
	neighbors in communication range (see Figure 7), mesh topology		neighbors in communication range (see Figure 7), mesh topology
	dramatically enhances the communication efficiency and thus expands		dramatically enhances the communication efficiency and thus expands
	skipping to change at page 15, line 21 ¶		skipping to change at page 15, line 21 ¶
	Due to the high accessibility of power grid, PLC might be susceptible		Due to the high accessibility of power grid, PLC might be susceptible
	to eavesdropping within its communication coverage, e.g., one		to eavesdropping within its communication coverage, e.g., one
	apartment tenant may have the chance to monitor the other smart		apartment tenant may have the chance to monitor the other smart
	meters in the same apartment building. For security consideration,		meters in the same apartment building. For security consideration,
	link layer security is guaranteed in every PLC technology.		link layer security is guaranteed in every PLC technology.
	Malicious PLC devices could paralyze the whole network via DOS		Malicious PLC devices could paralyze the whole network via DOS
	attacks, e.g., keep joining and leaving the network frequently, or		attacks, e.g., keep joining and leaving the network frequently, or
	multicast routing messages containing fake metrics. A device may		multicast routing messages containing fake metrics. A device may
	also join a wrong or even malicious network, exposing its data to		also join a wrong or even malicious network, exposing its data to
	illegal users. Thus it is highly recommended to conduct a mutual		illegal users. Mutual authentication of network and new device can
	authentication between the network and the device tending to join in		be conducted during the onboarding process of the new device.
	it. Pre-installed certificates can be transported over DTLS to		Methods include protocols such as [RFC7925] (exchanging pre-installed
	facilitate the authentication. Alternatively, as per		certificates over DTLS) , [I-D.ietf-6tisch-minimal-security] (which
	[I-D.ietf-6tisch-minimal-security], provisioning a unique pre-shared		uses pre-shared keys), and
	keys (PSKs) to each PLC device is also feasible. In both cases, if		[I-D.ietf-6tisch-dtsecurity-zerotouch-join] (which uses IDevID and
	the PLC device is not direct neighbor to the PANC/JRC, where the		MASA service). It is also possible to use EAP methods such as
	authenticate is conducted, another PLC device which has joined the		[I-D.ietf-emu-eap-noob] via transports like PANA [RFC5191]. No
	network can act as a proxy to help exchange the authentication		specific mechanism is specified by this document as an appropriate
	messages.		mechanism will depend upon deployment circumstances. The network
			encryption key appropriate for the layer-2 can also be acquired
			during the onboarding process.
	IP addresses may be used to track devices on the Internet; such		IP addresses may be used to track devices on the Internet; such
	devices can in turn be linked to individuals and their activities.		devices can in turn be linked to individuals and their activities.
	Depending on the application and the actual use pattern, this may be		Depending on the application and the actual use pattern, this may be
	undesirable. To impede tracking, globally unique and non-changing		undesirable. To impede tracking, globally unique and non-changing
	characteristics of IP addresses should be avoided, e.g., by		characteristics of IP addresses should be avoided, e.g., by
	frequently changing the global prefix and avoiding unique link-layer		frequently changing the global prefix and avoiding unique link-layer
	derived IIDs in addresses. [RFC3315], [RFC3972], [RFC4941],		derived IIDs in addresses. [RFC3315], [RFC3972], [RFC4941],
	[RFC5535], [RFC7217], and [RFC8065] provide valuable information for		[RFC5535], [RFC7217], and [RFC8065] provide valuable information for
	IID formation with improved privacy, and are RECOMMENDED for IPv6		IID formation with improved privacy, and are RECOMMENDED for IPv6
	networks.		networks.
	8. Acknowledgements		8. Acknowledgements
	We gratefully acknowledge suggestions from the members of the IETF		We gratefully acknowledge suggestions from the members of the IETF
	6lo working group. Great thanks to Samita Chakrabarti and Gabriel		6lo working group. Great thanks to Samita Chakrabarti and Gabriel
	Montenegro for their feedback and support in connecting the IEEE and		Montenegro for their feedback and support in connecting the IEEE and
	ITU-T sides. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney		ITU-T sides. Authors thank Scott Mansfield, Ralph Droms, Pat Kinney
	for their guidance in the liaison process. Authors wish to thank		for their guidance in the liaison process. Authors wish to thank
	Stefano Galli, Thierry Lys, Yizhou Li and Yuefeng Wu for their		Stefano Galli, Thierry Lys, Yizhou Li, Yuefeng Wu and Michael
	valuable comments and contributions.		Richardson for their valuable comments and contributions.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[IEEE_1901.1]		[IEEE_1901.1]
	IEEE-SA Standards Board, "Standard for Medium Frequency		IEEE-SA Standards Board, "Standard for Medium Frequency
	(less than 15 MHz) Power Line Communications for Smart		(less than 15 MHz) Power Line Communications for Smart
	Grid Applications", IEEE 1901.1, May 2018,		Grid Applications", IEEE 1901.1, May 2018,
	<https://ieeexplore.ieee.org/document/8360785>.		<https://ieeexplore.ieee.org/document/8360785>.
	skipping to change at page 17, line 30 ¶		skipping to change at page 17, line 35 ¶
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.		[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C.
	Perkins, "Registration Extensions for IPv6 over Low-Power		Perkins, "Registration Extensions for IPv6 over Low-Power
	Wireless Personal Area Network (6LoWPAN) Neighbor		Wireless Personal Area Network (6LoWPAN) Neighbor
	Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,		Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018,
	<https://www.rfc-editor.org/info/rfc8505>.		<https://www.rfc-editor.org/info/rfc8505>.
	9.2. Informative References		9.2. Informative References
			[I-D.ietf-6tisch-dtsecurity-zerotouch-join]
			Richardson, M., "6tisch Zero-Touch Secure Join protocol",
			draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in
			progress), July 2019.
	[I-D.ietf-6tisch-minimal-security]		[I-D.ietf-6tisch-minimal-security]
	Vucinic, M., Simon, J., Pister, K., and M. Richardson,		Vucinic, M., Simon, J., Pister, K., and M. Richardson,
	"Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf-		"Constrained Join Protocol (CoJP) for 6TiSCH", draft-ietf-
	6tisch-minimal-security-15 (work in progress), December		6tisch-minimal-security-15 (work in progress), December
	2019.		2019.
			[I-D.ietf-emu-eap-noob]
			Aura, T. and M. Sethi, "Nimble out-of-band authentication
			for EAP (EAP-NOOB)", draft-ietf-emu-eap-noob-01 (work in
			progress), June 2020.
	[I-D.ietf-roll-aodv-rpl]		[I-D.ietf-roll-aodv-rpl]
	Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B.		Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B.
	Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy		Liu, "AODV based RPL Extensions for Supporting Asymmetric
	Networks (LLNs)", draft-ietf-roll-aodv-rpl-07 (work in		P2P Links in Low-Power and Lossy Networks", draft-ietf-
	progress), April 2019.		roll-aodv-rpl-08 (work in progress), May 2020.
	[I-D.ietf-roll-unaware-leaves]		[I-D.ietf-roll-unaware-leaves]
	Thubert, P. and M. Richardson, "Routing for RPL Leaves",		Thubert, P. and M. Richardson, "Routing for RPL Leaves",
	draft-ietf-roll-unaware-leaves-15 (work in progress),		draft-ietf-roll-unaware-leaves-15 (work in progress),
	April 2020.		April 2020.
	[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]		[I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks]
	Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets		Popa, D. and J. Hui, "6LoPLC: Transmission of IPv6 Packets
	over IEEE 1901.2 Narrowband Powerline Communication		over IEEE 1901.2 Narrowband Powerline Communication
	Networks", draft-popa-6lo-6loplc-ipv6-over-		Networks", draft-popa-6lo-6loplc-ipv6-over-
	skipping to change at page 18, line 30 ¶		skipping to change at page 18, line 47 ¶
	[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing		[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
	Architecture", RFC 4291, DOI 10.17487/RFC4291, February		Architecture", RFC 4291, DOI 10.17487/RFC4291, February
	2006, <https://www.rfc-editor.org/info/rfc4291>.		2006, <https://www.rfc-editor.org/info/rfc4291>.
	[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy		[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
	Extensions for Stateless Address Autoconfiguration in		Extensions for Stateless Address Autoconfiguration in
	IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,		IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
	<https://www.rfc-editor.org/info/rfc4941>.		<https://www.rfc-editor.org/info/rfc4941>.
			[RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H.,
			and A. Yegin, "Protocol for Carrying Authentication for
			Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191,
			May 2008, <https://www.rfc-editor.org/info/rfc5191>.
	[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,		[RFC5535] Bagnulo, M., "Hash-Based Addresses (HBA)", RFC 5535,
	DOI 10.17487/RFC5535, June 2009,		DOI 10.17487/RFC5535, June 2009,
	<https://www.rfc-editor.org/info/rfc5535>.		<https://www.rfc-editor.org/info/rfc5535>.
	[RFC7217] Gont, F., "A Method for Generating Semantically Opaque		[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
	Interface Identifiers with IPv6 Stateless Address		Interface Identifiers with IPv6 Stateless Address
	Autoconfiguration (SLAAC)", RFC 7217,		Autoconfiguration (SLAAC)", RFC 7217,
	DOI 10.17487/RFC7217, April 2014,		DOI 10.17487/RFC7217, April 2014,
	<https://www.rfc-editor.org/info/rfc7217>.		<https://www.rfc-editor.org/info/rfc7217>.
			[RFC7925] Tschofenig, H., Ed. and T. Fossati, "Transport Layer
			Security (TLS) / Datagram Transport Layer Security (DTLS)
			Profiles for the Internet of Things", RFC 7925,
			DOI 10.17487/RFC7925, July 2016,
			<https://www.rfc-editor.org/info/rfc7925>.
	[RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability		[RFC8036] Cam-Winget, N., Ed., Hui, J., and D. Popa, "Applicability
	Statement for the Routing Protocol for Low-Power and Lossy		Statement for the Routing Protocol for Low-Power and Lossy
	Networks (RPL) in Advanced Metering Infrastructure (AMI)		Networks (RPL) in Advanced Metering Infrastructure (AMI)
	Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017,		Networks", RFC 8036, DOI 10.17487/RFC8036, January 2017,
	<https://www.rfc-editor.org/info/rfc8036>.		<https://www.rfc-editor.org/info/rfc8036>.
	[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,		[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu,
	"Recommendation on Stable IPv6 Interface Identifiers",		"Recommendation on Stable IPv6 Interface Identifiers",
	RFC 8064, DOI 10.17487/RFC8064, February 2017,		RFC 8064, DOI 10.17487/RFC8064, February 2017,
	<https://www.rfc-editor.org/info/rfc8064>.		<https://www.rfc-editor.org/info/rfc8064>.
End of changes. 17 change blocks.
	37 lines changed or deleted		60 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/