< draft-ietf-6lo-ap-nd-16.txt		draft-ietf-6lo-ap-nd-17.txt >
	6lo P. Thubert, Ed.		6lo P. Thubert, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Updates: 8505 (if approved) B.S. Sarikaya		Updates: 8505 (if approved) B.S. Sarikaya
	Intended status: Standards Track		Intended status: Standards Track
	Expires: 6 August 2020 M.S. Sethi		Expires: 7 August 2020 M.S. Sethi
	Ericsson		Ericsson
	R.S. Struik		R.S. Struik
	Struik Security Consultancy		Struik Security Consultancy
	3 February 2020		4 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-16		draft-ietf-6lo-ap-nd-17
	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 6 August 2020.		This Internet-Draft will expire on 7 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 4, line 15 ¶		skipping to change at page 4, line 15 ¶
	The protected address registration protocol proposed in this document		The protected address registration protocol proposed in this document
	provides the same conceptual benefit as Source Address Validation		provides the same conceptual benefit as Source Address Validation
	(SAVI) [RFC7039] that only the owner of an IPv6 address may source		(SAVI) [RFC7039] that only the owner of an IPv6 address may source
	packets with that address. As opposed to [RFC7039], which relies on		packets with that address. As opposed to [RFC7039], which relies on
	snooping protocols, the protection is based on a state that is		snooping protocols, the protection is based on a state that is
	installed and maintained in the network by the owner of the address.		installed and maintained in the network by the owner of the address.
	With this specification, a 6LN may use a 6LR for forwarding an IPv6		With this specification, a 6LN may use a 6LR for forwarding an IPv6
	packets if and only if it has registered the address used as source		packets if and only if it has registered the address used as source
	of the packet with that 6LR.		of the packet with that 6LR.
	The 6lo adaptation layer in [RFC4944] and [RFC6282] requires a device		With the 6lo adaptation layer in [RFC4944] and [RFC6282], a 6LN can
	to form its IPv6 addresses based on its Layer-2 address to enable a		obtain a better compression for an IPv6 address with an Interface ID
	better compression. As a side note, this is incompatible with Secure		(IID) that is derived from a Layer-2 address. As a side note, this
	Neighbor Discovery (SeND) [RFC3971] and Cryptographically Generated		is incompatible with Secure Neighbor Discovery (SeND) [RFC3971] and
	Addresses (CGAs) [RFC3972], since they derive the Interface ID (IID)		Cryptographically Generated Addresses (CGAs) [RFC3972], since they
	in IPv6 addresses from cryptographic keys.		derive the IID from cryptographic keys, whereas this specification
			separates the IID and the key material.
	2. Terminology		2. Terminology
	2.1. BCP 14		2.1. BCP 14
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	skipping to change at page 4, line 45 ¶		skipping to change at page 4, line 46 ¶
	6BBR: 6LoWPAN Backbone Router		6BBR: 6LoWPAN Backbone Router
	6LBR: 6LoWPAN Border Router		6LBR: 6LoWPAN Border Router
	6LN: 6LoWPAN Node		6LN: 6LoWPAN Node
	6LR: 6LoWPAN Router		6LR: 6LoWPAN Router
	EARO: Extended Address Registration Option		EARO: Extended Address Registration Option
	CIPO: Crypto-ID Parameters Option		CIPO: Crypto-ID Parameters Option
	LLN: Low-Power and Lossy Network		LLN: Low-Power and Lossy Network
	NA: Neighbor Advertisement		NA: Neighbor Advertisement
	ND: Neighbor Discovery		ND: Neighbor Discovery
	NDP: Neighbor Discovery Protocol		NDPSO: Neighbor Discovery Protocol Signature Option
	NDPSO: NDP Signature Option
	NS: Neighbor Solicitation		NS: Neighbor Solicitation
	ROVR: Registration Ownership Verifier		ROVR: Registration Ownership Verifier
	RA: Router Advertisement		RA: Router Advertisement
	RS: Router Solicitation		RS: Router Solicitation
	RSAO: RSA Signature Option		RSAO: RSA Signature Option
	TID: Transaction ID		TID: Transaction ID
	2.3. Additional References		2.3. Additional References
	The reader may get additional context for this specification from the		The reader may get additional context for this specification from the
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 27 ¶
	* "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 as a generic object that
	is designed for backward compatibility with the capability to		is designed for backward compatibility with the capability to
	introduce new computation methods in the future. Section 7.3		introduce new computation methods in the future. Section 7.3
	discusses collisions when heterogeneous methods to compute the ROVR		discusses collisions when heterogeneous methods to compute the ROVR
	field coexist inside a same network.		field coexist inside a same network. [RFC8505] was designed in
			preparation for this specification, which is the RECOMMENDED method
	[RFC8505] was designed in preparation for this specification, which		for building a ROVR field.
	is the RECOMMENDED method for building a ROVR field.
	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
	to supply certain parameters including a Nonce and a signature that		to supply certain parameters including a nonce and a signature that
	will demonstrate that the node possesses the private-key		will demonstrate that the node possesses the private-key
	corresponding to the public-key used to build the Crypto-ID.		corresponding to the public-key used to build the Crypto-ID.
	The elliptic curves and the hash functions that can be used with this		The elliptic curves and the hash functions listed in Table 2 in
	specification are listed in Table 2 in Section 8.3. The signature		Section 8.3 can be used with this specification; more may be added in
	scheme that specifies which combination is used is signaled by a		the future to the IANA registry. The signature scheme that specifies
	Crypto-Type (values to be confirmed by IANA) in a new IPv6 ND Crypto-		which combination is used (including the curve and the representation
	ID Parameters Option (CIPO, see Section 4.3) that contains the		conventions) is signaled by a Crypto-Type in a new IPv6 ND Crypto-ID
			Parameters Option (CIPO, see Section 4.3) that contains the
	parameters that are necessary for the proof, a Nonce option		parameters that are necessary for the proof, a Nonce option
	([RFC3971]) and a NDP Signature option (Section 4.4). The NA(EARO)		([RFC3971]) and a NDP Signature option (Section 4.4). The NA(EARO)
	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
	skipping to change at page 6, line 30 ¶		skipping to change at page 6, line 30 ¶
	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
	CIPO. Note that all the reserved and padding bits MUST be set to		CIPO. Note that all the reserved and padding bits MUST be set to
	zero.		zero.
	2. The leftmost bits of the resulting hash, up to the desired size,		2. The leftmost bits of the resulting hash, up to the desired size,
	are used as the Crypto-ID.		are used as the Crypto-ID.
	At the time of this writing, a minimal size for the Crypto-ID of 128		At the time of this writing, a minimal size for the Crypto-ID of 128
	bits is RECOMMENDED. This value is bound to augment in the future.		bits is RECOMMENDED unless backward compatibility is needed
			[RFC8505]. This value is bound to augment in the future.
	4.2. Updated EARO		4.2. Updated EARO
	This specification updates the EARO option to enable the use of the		This specification updates the EARO option to enable the use of the
	ROVR field to transport the Crypto-ID.		ROVR field to transport the Crypto-ID. The resulting format is as
			follows:
	The resulting format is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length | Status | Opaque |		| Type | Length | Status | Opaque |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|Rsvd |C| I |R|T| TID | Registration Lifetime |		|Rsvd |C| I |R|T| TID | Registration Lifetime |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	... Registration Ownership Verifier (ROVR) ...		... Registration Ownership Verifier (ROVR) ...
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1: Enhanced Address Registration Option		Figure 1: Enhanced Address Registration Option
	Type: 33		Type: 33
	Length: Defined in [RFC8505].		Length: Defined in [RFC8505] and copied in associated CIPO.
	Status: Defined in [RFC8505].		Status: Defined in [RFC8505].
	Opaque: Defined in [RFC8505].		Opaque: Defined in [RFC8505].
	Rsvd (Reserved): 3-bit unsigned integer. It MUST be set to zero by		Rsvd (Reserved): 3-bit unsigned integer. It MUST be set to zero by
	the sender and MUST be ignored by the receiver.		the sender and MUST be ignored by the receiver.
	C: This "C" flag is set to indicate that the ROVR field contains a		C: This "C" flag is set to indicate that the ROVR field contains a
	Crypto-ID and that the 6LN MAY be challenged for ownership as		Crypto-ID and that the 6LN MAY be challenged for ownership as
	skipping to change at page 8, line 10 ¶		skipping to change at page 8, line 10 ¶
	functions, signature algorithms, and/or representation		functions, signature algorithms, and/or representation
	conventions. Future specification may extend this for different		conventions. Future specification may extend this for different
	cryptographic algorithms and longer keys, e.g., to provide a		cryptographic algorithms and longer keys, e.g., to provide a
	better security properties or a simpler implementation.		better security properties or a simpler implementation.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |Reserved1| Public Key Length |		| Type | Length |Reserved1| Public Key Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Crypto-Type | Modifier | Reserved2 |		| Crypto-Type | Modifier | EARO Length | Reserved2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| |
	. .		. .
	. Public Key (variable length) .		. Public Key (variable length) .
	. .		. .
	| |		| |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .
	. Padding .		. Padding .
	. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2: Crypto-ID Parameters Option		Figure 2: Crypto-ID Parameters Option
	Type: 8-bit unsigned integer. to be assigned by IANA, see Table 1.		Type: 8-bit unsigned integer. to be assigned by IANA, see Table 1.
	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.
	skipping to change at page 8, line 50 ¶		skipping to change at page 8, line 46 ¶
	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 (see Table 2 in
	Section 8.3).		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
			that contains the Crypto-ID associated with the CIPO.
	Reserved2: 16-bit unsigned integer. It MUST be set to zero by the		Reserved2: 16-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: A variable-length field, size indicated in the Public		Public Key: A variable-length field, size indicated in the Public
	Key Length field. JWK-Encoded Public Key [RFC7517].		Key Length field. JWK-Encoded Public Key [RFC7517].
	Padding: A variable-length field completing the Public Key field to		Padding: A variable-length field completing the Public Key field to
	align to the next 8-bytes boundary. It MUST be set to zero by the		align to the next 8-bytes boundary. It MUST be set to zero by the
	sender and MUST be ignored by the receiver.		sender and MUST be ignored by the receiver.
	skipping to change at page 9, line 23 ¶		skipping to change at page 9, line 23 ¶
	devices may consume excessive amounts of program memory. This		devices may consume excessive amounts of program memory. This
	specification enables the use of SHA-256 [RFC6234] for all the		specification enables the use of SHA-256 [RFC6234] for all the
	supported ECC curves.		supported ECC curves.
	Some code factorization is also possible for the ECC computation		Some code factorization is also possible for the ECC computation
	itself. [CURVE-REPRESENTATIONS] provides information on how to		itself. [CURVE-REPRESENTATIONS] provides information on how to
	represent Montgomery curves and (twisted) Edwards curves as curves in		represent Montgomery curves and (twisted) Edwards curves as curves in
	short-Weierstrass form and illustrates how this can be used to		short-Weierstrass form and illustrates how this can be used to
	implement elliptic curve computations using existing implementations		implement elliptic curve computations using existing implementations
	that already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4]		that already provide, e.g., ECDSA and ECDH using NIST [FIPS186-4]
	prime curves.		prime curves. For more details on representation conventions, we
			refer to Appendix B.
	For more details on representation conventions, we refer to
	Appendix B.
	4.4. NDP Signature Option		4.4. NDP Signature Option
	This specification defines the NDP Signature Option (NDPSO). The		This specification defines the NDP Signature Option (NDPSO). The
	NDPSO carries the signature that proves the ownership of the Crypto-		NDPSO carries the signature that proves the ownership of the Crypto-
	ID.		ID. The format of the NDPSO is illustrated in Figure 3.
	The format of the NDP Signature Option (NDPSO) is illustrated in
	Figure 3.
	As opposed to the RSA Signature Option (RSAO) defined in section 5.2.		As opposed to the RSA Signature Option (RSAO) defined in section 5.2.
	of SEND [RFC3971], the NDPSO does not have a key hash field.		of SEND [RFC3971], the NDPSO does not have a key hash field.
	Instead, the leftmost 128 bits of the ROVR field in the EARO are used		Instead, the leftmost 128 bits of the ROVR field in the EARO are used
	to retrieve the CIPO that contains the key material used for		to retrieve the CIPO that contains the key material used for
	signature verification, left-padded if needed.		signature verification, left-padded if needed.
	Another difference is that the NDPSO signs a fixed set of fields as		Another difference is that the NDPSO signs a fixed set of fields as
	opposed to all options that appear prior to it in the that bears the		opposed to all options that appear prior to it in the ND message that
	signature. This allows to elide a CIPO that the 6LR already		bears the signature. This allows to elide a CIPO that the 6LR
	received, at the expense of the capability to add arbitrary options		already received, at the expense of the capability to add arbitrary
	that would signed with a RSAO.		options that would signed with a RSAO.
	The CIPO may be present in the same message as the NDPSO. If not, it		An ND message that carries an NDPSO MUST have one and only one EARO.
	can be found in an abstract table that was created by a previous		The EARO MUST contain a Crypto-ID in the ROVR field, and the Crypto-
	message and indexed by the hash.		ID MUST be associated with the keypair used for the Digital Signature
			in the NDPSO.
			The CIPO may be present in the same message as the NDPSO. If it is
			not present, it can be found in an abstract table that was created by
			a previous message and indexed by the hash.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Type | Length |Reserved1| Signature Length |		| Type | Length |Reserved1| Signature Length |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Reserved2 |		| Reserved2 |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	| |
	. .		. .
	. Digital Signature .		. Digital Signature (variable length) .
	. .		. .
	| |		| |
	| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| |		| |
	. .
	. Padding .		. Padding .
	. .
	| |		| |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: NDP signature Option		Figure 3: NDP signature Option
	Type: to be assigned by IANA, see Table 1.		Type: to be assigned by IANA, see Table 1.
	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.
	skipping to change at page 10, line 47 ¶		skipping to change at page 10, line 43 ¶
	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 computation of the digital signature depends on
	the Crypto-Type which is found in the associated CIPO. For the		the Crypto-Type which is found in the associated CIPO. For the
	values of the Crypto-Type that are defined in this specification,		values of the Crypto-Type that are defined in this specification,
	the signature is computed as detailed in Section 6.2.		and unless specified otherwise for a future value 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 22 ¶		skipping to change at page 12, line 22 ¶
	attract its traffic, or use it as source address.		attract its traffic, or use it as source address.
	The challenge can also triggered by the 6LBR, e.g., to enforce a		The challenge can also triggered by the 6LBR, e.g., to enforce a
	global policy. In that case, the 6LBR returns a status of		global policy. In that case, the 6LBR returns a status of
	"Validation Requested" in the DAR/DAC exchange, which is echoed by		"Validation Requested" in the DAR/DAC exchange, which is echoed by
	the 6LR in the NA (EARO) back to the registering node. A valid		the 6LR in the NA (EARO) back to the registering node. A valid
	registration in the 6LR or the 6LBR MUST NOT be altered until the		registration in the 6LR or the 6LBR MUST NOT be altered until the
	challenge is complete.		challenge is complete.
	A node may use more than one IPv6 address at the same time. The		A node may use more than one IPv6 address at the same time. The
	separation of the address and the cryptographic material avoids		separation of the address and the cryptographic material avoids the
	avoids the need for the constrained device to compute multiple keys		need for the constrained device to compute multiple keys for multiple
	for multiple addresses. The 6LN MAY use the same Crypto-ID to prove		addresses. The 6LN MAY use the same Crypto-ID to prove the ownership
	the ownership of multiple IPv6 addresses. The 6LN MAY also derive		of multiple IPv6 addresses. The 6LN MAY also derive multiple Crypto-
	multiple Crypto-IDs from a same key.		IDs from a same key.
	6.1. First Exchange with a 6LR		6.1. First Exchange with a 6LR
	A 6LN registers to a 6LR that is one hop away from it with the "C"		A 6LN registers to a 6LR that is one hop away from it with the "C"
	flag set in the EARO, indicating that the ROVR field contains a		flag set in the EARO, indicating that the ROVR field contains a
	Crypto-ID. The Target Address in the NS message indicates the IPv6		Crypto-ID. The Target Address in the NS message indicates the IPv6
	address that the 6LN is trying to register [RFC8505]. The on-link		address that the 6LN is trying to register [RFC8505]. The on-link
	(local) protocol interactions are shown in Figure 5. If the 6LR does		(local) protocol interactions are shown in Figure 5. If the 6LR does
	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 [RFC4086]. 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),
	and the NDPSO containing the signature. Both Nonces are included in		and the NDPSO containing the signature. Both Nonces are included in
	the signed material. This provides a "contributory behavior", so		the signed material. This provides a "contributory behavior", so
	that either party that knows it generates a good quality Nonce knows		that either party that knows it generates a good quality nonce knows
	that the protocol will be secure.		that the protocol will be secure.
	The 6LR MUST store the information associated to a Crypto-ID on the		The 6LR MUST store the information associated to a Crypto-ID on the
	first NS exchange where it appears in a fashion that the CIPO		first NS exchange where it appears in a fashion that the CIPO
	parameters can be retrieved from the Crypto-ID alone.		parameters can be retrieved from the Crypto-ID alone.
	6LN 6LR		6LN 6LR
	| |		| |
	|<------------------------- RA -------------------------|		|<------------------------- RA -------------------------|
	| | ^		| | ^
	skipping to change at page 14, line 48 ¶		skipping to change at page 14, line 48 ¶
	1. The 128-bit Message Type tag [RFC3972] (in network byte order).		1. The 128-bit Message Type tag [RFC3972] (in network byte order).
	For this specification the tag is 0x8701 55c8 0cca dd32 6ab7 e415		For this specification the tag is 0x8701 55c8 0cca dd32 6ab7 e415
	f148 84d0. (The tag value has been generated by the editor of		f148 84d0. (The tag value has been generated by the editor of
	this specification on random.org).		this specification on random.org).
	2. JWK-encoded public key		2. JWK-encoded public key
	3. the 16-byte Target Address (in network byte order) sent in the		3. the 16-byte Target Address (in network byte order) sent in the
	Neighbor Solicitation (NS) message. It is the address which the		Neighbor Solicitation (NS) message. It is the address which the
	6LN is registering with the 6LR and 6LBR.		6LN is registering with the 6LR and 6LBR.
	4. NonceLR received from the 6LR (in network byte order) in the		4. NonceLR received from the 6LR (in network byte order) in the
	Neighbor Advertisement (NA) message. The Nonce is at least 6		Neighbor Advertisement (NA) message. The nonce is at least 6
	bytes long as defined in [RFC3971].		bytes long as defined in [RFC3971].
	5. NonceLN sent from the 6LN (in network byte order). The Nonce is		5. NonceLN sent from the 6LN (in network byte order). The nonce is
	at least 6 bytes long as defined in [RFC3971].		at least 6 bytes long as defined in [RFC3971].
	6. The length of the ROVR field containing the Crypto-ID.		6. 1-byte Option Length of the EARO containing the Crypto-ID.
	7. 1-byte Crypto-Type value sent in the CIPO option.		7. 1-byte Crypto-Type value sent in the CIPO.
	* Apply the hash function (if any) specified by the Crypto-Type to		* Apply the hash function (if any) specified by the Crypto-Type to
	the concatenated data, e.g., hash the resulting data using SHA-		the concatenated data, e.g., hash the resulting data using SHA-
	256.		256.
	* Apply the signature algorithm specified by the Crypto-Type, e.g.,		* Apply the signature algorithm specified by the Crypto-Type, e.g.,
	sign the hash output with ECDSA (if curve P-256 is used) or sign		sign the hash output with ECDSA (if curve P-256 is used) or sign
	the hash with EdDSA (if curve Ed25519 (PureEdDSA)).		the hash with EdDSA (if curve Ed25519 (PureEdDSA)).
	The 6LR on receiving the NDPSO and CIPO options first regenerates the		The 6LR on receiving the NDPSO and CIPO options first checks that the
	Crypto-ID based on the CIPO option to make sure that the leftmost		EARO Length in the CIPO matches the length of the EARO. If so it
	bits up to the size of the ROVR match. If and only if the check is		regenerates the Crypto-ID based on the CIPO to make sure that the
	successful, it tries to verify the signature in the NDPSO option		leftmost bits up to the size of the ROVR match.
	using the following:
			If and only if the check is successful, it tries to verify the
			signature in the NDPSO option using the following:
	* Concatenate the following in the order listed:		* Concatenate the following in the order listed:
	1. 128-bit type tag (in network byte order)		1. 128-bit type tag (in network byte order)
	2. JWK-encoded public key received in the CIPO option		2. JWK-encoded public key received in the CIPO
	3. the 16-byte Target Address (in network byte order) received in		3. the 16-byte Target Address (in network byte order) received in
	the Neighbor Solicitation (NS) message. It is the address which		the Neighbor Solicitation (NS) message. It is the address which
	the 6LN is registering with the 6LR and 6LBR.		the 6LN is registering with the 6LR and 6LBR.
	4. NonceLR sent in the Neighbor Advertisement (NA) message. The		4. NonceLR sent in the Neighbor Advertisement (NA) message. The
	Nonce is at least 6 bytes long as defined in [RFC3971].		nonce is at least 6 bytes long as defined in [RFC3971].
	5. NonceLN received from the 6LN (in network byte order) in the NS		5. NonceLN received from the 6LN (in network byte order) in the NS
	message. The Nonce is at least 6 bytes long as defined in		message. The nonce is at least 6 bytes long as defined in
	[RFC3971].		[RFC3971].
	6. The length of the ROVR field in the NS message containing the		6. 1-byte EARO Length received in the CIPO.
	Crypto-ID that was received.		7. 1-byte Crypto-Type value received in the CIPO.
	7. 1-byte Crypto-Type value received in the CIPO option.
	* Apply the hash function (if any) specified by the Crypto-Type		* Apply the hash function (if any) specified by the Crypto-Type
	indicated by the 6LN in the CIPO to the concatenated data.		indicated by the 6LN in the CIPO to the concatenated data.
	* Verify the signature with the public-key in the CIPO and the		* Verify the signature with the public-key in the CIPO and the
	locally computed values using the signature algorithm specified by		locally computed values using the signature algorithm specified by
	the Crypto-Type. If the verification succeeds, the 6LR propagates		the Crypto-Type. If the verification succeeds, the 6LR propagates
	the information to the 6LBR using a EDAR/EDAC flow. Due to the		the information to the 6LBR using a EDAR/EDAC flow.
	first-come/first-serve nature of the registration, if the address
	is not registered to the 6LBR, then flow succeeds and both the 6LR		* Due to the first-come/first-serve nature of the registration, if
	and 6LBR add the state information about the Crypto-ID and Target		the address is not registered to the 6LBR, then flow succeeds and
	Address being registered to their respective abstract database.		both the 6LR and 6LBR add the state information about the Crypto-
			ID and Target Address being registered to their respective
			abstract database.
	6.3. Multihop Operation		6.3. Multihop Operation
	A new 6LN that joins the network auto-configures an address and		A new 6LN that joins the network auto-configures an address and
	performs an initial registration to a neighboring 6LR with an NS		performs an initial registration to a neighboring 6LR with an NS
	message that carries an Address Registration Option (EARO) [RFC8505].		message that carries an Address Registration Option (EARO) [RFC8505].
	In a multihop 6LoWPAN, the registration with Crypto-ID is propagated		In a multihop 6LoWPAN, the registration with Crypto-ID is propagated
	to 6LBR as shown in Figure 6, which illustrates the registration flow		to 6LBR as shown in Figure 6, which illustrates the registration flow
	all the way to a 6LowPAN Backbone Router (6BBR) [BACKBONE-ROUTER].		all the way to a 6LowPAN Backbone Router (6BBR) [BACKBONE-ROUTER].
	The 6LR and the 6LBR communicate using ICMPv6 Extended Duplicate		The 6LR and the 6LBR communicate using ICMPv6 Extended Duplicate
	Address Request (EDAR) and Extended Duplicate Address Confirmation		Address Request (EDAR) and Extended Duplicate Address Confirmation
	(EDAC) messages [RFC8505] as shown in Figure 6. This specification		(EDAC) messages [RFC8505] as shown in Figure 6. This specification
	extends EDAR/EDAC messages to carry cryptographically generated ROVR.		extends EDAR/EDAC messages to carry cryptographically generated ROVR.
	The assumption is that the 6LR and the 6LBR maintain a security		The assumption is that the 6LR and the 6LBR maintain a security
	association, so there is no need to propagate the proof of ownership		association to authenticate and protect the integrity of the EDAR and
	to the 6LBR. The 6LBR implicitly trusts that the 6LR performs the		EDAC messages, so there is no need to propagate the proof of
	verification when the 6LBR requires it, and if there is no further		ownership to the 6LBR. The 6LBR implicitly trusts that the 6LR
	exchange from the 6LR to remove the state, that the verification		performs the verification when the 6LBR requires it, and if there is
	succeeded.		no further exchange from the 6LR to remove the state, that the
			verification succeeded.
	6LN 6LR 6LBR 6BBR		6LN 6LR 6LBR 6BBR
	| | | |		| | | |
	| NS(EARO) | | |		| NS(EARO) | | |
	|--------------->| | |		|--------------->| | |
	| | Extended DAR | |		| | Extended DAR | |
	| |-------------->| |		| |-------------->| |
	| | | |		| | | |
	| | | proxy NS(EARO) |		| | | proxy NS(EARO) |
	| | |--------------->|		| | |--------------->|
	skipping to change at page 17, line 36 ¶		skipping to change at page 17, line 36 ¶
	backbone routers to determine which one has the freshest		backbone routers to determine which one has the freshest
	registration [RFC8505] and is thus the best candidate to validate		registration [RFC8505] and is thus the best candidate to validate
	the registration for the device attached to it [BACKBONE-ROUTER].		the registration for the device attached to it [BACKBONE-ROUTER].
	But this specification does not guarantee that the backbone router		But this specification does not guarantee that the backbone router
	claiming an address over the backbone is not an attacker.		claiming an address over the backbone is not an attacker.
	Router Solicitation and Advertisement Attacks: This specification		Router Solicitation and Advertisement Attacks: This specification
	does not change the protection of RS and RA which can still be		does not change the protection of RS and RA which can still be
	protected by SEND.		protected by SEND.
	Replay Attacks Using Nonces (NonceLR and NonceLN) generated by both		Replay Attacks A nonce should never repeat for a single key, but
	the 6LR and 6LN ensure a contributory behavior that provides an		nonces do not need to be unpredictable for secure operation.
	efficient protection against replay attacks of the challenge/		Using nonces (NonceLR and NonceLN) generated by both the 6LR and
	response flow. A nonce should never repeat for a same key. The		6LN ensure a contributory behavior that provides an efficient
	protection depends on the quality of the Nonce computation, e.g.,		protection against replay attacks of the challenge/response flow.
	of a random number generator when used to compute the Nonce.		The quality of the protection by a random nonce depends on the
			random number generator and its parameters (e.g., sense of time).
	Neighbor Discovery DoS Attack: A rogue node that managed to access		Neighbor Discovery DoS Attack: A rogue node that managed to access
	the L2 network may form many addresses and register them using AP-		the L2 network may form many addresses and register them using AP-
	ND. The perimeter of the attack is all the 6LRs in range of the		ND. The perimeter of the attack is all the 6LRs in range of the
	attacker. The 6LR MUST protect itself against overflows and		attacker. The 6LR MUST protect itself against overflows and
	reject excessive registration with a status 2 "Neighbor Cache		reject excessive registration with a status 2 "Neighbor Cache
	Full". This effectively blocks another (honest) 6LN from		Full". This effectively blocks another (honest) 6LN from
	registering to the same 6LR, but the 6LN may register to other		registering to the same 6LR, but the 6LN may register to other
	6LRs that are in its range but not in that of the rogue.		6LRs that are in its range but not in that of the rogue.
	skipping to change at page 18, line 51 ¶		skipping to change at page 18, line 51 ¶
	1.84E19) and k is the actual population (number of nodes, assuming		1.84E19) and k is the actual population (number of nodes, assuming
	one Crypto-ID per node).		one Crypto-ID per node).
	If the Crypto-ID is 64-bits (the least possible size allowed), the		If the Crypto-ID is 64-bits (the least possible size allowed), the
	chance of a collision is 0.01% for network of 66 million nodes.		chance of a collision is 0.01% for network of 66 million nodes.
	Moreover, the collision is only relevant when this happens within one		Moreover, the collision is only relevant when this happens within one
	stub network (6LBR). In the case of such a collision, a third party		stub network (6LBR). In the case of such a collision, a third party
	node would be able to claim the registered address of an another		node would be able to claim the registered address of an another
	legitimate node, provided that it wishes to use the same address. To		legitimate node, provided that it wishes to use the same address. To
	prevent address disclosure and avoid the chances of collision on both		prevent address disclosure and avoid the chances of collision on both
	the RIVR and the address, it is RECOMMENDED that nodes do not derive		the ROVR and the address, it is RECOMMENDED that nodes do not derive
	the address being registered from the ROVR.		the address being registered from the ROVR.
	7.4. Implementation Attacks		7.4. Implementation Attacks
	The signature schemes referenced in this specification comply with		The signature schemes referenced in this specification comply with
	NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards		NIST [FIPS186-4] or Crypto Forum Research Group (CFRG) standards
	[RFC8032] and offer strong algorithmic security at roughly 128-bit		[RFC8032] and offer strong algorithmic security at roughly 128-bit
	security level. These signature schemes use elliptic curves that		security level. These signature schemes use elliptic curves that
	were either specifically designed with exception-free and constant-		were either specifically designed with exception-free and constant-
	time arithmetic in mind [BCP 201] or where one has extensive		time arithmetic in mind [RFC7748] or where one has extensive
	implementation experience of resistance to timing attacks		implementation experience of resistance to timing attacks
	[FIPS186-4]. However, careless implementations of the signing		[FIPS186-4]. However, careless implementations of the signing
	operations could nevertheless leak information on private keys. For		operations could nevertheless leak information on private keys. For
	example, there are micro-architectural side channel attacks that		example, there are micro-architectural side channel attacks that
	implementors should be aware of [breaking-ed25519]. Implementors		implementors should be aware of [breaking-ed25519]. Implementors
	should be particularly aware that a secure implementation of Ed25519		should be particularly aware that a secure implementation of Ed25519
	requires a protected implementation of the hash function SHA-512,		requires a protected implementation of the hash function SHA-512,
	whereas this is not required with implementations of SHA-256 used		whereas this is not required with implementations of SHA-256 used
	with ECDSA.		with ECDSA.
	skipping to change at page 21, line 9 ¶		skipping to change at page 21, line 9 ¶
	(ICMPv6) Parameters". The registry is indexed by an integer in the		(ICMPv6) Parameters". The registry is indexed by an integer in the
	interval 0..255 and contains an Elliptic Curve, a Hash Function, a		interval 0..255 and contains an Elliptic Curve, a Hash Function, a
	Signature Algorithm, and Representation Conventions, as shown in		Signature Algorithm, and Representation Conventions, as shown in
	Table 2, which together specify a signature scheme. The following		Table 2, which together specify a signature scheme. The following
	Crypto-Type values are defined in this document:		Crypto-Type values are defined in this document:
	+----------------+-----------------+-------------+-----------------+		+----------------+-----------------+-------------+-----------------+
	| Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 (ECDSA25519) |		| Crypto-Type | 0 (ECDSA256) | 1 (Ed25519) | 2 (ECDSA25519) |
	| value | | | |		| value | | | |
	+================+=================+=============+=================+		+================+=================+=============+=================+
	| Elliptic curve | NIST P-256 | Curve25519 | Curve25519 [BCP |		| Elliptic curve | NIST P-256 | Curve25519 | Curve25519 |
	| | [FIPS186-4] | [BCP 201] | 201] |		| | [FIPS186-4] | [RFC7748] | [RFC7748] |
	+----------------+-----------------+-------------+-----------------+		+----------------+-----------------+-------------+-----------------+
	| Hash function | SHA-256 | SHA-512 | SHA-256 |		| Hash function | SHA-256 | SHA-512 | SHA-256 |
	| | [RFC6234] | [RFC6234] | [RFC6234] |		| | [RFC6234] | [RFC6234] | [RFC6234] |
	+----------------+-----------------+-------------+-----------------+		+----------------+-----------------+-------------+-----------------+
	| Signature | ECDSA | Ed25519 | ECDSA |		| Signature | ECDSA | Ed25519 | ECDSA |
	| algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] |		| algorithm | [FIPS186-4] | [RFC8032] | [FIPS186-4] |
	+----------------+-----------------+-------------+-----------------+		+----------------+-----------------+-------------+-----------------+
	| Representation | Weierstrass, | Edwards, | Weierstrass, |		| Representation | Weierstrass, | Edwards, | Weierstrass, |
	| conventions | (un)compressed, | compressed, | (un)compressed, |		| conventions | (un)compressed, | compressed, | (un)compressed, |
	| | MSB/msb first | LSB/lsb | MSB/msb first |		| | MSB/msb first | LSB/lsb | MSB/msb first |
	skipping to change at page 22, line 24 ¶		skipping to change at page 22, line 24 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,		[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
	"SEcure Neighbor Discovery (SEND)", RFC 3971,		"SEcure Neighbor Discovery (SEND)", RFC 3971,
	DOI 10.17487/RFC3971, March 2005,		DOI 10.17487/RFC3971, March 2005,
	<https://www.rfc-editor.org/info/rfc3971>.		<https://www.rfc-editor.org/info/rfc3971>.
	[BCP 201] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves		[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
	for Security", RFC 7748, DOI 10.17487/RFC7748, January		for Security", RFC 7748, DOI 10.17487/RFC7748, January
	2016, <https://www.rfc-editor.org/info/rfc7748>.		2016, <https://www.rfc-editor.org/info/rfc7748>.
	[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital		[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
	Signature Algorithm (EdDSA)", RFC 8032,		Signature Algorithm (EdDSA)", RFC 8032,
	DOI 10.17487/RFC8032, January 2017,		DOI 10.17487/RFC8032, January 2017,
	<https://www.rfc-editor.org/info/rfc8032>.		<https://www.rfc-editor.org/info/rfc8032>.
	[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
	skipping to change at page 25, line 47 ¶		skipping to change at page 25, line 47 ¶
	(see [FIPS186-4]) and are encoded as octet strings in most-		(see [FIPS186-4]) and are encoded as octet strings in most-
	significant-bit first (msb) and most-significant-byte first (MSB)		significant-bit first (msb) and most-significant-byte first (MSB)
	order. The signature itself consists of two integers (r and s),		order. The signature itself consists of two integers (r and s),
	which are each encoded as fixed-size octet strings in most-		which are each encoded as fixed-size octet strings in most-
	significant-bit first and most-significant-byte first order. For		significant-bit first and most-significant-byte first order. For
	details on ECDSA, see [FIPS186-4]; for details on the integer		details on ECDSA, see [FIPS186-4]; for details on the integer
	encoding, see Appendix B.2.		encoding, see Appendix B.2.
	The signature scheme Ed25519 corresponding to Crypto-Type 1 is EdDSA,		The signature scheme Ed25519 corresponding to Crypto-Type 1 is EdDSA,
	as specified in [RFC8032], instantiated with the Montgomery curve		as specified in [RFC8032], instantiated with the Montgomery curve
	Curve25519, as specified in [BCP 201], and the hash function SHA-512,		Curve25519, as specified in [RFC7748], and the hash function SHA-512,
	as specified in [RFC6234], where points of this Montgomery curve are		as specified in [RFC6234], where points of this Montgomery curve are
	represented as points of the corresponding twisted Edwards curve (see		represented as points of the corresponding twisted Edwards curve (see
	Appendix B.3) and are encoded as octet strings in least-significant-		Appendix B.3) and are encoded as octet strings in least-significant-
	bit first (lsb) and least-significant-byte first (LSB) order. The		bit first (lsb) and least-significant-byte first (LSB) order. The
	signature itself consists of a bit string that encodes a point of		signature itself consists of a bit string that encodes a point of
	this twisted Edwards curve, in compressed format, and an integer		this twisted Edwards curve, in compressed format, and an integer
	encoded in least-significant-bit first and least-significant-byte		encoded in least-significant-bit first and least-significant-byte
	first order. For details on EdDSA and on the encoding conversions,		first order. For details on EdDSA and on the encoding conversions,
	see the specification of pure Ed25519 in . [RFC8032]		see the specification of pure Ed25519 in . [RFC8032]
	The signature scheme ECDSA25519 corresponding to Crypto-Type 2 is		The signature scheme ECDSA25519 corresponding to Crypto-Type 2 is
	ECDSA, as specified in [FIPS186-4], instantiated with the Montgomery		ECDSA, as specified in [FIPS186-4], instantiated with the Montgomery
	curve Curve25519, as specified in [BCP 201], and the hash function		curve Curve25519, as specified in [RFC7748], and the hash function
	SHA-256, as specified in [RFC6234], where points of this Montgomery		SHA-256, as specified in [RFC6234], where points of this Montgomery
	curve are represented as points of a corresponding curve in short-		curve are represented as points of a corresponding curve in short-
	Weierstrass form (see Appendix B.3) and are encoded as octet strings		Weierstrass form (see Appendix B.3) and are encoded as octet strings
	in most-significant-bit first and most-significant-byte first order.		in most-significant-bit first and most-significant-byte first order.
	The signature itself consists of a bit string that encodes two		The signature itself consists of a bit string that encodes two
	integers, each encoded as fixed-size octet strings in most-		integers, each encoded as fixed-size octet strings in most-
	significant-bit first and most-significant-byte first order. For		significant-bit first and most-significant-byte first order. For
	details on ECDSA, see [FIPS186-4]; for details on the integer		details on ECDSA, see [FIPS186-4]; for details on the integer
	encoding, see Appendix B.2		encoding, see Appendix B.2
	skipping to change at page 26, line 36 ¶		skipping to change at page 26, line 36 ¶
	Each integer is encoded as a fixed-size 256-bit bit string, where		Each integer is encoded as a fixed-size 256-bit bit string, where
	each integer is represented according to the Field Element to Octet		each integer is represented according to the Field Element to Octet
	String and Octet String to Bit String conversion rules in [SEC1] and		String and Octet String to Bit String conversion rules in [SEC1] and
	where the ordered pair of integers is represented as the		where the ordered pair of integers is represented as the
	rightconcatenation of the resulting representation values. The		rightconcatenation of the resulting representation values. The
	inverse operation follows the corresponding Bit String to Octet		inverse operation follows the corresponding Bit String to Octet
	String and Octet String to Field Element conversion rules of [SEC1].		String and Octet String to Field Element conversion rules of [SEC1].
	B.3. Alternative Representations of Curve25519		B.3. Alternative Representations of Curve25519
	The elliptic curve Curve25519, as specified in [BCP 201], is a so-		The elliptic curve Curve25519, as specified in [RFC7748], is a so-
	called Montgomery curve. Each point of this curve can also be		called Montgomery curve. Each point of this curve can also be
	represented as a point of a twisted Edwards curve or as a point of an		represented as a point of a twisted Edwards curve or as a point of an
	elliptic curve in short-Weierstrass form, via a coordinate		elliptic curve in short-Weierstrass form, via a coordinate
	transformation (a so-called isomorphic mapping). The parameters of		transformation (a so-called isomorphic mapping). The parameters of
	the Montgomery curve and the corresponding isomorphic curves in		the Montgomery curve and the corresponding isomorphic curves in
	twisted Edwards curve and short-Weierstrass form are as indicated		twisted Edwards curve and short-Weierstrass form are as indicated
	below. Here, the domain parameters of the Montgomery curve		below. Here, the domain parameters of the Montgomery curve
	Curve25519 and of the twisted Edwards curve Edwards25519 are as		Curve25519 and of the twisted Edwards curve Edwards25519 are as
	specified in [BCP 201]; the domain parameters of the elliptic curve		specified in [RFC7748]; the domain parameters of the elliptic curve
	Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of		Wei25519 in short-Weierstrass curve comply with Section 6.1.1 of
	[FIPS186-4]. For details of the coordinate transformation referenced		[FIPS186-4]. For details of the coordinate transformation referenced
	above, see [BCP 201] and [CURVE-REPRESENTATIONS].		above, see [RFC7748] and [CURVE-REPRESENTATIONS].
	General parameters (for all curve models):		General parameters (for all curve models):
	p 2^{255}-19		p 2^{255}-19
	(=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff		(=0x7fffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff
	ffffffed)		ffffffed)
	h 8		h 8
	n		n
	723700557733226221397318656304299424085711635937990760600195093828		723700557733226221397318656304299424085711635937990760600195093828
	5454250989		5454250989
End of changes. 52 change blocks.
	102 lines changed or deleted		103 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/