Privacy aspects of IPv6

We recommend using Privacy Extensions for SLAAC

Futuristic background with padlock on digital integrated circuit

With IPv6, scanning the online address space for active systems is much harder than with IPv4. That's simply down to the length of the addresses: while the 32-bit IPv4 system supports a maximum of four billion addresses – a scannable number – the 128-bit IPv6 system supports 340 sextillion (34 followed by 37 zeros).

Although scanning the whole of the vast IPv6 address space is practically impossible, clever ways of mapping active systems have been devised, making it possible to identify and track end users at the address level. Indeed, in the context of such activities, the huge address space has the advantage that the identification of individual systems is facilitated by the use of unique labels. That has significant security and privacy implications for IPv6 network operators and users.

Although there are many ways of monitoring end users online – including fingerprinting and cookies of various types – IPv6's automatic address assignment (SLAAC) makes the task much easier unless countermeasures are taken. With IPv6, the last 64 bits of an address, the 'network interface identifier', are normally generated automatically for the end user by the user's computer. That's traditionally been done on the basis of the 'Modified EUI-64' format, derived from the more-or-less unique MAC address. Because that portion of the address therefore stays the same – even if the user's computer connects to a completely different network with a different prefix – the user can in principle be tracked online wherever they go in the world. That situation is clearly undesirable from a privacy viewpoint.

Privacy Extensions for SLAAC

The solution to that problem is to use the Privacy Extensions for SLAAC defined in RFC 8981. Then, for example, a random new address is generated on a daily basis. Each previous day's address can be kept active for a further day for any traffic that may still arrive, implying that an interface can be making use of multiple concurrent IPv6 addresses (interface identifiers) with the same network prefix.

An alternative approach is put forward in RFC 7217, involving the generation and maintenance of a random interface identifier for each interface and subnet. So the IPv6 addresses remain constant for each network (prefix), but they can't be identified as belonging to the same device. RFC 8064 now advises against using hardware-dependent SLAAC addresses, in favour of using IPv6 addresses generated in accordance with RFC 7217 instead.

The security and privacy considerations associated with address assignment are considered in detail in RFC 7721.

IPv4 address sharing

Broadly speaking, the 56/48-bit prefixes assigned to home users work in a similar way to native IPv4 addresses or IPv4 addresses in single-NAT systems: they identify a unique user (or household) at a given moment. On a business network, a 64-bit prefix identifies the network segment to which, for example, several dozen systems (interface identifiers) are connected.

However, there is no such similarity between IPv6 and IPv4 with CGNAT. In a CGNAT system, thousands of end users in different households may share a single IPv4 address.

Fighting crime

IPv4 with CGNAT creates problems, not only for all IP address-based security mechanisms (e.g. blacklisting/whitelisting and reputation management), but also for law enforcement agencies. Back in 2017, for example, Europol reported that access providers using CGNAT were often no longer able to meet their legal obligation to provide details of the account holder linked to a given connection. As a result, the agency said, it was common for investigations to involve examining and tapping the connections of many more people than really necessary.

At about the same time, the European Commission published a letter describing how the EU planned to promote the adoption of IPv6. The ultimate aim being to have one user per IP address, thus facilitating the accurate targeting of investigative activities by the police and security services. The Commission plans to pursue that aim through procurement policy, research and project funding, and covenants.

Telecommunications Data Retention Act

In 2019, the Dutch Ministry of Justice and Security's Research and Documentation Centre (WODC) published the findings of research into the identification of individual IP address users for the purposes of criminal investigation and prosecution (as provided for in the Telecommunications Data Retention Act). Again, the general adoption of IPv6 was recommended as the most obvious solution.

Although end users sometimes voice privacy-based objections to the use of IPv6 – on the grounds that CGNAT unintentionally provides a degree of anonymity not dissimilar to the use of a VPN provider – the authors of the WODC report argue that IPv6 actually enhances privacy. The rationale being that criminal investigations can be targeted better, without large numbers of innocent users falling within their scope. Moreover, aside from the technical and commercial considerations, it is much easier for access providers to fulfil their compliance responsibilities with IPv6 than with IPv4 plus CGNAT.

Public network service providers

Naturally, the big public DNS service providers such as Google (Public DNS), Quad9 and Cloudflare (1.1.1.1) have a better picture of the IPv6 address space than anyone else. They are able to see both clients (the IP addresses of end users and local resolvers) and servers (queried domain names) in the tens or even hundreds of billions of queries they handle every day. While the size of the IPv6 address space makes an exhaustive inventory impossible, such companies are in a position to map the active region of that space, including users and service providers.

Privacy and security-conscious users and operators therefore need to think carefully about how and where they obtain DNS services. We believe that the internet in general and the DNS system in particular benefit from topological decentralisation. In relation to DNSSEC, that implies that the closer to the end user a validating resolver is, the better from a security viewpoint [1, 2]. We therefore advise all end users that can run validating resolvers on their own systems to do so. It is similarly possible to harvest IPv6 addresses – for benign or malicious purposes – by joining the NTP Pool, which is in principle open to all.

Needless to say, although our own public NTP server (time.nl) is part of the pool, we don't collect users' addresses. If (in network terms) you're close to SIDN's home city of Arnhem, you are warmly invited to use our NTP and NTS server (nts.time.nl) [1, 2] (in combination with a few other NTP servers). Advice on configuring your computer to use our NTP service can be found on the TimeNL website.

Do you have Privacy Extensions enabled?

Like the configuration of DNS and NTP, the configuration of Privacy Extensions for SLAAC is very straight forward. It is really just a question of enabling support. Whether you are an end user or an operator, we recommend checking to see whether you have the Privacy Extensions enabled. After all, the old method of generating MAC-based IPv6 addresses is now really outdated, and the extensions are widely supported.

The importance of checking was recently underlined by research showing that some access providers' CPE equipment (modems) is still using the old 'Modified EUI-64' format for generating IPv6 addresses. That completely negates the protection that should be afforded by provider prefix rotation (where home users are continually given new prefixes).

You can check whether your system is using Privacy Extensions for SLAAC by doing the connection test on Internet.nl, or on either ip.bieringer.net or ipv6-test.com.