draft-ietf-6man-rfc4941bis-06.txt   draft-ietf-6man-rfc4941bis-07.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: August 12, 2020 T. Narten Expires: August 29, 2020 T. Narten
IBM Corporation IBM Corporation
R. Draves R. Draves
Microsoft Research Microsoft Research
February 9, 2020 February 26, 2020
Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
draft-ietf-6man-rfc4941bis-06 draft-ietf-6man-rfc4941bis-07
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 with randomized interface identifiers that change over addresses with randomized interface identifiers that change over
time. Changing global scope addresses over time makes it more time. Changing global scope addresses over time makes it more
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 August 12, 2020. This Internet-Draft will expire on August 29, 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 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 43 skipping to change at page 2, line 43
3.3.2. Hash-based Generation of Randomized Interface 3.3.2. Hash-based Generation of Randomized Interface
Identifiers . . . . . . . . . . . . . . . . . . . . . 9 Identifiers . . . . . . . . . . . . . . . . . . . . . 9
3.4. Generating Temporary Addresses . . . . . . . . . . . . . 10 3.4. Generating Temporary Addresses . . . . . . . . . . . . . 10
3.5. Expiration of Temporary Addresses . . . . . . . . . . . . 12 3.5. Expiration of Temporary Addresses . . . . . . . . . . . . 12
3.6. Regeneration of Temporary Addresses . . . . . . . . . . . 12 3.6. Regeneration of Temporary Addresses . . . . . . . . . . . 12
3.7. Implementation Considerations . . . . . . . . . . . . . . 14 3.7. Implementation Considerations . . . . . . . . . . . . . . 14
3.8. Defined Constants . . . . . . . . . . . . . . . . . . . . 14 3.8. Defined Constants . . . . . . . . . . . . . . . . . . . . 14
4. Implications of Changing Interface Identifiers . . . . . . . 15 4. Implications of Changing Interface Identifiers . . . . . . . 15
5. Significant Changes from RFC4941 . . . . . . . . . . . . . . 16 5. Significant Changes from RFC4941 . . . . . . . . . . . . . . 16
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19 9.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Changes from RFC4941 [to be removed by the RFC- Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
Editor before publication . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Stateless address autoconfiguration (SLAAC) [RFC4862] defines how an Stateless address autoconfiguration (SLAAC) [RFC4862] defines how an
IPv6 node generates addresses without the need for a Dynamic Host IPv6 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. This is a revision of RFC4941, aforementioned issues are mitigated. This is a revision of RFC4941,
and formally obsoletes RFC4941. Section 5 describes the changes from and formally obsoletes RFC4941. Section 5 describes the changes from
[RFC4941]. [RFC4941].
The default address selection for IPv6 has been specified in The default address selection for IPv6 has been specified in
[RFC6724]. The determination as to whether to use stable versus [RFC6724]. The determination as to whether to use stable versus
temporary addresses can in some cases only be made by an application. temporary addresses can in some cases only be made by an application.
For example, some applications may always want to use temporary For example, some applications may always want to use temporary
addresses, while others may want to use them only in some addresses, while others may want to use them only in some
circumstances or not at all. An API such as that specified in circumstances or not at all. An Application Programming Interface
[RFC5014] can enable individual applications to indicate a preference (API) such as that specified in [RFC5014] can enable individual
for the use of temporary addresses. applications to indicate a preference for the use of temporary
addresses.
Section 2 provides background information on the issue. Section 3 Section 2 provides background information on the issue. Section 3
describes a procedure for generating temporary interface identifiers describes a procedure for generating temporary addresses. Section 4
and global scope addresses. Section 4 discusses implications of discusses implications of changing interface identifiers (IIDs).
changing interface identifiers. Section 5 describes the changes from Section 5 describes the changes from [RFC4941].
[RFC4941].
1.1. Terminology 1.1. Terminology
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.
The terms "public address", "stable address", "temporary address", The terms "public address", "stable address", "temporary address",
skipping to change at page 12, line 13 skipping to change at page 12, line 13
this document) to the prefix that was received. this document) to the prefix that was received.
7. The node MUST perform duplicate address detection (DAD) on the 7. The node MUST perform duplicate address detection (DAD) on the
generated temporary address. If DAD indicates the address is generated temporary address. If DAD indicates the address is
already in use, the node MUST generate a new randomized interface already in use, the node MUST generate a new randomized interface
identifier, and repeat the previous steps as appropriate up to identifier, and repeat the previous steps as appropriate up to
TEMP_IDGEN_RETRIES times. If after TEMP_IDGEN_RETRIES TEMP_IDGEN_RETRIES times. If after TEMP_IDGEN_RETRIES
consecutive attempts no non-unique address was generated, the consecutive attempts no non-unique address was generated, the
node MUST log a system error and MUST NOT attempt to generate node MUST log a system error and MUST NOT attempt to generate
temporary addresses for that interface. This allows hosts to temporary addresses for that interface. This allows hosts to
recover from ocassional DAD failures, or otherwhise log the recover from occasional DAD failures, or otherwise log the
recurrent address collissions. recurrent address collisions.
3.5. Expiration of Temporary Addresses 3.5. Expiration of Temporary Addresses
When a temporary address becomes deprecated, a new one MUST be When a temporary address becomes deprecated, a new one MUST be
generated. This is done by repeating the actions described in generated. This is done by repeating the actions described in
Section 3.4, starting at step 4). Note that, except for the Section 3.4, starting at step 4). Note that, except for the
transient period when a temporary address is being regenerated, in transient period when a temporary address is being regenerated, in
normal operation at most one temporary address per prefix should be normal operation at most one temporary address per prefix should be
in a non-deprecated state at any given time on a given interface. in a non-deprecated state at any given time on a given interface.
Note that if a temporary address becomes deprecated as result of Note that if a temporary address becomes deprecated as result of
skipping to change at page 13, line 33 skipping to change at page 13, line 33
expires, a new temporary address MUST be generated using the new expires, a new temporary address MUST be generated using the new
randomized interface identifier. randomized interface identifier.
Because the precise frequency at which it is appropriate to generate Because the precise frequency at which it is appropriate to generate
new addresses varies from one environment to another, implementations new addresses varies from one environment to another, implementations
SHOULD provide end users with the ability to change the frequency at SHOULD provide end users with the ability to change the frequency at
which addresses are regenerated. The default value is given in which addresses are regenerated. The default value is given in
TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time
at which to invalidate a temporary address depends on how at which to invalidate a temporary address depends on how
applications are used by end users. Thus, the suggested default applications are used by end users. Thus, the suggested default
value of one week (TEMP_VALID_LIFETIME) may not be appropriate in all value of two days (TEMP_VALID_LIFETIME) may not be appropriate in all
environments. Implementations SHOULD provide end users with the environments. Implementations SHOULD provide end users with the
ability to override both of these default values. ability to override both of these default values.
Finally, when an interface connects to a new (different) link, a new Finally, when an interface connects to a new (different) link, a new
set of temporary addresses MUST be generated immediately for use on set of temporary addresses MUST be generated immediately for use on
the new link. If a device moves from one link to another, generating the new link. If a device moves from one link to another, generating
a new set of temporary addresses ensures that the device uses a new set of temporary addresses ensures that the device uses
different randomized interface identifiers for the temporary different randomized interface identifiers for the temporary
addresses associated with the two links, making it more difficult to addresses associated with the two links, making it more difficult to
correlate addresses from the two different links as being from the correlate addresses from the two different links as being from the
skipping to change at page 14, line 40 skipping to change at page 14, line 40
debugging and other operational troubleshooting activities. debugging and other operational troubleshooting activities.
Consequently, it may be site policy that temporary addresses should Consequently, it may be site policy that temporary addresses should
not be used. Consequently, implementations MUST provide a method for not be used. Consequently, implementations MUST provide a method for
the end user or trusted administrator to override the use of the end user or trusted administrator to override the use of
temporary addresses. temporary addresses.
3.8. Defined Constants 3.8. Defined Constants
Constants defined in this document include: Constants defined in this document include:
TEMP_VALID_LIFETIME -- Default value: 1 week. Users should be able TEMP_VALID_LIFETIME -- Default value: 2 days. Users should be able
to override the default value. to override the default value.
TEMP_PREFERRED_LIFETIME -- Default value: 1 day. Users should be TEMP_PREFERRED_LIFETIME -- Default value: 1 day. Users should be
able to override the default value. able to override the default value.
REGEN_ADVANCE -- 5 seconds REGEN_ADVANCE -- 5 seconds
MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR. MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR.
DESYNC_FACTOR -- A random value within the range 0 - DESYNC_FACTOR -- A random value within the range 0 -
skipping to change at page 16, line 13 skipping to change at page 16, line 13
use the same addresses. use the same addresses.
5. Significant Changes from RFC4941 5. Significant Changes from RFC4941
This section summarizes the changes in this document relative to RFC This section summarizes the changes in this document relative to RFC
4941 that an implementer of RFC 4941 should be aware of. 4941 that an implementer of RFC 4941 should be aware of.
Broadly speaking, this document introduces the following changes: Broadly speaking, this document introduces the following changes:
o Addresses a number of flaws in the algorithm for generating o Addresses a number of flaws in the algorithm for generating
temporary addresses (see [RAID2015] and [RFC7721]). temporary addresses: The aforementioned flaws include the use of
MD5 for computing the temporary IIDs, and reusing the same IID for
multiple prefixes (see [RAID2015] and [RFC7721] for further
details).
o Allows hosts to employ only temporary addresses (i.e. o Allows hosts to employ only temporary addresses:
configuration of stable addresses is no longer implied or [RFC4941] assumed that temporary addresses were configured in
required). addition to stable addresses. This document does not imply or
require the configuration of stable addresses, and thus
implementations can now configure both stable and temporary
addresses, or temporary addresses only.
o Suggests that temporary addresses be enabled by default (in line o Recommends that temporary addresses be enabled by default:
with [RFC7258]). Enabling temporary addresses by default is in line with BCP188
([RFC7258]), and also with BCP204 ([RFC7934]).
o Reduces the default Valid Lifetime for temporary addresses:
The default Valid Lifetime for temporary addresses has been
reduced from 1 week to 2 days, decreasing the typical number of
concurrent temporary addresses from 7 to 2. This reduces the
possible stress on network elements (see Section 4 for further
details).
o Addresses all errata submitted for [RFC4941]. o Addresses all errata submitted for [RFC4941].
6. Future Work 6. Future Work
An implementation might want to keep track of which addresses are An implementation might want to keep track of which addresses are
being used by upper layers so as to be able to remove a deprecated being used by upper layers so as to be able to remove a deprecated
temporary address from internal data structures once no upper layer temporary address from internal data structures once no upper layer
protocols are using it (but not before). This is in contrast to protocols are using it (but not before). This is in contrast to
current approaches where addresses are removed from an interface when current approaches where addresses are removed from an interface when
skipping to change at page 18, line 47 skipping to change at page 19, line 11
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <https://www.rfc-editor.org/info/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,
"Recommendation on Stable IPv6 Interface Identifiers",
RFC 8064, DOI 10.17487/RFC8064, February 2017,
<https://www.rfc-editor.org/info/rfc8064>.
[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>.
[RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda, [RFC8190] Bonica, R., Cotton, M., Haberman, B., and L. Vegoda,
"Updates to the Special-Purpose IP Address Registries", "Updates to the Special-Purpose IP Address Registries",
BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017, BCP 153, RFC 8190, DOI 10.17487/RFC8190, June 2017,
<https://www.rfc-editor.org/info/rfc8190>. <https://www.rfc-editor.org/info/rfc8190>.
9.2. Informative References 9.2. Informative References
skipping to change at page 20, line 9 skipping to change at page 20, line 16
Ullrich, J. and E. Weippl, "Privacy is Not an Option: Ullrich, J. and E. Weippl, "Privacy is Not an Option:
Attacking the IPv6 Privacy Extension", International Attacking the IPv6 Privacy Extension", International
Symposium on Recent Advances in Intrusion Detection Symposium on Recent Advances in Intrusion Detection
(RAID), 2015, <https://www.sba-research.org/wp- (RAID), 2015, <https://www.sba-research.org/wp-
content/uploads/publications/Ullrich2015Privacy.pdf>. content/uploads/publications/Ullrich2015Privacy.pdf>.
[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>.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472,
DOI 10.17487/RFC4472, April 2006,
<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>.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, Detecting Network Attachment in IPv6", RFC 6059,
DOI 10.17487/RFC6059, November 2010, DOI 10.17487/RFC6059, November 2010,
<https://www.rfc-editor.org/info/rfc6059>. <https://www.rfc-editor.org/info/rfc6059>.
skipping to change at page 21, line 26 skipping to change at page 21, line 26
[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>.
[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi,
"Host Address Availability Recommendations", BCP 204, "Host Address Availability Recommendations", BCP 204,
RFC 7934, DOI 10.17487/RFC7934, July 2016, RFC 7934, DOI 10.17487/RFC7934, July 2016,
<https://www.rfc-editor.org/info/rfc7934>. <https://www.rfc-editor.org/info/rfc7934>.
[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>.
Appendix A. Changes from RFC4941 [to be removed by the RFC-Editor
before publication
The following changes have been introduced by this document:
1. Discussion of IIDs based on IEEE identifiers has been removed,
since the current recommendation ([RFC8064]) is to employ
[RFC7217]).
2. The document employs the terminology from [RFC7721].
3. Sections 2.2 and 2.3 of [RFC4941] have been removed since the
topic has been discussed in more detail in e.g. [RFC7721].
4. The algorithm specified in Section 3.2.1 and 3.2.2 of [RFC4941]
was replaced by two possible alternative algorithms.
5. Generation of stable addresses is not implied or required by this
document.
6. Temporary addresses are enabled by default, in the light of
[RFC7258].
7. Section 3.2.3 from [RFC4941] was removed, based on the
explanation of that very section of RFC4941.
8. All the verified errata for [RFC4941] has been incorporated.
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: https://www.si6networks.com
Suresh Krishnan Suresh Krishnan
Ericsson Research Ericsson Research
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
Thomas Narten Thomas Narten
IBM Corporation IBM Corporation
P.O. Box 12195 P.O. Box 12195
Research Triangle Park, NC Research Triangle Park, NC
USA USA
Email: narten@us.ibm.com Email: narten@us.ibm.com
Richard Draves Richard Draves
Microsoft Research Microsoft Research
 End of changes. 20 change blocks. 
73 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/