--- 1/draft-ietf-6man-rfc4941bis-01.txt 2019-07-08 17:20:16.882836592 -0700 +++ 2/draft-ietf-6man-rfc4941bis-02.txt 2019-07-08 17:20:16.926837703 -0700 @@ -1,23 +1,23 @@ IPv6 Maintenance (6man) Working Group F. Gont Internet-Draft SI6 Networks / UTN-FRH Obsoletes: rfc4941 (if approved) S. Krishnan Intended status: Standards Track Ericsson Research -Expires: September 12, 2019 T. Narten +Expires: January 9, 2020 T. Narten IBM Corporation R. Draves Microsoft Research - March 11, 2019 + July 8, 2019 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 - draft-ietf-6man-rfc4941bis-01 + draft-ietf-6man-rfc4941bis-02 Abstract Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. This document describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time. Changing the interface identifier (and the global scope addresses generated @@ -33,21 +33,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -317,21 +317,21 @@ requiring application-specific enablement. This document also assumes that an API will exist that allows individual applications to indicate whether they prefer to use temporary or stable addresses and override the system defaults. 3.2. Generation of Randomized Interface Identifiers The following subsections specify some possible algorithms for generating temporary interface identifiers that comply with the 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 algorithm specified in Section 3.2.2 allows for code reuse by nodes that implement [RFC7217]. 3.2.1. Simple Randomized Interface Identifiers One possible approach would be to select a pseudorandom number of the appropriate length. A node employing this algorithm should generate IIDs as follows: @@ -443,62 +443,59 @@ [RFC4862] describes the steps for generating a link-local address when an interface becomes enabled as well as the steps for generating addresses for other scopes. This document extends [RFC4862] as follows. When processing a Router Advertisement with a Prefix Information option carrying a global scope prefix for the purposes of address autoconfiguration (i.e., the A bit is set), the node MUST perform the following steps: 1. Process the Prefix Information Option as defined in [RFC4862], - either creating a new stable address or adjusting the lifetimes - of existing addresses, both stable and temporary. If a received - option will extend the lifetime of a stable address, the - lifetimes of temporary addresses should be extended, subject to - the overall constraint that no temporary addresses should ever - remain "valid" or "preferred" for a time longer than + adjusting the lifetimes of existing temporary addresses. If a + received option may extend the lifetimes of temporary addresses, + with 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 - DESYNC_FACTOR) respectively. The configuration variables TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to approximate target lifetimes for temporary addresses. 2. One way an implementation can satisfy the above constraints is to associate with each temporary address a creation time (called CREATION_TIME) that indicates the time at which the address was created. When updating the preferred lifetime of an existing temporary address, it would be set to expire at whichever time is earlier: the time indicated by the received lifetime or (CREATION_TIME + TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR). A similar approach can be used with the valid lifetime. - 3. When a new stable address is created as described in [RFC4862], - or if the node has not configured any temporary address for the + 3. If the node has not configured any temporary address for the corresponding prefix, the node SHOULD create a new temporary address for such prefix. 4. When creating a temporary address, the lifetime values MUST be derived from the corresponding prefix as follows: * Its Valid Lifetime is the lower of the Valid Lifetime of the prefix and TEMP_VALID_LIFETIME * Its Preferred Lifetime is the lower of the Preferred Lifetime of prefix and TEMP_PREFERRED_LIFETIME - DESYNC_FACTOR. 5. A temporary address is created only if this calculated Preferred Lifetime is greater than REGEN_ADVANCE time units. In particular, an implementation MUST NOT create a temporary address with a zero Preferred Lifetime. - 6. New temporary addresses MUST be created by appending the - interface's current randomized interface identifier to the prefix - that was received. + 6. New temporary addresses MUST be created by appending a randomized + interface identifier (generates as described in Section 3.2 of + this document) to the prefix that was received. 7. The node MUST perform duplicate address detection (DAD) on the generated temporary address. If DAD indicates the address is already in use, the node MUST generate a new randomized interface identifier, and repeat the previous steps as appropriate up to TEMP_IDGEN_RETRIES times. If after TEMP_IDGEN_RETRIES consecutive attempts no non-unique address was generated, the node MUST log a system error and MUST NOT attempt to generate temporary addresses for that interface. Note that DAD MUST be performed on every unicast address generated from this randomized @@ -567,30 +564,32 @@ new addresses varies from one environment to another, implementations SHOULD provide end users with the ability to change the frequency at which addresses are regenerated. The default value is given in TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time at which to invalidate a temporary address depends on how applications are used by end users. Thus, the suggested default value of one week (TEMP_VALID_LIFETIME) may not be appropriate in all environments. Implementations SHOULD provide end users with the ability to override both of these default values. - Finally, when an interface connects to a new link, a new set of - temporary addresses MUST be generated immediately. If a device moves - from one ethernet to another, generating a new set of temporary - addresses ensures that the device uses different randomized interface - identifiers for the temporary addresses associated with the two - links, making it more difficult to correlate addresses from the two - different links as being from the same node. The node MAY follow any - process available to it, to determine that the link change has - occurred. One such process is described by Detecting Network - Attachment [RFC4135]. + Finally, when an interface connects to a new (different) link, a new + set of temporary addresses MUST be generated immediately. If a + device moves from one ethernet to another, generating a new set of + temporary addresses ensures that the device uses different randomized + interface identifiers for the temporary addresses associated with the + two links, making it more difficult to correlate addresses from the + two different links as being from the same node. The node MAY follow + any process available to it, to determine that the link change has + occurred. One such process is described by "Simple Procedures for + 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 Devices implementing this specification MUST provide a way for the end user to explicitly enable or disable the use of temporary addresses. In addition, a site might wish to disable the use of temporary addresses in order to simplify network debugging and operations. Consequently, implementations SHOULD provide a way for trusted system administrators to enable or disable the use of temporary addresses. @@ -740,22 +739,23 @@ 8. Section 3.2.3 from [RFC4941] was removed, based on the explanation of that very section of RFC4941. 9. All the verified errata for [RFC4941] has been incorporated. 9. Acknowledgments The authors would like to thank (in alphabetical order) Brian Carpenter, Tim Chown, Lorenzo Colitti, David Farmer, Tom Herbert, Bob - Hinden, Michael Richardson, and Johanna Ullrich for providing - valuable comments on earlier versions of this document. + Hinden, Christian Huitema, Dave Plonka, Michael Richardson, Mark + 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 Krishnan was the sole author of RFC4941. He would like to acknowledge the contributions of the ipv6 working group and, in particular, Jari Arkko, Pekka Nikander, Pekka Savola, Francis Dupont, Brian Haberman, Tatuya Jinmei, and Margaret Wasserman for their detailed comments. Rich Draves and Thomas Narten were the authors of RFC 3041. They would like to acknowledge the contributions of the ipv6 working group @@ -796,24 +796,20 @@ [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC 5453, DOI 10.17487/RFC5453, February 2009, . [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . - [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 - Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, - February 2014, . - [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, . [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, "Recommendation on Stable IPv6 Interface Identifiers", RFC 8064, DOI 10.17487/RFC8064, February 2017, . @@ -850,24 +846,20 @@ [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, DOI 10.17487/RFC1321, April 1992, . [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, . - [RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network - Attachment in IPv6", RFC 4135, DOI 10.17487/RFC4135, - August 2005, . - [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational Considerations and Issues with IPv6 DNS", RFC 4472, DOI 10.17487/RFC4472, April 2006, . [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 Socket API for Source Address Selection", RFC 5014, DOI 10.17487/RFC5014, September 2007, .