This document specifies a method for generating IPv6 Interface
Identifiers to be used with IPv6 Stateless Address Autoconfiguration
(SLAAC), such that addresses configured using this method are stable
within each subnet, but the Interface Identifier changes when hosts
move from one network to another. The aforementioned method is meant
to be an alternative to generating Interface Identifiers based on
IEEE identifiers, such that the benefits of stable addresses can be
achieved without sacrificing the privacy of users.
[RFC4862] specifies the Stateless Address Autoconfiguration (SLAAC)
for IPv6 [RFC2460], which typically results in hosts configuring one
or more "stable" addresses composed of a network prefix advertised by
a local router, and an Interface Identifier (IID) that typically
embeds a hardware address (e.g., using IEEE identifiers) [RFC4291].
Generally, stable addresses are thought to simplify network
management, since they simplify Access Control Lists (ACLs) and
logging. However, since IEEE identifiers are typically globally
unique, the resulting IPv6 addresses can be leveraged to track and
correlate the activity of a node over time and across multiple
subnets and networks, thus negatively affecting the privacy of users.
The "Privacy Extensions for Stateless Address Autoconfiguration in
IPv6" [RFC4941] were introduced to complicate the task of
eavesdroppers and other information collectors to correlate the
activities of a node, and basically result in temporary (and random)
Interface Identifiers that are typically more difficult to leverage
than those based on IEEE identifiers. When privacy extensions are
enabled, "privacy addresses" are employed for "outgoing
communications", while the traditional IPv6 addresses based on IEEE
identifiers are still used for "server" functions (i.e., receiving
As noted in [RFC4941], "anytime a fixed identifier is used in
multiple contexts, it becomes possible to correlate seemingly
unrelated activity using this identifier". Therefore, since
"privacy addresses" [RFC4941] do not eliminate the use of fixed
identifiers for server-like functions, they only *partially*
mitigate the correlation of host activities (see Appendix A for
some example attacks that are still possible with privacy
addresses). Therefore, it is vital that the privacy
characteristics of "stable" addresses are improved such that the
ability of an attacker correlating host activities across networks
Another important aspect not mitigated by "Privacy Addresses"
[RFC4941] is that of host scanning. Since IPv6 addresses that
embed IEEE identifiers have specific patterns, an attacker could
leverage such patterns to greatly reduce the search space for
"live" hosts. Since "privacy addresses" do not eliminate the use
of IPv6 addresses that embed IEEE identifiers, host scanning
attacks are still feasible even if "privacy extensions" are
employed [Gont-DEEPSEC2011] [CPNI-IPv6]. This is yet another
motivation to improve the privacy characteristics of "stable"
addresses (currently embedding IEEE identifiers).
Privacy/temporary addresses can be challenging in a number of areas.
For example, from a network-management point of view, they tend to
increase the complexity of event logging, trouble-shooting, and
enforcing access controls and quality of service, etc. As a result,
some organizations disable the use of privacy addresses even at the
expense of reduced privacy [Broersma]. Also, they result in
increased complexity, which might not be possible or desirable in
some implementations (e.g., some embedded devices).
In scenarios in which "Privacy Extensions" are deliberately not used
(possibly for any of the aforementioned reasons), all a host is left
with is the addresses that have been generated using e.g. IEEE
identifiers, and this is yet another case in which it is also vital
that the privacy characteristics of these stable addresses are
We note that in most (if not all) of those scenarios in which
"Privacy Extensions" are disabled, there is usually no actual desire
to negatively affect user privacy, but rather a desire to simplify
operation of the network (simplify the use of ACLs, logging, etc.).
This document specifies a method to generate interface identifiers
that are stable/constant within each subnet, but that change as hosts
move from one network to another, thus keeping the "stability"
properties of the interface identifiers specified in [RFC4291], while
still mitigating host-scanning attacks and preventing correlation of
the activities of a node as it moves from one network to another.
This document does not update or modify IPv6 StateLess Address Auto-
Configuration (SLAAC) [RFC4862] itself, but rather only specifies an
alternative algorithm to generate Interface IDs. Therefore, the
usual address lifetime properties (as specified in the corresponding
Prefix Information Options) apply when IPv6 addresses are generated
as a result of employing the algorithm specified in this document
with SLAAC [RFC4862]. Additionally, from the point of view of
renumbering, we note that these addresses behave like the traditional
IPv6 addresses (that embed a hardware address) resulting from SLAAC
For nodes that currently disable "Privacy extensions" [RFC4941] for
some of the reasons stated above, this mechanism provides stable
privacy-enhanced addresses which may already address most of the
privacy concerns related to addresses that embed IEEE identifiers
[RFC4291]. On the other hand, in scenarios in which "Privacy
Extensions" are employed, implementation of the mechanism described
in this document would mitigate host-scanning attacks and also
mitigate correlation of host activities.