draft-ietf-ipv6-privacy-addrs-v2-01.txt   draft-ietf-ipv6-privacy-addrs-v2-02.txt 
IPv6 Working Group T. Narten IPv6 Working Group T. Narten
Internet-Draft IBM Corporation Internet-Draft IBM Corporation
Expires: April 22, 2005 R. Draves Expires: June 23, 2005 R. Draves
Microsoft Research Microsoft Research
S. Krishnan S. Krishnan
Ericsson Ericsson
October 22, 2004 December 23, 2004
Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
draft-ietf-ipv6-privacy-addrs-v2-01 draft-ietf-ipv6-privacy-addrs-v2-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with and any of which I become aware will be disclosed, in accordance with
RFC 3668. 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
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 April 22, 2005. This Internet-Draft will expire on June 23, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
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 41 skipping to change at page 2, line 41
3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 14 3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 14
3.3 Generating Temporary Addresses . . . . . . . . . . . . . . 14 3.3 Generating Temporary Addresses . . . . . . . . . . . . . . 14
3.4 Expiration of Temporary Addresses . . . . . . . . . . . . 15 3.4 Expiration of Temporary Addresses . . . . . . . . . . . . 15
3.5 Regeneration of Randomized Interface Identifiers . . . . . 16 3.5 Regeneration of Randomized Interface Identifiers . . . . . 16
3.6 Deployment Considerations . . . . . . . . . . . . . . . . 17 3.6 Deployment Considerations . . . . . . . . . . . . . . . . 17
4. Implications of Changing Interface Identifiers . . . . . . . . 19 4. Implications of Changing Interface Identifiers . . . . . . . . 19
5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 20 5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 20
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 22 7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 22
8. Changes from version 00 . . . . . . . . . . . . . . . . . . . 23 8. Changes from version 00 . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 9. Changes from version 01 . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . 25
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 26 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
11.2 Informative References . . . . . . . . . . . . . . . . . . . 26 12.1 Normative References . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 12.2 Informative References . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . 30
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-
bit interface identifier [ADDRARCH]. By design, the interface bit interface identifier [ADDRARCH]. By design, the interface
identifier is likely to be globally unique when generated in this identifier is likely to be globally unique when generated in this
fashion. The interface identifier is in turn appended to a prefix to fashion. The interface identifier is in turn appended to a prefix to
form a 128-bit IPv6 address. form a 128-bit IPv6 address. Note that an IPv6 identifier does not
necessarily have to be 64 bits in length, but the algorithm specified
in this document is targeted towards 64-bit interface identifiers.
All nodes combine interface identifiers (whether derived from an IEEE All nodes combine interface identifiers (whether derived from an IEEE
identifier or generated through some other technique) with the identifier or generated through some other technique) with the
reserved link-local prefix to generate link-local addresses for their reserved link-local prefix to generate link-local addresses for their
attached interfaces. Additional addresses can then be created by attached interfaces. Additional addresses can then be created by
combining prefixes advertised in Router Advertisements via Neighbor combining prefixes advertised in Router Advertisements via Neighbor
Discovery [DISCOVERY] with the interface identifier. Discovery [DISCOVERY] with the interface identifier.
Not all nodes and interfaces contain IEEE identifiers. In such Not all nodes and interfaces contain IEEE identifiers. In such
cases, an interface identifier is generated through some other means cases, an interface identifier is generated through some other means
skipping to change at page 4, line 25 skipping to change at page 4, line 25
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.
Please 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 1.2 Conventions used in this document
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 [RFC2119]. 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
skipping to change at page 6, line 35 skipping to change at page 6, line 35
address a client gets via DHCP can change over time, but in practice address a client gets via DHCP can change over time, but in practice
servers often return the same address to the same client (unless servers often return the same address to the same client (unless
addresses are in such short supply that they are reused immediately addresses are in such short supply that they are reused immediately
by a different node when they become free). Thus, even within sites by a different node when they become free). Thus, even within sites
using DHCP, clients frequently end up using the same address for using DHCP, clients frequently end up using the same address for
weeks to months at a time. weeks to months at a time.
For home users accessing the Internet over dialup lines, the For home users accessing the Internet over dialup lines, the
situation is generally different. Such users do not have permanent situation is generally different. Such users do not have permanent
connections and are often assigned temporary addresses each time they connections and are often assigned temporary addresses each time they
connect to their ISP (e.g., AOL). Consequently, the addresses they connect to their ISP. Consequently, the addresses they use change
use change frequently over time and are shared among a number of frequently over time and are shared among a number of different
different users. Thus, an address does not reliably identify a users. Thus, an address does not reliably identify a particular
particular device over time spans of more than a few minutes. device over time spans of more than a few minutes.
A more interesting case concerns always-on connections (e.g., cable A more interesting case concerns always-on connections (e.g., cable
modems, ISDN, DSL, etc.) that result in a home site using the same modems, ISDN, DSL, etc.) that result in a home site using the same
address for extended periods of time. This is a scenario that is address for extended periods of time. This is a scenario that is
just starting to become common in IPv4 and promises to become more of just starting to become common in IPv4 and promises to become more of
a concern as always-on internet connectivity becomes widely a concern as always-on internet connectivity becomes widely
available. available.
Finally, it should be noted that nodes that need a (non-changing) DNS Finally, it should be noted that nodes that need a (non-changing) DNS
name generally have static addresses assigned to them to simplify the name generally have static addresses assigned to them to simplify the
configuration of DNS servers. Although Dynamic DNS [DDNS] can be configuration of DNS servers. Although Dynamic DNS [DDNS] can be
used to update the DNS dynamically, it is not yet widely deployed. used to update the DNS dynamically, it may not always be available
In addition, changing an address but keeping the same DNS name does depending on the administrative policy. In addition, changing an
not really address the underlying concern, since the DNS name becomes address but keeping the same DNS name does not really address the
a non-changing identifier. Servers generally require a DNS name (so underlying concern, since the DNS name becomes a non-changing
clients can connect to them), and clients often do as well (e.g., identifier. Servers generally require a DNS name (so clients can
some servers refuse to speak to a client whose address cannot be connect to them), and clients often do as well (e.g., some servers
mapped into a DNS name that also maps back into the same address). refuse to speak to a client whose address cannot be mapped into a DNS
Section 4 describes one approach to this issue. name that also maps back into the same address). Section 4 describes
one approach to this issue.
2.3 The Concern With IPv6 Addresses 2.3 The Concern With IPv6 Addresses
The division of IPv6 addresses into distinct topology and interface The division of IPv6 addresses into distinct topology and interface
identifier portions raises an issue new to IPv6 in that a fixed identifier portions raises an issue new to IPv6 in that a fixed
portion of an IPv6 address (i.e., the interface identifier) can portion of an IPv6 address (i.e., the interface identifier) can
contain an identifier that remains constant even when the topology contain an identifier that remains constant even when the topology
portion of an address changes (e.g., as the result of connecting to a portion of an address changes (e.g., as the result of connecting to a
different part of the Internet). In IPv4, when an address changes, different part of the Internet). In IPv4, when an address changes,
the entire address (including the local part of the address) usually the entire address (including the local part of the address) usually
skipping to change at page 8, line 14 skipping to change at page 8, line 14
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
One way to avoid some of the problems discussed above is to use One way to avoid having a static non-changing address is to use
DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be
configured to hand out addresses that change over time. But DHCPv6 configured to hand out addresses that change over time. But DHCPv6
will solve the privacy issue only if it frequently handed out will solve the privacy issue only if it frequently handed out
constantly changing addresses to the nodes. Since this does not constantly changing addresses to the nodes. Since this does not
happen automatically, and is difficult to configure manually, DHCPv6 happen automatically, and is difficult to configure manually, DHCPv6
is not a self contained alternative for solving the privacy issues is not a self contained alternative for solving the privacy issues
addressed by this document. However, in the absence of stateless addressed by this document. However, in the absence of stateless
address autoconfiguration, DHCPv6 can be used for distributing address autoconfiguration, DHCPv6 can be used for distributing
temporary addresses to clients. temporary addresses to clients.
Another approach, compatible with the stateless address Another approach, compatible with the stateless address
autoconfiguration architecture, would be to change the interface id autoconfiguration architecture, would be to change the interface
portion of an address over time and generate new addresses from the identifier portion of an address over time and generate new addresses
interface identifier for some address scopes. Changing the interface from the interface identifier for some address scopes. Changing the
identifier can make it more difficult to look at the IP addresses in interface identifier can make it more difficult to look at the IP
independent transactions and identify which ones actually correspond addresses in independent transactions and identify which ones
to the same node, both in the case where the routing prefix portion actually correspond to the same node, both in the case where the
of an address changes and when it does not. routing prefix portion of an address changes and when it does not.
Many machines function as both clients and servers. In such cases, Many machines function as both clients and servers. In such cases,
the machine would need a DNS name for its use as a server. Whether the machine would need a DNS name for its use as a server. Whether
the address stays fixed or changes has little privacy implication the address stays fixed or changes has little privacy implication
since the DNS name remains constant and serves as a constant since the DNS name remains constant and serves as a constant
identifier. When acting as a client (e.g., initiating identifier. When acting as a client (e.g., initiating
communication), however, such a machine may want to vary the communication), however, such a machine may want to vary the
addresses it uses. In such environments, one may need multiple addresses it uses. In such environments, one may need multiple
addresses: a "public" (i.e., non-secret) server address, registered addresses: a "public" (i.e., non-secret) server address, registered
in the DNS, that is used to accept incoming connection requests from in the DNS, that is used to accept incoming connection requests from
skipping to change at page 12, line 43 skipping to change at page 12, line 43
1. Take the history value from the previous iteration of this 1. Take the history value from the previous iteration of this
algorithm (or a random value if there is no previous value) and algorithm (or a random value if there is no previous value) and
append to it the interface identifier generated as described in append to it the interface identifier generated as described in
[ADDRARCH]. [ADDRARCH].
2. Compute the MD5 message digest [MD5] over the quantity created in 2. Compute the MD5 message digest [MD5] over the quantity created in
the previous step. the previous step.
3. Take the left-most 64-bits of the MD5 digest and set bit 6 (the 3. Take the left-most 64-bits of the MD5 digest and set bit 6 (the
left-most bit is numbered 0) to zero. This creates an interface left-most bit is numbered 0) to zero. This creates an interface
identifier with the universal/local bit indicating local identifier with the universal/local bit indicating local
significance only. significance only.
4. Compare the generated identifier against a list of known values 4. Compare the generated identifier against a list of reserved
that should not be used. Inappropriate values include those used interface identifiers and to those already assigned to an address
in reserved anycast addresses [RFC2526], those used by ISATAP
[ISATAP], the value 0, and those already assigned to an address
on the local device. In the event that an unacceptable on the local device. In the event that an unacceptable
identifier has been generated, the node MUST restart the process identifier has been generated, the node MUST restart the process
at step 1 above, using the right-most 64 bits of the MD5 digest at step 1 above, using the right-most 64 bits of the MD5 digest
obtained in step 2 in place of the history value in step 1. obtained in step 2 in place of the history value in step 1.
5. Save the generated identifier as the associated randomized 5. Save the generated identifier as the associated randomized
interface identifier. interface identifier.
6. Take the rightmost 64-bits of the MD5 digest computed in step 2) 6. Take the rightmost 64-bits of the MD5 digest computed in step 2)
and save them in stable storage as the history value to be used and save them in stable storage as the history value to be used
in the next iteration of the algorithm. in the next iteration of the algorithm.
MD5 was chosen for convenience, and because its particular properties MD5 was chosen for convenience, and because its particular properties
were adequate to produce the desired level of randomization. IPv6 were adequate to produce the desired level of randomization. IPv6
nodes are already required to implement MD5 as part of IPsec [IPSEC], nodes are already required to implement MD5 as part of IPsec [IPSEC],
thus the code will already be present on IPv6 machines. thus the code will already be present on IPv6 machines.
In theory, generating successive randomized interface identifiers In theory, generating successive randomized interface identifiers
skipping to change at page 14, line 7 skipping to change at page 14, line 7
cases have configuration information that differs from one machine to cases have configuration information that differs from one machine to
another (e.g., user identity, security keys, serial numbers, etc.). another (e.g., user identity, security keys, serial numbers, etc.).
One approach to generating a random initial history value in such One approach to generating a random initial history value in such
cases is to use the configuration information to generate some data cases is to use the configuration information to generate some data
bits (which may remain constant for the life of the machine, but will bits (which may remain constant for the life of the machine, but will
vary from one machine to another), append some random data and vary from one machine to another), append some random data and
compute the MD5 digest as before. compute the MD5 digest as before.
3.2.3 Alternate approaches 3.2.3 Alternate approaches
Please note that there are other approaches to generate random Note that there are other approaches to generate random interface
interface identifiers, albeit with different goals and applicability. identifiers, albeit with different goals and applicability. One such
One such approach is CGA [CGA], which generates a random interface approach is CGA [CGA], which generates a random interface identifier
identifier based on the public key of the node. The goal of CGAs is based on the public key of the node. The goal of CGAs is to prove
to prove ownership of an address and to prevent spoofing and stealing ownership of an address and to prevent spoofing and stealing of
of existing IPv6 addresses. They are used for securing neighbor existing IPv6 addresses. They are used for securing neighbor
discovery using [SEND]. The CGA random interface identifier discovery using [SEND]. The CGA random interface identifier
generation algorithm may not be suitable for privacy addresses generation algorithm may not be suitable for privacy addresses
because of the following properties because of the following properties
o It requires the node to have a public key. This means that the o It requires the node to have a public key. This means that the
node can still be identified by its public key node can still be identified by its public key
o The random interface identifier process is computationally o The random interface identifier process is computationally
intensive and hence discourages frequent regeneration intensive and hence discourages frequent regeneration
3.3 Generating Temporary Addresses 3.3 Generating Temporary Addresses
skipping to change at page 14, line 39 skipping to change at page 14, line 39
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 [ADDRCONF], 1. Process the Prefix Information Option as defined in [ADDRCONF],
either creating a new public address or adjusting the lifetimes either creating a new public address or adjusting the lifetimes
of existing addresses, both public and temporary. If a received of existing addresses, both public and temporary. If a received
option will extend the lifetime of a public address, the option will extend the lifetime of a public address, the
lifetimes of temporary addresses should be extended, subject to lifetimes of temporary addresses should be extended, subject to
the overall constraint that no temporary addresses should ever the overall constraint that no temporary addresses should ever
remain "valid" or "preferred" for a time longer than remain "valid" or "preferred" for a time longer than
(TEMP_VALID_LIFETIME-DESYNC_FACTOR) or (TEMP_VALID_LIFETIME - DESYNC_FACTOR) or (TEMP_PREFERRED_LIFETIME
(TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR) respectively. The - DESYNC_FACTOR) respectively. The configuration variables
configuration variables TEMP_VALID_LIFETIME and TEMP_VALID_LIFETIME and TEMP_PREFERRED_LIFETIME correspond to
TEMP_PREFERRED_LIFETIME correspond to approximate target approximate target lifetimes for temporary addresses.
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 public address is created as described in [ADDRCONF],
the node SHOULD also create a new temporary address.
3. When a new public address is created as described in [ADDRCONF]
(because the prefix advertised does not match the prefix of any
address already assigned to the interface, and the Valid Lifetime
in the option is not zero), the node SHOULD also create a new
temporary address.
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
public address or TEMP_VALID_LIFETIME public address or TEMP_VALID_LIFETIME
* Its Preferred Lifetime is the lower of the Preferred Lifetime * Its Preferred Lifetime is the lower of the Preferred Lifetime
of the prefix or TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR. of the prefix or 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.
skipping to change at page 16, line 7 skipping to change at page 15, line 51
temporary address SHOULD be regenerated slightly before its temporary address SHOULD be regenerated slightly before its
predecessor is deprecated. This is to allow sufficient time to avoid predecessor is deprecated. This is to allow sufficient time to avoid
race conditions in the case where generating a new temporary address race conditions in the case where generating a new temporary address
is not instantaneous, such as when duplicate address detection must is not instantaneous, such as when duplicate address detection must
be run. The node SHOULD start the address regeneration process be run. The node SHOULD start the address regeneration process
REGEN_ADVANCE time units before a temporary address would actually be REGEN_ADVANCE time units before a temporary address would actually be
deprecated. deprecated.
As an optional optimization, an implementation MAY remove a As an optional optimization, an implementation MAY remove a
deprecated temporary address that is not in use by applications or deprecated temporary address that is not in use by applications or
upper-layers as detailed in Section 6 upper-layers as detailed in Section 6.
3.5 Regeneration of Randomized Interface Identifiers 3.5 Regeneration of Randomized Interface Identifiers
The frequency at which temporary addresses changes depends on how a The frequency at which temporary addresses changes depends on how a
device is being used (e.g., how frequently it initiates new device is being used (e.g., how frequently it initiates new
communication) and the concerns of the end user. The most egregious communication) and the concerns of the end user. The most egregious
privacy concerns appear to involve addresses used for long periods of privacy concerns appear to involve addresses used for long periods of
time (weeks to months to years). The more frequently an address time (weeks to months to years). The more frequently an address
changes, the less feasible collecting or coordinating information changes, the less feasible collecting or coordinating information
keyed on interface identifiers becomes. Moreover, the cost of keyed on interface identifiers becomes. Moreover, the cost of
skipping to change at page 17, line 24 skipping to change at page 17, line 12
Finally, when an interface connects to a new link, a new randomized Finally, when an interface connects to a new link, a new randomized
interface identifier SHOULD be generated immediately together with a interface identifier SHOULD be generated immediately together with a
new set of temporary addresses. If a device moves from one ethernet new set of temporary addresses. If a device moves from one ethernet
to another, generating a new set of temporary addresses from a to another, generating a new set of temporary addresses from a
different randomized interface identifier ensures that the device different randomized interface identifier ensures that the device
uses different randomized interface identifiers for the temporary uses different randomized interface identifiers for the temporary
addresses associated with the two links, making it more difficult to addresses associated with the two links, making it more difficult to
correlate addresses from the two different links as being from the correlate addresses from the two different links as being from the
same node. The node MAY follow any process available to it, to same node. The node MAY follow any process available to it, to
determine that the link change has occurred. One such process is determine that the link change has occurred. One such process is
described by Detecting Network Attachment [DNA] described by Detecting Network Attachment [DNA].
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 17, line 46 skipping to change at page 17, line 34
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-prefix setting SHOULD override the global settings on the node per-prefix setting SHOULD override the global settings on the node
with respect to the specified prefix subranges. with respect to the specified prefix subranges. Note that the
pre-prefix setting can be applied at any granularity, and not
necessarily on a 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 an 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
applications, which have specific knowledge about the normal duration applications, which have specific knowledge about the normal duration
of connections, MAY override this as appropriate. of connections, MAY override this as appropriate.
If a very small number of nodes(say only one) use a given prefix for If a very small number of nodes(say only one) use a given prefix for
extended periods of time, just changing the interface identifier extended periods of time, just changing the interface identifier part
part of the prefix may not be sufficient to ensure privacy, since of the address may not be sufficient to ensure privacy, since the
the prefix acts as a constant identifier. The procedures described prefix acts as a constant identifier. The procedures described in
in this document are most effective when the prefix is reasonably non this document are most effective when the prefix is reasonably non
static or is used by a fairly large number of nodes static or is used by a fairly large number of nodes.
4. Implications of Changing Interface Identifiers 4. Implications of Changing Interface Identifiers
The IPv6 addressing architecture goes to some lengths to ensure that The IPv6 addressing architecture goes to some lengths to ensure that
interface identifiers are likely to be globally unique where easy to interface identifiers are likely to be globally unique where easy to
do so. The widespread use of temporary addresses may result in a do so. The widespread use of temporary addresses may result in a
significant fraction of Internet traffic not using addresses in which significant fraction of Internet traffic not using addresses in which
the interface id portion is globally unique. Consequently, usage of the interface identifier portion is globally unique. Consequently,
the algorithms in this document may complicate providing such a usage of the algorithms in this document may complicate providing
future flexibility, if global uniqueness is necessary. such a future flexibility, if global uniqueness is necessary.
The desires of protecting individual privacy vs. the desire to The desires of protecting individual privacy versus the desire to
effectively maintain and debug a network can conflict with each effectively maintain and debug a network can conflict with each
other. Having clients use addresses that change over time will make other. Having clients use addresses that change over time will make
it more difficult to track down and isolate operational problems. it more difficult to track down and isolate operational problems.
For example, when looking at packet traces, it could become more For example, when looking at packet traces, it could become more
difficult to determine whether one is seeing behavior caused by a difficult to determine whether one is seeing behavior caused by a
single errant machine, or by a number of them. single errant machine, or by a number of them.
Some servers refuse to grant access to clients for which no DNS name Some servers refuse to grant access to clients for which no DNS name
exists. That is, they perform a DNS PTR query to determine the DNS exists. That is, they perform a DNS PTR query to determine the DNS
name, and may then also perform an AAAA query on the returned name to name, and may then also perform an AAAA query on the returned name to
skipping to change at page 21, line 20 skipping to change at page 21, line 20
protocols are using it (but not before). This is in contrast to protocols are using it (but not before). This is in contrast to
current approaches where addresses are removed from an interface when current approaches where addresses are removed from an interface when
they become invalid [ADDRCONF], independent of whether or not upper they become invalid [ADDRCONF], independent of whether or not upper
layer protocols are still using them. For TCP connections, such layer protocols are still using them. For TCP connections, such
information is available in control blocks. For UDP-based information is available in control blocks. For UDP-based
applications, it may be the case that only the applications have applications, it may be the case that only the applications have
knowledge about what addresses are actually in use. Consequently, an knowledge about what addresses are actually in use. Consequently, an
implementation generally will need to use heuristics in deciding when implementation generally will need to use heuristics in deciding when
an address is no longer in use. an address is no longer in use.
The determination as to whether to use public vs. temporary The determination as to whether to use public versus temporary
addresses can in some cases only be made by an application. For addresses can in some cases only be made by an application. For
example, some applications may always want to use temporary example, some applications may always want to use temporary
addresses, while others may want to use them only in some addresses, while others may want to use them only in some
circumstances or not at all. Suitable API extensions will likely circumstances or not at all. Suitable API extensions will likely
need to be developed to enable individual applications to indicate need to be developed to enable individual applications to indicate
with sufficient granularity their needs with regards to the use of with sufficient granularity their needs with regards to the use of
temporary addresses. Recommendations on DNS practices to avoid the temporary addresses. Recommendations on DNS practices to avoid the
problem described in Section 4 when reverse DNS lookups fail may be problem described in Section 4 when reverse DNS lookups fail may be
needed. [DNSOP] contains a more detailed discussion of the DNS needed. [DNSOP] contains a more detailed discussion of the DNS
related issues. related issues.
skipping to change at page 22, line 33 skipping to change at page 23, line 4
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.
11. DAD is now performed on all unicast addresses created from the
same interface identifier instead of just the first one
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 1. The algorithm used for generating random interface identifiers is
no longer restricted to just MD5 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. Security Considerations 9. Changes from version 01
This section summarizes the changes from version 01 of this draft
1. Clarifiying the length of interface identifier
2. Added a per-prefix enable/disable knob as a SHOULD to retain
backward compatibility
3. Removed normative reference to ISATAP to avoid downref problem
4. Added text for per-prefix knobs to be applied at any granularity
5. Moved RFC2526 to informative reference
10. 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.
10. Acknowledgements 11. 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, and Francis Dupont for their detailed comments. Pekka Savola, Francis Dupont, Brian Haberman, and Tatuya Jinmei for
their detailed comments.
11. References 12. References
11.1 Normative References 12.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", draft-ietf-ipv6-rfc2462bis-06 Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-06
(work in progress), September 2004. (work in progress), September 2004.
skipping to change at page 26, line 36 skipping to change at page 27, line 36
[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.
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast 12.2 Informative References
Addresses", RFC 2526, March 1999.
11.2 Informative References
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-06 (work in progress), April 2004. draft-ietf-send-cga-06 (work in progress), April 2004.
[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, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136, Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997. April 1997.
skipping to change at page 27, line 18 skipping to change at page 28, line 15
[DNA] Choi, J. and G. Daley, "Detecting Network Attachment in [DNA] Choi, J. and G. Daley, "Detecting Network Attachment in
IPv6 Goals", draft-ietf-dna-goals-01 (work in progress), IPv6 Goals", draft-ietf-dna-goals-01 (work in progress),
September 2004. September 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",
draft-ietf-dnsop-ipv6-dns-issues-09 (work in progress), draft-ietf-dnsop-ipv6-dns-issues-09 (work in progress),
August 2004. August 2004.
[ISATAP] Templin, F., Gleeson, T., Talwar, M. and D. Thaler,
"Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", draft-ietf-ngtrans-isatap-22 (work in
progress), May 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
Addresses", RFC 2526, March 1999.
[SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
Nikander, "SEcure Neighbor Discovery (SEND)", Nikander, "SEcure Neighbor Discovery (SEND)",
draft-ietf-send-ndopt-06 (work in progress), July 2004. draft-ietf-send-ndopt-06 (work in progress), July 2004.
[ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [ULA] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in Addresses", draft-ietf-ipv6-unique-local-addr-05 (work in
progress), June 2004. progress), June 2004.
Authors' Addresses Authors' Addresses
 End of changes. 

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