No need to sacrifice a great protocol due to some privacy issues, better improve it!

IPv6 hosts can use IPv6 Stateless Address Autoconfiguration (SLAAC) to label themselves with one or more IPv6 addresses. These are composed of a network prefix advertised by a local router, and some kind of interface identifier. There are many security and privacy implications if such an identifier is globally unique — addresses with embedded hardware address being a perfect example. On the other hand these kind of addresses are stable, allowing for a higher degree of network control and manageability.
Users privacy can be significantly improved if the interface identifier is random and changes frequently. Such mechanisms, like Privacy Extensions for SLAAC (RFC 4941), can bring a nightmare to many network administrators.

DHCPv6 to the rescue!

With DHCPv6 we can assure that global IPv6 addresses which are assigned to local hosts are not globally trackable down to the end-user, but we still have full ability for auditing the address usage in our local networks. But DHCPv6 comes with a price: an additional and redundant server must be installed and administered putting more complexity in the network. More, SLAAC and other means of address configuration must be somehow disabled and local hosts must be prevented to use other address rather than the ones from DHCPv6.

Do we really need to sacrifice SLAAC to improve on privacy? To SLAAC or not to SLAAC, that is the question. Well, I would vote for SLAAC if we find a way for stable and private addressing by SLAAC, such that addresses configured are stable within each subnet, but the interface identifier and the corresponding address changes when host moves from one network to another.


IPv6 address types in the “privacy-stability-manageability” cube.

I’ve positioned our choices in the “privacy-stability-manageability” cube. Hardware-based SLAAC addresses are stable but predictable, temporary SLAAC addresses are private but non-stable and DHCPv6 addresses come with the additional complexity. What we are looking for is the stable-privacy SLAAC address type which is random, stable and built-in the protocol itself, therefore elementary.

Here is one of the most promising proposals — a Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration. Hope it will make a RFC very soon :-), which will give us an opportunity to deprecate hardware-based IPv6 addresses and basicaly no need for privacy extensions in SLAAC.

Briefly, the proposed method derives the interface identifier from a prefix, network interface, an optional network identifier (SSID, for example), duplicate-address-detection (DAD) attempt counter and a secret key. A pseudo-random function F, like some kind of cryptographic hash of the concatenation of each of these parameters, is used to compute the random (but stable) interface identifier (RID) for SLAAC:

RID = F(Prefix, Net_Iface, Network_ID, DAD_Counter, secret_key)

The identifier built that way changes when host moves to another network, but remains stable within the network. Voilà!