< draft-ietf-6man-rfc4941bis-01.txt   draft-ietf-6man-rfc4941bis-02.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: September 12, 2019 T. Narten Expires: January 9, 2020 T. Narten
IBM Corporation IBM Corporation
R. Draves R. Draves
Microsoft Research Microsoft Research
March 11, 2019 July 8, 2019
Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
draft-ietf-6man-rfc4941bis-01 draft-ietf-6man-rfc4941bis-02
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 from interface identifiers that change over time. Changing
the interface identifier (and the global scope addresses generated the interface identifier (and the global scope addresses generated
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 September 12, 2019. This Internet-Draft will expire on January 9, 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 7, line 50 skipping to change at page 7, line 50
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 comply with the
requirements in [I-D.gont-6man-non-stable-iids]. The algorithm requirements in [I-D.gont-6man-non-stable-iids]. The algorithm
specified in Section 3.2.1 benefits from a Peseudo-Random Number specified in Section 3.2.1 benefits from a Pseudo-Random Number
Generator (PRNG) available on the system. On the other hand, the Generator (PRNG) available on the system. On the other hand, the
algorithm specified in Section 3.2.2 allows for code reuse by nodes algorithm specified in Section 3.2.2 allows for code reuse by nodes
that implement [RFC7217]. that implement [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:
skipping to change at page 10, line 33 skipping to change at page 10, line 33
[RFC4862] describes the steps for generating a link-local address [RFC4862] describes the steps for generating a link-local address
when an interface becomes enabled as well as the steps for generating when an interface becomes enabled as well as the steps for generating
addresses for other scopes. This document extends [RFC4862] as addresses for other scopes. This document extends [RFC4862] as
follows. When processing a Router Advertisement with a Prefix follows. When processing a Router Advertisement with a Prefix
Information option carrying a global scope prefix for the purposes of Information option carrying a global scope prefix for the purposes of
address autoconfiguration (i.e., the A bit is set), the node MUST address autoconfiguration (i.e., the A bit is set), the node MUST
perform the following steps: perform the following steps:
1. Process the Prefix Information Option as defined in [RFC4862], 1. Process the Prefix Information Option as defined in [RFC4862],
either creating a new stable address or adjusting the lifetimes adjusting the lifetimes of existing temporary addresses. If a
of existing addresses, both stable and temporary. If a received received option may extend the lifetimes of temporary addresses,
option will extend the lifetime of a stable address, the with the overall constraint that no temporary addresses should
lifetimes of temporary addresses should be extended, subject to ever remain "valid" or "preferred" for a time longer than
the overall constraint that no temporary addresses should ever
remain "valid" or "preferred" for a time longer than
(TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME - (TEMP_VALID_LIFETIME) or (TEMP_PREFERRED_LIFETIME -
DESYNC_FACTOR) respectively. The configuration variables DESYNC_FACTOR) respectively. The configuration variables
TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to
approximate target lifetimes for temporary addresses. approximate target lifetimes for temporary addresses.
2. One way an implementation can satisfy the above constraints is to 2. One way an implementation can satisfy the above constraints is to
associate with each temporary address a creation time (called associate with each temporary address a creation time (called
CREATION_TIME) that indicates the time at which the address was CREATION_TIME) that indicates the time at which the address was
created. When updating the preferred lifetime of an existing created. When updating the preferred lifetime of an existing
temporary address, it would be set to expire at whichever time is temporary address, it would be set to expire at whichever time is
earlier: the time indicated by the received lifetime or earlier: the time indicated by the received lifetime or
(CREATION_TIME + TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR). A (CREATION_TIME + TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR). A
similar approach can be used with the valid lifetime. similar approach can be used with the valid lifetime.
3. When a new stable address is created as described in [RFC4862], 3. If the node has not configured any temporary address for the
or if the node has not configured any temporary address for the
corresponding prefix, the node SHOULD create a new temporary corresponding prefix, the node SHOULD create a new temporary
address for such prefix. address for such prefix.
4. When creating a temporary address, the lifetime values MUST be 4. When creating a temporary address, the lifetime values MUST be
derived from the corresponding prefix as follows: derived from the corresponding prefix as follows:
* Its Valid Lifetime is the lower of the Valid Lifetime of the * Its Valid Lifetime is the lower of the Valid Lifetime of the
prefix and TEMP_VALID_LIFETIME prefix and TEMP_VALID_LIFETIME
* Its Preferred Lifetime is the lower of the Preferred Lifetime * Its Preferred Lifetime is the lower of the Preferred Lifetime
of prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR. of prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR.
5. A temporary address is created only if this calculated Preferred 5. A temporary address is created only if this calculated Preferred
Lifetime is greater than REGEN_ADVANCE time units. In Lifetime is greater than REGEN_ADVANCE time units. In
particular, an implementation MUST NOT create a temporary address particular, an implementation MUST NOT create a temporary address
with a zero Preferred Lifetime. with a zero Preferred Lifetime.
6. New temporary addresses MUST be created by appending the 6. New temporary addresses MUST be created by appending a randomized
interface's current randomized interface identifier to the prefix interface identifier (generates as described in Section 3.2 of
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. Note that DAD MUST be temporary addresses for that interface. Note that DAD MUST be
performed on every unicast address generated from this randomized performed on every unicast address generated from this randomized
skipping to change at page 13, line 12 skipping to change at page 13, line 11
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 one week (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 link, a new set of Finally, when an interface connects to a new (different) link, a new
temporary addresses MUST be generated immediately. If a device moves set of temporary addresses MUST be generated immediately. If a
from one ethernet to another, generating a new set of temporary device moves from one ethernet to another, generating a new set of
addresses ensures that the device uses different randomized interface temporary addresses ensures that the device uses different randomized
identifiers for the temporary addresses associated with the two interface identifiers for the temporary addresses associated with the
links, making it more difficult to correlate addresses from the two two links, making it more difficult to correlate addresses from the
different links as being from the same node. The node MAY follow any two different links as being from the same node. The node MAY follow
process available to it, to determine that the link change has any process available to it, to determine that the link change has
occurred. One such process is described by Detecting Network occurred. One such process is described by "Simple Procedures for
Attachment [RFC4135]. Detecting Network Attachment in IPv6" [RFC6059]. Detecting link
changes would prevent link down/up events from causing temporary
addresses to be (unnecessarily) regenerated.
3.6. Deployment Considerations 3.6. Deployment Considerations
Devices implementing this specification MUST provide a way for the Devices implementing this specification MUST provide a way for the
end user to explicitly enable or disable the use of temporary end user to explicitly enable or disable the use of temporary
addresses. In addition, a site might wish to disable the use of addresses. In addition, a site might wish to disable the use of
temporary addresses in order to simplify network debugging and temporary addresses in order to simplify network debugging and
operations. Consequently, implementations SHOULD provide a way for operations. Consequently, implementations SHOULD provide a way for
trusted system administrators to enable or disable the use of trusted system administrators to enable or disable the use of
temporary addresses. temporary addresses.
skipping to change at page 16, line 41 skipping to change at page 16, line 41
8. Section 3.2.3 from [RFC4941] was removed, based on the 8. Section 3.2.3 from [RFC4941] was removed, based on the
explanation of that very section of RFC4941. explanation of that very section of RFC4941.
9. All the verified errata for [RFC4941] has been incorporated. 9. All the verified errata for [RFC4941] has been incorporated.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank (in alphabetical order) Brian The authors would like to thank (in alphabetical order) Brian
Carpenter, Tim Chown, Lorenzo Colitti, David Farmer, Tom Herbert, Bob Carpenter, Tim Chown, Lorenzo Colitti, David Farmer, Tom Herbert, Bob
Hinden, Michael Richardson, and Johanna Ullrich for providing Hinden, Christian Huitema, Dave Plonka, Michael Richardson, Mark
valuable comments on earlier versions of this document. Smith, and Johanna Ullrich for providing valuable comments on earlier
versions of this document.
This document is based on [RFC4941] (a revision of RFC3041). Suresh This document is based on [RFC4941] (a revision of RFC3041). Suresh
Krishnan was the sole author of RFC4941. He would like to Krishnan was the sole author of RFC4941. He would like to
acknowledge the contributions of the ipv6 working group and, in acknowledge the contributions of the ipv6 working group and, in
particular, Jari Arkko, Pekka Nikander, Pekka Savola, Francis Dupont, particular, Jari Arkko, Pekka Nikander, Pekka Savola, Francis Dupont,
Brian Haberman, Tatuya Jinmei, and Margaret Wasserman for their Brian Haberman, Tatuya Jinmei, and Margaret Wasserman for their
detailed comments. detailed comments.
Rich Draves and Thomas Narten were the authors of RFC 3041. They Rich Draves and Thomas Narten were the authors of RFC 3041. They
would like to acknowledge the contributions of the ipv6 working group would like to acknowledge the contributions of the ipv6 working group
skipping to change at page 18, line 5 skipping to change at page 18, line 5
[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>.
skipping to change at page 19, line 10 skipping to change at page 19, line 10
[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, [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
C., and M. Carney, "Dynamic Host Configuration Protocol C., and M. Carney, "Dynamic Host Configuration Protocol
for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
2003, <https://www.rfc-editor.org/info/rfc3315>. 2003, <https://www.rfc-editor.org/info/rfc3315>.
[RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network
Attachment in IPv6", RFC 4135, DOI 10.17487/RFC4135,
August 2005, <https://www.rfc-editor.org/info/rfc4135>.
[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>.
 End of changes. 12 change blocks. 
36 lines changed or deleted 28 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/