draft-ietf-6man-stable-privacy-addresses-16.txt   draft-ietf-6man-stable-privacy-addresses-17.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
Intended status: Standards Track December 10, 2013 Intended status: Standards Track January 27, 2014
Expires: June 13, 2014 Expires: July 31, 2014
A Method for Generating Semantically Opaque Interface Identifiers with A Method for Generating Semantically Opaque Interface Identifiers with
IPv6 Stateless Address Autoconfiguration (SLAAC) IPv6 Stateless Address Autoconfiguration (SLAAC)
draft-ietf-6man-stable-privacy-addresses-16 draft-ietf-6man-stable-privacy-addresses-17
Abstract Abstract
This document specifies a method for generating IPv6 Interface This document specifies a method for generating IPv6 Interface
Identifiers to be used with IPv6 Stateless Address Autoconfiguration Identifiers to be used with IPv6 Stateless Address Autoconfiguration
(SLAAC), such that addresses configured using this method are stable (SLAAC), such that addresses configured using this method are stable
within each subnet, but the Interface Identifier changes when hosts within each subnet, but the Interface Identifier changes when hosts
move from one network to another. This method is meant to be an move from one network to another. This method is meant to be an
alternative to generating Interface Identifiers based on hardware alternative to generating Interface Identifiers based on hardware
addresses (e.g., IEEE LAN MAC addresses), such that the benefits of addresses (e.g., IEEE LAN MAC addresses), such that the benefits of
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 June 13, 2014. This Internet-Draft will expire on July 31, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Relationship to Other standards . . . . . . . . . . . . . . . 5 3. Relationship to Other standards . . . . . . . . . . . . . . . 5
4. Design goals . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Design goals . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Algorithm specification . . . . . . . . . . . . . . . . . . . 6 5. Algorithm specification . . . . . . . . . . . . . . . . . . . 6
6. Resolving Duplicate Address Detection (DAD) conflicts . . . . 11 6. Resolving Duplicate Address Detection (DAD) conflicts . . . . 11
7. Specified Constants . . . . . . . . . . . . . . . . . . . . . 12 7. Specified Constants . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 16 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Possible sources for the Net_Iface parameter . . . . 17 Appendix A. Possible sources for the Net_Iface parameter . . . . 18
A.1. Interface Index . . . . . . . . . . . . . . . . . . . . . 17 A.1. Interface Index . . . . . . . . . . . . . . . . . . . . . 18
A.2. Interface Name . . . . . . . . . . . . . . . . . . . . . 18 A.2. Interface Name . . . . . . . . . . . . . . . . . . . . . 18
A.3. Link-layer Addresses . . . . . . . . . . . . . . . . . . 18 A.3. Link-layer Addresses . . . . . . . . . . . . . . . . . . 19
A.4. Logical Network Service Identity . . . . . . . . . . . . 18 A.4. Logical Network Service Identity . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
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) that typically embeds local router, and an Interface Identifier (IID) that typically embeds
a hardware address (e.g., an IEEE LAN MAC address) [RFC4291]. a hardware address (e.g., an IEEE LAN MAC address) [RFC4291].
Cryptographically Generated Addresses (CGAs) [RFC3972] are yet Cryptographically Generated Addresses (CGAs) [RFC3972] are yet
skipping to change at page 3, line 46 skipping to change at page 3, line 46
the extent to which the method discussed in this document mitigates the extent to which the method discussed in this document mitigates
them. them.
The "Privacy Extensions for Stateless Address Autoconfiguration in The "Privacy Extensions for Stateless Address Autoconfiguration in
IPv6" [RFC4941] (henceforth referred to as "temporary addresses") IPv6" [RFC4941] (henceforth referred to as "temporary addresses")
were introduced to complicate the task of eavesdroppers and other were introduced to complicate the task of eavesdroppers and other
information collectors (e.g., IPv6 addresses in web server logs or information collectors (e.g., IPv6 addresses in web server logs or
email headers, etc.) to correlate the activities of a node, and email headers, etc.) to correlate the activities of a node, and
basically result in temporary (and random) Interface Identifiers. basically result in temporary (and random) Interface Identifiers.
These temporary addresses are generated in addition to the These temporary addresses are generated in addition to the
traditional IPv6 addresses based on IEEE LAC MAC addresses, with the traditional IPv6 addresses based on IEEE LAN MAC addresses, with the
"temporary addresses" being employed for "outgoing communications", "temporary addresses" being employed for "outgoing communications",
and the traditional SLAAC addresses being employed for "server" and the traditional SLAAC addresses being employed for "server"
functions (i.e., receiving incoming connections). functions (i.e., receiving incoming connections).
It should be noted that temporary addresses can be challenging in a It should be noted that temporary addresses can be challenging in a
number of areas. For example, from a network-management point of number of areas. For example, from a network-management point of
view, they tend to increase the complexity of event logging, trouble- view, they tend to increase the complexity of event logging, trouble-
shooting, enforcement of access controls and quality of service, etc. shooting, enforcement of access controls and quality of service, etc.
As a result, some organizations disable the use of temporary As a result, some organizations disable the use of temporary
addresses even at the expense of reduced privacy [Broersma]. addresses even at the expense of reduced privacy [Broersma].
skipping to change at page 5, line 34 skipping to change at page 5, line 37
While the method specified in this document is meant to be used with While the method specified in this document is meant to be used with
SLAAC, this does not preclude this algorithm from being used with SLAAC, this does not preclude this algorithm from being used with
other address configuration mechanisms, such as DHCPv6 [RFC3315] or other address configuration mechanisms, such as DHCPv6 [RFC3315] or
manual address configuration. manual address configuration.
4. Design goals 4. Design goals
This document specifies a method for generating Interface Identifiers This document specifies a method for generating Interface Identifiers
to be used with IPv6 SLAAC, with the following goals: to be used with IPv6 SLAAC, with the following goals:
o The resulting Interface Identifiers remain constant/stable for o The resulting Interface Identifiers remain stable for each prefix
each prefix used with SLAAC within each subnet. That is, the used with SLAAC within each subnet for the same network interface.
algorithm generates the same Interface Identifier when configuring That is, the algorithm generates the same Interface Identifier
an address (for the same interface) belonging to the same prefix when configuring an address (for the same interface) belonging to
within the same subnet. the same prefix within the same subnet.
o The resulting Interface Identifiers do change when addresses are o The resulting Interface Identifiers must change when addresses are
configured for different prefixes. That is, if different configured for different prefixes. That is, if different
autoconfiguration prefixes are used to configure addresses for the autoconfiguration prefixes are used to configure addresses for the
same network interface card, the resulting Interface Identifiers same network interface card, the resulting Interface Identifiers
must be (statistically) different. This means that, given two must be (statistically) different. This means that, given two
addresses produced by the method specified in this document, it addresses produced by the method specified in this document, it
must be difficult for an attacker tell whether the addresses have must be difficult for an attacker tell whether the addresses have
been generated/used by the same node. been generated/used by the same node.
o It must be difficult for an outsider to predict the Interface o It must be difficult for an outsider to predict the Interface
Identifiers that will be generated by the algorithm, even with Identifiers that will be generated by the algorithm, even with
skipping to change at page 7, line 41 skipping to change at page 7, line 32
Random (but stable) Identifier Random (but stable) Identifier
F(): F():
A pseudorandom function (PRF) that MUST NOT be computable from A pseudorandom function (PRF) that MUST NOT be computable from
the outside (without knowledge of the secret key). F() MUST the outside (without knowledge of the secret key). F() MUST
also be difficult to reverse, such that it resists attempts to also be difficult to reverse, such that it resists attempts to
obtain the secret_key, even when given samples of the output obtain the secret_key, even when given samples of the output
of F() and knowledge or control of the other input parameters. of F() and knowledge or control of the other input parameters.
F() SHOULD produce an output of at least 64 bits. F() could F() SHOULD produce an output of at least 64 bits. F() could
be implemented as a cryptographic hash of the concatenation of be implemented as a cryptographic hash of the concatenation of
each of the function parameters. MD5 [RFC1321] and SHA-1 each of the function parameters. SHA-1 [FIPS-SHS] and SHA-256
[FIPS-SHS] are two possible options for F(). are two possible options for F(). Note: MD5 [RFC1321] is
considered unacceptable for F() [RFC6151].
Prefix: Prefix:
The prefix to be used for SLAAC, as learned from an ICMPv6 The prefix to be used for SLAAC, as learned from an ICMPv6
Router Advertisement message, or the link-local IPv6 unicast Router Advertisement message, or the link-local IPv6 unicast
prefix [RFC4291]. prefix [RFC4291].
Net_Iface: Net_Iface:
An implementation-dependent stable identifier associated with An implementation-dependent stable identifier associated with
the network interface for which the RID is being generated. the network interface for which the RID is being generated.
An implementation MAY provide a configuration option to select An implementation MAY provide a configuration option to select
the source of the identifier to be used for the Net_Iface the source of the identifier to be used for the Net_Iface
parameter. A discussion of possible sources for this value parameter. A discussion of possible sources for this value
(along with the corresponding trade-offs) can be found in (along with the corresponding trade-offs) can be found in
Appendix A. Appendix A.
Network_ID: Network_ID:
Some network specific data that identifies the subnet to which Some network specific data that identifies the subnet to which
this interface is attached. For example the IEEE 802.11 this interface is attached. For example the IEEE 802.11
Service Set Identifier (SSID) corresponding to the network to Service Set Identifier (SSID) corresponding to the network to
which this interface is associated. This parameter is which this interface is associated. Additionally, Simple DNA
OPTIONAL. [RFC6059] describes ideas that could be leveraged to generate
a Network_ID parameter. This parameter is OPTIONAL.
DAD_Counter: DAD_Counter:
A counter that is employed to resolve Duplicate Address A counter that is employed to resolve Duplicate Address
Detection (DAD) conflicts. It MUST be initialized to 0, and Detection (DAD) conflicts. It MUST be initialized to 0, and
incremented by 1 for each new tentative address that is incremented by 1 for each new tentative address that is
configured as a result of a DAD conflict. Implementations configured as a result of a DAD conflict. Implementations
that record DAD_Counter in non-volatile memory for each that record DAD_Counter in non-volatile memory for each
{Prefix, Net_Iface, Network_ID} tuple MUST initialize {Prefix, Net_Iface, Network_ID} tuple MUST initialize
DAD_Counter to the recorded value if such an entry exists in DAD_Counter to the recorded value if such an entry exists in
non-volatile memory. See Section 6 for additional details. non-volatile memory. See Section 6 for additional details.
secret_key: secret_key:
A secret key that is not known by the attacker. The secret A secret key that is not known by the attacker. The secret
key MUST be initialized to a pseudo-random number (see key MUST be initialized to a pseudo-random number (see
[RFC4086] for randomness requirements for security) at [RFC4086] for randomness requirements for security) at
operating system installation time or when the IPv6 protocol operating system installation time or when the IPv6 protocol
stack is initialized for the first time. An implementation stack is initialized for the first time. An implementation
MAY provide the means for the the system administrator to MAY provide the means for the the system administrator to
change or display the secret key. display and change the secret key.
2. The Interface Identifier is finally obtained by taking as many 2. The Interface Identifier is finally obtained by taking as many
bits from the RID value (computed in the previous step) as bits from the RID value (computed in the previous step) as
necessary, starting from the least significant bit. necessary, starting from the least significant bit.
We note that [RFC4291] requires that, the Interface IDs of all We note that [RFC4291] requires that, the Interface IDs of all
unicast addresses (except those that start with the binary unicast addresses (except those that start with the binary
value 000) be 64-bit long. However, the method discussed in value 000) be 64-bit long. However, the method discussed in
this document could be employed for generating Interface IDs this document could be employed for generating Interface IDs
of any arbitrary length, albeit at the expense of reduced of any arbitrary length, albeit at the expense of reduced
skipping to change at page 9, line 14 skipping to change at page 9, line 8
identifier has been generated, this situation SHOULD be handled identifier has been generated, this situation SHOULD be handled
in the same way as the case of duplicate addresses (see in the same way as the case of duplicate addresses (see
Section 6). Section 6).
This document does not require the use of any specific PRF for the This document does not require the use of any specific PRF for the
function F() above, since the choice of such PRF is usually a trade- function F() above, since the choice of such PRF is usually a trade-
off between a number of properties (processing requirements, ease of off between a number of properties (processing requirements, ease of
implementation, possible intellectual property rights, etc.), and implementation, possible intellectual property rights, etc.), and
since the best possible choice for F() might be different for since the best possible choice for F() might be different for
different types of devices (e.g. embedded systems vs. regular different types of devices (e.g. embedded systems vs. regular
servers) and might possibly change over time. For informative servers) and might possibly change over time.
purposes, we note that MD5 [RFC1321] and SHA-1 [FIPS-SHS] are two
possible options for F().
Note that the result of F() in the algorithm above is no more secure
than the secret key. If an attacker is aware of the PRF that is
being used by the victim (which we should expect), and the attacker
can obtain enough material (i.e. addresses configured by the victim),
the attacker may simply search the entire secret-key space to find
matches. To protect against this, the secret key should be of a
reasonable length. Key lengths of at least 128 bits should be
adequate. The secret key is initialized at system installation time
to a pseudo-random number, thus allowing this mechanism to be enabled
/used automatically, without user intervention.
Including the SLAAC prefix in the PRF computation causes the Including the SLAAC prefix in the PRF computation causes the
Interface Identifier to vary across each prefix (link-local, global, Interface Identifier to vary across each prefix (link-local, global,
etc.) employed by the node and, as consequently, also across etc.) employed by the node and, as consequently, also across
networks. This mitigates the correlation of activities of multi- networks. This mitigates the correlation of activities of multi-
homed nodes (since each of the corresponding addresses will employ a homed nodes (since each of the corresponding addresses will employ a
different Interface ID), host-tracking (since the network prefix will different Interface ID), host-tracking (since the network prefix will
change as the node moves from one network to another), and any other change as the node moves from one network to another), and any other
attacks that benefit from predictable Interface Identifiers (such as attacks that benefit from predictable Interface Identifiers (such as
IPv6 address scanning attacks). IPv6 address scanning attacks).
skipping to change at page 10, line 10 skipping to change at page 9, line 39
Since the stability of the addresses generated with this method Since the stability of the addresses generated with this method
relies on the stability of all arguments of F(), it is key that the relies on the stability of all arguments of F(), it is key that the
Net_Iface be constant across system bootstrap sequences and other Net_Iface be constant across system bootstrap sequences and other
network events. Additionally, the Net_Iface must uniquely identify network events. Additionally, the Net_Iface must uniquely identify
an interface within the node, such that two interfaces connecting to an interface within the node, such that two interfaces connecting to
the same network do not result in duplicate addresses. Different the same network do not result in duplicate addresses. Different
types of operating systems might benefit from different stability types of operating systems might benefit from different stability
properties of the Net_Iface parameter. For example, a client- properties of the Net_Iface parameter. For example, a client-
oriented operating system might want to employ Net_Iface identifiers oriented operating system might want to employ Net_Iface identifiers
that are attached to the underlying network interface card (NIC), that are attached to the NIC, such that a removable NIC always gets
such that a removable NIC always gets the same IPv6 address, the same IPv6 address, irrespective of the system communications port
irrespective of the system communications port to which it is to which it is attached. On the other hand, a server-oriented
attached. On the other hand, a server-oriented operating system operating system might prefer Net_Iface identifiers that are attached
might prefer Net_Iface identifiers that are attached to system slots/ to system slots/ports, such that replacement of a network interface
ports, such that replacement of a network interface card does not card does not result in an IPv6 address change. Appendix A discusses
result in an IPv6 address change. Appendix A discusses possible possible sources for the Net_Iface, along with their pros and cons.
sources for the Net_Iface, along with their pros and cons.
Including the optional Network_ID parameter when computing the RID Including the optional Network_ID parameter when computing the RID
value above causes the algorithm to produce a different Interface value above causes the algorithm to produce a different Interface
Identifier when connecting to different networks, even when Identifier when connecting to different networks, even when
configuring addresses belonging to the same prefix. This means that configuring addresses belonging to the same prefix. This means that
a host would employ a different Interface Identifier as it moves from a host would employ a different Interface Identifier as it moves from
one network to another even for IPv6 link-local addresses or Unique one network to another even for IPv6 link-local addresses or Unique
Local Addresses (ULAs). In those scenarios where the Network_ID is Local Addresses (ULAs) [RFC4193]. In those scenarios where the
unknown to the attacker, including this parameter might help mitigate Network_ID is unknown to the attacker, including this parameter might
attacks where a victim node connects to the same subnet as the help mitigate attacks where a victim node connects to the same subnet
attacker, and the attacker tries to learn the Interface Identifier as the attacker, and the attacker tries to learn the Interface
used by the victim node for a remote network (see Section 9 for Identifier used by the victim node for a remote network (see
further details). Section 9 for further details).
The DAD_Counter parameter provides the means to intentionally cause The DAD_Counter parameter provides the means to intentionally cause
this algorithm to produce a different IPv6 addresses (all other this algorithm to produce a different IPv6 addresses (all other
parameters being the same). This could be necessary to resolve parameters being the same). This could be necessary to resolve
Duplicate Address Detection (DAD) conflicts, as discussed in detail Duplicate Address Detection (DAD) conflicts, as discussed in detail
in Section 6. in Section 6.
Finally, we note that all of the bits in the resulting Interface IDs Note that the result of F() in the algorithm above is no more secure
are treated as "opaque" bits [I-D.ietf-6man-ug]. For example, the than the secret key. If an attacker is aware of the PRF that is
being used by the victim (which we should expect), and the attacker
can obtain enough material (i.e. addresses configured by the victim),
the attacker may simply search the entire secret-key space to find
matches. To protect against this, the secret key SHOULD be of at
least 128 bits. Key lengths of at least 128 bits should be adequate.
The secret key is initialized at system installation time to a
pseudo-random number, thus allowing this mechanism to be enabled/used
automatically, without user intervention. Providing a mechanism to
display and change the secret_key would allow and administrator to
cause a replaced system (with the same implementation of this
document) to generate the same IPv6 addresses as the system being
replaced. We note that since the privacy of the scheme specified in
this document relies on the secrecy of the secret_key parameter,
implementations should constrain access to the secret_key parameter
to the extent practicable (e.g., require superuser privileges to
access it). Furthermore, in order to prevent leakages of the
secret_key parameter, it should not be used for any other purposes
than being a parameter to the scheme specified in this document.
We note that all of the bits in the resulting Interface IDs are
treated as "opaque" bits [I-D.ietf-6man-ug]. For example, the
universal/local bit of Modified EUI-64 format identifiers is treated universal/local bit of Modified EUI-64 format identifiers is treated
as any other bit of such identifier. In theory, this might result in as any other bit of such identifier. In theory, this might result in
Duplicate Address Detection (DAD) failures that would otherwise not IPv6 address collisions and Duplicate Address Detection (DAD)
be encountered. However, this is not deemed as a real issue, because failures that would otherwise not be encountered. However, this is
of the following considerations: not deemed as a likely issue, because of the following
considerations:
o The interface IDs of all addresses (except those of addresses that o The interface IDs of all addresses (except those of addresses that
that start with the binary value 000) are 64-bit long. Since the that start with the binary value 000) are 64-bit long. Since the
method specified in this document results in random Interface IDs, method specified in this document results in random Interface IDs,
the probability of DAD failures is very small. the probability of DAD failures is very small.
o Real world data indicates that MAC address reuse is far more o Real world data indicates that MAC address reuse is far more
common than assumed [HDMoore]. This means that even IPv6 common than assumed [HDMoore]. This means that even IPv6
addresses that employ (allegedly) unique identifiers (such as IEEE addresses that employ (allegedly) unique identifiers (such as IEEE
LAN MAC addresses) might result in DAD failures, and hence LAN MAC addresses) might result in DAD failures, and hence
implementations should be prepared to gracefully handle such implementations should be prepared to gracefully handle such
occurrences. occurrences. Additionally, some virtualization technologies
already employ hardware addresses that are randomly selected, and
hence cannot be guaranteed to be unique
[I-D.ietf-opsec-ipv6-host-scanning].
o Since some popular and widely-deployed operating systems (such as o Since some popular and widely-deployed operating systems (such as
Microsoft Windows) do not employ unique hardware addresses for the Microsoft Windows) do not embed hardware addresses in the
Interface IDs of their stable addresses, reliance on such unique Interface IDs of their stable addresses, reliance on such unique
identifiers is more reduced in the deployed world (fewer deployed identifiers is more reduced in the deployed world (fewer deployed
systems rely on them for the avoidance of address collisions). systems rely on them for the avoidance of address collisions).
Finally, that since different implementation are likely to use
different values for the secret_key parameter, and may also employ
different PRFs for F() and different sources for the Net_Iface
parameter, the addresses generated by this scheme should not expected
to be stable across different operating system installations. For
example, a host that is dual-boot or that is reinstalled may result
in different IPv6 addresses for each operating system and/or
installation.
6. Resolving Duplicate Address Detection (DAD) conflicts 6. Resolving Duplicate Address Detection (DAD) conflicts
If as a result of performing Duplicate Address Detection (DAD) If as a result of performing Duplicate Address Detection (DAD)
[RFC4862] a host finds that the tentative address generated with the [RFC4862] a host finds that the tentative address generated with the
algorithm specified in Section 5 is a duplicate address, it SHOULD algorithm specified in Section 5 is a duplicate address, it SHOULD
resolve the address conflict by trying a new tentative address as resolve the address conflict by trying a new tentative address as
follows: follows:
o DAD_Counter is incremented by 1. o DAD_Counter is incremented by 1.
skipping to change at page 12, line 39 skipping to change at page 13, line 5
9. Security Considerations 9. Security Considerations
This document specifies an algorithm for generating Interface This document specifies an algorithm for generating Interface
Identifiers to be used with IPv6 Stateless Address Autoconfiguration Identifiers to be used with IPv6 Stateless Address Autoconfiguration
(SLAAC), as an alternative to e.g. Interface Identifiers that embed (SLAAC), as an alternative to e.g. Interface Identifiers that embed
hardware addresses (such as those specified in [RFC2464], [RFC2467], hardware addresses (such as those specified in [RFC2464], [RFC2467],
and [RFC2470]). When compared to such identifiers, the identifiers and [RFC2470]). When compared to such identifiers, the identifiers
specified in this document have a number of advantages: specified in this document have a number of advantages:
o They prevent trivial host-tracking, since when a host moves from o They prevent trivial host-tracking based on the IPv6 address,
one network to another the network prefix used for since when a host moves from one network to another the network
autoconfiguration and/or the Network ID (e.g., IEEE 802.11 SSID) prefix used for autoconfiguration and/or the Network ID (e.g.,
will typically change, and hence the resulting Interface IEEE 802.11 SSID) will typically change, and hence the resulting
Identifier will also change (see Interface Identifier will also change (see
[I-D.ietf-6man-ipv6-address-generation-privacy]). [I-D.ietf-6man-ipv6-address-generation-privacy]).
o They mitigate address-scanning techniques which leverage o They mitigate address-scanning techniques which leverage
predictable Interface Identifiers (e.g., known Organizationally predictable Interface Identifiers (e.g., known Organizationally
Unique Identifiers) [I-D.ietf-opsec-ipv6-host-scanning]. Unique Identifiers) [I-D.ietf-opsec-ipv6-host-scanning].
o They may result in IPv6 addresses that are independent of the o They may result in IPv6 addresses that are independent of the
underlying hardware (i.e. the resulting IPv6 addresses do not underlying hardware (i.e. the resulting IPv6 addresses do not
change if a network interface card is replaced) if an appropriate change if a network interface card is replaced) if an appropriate
source for Net_Iface (Section 5) is employed. source for Net_Iface (Section 5) is employed.
skipping to change at page 14, line 38 skipping to change at page 14, line 49
use of temporary addresses is not feasible. use of temporary addresses is not feasible.
10. Acknowledgements 10. Acknowledgements
The algorithm specified in this document has been inspired by Steven The algorithm specified in this document has been inspired by Steven
Bellovin's work ([RFC1948]) in the area of TCP sequence numbers. Bellovin's work ([RFC1948]) in the area of TCP sequence numbers.
The author would like to thank (in alphabetical order) Mikael The author would like to thank (in alphabetical order) Mikael
Abrahamsson, Ran Atkinson, Karl Auer, Steven Bellovin, Matthias Abrahamsson, Ran Atkinson, Karl Auer, Steven Bellovin, Matthias
Bethke, Ben Campbell, Brian Carpenter, Tassos Chatzithomaoglou, Tim Bethke, Ben Campbell, Brian Carpenter, Tassos Chatzithomaoglou, Tim
Chown, Alissa Cooper, Dominik Elsbroek, Eric Gray, Brian Haberman, Chown, Alissa Cooper, Dominik Elsbroek, Stephen Farrell, Eric Gray,
Bob Hinden, Christian Huitema, Ray Hunter, Jouni Korhonen, Suresh Brian Haberman, Bob Hinden, Christian Huitema, Ray Hunter, Jouni
Krishnan, Eliot Lear, Jong-Hyouk Lee, Andrew McGregor, Tom Petch, Korhonen, Suresh Krishnan, Eliot Lear, Jong-Hyouk Lee, Andrew
Michael Richardson, Mark Smith, Dave Thaler, Ole Troan, James McGregor, Thomas Narten, Simon Perreault, Tom Petch, Michael
Woodyatt, and He Xuan, for providing valuable comments on earlier Richardson, Vincent Roca, Mark Smith, Hannes Frederic Sowa, Martin
versions of this document. Stiemerling, Dave Thaler, Ole Troan, Lloyd Wood, James Woodyatt, and
He Xuan, for providing valuable comments on earlier versions of this
document.
Hannes Frederic Sowa produced a reference implementation of this
specification for the Linux kernel.
This document is based on the technical report "Security Assessment This document is based on the technical report "Security Assessment
of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] authored by
Fernando Gont on behalf of the UK Centre for the Protection of Fernando Gont on behalf of the UK Centre for the Protection of
National Infrastructure (CPNI). National Infrastructure (CPNI).
The author would like to thank CPNI (http://www.cpni.gov.uk) for
their continued support.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[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.
skipping to change at page 15, line 32 skipping to change at page 15, line 44
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005. 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[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.
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", RFC
5453, February 2009. 5453, February 2009.
[I-D.ietf-6man-ug] [I-D.ietf-6man-ug]
Carpenter, B. and S. Jiang, "Significance of IPv6 Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", draft-ietf-6man-ug-05 (work in Interface Identifiers", draft-ietf-6man-ug-06 (work in
progress), November 2013. progress), December 2013.
11.2. Informative References 11.2. Informative References
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992. April 1992.
[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks", [RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
RFC 1948, May 1996. RFC 1948, May 1996.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
skipping to change at page 16, line 31 skipping to change at page 16, line 50
1998. 1998.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC Stevens, "Basic Socket Interface Extensions for IPv6", RFC
3493, February 2003. 3493, February 2003.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for "Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, May 2003. IPv6", RFC 3542, May 2003.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, November
2010.
[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J. [RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105, Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
February 2011. February 2011.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, March 2011.
[I-D.ietf-opsec-ipv6-host-scanning] [I-D.ietf-opsec-ipv6-host-scanning]
Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Gont, F. and T. Chown, "Network Reconnaissance in IPv6
Networks", draft-ietf-opsec-ipv6-host-scanning-02 (work in Networks", draft-ietf-opsec-ipv6-host-scanning-02 (work in
progress), July 2013. progress), July 2013.
[I-D.ietf-v6ops-ra-guard-implementation] [I-D.ietf-v6ops-ra-guard-implementation]
Gont, F., "Implementation Advice for IPv6 Router Gont, F., "Implementation Advice for IPv6 Router
Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra- Advertisement Guard (RA-Guard)", draft-ietf-v6ops-ra-
guard-implementation-07 (work in progress), November 2012. guard-implementation-07 (work in progress), November 2012.
 End of changes. 30 change blocks. 
74 lines changed or deleted 109 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/