draft-ietf-6man-default-iids-10.txt   draft-ietf-6man-default-iids-11.txt 
IPv6 maintenance Working Group (6man) F. Gont IPv6 maintenance Working Group (6man) F. Gont
Internet-Draft SI6 Networks / UTN-FRH Internet-Draft SI6 Networks / UTN-FRH
Updates: 2464, 2467, 2470, 2491, 2492, A. Cooper Updates: 2464, 2467, 2470, 2491, 2492, A. Cooper
2497, 2590, 3146, 3315, 3572, Cisco 2497, 2590, 3146, 3315, 3572, Cisco
4291, 4338, 4391, 5072, 5121 D. Thaler 4291, 4338, 4391, 5072, 5121 D. Thaler
(if approved) Microsoft (if approved) Microsoft
Intended status: Standards Track W. Liu Intended status: Standards Track W. Liu
Expires: August 20, 2016 Huawei Technologies Expires: October 29, 2016 Huawei Technologies
February 17, 2016 April 27, 2016
Recommendation on Stable IPv6 Interface Identifiers Recommendation on Stable IPv6 Interface Identifiers
draft-ietf-6man-default-iids-10 draft-ietf-6man-default-iids-11
Abstract Abstract
This document changes the default Interface Identifier generation This document changes the default scheme for generating stable
scheme for SLAAC to that specified in RFC7217, and recommends against Interface Identifiers with SLAAC to that specified in RFC7217, and
embedding link-layer addresses in IPv6 Interface Identifiers. It recommends against embedding link-layer addresses in IPv6 Interface
formally updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, Identifiers. It formally updates RFC2464, RFC2467, RFC2470, RFC2491,
RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338,
RFC5072, and RFC5121, by removing the text in these RFCs that RFC4391, RFC5072, and RFC5121, by removing the text in these RFCs
required the IPv6 Interface Identifiers to be derived from the that required the IPv6 Interface Identifiers to be derived from the
underlying link-layer address, and replacing the aforementioned text underlying link-layer address, and replacing the aforementioned text
with a pointer to this document. Additionally, this document updates with a pointer to this document. Additionally, this document updates
RFC3315 by specifying additional requirements on the generation of RFC3315 by specifying additional requirements on the generation of
Interface Identifiers used in Dynamic Host Configuration Protocol Interface Identifiers used in Dynamic Host Configuration Protocol
version 6 (DHCPv6). It also provides advice to system administrators version 6 (DHCPv6). It also provides advice to system administrators
who employ manual configuration. who employ manual configuration. This document does not 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 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 August 20, 2016. This Internet-Draft will expire on October 29, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Generation of IPv6 Interface Identifiers with SLAAC . . . . . 3 3. Generation of IPv6 Interface Identifiers with SLAAC . . . . . 4
4. Generation of IPv6 Interface Identifiers with DHCPv6 . . . . 4 4. Generation of IPv6 Interface Identifiers with DHCPv6 . . . . 5
5. Generation of IPv6 Interface Identifiers with Manual 5. Generation of IPv6 Interface Identifiers with Manual
Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5 Configuration . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Update to existing RFCs . . . . . . . . . . . . . . . . . . . 5 6. Update to existing RFCs . . . . . . . . . . . . . . . . . . . 6
7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 link-layer address (e.g., an IEEE LAN MAC typically embeds a 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, the IP-over-IEEE802.15.4 standard in [RFC6775] allows for
compression of IPv6 addresses when the IID is based on the underlying compression of IPv6 addresses when the IID is based on the underlying
link-layer address. link-layer address.
The security and privacy implications of embedding a link-layer The security and privacy implications of embedding a link-layer
address in an IPv6 IID have been known for some time now, and are address in an IPv6 IID have been known for some time now, and are
discussed in great detail in discussed in great detail in [RFC7721]. They include:
[I-D.ietf-6man-ipv6-address-generation-privacy]; 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
Some popular IPv6 implementations have already deviated from the More generally, the reuse of identifiers that have their own
traditional stable IID generation scheme to mitigate the semantics or properties across different contexts or scopes can be
detrimental for security and privacy
[I-D.gont-predictable-numeric-ids]. In the case of traditional
stable IPv6 IIDs, some of the security and privacy implications are
dependent on the properties of the underlying link-layer addresses
(e.g., whether the link-layer address is ephemeral or randomly
generated), while other implications (e.g., reduction of the entropy
of the IID) depend on the algorithm for generating the IID itself.
In standardized recommendations for IPv6 IID generation meant to
achieve particular security and privacy properties, it is therefore
necessary to recommend against embedding link-layer addresses in IPv6
IIDs.
Furthermore, some popular IPv6 implementations have already deviated
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
default Interface Identifier generation scheme for SLAAC to that default IID generation scheme for SLAAC to that specified in
specified in [RFC7217], and recommends against embedding link-layer [RFC7217], and recommends against embedding link-layer addresses in
addresses in IPv6 Interface Identifiers, such that the aforementioned IPv6 Interface Identifiers, such that the aforementioned issues are
issues are mitigated. mitigated. That is, this document simply replaces the default
algorithm that must 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
lifetime of a host's connection to a single subnet, are viewed as
desirable. For example, stable addresses may be viewed as beneficial
for network management, event logging, enforcement of access control,
provision of quality of service, or for server or routing interfaces.
Similarly, stable addresses (as opposed to temporary addresses
[RFC4941]) allow for long-lived TCP connections, and are also usually
desirable when performing server-like functions (i.e., receiving
incoming connections).
The recommendations in this document apply only in cases where
implementations otherwise would have configured a stable IPv6 IID
containing a link layer address. That is, this document does not
change any existing recommendations concerning the use of temporary
addresses as specified in [RFC4941], nor does it introduce any new
requirements regarding when stable addresses are to be configured.
Thus, the recommendations in this document simply improve the
security and privacy properties of stable addresses.
Finally this document updates [RFC3315] by specifying additional Finally this document updates [RFC3315] by specifying additional
requirements on the generation of Interface Identifiers used in requirements on the generation of Interface Identifiers used in
Dynamic Host Configuration Protocol version 6 (DHCPv6), and also Dynamic Host Configuration Protocol version 6 (DHCPv6), and also
provides advice to system administrators who employ manual provides advice to system administrators who employ manual
configuration. configuration.
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 [I-D.ietf-6man-ipv6-address-generation-privacy]). (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
Link layers MUST define a mechanism that provides mitigation of the Link layers MUST define a mechanism that provides mitigation of the
security and privacy implications discussed in Section 1. Such security and privacy implications discussed in Section 1. Such
mechanism MUST meet the following requirements: mechanism MUST meet the following requirements:
skipping to change at page 5, line 10 skipping to change at page 5, line 45
consecutive small numbers). [I-D.ietf-dhc-stable-privacy-addresses] consecutive small numbers). [I-D.ietf-dhc-stable-privacy-addresses]
specifies one possible algorithm that could be employed to comply specifies one possible algorithm that could be employed to comply
with this requirement. Another possible algorithm would be to select with this requirement. Another possible algorithm would be to select
a pseudo-random value chosen from a discrete uniform distribution, a pseudo-random value chosen from a discrete uniform distribution,
while avoiding the reserved IPv6 Interface Identifiers [RFC5453] while avoiding the reserved IPv6 Interface Identifiers [RFC5453]
[IANA-RESERVED-IID]. [IANA-RESERVED-IID].
5. Generation of IPv6 Interface Identifiers with Manual Configuration 5. Generation of IPv6 Interface Identifiers with Manual Configuration
Network administrators should be aware of the security implications Network administrators should be aware of the security implications
of predictable Interface Identifiers of predictable Interface Identifiers [RFC7721], and avoid the use of
[I-D.ietf-6man-ipv6-address-generation-privacy], and avoid the use of
predictable addresses when the aforementioned issues are of concern. predictable addresses when the aforementioned issues are of concern.
6. Update to existing RFCs 6. Update to existing RFCs
The following subsections clarify how each of the RFCs affected by The following subsections clarify how each of the RFCs affected by
this document are updated. this document are updated.
Note to the RFC Editor: Note to the RFC Editor:
In the following subsections, the legend "[RFCXXXX]" should be In the following subsections, the legend "[RFCXXXX]" should be
replaced with the RFC number assigned to this document, and this replaced with the RFC number assigned to this document, and this
skipping to change at page 18, line 42 skipping to change at page 19, line 42
The authors would like to thank (in alphabetical order) Fred Baker, The authors would like to thank (in alphabetical order) Fred Baker,
Carsten Bormann, Scott Brim, Brian Carpenter, Samita Chakrabarti, Tim Carsten Bormann, Scott Brim, Brian Carpenter, Samita Chakrabarti, Tim
Chown, Lorenzo Colitti, Jean-Michel Combes, Greg Daley, Esko Dijk, Chown, Lorenzo Colitti, Jean-Michel Combes, Greg Daley, Esko Dijk,
Ralph Droms, David Farmer, Brian Haberman, Ulrich Herberg, Philip Ralph Droms, David Farmer, Brian Haberman, Ulrich Herberg, Philip
Homburg, Jahangir Hossain, Jonathan Hui, Christian Huitema, Ray Homburg, Jahangir Hossain, Jonathan Hui, Christian Huitema, Ray
Hunter, Erik Kline, Sheng Jiang, Roger Jorgensen, Dan Luedtke, Kerry Hunter, Erik Kline, Sheng Jiang, Roger Jorgensen, Dan Luedtke, Kerry
Lynn, George Mitchel, Gabriel Montenegro, Erik Nordmark, Simon Lynn, George Mitchel, Gabriel Montenegro, Erik Nordmark, Simon
Perreault, Tom Petch, Alexandru Petrescu, Michael Richardson, Arturo Perreault, Tom Petch, Alexandru Petrescu, Michael Richardson, Arturo
Servin, Mark Smith, Tom Taylor, Ole Troan, Tina Tsou, Glen Turner, Servin, Mark Smith, Tom Taylor, Ole Troan, Tina Tsou, Glen Turner,
Randy Turner, and James Woodyatt, for providing valuable comments on Randy Turner, James Woodyatt, and Juan Carlos Zuniga, for providing
earlier versions of this document. valuable comments on earlier versions of this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 20, line 19 skipping to change at page 21, line 19
[RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over [RFC4391] Chu, J. and V. Kashyap, "Transmission of IP over
InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391, April InfiniBand (IPoIB)", RFC 4391, DOI 10.17487/RFC4391, April
2006, <http://www.rfc-editor.org/info/rfc4391>. 2006, <http://www.rfc-editor.org/info/rfc4391>.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, Address Autoconfiguration", RFC 4862,
DOI 10.17487/RFC4862, September 2007, DOI 10.17487/RFC4862, September 2007,
<http://www.rfc-editor.org/info/rfc4862>. <http://www.rfc-editor.org/info/rfc4862>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<http://www.rfc-editor.org/info/rfc4944>. <http://www.rfc-editor.org/info/rfc4944>.
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007, over PPP", RFC 5072, DOI 10.17487/RFC5072, September 2007,
<http://www.rfc-editor.org/info/rfc5072>. <http://www.rfc-editor.org/info/rfc5072>.
[RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S. [RFC5121] Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
skipping to change at page 21, line 18 skipping to change at page 22, line 18
DOI 10.17487/RFC7217, April 2014, DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>. <http://www.rfc-editor.org/info/rfc7217>.
[RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets
over ITU-T G.9959 Networks", RFC 7428, over ITU-T G.9959 Networks", RFC 7428,
DOI 10.17487/RFC7428, February 2015, DOI 10.17487/RFC7428, February 2015,
<http://www.rfc-editor.org/info/rfc7428>. <http://www.rfc-editor.org/info/rfc7428>.
11.2. Informative References 11.2. Informative References
[I-D.ietf-6man-ipv6-address-generation-privacy] [I-D.gont-predictable-numeric-ids]
Cooper, A., Gont, F., and D. Thaler, "Privacy Gont, F. and I. Arce, "Security and Privacy Implications
Considerations for IPv6 Address Generation Mechanisms", of Numeric Identifiers Employed in Network Protocols",
draft-ietf-6man-ipv6-address-generation-privacy-08 (work draft-gont-predictable-numeric-ids-00 (work in progress),
in progress), September 2015. February 2016.
[I-D.ietf-dhc-stable-privacy-addresses] [I-D.ietf-dhc-stable-privacy-addresses]
Gont, F. and S. LIU, "A Method for Generating Semantically Gont, F. and S. LIU, "A Method for Generating Semantically
Opaque Interface Identifiers with Dynamic Host Opaque Interface Identifiers with Dynamic Host
Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc- Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-
stable-privacy-addresses-02 (work in progress), April stable-privacy-addresses-02 (work in progress), April
2015. 2015.
[IANA-RESERVED-IID] [IANA-RESERVED-IID]
IANA, "Reserved IPv6 Interface Identifiers", IANA, "Reserved IPv6 Interface Identifiers",
skipping to change at page 21, line 44 skipping to change at page 22, line 44
[Microsoft] [Microsoft]
Davies, J., "Understanding IPv6, 3rd. ed", page 83, Davies, J., "Understanding IPv6, 3rd. ed", page 83,
Microsoft Press, 2012, <http://it-ebooks.info/book/1022/>. Microsoft Press, 2012, <http://it-ebooks.info/book/1022/>.
[RFC3572] Ogura, T., Maruyama, M., and T. Yoshida, "Internet [RFC3572] Ogura, T., Maruyama, M., and T. Yoshida, "Internet
Protocol Version 6 over MAPOS (Multiple Access Protocol Protocol Version 6 over MAPOS (Multiple Access Protocol
Over SONET/SDH)", RFC 3572, DOI 10.17487/RFC3572, July Over SONET/SDH)", RFC 3572, DOI 10.17487/RFC3572, July
2003, <http://www.rfc-editor.org/info/rfc3572>. 2003, <http://www.rfc-editor.org/info/rfc3572>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016,
<http://www.rfc-editor.org/info/rfc7721>.
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: http://www.si6networks.com
 End of changes. 18 change blocks. 
40 lines changed or deleted 86 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/