< draft-ietf-6lo-ap-nd-18.txt		draft-ietf-6lo-ap-nd-19.txt >
	6lo P. Thubert, Ed.		6lo P. Thubert, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Updates: 8505 (if approved) B. Sarikaya		Updates: 8505 (if approved) B. Sarikaya
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 8 August 2020 M. Sethi		Expires: 9 August 2020 M. Sethi
	Ericsson		Ericsson
	R. Struik		R. Struik
	Struik Security Consultancy		Struik Security Consultancy
	5 February 2020		6 February 2020
	Address Protected Neighbor Discovery for Low-power and Lossy Networks		Address Protected Neighbor Discovery for Low-power and Lossy Networks
	draft-ietf-6lo-ap-nd-18		draft-ietf-6lo-ap-nd-19
	Abstract		Abstract
	This document updates the 6LoWPAN Neighbor Discovery (ND) protocol		This document updates the 6LoWPAN Neighbor Discovery (ND) protocol
	defined in RFC 6775 and RFC 8505. The new extension is called		defined in RFC 6775 and RFC 8505. The new extension is called
	Address Protected Neighbor Discovery (AP-ND) and it protects the		Address Protected Neighbor Discovery (AP-ND) and it protects the
	owner of an address against address theft and impersonation attacks		owner of an address against address theft and impersonation attacks
	in a low-power and lossy network (LLN). Nodes supporting this		in a low-power and lossy network (LLN). Nodes supporting this
	extension compute a cryptographic identifier (Crypto-ID) and use it		extension compute a cryptographic identifier (Crypto-ID) and use it
	with one or more of their Registered Addresses. The Crypto-ID		with one or more of their Registered Addresses. The Crypto-ID
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 8 August 2020.		This Internet-Draft will expire on 9 August 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 (https://trustee.ietf.org/		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	license-info) in effect on the date of publication of this document.		license-info) in effect on the date of publication of this document.
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 49 ¶		skipping to change at page 2, line 49 ¶
	7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 18		7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 18
	7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 18		7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 18
	7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 19		7.4. Implementation Attacks . . . . . . . . . . . . . . . . . 19
	7.5. Cross-Algorithm and Cross-Protocol Attacks . . . . . . . 19		7.5. Cross-Algorithm and Cross-Protocol Attacks . . . . . . . 19
	7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 19		7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 19
	7.7. Correlating Registrations . . . . . . . . . . . . . . . . 20		7.7. Correlating Registrations . . . . . . . . . . . . . . . . 20
	8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20		8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20
	8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 20		8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 20
	8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 20		8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 20
	8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 21		8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 21
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
	10. Normative References . . . . . . . . . . . . . . . . . . . . 22		10. Normative References . . . . . . . . . . . . . . . . . . . . 22
	11. Informative references . . . . . . . . . . . . . . . . . . . 23		11. Informative references . . . . . . . . . . . . . . . . . . . 23
	Appendix A. Requirements Addressed in this Document . . . . . . 25		Appendix A. Requirements Addressed in this Document . . . . . . 25
	Appendix B. Representation Conventions . . . . . . . . . . . . . 25		Appendix B. Representation Conventions . . . . . . . . . . . . . 25
	B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 25		B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 25
	B.2. Integer Representation for ECDSA signatures . . . . . . . 26		B.2. Integer Representation for ECDSA signatures . . . . . . . 26
	B.3. Alternative Representations of Curve25519 . . . . . . . . 26		B.3. Alternative Representations of Curve25519 . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
	1. Introduction		1. Introduction
	Neighbor Discovery Optimizations for 6LoWPAN networks [RFC6775]		Neighbor Discovery Optimizations for 6LoWPAN networks [RFC6775]
	(6LoWPAN ND) adapts the original IPv6 Neighbor Discovery (IPv6 ND)		(6LoWPAN ND) adapts the original IPv6 Neighbor Discovery (IPv6 ND)
	protocols defined in [RFC4861] and [RFC4862] for constrained low-		protocols defined in [RFC4861] and [RFC4862] for constrained low-
	power and lossy network (LLN). In particular, 6LoWPAN ND introduces		power and lossy network (LLN). In particular, 6LoWPAN ND introduces
	a unicast host Address Registration mechanism that reduces the use of		a unicast host Address Registration mechanism that reduces the use of
	multicast compared to the Duplicate Address Detection (DAD) mechanism		multicast compared to the Duplicate Address Detection (DAD) mechanism
	skipping to change at page 5, line 23 ¶		skipping to change at page 5, line 23 ¶
	* "Neighbor Discovery for IP version 6" [RFC4861] ,		* "Neighbor Discovery for IP version 6" [RFC4861] ,
	* "IPv6 Stateless Address Autoconfiguration" [RFC4862], and		* "IPv6 Stateless Address Autoconfiguration" [RFC4862], and
	* "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):		* "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs):
	Overview, Assumptions, Problem Statement, and Goals " [RFC4919].		Overview, Assumptions, Problem Statement, and Goals " [RFC4919].
	3. Updating RFC 8505		3. Updating RFC 8505
	Section 5.3 of [RFC8505] introduces the ROVR as a generic object that		Section 5.3 of [RFC8505] introduces the ROVR that is used to detect
	is designed for backward compatibility with the capability to		and reject duplicate registrations in the DAD process. The ROVR is a
	introduce new computation methods in the future. Section 7.3		generic object that is designed for backward compatibility with the
	discusses collisions when heterogeneous methods to compute the ROVR		capability to introduce new computation methods in the future. Using
	field coexist inside a same network. [RFC8505] was designed in		a Crypto-ID per this specification is the RECOMMENDED method.
	preparation for this specification, which is the RECOMMENDED method		Section 7.3 discusses collisions when heterogeneous methods to
	for building a ROVR field.		compute the ROVR field coexist inside a same network.
	This specification introduces a new token called a cryptographic		This specification introduces a new token called a cryptographic
	identifier (Crypto-ID) that is transported in the ROVR field and used		identifier (Crypto-ID) that is transported in the ROVR field and used
	to prove indirectly the ownership of an address that is being		to prove indirectly the ownership of an address that is being
	registered by means of [RFC8505]. The Crypto-ID is derived from a		registered by means of [RFC8505]. The Crypto-ID is derived from a
	cryptographic public key and additional parameters.		cryptographic public key and additional parameters.
	The overall mechanism requires the support of Elliptic Curve		The overall mechanism requires the support of Elliptic Curve
	Cryptography (ECC) and of a hash function as detailed in Section 6.2.		Cryptography (ECC) and of a hash function as detailed in Section 6.2.
	To enable the verification of the proof, the registering node needs		To enable the verification of the proof, the registering node needs
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 13 ¶
	is modified to enable a challenge and transport a Nonce option.		is modified to enable a challenge and transport a Nonce option.
	4. New Fields and Options		4. New Fields and Options
	4.1. New Crypto-ID		4.1. New Crypto-ID
	The Crypto-ID is transported in the ROVR field of the EARO option and		The Crypto-ID is transported in the ROVR field of the EARO option and
	the EDAR message, and is associated with the Registered Address at		the EDAR message, and is associated with the Registered Address at
	the 6LR and the 6LBR. The ownership of a Crypto-ID can be		the 6LR and the 6LBR. The ownership of a Crypto-ID can be
	demonstrated by cryptographic mechanisms, and by association, the		demonstrated by cryptographic mechanisms, and by association, the
	ownership of the Registered Address can be acertained.		ownership of the Registered Address can be ascertained.
	A node in possession of the necessary cryptographic primitives SHOULD		A node in possession of the necessary cryptographic primitives SHOULD
	use Crypto-ID by default as ROVR in its registrations. Whether a		use Crypto-ID by default as ROVR in its registrations. Whether a
	ROVR is a Crypto-ID is indicated by a new "C" flag in the NS(EARO)		ROVR is a Crypto-ID is indicated by a new "C" flag in the NS(EARO)
	message.		message.
	The Crypto-ID is derived from the public key and a modifier as		The Crypto-ID is derived from the public key and a modifier as
	follows:		follows:
	1. The hash function indicated by the Crypto-Type is applied to the		1. The hash function indicated by the Crypto-Type is applied to the
	skipping to change at page 7, line 37 ¶		skipping to change at page 7, line 37 ¶
	This specification uses Status values "Validation Requested" and		This specification uses Status values "Validation Requested" and
	"Validation Failed", which are defined in [RFC8505].		"Validation Failed", which are defined in [RFC8505].
	this specification does not define any new Status value.		this specification does not define any new Status value.
	4.3. Crypto-ID Parameters Option		4.3. Crypto-ID Parameters Option
	This specification defines the Crypto-ID Parameters Option (CIPO).		This specification defines the Crypto-ID Parameters Option (CIPO).
	The CIPO carries the parameters used to form a Crypto-ID.		The CIPO carries the parameters used to form a Crypto-ID.
	In order to provide cryptographic agility [RFC7696], this		In order to provide cryptographic agility [BCP 201], this
	specification supports different elliptic curves, indicated by a		specification supports different elliptic curves, indicated by a
	Crypto-Type field:		Crypto-Type field:
	* NIST P-256 [FIPS186-4] MUST be supported by all implementations.		* NIST P-256 [FIPS186-4] MUST be supported by all implementations.
	* The Edwards-Curve Digital Signature Algorithm (EdDSA) curve		* The Edwards-Curve Digital Signature Algorithm (EdDSA) curve
	Ed25519 (PureEdDSA) [RFC8032] MAY be supported as an alternative.		Ed25519 (PureEdDSA) [RFC8032] MAY be supported as an alternative.
	* This specification uses signature schemes that target similar		* This specification uses signature schemes that target similar
	cryptographic strength but rely on different curves, hash		cryptographic strength but rely on different curves, hash
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 37 ¶
	Length: 8-bit unsigned integer. The length of the option in units		Length: 8-bit unsigned integer. The length of the option in units
	of 8 octets.		of 8 octets.
	Reserved1: 5-bit unsigned integer. It MUST be set to zero by the		Reserved1: 5-bit unsigned integer. It MUST be set to zero by the
	sender and MUST be ignored by the receiver.		sender and MUST be ignored by the receiver.
	Public Key Length: 11-bit unsigned integer. The length of the		Public Key Length: 11-bit unsigned integer. The length of the
	Public Key field in bytes.		Public Key field in bytes.
	Crypto-Type: 8-bit unsigned integer. The type of cryptographic		Crypto-Type: 8-bit unsigned integer. The type of cryptographic
	algorithm used in calculation Crypto-ID (see Table 2 in		algorithm used in calculation Crypto-ID indexed by IANA in the
	Section 8.3).		"Crypto-Type Subregistry" in the "Internet Control Message
			Protocol version 6 (ICMPv6) Parameters" (see Section 8.3).
	Modifier: 8-bit unsigned integer. Set to an arbitrary value by the		Modifier: 8-bit unsigned integer. Set to an arbitrary value by the
	creator of the Crypto-ID. The role of the modifier is to enable		creator of the Crypto-ID. The role of the modifier is to enable
	the formation of multiple Crypto-IDs from a same key pair, which		the formation of multiple Crypto-IDs from a same key pair, which
	reduces the traceability and thus improves the privacy of a		reduces the traceability and thus improves the privacy of a
	constrained node that could not maintain many key-pairs.		constrained node that could not maintain many key-pairs.
	EARO Length: 8-bit unsigned integer. The option length of the EARO		EARO Length: 8-bit unsigned integer. The option length of the EARO
	that contains the Crypto-ID associated with the CIPO.		that contains the Crypto-ID associated with the CIPO.
	skipping to change at page 10, line 40 ¶		skipping to change at page 10, line 40 ¶
	Reserved1: 5-bit unsigned integer. It MUST be set to zero by the		Reserved1: 5-bit unsigned integer. It MUST be set to zero by the
	sender and MUST be ignored by the receiver.		sender and MUST be ignored by the receiver.
	Digital Signature Length: 11-bit unsigned integer. The length of		Digital Signature Length: 11-bit unsigned integer. The length of
	the Digital Signature field in bytes.		the Digital Signature field in bytes.
	Reserved2: 32-bit unsigned integer. It MUST be set to zero by the		Reserved2: 32-bit unsigned integer. It MUST be set to zero by the
	sender and MUST be ignored by the receiver.		sender and MUST be ignored by the receiver.
	Digital Signature: A variable-length field containing a digital		Digital Signature: A variable-length field containing a digital
	signature. The computation of the digital signature depends on		signature. The length and computation of the digital signature
	the Crypto-Type which is found in the associated CIPO. For the		both depend on the Crypto-Type which is found in the associated
	values of the Crypto-Type that are defined in this specification,		CIPO. For the values of the Crypto-Type that are defined in this
	and unless specified otherwise for a future value of the Crypto-		specification, and unless specified otherwise for a future value
	Type, the signature is computed as detailed in Section 6.2.		of the Crypto-Type, the signature is computed as detailed in
			Section 6.2.
	Padding: A variable-length field completing the Digital Signature		Padding: A variable-length field completing the Digital Signature
	field to align to the next 8-bytes boundary. It MUST be set to		field to align to the next 8-bytes boundary. It MUST be set to
	zero by the sender and MUST be ignored by the receiver.		zero by the sender and MUST be ignored by the receiver.
	5. Protocol Scope		5. Protocol Scope
	The scope of the protocol specified here is a 6LoWPAN LLN, typically		The scope of the protocol specified here is a 6LoWPAN LLN, typically
	a stub network connected to a larger IP network via a Border Router		a stub network connected to a larger IP network via a Border Router
	called a 6LBR per [RFC6775]. A 6LBR has sufficient capability to		called a 6LBR per [RFC6775]. A 6LBR has sufficient capability to
	skipping to change at page 12, line 45 ¶		skipping to change at page 12, line 45 ¶
	not have a state with the 6LN that is consistent with the NS(EARO),		not have a state with the 6LN that is consistent with the NS(EARO),
	then it replies with a challenge NA (EARO, status=Validation		then it replies with a challenge NA (EARO, status=Validation
	Requested) that contains a Nonce Option (shown as NonceLR in		Requested) that contains a Nonce Option (shown as NonceLR in
	Figure 5).		Figure 5).
	The Nonce option contains a nonce value that, to the extent possible		The Nonce option contains a nonce value that, to the extent possible
	for the implementation, was never employed in association with the		for the implementation, was never employed in association with the
	key pair used to generate the Crypto-ID. This specification inherits		key pair used to generate the Crypto-ID. This specification inherits
	from [RFC3971] that simply indicates that the nonce is a random		from [RFC3971] that simply indicates that the nonce is a random
	value. Ideally, an implementation uses an unpredictable		value. Ideally, an implementation uses an unpredictable
	cryptographically random value [RFC4086]. But that may be		cryptographically random value [BCP 106]. But that may be
	impractical in some LLN scenarios where the devices do not have a		impractical in some LLN scenarios where the devices do not have a
	guaranteed sense of time and for which computing complex hashes is		guaranteed sense of time and for which computing complex hashes is
	detrimental to the battery lifetime. Alternatively, the device may		detrimental to the battery lifetime. Alternatively, the device may
	use an always-incrementing value saved in the same stable storage as		use an always-incrementing value saved in the same stable storage as
	the key, so they are lost together, and starting at a best effort		the key, so they are lost together, and starting at a best effort
	random value, either as the nonce value or as a component to its		random value, either as the nonce value or as a component to its
	computation.		computation.
	The 6LN replies to the challenge with an NS(EARO) that includes a new		The 6LN replies to the challenge with an NS(EARO) that includes a new
	Nonce option (shown as NonceLN in Figure 5), the CIPO (Section 4.3),		Nonce option (shown as NonceLN in Figure 5), the CIPO (Section 4.3),
	skipping to change at page 20, line 22 ¶		skipping to change at page 20, line 22 ¶
	address being registered are decoupled. A 6LN may use a same ROVR		address being registered are decoupled. A 6LN may use a same ROVR
	for multiple registrations or a different ROVR per registration, and		for multiple registrations or a different ROVR per registration, and
	the IID must not derive from the ROVR. In theory different 6LNs		the IID must not derive from the ROVR. In theory different 6LNs
	could use a same ROVR as long as they do not attempt to register the		could use a same ROVR as long as they do not attempt to register the
	same address.		same address.
	The Modifier used in the computation of the Crypto-ID enables a 6LN		The Modifier used in the computation of the Crypto-ID enables a 6LN
	to build different Crypto-IDs for different addresses with a same		to build different Crypto-IDs for different addresses with a same
	keypair. Using that facility improves the privacy of the 6LN as the		keypair. Using that facility improves the privacy of the 6LN as the
	expense of storage in the 6LR, which will need to store multiple		expense of storage in the 6LR, which will need to store multiple
	CIPOs that contain the same private key. Note that if the attacker		CIPOs that contain the same public key. Note that if the attacker is
	is the 6LR, then the Modifier alone does not provide a protection,		the 6LR, then the Modifier alone does not provide a protection, and
	and the 6LN would need to use different keys and MAC addresses in an		the 6LN would need to use different keys and MAC addresses in an
	attempt to obfuscate its multiple ownership.		attempt to obfuscate its multiple ownership.
	8. IANA considerations		8. IANA considerations
	8.1. CGA Message Type		8.1. CGA Message Type
	This document defines a new 128-bit value under the CGA Message Type		This document defines a new 128-bit value under the CGA Message Type
	[RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0.		[RFC3972] name space: 0x8701 55c8 0cca dd32 6ab7 e415 f148 84d0.
	8.2. IPv6 ND option types		8.2. IPv6 ND option types
	skipping to change at page 21, line 43 ¶		skipping to change at page 21, line 43 ¶
	| specification | | | |		| specification | | | |
	+----------------+---------------+---------------+---------------+		+----------------+---------------+---------------+---------------+
	Table 2: Crypto-Types		Table 2: Crypto-Types
	New Crypto-Type values providing similar or better security may be		New Crypto-Type values providing similar or better security may be
	defined in the future.		defined in the future.
	Assignment of new values for new Crypto-Type MUST be done through		Assignment of new values for new Crypto-Type MUST be done through
	IANA with either "Specification Required" or "IESG Approval" as		IANA with either "Specification Required" or "IESG Approval" as
	defined in [RFC8126].		defined in BCP 26 [RFC8126].
			The "Defining specification" column indicates the document that
			defines the length and computation of the digital signature, which
			could be this for values defined through "IESG Approval".
	9. Acknowledgments		9. Acknowledgments
	Many thanks to Charlie Perkins for his in-depth review and		Many thanks to Charlie Perkins for his in-depth review and
	constructive suggestions. The authors are also especially grateful		constructive suggestions. The authors are also especially grateful
	to Robert Moskowitz for his comments that led to many improvements.		to Robert Moskowitz and Benjamin Kaduk for their comments and
	The authors wish to thank Benjamin Kaduk, Mirja Kuhlewind, Eric		discussions that led to many improvements. The authors wish to also
	Vyncke, Vijay Gurbani, Al Morton and Adam Montville for their		thank Roman Danyliw, Alissa Cooper, Mirja Kuhlewind, Eric Vyncke,
	constructive reviews during the IESG process.		Vijay Gurbani, Al Morton and Adam Montville for their constructive
			reviews during the IESG process.
	10. Normative References		10. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.		[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
	Bormann, "Neighbor Discovery Optimization for IPv6 over		Bormann, "Neighbor Discovery Optimization for IPv6 over
	skipping to change at page 23, line 43 ¶		skipping to change at page 24, line 5 ¶
	Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,		Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
	DOI 10.17487/RFC6282, September 2011,		DOI 10.17487/RFC6282, September 2011,
	<https://www.rfc-editor.org/info/rfc6282>.		<https://www.rfc-editor.org/info/rfc6282>.
	[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6		[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6
	over Low-Power Wireless Personal Area Networks (6LoWPANs):		over Low-Power Wireless Personal Area Networks (6LoWPANs):
	Overview, Assumptions, Problem Statement, and Goals",		Overview, Assumptions, Problem Statement, and Goals",
	RFC 4919, DOI 10.17487/RFC4919, August 2007,		RFC 4919, DOI 10.17487/RFC4919, August 2007,
	<https://www.rfc-editor.org/info/rfc4919>.		<https://www.rfc-editor.org/info/rfc4919>.
	[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,		[BCP 106] Eastlake 3rd, D., Schiller, J., and S. Crocker,
	"Randomness Requirements for Security", BCP 106, RFC 4086,		"Randomness Requirements for Security", BCP 106, RFC 4086,
	DOI 10.17487/RFC4086, June 2005,		DOI 10.17487/RFC4086, June 2005,
	<https://www.rfc-editor.org/info/rfc4086>.		<https://www.rfc-editor.org/info/rfc4086>.
	[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for		[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
	Writing an IANA Considerations Section in RFCs", BCP 26,		Writing an IANA Considerations Section in RFCs", BCP 26,
	RFC 8126, DOI 10.17487/RFC8126, June 2017,		RFC 8126, DOI 10.17487/RFC8126, June 2017,
	<https://www.rfc-editor.org/info/rfc8126>.		<https://www.rfc-editor.org/info/rfc8126>.
	[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,		[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
	"Source Address Validation Improvement (SAVI) Framework",		"Source Address Validation Improvement (SAVI) Framework",
	RFC 7039, DOI 10.17487/RFC7039, October 2013,		RFC 7039, DOI 10.17487/RFC7039, October 2013,
	<https://www.rfc-editor.org/info/rfc7039>.		<https://www.rfc-editor.org/info/rfc7039>.
	[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>.
	[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm		[BCP 201] Housley, R., "Guidelines for Cryptographic Algorithm
	Agility and Selecting Mandatory-to-Implement Algorithms",		Agility and Selecting Mandatory-to-Implement Algorithms",
	BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,		BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
	<https://www.rfc-editor.org/info/rfc7696>.		<https://www.rfc-editor.org/info/rfc7696>.
	[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>.
	[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-		[RFC8065] Thaler, D., "Privacy Considerations for IPv6 Adaptation-
End of changes. 17 change blocks.
	33 lines changed or deleted		40 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/