Internet Service Providers (ISPs) globally are increasingly deploying IPv6 in their networks. One driver for this deployment is the ever-increasing number of IoT devices installed in the home.
Unfortunately, even a single poorly configured device using legacy IPv6 addressing schemes can break the privacy mechanisms offered by IPv6 and employed by many ISPs. These misconfigurations can enable third parties such as Content Delivery Networks (CDNs) or large service providers to track the prefix of an ISP customer longitudinally.
In a recent study, my colleagues and I at the Max Planck Institute for Informatics and TU Delft found that up to 19% of subscribers of a large European ISP might be at risk of reduced IPv6 privacy.
The following post shares some further insights which we hope will raise awareness among IoT manufacturers, policymakers, users, and network operators.
Legacy IPv6 addressing
With legacy EUI-64 IPv6 addressing, a device generates its IPv6 address by sequencing a transformation of its MAC address with the prefix, which is normally provided by the home router. The static and consistent nature of MAC addresses makes EUI-64 harmful to privacy since it allows tracking of devices through their MAC address. Therefore, RFC 4941 introduced IPv6 privacy extensions as a privacy-friendly technique for IPv6 address generation. With IPv6 privacy extensions, instead of a MAC address, the device uses a random value to generate its IPv6 address.
In addition to tracking by MAC address, it is also possible to track ISP customers through their IPv6 prefixes. So, to protect their customer’s privacy, many ISPs employ prefix rotation such that the customer’s prefix changes every so often, for example, every 24 hours.
Tracking a subscriber
With ISPs using prefix delegation, a subscriber’s customer-premises equipment (CPE) obtains a larger prefix, typically a /56, from the ISP. Next, the CPE chooses a smaller prefix, for example, a /64 prefix, to be used by the devices at home.
The home devices can obtain their IPv6 addresses either using DHCPv6 or SLAAC. In SLAAC, the CPE or router announces the prefix, and each client generates its IPv6 address using either EUI-64 or IPv6 privacy extensions. If the ISP operates prefix rotation, this process repeats every time the ISP delegates a new /56 prefix to the CPE. This results in devices renewing their IPv6 address every time the prefix is rotated.
Figure 1 shows how a single device using EUI-64 can be used as a tracking anchor to track the customer’s prefix across multiple prefix rotations, even if all other devices use IPv6 privacy extensions and the ISP employs prefix rotation.
In this figure, the CPE obtains a /56 prefix from ISP and chooses a /64 to announce in the end-user prefix. The CPE may or may not get a separate /56 prefix for its public-facing interface (periphery prefix). The laptop uses privacy extensions, and the smart TV uses EUI-64 to generate its IPv6 addresses. The laptop and smart TV both contact the same CDN.
Since the smart TV uses the legacy EUI-64 standard, its interface ID (the rightmost part of an IPv6 address, highlighted in red) will stay the same across prefix rotations at time 1 and time 2. Therefore, a CDN or any other popular application can use the interface ID of the smart TV’s address as a tracking ID to track both the TV and laptop across prefixes. Even one EUI-64 device is enough for the CDN to track the laptop, even if it uses privacy extensions and the ISP employs prefix rotation.
How prevalent is EUI-64?
We analyzed one day of NetFlow data from a large European ISP with 15M subscribers to find out to what extent the subscribers are exposed to this privacy leakage. This ISP delegates /56 prefixes to its subscribers and the periphery interfaces of CPEs and end-user networks are in separate /56 prefixes. Therefore, a /56 prefix represents an end-user network of a subscriber.
As shown in Figure 2, we found 16.9M IPv6 addresses with EUI-64 in our dataset (left subplot). By extracting the unique MAC addresses, we found 14.4M devices using EUI-64 addressing.
In addition, Figure 2 shows that roughly 2.7M /56 prefixes have at least one device with an EUI-64 IPv6 address (right subplot). Remarkably, this amounts to 19% of all 11.3M observed /56 prefixes.
Who is the culprit of privacy leakage?
We can easily reverse the EUI-64 process and extract the MAC address from an EUI-64 IPv6 address and use the MAC address to gain more information about the type of the device. The first 24 bits-long part of a MAC address is the Organizational Unique Identifier (OUI). We can look up these OUIs in the IEEE database to gain some information about the device’s manufacturer. The IEEE database of OUIs contains the name and address of the manufacturer.
We extracted 1,217 unique OUIs from 14.4M devices identified as using EUI-64 addressing. We then visited the websites of the top 100 manufacturers and manually categorized their product portfolios into one or multiple categories.
Figure 3 shows the popularity of each category in terms of the percentage of subscribers. To our surprise, IoT device manufacturers, by far, amount to the largest category: More than 80% of subscribers host devices from manufacturers that produce IoT devices. In addition, roughly 40% of subscribers host devices from manufacturers that only produce IoT devices. Further investigation of the IoT device category showed that devices from a few manufacturers were responsible for the majority of EUI-64 usage.
How serious is the danger of tracking?
Next, we wanted to identify which CDNs and other large providers can track the subscribers using this technique — remembering that for privacy leakage, at least one EUI-64 and a non-EUI-64 device have to contact the same CDN.
Figure 4 shows the number of subscribers whose privacy can be leaked to each CDN. We found that more than 2M subscriber lines are affected by privacy leaks at CDNs.
How can we fix this?
Vendors can self-regulate by making every effort to protect the users’ privacy. We are in the process of contacting IoT manufacturers that still employ EUI-64.
ISPs can continuously monitor for such privacy violations and inform users about the risks. In addition, they should check the configuration of CPE devices as a whole for these risks before shipping them to subscribers.
To learn more about our work, read our paper in ACM SIGCOMM Computer Communication Review in April 2022: “One Bad Apple Can Spoil Your IPv6 Privacy”.
Said Jawad Saidi is a Research Assistant at the Max Planck Institute for Informatics.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.