IPv6 update: A look at the security and privacy improvements

Background on IPv6

The traditional algorithm to generate stable IPv6 addresses with stateless address auto configuration (SLAAC) was designed to generate them by employing the underlying link layer address as the Interface Identifier of the address.

Over time, awareness has been raised about performing host tracking by means of IPv6 addresses. Since the MAC addresses are typically globally unique, and they were embedded in the IPv6 addresses, host identity was leaked by IPv6 addresses. In response to these concerns, the IETF published a standard for temporary addresses that were meant to be employed along with the traditional (stable) IPv6 addresses. While temporary addresses have helped mitigate one specific vector for host tracking, other vectors for IPv6 host tracking, as well as the vulnerability of the traditional scheme to trivial address scans, remained unaddressed.

Ongoing work on the security and privacy properties of IPv6 addresses eventually led to the publication of a proposal to replace the traditional algorithm to generate stable IPv6 addresses with SLAAC with one with improved properties. However, the IPv6 update proposal got push-back at the relevant IETF Working Group, known as 6man. Thus, the 6man working group decided to publish the proposed algorithm as RFC 7217, without formally replacing the traditional SLAAC algorithm. This means that no IETF standards were formally updated.

While the publication of RFC 7217 was a step forward as an IPv6 update, its implementation and use was not recommended or mandated by any standard, and therefore the traditional SLAAC algorithm was still the recommended approach for generating stable IPv6 addresses.

Publication of two informational RFCs on the security and privacy implications of IPv6 addresses, namely RFC 7707 and RFC 7721, probably prepared the grounds for the IETF to take the final step and replace the traditional SLAAC algorithm with the one specified in RFC 7217.

This was finally achieved in February 2017 with the publication of RFC 8064, which recommends the implementation and use of RFC 7217 for the generation of stable addresses, and also recommends against using any address generation schemes that embed link-layer addresses in IPv6 addresses.

Semantically opaque interface identifiers

The RFC 7217 IPv6 update specifies an algorithm that can produce IPv6 Interface Identifiers (and, thus, IPv6 addresses) that are stable within the same network, but that vary as a node moves from one network to another. The algorithm can be summarized and simplified with the following expression:

IPv6_IID = Hash(Net_Prefix, Net_ID, Net_Iface_ID, Secret_Key)

where:

• Hash(): A cryptographically secure hash function.
• Net_Prefix: IPv6 Prefix being advertised by local routers.
• Net_ID: An optional network identifier, such as the service set identifier of a Wi-Fi network.
• Net_Iface_ID: An identifier for the underlying network interface (e.g., the network interface name).
• Secret_Key: A secret value, typically initialized during system installation as a random value, and constant across reboots.

Essentially, the IPv6 Interface Identifier is obtained by computing a secure hash over the concatenation of a number of parameters, most notably the network prefix advertised by local routers (Net_Prefix) and a secret key (Secret_Key).

As long as the node remains in the same network, it will maintain and configure the same IPv6 addresses, since all of the parameters employed for the hash function remain constant. On the other hand, as soon as the node connects to a different network, the IPv6 Interface Identifier will change, since the network prefix will change. If the node moves back to a network to which it previously connected, it will configure the same IPv6 address as before, as all of the parameters originally employed to compute the IPv6 Interface Identifier will be the same as in the original case.

Implementing the IPv6 update

At the time of this writing, at least the following implementations of RFC 7217 are known to exist:

• Linux kernel v4.0;
• NetworkManager v1.2.0-0.3.20151112gitec4d653.fc24;
• dhcpcd 6.4.0; and
• macOS Sierra.

The Linux kernel implementation was the first implementation of RFC 7217, and thus, also served as a reference implementation. However, some of the most popular Linux distributions, such as Ubuntu and Fedora, employ the NetworkManager application package for network configuration rather than relying on the kernel. NetworkManager has implemented RFC 7217 since version 1.2.0-0.3.20151112gitec4d653.fc24. Thus, as new versions of popular Linux distributions are released, all major distributions should be supporting the new algorithm specified in RFC 7217. Some popular Linux distributions, such as Fedora, already ship with the new algorithm enabled by default.

The dhcpcd package is employed in a number of Linux distributions, such as Raspbian, for network configuration. Dhcpcd has implemented support for RFC 7217 since version 6.4.0. Current releases of Raspbian already ship with the algorithm specified by RFC 7217 enabled by default.

Finally, another popular operating system that has incorporated the RFC 7217 IPv6 update support is macOS Sierra, which ships with this new algorithm enabled by default.

The latest releases of some of the most popular operating systems already support RFC 7217. Android is expected to support RFC 7217, as most recent versions of the Linux kernel are supported.

On the other hand, at the time of this writing, Microsoft Windows does not support RFC 7217. However, based on a number of other security and privacy improvements incorporated into Windows (such as MAC address randomization), as well as the fact that one of the co-authors of RFC 8064 is affiliated with Microsoft, one should probably expect Microsoft to implement support for RFC 7217 at some point in the future.