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.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/