draft-ietf-6man-ipv6-address-generation-privacy-02.txt   draft-ietf-6man-ipv6-address-generation-privacy-03.txt 
Network Working Group A. Cooper Network Working Group A. Cooper
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational F. Gont Intended status: Informational F. Gont
Expires: April 13, 2015 Huawei Technologies Expires: July 19, 2015 Huawei Technologies
D. Thaler D. Thaler
Microsoft Microsoft
October 10, 2014 January 15, 2015
Privacy Considerations for IPv6 Address Generation Mechanisms Privacy Considerations for IPv6 Address Generation Mechanisms
draft-ietf-6man-ipv6-address-generation-privacy-02.txt draft-ietf-6man-ipv6-address-generation-privacy-03.txt
Abstract Abstract
This document discusses privacy and security considerations for This document discusses privacy and security considerations for
several IPv6 address generation mechanisms, both standardized and several IPv6 address generation mechanisms, both standardized and
non-standardized. It evaluates how different mechanisms mitigate non-standardized. It evaluates how different mechanisms mitigate
different threats and the trade-offs that implementors, developers, different threats and the trade-offs that implementors, developers,
and users face in choosing different addresses or address generation and users face in choosing different addresses or address generation
mechanisms. mechanisms.
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 13, 2015. This Internet-Draft will expire on July 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Weaknesses in IEEE-identifier-based IIDs . . . . . . . . . . 4 3. Weaknesses in IEEE-identifier-based IIDs . . . . . . . . . . . 6
3.1. Correlation of activities over time . . . . . . . . . . . 5 3.1. Correlation of activities over time . . . . . . . . . . . 6
3.2. Location tracking . . . . . . . . . . . . . . . . . . . . 6 3.2. Location tracking . . . . . . . . . . . . . . . . . . . . 7
3.3. Address scanning . . . . . . . . . . . . . . . . . . . . 6 3.3. Address scanning . . . . . . . . . . . . . . . . . . . . . 7
3.4. Device-specific vulnerability exploitation . . . . . . . 6 3.4. Device-specific vulnerability exploitation . . . . . . . . 8
4. Privacy and security properties of address generation 4. Privacy and security properties of address generation
mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 7 mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. IEEE-identifier-based IIDs . . . . . . . . . . . . . . . 9 4.1. IEEE-identifier-based IIDs . . . . . . . . . . . . . . . . 11
4.2. Static, manually configured IIDs . . . . . . . . . . . . 10 4.2. Static, manually configured IIDs . . . . . . . . . . . . . 11
4.3. Constant, semantically opaque IIDs . . . . . . . . . . . 10 4.3. Constant, semantically opaque IIDs . . . . . . . . . . . . 11
4.4. Cryptographically generated IIDs . . . . . . . . . . . . 10 4.4. Cryptographically generated IIDs . . . . . . . . . . . . . 12
4.5. Stable, semantically opaque IIDs . . . . . . . . . . . . 10 4.5. Stable, semantically opaque IIDs . . . . . . . . . . . . . 12
4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . 11 4.6. Temporary IIDs . . . . . . . . . . . . . . . . . . . . . . 12
4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 12 4.7. DHCPv6 generation of IIDs . . . . . . . . . . . . . . . . 13
4.8. Transition/co-existence technologies . . . . . . . . . . 12 4.8. Transition/co-existence technologies . . . . . . . . . . . 13
5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 12 5. Miscellaneous Issues with IPv6 addressing . . . . . . . . . . 15
5.1. Geographic Location . . . . . . . . . . . . . . . . . . . 12 5.1. Network Operation . . . . . . . . . . . . . . . . . . . . 15
5.2. Network Operation . . . . . . . . . . . . . . . . . . . . 12 5.2. Compliance . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3. Compliance . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. Intellectual Property Rights (IPRs) . . . . . . . . . . . 15
5.4. Intellectual Property Rights (IPRs) . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Informative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
IPv6 was designed to improve upon IPv4 in many respects, and IPv6 was designed to improve upon IPv4 in many respects, and
mechanisms for address assignment were one such area for improvement. mechanisms for address assignment were one such area for improvement.
In addition to static address assignment and DHCP, stateless In addition to static address assignment and DHCP, stateless
autoconfiguration was developed as a less intensive, fate-shared autoconfiguration was developed as a less intensive, fate-shared
means of performing address assignment. With stateless means of performing address assignment. With stateless
autoconfiguration, routers advertise on-link prefixes and hosts autoconfiguration, routers advertise on-link prefixes and hosts
generate their own interface identifiers (IIDs) to complete their generate their own interface identifiers (IIDs) to complete their
addresses. Over the years, many interface identifier generation addresses. [RFC7136] clarifies that the IID should be treated as an
techniques have been defined, both standardized and non-standardized: opaque value, while [RFC7421] provides an analysis of the 64-bit
boundary in IPv6 addressing (e.g. the implications of the IID length
on security and privacy). Over the years, many interface identifier
generation techniques have been defined, both standardized and non-
standardized:
o Manual configuration o Manual configuration
* IPv4 address * IPv4 address
* Service port * Service port
* Wordy * Wordy
* Low-byte * Low-byte
o Stateless Address Auto-Cofiguration (SLAAC) o Stateless Address Auto-Cofiguration (SLAAC)
skipping to change at page 3, line 34 skipping to change at page 4, line 4
* Stable, semantically opaque [RFC7217] * Stable, semantically opaque [RFC7217]
o DHCPv6-based [RFC3315] o DHCPv6-based [RFC3315]
o Specified by transition/co-existence technologies o Specified by transition/co-existence technologies
* IPv4 address and port [RFC4380] * IPv4 address and port [RFC4380]
Deriving the IID from a globally unique IEEE identifier [RFC2462] was Deriving the IID from a globally unique IEEE identifier [RFC2462] was
one of the earliest mechanisms developed. A number of privacy and one of the earliest mechanisms developed. A number of privacy and
security issues related to the interface IDs derived from IEEE security issues related to the IIDs derived from IEEE identifiers
identifiers were discovered after their standardization, and many of were discovered after their standardization, and many of the
the mechanisms developed later aimed to mitigate some or all of these mechanisms developed later aimed to mitigate some or all of these
weaknesses. This document identifies four types of threats against weaknesses. This document identifies four types of threats against
IEEE-identifier-based IIDs, and discusses how other existing IEEE-identifier-based IIDs, and discusses how other existing
techniques for generating IIDs do or do not mitigate those threats. techniques for generating IIDs do or do not mitigate those threats.
2. Terminology 2. Terminology
This section clarifies the terminology used throughout this document. This section clarifies the terminology used throughout this document.
Public address: Public address:
An address that has been published in a directory or other public An address that has been published in a directory or other public
skipping to change at page 5, line 23 skipping to change at page 6, line 38
the order of years, compared to days for DHCP. the order of years, compared to days for DHCP.
As [RFC4941] explains, As [RFC4941] explains,
"[t]he use of a non-changing interface identifier to form "[t]he use of a non-changing interface identifier to form
addresses is a specific instance of the more general case where a addresses is a specific instance of the more general case where a
constant identifier is reused over an extended period of time and constant identifier is reused over an extended period of time and
in multiple independent activities. Anytime the same identifier in multiple independent activities. Anytime the same identifier
is used in multiple contexts, it becomes possible for that is used in multiple contexts, it becomes possible for that
identifier to be used to correlate seemingly unrelated activity. identifier to be used to correlate seemingly unrelated activity.
... The use of a constant identifier within an address is of ... The use of a constant identifier within an address is of
special concern because addresses are a fundamental requirement of special concern because addresses are a fundamental requirement of
communication and cannot easily be hidden from eavesdroppers and communication and cannot easily be hidden from eavesdroppers and
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." addresses in packet headers appear in the clear."
IP addresses are just one example of information that can be used to IP addresses are just one example of information that can be used to
correlate activities over time. DNS names, cookies [RFC6265], correlate activities over time. DNS names, cookies [RFC6265],
browser fingerprints [Panopticlick], and application-layer usernames browser fingerprints [Panopticlick], and application-layer usernames
can all be used to link a host's activities together. Although IEEE- can all be used to link a host's activities together. Although IEEE-
identifier-based IIDs are likely to last at least as long or longer identifier-based IIDs are likely to last at least as long or longer
skipping to change at page 6, line 48 skipping to change at page 8, line 15
value (0xff, 0xfe) used to form a Modified EUI-64 Interface value (0xff, 0xfe) used to form a Modified EUI-64 Interface
Identifier, greatly help to reduce the search space, making it easier Identifier, greatly help to reduce the search space, making it easier
for an attacker to scan for individual addresses using widely-known for an attacker to scan for individual addresses using widely-known
popular OUIs. This erases much of the protection against address popular OUIs. This erases much of the protection against address
scanning that the larger IPv6 address space was supposed to provide scanning that the larger IPv6 address space was supposed to provide
as compared to IPv4. as compared to IPv4.
3.4. Device-specific vulnerability exploitation 3.4. Device-specific vulnerability exploitation
IPv6 addresses that embed IEEE identifiers leak information about the IPv6 addresses that embed IEEE identifiers leak information about the
device (Network Interface Card vendor, or even Operating System and/ device (Network Interface Card vendor, or even Operating System
or software type), which could be leveraged by an attacker with and/or software type), which could be leveraged by an attacker with
knowledge of device/software-specific vulnerabilities to quickly find knowledge of device/software-specific vulnerabilities to quickly find
possible targets. Attackers can exploit vulnerabilities in hosts possible targets. Attackers can exploit vulnerabilities in hosts
whose IIDs they have previously obtained, or scan an address space to whose IIDs they have previously obtained, or scan an address space to
find potential targets. find potential targets.
4. Privacy and security properties of address generation mechanisms 4. Privacy and security properties of address generation mechanisms
Analysis of the extent to which a particular host is protected Analysis of the extent to which a particular host is protected
against the threats described in Section 3 depends on how each of a against the threats described in Section 3 depends on how each of a
host's addresses is generated and used. In some scenarios, a host host's addresses is generated and used. In some scenarios, a host
skipping to change at page 12, line 12 skipping to change at page 13, line 36
the previous scenario, a host that configures but does not use a the previous scenario, a host that configures but does not use a
stable, semantically opaque address mitigates all four threats. stable, semantically opaque address mitigates all four threats.
4.7. DHCPv6 generation of IIDs 4.7. DHCPv6 generation of IIDs
The security/privacy implications of DHCPv6-based addresses will The security/privacy implications of DHCPv6-based addresses will
typically depend on the specific DHCPv6 server software being typically depend on the specific DHCPv6 server software being
employed. We note that recent releases of most popular DHCPv6 server employed. We note that recent releases of most popular DHCPv6 server
software typically lease random addresses with a similar lease time software typically lease random addresses with a similar lease time
as that of IPv4. Thus, these addresses can be considered to be as that of IPv4. Thus, these addresses can be considered to be
"stable, semantically opaque." "stable, semantically opaque".
[I-D.ietf-dhc-stable-privacy-addresses] specifies an algorithm that
can be employed by DHCP servers to generate "stable, semantically
opaque" addresses.
On the other hand, some DHCPv6 software leases sequential addresses On the other hand, some DHCPv6 software leases sequential addresses
(typically low-byte addresses). These addresses can be considered to (typically low-byte addresses). These addresses can be considered to
be stable addresses. The drawback of this address generation scheme be stable addresses. The drawback of this address generation scheme
compared to "stable, semantically opaque" addresses is that, since compared to "stable, semantically opaque" addresses is that, since
they follow specific patterns, they enable IPv6 address scans. they follow specific patterns, they enable IPv6 address scans.
4.8. Transition/co-existence technologies 4.8. Transition/co-existence technologies
Addresses specified based on transition/co-existence technologies Addresses specified based on transition/co-existence technologies
skipping to change at page 12, line 37 skipping to change at page 15, line 7
and port, leaving many other bits set to zero. This makes it and port, leaving many other bits set to zero. This makes it
relatively easy for an attacker to scan for IPv6 addresses by relatively easy for an attacker to scan for IPv6 addresses by
guessing the Teredo client's IPv4 address and port (which for many guessing the Teredo client's IPv4 address and port (which for many
NATs is not randomized). For this reason, popular implementations NATs is not randomized). For this reason, popular implementations
(e.g., Windows), began deviating from the standard by including 12 (e.g., Windows), began deviating from the standard by including 12
random bits in place of zero bits. This modification was later random bits in place of zero bits. This modification was later
standardized in [RFC5991]. standardized in [RFC5991].
5. Miscellaneous Issues with IPv6 addressing 5. Miscellaneous Issues with IPv6 addressing
5.1. Geographic Location 5.1. Network Operation
Since IPv6 subnets have unique prefixes, they reveal some information
about the location of the subnet, just as IPv4 addresses do. Hiding
this information is one motivation for using NAT in IPv6 (see RFC
5902 section 2.4).
5.2. Network Operation
It is generally agreed that IPv6 addresses that vary over time in a It is generally agreed that IPv6 addresses that vary over time in a
specific network tend to increase the complexity of event logging, specific network tend to increase the complexity of event logging,
trouble-shooting, enforcement of access controls and quality of trouble-shooting, enforcement of access controls and quality of
service, etc. As a result, some organizations disable the use of service, etc. As a result, some organizations disable the use of
temporary addresses [RFC4941] even at the expense of reduced privacy temporary addresses [RFC4941] even at the expense of reduced privacy
[Broersma]. [Broersma].
5.3. Compliance 5.2. Compliance
Some IPv6 compliance testing suites required (and might still Some IPv6 compliance testing suites required (and might still
require) implementations to support MAC-derived suffixes in order to require) implementations to support MAC-derived suffixes in order to
be approved as compliant. This document recommends that compliance be approved as compliant. This document recommends that compliance
testing suites be relaxed to allow other forms of address generation testing suites be relaxed to allow other forms of address generation
that are more amenable to privacy. that are more amenable to privacy.
5.4. Intellectual Property Rights (IPRs) 5.3. Intellectual Property Rights (IPRs)
Some IPv6 addressing techniques might be covered by Intellectual Some IPv6 addressing techniques might be covered by Intellectual
Property rights, which might limit their implementation in different Property rights, which might limit their implementation in different
Operating Systems. [CGA-IPR] and [KAME-CGA] discuss the IPRs on Operating Systems. [CGA-IPR] and [KAME-CGA] discuss the IPRs on
CGAs. CGAs.
6. Security Considerations 6. Security Considerations
This whole document concerns the privacy and security properties of This whole document concerns the privacy and security properties of
different IPv6 address generation mechanisms. different IPv6 address generation mechanisms.
7. IANA Considerations 7. IANA Considerations
This document does not require actions by IANA. This document does not require actions by IANA.
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Bernard Aboba, Tim Chown, Rich The authors would like to thank Bernard Aboba, Brian Carpenter, Tim
Draves, Robert Moskowitz, Erik Nordmark, and James Woodyatt for Chown, Lorenzo Colitti, Rich Draves, Robert Moskowitz, Erik Nordmark,
providing valuable comments on earlier versions of this document. and James Woodyatt for providing valuable comments on earlier
versions of this document.
9. Informative References
[Broersma]
Broersma, R., "IPv6 Everywhere: Living with a Fully
IPv6-enabled environment", Australian IPv6 Summit 2010,
Melbourne, VIC Australia, October 2010, October 2010,
<http://www.ipv6.org.au/10ipv6summit/talks/
Ron_Broersma.pdf>.
[CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005.
[I-D.ietf-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-ietf-opsec-ipv6-host-scanning-04 (work in
progress), June 2014.
[KAME-CGA]
KAME, "The KAME IPR policy and concerns of some
technologies which have IPR claims", 2005.
[Microsoft] 9. References
Microsoft, "IPv6 interface identifiers", 2013.
[Panopticlick] 9.1. Normative References
Electronic Frontier Foundation, "Panopticlick", 2011.
[RFC1972] Crawford, M., "A Method for the Transmission of IPv6 [RFC1972] Crawford, M., "A Method for the Transmission of IPv6
Packets over Ethernet Networks", RFC 1972, August 1996. Packets over Ethernet Networks", RFC 1972, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998. Networks", RFC 2464, December 1998.
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041, Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001. January 2001.
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third [RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards", RFC Generation Partnership Project (3GPP) Standards",
3314, September 2002. RFC 3314, September 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through
Network Address Translations (NATs)", RFC 4380, February Network Address Translations (NATs)", RFC 4380,
2006. February 2006.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, September 2007. IPv6", RFC 4941, September 2007.
[RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo [RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo
Security Updates", RFC 5991, September 2010. Security Updates", RFC 5991, September 2010.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012. (IPv6)", RFC 6724, September 2012.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Morris, J., Hansen, M., and R. Smith, "Privacy Interface Identifiers", RFC 7136, February 2014.
Considerations for Internet Protocols", RFC 6973, July
2013.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217, April 2014. Autoconfiguration (SLAAC)", RFC 7217, April 2014.
9.2. Informative References
[Broersma]
Broersma, R., "IPv6 Everywhere: Living with a Fully IPv6-
enabled environment", Australian IPv6 Summit 2010,
Melbourne, VIC Australia, October 2010, October 2010, <htt
p://www.ipv6.org.au/10ipv6summit/talks/Ron_Broersma.pdf>.
[CGA-IPR] IETF, "Intellectual Property Rights on RFC 3972", 2005.
[I-D.ietf-dhc-stable-privacy-addresses]
Gont, F. and W. Will, "A Method for Generating
Semantically Opaque Interface Identifiers with Dynamic
Host Configuration Protocol for IPv6 (DHCPv6)",
draft-ietf-dhc-stable-privacy-addresses-00 (work in
progress), October 2014.
[I-D.ietf-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-ietf-opsec-ipv6-host-scanning-04 (work in
progress), June 2014.
[KAME-CGA]
KAME, "The KAME IPR policy and concerns of some
technologies which have IPR claims", 2005,
<http://www.kame.net/newsletter/20040525/>.
[Microsoft]
Microsoft, "IPv6 interface identifiers", 2013, <target='ht
tp://www.microsoft.com/resources/documentation/windows/xp/
all/proddocs/en-us/sag_ip_v6_imp_addr7.mspx?mfr=true>.
[Panopticlick]
Electronic Frontier Foundation, "Panopticlick", 2011,
<http://panopticlick.eff.org>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
July 2013.
[RFC7421] Carpenter, B., Chown, T., Gont, F., Jiang, S., Petrescu,
A., and A. Yourtchenko, "Analysis of the 64-bit Boundary
in IPv6 Addressing", RFC 7421, January 2015.
Authors' Addresses Authors' Addresses
Alissa Cooper Alissa Cooper
Cisco Cisco
707 Tasman Drive 707 Tasman Drive
Milpitas, CA 95035 Milpitas, CA 95035
US US
Phone: +1-408-902-3950 Phone: +1-408-902-3950
Email: alcoop@cisco.com Email: alcoop@cisco.com
 End of changes. 24 change blocks. 
86 lines changed or deleted 110 lines changed or added

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