Home / Blogs

IPv6 Security Myth #5: Privacy Addresses Fix Everything!

Internet Protocol addresses fill two unique roles. They are both identifiers and locators. They both tell us which interface is which (identity) and tell us how to find that interface (location), through routing. In the last myth, about network scanning, we focused mainly on threats to IPv6 addresses as locators. That is, how to locate IPv6 nodes for exploitation. Today’s myth also deals with IPv6 addresses as identifiers.

As we learned in the last myth:

Traditionally SLAAC uses modified EUI-64 format interface identifiers, which basically takes the interface’s MAC address and stuffs the hexadecimal word “0xfffe” in between the OUI (Organizationally Unique Identifier) and the second half of the MAC address, plus setting the “Universal” bit to 1. For example, the MAC address 00.00.5E.00.53.01 would become the IID (Interface Identifier) 0200:5EFF:FE00:5301.

This mapping of IEEE link-layer (MAC) addresses into IPv6 addresses has significant privacy implications when you consider the identification role of those addresses. When my interface identifier (the second 64 bits of my IPv6 address) is built deterministically from my MAC address, it doesn’t change (unless I change my network interface hardware, another issue that can be problematic for network administrators). An unchanging interface identifier can be used to track my device and it’s Internet activity. Even as it moves from network to network the prefix changes but the IID does not and my identity is revealed.

In response to this privacy threat, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6” were developed and are now published in RFC 4941. Ultimately the idea documented here is to generate “privacy addresses” (also known as “temporary addresses”) that change over time. Unpredictable and short-lived, these addresses are meant to combat the threat of your devices being identified and tracked as you use the Internet.

Myth: Privacy Addresses Fix Everything!
Reality: It’s Complicated

The first thing to note about privacy addresses is that they are created in addition to, not in place of, your “regular” SLAAC address. This means that for the purposes of scanning and locating hosts, privacy addresses are of little help.

Another issue that should be considered with regard to privacy addresses is their short-lived nature and its affect on troubleshooting and forensics. It is very hard for network administrators to manage a network full of devices constantly changing their source addresses. Setting up filters, looking back at logs, and many other regular tasks become much more difficult when you can’t predict what address a node will be using, nor guess which address it was using.

The obvious solution to both of these challenges is to use a single, stable address that is not based on the interface’s MAC address. Replacing the EUI-64 based SLAAC address with a randomized one does reduce the ability for an attacker to target OUI patterns or other heuristics. Making the address stable (across reboots and network moves) makes filtering, troubleshooting, and forensics much more possible than with truly temporary addresses. Unfortunately, an unchanging address does not address the privacy concerns that prompted the creation of privacy addresses in the first place—unchanging IIDs can be used to identify and track a given device.

A more recent solution to this is being called “Semantically Opaque Interface Identifiers” and a method for generating them is documented in RFC 7217:

This document specifies a method to generate Interface Identifiers that are stable for each network interface within each subnet, but that change as a host moves from one network to another. Thus, this method enables keeping the “stability” properties of the Interface Identifiers specified in [RFC4291], while still mitigating address-scanning attacks and preventing correlation of the activities of a host as it moves from one network to another.

Not bad! I do note that on-network correlation is still possible, since the addresses only change when moving from one network to another. But that is of course what makes the address easier to manage from a network administrator point of view. It should also be noted that a device could use privacy addresses for outbound communication and opaque addresses for inbound communication, possibly frustrating network admins but improving privacy.

The alternative to all of this would be to use properly configured DHCPv6 instead of SLAAC on your networks. Just be sure to take into account all the risks of scanning mentioned in the last myth, and consider using privacy/temporary addresses with your DHCP implementation for user privacy.

Still confused? This is a tricky topic that is currently in flux a bit. If you want more information or have some clarifying questions, please don’t hesitate to look at our IPv6 security resources or to contact us directly!

Final note: I want to also point out that I intentionally left Cryptographically Generated Addresses (CGA) out of this conversation. I made this choice to simplify the topic in light of the extremely low adoption rate of SEND (Secure Neighbor Discovery) at this time.

By Chris Grundemann, Creative|Technologist

Filed Under


One possible solution is to use a Todd Knarr  –  Feb 17, 2015 10:39 AM

One possible solution is to use a smaller fixed chunk of the host address to identify the host, and randomize the remainder. For instance on a small home network I may only need 4 bits to identify a particular computer. That leaves me 59 bits to play with. If an eavesdropper doesn’t know exactly how many fixed bits I’m using, where they’re located in the address and especially if they’re non-contiguous, it should be just about impossible for them to map 64-bit host addresses to unique hosts. At the same time log-decoding software for the administrator knows exactly how many bits were used and where they are, and since a program can reassemble 4 bits located at positions 17, 4, 51, 25 just as easily as at 3, 2, 1, 0 the scrambling only adds a fraction of a second of overhead converting addresses to unique host numbers before displaying them. Dynamic host-number assignment adds some complexity, but not insurmountable and if the dynamic host pool is the same size as the one for static host numbers it just requires 1 extra bit to identify whether the host number is static or DHCP-assigned dynamic.

To block external scanning you can use a regular firewall configured to deny all inbound traffic not associated with an outbound connection plus something like UPnP to open inbound ports as needed. I wouldn’t use UPnP itself, but set up a new protocol that combined a request from the host to open a particular port inbound from a range of source addresses (routing those connections to the requesting host) with configuration in the firewall of what ports and address ranges each host could request to be opened. That’d mean that software vendors would have to disclose their software’s communications requirements, but in an enterprise environment that’s a good thing (and the software’s more likely to need outbound permissions for license servers and the like than inbound) and for home routers it could be set up as a block of XML or JSON in a text file the user could paste into a textbox in the router’s config screens that the router could decode into the exact set of rules for the software and then all the user has to do is check boxes for each host saying what pieces of software it’s supposed to be running. Home users may not be able to be completely oblivious about firewalls with this, but it’s not that hard. I’d be comfortable walking my mother through adding the configuration over the phone, and she’s 73 and a complete technophobe.

Not a bad set of ideas Chris Grundemann  –  Feb 17, 2015 3:02 PM

I can't say I strongly disagree with any of what you said Todd. Sounds like a solution worth exploring. Have you considered contributing to the IETF Homenet working group? They are looking at just these type of issues for home routers/networks: https://tools.ietf.org/wg/homenet/

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet




Sponsored byVerisign


Sponsored byDNIB.com

Domain Names

Sponsored byVerisign

Brand Protection

Sponsored byCSC

IPv4 Markets

Sponsored byIPv4.Global

New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API