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

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/