draft-ietf-6man-rfc4941bis-02.txt   draft-ietf-6man-rfc4941bis-03.txt 
IPv6 Maintenance (6man) Working Group F. Gont IPv6 Maintenance (6man) Working Group F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks / UTN-FRH
Obsoletes: rfc4941 (if approved) S. Krishnan Obsoletes: rfc4941 (if approved) S. Krishnan
Intended status: Standards Track Ericsson Research Intended status: Standards Track Ericsson Research
Expires: January 9, 2020 T. Narten Expires: March 8, 2020 T. Narten
IBM Corporation IBM Corporation
R. Draves R. Draves
Microsoft Research Microsoft Research
July 8, 2019 September 5, 2019
Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
draft-ietf-6man-rfc4941bis-02 draft-ietf-6man-rfc4941bis-03
Abstract Abstract
Nodes use IPv6 stateless address autoconfiguration to generate Nodes use IPv6 stateless address autoconfiguration to generate
addresses using a combination of locally available information and addresses using a combination of locally available information and
information advertised by routers. Addresses are formed by combining information advertised by routers. Addresses are formed by combining
network prefixes with an interface identifier. This document network prefixes with an interface identifier. This document
describes an extension that causes nodes to generate global scope describes an extension that causes nodes to generate global scope
addresses from interface identifiers that change over time. Changing addresses with randomized interface identifiers that change over
the interface identifier (and the global scope addresses generated time. Changing global scope addresses over time makes it more
from it) over time makes it more difficult for eavesdroppers and difficult for eavesdroppers and other information collectors to
other information collectors to identify when different addresses identify when different addresses used in different transactions
used in different transactions actually correspond to the same node. actually correspond to the same node. This document formally
obsoletes RFC4941.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 January 9, 2020. This Internet-Draft will expire on March 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 3 1.2. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Extended Use of the Same Identifier . . . . . . . . . . . 4 2.1. Extended Use of the Same Identifier . . . . . . . . . . . 4
2.2. Possible Approaches . . . . . . . . . . . . . . . . . . . 5 2.2. Possible Approaches . . . . . . . . . . . . . . . . . . . 6
3. Protocol Description . . . . . . . . . . . . . . . . . . . . 6 3. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Generation of Randomized Interface Identifiers . . . . . 7 3.2. Generation of Randomized Interface Identifiers . . . . . 8
3.2.1. Simple Randomized Interface Identifiers . . . . . . . 8 3.2.1. Simple Randomized Interface Identifiers . . . . . . . 8
3.2.2. Hash-based Generation of Randomized Interface 3.2.2. Hash-based Generation of Randomized Interface
Identifiers . . . . . . . . . . . . . . . . . . . . . 8 Identifiers . . . . . . . . . . . . . . . . . . . . . 9
3.3. Generating Temporary Addresses . . . . . . . . . . . . . 10 3.3. Generating Temporary Addresses . . . . . . . . . . . . . 10
3.4. Expiration of Temporary Addresses . . . . . . . . . . . . 11 3.4. Expiration of Temporary Addresses . . . . . . . . . . . . 12
3.5. Regeneration of Randomized Interface Identifiers . . . . 12 3.5. Regeneration of Randomized Interface Identifiers . . . . 12
3.6. Deployment Considerations . . . . . . . . . . . . . . . . 13 3.6. Deployment Considerations . . . . . . . . . . . . . . . . 13
4. Implications of Changing Interface Identifiers . . . . . . . 14 4. Implications of Changing Interface Identifiers . . . . . . . 14
5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 14 5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 15
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Significant Changes from RFC4941 . . . . . . . . . . . . . . 16 8. Significant Changes from RFC4941 . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Stateless address autoconfiguration [RFC4862] defines how an IPv6 Stateless address autoconfiguration [RFC4862] defines how an IPv6
node generates addresses without the need for a Dynamic Host node generates addresses without the need for a Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) server. The security and Configuration Protocol for IPv6 (DHCPv6) server. The security and
privacy implications of such addresses have been discussed in great privacy implications of such addresses have been discussed in great
detail in [RFC7721],[RFC7217], and RFC7707. This document specifies detail in [RFC7721],[RFC7217], and RFC7707. This document specifies
an extension for SLAAC to generate temporary addresses, such that the an extension for SLAAC to generate temporary addresses, such that the
aforementioned issues are mitigated. aforementioned issues are mitigated.
skipping to change at page 4, line 24 skipping to change at page 4, line 24
interface identifiers that vary over time. interface identifiers that vary over time.
Note that an attacker, who is on path, may be able to perform Note that an attacker, who is on path, may be able to perform
significant correlation based on significant correlation based on
o The payload contents of the packets on the wire o The payload contents of the packets on the wire
o The characteristics of the packets such as packet size and timing o The characteristics of the packets such as packet size and timing
Use of temporary addresses will not prevent such payload-based Use of temporary addresses will not prevent such payload-based
correlation. correlation, which can only be addressed by widespread deployment of
encryption as advocated in [RFC7624].
2. Background 2. Background
This section discusses the problem in more detail, provides context This section discusses the problem in more detail, provides context
for evaluating the significance of the concerns in specific for evaluating the significance of the concerns in specific
environments and makes comparisons with existing practices. environments and makes comparisons with existing practices.
2.1. Extended Use of the Same Identifier 2.1. Extended Use of the Same Identifier
The use of a non-changing interface identifier to form addresses is a The use of a non-changing interface identifier to form addresses is a
skipping to change at page 5, line 40 skipping to change at page 5, line 41
The use of a constant identifier within an address is of special The use of a constant identifier within an address is of special
concern because addresses are a fundamental requirement of concern because addresses are a fundamental requirement of
communication and cannot easily be hidden from eavesdroppers and communication and cannot easily be hidden from eavesdroppers and
other parties. Even when higher layers encrypt their payloads, other parties. Even when higher layers encrypt their payloads,
addresses in packet headers appear in the clear. Consequently, if a addresses in packet headers appear in the clear. Consequently, if a
mobile host (e.g., laptop) accessed the network from several mobile host (e.g., laptop) accessed the network from several
different locations, an eavesdropper might be able to track the different locations, an eavesdropper might be able to track the
movement of that mobile host from place to place, even if the upper movement of that mobile host from place to place, even if the upper
layer payloads were encrypted. layer payloads were encrypted.
Using temporary address alone may not be sufficient to prevent all
forms of tracking. It is however quite clear that some usage of
temporary addresses is necessary to improve user privacy.
The security and privacy implications of IPv6 addresses are discussed The security and privacy implications of IPv6 addresses are discussed
in detail in [RFC7721], [RFC7707], and [RFC7217]. in detail in [RFC7721], [RFC7707], and [RFC7217].
2.2. Possible Approaches 2.2. Possible Approaches
One way to avoid having a stable non-changing address is to use One way to avoid having a stable non-changing address is to use
DHCPv6 [RFC3315] for obtaining addresses. Section 12 of [RFC3315] DHCPv6 [RFC8415] for obtaining addresses. Section 12 of [RFC8415]
discusses the use of DHCPv6 for the assignment and management of discusses the use of DHCPv6 for the assignment and management of
"temporary addresses", which are never renewed and provide the same "temporary addresses", which are never renewed and provide the same
property of temporary addresses described in this document with property of temporary addresses described in this document with
regards to the privacy concern. regards to the privacy concern.
Another approach, compatible with the stateless address Another approach, compatible with the stateless address
autoconfiguration architecture, would be to change the interface autoconfiguration architecture, would be to change the interface
identifier portion of an address over time. Changing the interface identifier portion of an address over time. Changing the interface
identifier can make it more difficult to look at the IP addresses in identifier can make it more difficult to look at the IP addresses in
independent transactions and identify which ones actually correspond independent transactions and identify which ones actually correspond
skipping to change at page 6, line 37 skipping to change at page 6, line 46
On the other hand, a machine that functions only as a client may want On the other hand, a machine that functions only as a client may want
to employ only temporary addresses for public communication. to employ only temporary addresses for public communication.
To make it difficult to make educated guesses as to whether two To make it difficult to make educated guesses as to whether two
different interface identifiers belong to the same node, the different interface identifiers belong to the same node, the
algorithm for generating alternate identifiers must include input algorithm for generating alternate identifiers must include input
that has an unpredictable component from the perspective of the that has an unpredictable component from the perspective of the
outside entities that are collecting information. outside entities that are collecting information.
[I-D.gont-6man-non-stable-iids] specifies requirements for temporary
addresses. This document specifies a number of algorithms for
generating temporary addresses that comply with the aforementioned
requirements.
3. Protocol Description 3. Protocol Description
The goal of this section is to define procedures that: The goal of this section is to define procedures that can generate
IPv6 addresses with the following properties:
1. Do not result in any changes to the basic behavior of addresses 1. Temporary addresses can be employed for initiating outgoing
generated via stateless address autoconfiguration [RFC4862]. sessions.
2. Create temporary addresses based on an unpredictable interface 2. Temporary addresses are used for a short period of time
identifier for the purpose of initiating outgoing sessions. (typically hours to days) and are subsequently deprecated.
These temporary addresses would be used for a short period of Deprecated addresses can continue to be used for already
time (hours to days) and would then be deprecated. Deprecated established connections, but are not used to initiate new
addresses can continue to be used for already established connections.
connections, but are not used to initiate new connections. New
temporary addresses are generated periodically to replace
temporary addresses that expire, with the exact time between
address generation a matter of local policy.
3. Produce a sequence of temporary global scope addresses from a 3. New temporary addresses are generated periodically to replace
sequence of interface identifiers that appear to be random in the temporary addresses that expire.
sense that it is difficult for an outside observer to predict a
future address (or identifier) based on a current one and it is
difficult to determine previous addresses (or identifiers)
knowing only the present one.
4. By default, generate one address for each prefix advertised for 4. Temporary addresses must have a limited lifetime (limited "valid
stateless address autoconfiguration. The interface identifier lifetime" and "preferred lifetime" from [RFC4862]), that should
generated for each of those prefixes should be (statistically) be statistically different for different addresses. The lifetime
different. That is, a new interface identifier should be of an address should be further reduced when privacy-meaningful
computed for each temporary address that is to be generated. events (such as a node attaching to a different network, or the
regeneration of a new randomized MAC address) takes place.
5. By default, one address is generated for each prefix advertised
for stateless address autoconfiguration. The resulting Interface
Identifiers must be statistically different when addresses are
configured for different prefixes. That is, when temporary
addresses are generated for different autoconfiguration prefixes
for the same network interface, the resulting Interface
Identifiers must be statistically different. This means that,
given two addresses that employ different prefixes, it must be
difficult for an outside entity to tell whether the addresses
correspond to the same network interface or even whether they
have been generated by the same host.
6. It must be difficult for an outside entity to predict the
Interface Identifiers that will be employed for temporary
addresses, even with knowledge of the algorithm/method employed
to generate them and/or knowledge of the Interface Identifiers
previously employed for other temporary addresses. These
Interface Identifiers must be semantically opaque [RFC7136] and
must not follow any specific patterns.
3.1. Assumptions 3.1. Assumptions
The following algorithm assumes that for a given temporary address, The following algorithm assumes that for a given temporary address,
an implementation can determine the prefix from which it was an implementation can determine the prefix from which it was
generated. When a temporary address is deprecated, a new temporary generated. When a temporary address is deprecated, a new temporary
address is generated. The specific valid and preferred lifetimes for address is generated. The specific valid and preferred lifetimes for
the new address are dependent on the corresponding lifetime values the new address are dependent on the corresponding lifetime values
set for the prefix from which it was generated. set for the prefix from which it was generated.
skipping to change at page 7, line 48 skipping to change at page 8, line 17
implementation to prefer temporary addresses by default, so that the implementation to prefer temporary addresses by default, so that the
connections initiated by the node can use temporary addresses without connections initiated by the node can use temporary addresses without
requiring application-specific enablement. This document also requiring application-specific enablement. This document also
assumes that an API will exist that allows individual applications to assumes that an API will exist that allows individual applications to
indicate whether they prefer to use temporary or stable addresses and indicate whether they prefer to use temporary or stable addresses and
override the system defaults. override the system defaults.
3.2. Generation of Randomized Interface Identifiers 3.2. Generation of Randomized Interface Identifiers
The following subsections specify some possible algorithms for The following subsections specify some possible algorithms for
generating temporary interface identifiers that comply with the generating temporary interface identifiers that follow the guidelines
requirements in [I-D.gont-6man-non-stable-iids]. The algorithm in Section 3 of this document. The algorithm specified in
specified in Section 3.2.1 benefits from a Pseudo-Random Number Section 3.2.1 benefits from a Pseudo-Random Number Generator (PRNG)
Generator (PRNG) available on the system. On the other hand, the available on the system. On the other hand, the algorithm specified
algorithm specified in Section 3.2.2 allows for code reuse by nodes in Section 3.2.2 allows for code reuse by nodes that implement
that implement [RFC7217]. [RFC7217].
3.2.1. Simple Randomized Interface Identifiers 3.2.1. Simple Randomized Interface Identifiers
One possible approach would be to select a pseudorandom number of the One possible approach would be to select a pseudorandom number of the
appropriate length. A node employing this algorithm should generate appropriate length. A node employing this algorithm should generate
IIDs as follows: IIDs as follows:
1. Obtain a random number (see [RFC4086] for randomness requirements 1. Obtain a random number (see [RFC4086] for randomness requirements
for security) for security)
skipping to change at page 18, line 5 skipping to change at page 18, line 24
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers",
RFC 5453, DOI 10.17487/RFC5453, February 2009, RFC 5453, DOI 10.17487/RFC5453, February 2009,
<https://www.rfc-editor.org/info/rfc5453>. <https://www.rfc-editor.org/info/rfc5453>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <https://www.rfc-editor.org/info/rfc7136>.
[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>.
[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>.
10.2. Informative References 10.2. Informative References
[FIPS-SHS] [FIPS-SHS]
NIST, "Secure Hash Standard (SHS)", FIPS NIST, "Secure Hash Standard (SHS)", FIPS
Publication 180-4, March 2012, Publication 180-4, March 2012,
<http://csrc.nist.gov/publications/fips/fips180-4/ <http://csrc.nist.gov/publications/fips/fips180-4/
fips-180-4.pdf>. fips-180-4.pdf>.
[I-D.gont-6man-non-stable-iids]
Gont, F., Huitema, C., Krishnan, S., Gont, G., and M.
Corbo, "Recommendation on Temporary IPv6 Interface
Identifiers", draft-gont-6man-non-stable-iids-04 (work in
progress), March 2018.
[IANA-RESERVED-IID] [IANA-RESERVED-IID]
IANA, "Reserved IPv6 Interface Identifiers", IANA, "Reserved IPv6 Interface Identifiers",
<http://www.iana.org/assignments/ipv6-interface-ids>. <http://www.iana.org/assignments/ipv6-interface-ids>.
[ONION] Reed, MGR., Syverson, PFS., and DMG. Goldschlag, "Proxies [ONION] Reed, MGR., Syverson, PFS., and DMG. Goldschlag, "Proxies
for Anonymous Routing", Proceedings of the 12th Annual for Anonymous Routing", Proceedings of the 12th Annual
Computer Security Applications Conference, San Diego, CA, Computer Security Applications Conference, San Diego, CA,
December 1996. December 1996.
[OPEN-GROUP] [OPEN-GROUP]
The Open Group, "The Open Group Base Specifications Issue The Open Group, "The Open Group Base Specifications Issue
7 / IEEE Std 1003.1-2008, 2016 Edition", 7 / IEEE Std 1003.1-2008, 2016 Edition",
Section 4.16 Seconds Since the Epoch, 2016, Section 4.16 Seconds Since the Epoch, 2016,
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
contents.html>. contents.html>.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
DOI 10.17487/RFC1321, April 1992, DOI 10.17487/RFC1321, April 1992,
<https://www.rfc-editor.org/info/rfc1321>. <https://www.rfc-editor.org/info/rfc1321>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472, Considerations and Issues with IPv6 DNS", RFC 4472,
DOI 10.17487/RFC4472, April 2006, DOI 10.17487/RFC4472, April 2006,
<https://www.rfc-editor.org/info/rfc4472>. <https://www.rfc-editor.org/info/rfc4472>.
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
Socket API for Source Address Selection", RFC 5014, Socket API for Source Address Selection", RFC 5014,
DOI 10.17487/RFC5014, September 2007, DOI 10.17487/RFC5014, September 2007,
<https://www.rfc-editor.org/info/rfc5014>. <https://www.rfc-editor.org/info/rfc5014>.
skipping to change at page 19, line 34 skipping to change at page 19, line 45
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011, RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>. <https://www.rfc-editor.org/info/rfc6151>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>.
[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 [RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016, Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,
<https://www.rfc-editor.org/info/rfc7707>. <https://www.rfc-editor.org/info/rfc7707>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks / UTN-FRH SI6 Networks / UTN-FRH
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://www.si6networks.com URI: http://www.si6networks.com
 End of changes. 29 change blocks. 
64 lines changed or deleted 86 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/