draft-ietf-ipv6-privacy-addrs-v2-00.txt   draft-ietf-ipv6-privacy-addrs-v2-01.txt 
IPv6 Working Group T. Narten IPv6 Working Group T. Narten
Internet-Draft IBM Corporation Internet-Draft IBM Corporation
Expires: March 16, 2005 R. Draves Expires: April 22, 2005 R. Draves
Microsoft Research Microsoft Research
S. Krishnan S. Krishnan
Ericsson Ericsson
September 15, 2004 October 22, 2004
Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
draft-ietf-ipv6-privacy-addrs-v2-00 draft-ietf-ipv6-privacy-addrs-v2-01
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 36 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 March 16, 2005. This Internet-Draft will expire on April 22, 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 without the necessity of a Dynamic Host Configuration addresses using a combination of locally available information and
Protocol (DHCP) server. Addresses are formed by combining network information advertised by routers. Addresses are formed by combining
prefixes with an interface identifier. On interfaces that contain network prefixes with an interface identifier. On interfaces that
embedded IEEE Identifiers, the interface identifier is typically contain embedded IEEE Identifiers, the interface identifier is
derived from it. On other interface types, the interface identifier typically derived from it. On other interface types, the interface
is generated through other means, for example, via random number identifier is generated through other means, for example, via random
generation. This document describes an extension to IPv6 stateless number generation. This document describes an extension to IPv6
address autoconfiguration for interfaces whose interface identifier stateless address autoconfiguration for interfaces whose interface
is derived from an IEEE identifier. Use of the extension causes identifier is derived from an IEEE identifier. Use of the extension
nodes to generate global scope addresses from interface identifiers causes nodes to generate global scope addresses from interface
that change over time, even in cases where the interface contains an identifiers that change over time, even in cases where the interface
embedded IEEE identifier. Changing the interface identifier (and the contains an embedded IEEE identifier. Changing the interface
global scope addresses generated from it) over time makes it more identifier (and the global scope addresses generated from it) over
difficult for eavesdroppers and other information collectors to time makes it more difficult for eavesdroppers and other information
identify when different addresses used in different transactions collectors to identify when different addresses used in different
actually correspond to the same node. transactions actually correspond to the same node.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Conventions used in this document . . . . . . . . . . . . 3 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Conventions used in this document . . . . . . . . . . . . 4
2.1 Extended Use of the Same Identifier . . . . . . . . . . . 4 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 5 2.1 Extended Use of the Same Identifier . . . . . . . . . . . 5
2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 6 2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 6
2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 7 2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 7
3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 9 2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 8
3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 9 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10
3.2 Generation Of Randomized Interface Identifiers . . . . . . 11 3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 When Stable Storage Is Present . . . . . . . . . . . . 11 3.2 Generation Of Randomized Interface Identifiers . . . . . . 12
3.2.2 In The Absence of Stable Storage . . . . . . . . . . . 12 3.2.1 When Stable Storage Is Present . . . . . . . . . . . . 12
3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 13 3.2.2 In The Absence of Stable Storage . . . . . . . . . . . 13
3.3 Generating Temporary Addresses . . . . . . . . . . . . . . 13 3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 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 . . . . . 15 3.5 Regeneration of Randomized Interface Identifiers . . . . . 16
3.6 Deployment Considerations . . . . . . . . . . . . . . . . 16 3.6 Deployment Considerations . . . . . . . . . . . . . . . . 17
4. Implications of Changing Interface Identifiers . . . . . . . . 18 4. Implications of Changing Interface Identifiers . . . . . . . . 19
5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 19 5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 20
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 20 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 21
7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 21 7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 22
8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 8. Changes from version 00 . . . . . . . . . . . . . . . . . . . 23
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 24 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . 26 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 26
11.2 Informative References . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . 29
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 DHCP 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.
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
(e.g., at random), and the resultant interface identifier is not (e.g., at random), and the resultant interface identifier may not be
globally unique and may also change over time. The focus of this globally unique and may also change over time. The focus of this
document is on addresses derived from IEEE identifiers, as the document is on addresses derived from IEEE identifiers, as the
concern being addressed exists only in those cases where the concern being addressed exists only in those cases where the
interface identifier is globally unique and non-changing. The rest interface identifier is globally unique and non-changing. The rest
of this document assumes that IEEE identifiers are being used, but of this document assumes that IEEE identifiers are being used, but
the techniques described may also apply to interfaces with other the techniques described may also apply to interfaces with other
types of globally unique and/or persistent identifiers. types of globally unique and/or persistent identifiers.
This document discusses concerns associated with the embedding of This document discusses concerns associated with the embedding of
non-changing interface identifiers within IPv6 addresses and non-changing interface identifiers within IPv6 addresses and
skipping to change at page 3, line 48 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 Conventions used in this document 1.1 Problem Statement
Addresses generated using Stateless address autoconfiguration
[ADDRCONF]contain an embedded 64-bit interface identifier, which
remains constant over time. Anytime a fixed identifier is used in
multiple contexts, it becomes possible to correlate seemingly
unrelated activity using this identifier.
The correlation can be performed by
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
addresses present in the datagrams.
o An attacker who can access the communication logs of the peers
with which the node has communicated.
Since the identifier is embedded within the IPv6 address, which is a
fundamental requirement of communication, it cannot be easily hidden.
This document proposes a solution to this issue by generating
interface identifiers which vary over time.
Please note that an attacker, who is on path, may be able to perform
significant correlation based on
o The payload contents of the packets on the wire
o The characteristics of the packets such as packet size and timing
Use of temporary addresses will not prevent such payload based
correlation
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
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.
skipping to change at page 4, line 23 skipping to change at page 5, line 23
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 to/ sniffer placed strategically on a link across which all traffic to/
from a particular host crosses could keep track of which destinations from a particular host crosses could keep track of which destinations
a node communicated with and at what times. Such information can in a node communicated with and at what times. Such information can in
some cases be used to infer things, such as what hours an employee some cases be used to infer things, such as what hours an employee
was active, when someone is at home, etc. was active, when someone is at home, etc. Although it might appear
that changing an address regularly in such environments would be
desirable to lessen privacy concerns, it should be noted that the
network prefix portion of an address also serves as a constant
identifier. All nodes at (say) a home, would have the same network
prefix, which identifies the topological location of those nodes.
This has implications for privacy, though not at the same granularity
as the concern that this document addresses. Specifically, all nodes
within a home could be grouped together for the purposes of
collecting information. If the network contains a very small number
of nodes, say just one, changing just the interface identifier will
not enhance privacy at all, since the prefix serves as a constant
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 5, line 9 skipping to change at page 6, line 21
other parties. Even when higher layers encrypt their payloads, other parties. Even when higher layers encrypt their payloads,
addresses in packet headers appear in the clear. Consequently, if a addresses in packet headers appear in the clear. Consequently, if a
mobile host (e.g., laptop) accessed the network from several mobile host (e.g., laptop) accessed the network from several
different locations, an eavesdropper might be able to track the different locations, an eavesdropper might be able to track the
movement of that mobile host from place to place, even if the upper movement of that mobile host from place to place, even if the upper
layer payloads were encrypted. layer payloads were encrypted.
2.2 Address Usage in IPv4 Today 2.2 Address Usage in IPv4 Today
Addresses used in today's Internet are often non-changing in practice Addresses used in today's Internet are often non-changing in practice
for extended periods of time, especially in non-home environments for extended periods of time. In an increasing number of sites,
(e.g., corporations, campuses, etc.). In such sites, addresses are addresses are assigned statically and typically change infrequently.
assigned statically and typically change infrequently. Over the last Over the last few years, sites have begun moving away from static
few years, sites have begun moving away from static allocation to allocation to dynamic allocation via DHCP [DHCP]. In theory, the
dynamic allocation via DHCP [DHCP]. In theory, the address a client address a client gets via DHCP can change over time, but in practice
gets via DHCP can change over time, but in practice servers often servers often return the same address to the same client (unless
return the same address to the same client (unless addresses are in addresses are in such short supply that they are reused immediately
such short supply that they are reused immediately by a different by a different node when they become free). Thus, even within sites
node when they become free). Thus, even within sites using DHCP, using DHCP, clients frequently end up using the same address for
clients frequently end up using the same address for weeks to months weeks to months at a time.
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 (e.g., AOL). Consequently, the addresses they
use change frequently over time and are shared among a number of use change frequently over time and are shared among a number of
different users. Thus, an address does not reliably identify a different users. Thus, an address does not reliably identify a
particular device over time spans of more than a few minutes. particular 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. Although it might appear that changing an address available.
regularly in such environments would be desirable to lessen privacy
concerns, it should be noted that the network prefix portion of an
address also serves as a constant identifier. All nodes at (say) a
home, would have the same network prefix, which identifies the
topological location of those nodes. This has implications for
privacy, though not at the same granularity as the concern that this
document addresses. Specifically, all nodes within a home would be
grouped together for the purposes of collecting information. This
issue is difficult to address, because the routing prefix part of an
address contains topology information and cannot contain arbitrary
values.
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 is not yet widely deployed.
In addition, changing an address but keeping the same DNS name does In addition, changing an address but keeping the same DNS name does
not really address the underlying concern, since the DNS name becomes not really address the underlying concern, since the DNS name becomes
a non-changing identifier. Servers generally require a DNS name (so a non-changing identifier. Servers generally require a DNS name (so
clients can connect to them), and clients often do as well (e.g., clients can connect to them), and clients often do as well (e.g.,
some servers refuse to speak to a client whose address cannot be some servers refuse to speak to a client whose address cannot be
skipping to change at page 6, line 33 skipping to change at page 7, line 33
user's address could contain an interface identifier that remains the user's address could contain an interface identifier that remains the
same from one dialup session to the next, even if the rest of the same from one dialup session to the next, even if the rest of the
address changes. The way PPP is used today, however, PPP servers address changes. The way PPP is used today, however, PPP servers
typically unilaterally inform the client what address they are to use typically unilaterally inform the client what address they are to use
(i.e., the client doesn't generate one on its own). This practice, (i.e., the client doesn't generate one on its own). This practice,
if continued in IPv6, would avoid the concerns that are the focus of if continued in IPv6, would avoid the concerns that are the focus of
this document. this document.
A more troubling case concerns mobile devices (e.g., laptops, PDAs, A more troubling case concerns mobile devices (e.g., laptops, PDAs,
etc.) that move topologically within the Internet. Whenever they etc.) that move topologically within the Internet. Whenever they
move (in the absence of technology such as mobile IP [MOBILEIP]), move they form new addresses for their current topological point of
they form new addresses for their current topological point of
attachment. This is typified today by the "road warrior" who has attachment. This is typified today by the "road warrior" who has
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
skipping to change at page 7, 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 DHCP One way to avoid some of the problems discussed above is to use
for obtaining addresses. With DHCP, the DHCP server could arrange to DHCPv6 [DHCPV6] for obtaining addresses. The DHCPv6 server could be
hand out addresses that change over time. configured to hand out addresses that change over time. But DHCPv6
will solve the privacy issue only if it frequently handed out
constantly changing addresses to the nodes. Since this does not
happen automatically, and is difficult to configure manually, DHCPv6
is not a self contained alternative for solving the privacy issues
addressed by this document. However, in the absence of stateless
address autoconfiguration, DHCPv6 can be used for distributing
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 id
portion of an address over time and generate new addresses from the portion of an address over time and generate new addresses from the
interface identifier for some address scopes. Changing the interface interface identifier for some address scopes. Changing the interface
identifier can make it more difficult to look at the IP addresses in identifier can make it more difficult to look at the IP addresses in
independent transactions and identify which ones actually correspond independent transactions and identify which ones actually correspond
to the same node, both in the case where the routing prefix portion to the same node, both in the case where the routing prefix portion
of an address changes and when it does not. of an address changes and when it does not.
skipping to change at page 9, line 42 skipping to change at page 10, line 42
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
multicast groups may be required to put its interface into multicast groups may be required to put its interface into
promiscuous mode, resulting in possible reduced performance. promiscuous mode, resulting in possible reduced performance.
A node highly concerned about privacy MAY use different interface A node highly concerned about privacy MAY use different interface
identifiers on different prefixes, resulting in a set of global identifiers on different prefixes, resulting in a set of global
addresses that cannot be easily tied to each other. This may be addresses that cannot be easily tied to each other. For example
useful, for example, to a mobile node using multiple wireless a node MAY create different interface identifiers I1,I2, and I3
interfaces to connect to multiple independent networks. for use with different prefixes P1,P2, and P3 on the same
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. The actual value of the identifier
changes over time as described below, but the same identifier can be changes over time as described below, but the same identifier can be
used to generate more than one temporary address. used to generate more than one temporary address.
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 corresponding public address from implementation can determine the prefix from which it was generated.
which it was generated. When a temporary address is deprecated, a When a temporary address is deprecated, a new temporary address is
new temporary address is generated. The specific valid and preferred generated. The specific valid and preferred lifetimes for the new
lifetimes for the new address are dependent on the corresponding address are dependent on the corresponding lifetime values set for
lifetime values in the public address. 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
public addresses, when the device is configured to do so. This is public addresses, when the device is configured to do so.
consistent with on-going work that addresses the topic of [ADDR_SELECT] mandates implementations to provide a mechanism, which
source-address selection in the more general case [ADDR_SELECT] and allows an application to configure its preference for temporary
also means that all connections initiated by the node can use addresses over public addresses. It also allows for an
temporary addresses without requiring application-specific implementation to prefer temporary addresses by default, so that the
enablement. This document also assumes that an API will exist that connections initiated by the node can use temporary addresses without
allows individual applications to indicate whether they prefer to use requiring application-specific enablement. This document also
temporary or public addresses and override the system defaults. assumes that an API will exist that allows individual applications to
indicate whether they prefer to use temporary or public addresses and
override the system defaults.
3.2 Generation Of Randomized Interface Identifiers 3.2 Generation Of Randomized Interface Identifiers
We describe two approaches for the generation and maintenance of the We describe two approaches for the generation and maintenance of the
randomized interface identifier. The first assumes the presence of randomized interface identifier. The first assumes the presence of
stable storage that can be used to record state history for use as stable storage that can be used to record state history for use as
input into the next iteration of the algorithm across system input into the next iteration of the algorithm across system
restarts. A second approach addresses the case where stable storage restarts. A second approach addresses the case where stable storage
is unavailable and there is a need to generate randomized interface is unavailable and there is a need to generate randomized interface
identifiers without previous state. identifiers without previous state.
The random interface identifier generation algorithm, as described in
this document, uses MD5 as the hash algorithm. The node MAY use
another algorithm instead of MD5 to produce the random interface
identifier.
3.2.1 When Stable Storage Is Present 3.2.1 When Stable Storage Is Present
The following algorithm assumes the presence of a 64-bit "history The following algorithm assumes the presence of a 64-bit "history
value" that is used as input in generating a randomized interface value" that is used as input in generating a randomized interface
identifier. The very first time the system boots (i.e., out-of-the- identifier. The very first time the system boots (i.e., out-of-the-
box), a random value SHOULD be generated using techniques that help box), a random value SHOULD be generated using techniques that help
ensure the initial value is hard to guess [RANDOM]. Whenever a new ensure the initial value is hard to guess [RANDOM]. Whenever a new
interface identifier is generated, a value generated by the interface identifier is generated, a value generated by the
computation is saved in the history value for the next iteration of computation is saved in the history value for the next iteration of
the algorithm. the algorithm.
skipping to change at page 13, line 12 skipping to change at page 14, line 12
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 Please note that there are other approaches to generate random
interface identifiers, albeit with different goals and applicability. interface identifiers, albeit with different goals and applicability.
One such approach is CGA [CGA], which generates a random interface One such approach is CGA [CGA], which generates a random interface
identifier based on the public key of the node. The goal of CGAs is identifier based on the public key of the node. The goal of CGAs is
to prove ownership of an address and to prevent spoofing and stealing to prove ownership of an address and to prevent spoofing and stealing
of existing IPv6 addresses. The CGA random interface identifier of existing IPv6 addresses. They are used for securing neighbor
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
[ADDRCONF] describes the steps for generating a link-local address [ADDRCONF] describes the steps for generating a link-local address
when an interface becomes enabled as well as the steps for generating when an interface becomes enabled as well as the steps for generating
addresses for other scopes. This document extends [ADDRCONF] as addresses for other scopes. This document extends [ADDRCONF] as
follows. When processing a Router Advertisement with a Prefix follows. When processing a Router Advertisement with a Prefix
Information option carrying a global scope prefix for the purposes of Information option carrying a global scope prefix for the purposes of
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. When adjusting of existing addresses, both public and temporary. If a received
the lifetime of an existing temporary address, there are two option will extend the lifetime of a public address, the
cases to consider: lifetimes of temporary addresses should be extended, subject to
A. In some cases, the lifetimes in a received option will be the overall constraint that no temporary addresses should ever
shorter than the lifetimes of an existing temporary addresses remain "valid" or "preferred" for a time longer than
derived from the prefix given in the option. This (TEMP_VALID_LIFETIME-DESYNC_FACTOR) or
corresponds to the case where the lifetimes have been
reconfigured by a system administrator to have a shorter
lifetime. Perform the following procedure to determine how
to update the lifetime of the temporary address:
B.
+ If the received Valid Lifetime is greater than 2 hours
update the lifetime of the temporary address to the
received lifetime.
+ If the RemainingLifetime of the temporary address is less
than or equal to 2 hours ignore the received option.
+ Otherwise set the valid lifetime to 2 hours.
C. These steps are necessary to prevent a denial of service
attack where a bogus advertisement contains prefixes with
very small Valid Lifetimes
D. In many cases, the lifetime of a received option will extend
the lifetime of a public address. For example, a site might
advertise short lifetimes (on the order of hours or minutes)
that are effectively extended with each new RA. In such
cases, the lifetimes of temporary addresses should be
extended, subject to the overall constraint that no temporary
addresses should ever remain "valid" or "preferred" for a
time longer than (TEMP_VALID_LIFETIME-DESYNC_FACTOR) or
(TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR) respectively. The (TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR) respectively. The
configuration variables TEMP_VALID_LIFETIME and configuration variables TEMP_VALID_LIFETIME and
TEMP_PREFERRED_LIFETIME correspond to approximate target TEMP_PREFERRED_LIFETIME correspond to approximate target
lifetimes for temporary addresses. lifetimes for temporary addresses.
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.
2. When a new public address is created as described in [ADDRCONF]
3. When a new public address is created as described in [ADDRCONF]
(because the prefix advertised does not match the prefix of any (because the prefix advertised does not match the prefix of any
address already assigned to the interface, and the Valid Lifetime address already assigned to the interface, and the Valid Lifetime
in the option is not zero), the node SHOULD also create a new in the option is not zero), the node SHOULD also create a new
temporary address. temporary address.
3. 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 public address 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 public address or of the prefix or TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR.
TEMP_PREFERRED_LIFETIME-DESYNC_FACTOR. 5. A temporary address is created only if this calculated Preferred
4. 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.
5. New temporary addresses MUST be created by appending the 6. New temporary addresses MUST be created by appending the
interface's current randomized interface identifier to the prefix interface's current randomized interface identifier to the prefix
that was used to generate the corresponding public address. that was received.
6. The node MUST Perform duplicate address detection (DAD) on the 7. The node MUST Perform duplicate address detection (DAD) on the
generated temporary address. If DAD indicates the address is generated temporary address. If DAD indicates the address is
already in use, the node MUST generate a new randomized interface already in use, the node MUST generate a new randomized interface
identifier as described in Section 3.2 above, and repeat the identifier as described in Section 3.2 above, and repeat the
previous steps as appropriate up to 5 times. If after 5 previous steps as appropriate up to TEMP_IDGEN_RETRIES times. If
consecutive attempts no non-unique address was generated, the after TEMP_IDGEN_RETRIES consecutive attempts no non-unique
node MUST log a system error and MUST NOT attempt to generate address was generated, the node MUST log a system error and MUST
temporary addresses for that interface. Note that DAD MUST be NOT attempt to generate temporary addresses for that interface.
performed on every unicast address generated from this randomized Note that DAD MUST be performed on every unicast address
interface identifier. generated from this randomized interface identifier.
3.4 Expiration of Temporary Addresses 3.4 Expiration of Temporary Addresses
When a temporary address becomes deprecated, a new one MUST be When a temporary address becomes deprecated, a new one MUST be
generated. This is done by repeating the actions described in generated. This is done by repeating the actions described in
Section 3.3, starting at step 3). Note that, except for the Section 3.3, starting at step 3). Note that, except for the
transient period when a temporary address is being regenerated, in transient period when a temporary address is being regenerated, in
normal operation at most one temporary address corresponding to a normal operation at most one temporary address per prefix should be
public address should be in a non-deprecated state at any given time. in a non-deprecated state at any given time on a given interface.
Note that if a temporary address becomes deprecated as result of Note that if a temporary address becomes deprecated as result of
processing a Prefix Information Option with a zero Preferred processing a Prefix Information Option with a zero Preferred
Lifetime, then a new temporary address MUST NOT be generated. The Lifetime, then a new temporary address MUST NOT be generated.To
Prefix Information Option will also deprecate the corresponding ensure that a preferred temporary address is always available, a new
public address. To insure that a preferred temporary address is temporary address SHOULD be regenerated slightly before its
always available, a new temporary address SHOULD be regenerated predecessor is deprecated. This is to allow sufficient time to avoid
slightly before its predecessor is deprecated. This is to allow race conditions in the case where generating a new temporary address
sufficient time to avoid race conditions in the case where generating is not instantaneous, such as when duplicate address detection must
a new temporary address is not instantaneous, such as when duplicate be run. The node SHOULD start the address regeneration process
address detection must be run. The node SHOULD start the address REGEN_ADVANCE time units before a temporary address would actually be
regeneration process REGEN_ADVANCE time units before a temporary deprecated.
address would actually be 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. For TCP connections, such information is available in upper-layers as detailed in Section 6
control blocks. For UDP-based applications, it may be the case that
only the applications have knowledge about what addresses are
actually in use. Consequently, one may need to use heuristics in
deciding when an address is no longer in use (e.g., the default
TEMP_VALID_LIFETIME suggested above).
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 16, line 29 skipping to change at page 17, line 9
same time. When the preferred lifetime expires, a new temporary same time. When the preferred lifetime expires, a new temporary
address MUST be generated using the new randomized interface address MUST be generated using the new randomized interface
identifier. identifier.
Because the precise frequency at which it is appropriate to generate Because the precise frequency at which it is appropriate to generate
new addresses varies from one environment to another, implementations new addresses varies from one environment to another, implementations
SHOULD provide end users with the ability to change the frequency at SHOULD provide end users with the ability to change the frequency at
which addresses are regenerated. The default value is given in which addresses are regenerated. The default value is given in
TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time TEMP_PREFERRED_LIFETIME and is one day. In addition, the exact time
at which to invalidate a temporary address depends on how at which to invalidate a temporary address depends on how
applications are used by end users. Thus, the default value given of applications are used by end users. Thus, the suggested default
one week (TEMP_VALID_LIFETIME) may not be appropriate in all value of one week (TEMP_VALID_LIFETIME) may not be appropriate in all
environments. Implementations SHOULD provide end users with the environments. Implementations SHOULD provide end users with the
ability to override both of these default values. ability to override both of these default values.
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 process by which a node can determine whether a link same node. The node MAY follow any process available to it, to
change has occurred is described by Detecting Network Attachment determine that the link change has occurred. One such process is
[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 simply 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.
Additionally, sites might wish to selectively enable or disable the
use of temporary addresses for some prefixes. For example, a site
might wish to disable temporary address generation for "Unique local"
[ULA] prefixes while still generating temporary addresses for all
other global prefixes. Another site might wish to enable temporary
address generation only for the prefixes 2001::/16 and 2002::/16
while disabling it for all other prefixes. To support this behavior,
implementations SHOULD provide a way to enable and disable generation
of temporary addresses for specific prefix subranges. This
per-prefix setting SHOULD override the global settings on the node
with respect to the specified prefix subranges.
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 an 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
skipping to change at page 18, line 40 skipping to change at page 19, line 40
The wide deployment of the extension described in this document could The wide deployment of the extension described in this document could
challenge the practice of inverse-DNS-based "authentication," which challenge the practice of inverse-DNS-based "authentication," which
has little validity, though it is widely implemented. In order to has little validity, though it is widely implemented. In order to
meet server challenges, nodes could register temporary addresses in meet server challenges, nodes could register temporary addresses in
the DNS using random names (for example a string version of the the DNS using random names (for example a string version of the
random address itself). random address itself).
Use of the extensions defined in this document may complicate Use of the extensions defined in this document may complicate
debugging and other operational troubleshooting activities. debugging and other operational troubleshooting activities.
Consequently, it may be site policy that temporary addresses should Consequently, it may be site policy that temporary addresses should
not be used. Consequently, implementations must provide a method for not be used. Consequently, implementations MUST provide a method for
the end user or trusted administrator to override the use of the end user or trusted administrator to override the use of
temporary addresses. temporary addresses.
5. Defined Constants 5. Defined Constants
Constants defined in this document include: Constants defined in this document include:
TEMP_VALID_LIFETIME -- Default value: 1 week. Users should be able TEMP_VALID_LIFETIME -- Default value: 1 week. Users should be able
to override the default value. to override the default value.
skipping to change at page 20, line 5 skipping to change at page 20, line 24
REGEN_ADVANCE -- 5 seconds REGEN_ADVANCE -- 5 seconds
MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR. MAX_DESYNC_FACTOR -- 10 minutes. Upper bound on DESYNC_FACTOR.
DESYNC_FACTOR -- A random value within the range 0 - DESYNC_FACTOR -- A random value within the range 0 -
MAX_DESYNC_FACTOR. It is computed once at system start (rather than MAX_DESYNC_FACTOR. It is computed once at system start (rather than
each time it is used) and must never be greater than each time it is used) and must never be greater than
(TEMP_VALID_LIFETIME - REGEN_ADVANCE). (TEMP_VALID_LIFETIME - REGEN_ADVANCE).
TEMP_IDGEN_RETRIES -- Default value: 3
6. Future Work 6. Future Work
An implementation might want to keep track of which addresses are An implementation might want to keep track of which addresses are
being used by upper layers so as to be able to remove a deprecated being used by upper layers so as to be able to remove a deprecated
temporary address from internal data structures once no upper layer temporary address from internal data structures once no upper layer
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 (e.g., as is suggested in Section an address is no longer in use.
3.4).
The determination as to whether to use public vs. temporary The determination as to whether to use public vs. 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. needed. [DNSOP] contains a more detailed discussion of the DNS
related issues.
While this document discusses ways of obscuring a user's permanent IP While this document discusses ways of obscuring a user's permanent IP
address, the method described is believed to be ineffective against address, the method described is believed to be ineffective against
sophisticated forms of traffic analysis. To increase effectiveness, sophisticated forms of traffic analysis. To increase effectiveness,
one may need to consider use of more advanced techniques, such as one may need to consider use of more advanced techniques, such as
Onion Routing [ONION]. Onion Routing [ONION].
Open Issues Open Issues
1) Implementations should allow system administrators to configure 1) Implementations should allow system administrators to configure
skipping to change at page 22, line 5 skipping to change at page 23, line 5
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 11. DAD is now performed on all unicast addresses created from the
same interface identifier instead of just the first one same interface identifier instead of just the first one
8. Security Considerations 8. Changes from version 00
Ingress filtering is being deployed as a means of preventing the use This section summarizes the changes from version 00 of this draft
of spoofed source addresses in Distributed Denial of Service(DDoS) 1. The algorithm used for generating random interface identifiers is
attacks. In a network with a large number of nodes, new temporary no longer restricted to just MD5
addresses are created at a fairly high rate. This might make it 2. Added a problem statement
difficult for ingress filtering mechanisms to distinguish between 3. Classified the references into normative and informative
legitimately changing temporary addresses and spoofed source 4. Reduced default number of retries to 3 from 5 and added a
addresses which "in-prefix"(They use a topologically correct prefix configuration variable
and non-existent interface ID). This can be addressed by using 5. Removed text about RA processing which is duplicated from
access control mechanisms on a per address basis on the network [ADDRCONF]
egress point. 6. Added text about the privacy implications of a non-changing
prefix
7. Added a per-prefix enable/disable setting
8. Added text about the means of correlation
9. Clarified text about DHCPv6
10. Added reference to dnsop issues draft
9. Acknowledgements 9. Security Considerations
Ingress filtering has been and is being deployed as a means of
preventing the use of spoofed source addresses in Distributed Denial
of Service(DDoS) attacks. In a network with a large number of nodes,
new temporary addresses are created at a fairly high rate. This
might make it difficult for ingress filtering mechanisms to
distinguish between legitimately changing temporary addresses and
spoofed source addresses, which are "in-prefix"(They use a
topologically correct prefix and non-existent interface ID). This
can be addressed by using access control mechanisms on a per address
basis on the network egress point.
10. 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, and Francis Dupont for their detailed comments.
10 References 11. References
11.1 Normative References
[ADDRARCH] [ADDRARCH]
Hinden, R. and S. Deering, "IP Version 6 Addressing Hinden, R. and S. Deering, "Internet Protocol Version 6
Architecture", RFC 2373, July 1998. (IPv6) Addressing Architecture", RFC 3513, April 2003.
[ADDRCONF] [ADDRCONF]
Thomson, S. and T. Narten, "IPv6 Stateless Address Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless
Autoconfiguration", RFC 2462, December 1998. Address Autoconfiguration", draft-ietf-ipv6-rfc2462bis-06
(work in progress), September 2004.
[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.
[DISCOVERY]
Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-00 (work in progress), July 2004.
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
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.
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997. 2131, March 1997.
[DISCOVERY] [DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
Narten, T., Nordmark, E. and W. Simpson, "Neighbor M. Carney, "Dynamic Host Configuration Protocol for IPv6
Discovery for IP Version 6 (IPv6)", RFC 2461, December (DHCPv6)", RFC 3315, July 2003.
1998.
[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.
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the [DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational
Internet Protocol", RFC 2401, November 1998. Considerations and Issues with IPv6 DNS",
draft-ietf-dnsop-ipv6-dns-issues-09 (work in progress),
August 2004.
[ISATAP] Templin, F., Gleeson, T., Talwar, M. and D. Thaler, [ISATAP] Templin, F., Gleeson, T., Talwar, M. and D. Thaler,
"Intra-Site Automatic Tunnel Addressing Protocol "Intra-Site Automatic Tunnel Addressing Protocol
(ISATAP)", draft-ietf-ngtrans-isatap-22 (work in (ISATAP)", draft-ietf-ngtrans-isatap-22 (work in
progress), May 2004. progress), May 2004.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[MOBILEIP]
Perkins, C., "IP Mobility Support", RFC 2002, October
1996.
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
Requirement Levels", RFC 2119, March 1997. Nikander, "SEcure Neighbor Discovery (SEND)",
draft-ietf-send-ndopt-06 (work in progress), July 2004.
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999.
[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
Thomas Narten Thomas Narten
IBM Corporation IBM Corporation
P.O. Box 12195 P.O. Box 12195
 End of changes. 

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