draft-ietf-6man-default-iids-16.txt   rfc8064.txt 
IPv6 maintenance Working Group (6man) F. Gont Internet Engineering Task Force (IETF) F. Gont
Internet-Draft SI6 Networks / UTN-FRH Request for Comments: 8064 SI6 Networks / UTN-FRH
Updates: 2464, 2467, 2470, 2491, 2492, A. Cooper Updates: 2464, 2467, 2470, 2491, 2492, A. Cooper
2497, 2590, 3146, 3572, 4291, Cisco 2497, 2590, 3146, 3572, 4291, Cisco
4338, 4391, 5072, 5121 (if D. Thaler 4338, 4391, 5072, 5121 D. Thaler
approved) Microsoft Category: Standards Track Microsoft
Intended status: Standards Track W. Liu ISSN: 2070-1721 W. Liu
Expires: March 29, 2017 Huawei Technologies Huawei Technologies
September 28, 2016 February 2017
Recommendation on Stable IPv6 Interface Identifiers Recommendation on Stable IPv6 Interface Identifiers
draft-ietf-6man-default-iids-16
Abstract Abstract
This document changes the recommended default IID generation scheme This document changes the recommended default Interface Identifier
for cases where SLAAC is used to generate a stable IPv6 address. It (IID) generation scheme for cases where Stateless Address
recommends using the mechanism specified in RFC7217 in such cases, Autoconfiguration (SLAAC) is used to generate a stable IPv6 address.
and recommends against embedding stable link-layer addresses in IPv6 It recommends using the mechanism specified in RFC 7217 in such
Interface Identifiers. It formally updates RFC2464, RFC2467, cases, and recommends against embedding stable link-layer addresses
RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, in IPv6 IIDs. It formally updates RFC 2464, RFC 2467, RFC 2470, RFC
RFC4291, RFC4338, RFC4391, RFC5072, and RFC5121. This document does 2491, RFC 2492, RFC 2497, RFC 2590, RFC 3146, RFC 3572, RFC 4291, RFC
not change any existing recommendations concerning the use of 4338, RFC 4391, RFC 5072, and RFC 5121. This document does not
temporary addresses as specified in RFC 4941. change any existing recommendations concerning the use of temporary
addresses as specified in RFC 4941.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 21, 2017. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8064.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Generation of IPv6 Interface Identifiers with SLAAC . . . . . 4 3. Generation of IPv6 Interface Identifiers with SLAAC . . . . . 5
4. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction 1. Introduction
[RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for [RFC4862] specifies Stateless Address Autoconfiguration (SLAAC) for
IPv6 [RFC2460], which typically results in hosts configuring one or IPv6 [RFC2460], which typically results in hosts configuring one or
more "stable" addresses composed of a network prefix advertised by a more "stable" addresses composed of a network prefix advertised by a
local router, and an Interface Identifier (IID) [RFC4291] that local router, and an Interface Identifier (IID) [RFC4291] that
typically embeds a stable link-layer address (e.g., an IEEE LAN MAC typically embeds a stable link-layer address (e.g., an IEEE LAN MAC
address). address).
In some network technologies and adaptation layers, the use of an IID In some network technologies and adaptation layers, the use of an IID
based on a link-layer address may offer some advantages. For based on a link-layer address may offer some advantages. For
example, the IP-over-IEEE802.15.4 standard in [RFC6775] allows for example, [RFC6282] allows for the compression of IPv6 datagrams over
compression of IPv6 addresses when the IID is based on the underlying IEEE 802.15.4-based networks [RFC4944] when the IID is based on the
link-layer address. underlying link-layer address.
The security and privacy implications of embedding a stable link- The security and privacy implications of embedding a stable link-
layer address in an IPv6 IID have been known for some time now, and layer address in an IPv6 IID have been known for some time now and
are discussed in great detail in [RFC7721]. They include: are discussed in great detail in [RFC7721]. They include:
o Network activity correlation o Network-activity correlation
o Location tracking o Location tracking
o Address scanning o Address scanning
o Device-specific vulnerability exploitation o Device-specific vulnerability exploitation
More generally, the reuse of identifiers that have their own More generally, the reuse of identifiers that have their own
semantics or properties across different contexts or scopes can be semantics or properties across different contexts or scopes can be
detrimental for security and privacy detrimental for security and privacy [NUM-IDS]. In the case of
[I-D.gont-predictable-numeric-ids]. In the case of traditional traditional stable IPv6 IIDs, some of the security and privacy
stable IPv6 IIDs, some of the security and privacy implications are implications are dependent on the properties of the underlying link-
dependent on the properties of the underlying link-layer addresses layer addresses (e.g., whether the link-layer address is ephemeral or
(e.g., whether the link-layer address is ephemeral or randomly randomly generated), while other implications (e.g., reduction of the
generated), while other implications (e.g., reduction of the entropy entropy of the IID) depend on the algorithm for generating the IID
of the IID) depend on the algorithm for generating the IID itself. itself. In standardized recommendations for stable IPv6 IID
In standardized recommendations for stable IPv6 IID generation meant generation meant to achieve particular security and privacy
to achieve particular security and privacy properties, it is properties, it is necessary to recommend against embedding stable
therefore necessary to recommend against embedding stable link-layer link-layer addresses in IPv6 IIDs.
addresses in IPv6 IIDs.
Furthermore, some popular IPv6 implementations have already deviated Furthermore, some popular IPv6 implementations have already deviated
from the traditional stable IID generation scheme to mitigate the from the traditional stable IID generation scheme to mitigate the
aforementioned security and privacy implications [Microsoft]. aforementioned security and privacy implications [Microsoft].
As a result of the aforementioned issues, this document changes the As a result of the aforementioned issues, this document changes the
recommended default IID generation scheme for generating stable IPv6 recommended default IID generation scheme for generating stable IPv6
addresses with SLAAC to that specified in [RFC7217], and recommends addresses with SLAAC to that specified in [RFC7217] and recommends
against embedding stable link-layer addresses in IPv6 Interface against embedding stable link-layer addresses in IPv6 Interface
Identifiers, such that the aforementioned issues are mitigated. That Identifiers, such that the aforementioned issues are mitigated. That
is, this document simply replaces the default algorithm that is is, this document simply replaces the default algorithm that is
recommended to be employed when generating stable IPv6 IIDs. recommended to be employed when generating stable IPv6 IIDs.
NOTE: [RFC4291] defines the "Modified EUI-64 format" for IIDs. NOTE:
[RFC4291] defines the "Modified EUI-64 format" for IIDs.
Appendix A of [RFC4291] then describes how to transform an IEEE Appendix A of [RFC4291] then describes how to transform an IEEE
EUI-64 identifier, or an IEEE 802 48-bit MAC address from which an EUI-64 identifier, or an IEEE 802 48-bit MAC address from which an
EUI-64 identifier is derived, into an IID in the Modified EUI-64 EUI-64 identifier is derived, into an IID in the Modified EUI-64
format. format.
In a variety of scenarios, addresses that remain stable for the In a variety of scenarios, addresses that remain stable for the
lifetime of a host's connection to a single subnet, are viewed as lifetime of a host's connection to a single subnet are viewed as
desirable. For example, stable addresses may be viewed as beneficial desirable. For example, stable addresses may be viewed as beneficial
for network management, event logging, enforcement of access control, for network management, event logging, enforcement of access control,
provision of quality of service, or for server or routing interfaces. provision of quality of service, or for server or router interfaces.
Similarly, stable addresses (as opposed to temporary addresses Similarly, stable addresses (as opposed to temporary addresses
[RFC4941]) allow for long-lived TCP connections, and are also usually [RFC4941]) allow for long-lived TCP connections and are also usually
desirable when performing server-like functions (i.e., receiving desirable when performing server-like functions (i.e., receiving
incoming connections). incoming connections).
The recommendations in this document apply only in cases where The recommendations in this document apply only in cases where
implementations otherwise would have configured a stable IPv6 IID implementations otherwise would have configured a stable IPv6 IID
containing a link layer address. For example, this document does not containing a link-layer address. For example, this document does not
change any existing recommendations concerning the use of temporary change any existing recommendations concerning the use of temporary
addresses as specified in [RFC4941], nor do the recommendations apply addresses as specified in [RFC4941] and the recommendations do not
to cases where SLAAC is employed to generate non-stable IPv6 apply to cases where SLAAC is employed to generate non-stable IPv6
addresses (e.g. by embedding a link-layer address that is addresses (e.g., by embedding a link-layer address that is
periodically randomized), nor does it introduce any new requirements periodically randomized); in addition, this document does not
regarding when stable addresses are to be configured. Thus, the introduce any new requirements regarding when stable addresses are to
recommendations in this document simply improve the security and be configured. Thus, the recommendations in this document simply
privacy properties of stable addresses. improve the security and privacy properties of stable addresses.
2. Terminology 2. Terminology
Stable address: Stable address:
An address that does not vary over time within the same network An address that does not vary over time within the same network
(as defined in [RFC7721]). (as defined in [RFC7721]).
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 RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Generation of IPv6 Interface Identifiers with SLAAC 3. Generation of IPv6 Interface Identifiers with SLAAC
Nodes SHOULD implement and employ [RFC7217] as the default scheme for Nodes SHOULD implement and employ [RFC7217] as the default scheme for
generating stable IPv6 addresses with SLAAC. A link layer MAY also generating stable IPv6 addresses with SLAAC. A link layer MAY also
define a mechanism for stable IPv6 address generation that is more define a mechanism for stable IPv6 address generation that is more
efficient and does not address the security and privacy efficient and does not address the security and privacy
considerations discussed in Section 1. The choice of whether to considerations discussed in Section 1. The choice of whether or not
enable the security- and privacy-preserving mechanism or not SHOULD to enable the security- and privacy-preserving mechanism SHOULD be
be configurable in such a case. configurable in such a case.
By default, nodes SHOULD NOT employ IPv6 address generation schemes By default, nodes SHOULD NOT employ IPv6 address generation schemes
that embed a stable link-layer address in the IID. In particular, that embed a stable link-layer address in the IID. In particular,
this document RECOMMENDS that nodes do not generate stable IIDs with this document RECOMMENDS that nodes do not generate stable IIDs with
the schemes specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491], the schemes specified in [RFC2464], [RFC2467], [RFC2470], [RFC2491],
[RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338], [RFC2492], [RFC2497], [RFC2590], [RFC3146], [RFC3572], [RFC4338],
[RFC4391], [RFC5121], and [RFC5072]. [RFC4391], [RFC5072], and [RFC5121].
4. Future Work 4. Future Work
At the time of this writing, the mechanisms specified in the At the time of this writing, the mechanisms specified in the
following documents might require updates to be fully compatible with following documents might require updates to be fully compatible with
the recommendations in this document: the recommendations in this document:
o "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based o "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based
Networks" [RFC6282] Networks" [RFC6282]
o "Transmission of IPv6 Packets over IEEE 802.15.4 Networks" o "Transmission of IPv6 Packets over IEEE 802.15.4 Networks"
[RFC4944] [RFC4944]
o "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless o "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)"[RFC6775] Personal Area Networks (6LoWPANs)" [RFC6775]
o "Transmission of IPv6 Packets over ITU-T G.9959 Networks" [RFC7428]
Future revisions or updates of these documents should take the issues
of privacy and security mentioned in Section 1 and explain any design
and engineering considerations that lead to the use of stable IIDs
based on a node's link-layer address.
5. IANA Considerations o "Transmission of IPv6 Packets over ITU-T G.9959 Networks"
[RFC7428]
There are no IANA registries within this document. The RFC-Editor Future revisions or updates of these documents should consider the
can remove this section before publication of this document as an issues of privacy and security mentioned in Section 1 and explain any
RFC. design and engineering considerations that lead to the use of stable
IIDs based on a node's link-layer address.
6. Security Considerations 5. Security Considerations
This recommends against the (default) use of predictable Interface This document recommends against the (default) use of predictable
Identifiers in IPv6 addresses. It recommends [RFC7217] as the Interface Identifiers in IPv6 addresses. It recommends [RFC7217] as
default scheme for generating IPv6 stable addresses with SLAAC, such the default scheme for generating IPv6 stable addresses with SLAAC,
that the security and privacy issues of IIDs that embed stable link- such that the security and privacy issues of IIDs that embed stable
layer addresses are mitigated. link-layer addresses are mitigated.
7. Acknowledgements 6. References
The authors would like to thank (in alphabetical order) Bob Hinden, 6.1. Normative References
Ray Hunter and Erik Nordmark, for providing a detailed review of this
document.
The authors would like to thank (in alphabetical order) Fred Baker, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Carsten Bormann, Scott Brim, Brian Carpenter, Samita Chakrabarti, Tim Requirement Levels", BCP 14, RFC 2119,
Chown, Lorenzo Colitti, Jean-Michel Combes, Greg Daley, Esko Dijk, DOI 10.17487/RFC2119, March 1997,
Ralph Droms, David Farmer, Brian Haberman, Ulrich Herberg, Philip <http://www.rfc-editor.org/info/rfc2119>.
Homburg, Jahangir Hossain, Jonathan Hui, Christian Huitema, Ray
Hunter, Erik Kline, Sheng Jiang, Roger Jorgensen, Dan Luedtke, Kerry
Lynn, George Mitchel, Gabriel Montenegro, Erik Nordmark, Simon
Perreault, Tom Petch, Alexandru Petrescu, Michael Richardson, Arturo
Servin, Mark Smith, Tom Taylor, Ole Troan, Tina Tsou, Glen Turner,
Randy Turner, James Woodyatt, and Juan Carlos Zuniga, for providing
valuable comments on earlier versions of this document.
8. References [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
8.1. Normative References [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<http://www.rfc-editor.org/info/rfc2464>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI
Requirement Levels", BCP 14, RFC 2119, Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998,
DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2467>.
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, IPv6 Packets over Token Ring Networks", RFC 2470,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. DOI 10.17487/RFC2470, December 1998,
<http://www.rfc-editor.org/info/rfc2470>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter,
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, "IPv6 over Non-Broadcast Multiple Access (NBMA)
<http://www.rfc-editor.org/info/rfc2464>. networks", RFC 2491, DOI 10.17487/RFC2491, January 1999,
<http://www.rfc-editor.org/info/rfc2491>.
[RFC2467] Crawford, M., "Transmission of IPv6 Packets over FDDI [RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM
Networks", RFC 2467, DOI 10.17487/RFC2467, December 1998, Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999,
<http://www.rfc-editor.org/info/rfc2467>. <http://www.rfc-editor.org/info/rfc2492>.
[RFC2470] Crawford, M., Narten, T., and S. Thomas, "Transmission of [RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet
IPv6 Packets over Token Ring Networks", RFC 2470, Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999,
DOI 10.17487/RFC2470, December 1998, <http://www.rfc-editor.org/info/rfc2497>.
<http://www.rfc-editor.org/info/rfc2470>.
[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 [RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of
over Non-Broadcast Multiple Access (NBMA) networks", IPv6 Packets over Frame Relay Networks Specification",
RFC 2491, DOI 10.17487/RFC2491, January 1999, RFC 2590, DOI 10.17487/RFC2590, May 1999,
<http://www.rfc-editor.org/info/rfc2491>. <http://www.rfc-editor.org/info/rfc2590>.
[RFC2492] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM [RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets
Networks", RFC 2492, DOI 10.17487/RFC2492, January 1999, over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146,
<http://www.rfc-editor.org/info/rfc2492>. October 2001, <http://www.rfc-editor.org/info/rfc3146>.
[RFC2497] Souvatzis, I., "Transmission of IPv6 Packets over ARCnet [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Networks", RFC 2497, DOI 10.17487/RFC2497, January 1999, Architecture", RFC 4291, DOI 10.17487/RFC4291, February
<http://www.rfc-editor.org/info/rfc2497>. 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC2590] Conta, A., Malis, A., and M. Mueller, "Transmission of [RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of
IPv6 Packets over Frame Relay Networks Specification", IPv6, IPv4, and Address Resolution Protocol (ARP) Packets
RFC 2590, DOI 10.17487/RFC2590, May 1999, over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338,
<http://www.rfc-editor.org/info/rfc2590>. January 2006, <http://www.rfc-editor.org/info/rfc4338>.
[RFC3146] Fujisawa, K. and A. Onoe, "Transmission of IPv6 Packets [RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over
over IEEE 1394 Networks", RFC 3146, DOI 10.17487/RFC3146, InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391,
October 2001, <http://www.rfc-editor.org/info/rfc3146>. April 2006, <http://www.rfc-editor.org/info/rfc4391>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Address Autoconfiguration", RFC 4862,
2006, <http://www.rfc-editor.org/info/rfc4291>. DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>.
[RFC4338] DeSanti, C., Carlson, C., and R. Nixon, "Transmission of [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
IPv6, IPv4, and Address Resolution Protocol (ARP) Packets Extensions for Stateless Address Autoconfiguration in
over Fibre Channel", RFC 4338, DOI 10.17487/RFC4338, IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
January 2006, <http://www.rfc-editor.org/info/rfc4338>. <http://www.rfc-editor.org/info/rfc4941>.
[RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391, April "Transmission of IPv6 Packets over IEEE 802.15.4
2006, <http://www.rfc-editor.org/info/rfc4391>. Networks", RFC 4944, DOI 10.17487/RFC4944, September
2007, <http://www.rfc-editor.org/info/rfc4944>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
Address Autoconfiguration", RFC 4862, over PPP", RFC 5072, DOI 10.17487/RFC5072, September
DOI 10.17487/RFC4862, September 2007, 2007, <http://www.rfc-editor.org/info/rfc5072>.
<http://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
Extensions for Stateless Address Autoconfiguration in Madanapalli, "Transmission of IPv6 via the IPv6
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, Convergence Sublayer over IEEE 802.16 Networks",
<http://www.rfc-editor.org/info/rfc4941>. RFC 5121, DOI 10.17487/RFC5121, February 2008,
<http://www.rfc-editor.org/info/rfc5121>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
"Transmission of IPv6 Packets over IEEE 802.15.4 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, DOI 10.17487/RFC6282, September 2011,
<http://www.rfc-editor.org/info/rfc4944>. <http://www.rfc-editor.org/info/rfc6282>.
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, Bormann, "Neighbor Discovery Optimization for IPv6 over
<http://www.rfc-editor.org/info/rfc5072>. Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. [RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Madanapalli, "Transmission of IPv6 via the IPv6 Interface Identifiers with IPv6 Stateless Address
Convergence Sublayer over IEEE 802.16 Networks", RFC 5121, Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC5121, February 2008, DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc5121>. <http://www.rfc-editor.org/info/rfc7217>.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, over ITU-T G.9959 Networks", RFC 7428,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC7428, February 2015,
<http://www.rfc-editor.org/info/rfc6282>. <http://www.rfc-editor.org/info/rfc7428>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 6.2. Informative References
Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque [Microsoft] Davies, J., "Understanding IPv6, 3rd. ed",
Interface Identifiers with IPv6 Stateless Address page 83, Microsoft Press, 2012,
Autoconfiguration (SLAAC)", RFC 7217, <http://it-ebooks.info/book/1022/>.
DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets [NUM-IDS] Gont, F. and I. Arce, "Security and Privacy Implications
over ITU-T G.9959 Networks", RFC 7428, of Numeric Identifiers Employed in Network Protocols",
DOI 10.17487/RFC7428, February 2015, Work in Progress, February 2016.
<http://www.rfc-editor.org/info/rfc7428>.
8.2. Informative References [RFC3572] Ogura, T., Maruyama, M., and T. Yoshida, "Internet
Protocol Version 6 over MAPOS (Multiple Access Protocol
Over SONET/SDH)", RFC 3572, DOI 10.17487/RFC3572, July
2003, <http://www.rfc-editor.org/info/rfc3572>.
[I-D.gont-predictable-numeric-ids] [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and
Gont, F. and I. Arce, "Security and Privacy Implications Privacy Considerations for IPv6 Address Generation
of Numeric Identifiers Employed in Network Protocols", Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016,
draft-gont-predictable-numeric-ids-00 (work in progress), <http://www.rfc-editor.org/info/rfc7721>.
February 2016.
[Microsoft] Acknowledgements
Davies, J., "Understanding IPv6, 3rd. ed", page 83,
Microsoft Press, 2012, <http://it-ebooks.info/book/1022/>.
[RFC3572] Ogura, T., Maruyama, M., and T. Yoshida, "Internet The authors would like to thank (in alphabetical order) Bob Hinden,
Protocol Version 6 over MAPOS (Multiple Access Protocol Ray Hunter, and Erik Nordmark, for providing a detailed review of
Over SONET/SDH)", RFC 3572, DOI 10.17487/RFC3572, July this document.
2003, <http://www.rfc-editor.org/info/rfc3572>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy The authors would like to thank (in alphabetical order) Fred Baker,
Considerations for IPv6 Address Generation Mechanisms", Carsten Bormann, Scott Brim, Brian Carpenter, Samita Chakrabarti, Tim
RFC 7721, DOI 10.17487/RFC7721, March 2016, Chown, Lorenzo Colitti, Jean-Michel Combes, Greg Daley, Esko Dijk,
<http://www.rfc-editor.org/info/rfc7721>. Ralph Droms, David Farmer, Brian Haberman, Ulrich Herberg, Philip
Homburg, Jahangir Hossain, Jonathan Hui, Christian Huitema, Ray
Hunter, Erik Kline, Sheng Jiang, Roger Jorgensen, Dan Luedtke, Kerry
Lynn, George Mitchel, Gabriel Montenegro, Erik Nordmark, Simon
Perreault, Tom Petch, Alexandru Petrescu, Michael Richardson, Arturo
Servin, Mark Smith, Tom Taylor, Ole Troan, Tina Tsou, Glen Turner,
Randy Turner, James Woodyatt, and Juan Carlos Zuniga, for providing
valuable comments on earlier draft versions of this document.
Authors' Addresses Authors' Addresses
Fernando Gont Fernando Gont
SI6 Networks / UTN-FRH SI6 Networks / UTN-FRH
Evaristo Carriego 2644 Evaristo Carriego 2644
Haedo, Provincia de Buenos Aires 1706 Haedo, Provincia de Buenos Aires 1706
Argentina Argentina
Phone: +54 11 4650 8472 Phone: +54 11 4650 8472
Email: fgont@si6networks.com Email: fgont@si6networks.com
URI: http://www.si6networks.com URI: https://www.si6networks.com
Alissa Cooper Alissa Cooper
Cisco Cisco
707 Tasman Drive 707 Tasman Drive
Milpitas, CA 95035 Milpitas, CA 95035
US United States of America
Phone: +1-408-902-3950 Phone: +1-408-902-3950
Email: alcoop@cisco.com Email: alcoop@cisco.com
URI: https://www.cisco.com/ URI: https://www.cisco.com/
Dave Thaler Dave Thaler
Microsoft Microsoft
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
Phone: +1 425 703 8835 Phone: +1 425 703 8835
Email: dthaler@microsoft.com Email: dthaler@microsoft.com
Will Liu Will (Shucheng) Liu
Huawei Technologies Huawei Technologies
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 Shenzhen 518129
P.R. China China
Email: liushucheng@huawei.com Email: liushucheng@huawei.com
 End of changes. 65 change blocks. 
210 lines changed or deleted 201 lines changed or added

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