draft-ietf-6lo-ap-nd-19.txt   draft-ietf-6lo-ap-nd-20.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: 9 August 2020 M. Sethi Expires: 10 September 2020 M. Sethi
Ericsson Ericsson
R. Struik R. Struik
Struik Security Consultancy Struik Security Consultancy
6 February 2020 9 March 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-19 draft-ietf-6lo-ap-nd-20
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 9 August 2020. This Internet-Draft will expire on 10 September 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 33 skipping to change at page 2, line 33
2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Additional References . . . . . . . . . . . . . . . . . . 5 2.3. Additional References . . . . . . . . . . . . . . . . . . 5
3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 5 3. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 5
4. New Fields and Options . . . . . . . . . . . . . . . . . . . 6 4. New Fields and Options . . . . . . . . . . . . . . . . . . . 6
4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 6 4.1. New Crypto-ID . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Updated EARO . . . . . . . . . . . . . . . . . . . . . . 6
4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 7 4.3. Crypto-ID Parameters Option . . . . . . . . . . . . . . . 7
4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 9 4.4. NDP Signature Option . . . . . . . . . . . . . . . . . . 9
5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Scope . . . . . . . . . . . . . . . . . . . . . . . 11
6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 11 6. Protocol Flows . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 12 6.1. First Exchange with a 6LR . . . . . . . . . . . . . . . . 13
6.2. NDPSO generation and verification . . . . . . . . . . . . 14 6.2. NDPSO generation and verification . . . . . . . . . . . . 15
6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 16 6.3. Multihop Operation . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 17 7.1. Inheriting from RFC 3971 . . . . . . . . . . . . . . . . 17
7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 18 7.2. Related to 6LoWPAN ND . . . . . . . . . . . . . . . . . . 18
7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 18 7.3. ROVR Collisions . . . . . . . . . . . . . . . . . . . . . 19
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 . . . . . . . 20
7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 19 7.6. Compromised 6LR . . . . . . . . . . . . . . . . . . . . . 20
7.7. Correlating Registrations . . . . . . . . . . . . . . . . 20 7.7. Correlating Registrations . . . . . . . . . . . . . . . . 21
8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 21
8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 20 8.1. CGA Message Type . . . . . . . . . . . . . . . . . . . . 21
8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 20 8.2. IPv6 ND option types . . . . . . . . . . . . . . . . . . 21
8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 21 8.3. Crypto-Type Subregistry . . . . . . . . . . . . . . . . . 22
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 8.4. New Codepoints Associated to JWK Encoding . . . . . . . . 22
10. Normative References . . . . . . . . . . . . . . . . . . . . 22 8.4.1. COSE Elliptic Curves Registration . . . . . . . . . . 23
11. Informative references . . . . . . . . . . . . . . . . . . . 23 8.4.2. COSE Algorithms Registration . . . . . . . . . . . . 23
Appendix A. Requirements Addressed in this Document . . . . . . 25 8.4.3. JOSE Elliptic Curves Registration . . . . . . . . . . 23
Appendix B. Representation Conventions . . . . . . . . . . . . . 25 8.4.4. JOSE Algorithms Registration . . . . . . . . . . . . 24
B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
B.2. Integer Representation for ECDSA signatures . . . . . . . 26 10. Normative References . . . . . . . . . . . . . . . . . . . . 24
B.3. Alternative Representations of Curve25519 . . . . . . . . 27 11. Informative references . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix A. Requirements Addressed in this Document . . . . . . 28
Appendix B. Representation Conventions . . . . . . . . . . . . . 28
B.1. Signature Schemes . . . . . . . . . . . . . . . . . . . . 28
B.2. Integer Representation for ECDSA signatures . . . . . . . 29
B.3. Alternative Representations of Curve25519 . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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
defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration defined in IPv6 ND. 6LoWPAN ND defines a new Address Registration
skipping to change at page 5, line 25 skipping to change at page 5, line 31
* "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 that is used to detect Section 5.3 of [RFC8505] introduces the ROVR that is used to detect
and reject duplicate registrations in the DAD process. The ROVR is a and reject duplicate registrations in the DAD process. The ROVR is a
generic object that is designed for backward compatibility with the generic object that is designed for both backward compatibility and
capability to introduce new computation methods in the future. Using the capability to introduce new computation methods in the future.
a Crypto-ID per this specification is the RECOMMENDED method. Using a Crypto-ID per this specification is the RECOMMENDED method.
Section 7.3 discusses collisions when heterogeneous methods to Section 7.3 discusses collisions when heterogeneous methods to
compute the ROVR field coexist inside a same network. 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
skipping to change at page 14, line 39 skipping to change at page 15, line 27
6.2. NDPSO generation and verification 6.2. NDPSO generation and verification
The signature generated by the 6LN to provide proof-of-ownership of The signature generated by the 6LN to provide proof-of-ownership of
the private-key is carried in the NDP Signature Option (NDPSO). It the private-key is carried in the NDP Signature Option (NDPSO). It
is generated by the 6LN in a fashion that depends on the Crypto-Type is generated by the 6LN in a fashion that depends on the Crypto-Type
(see Table 2 in Section 8.3) chosen by the 6LN as follows: (see Table 2 in Section 8.3) chosen by the 6LN as follows:
* Concatenate the following in the order listed: * Concatenate the following in the order listed:
1. The 128-bit Message Type tag [RFC3972] (in network byte order). 1. The 128-bit Message Type tag [RFC3972] (in network byte
For this specification the tag is 0x8701 55c8 0cca dd32 6ab7 e415 order). For this specification the tag is 0x8701 55c8 0cca
f148 84d0. (The tag value has been generated by the editor of dd32 6ab7 e415 f148 84d0. (The tag value has been generated
this specification on random.org). by the editor of 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
6LN is registering with the 6LR and 6LBR. the 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
at least 6 bytes long as defined in [RFC3971]. is at least 6 bytes long as defined in [RFC3971].
6. 1-byte Option Length of the EARO 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.
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 checks that the The 6LR on receiving the NDPSO and CIPO options first checks that the
EARO Length in the CIPO matches the length of the EARO. If so it EARO Length in the CIPO matches the length of the EARO. If so it
regenerates the Crypto-ID based on the CIPO to make sure that the regenerates the Crypto-ID based on the CIPO to make sure that the
leftmost bits up to the size of the ROVR match. leftmost bits up to the size of the ROVR match.
If and only if the check is successful, it tries to verify the If and only if the check is successful, it tries to verify the
signature in the NDPSO option using the following: 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 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
the 6LN is registering with the 6LR and 6LBR. which 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
message. The nonce is at least 6 bytes long as defined in NS message. The nonce is at least 6 bytes long as defined in
[RFC3971]. [RFC3971].
6. 1-byte EARO Length received in the CIPO. 6. 1-byte EARO Length received in the CIPO.
7. 1-byte Crypto-Type value received in the CIPO. 7. 1-byte Crypto-Type value received in the CIPO.
* 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. the information to the 6LBR using a EDAR/EDAC flow.
* Due to the first-come/first-serve nature of the registration, if * Due to the first-come/first-serve nature of the registration, if
skipping to change at page 22, line 5 skipping to change at page 22, line 49
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 BCP 26 [RFC8126]. defined in BCP 26 [RFC8126].
The "Defining specification" column indicates the document that The "Defining specification" column indicates the document that
defines the length and computation of the digital signature, which defines the length and computation of the digital signature, which
could be this for values defined through "IESG Approval". could be this for values defined through "IESG Approval".
8.4. New Codepoints Associated to JWK Encoding
Code points are requested for curve Wei25519 and its use with ECDSA,
using the representation conventions of this document.
8.4.1. COSE Elliptic Curves Registration
This section registers the following value in the IANA "COSE Elliptic
Curves" registry [IANA.COSE.Curves].
Name: Wei25519
Value: TBD (Requested value: -1)
Key Type: EC2 or OKP (where OKP uses the MSB/msb representation of
this specification)
Description: short-Weierstrass curve Wei25519
Change Controller: IESG
Reference: Appendix E.3 of [CURVE-REPRESENTATIONS]
Recommended: Yes.
(Note that The "kty" value for Wei25519 may be "OKP" or "EC2".)
8.4.2. COSE Algorithms Registration
This section registers the following value in the IANA "COSE
Algorithms" registry [IANA.COSE.Algorithms].
Name: ECDSA25519
Value: TBD (Requested value: -1)
Description: ECDSA using SHA-256 and curve Wei25519
Change Controller: IESG
Reference: Section 4.3 of [CURVE-REPRESENTATIONS]
Recommended: Yes.
8.4.3. JOSE Elliptic Curves Registration
This section registers the following value in the IANA "JSON Web Key
Elliptic Curve" registry [IANA.JOSE.Curves].
Curve Name: Wei25519
Curve Description: short-Weierstrass curve Wei25519
JOSE Implementation Requirements: Optional
Change Controller: IESG
Reference: Appendix E.3 of [CURVE-REPRESENTATIONS]
8.4.4. JOSE Algorithms Registration
This section registers the following value in the IANA "JSON Web
Signature and Encryption Algorithms" registry [IANA.JOSE.Algorithms].
Algorithm Name: ECDSA25519
Algorithm Description: ECDSA using SHA-256 and curve Wei25519
Algorithm Usage Locations: alg
JOSE Implementation Requirements: Optional
Change Controller: IESG
Reference: Section 4.3 of [CURVE-REPRESENTATIONS]
Algorithm Analysis Document(s): Section 4.3 of
[CURVE-REPRESENTATIONS]
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 and Benjamin Kaduk for their comments and to Robert Moskowitz and Benjamin Kaduk for their comments and
discussions that led to many improvements. The authors wish to also discussions that led to many improvements. The authors wish to also
thank Roman Danyliw, Alissa Cooper, Mirja Kuhlewind, Eric Vyncke, thank Roman Danyliw, Alissa Cooper, Mirja Kuhlewind, Eric Vyncke,
Vijay Gurbani, Al Morton and Adam Montville for their constructive Vijay Gurbani, Al Morton and Adam Montville for their constructive
reviews during the IESG process. reviews during the IESG process.
skipping to change at page 23, line 23 skipping to change at page 25, line 49
FIPS 186-4, "Digital Signature Standard (DSS), Federal FIPS 186-4, "Digital Signature Standard (DSS), Federal
Information Processing Standards Publication 186-4", US Information Processing Standards Publication 186-4", US
Department of Commerce/National Institute of Standards and Department of Commerce/National Institute of Standards and
Technology , July 2013. Technology , July 2013.
[SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0", [SEC1] SEC1, "SEC 1: Elliptic Curve Cryptography, Version 2.0",
Standards for Efficient Cryptography , June 2009. Standards for Efficient Cryptography , June 2009.
11. Informative references 11. Informative references
[IANA.COSE.Algorithms]
IANA, "COSE Algorithms", IANA,
https://www.iana.org/assignments/cose/
cose.xhtml#algorithms.
[IANA.COSE.Curves]
IANA, "COSE Elliptic Curves", IANA,
https://www.iana.org/assignments/cose/cose.xhtml#elliptic-
curves.
[IANA.JOSE.Algorithms]
IANA, "JSON Web Signature and Encryption Algorithms",
IANA,
https://www.iana.org/assignments/jose/jose.xhtml#web-
signature-encryption-algorithms.
[IANA.JOSE.Curves]
IANA, "JSON Web Key Elliptic Curve", IANA,
https://www.iana.org/assignments/jose/jose.xhtml#web-key-
elliptic-curve.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, DOI 10.17487/RFC3972, March 2005, RFC 3972, DOI 10.17487/RFC3972, March 2005,
<https://www.rfc-editor.org/info/rfc3972>. <https://www.rfc-editor.org/info/rfc3972>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007, DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>. <https://www.rfc-editor.org/info/rfc4861>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
skipping to change at page 24, line 43 skipping to change at page 27, line 40
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-
Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065, Layer Mechanisms", RFC 8065, DOI 10.17487/RFC8065,
February 2017, <https://www.rfc-editor.org/info/rfc8065>. February 2017, <https://www.rfc-editor.org/info/rfc8065>.
[BACKBONE-ROUTER] [BACKBONE-ROUTER]
Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6
Backbone Router", Work in Progress, Internet-Draft, draft- Backbone Router", Work in Progress, Internet-Draft, draft-
ietf-6lo-backbone-router-13, 26 September 2019, ietf-6lo-backbone-router-19, 3 March 2020,
<https://tools.ietf.org/html/draft-ietf-6lo-backbone- <https://tools.ietf.org/html/draft-ietf-6lo-backbone-
router-13>. router-19>.
[CURVE-REPRESENTATIONS] [CURVE-REPRESENTATIONS]
Struik, R., "Alternative Elliptic Curve Representations", Struik, R., "Alternative Elliptic Curve Representations",
Work in Progress, Internet-Draft, draft-ietf-lwig-curve- Work in Progress, Internet-Draft, draft-ietf-lwig-curve-
representations-08, 24 July 2019, representations-08, 24 July 2019,
<https://tools.ietf.org/html/draft-ietf-lwig-curve- <https://tools.ietf.org/html/draft-ietf-lwig-curve-
representations-08>. representations-08>.
[breaking-ed25519] [breaking-ed25519]
Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R. Samwel, N., Batina, L., Bertoni, G., Daemen, J., and R.
 End of changes. 14 change blocks. 
57 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/