draft-ietf-ipv6-privacy-addrs-v2-02.txt   draft-ietf-ipv6-privacy-addrs-v2-03.txt 
IPv6 Working Group T. Narten IPv6 Working Group T. Narten
Internet-Draft IBM Corporation Internet-Draft IBM Corporation
Expires: June 23, 2005 R. Draves Expires: October 6, 2005 R. Draves
Microsoft Research Microsoft Research
S. Krishnan S. Krishnan
Ericsson Ericsson
December 23, 2004 April 4, 2005
Privacy Extensions for Stateless Address Autoconfiguration in IPv6 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
draft-ietf-ipv6-privacy-addrs-v2-02 draft-ietf-ipv6-privacy-addrs-v2-03
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable This document is an Internet-Draft and is subject to all provisions
patent or other IPR claims of which I am aware have been disclosed, of Section 3 of RFC 3667. By submitting this Internet-Draft, each
and any of which I become aware will be disclosed, in accordance with author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 23, 2005. This Internet-Draft will expire on October 6, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
Nodes use IPv6 stateless address autoconfiguration to generate Nodes use IPv6 stateless address autoconfiguration to generate
addresses using a combination of locally available information and addresses using a combination of locally available information and
information advertised by routers. Addresses are formed by combining information advertised by routers. Addresses are formed by combining
network prefixes with an interface identifier. On interfaces that network prefixes with an interface identifier. On interfaces that
contain embedded IEEE Identifiers, the interface identifier is contain embedded IEEE Identifiers, the interface identifier is
typically derived from it. On other interface types, the interface typically derived from it. On other interface types, the interface
identifier is generated through other means, for example, via random identifier is generated through other means, for example, via random
skipping to change at page 2, line 18 skipping to change at page 2, line 21
causes nodes to generate global scope addresses from interface causes nodes to generate global scope addresses from interface
identifiers that change over time, even in cases where the interface identifiers that change over time, even in cases where the interface
contains an embedded IEEE identifier. Changing the interface contains an embedded IEEE identifier. Changing the interface
identifier (and the global scope addresses generated from it) over identifier (and the global scope addresses generated from it) over
time makes it more difficult for eavesdroppers and other information time makes it more difficult for eavesdroppers and other information
collectors to identify when different addresses used in different collectors to identify when different addresses used in different
transactions actually correspond to the same node. transactions actually correspond to the same node.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 4 1.1 Problem Statement . . . . . . . . . . . . . . . . . . . . 5
1.2 Conventions used in this document . . . . . . . . . . . . 4 1.2 Conventions used in this document . . . . . . . . . . . . 5
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1 Extended Use of the Same Identifier . . . . . . . . . . . 5 2.1 Extended Use of the Same Identifier . . . . . . . . . . . 6
2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 6 2.2 Address Usage in IPv4 Today . . . . . . . . . . . . . . . 7
2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 7 2.3 The Concern With IPv6 Addresses . . . . . . . . . . . . . 8
2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 8 2.4 Possible Approaches . . . . . . . . . . . . . . . . . . . 9
3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 10 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 11
3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 11
3.2 Generation Of Randomized Interface Identifiers . . . . . . 12 3.2 Generation Of Randomized Interface Identifiers . . . . . . 13
3.2.1 When Stable Storage Is Present . . . . . . . . . . . . 12 3.2.1 When Stable Storage Is Present . . . . . . . . . . . . 13
3.2.2 In The Absence of Stable Storage . . . . . . . . . . . 13 3.2.2 In The Absence of Stable Storage . . . . . . . . . . . 14
3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 14 3.2.3 Alternate approaches . . . . . . . . . . . . . . . . . 15
3.3 Generating Temporary Addresses . . . . . . . . . . . . . . 14 3.3 Generating Temporary Addresses . . . . . . . . . . . . . . 15
3.4 Expiration of Temporary Addresses . . . . . . . . . . . . 15 3.4 Expiration of Temporary Addresses . . . . . . . . . . . . 16
3.5 Regeneration of Randomized Interface Identifiers . . . . . 16 3.5 Regeneration of Randomized Interface Identifiers . . . . . 17
3.6 Deployment Considerations . . . . . . . . . . . . . . . . 17 3.6 Deployment Considerations . . . . . . . . . . . . . . . . 18
4. Implications of Changing Interface Identifiers . . . . . . . . 19 4. Implications of Changing Interface Identifiers . . . . . . . . 20
5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 20 5. Defined Constants . . . . . . . . . . . . . . . . . . . . . . 21
6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 21 6. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 22
7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 22 7. Significant Changes from RFC 3041 . . . . . . . . . . . . . . 23
8. Changes from version 00 . . . . . . . . . . . . . . . . . . . 23 8. Changes from version 00 . . . . . . . . . . . . . . . . . . . 24
9. Changes from version 01 . . . . . . . . . . . . . . . . . . . 24 9. Changes from version 01 . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . 25 10. Changes from version 02 . . . . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 27 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.2 Informative References . . . . . . . . . . . . . . . . . . . 27 13.1 Normative References . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 13.2 Informative References . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
Intellectual Property and Copyright Statements . . . . . . . . 32
1. Introduction 1. Introduction
Stateless address autoconfiguration [ADDRCONF] defines how an IPv6 Stateless address autoconfiguration [ADDRCONF] defines how an IPv6
node generates addresses without the need for a DHCPv6 server. Some node generates addresses without the need for a DHCPv6 server. Some
types of network interfaces come with an embedded IEEE Identifier types of network interfaces come with an embedded IEEE Identifier
(i.e., a link-layer MAC address), and in those cases stateless (i.e., a link-layer MAC address), and in those cases stateless
address autoconfiguration uses the IEEE identifier to generate a 64- address autoconfiguration uses the IEEE identifier to generate a 64-
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
skipping to change at page 3, line 30 skipping to change at page 4, line 30
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 may not be (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, because
concern being addressed exists only in those cases where the tracking of individual devices, the concern being addressed here, is
interface identifier is globally unique and non-changing. The rest possible only in those cases where the interface identifier is
of this document assumes that IEEE identifiers are being used, but globally unique and non-changing. The rest of this document assumes
the techniques described may also apply to interfaces with other that IEEE identifiers are being used, but the techniques described
types of globally unique and/or persistent identifiers. may also apply to interfaces with other 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
describes extensions to stateless address autoconfiguration that can describes extensions to stateless address autoconfiguration that can
help mitigate those concerns for individual users and in environments help mitigate those concerns for individual users and in environments
where such concerns are significant. Section 2 provides background where such concerns are significant. Section 2 provides background
information on the issue. Section 3 describes a procedure for information on the issue. Section 3 describes a procedure for
generating alternate interface identifiers and global scope generating alternate interface identifiers and global scope
addresses. Section 4 discusses implications of changing interface addresses. Section 4 discusses implications of changing interface
identifiers. The term "global scope addresses" is used in this identifiers. The term "global scope addresses" is used in this
document to collectively refer to "Global unicast addresses" as document to collectively refer to "Global unicast addresses" as
defined in [ADDRARCH] and "Unique local addresses" as defined in defined in [ADDRARCH] and "Unique local addresses" as defined in
[ULA] [ULA]
1.1 Problem Statement 1.1 Problem Statement
Addresses generated using Stateless address autoconfiguration Addresses generated using Stateless address autoconfiguration
[ADDRCONF]contain an embedded 64-bit interface identifier, which [ADDRCONF]contain an embedded interface identifier, which remains
remains constant over time. Anytime a fixed identifier is used in constant over time. Anytime a fixed identifier is used in multiple
multiple contexts, it becomes possible to correlate seemingly contexts, it becomes possible to correlate seemingly unrelated
unrelated activity using this identifier. activity using this identifier.
The correlation can be performed by The correlation can be performed by
o An attacker who is in the path between the node in question and o An attacker who is in the path between the node in question and
the peer(s) it is communicating to, and can view the IPv6 the peer(s) it is communicating to, and can view the IPv6
addresses present in the datagrams. addresses present in the datagrams.
o An attacker who can access the communication logs of the peers o An attacker who can access the communication logs of the peers
with which the node has communicated. with which the node has communicated.
Since the identifier is embedded within the IPv6 address, which is a Since the identifier is embedded within the IPv6 address, which is a
fundamental requirement of communication, it cannot be easily hidden. fundamental requirement of communication, it cannot be easily hidden.
skipping to change at page 5, line 19 skipping to change at page 6, line 19
environments and makes comparisons with existing practices. environments and makes comparisons with existing practices.
2.1 Extended Use of the Same Identifier 2.1 Extended Use of the Same Identifier
The use of a non-changing interface identifier to form addresses is a The use of a non-changing interface identifier to form addresses is a
specific instance of the more general case where a constant specific instance of the more general case where a constant
identifier is reused over an extended period of time and in multiple identifier is reused over an extended period of time and in multiple
independent activities. Anytime the same identifier is used in independent activities. Anytime the same identifier is used in
multiple contexts, it becomes possible for that identifier to be used multiple contexts, it becomes possible for that identifier to be used
to correlate seemingly unrelated activity. For example, a network to correlate seemingly unrelated activity. For example, a network
sniffer placed strategically on a link across which all traffic to/ sniffer placed strategically on a link across which all traffic
from a particular host crosses could keep track of which destinations to/from a particular host crosses could keep track of which
a node communicated with and at what times. Such information can in destinations a node communicated with and at what times. Such
some cases be used to infer things, such as what hours an employee information can in some cases be used to infer things, such as what
was active, when someone is at home, etc. Although it might appear hours an employee was active, when someone is at home, etc. Although
that changing an address regularly in such environments would be it might appear that changing an address regularly in such
desirable to lessen privacy concerns, it should be noted that the environments would be desirable to lessen privacy concerns, it should
network prefix portion of an address also serves as a constant be noted that the network prefix portion of an address also serves as
identifier. All nodes at (say) a home, would have the same network a constant identifier. All nodes at (say) a home, would have the
prefix, which identifies the topological location of those nodes. same network prefix, which identifies the topological location of
This has implications for privacy, though not at the same granularity those nodes. This has implications for privacy, though not at the
as the concern that this document addresses. Specifically, all nodes same granularity as the concern that this document addresses.
within a home could be grouped together for the purposes of Specifically, all nodes within a home could be grouped together for
collecting information. If the network contains a very small number the purposes of collecting information. If the network contains a
of nodes, say just one, changing just the interface identifier will very small number of nodes, say just one, changing just the interface
not enhance privacy at all, since the prefix serves as a constant identifier will not enhance privacy at all, since the prefix serves
identifier. 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 8, line 18 skipping to change at page 9, line 18
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 having a static non-changing address 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 or if the DHCPv6 client
happen automatically, and is difficult to configure manually, DHCPv6 moves from links to links frequently, being allocated independent
is not a self contained alternative for solving the privacy issues addresses from different DHCPv6 servers. However, the former does
addressed by this document. However, in the absence of stateless not happen automatically, and is difficult to configure manually; the
address autoconfiguration, DHCPv6 can be used for distributing latter cannot be assumed for static (not frequently moving) hosts.
temporary addresses to clients. Thus, 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 autoconfiguration architecture, would be to change the interface
identifier portion of an address over time and generate new addresses identifier portion of an address over time and generate new addresses
from the interface identifier for some address scopes. Changing the from the interface identifier for some address scopes. Changing the
interface identifier can make it more difficult to look at the IP interface identifier can make it more difficult to look at the IP
addresses in independent transactions and identify which ones addresses in independent transactions and identify which ones
actually correspond to the same node, both in the case where the actually correspond to the same node, both in the case where the
routing prefix portion of an address changes and when it does not. routing prefix portion of an address changes and when it does not.
skipping to change at page 25, line 5 skipping to change at page 26, line 5
9. Changes from version 01 9. Changes from version 01
This section summarizes the changes from version 01 of this draft This section summarizes the changes from version 01 of this draft
1. Clarifiying the length of interface identifier 1. Clarifiying the length of interface identifier
2. Added a per-prefix enable/disable knob as a SHOULD to retain 2. Added a per-prefix enable/disable knob as a SHOULD to retain
backward compatibility backward compatibility
3. Removed normative reference to ISATAP to avoid downref problem 3. Removed normative reference to ISATAP to avoid downref problem
4. Added text for per-prefix knobs to be applied at any granularity 4. Added text for per-prefix knobs to be applied at any granularity
5. Moved RFC2526 to informative reference 5. Moved RFC2526 to informative reference
10. Security Considerations 10. Changes from version 02
This section summarizes the changes from version 02 of this draft
1. Explained briefly the concern that is being addressed in the
introduction
2. Removed reference to 64 bit identifiers in the ADDRCONF context
3. Added clarifying text for the usage of DHCPv6 as an alternate
approach
4. Moved RFC3484 to informative reference
5. Updated references for SEND, and CGA as they became RFCs
6. Updated draft versions for ULA, DNSOP issues, 2461bis, 2462bis
and DNA goals
11. 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.
11. Acknowledgements 12. Acknowledgements
The authors would like to acknowledge the contributions of the ipv6 The authors would like to acknowledge the contributions of the ipv6
working group and, in particular, Ran Atkinson, Matt Crawford, Steve working group and, in particular, Ran Atkinson, Matt Crawford, Steve
Deering, Allison Mankin, Peter Bieringer, Jari Arkko, Pekka Nikander, Deering, Allison Mankin, Peter Bieringer, Jari Arkko, Pekka Nikander,
Pekka Savola, Francis Dupont, Brian Haberman, and Tatuya Jinmei for Pekka Savola, Francis Dupont, Brian Haberman, and Tatuya Jinmei for
their detailed comments. their detailed comments.
12. References 13. References
12.1 Normative References 13.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",
(work in progress), September 2004. Internet-Draft draft-ietf-ipv6-rfc2462bis-07, December
2004.
[ADDR_SELECT]
Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[DISCOVERY] [DISCOVERY]
Narten, T., Nordmark, E., Simpson, W. and H. Soliman, Narten, T., Nordmark, E., Simpson, W. and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-00 (work in progress), July 2004. Internet-Draft draft-ietf-ipv6-2461bis-02, February 2005.
[IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
12.2 Informative References 13.2 Informative References
[ADDR_SELECT]
Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[CGA] Aura, T., "Cryptographically Generated Addresses (CGA)", [CGA] Aura, T., "Cryptographically Generated Addresses (CGA)",
draft-ietf-send-cga-06 (work in progress), April 2004. RFC 3972, March 2005.
[COOKIES] Kristol, D. and L. Montulli, "HTTP State Management [COOKIES] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000. Mechanism", RFC 2965, October 2000.
[DDNS] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic [DDNS] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "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",
2131, March 1997. RFC 2131, March 1997.
[DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and [DHCPV6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and
M. Carney, "Dynamic Host Configuration Protocol for IPv6 M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[DNA] Choi, J. and G. Daley, "Detecting Network Attachment in [DNA] Choi, J. and G. Daley, "Detecting Network Attachment in
IPv6 Goals", draft-ietf-dna-goals-01 (work in progress), IPv6 Goals", Internet-Draft draft-ietf-dna-goals-04,
September 2004. December 2004.
[DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational [DNSOP] Durand, A., Ihren, J. and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", Considerations and Issues with IPv6 DNS",
draft-ietf-dnsop-ipv6-dns-issues-09 (work in progress), Internet-Draft draft-ietf-dnsop-ipv6-dns-issues-10,
August 2004. October 2004.
[ONION] Reed, MGR., Syverson, PFS. and DMG. Goldschlag, "Proxies [ONION] Reed, MGR., Syverson, PFS. and DMG. Goldschlag, "Proxies
for Anonymous Routing", Proceedings of the 12th Annual for Anonymous Routing", Proceedings of the 12th Annual
Computer Security Applications Conference, San Diego, CA, Computer Security Applications Conference, San Diego, CA,
December 1996. December 1996.
[RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness [RANDOM] Eastlake, D., Crocker, S. and J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994. Recommendations for Security", RFC 1750, December 1994.
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast [RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
Addresses", RFC 2526, March 1999. Addresses", RFC 2526, March 1999.
[SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. [SEND] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure
Nikander, "SEcure Neighbor Discovery (SEND)", Neighbor Discovery (SEND)", RFC 3971, March 2005.
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",
progress), June 2004. Internet-Draft draft-ietf-ipv6-unique-local-addr-09,
January 2005.
Authors' Addresses Authors' Addresses
Thomas Narten Thomas Narten
IBM Corporation IBM Corporation
P.O. Box 12195 P.O. Box 12195
Research Triangle Park, NC Research Triangle Park, NC
USA USA
EMail: narten@raleigh.ibm.com Email: narten@raleigh.ibm.com
Richard Draves Richard Draves
Microsoft Research Microsoft Research
One Microsoft Way One Microsoft Way
Redmond, WA Redmond, WA
USA USA
EMail: richdr@microsoft.com Email: richdr@microsoft.com
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Decarie Blvd. 8400 Decarie Blvd.
Town of Mount Royal, QC Town of Mount Royal, QC
Canada Canada
EMail: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 30, line 41 skipping to change at page 32, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

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