IPv6 adoption is ongoing; according to Google's statistics, between 17.5% and 21.4% of their web traffic is served over IPv6, though IPv6 usage varies significantly among different countries.

The principle driver for this new Internet Protocol version is its predecessor's shortage of addresses. In IPv6, addresses have been increased to a total length of 128 bit usually considered in two 64-bit halves: the first 64 bits are the network prefix, dependent on a host's location in the network, and the latter 64 bits are the interface identifier (IID) that enables a subscriber's identification on the local link.

IPv6 has led to new aspects in addressing, also with regard to security and privacy. This article discusses the impact of IPv6 addressing on security and privacy, how diverse address formats deal with these matters, and outlines shortcomings in today's addressing mechanisms.

More bits for addressing are a curse and a saviour at the same time: on the one hand, more address space provides more flexible addressing, but could also lead to information leakage. The IPv6 address format chosen by a host or a network operator has significant impact on how well a node is protected against malicious actions by adversaries.

Here, we'll elaborate on existing formats, highlighting their advantages and disadvantages with respect to security and privacy. Note that here we'll discuss the interface identifier - the lower 64 bits - and not issues related to address planning and/or assignment of prefixes to hosts. For information on IPv6 address planning see this recent post on Labs.

The Modified EUI-64 Format

Figure 1: IPv6 Addresses containing the Network Prefix and the Interface Identifier. The Modified EUI-64 Format is inferred from the MAC address by inserting a fixed pattern of two bytes.

 
The Modified EUI-64 format represents the oldest of such formats. A host forms the IID for an interface from the interface's MAC address, essentially by inserting a fixed pattern of two bytes as shown in Figure 1.

Including a globally unique identifier like the MAC address in the IIDs has multiple consequences on security and privacy of a node:

• All addresses used by a node in any network it connects to will have the same IID in the bottom 64 bits, and thus enable address correlation by solely comparing the IIDs. This way, an adversary is able to attribute Internet transactions from multiple vantage points to a single node, and gain an in-depth understanding of the latter's Internet behaviour. Further, analysing the collected network prefixes enables the adversary to trace a host's movement in the network, and is of particular interest for mobile hosts like smart phones or tablets.

• MAC addresses contain the Organisationally Unique Identifier (OUI) identifying the device manufacturer. On the one hand, this means that a sniffed address allows to gain details on the respective device type (for example, to tailor a successive tailored attack). On the other hand, the pattern allows an attacker to reduce the search space for scanning: Two bytes are fixed and thus reduce the address space; an adversary is able to further reduce the search space when looking for distinct types of devices. Notably, if you know a network's chosen vendor, and you know fixed pattern of FF:FE, you only have 24 bits left to scan.

These shortcomings have been known for a long time, and the Modified EUI-64 format's deprecation has already been discussed. Nevertheless, it is still used in numerous devices, particular mobile systems and Internet-of-Things (IoT) devices.

Statically Assigned Addresses

Statically assigned addresses that are chosen by the operators remain unchanged for longer periods of time and are typically assigned to routers and servers. Apart from the global uniqueness, the same as for addresses in Modified EUI-64 format holds for these type of addresses. An adversary might detect patterns revealing internals or reduce the search space when knowing the applied patterns.

In summary, the level of privacy and security protection depends on whether the addresses contain patterns and the adversary's capability to guess these patterns. While patterns might negatively impact security on the one hand, they ease management and maintenance for system operators on the other hand and a balance has to be found.

IPv6 Privacy Extension

The IPv6 Privacy Extension is defined in RFC 4941. It is a format defining temporary addresses that change in regular time intervals; successive addresses appear unrelated to each other for outsiders and are a means of protection against address correlation. Their regular change is independent from the network prefix; this way, they protect against tracking of movement as well as against temporal correlation.

RFC 4941 specifies however a vulnerable algorithm for the Privacy Extension's interface identifier generation. Adversaries are able to gain the algorithm's internal state via a side channel, and predict all future addresses of a host afterwards contradicting the intended privacy protection. The algorithm has not been officially revised yet; nevertheless operating systems implementing the IPv6 Privacy Extension appear to use random numbers instead and thus provide a sufficient level of protection. Initially, the temporary addresses of the Privacy Extension have been intended to be assigned in addition to some sort of static addresses; nowadays, they are also assigned in absence of static addresses. The latter fact significantly improves protection against active scanning: the adversary now has to find the (random or pseudo-random) temporary address instead of the static one which is a more tedious task.

Semantically Opaque Interface Identifiers

