draft-ietf-ipv6-privacy-addrs-v2-03.txt   draft-ietf-ipv6-privacy-addrs-v2-04.txt 
IPv6 Working Group T. Narten IPv6 Working Group T. Narten
Internet-Draft IBM Corporation Internet-Draft IBM Corporation
Expires: October 6, 2005 R. Draves Expires: November 25, 2005 R. Draves
Microsoft Research Microsoft Research
S. Krishnan S. Krishnan
Ericsson Ericsson Research
April 4, 2005 May 24, 2005
Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
draft-ietf-ipv6-privacy-addrs-v2-03 draft-ietf-ipv6-privacy-addrs-v2-04
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 6, 2005. This Internet-Draft will expire on November 25, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
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
skipping to change at page 2, line 21 skipping to change at page 2, line 19
causes nodes to generate global scope addresses from interface causes nodes to generate global scope addresses from interface
identifiers that change over time, even in cases where the interface identifiers that change over time, even in cases where the interface
contains an embedded IEEE identifier. Changing the interface contains an embedded IEEE identifier. Changing the interface
identifier (and the global scope addresses generated from it) over identifier (and the global scope addresses generated from it) over
time makes it more difficult for eavesdroppers and other information time makes it more difficult for eavesdroppers and other information
collectors to identify when different addresses used in different collectors to identify when different addresses used in different
transactions actually correspond to the same node. transactions actually correspond to the same node.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 5 1.1 Conventions used in this document . . . . . . . . . . . . 4
1.2 Conventions used in this document . . . . . . . . . . . . 5 1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Extended Use of the Same Identifier . . . . . . . . . . . 6 2.1 Extended Use of the Same Identifier . . . . . . . . . . . 5
2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 7 2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 6
2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 8 2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 7
2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 9 2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 8
3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 11 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10
3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11 3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Generation Of Randomized Interface Identifiers . . . . . . 13 3.2 Generation Of Randomized Interface Identifiers . . . . . . 12
3.2.1 When Stable Storage Is Present . . . . . . . . . . . . 13 3.2.1 When Stable Storage Is Present . . . . . . . . . . . . 12
3.2.2 In The Absence of Stable Storage . . . . . . . . . . . 14 3.2.2 In The Absence of Stable Storage . . . . . . . . . . . 13
3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 15 3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 14
3.3 Generating Temporary Addresses . . . . . . . . . . . . . . 15 3.3 Generating Temporary Addresses . . . . . . . . . . . . . . 14
3.4 Expiration of Temporary Addresses . . . . . . . . . . . . 16 3.4 Expiration of Temporary Addresses . . . . . . . . . . . . 15
3.5 Regeneration of Randomized Interface Identifiers . . . . . 17 3.5 Regeneration of Randomized Interface Identifiers . . . . . 16
3.6 Deployment Considerations . . . . . . . . . . . . . . . . 18 3.6 Deployment Considerations . . . . . . . . . . . . . . . . 17
4. Implications of Changing Interface Identifiers . . . . . . . . 20 4. Implications of Changing Interface Identifiers . . . . . . . . 19
5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 21 5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 20
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 23 7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 22
8. Changes from version 00 . . . . . . . . . . . . . . . . . . . 24 8. Changes from version 00 . . . . . . . . . . . . . . . . . . . 23
9. Changes from version 01 . . . . . . . . . . . . . . . . . . . 25 9. Changes from version 01 . . . . . . . . . . . . . . . . . . . 24
10. Changes from version 02 . . . . . . . . . . . . . . . . . . 26 10. Changes from version 02 . . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . 27 11. Changes from version 03 . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 12. Security Considerations . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
13.1 Normative References . . . . . . . . . . . . . . . . . . . 29 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
13.2 Informative References . . . . . . . . . . . . . . . . . . 29 14.1 Normative References . . . . . . . . . . . . . . . . . . . 29
14.2 Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . 32 Intellectual Property and Copyright Statements . . . . . . . . 32
1. Introduction 1. Introduction
Stateless address autoconfiguration [ADDRCONF] defines how an IPv6 Stateless address autoconfiguration [ADDRCONF] defines how an IPv6
node generates addresses without the need for a DHCPv6 server. Some node generates addresses without the need for a DHCPv6 server. Some
types of network interfaces come with an embedded IEEE Identifier types of network interfaces come with an embedded IEEE Identifier
(i.e., a link-layer MAC address), and in those cases stateless (i.e., a link-layer MAC address), and in those cases stateless
address autoconfiguration uses the IEEE identifier to generate a 64- address autoconfiguration uses the IEEE identifier to generate a 64-
skipping to change at page 5, line 5 skipping to change at page 4, line 5
help mitigate those concerns for individual users and in environments help mitigate those concerns for individual users and in environments
where such concerns are significant. Section 2 provides background where such concerns are significant. Section 2 provides background
information on the issue. Section 3 describes a procedure for information on the issue. Section 3 describes a procedure for
generating alternate interface identifiers and global scope generating alternate interface identifiers and global scope
addresses. Section 4 discusses implications of changing interface addresses. Section 4 discusses implications of changing interface
identifiers. The term "global scope addresses" is used in this identifiers. The term "global scope addresses" is used in this
document to collectively refer to "Global unicast addresses" as document to collectively refer to "Global unicast addresses" as
defined in [ADDRARCH] and "Unique local addresses" as defined in defined in [ADDRARCH] and "Unique local addresses" as defined in
[ULA] [ULA]
1.1 Problem Statement 1.1 Conventions used in this document
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 [RFC2119].
1.2 Problem Statement
Addresses generated using Stateless address autoconfiguration Addresses generated using Stateless address autoconfiguration
[ADDRCONF]contain an embedded interface identifier, which remains [ADDRCONF]contain an embedded interface identifier, which remains
constant over time. Anytime a fixed identifier is used in multiple constant over time. Anytime a fixed identifier is used in multiple
contexts, it becomes possible to correlate seemingly unrelated contexts, it becomes possible to correlate seemingly unrelated
activity using this identifier. activity using this identifier.
The correlation can be performed by The correlation can be performed by
o An attacker who is in the path between the node in question and o An attacker who is in the path between the node in question and
the peer(s) it is communicating to, and can view the IPv6 the peer(s) it is communicating to, and can view the IPv6
addresses present in the datagrams. addresses present in the datagrams.
o An attacker who can access the communication logs of the peers o An attacker who can access the communication logs of the peers
with which the node has communicated. with which the node has communicated.
Since the identifier is embedded within the IPv6 address, which is a Since the identifier is embedded within the IPv6 address, which is a
fundamental requirement of communication, it cannot be easily hidden. fundamental requirement of communication, it cannot be easily hidden.
This document proposes a solution to this issue by generating This document proposes a solution to this issue by generating
interface identifiers which vary over time. interface identifiers which vary over time.
Note that an attacker, who is on path, may be able to perform Note that an attacker, who is on path, may be able to perform
significant correlation based on significant correlation based on
skipping to change at page 5, line 27 skipping to change at page 4, line 35
o An attacker who can access the communication logs of the peers o An attacker who can access the communication logs of the peers
with which the node has communicated. with which the node has communicated.
Since the identifier is embedded within the IPv6 address, which is a Since the identifier is embedded within the IPv6 address, which is a
fundamental requirement of communication, it cannot be easily hidden. fundamental requirement of communication, it cannot be easily hidden.
This document proposes a solution to this issue by generating This document proposes a solution to this issue by generating
interface identifiers which vary over time. interface identifiers which vary over time.
Note that an attacker, who is on path, may be able to perform Note that an attacker, who is on path, may be able to perform
significant correlation based on significant correlation based on
o The payload contents of the packets on the wire o The payload contents of the packets on the wire
o The characteristics of the packets such as packet size and timing o The characteristics of the packets such as packet size and timing
Use of temporary addresses will not prevent such payload based Use of temporary addresses will not prevent such payload based
correlation. correlation.
1.2 Conventions used in this document
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 [RFC2119].
2. Background 2. Background
This section discusses the problem in more detail, provides context This section discusses the problem in more detail, provides context
for evaluating the significance of the concerns in specific for evaluating the significance of the concerns in specific
environments and makes comparisons with existing practices. environments and makes comparisons with existing practices.
2.1 Extended Use of the Same Identifier 2.1 Extended Use of the Same Identifier
The use of a non-changing interface identifier to form addresses is a The use of a non-changing interface identifier to form addresses is a
specific instance of the more general case where a constant specific instance of the more general case where a constant
identifier is reused over an extended period of time and in multiple identifier is reused over an extended period of time and in multiple
independent activities. Anytime the same identifier is used in independent activities. Anytime the same identifier is used in
multiple contexts, it becomes possible for that identifier to be used multiple contexts, it becomes possible for that identifier to be used
to correlate seemingly unrelated activity. For example, a network to correlate seemingly unrelated activity. For example, a network
sniffer placed strategically on a link across which all traffic sniffer placed strategically on a link across which all traffic to/
to/from a particular host crosses could keep track of which from a particular host crosses could keep track of which destinations
destinations a node communicated with and at what times. Such a node communicated with and at what times. Such information can in
information can in some cases be used to infer things, such as what some cases be used to infer things, such as what hours an employee
hours an employee was active, when someone is at home, etc. Although was active, when someone is at home, etc. Although it might appear
it might appear that changing an address regularly in such that changing an address regularly in such environments would be
environments would be desirable to lessen privacy concerns, it should desirable to lessen privacy concerns, it should be noted that the
be noted that the network prefix portion of an address also serves as network prefix portion of an address also serves as a constant
a constant identifier. All nodes at (say) a home, would have the identifier. All nodes at (say) a home, would have the same network
same network prefix, which identifies the topological location of prefix, which identifies the topological location of those nodes.
those nodes. This has implications for privacy, though not at the This has implications for privacy, though not at the same granularity
same granularity as the concern that this document addresses. as the concern that this document addresses. Specifically, all nodes
Specifically, all nodes within a home could be grouped together for within a home could be grouped together for the purposes of
the purposes of collecting information. If the network contains a collecting information. If the network contains a very small number
very small number of nodes, say just one, changing just the interface of nodes, say just one, changing just the interface identifier will
identifier will not enhance privacy at all, since the prefix serves not enhance privacy at all, since the prefix serves as a constant
as a constant identifier. identifier.
One of the requirements for correlating seemingly unrelated One of the requirements for correlating seemingly unrelated
activities is the use (and reuse) of an identifier that is activities is the use (and reuse) of an identifier that is
recognizable over time within different contexts. IP addresses recognizable over time within different contexts. IP addresses
provide one obvious example, but there are more. Many nodes also provide one obvious example, but there are more. Many nodes also
have DNS names associated with their addresses, in which case the DNS have DNS names associated with their addresses, in which case the DNS
name serves as a similar identifier. Although the DNS name name serves as a similar identifier. Although the DNS name
associated with an address is more work to obtain (it may require a associated with an address is more work to obtain (it may require a
DNS query) the information is often readily available. In such DNS query) the information is often readily available. In such
cases, changing the address on a machine over time would do little to cases, changing the address on a machine over time would do little to
skipping to change at page 8, line 46 skipping to change at page 7, line 46
Internet connectivity both at home and at the office. While the Internet connectivity both at home and at the office. While the
node's address changes as it moves, however, the interface identifier node's address changes as it moves, however, the interface identifier
contained within the address remains the same (when derived from an contained within the address remains the same (when derived from an
IEEE Identifier). In such cases, the interface identifier can be IEEE Identifier). In such cases, the interface identifier can be
used to track the movement and usage of a particular machine. For used to track the movement and usage of a particular machine. For
example, a server that logs usage information together with a source example, a server that logs usage information together with a source
addresses, is also recording the interface identifier since it is addresses, is also recording the interface identifier since it is
embedded within an address. Consequently, any data-mining technique embedded within an address. Consequently, any data-mining technique
that correlates activity based on addresses could easily be extended that correlates activity based on addresses could easily be extended
to do the same using the interface identifier. This is of particular to do the same using the interface identifier. This is of particular
concern with the expected proliferation of next-generation concern with the expected proliferation of next-generation network-
network-connected devices (e.g., PDAs, cell phones, etc.) in which connected devices (e.g., PDAs, cell phones, etc.) in which large
large numbers of devices are in practice associated with individual numbers of devices are in practice associated with individual users
users (i.e., not shared). Thus, the interface identifier embedded (i.e., not shared). Thus, the interface identifier embedded within
within an address could be used to track activities of an individual, an address could be used to track activities of an individual, even
even as they move topologically within the internet. as they move topologically within the internet.
In summary, IPv6 addresses on a given interface generated via In summary, IPv6 addresses on a given interface generated via
Stateless Autoconfiguration contain the same interface identifier, Stateless Autoconfiguration contain the same interface identifier,
regardless of where within the Internet the device connects. This regardless of where within the Internet the device connects. This
facilitates the tracking of individual devices (and thus potentially facilitates the tracking of individual devices (and thus potentially
users). The purpose of this document is to define mechanisms that users). The purpose of this document is to define mechanisms that
eliminate this issue, in those situations where it is a concern. eliminate this issue, in those situations where it is a concern.
2.4 Possible Approaches 2.4 Possible Approaches
skipping to change at page 11, line 11 skipping to change at page 10, line 11
random component and the globally unique interface identifier (when random component and the globally unique interface identifier (when
available), to increase the likelihood that different nodes generate available), to increase the likelihood that different nodes generate
different sequences. different sequences.
3. Protocol Description 3. Protocol Description
The goal of this section is to define procedures that: The goal of this section is to define procedures that:
1. Do not result in any changes to the basic behavior of addresses 1. Do not result in any changes to the basic behavior of addresses
generated via stateless address autoconfiguration [ADDRCONF]. generated via stateless address autoconfiguration [ADDRCONF].
2. Create additional global scope addresses based on a random
interface identifier for use with global scope addresses.Such 2. Create additional addresses based on a random interface
addresses would be used to initiate outgoing sessions. These identifier for the purpose of initiating outgoing sessions These
"random" or temporary addresses would be used for a short period "random" or temporary addresses would be used for a short period
of time (hours to days) and would then be deprecated. Deprecated of time (hours to days) and would then be deprecated. Deprecated
address can continue to be used for already established address can continue to be used for already established
connections, but are not used to initiate new connections. New connections, but are not used to initiate new connections. New
temporary addresses are generated periodically to replace temporary addresses are generated periodically to replace
temporary addresses that expire, with the exact time between temporary addresses that expire, with the exact time between
address generation a matter of local policy. address generation a matter of local policy.
3. Produce a sequence of temporary global scope addresses from a 3. Produce a sequence of temporary global scope addresses from a
sequence of interface identifiers that appear to be random in the sequence of interface identifiers that appear to be random in the
sense that it is difficult for an outside observer to predict a sense that it is difficult for an outside observer to predict a
future address (or identifier) based on a current one and it is future address (or identifier) based on a current one and it is
difficult to determine previous addresses (or identifiers) difficult to determine previous addresses (or identifiers)
knowing only the present one. knowing only the present one.
4. By default, generate a set of addresses from the same 4. By default, generate a set of addresses from the same
(randomized) interface identifier, one address for each prefix (randomized) interface identifier, one address for each prefix
for which a global address has been generated via stateless for which a global address has been generated via stateless
address autoconfiguration. Using the same interface identifier address autoconfiguration. Using the same interface identifier
to generate a set of temporary addresses reduces the number of IP to generate a set of temporary addresses reduces the number of IP
multicast groups a host must join. Nodes join the solicited-node multicast groups a host must join. Nodes join the solicited-node
multicast address for each unicast address they support, and multicast address for each unicast address they support, and
solicited-node addresses are dependent only on the low-order bits solicited-node addresses are dependent only on the low-order bits
of the corresponding address. This default behaviour was made to of the corresponding address. This default behaviour was made to
address the concern that a node that joins a large number of address the concern that a node that joins a large number of
skipping to change at page 11, line 52 skipping to change at page 11, line 6
addresses that cannot be easily tied to each other. For example addresses that cannot be easily tied to each other. For example
a node MAY create different interface identifiers I1,I2, and I3 a node MAY create different interface identifiers I1,I2, and I3
for use with different prefixes P1,P2, and P3 on the same for use with different prefixes P1,P2, and P3 on the same
interface. interface.
3.1 Assumptions 3.1 Assumptions
The following algorithm assumes that each interface maintains an The following algorithm assumes that each interface maintains an
associated randomized interface identifier. When temporary addresses associated randomized interface identifier. When temporary addresses
are generated, the current value of the associated randomized are generated, the current value of the associated randomized
interface identifier is used. The actual value of the identifier interface identifier is used. While the same identifier can be used
changes over time as described below, but the same identifier can be to create more than one temporary address, the value SHOULD change
used to generate more than one temporary address. over time as described in Section 3.5.
The algorithm also assumes that for a given temporary address, an The algorithm also assumes that for a given temporary address, an
implementation can determine the prefix from which it was generated. implementation can determine the prefix from which it was generated.
When a temporary address is deprecated, a new temporary address is When a temporary address is deprecated, a new temporary address is
generated. The specific valid and preferred lifetimes for the new generated. The specific valid and preferred lifetimes for the new
address are dependent on the corresponding lifetime values set for address are dependent on the corresponding lifetime values set for
the prefix from which it was generated. the prefix from which it was generated.
Finally, this document assumes that when a node initiates outgoing Finally, this document assumes that when a node initiates outgoing
communication, temporary addresses can be given preference over communication, temporary addresses can be given preference over
skipping to change at page 18, line 32 skipping to change at page 17, line 43
temporary addresses. temporary addresses.
Additionally, sites might wish to selectively enable or disable the Additionally, sites might wish to selectively enable or disable the
use of temporary addresses for some prefixes. For example, a site use of temporary addresses for some prefixes. For example, a site
might wish to disable temporary address generation for "Unique local" might wish to disable temporary address generation for "Unique local"
[ULA] prefixes while still generating temporary addresses for all [ULA] prefixes while still generating temporary addresses for all
other global prefixes. Another site might wish to enable temporary other global prefixes. Another site might wish to enable temporary
address generation only for the prefixes 2001::/16 and 2002::/16 address generation only for the prefixes 2001::/16 and 2002::/16
while disabling it for all other prefixes. To support this behavior, while disabling it for all other prefixes. To support this behavior,
implementations SHOULD provide a way to enable and disable generation implementations SHOULD provide a way to enable and disable generation
of temporary addresses for specific prefix subranges. This of temporary addresses for specific prefix subranges. This per-
per-prefix setting SHOULD override the global settings on the node prefix setting SHOULD override the global settings on the node with
with respect to the specified prefix subranges. Note that the respect to the specified prefix subranges. Note that the pre-prefix
pre-prefix setting can be applied at any granularity, and not setting can be applied at any granularity, and not necessarily on a
necessarily on a per subnet basis. per subnet basis.
The use of temporary addresses may cause unexpected difficulties with The use of temporary addresses may cause unexpected difficulties with
some applications. As described below, some servers refuse to accept some applications. As described below, some servers refuse to accept
communications from clients for which they cannot map the IP address communications from clients for which they cannot map the IP address
into a DNS name. In addition, some applications may not behave into a DNS name. In addition, some applications may not behave
robustly if temporary addresses are used and an address expires robustly if temporary addresses are used and an address expires
before the application has terminated, or if it opens multiple before the application has terminated, or if it opens multiple
sessions, but expects them to all use the same addresses. sessions, but expects them to all use the same addresses.
Consequently, the use of temporary addresses SHOULD be disabled by Consequently, the use of temporary addresses SHOULD be disabled by
default in order to minimize potential disruptions. Individual default in order to minimize potential disruptions. Individual
skipping to change at page 23, line 9 skipping to change at page 22, line 9
administrator of the host and the administrator of the router may administrator of the host and the administrator of the router may
have different opinions about the use of temporary addresses. Any have different opinions about the use of temporary addresses. Any
configuration mechanism that disables the use of temporary addresses configuration mechanism that disables the use of temporary addresses
without input from the user MUST ensure that the host's administrator without input from the user MUST ensure that the host's administrator
has authorized the disabling. has authorized the disabling.
7. Significant Changes from RFC 3041 7. Significant Changes from RFC 3041
This section summarizes the changes in this document relative to RFC This section summarizes the changes in this document relative to RFC
3041 that an implementer of RFC 3041 should be aware of. 3041 that an implementer of RFC 3041 should be aware of.
1. Added wording to exclude certain interface identifiers from the 1. Added wording to exclude certain interface identifiers from the
range of acceptable interface identifiers. Interface IDs such range of acceptable interface identifiers. Interface IDs such
as 0, those for reserved anycast addresses [RFC2526], etc. as 0, those for reserved anycast addresses [RFC2526], etc.
2. Added a configuration knob that provides the end user with a way 2. Added a configuration knob that provides the end user with a way
to enable or disable the use of temporary addresses. to enable or disable the use of temporary addresses.
3. Under RFC 3041, RAs with short lifetimes (e.g., 1 hour) that 3. Under RFC 3041, RAs with short lifetimes (e.g., 1 hour) that
always send the same lifetime for long periods of time (e.g., always send the same lifetime for long periods of time (e.g.,
days to weeks) resulted in temporary addresses being created days to weeks) resulted in temporary addresses being created
with lifetimes of only 1 hour. Additional rules were added to with lifetimes of only 1 hour. Additional rules were added to
increase the Lifetime of temporary addresses when the advertised increase the Lifetime of temporary addresses when the advertised
lifetimes were short. lifetimes were short.
4. DAD is now run on all temporary addresses, not just the first one
generated from an interface identifier. 4. DAD is now run on all temporary addresses, not just the first
one generated from an interface identifier.
5. Changed the default setting for usage of temporary addresses to 5. Changed the default setting for usage of temporary addresses to
be disabled. be disabled.
6. Added a security considerations section to highlight the ingress 6. Added a security considerations section to highlight the ingress
filtering issues which can be caused by the use of temporary filtering issues which can be caused by the use of temporary
addresses as described in this document addresses as described in this document
7. Removed references to site-local addresses 7. Removed references to site-local addresses
8. Added a check for denial of service attacks using low valid 8. Added a check for denial of service attacks using low valid
lifetimes in router advertisements lifetimes in router advertisements
9. Changed the document to use RFC2119 language 9. Changed the document to use RFC2119 language
10. The node is now allowed to generate different interface 10. The node is now allowed to generate different interface
identifiers for different prefixes, if it so desires. identifiers for different prefixes, if it so desires.
8. Changes from version 00 8. Changes from version 00
This section summarizes the changes from version 00 of this draft This section summarizes the changes from version 00 of this draft
1. The algorithm used for generating random interface identifiers is
no longer restricted to just MD5 1. The algorithm used for generating random interface identifiers
is no longer restricted to just MD5
2. Added a problem statement 2. Added a problem statement
3. Classified the references into normative and informative 3. Classified the references into normative and informative
4. Reduced default number of retries to 3 from 5 and added a 4. Reduced default number of retries to 3 from 5 and added a
configuration variable configuration variable
5. Removed text about RA processing which is duplicated from 5. Removed text about RA processing which is duplicated from
[ADDRCONF] [ADDRCONF]
6. Added text about the privacy implications of a non-changing 6. Added text about the privacy implications of a non-changing
prefix prefix
7. Added a per-prefix enable/disable setting 7. Added a per-prefix enable/disable setting
8. Added text about the means of correlation 8. Added text about the means of correlation
9. Clarified text about DHCPv6 9. Clarified text about DHCPv6
10. Added reference to dnsop issues draft 10. Added reference to dnsop issues draft
9. Changes from version 01 9. Changes from version 01
This section summarizes the changes from version 01 of this draft This section summarizes the changes from version 01 of this draft
1. Clarifiying the length of interface identifier 1. Clarifiying the length of interface identifier
2. Added a per-prefix enable/disable knob as a SHOULD to retain 2. Added a per-prefix enable/disable knob as a SHOULD to retain
backward compatibility backward compatibility
3. Removed normative reference to ISATAP to avoid downref problem 3. Removed normative reference to ISATAP to avoid downref problem
4. Added text for per-prefix knobs to be applied at any granularity 4. Added text for per-prefix knobs to be applied at any granularity
5. Moved RFC2526 to informative reference 5. Moved RFC2526 to informative reference
10. Changes from version 02 10. Changes from version 02
This section summarizes the changes from version 02 of this draft This section summarizes the changes from version 02 of this draft
1. Explained briefly the concern that is being addressed in the 1. Explained briefly the concern that is being addressed in the
introduction introduction
2. Removed reference to 64 bit identifiers in the ADDRCONF context 2. Removed reference to 64 bit identifiers in the ADDRCONF context
3. Added clarifying text for the usage of DHCPv6 as an alternate 3. Added clarifying text for the usage of DHCPv6 as an alternate
approach approach
4. Moved RFC3484 to informative reference 4. Moved RFC3484 to informative reference
5. Updated references for SEND, and CGA as they became RFCs 5. Updated references for SEND, and CGA as they became RFCs
6. Updated draft versions for ULA, DNSOP issues, 2461bis, 2462bis 6. Updated draft versions for ULA, DNSOP issues, 2461bis, 2462bis
and DNA goals and DNA goals
11. Security Considerations 11. Changes from version 03
This section summarizes the changes from version 03 of this draft
1. Added additional clarifying text regarding regeneration of
identifiers as proposed in the AD(Margaret Wasserman) review
comments.
2. Clarified confusing text which seemed to imply that the randomnly
generated identigiers could only be used with global scope
addresses.
3. Switched to the new IPR boilerplate
12. Security Considerations
Ingress filtering has been and is being deployed as a means of Ingress filtering has been and is being deployed as a means of
preventing the use of spoofed source addresses in Distributed Denial preventing the use of spoofed source addresses in Distributed Denial
of Service(DDoS) attacks. In a network with a large number of nodes, of Service(DDoS) attacks. In a network with a large number of nodes,
new temporary addresses are created at a fairly high rate. This new temporary addresses are created at a fairly high rate. This
might make it difficult for ingress filtering mechanisms to might make it difficult for ingress filtering mechanisms to
distinguish between legitimately changing temporary addresses and distinguish between legitimately changing temporary addresses and
spoofed source addresses, which are "in-prefix"(They use a spoofed source addresses, which are "in-prefix"(They use a
topologically correct prefix and non-existent interface ID). This topologically correct prefix and non-existent interface ID). This
can be addressed by using access control mechanisms on a per address can be addressed by using access control mechanisms on a per address
basis on the network egress point. basis on the network egress point.
12. Acknowledgements 13. Acknowledgements
The authors would like to acknowledge the contributions of the ipv6 The authors would like to acknowledge the contributions of the ipv6
working group and, in particular, Ran Atkinson, Matt Crawford, Steve working group and, in particular, Ran Atkinson, Matt Crawford, Steve
Deering, Allison Mankin, Peter Bieringer, Jari Arkko, Pekka Nikander, Deering, Allison Mankin, Peter Bieringer, Jari Arkko, Pekka Nikander,
Pekka Savola, Francis Dupont, Brian Haberman, and Tatuya Jinmei for Pekka Savola, Francis Dupont, Brian Haberman, Tatuya Jinmei and
their detailed comments. Margaret Wasserman for their detailed comments.
13. References 14. References
13.1 Normative References 14.1 Normative References
[ADDRARCH] [ADDRARCH]
Hinden, R. and S. Deering, "Internet Protocol Version 6 Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003. (IPv6) Addressing Architecture", RFC 3513, April 2003.
[ADDRCONF] [ADDRCONF]
Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-07
Internet-Draft draft-ietf-ipv6-rfc2462bis-07, December (work in progress), December 2004.
2004.
[DISCOVERY] [DISCOVERY]
Narten, T., Nordmark, E., Simpson, W. and H. Soliman, Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", "Neighbor Discovery for IP version 6 (IPv6)",
Internet-Draft draft-ietf-ipv6-2461bis-02, February 2005. draft-ietf-ipv6-2461bis-02 (work in progress),
February 2005.
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
13.2 Informative References 14.2 Informative References
[ADDR_SELECT] [ADDR_SELECT]
Draves, R., "Default Address Selection for Internet Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[COOKIES] Kristol, D. and L. Montulli, "HTTP State Management [COOKIES] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000. Mechanism", RFC 2965, October 2000.
[DDNS] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [DDNS] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, "Dynamic Updates in the Domain Name System (DNS UPDATE)",
April 1997. RFC 2136, April 1997.
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", [DHCP] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997. RFC 2131, March 1997.
[DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
M. Carney, "Dynamic Host Configuration Protocol for IPv6 and M. Carney, "Dynamic Host Configuration Protocol for
(DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[DNA] Choi, J. and G. Daley, "Detecting Network Attachment in [DNA] Choi, J. and G. Daley, "Detecting Network Attachment in
IPv6 Goals", Internet-Draft draft-ietf-dna-goals-04, IPv6 Goals", draft-ietf-dna-goals-04 (work in progress),
December 2004. December 2004.
[DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational [DNSOP] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", Considerations and Issues with IPv6 DNS",
Internet-Draft draft-ietf-dnsop-ipv6-dns-issues-10, draft-ietf-dnsop-ipv6-dns-issues-10 (work in progress),
October 2004. October 2004.
[ONION] Reed, MGR., Syverson, PFS. and DMG. Goldschlag, "Proxies [ONION] Reed, MGR., Syverson, PFS., and DMG. Goldschlag, "Proxies
for Anonymous Routing", Proceedings of the 12th Annual for Anonymous Routing", Proceedings of the 12th Annual
Computer Security Applications Conference, San Diego, CA, Computer Security Applications Conference, San Diego, CA,
December 1996. December 1996.
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [RANDOM] Eastlake, D., Crocker, S., and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
[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.
[SEND] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in
Internet-Draft draft-ietf-ipv6-unique-local-addr-09, progress), January 2005.
January 2005.
Authors' Addresses Authors' Addresses
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@raleigh.ibm.com Email: narten@raleigh.ibm.com
Richard Draves Richard Draves
Microsoft Research Microsoft Research
One Microsoft Way One Microsoft Way
Redmond, WA Redmond, WA
USA USA
Email: richdr@microsoft.com Email: richdr@microsoft.com
Suresh Krishnan Suresh Krishnan
Ericsson 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
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/