--- 1/draft-ietf-6man-stable-privacy-addresses-12.txt 2013-09-03 05:14:24.405556295 -0700 +++ 2/draft-ietf-6man-stable-privacy-addresses-13.txt 2013-09-03 05:14:24.449557405 -0700 @@ -1,19 +1,19 @@ IPv6 maintenance Working Group (6man) F. Gont Internet-Draft SI6 Networks / UTN-FRH -Intended status: Standards Track August 19, 2013 -Expires: February 20, 2014 +Intended status: Standards Track September 3, 2013 +Expires: March 7, 2014 A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC) - draft-ietf-6man-stable-privacy-addresses-12 + draft-ietf-6man-stable-privacy-addresses-13 Abstract This document specifies a method for generating IPv6 Interface Identifiers to be used with IPv6 Stateless Address Autoconfiguration (SLAAC), such that addresses configured using this method are stable within each subnet, but the Interface Identifier changes when hosts move from one network to another. This method is meant to be an alternative to generating Interface Identifiers based on hardware address (e.g., using IEEE identifiers), such that the benefits of @@ -30,21 +30,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 http://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 February 20, 2014. + This Internet-Draft will expire on March 7, 2014. Copyright Notice Copyright (c) 2013 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -217,20 +217,25 @@ Address Auto-Configuration (SLAAC) [RFC4862] itself, but rather only specifies an alternative algorithm to generate Interface Identifiers. Therefore, the usual address lifetime properties (as specified in the corresponding Prefix Information Options) apply when IPv6 addresses are generated as a result of employing the algorithm specified in this document with SLAAC [RFC4862]. Additionally, from the point of view of renumbering, we note that these addresses behave like the traditional IPv6 addresses (that embed a hardware address) resulting from SLAAC [RFC4862]. + While the method specified in this document is meant to be used with + SLAAC, this does not preclude the same algorithm from being used with + other address configuration mechanisms, such as DHCPv6 [RFC3315] or + manual address configuration. + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Design goals This document specifies a method for selecting Interface Identifiers to be used with IPv6 SLAAC, with the following goals: o The resulting Interface Identifiers remain constant/stable for @@ -618,28 +623,28 @@ some of the privacy concerns arising from the use of IPv6 addresses that embed IEEE identifiers, without the use of temporary addresses, thus possibly offering an interesting trade-off for those scenarios in which the use of temporary addresses is not feasible. 8. Acknowledgements The algorithm specified in this document has been inspired by Steven Bellovin's work ([RFC1948]) in the area of TCP sequence numbers. - The author would like to thank (in alphabetical order) Ran Atkinson, - Karl Auer, Steven Bellovin, Matthias Bethke, Ben Campbell, Brian - Carpenter, Tassos Chatzithomaoglou, Tim Chown, Alissa Cooper, Dominik - Elsbroek, Brian Haberman, Bob Hinden, Christian Huitema, Ray Hunter, - Jouni Korhonen, Eliot Lear, Jong-Hyouk Lee, Andrew McGregor, Tom - Petch, Michael Richardson, Mark Smith, Dave Thaler, Ole Troan, James - Woodyatt, and He Xuan, for providing valuable comments on earlier - versions of this document. + The author would like to thank (in alphabetical order) Mikael + Abrahamsson, Ran Atkinson, Karl Auer, Steven Bellovin, Matthias + Bethke, Ben Campbell, Brian Carpenter, Tassos Chatzithomaoglou, Tim + Chown, Alissa Cooper, Dominik Elsbroek, Brian Haberman, Bob Hinden, + Christian Huitema, Ray Hunter, Jouni Korhonen, Eliot Lear, Jong-Hyouk + Lee, Andrew McGregor, Tom Petch, Michael Richardson, Mark Smith, Dave + Thaler, Ole Troan, James Woodyatt, and He Xuan, for providing + valuable comments on earlier versions of this document. This document is based on the technical report "Security Assessment of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by Fernando Gont on behalf of the UK Centre for the Protection of National Infrastructure (CPNI). Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for their continued support. 9. References @@ -648,20 +653,24 @@ [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999. + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003. [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, May 2003. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.