Semantically Opaque Interface Identifiers are defined in RFC 7217. The rationale behind this mechanism is to gain stable interface identifiers per prefix in order to reduce the administrative burden, e.g., in enterprise networks, while maintaining a certain level of privacy protection when being in another network. These IIDs are generated by hashing the network prefix, a secret key and various other parameters. This way, the interface identifier changes when moving to another network prefix; however, it snaps back to the same value when returning to the original network.

Semantically Opaque Identifiers prevent address correlation, and in particular tracking of movement as long as the secret key is unknown to the adversary. But they do not protect against temporal correlation, i.e., an adversary is able to attribute transactions at different points in time to a single (stationary) host. In order to protect against such threats, dynamic address schemes like the IPv6 Privacy Extension are needed. From the point of network scanning, Semantically Opaque Interface Identifiers are intended to appear randomly from an outside perspective and their discovery should thus remain a tedious tasks; nevertheless, its quality is dependent on the particular implementation that is not explicitly defined in RFC 7217 and practical implementation has just started. Currently, RFC 8064 recommends Semantically Opaque Interface Identifiers as default stable identifiers instead of the Modified EUI-64 format, increasing privacy protection as well as protection against scanning and operating systems, e.g., Mac OS X, have started its deployment.

Cryptographically Generated Addresses

Cryptographically Generated Addresses are defined in RFC 3972. They are generated by hashing a host's public key with other parameters, and are thus bound to the respective host.

Their ownership is verified by signing messages originated from this address with the respective private key. In combination this prevents address spoofing and has been intended to protect against attacks originating on the local network. From the point of privacy protection, these addresses are comparable to Semantically Opaque Interface Identifiers: as the network prefix is included into the hash, the address is changed when moving to another network. In addition to that, a new address could also be generated without a movement; this would allow protection against temporal correlation comparable to the IPv6 Privacy Extension. However, the generation of Cryptographically Generated Addresses is costly and in consequence hinders frequent address changes in practice. With respect to scanning, this type of addresses appears random from an adversary's perspective providing effective protection.

The biggest challenges in this context is its lacking acceptance and deployment: Cryptographically Generated Addresses and Secure Neighbour Discovery (SeND) are not supported by any of the major operating systems.

Discussion

The presented address formats can be classified into static, semi-static and dynamic: static addresses remain in use over a long time period like those in the Modified EUI-64 format and statically assigned addresses. For semi-static addresses, the specification calls for changes under certain circumstances, the latter occurs however rarely in practice. Semantically Opaque Interface Identifiers and Cryptographically Generated Addresses show such semi-static behaviour. Finally, dynamic addresses change in a regular manner, e.g., every day. At the moment this group of address formats only encompasses the IPv6 Privacy Extension. Semi-static and dynamic address formats are intended for clients while servers tend to exclusively use static address as servers are typically intended to be found by other hosts on the Internet.

However, future Internet-facing devices cannot be strictly classified into the two roles of server and client anymore: there are servers, e.g., gateways of IoT devices, that serve only a very limited group of users, e.g., the residents of a household, and also need some form of privacy protection. For example, server addresses could become temporary as well and be inferred from a shared secret. A legitimate client is able to calculate the current address due to having the secret while an adversary would have to exhaustively scan the network in order to find the server. Further, also peer-to-peer protocols like Bitcoin could exploit similar mechanisms to rediscover their peers.

Internet-facing devices have to assign an address. It would be wise to define them in the most secure and privacy-aware way in order to provide as much protection as possible. This aspect is of special interest for constrained devices like in the Internet-of-Things as they typically do not have much computational power for sophisticated protection measures. The flexibility of IPv6 addressing is therefore a great opportunity that should be seized.

Further Literature

For more information on IPv6 addressing and IPv6 in general, I recommend the following references:

• A. Cooper et al., Security and Privacy Considerations for IPv6 Address Generation Mechanisms, RFC 7721, 2016.
• A. Judmayer et al., Lightweight Address Hopping for Defending the IPv6 IoT, International Conference on Availability, Reliability and Security (ARES), 2017.
• J. Ullrich et al., IPv6 Security: Attacks and Countermeasures in a Nutshell, USENIX Workshop on Offensive Technologies (WOOT), 2014.
• J. Ullrich, E. Weippl, Privacy is Not an Option: Attacking the IPv6 Privacy Extension, International Symposium on Research in Attacks, Intrusions and Defenses (RAID), 2015.
• RIPE NCC IPv6 Security Training Course