IPv6 privacy addressing

With IPv4, a machine would have its own IP address on a subnet, and that would be it. Yes, it is true that each interface a device had would be on a separate subnet and so a separate address. It is also true that a device might have several distinct subnets even on the same interface. But these were exceptions to the normal simple subnet configuration.

IPv6 has slight different ways of working. It is normal for an interface to have multiple IPv6 addresses, and there are different scopes of address. For example, each interface has an link local address (starting FE80:) which the device creates for itself (typically based on MAC address) and does not need to be allocated by some system. It is useful, in principle, that a device always has some unique address with which to communicate on the interface itself, though it does cause some confusion.

An interface will also have one or more permanent addresses, either hard coded or allocated by some automated means (SLAAC/DHCPv6). This is also often based on the MAC address and the prefix that applies to the interface.

However, there is also the notion that an interface has one or more temporary addresses. This can, in theory, be allocated by DHCPv6, or more likely made up randomly by the device (checking it is not a duplicate). This is an address in the prefix for the interface, but not one based on the device MAC. These are usually called privacy addresses as their purpose is to avoid exposing details of your network to the world. Using only fixed permanent addresses it becomes obvious to the outside world how many machines you have, and allows traffic to those addresses later (if you did not have a firewall!). It allows the same machine seen twice to be recognised as the same machine, just like cookies and many other systems do already and continue to do with IPv6. With IPv4 the use of NAT would hide the internet network from the world, a bit. We don't want NAT for IPv6.

If someone is using a computer from home like they used to with IPv4 and NAT, then giving the same features they had before, no matter how pointless, is not that daft. Hence the use of privacy addressing. Normally a privacy address has a short life, and a new temporary address is created. Many of these can overlap, with existing TCP sessions carrying on using the old address, and new sessions using thew new one. Eventually old addresses can be removed when no longer in use. This is fine if all you do is use you home computer to access facebook and gmail.

However, as a business, we use computers for business. We have systems that log accesses using IP address and reverse DNS. We have systems that include IP address in login session tracking over multiple web pages. We have access control systems that use IP address and reverse DNS before even allowing a login. We have firewalls that use IP address. This is just the same as using proper IPv4. IPv6 makes life a lot easier as the whole company can be within on /48 rather than many fragmented IPv4 blocks, but otherwise the principle is the same.

The problem is that more and more machines are now operating privacy addressing by default. This includes linux, windows, mac, and iPad and iPhone. With many of these there is a way to turn it off, but not with all. If you do have any systems that even just log IP addresses, then privacy addresses are a pain.

So, what is the solution? The best solution is for devices to allow you to turn it off if you need. If devices used DHPv6 to get the address then the administrator could set a DHCPv6 server to give fixed "temporary" addresses and avoid that. However, it seems there are many devices now that do not get a temporary address by DHCPv6, have privacy addressing on by default, and do not allow you to turn it off.

Sadly I can think of a good solution, and it sort of involves NAT on IPv6. Yes, that would be horrid. NAT is evil. Well, this idea is only half evil, honest. The idea is that we know the permanent address that a device has based on its MAC - that does indeed seem to be very consistent and standard. So we can spot, at the border router/firewall (AKA FireBrick) where a device on the LAN is using a privacy address. So, we can, err, map it to the address it should be using!

This is not quite as evil as normal NAT. For a start there is no port change involved as there is no address sharing. Also, the address to which the session is mapped is an address that should work for the device sending the traffic as it will be its normal permanent address. This means, in theory, that even embedded addresses in protocols for return connections should work unless some very specific binding is used by the application.

It would also be possible to only do this mapping where contacting specific machines, e.g. the rest of the office network, and not when accessing the Internet in general, hence controlling where privacy addressing is used and where it is not.

So, I am seriously considering this as a standard feature in FireBricks, at the subnet level (like the nat setting) for all traffic from the subnet, and in the firewalling rules (like the set-nat setting) allowing finer control of when it is applied and not.

Have I really turned to the dark side? Should I do this?


  1. So using the layer 2 table you pick up the mac address, match it to the IPv6 address if !related & match do_nat rule then "nat" source to permanent ipv6 address,

    would only be workable for situations where the FB is the 1st hop....

    ... sounds useful, but a relatively high evil quotient. - probably has the same potential to break applications (where address is also embedded in payload) as NAT does..

  2. You're setting yourself up for breakage.

    A socket tuple is based on source address as well. A host can use the same source port on its various source IP addresses. I don't think that requires special binding; it just depends on TCP/IP stack behaviour.

    I'm in the same position as you are, and I agree that privacy extensions are just plain evil, and should always be disabled. This is *definitely* the case in a business environment. (DREN has this policy, for example). On which OS can you not do that?

    As you point out, for the little old ladies using Facebook, there is no real problem.

    For geeks like us, the use case is running an Internet-facing service on the host. The user is just going to have to have a stable IP address (duh; how will you get to it from the Internet otherwise), and therefore will have to disable privacy extensions, or at least configure a static address. So for user-configured firewall rules, you can ignore privacy extensions and just educate the users.

  3. I did something similar - work out what the real reverse DNS should be and register it for the 'privacy' address. The problem with that is that the reverse lookup tables could grow to near infinite size :p

    I do like the idea of a 'de-privacy' box. I suspect you wouldn't even have to deal with replies as the box is listening on that address anyway, so it's a straight outgoing rewrite.

    I believe some routers can already be configured to automatically block privacy addresses outgoing, on networks where tracking is important.

  4. It's only doing NAT and not NAT and PAT so only half-evil I suppose :)

  5. At an Enterprise level, we don't want to be concerned with what IPv6 address a device has. DNS is king, and rule based matching against DNS is the only way to avoid IP mapping hell.
    If devices can't get an IP address from DHCP (of either class), then there is more to worry about than zone traversal.

  6. I now have two devices using non-switchable privacy addressing... how am I supposed to tell them apart if one of them goes "runaway" sucking data down my line?

  7. Somehow get the router to spot privacy addresses, and dynamically generate reverse DNS to match their official name. Log by DNS name as well as ipv6 address, job's a good 'un. Refer to machines by names rather than numbers.


Comments are moderated purely to filter out obvious spam, but it means they may not show immediately.

ISO8601 is wasted

Why did we even bother? Why create ISO8601? A new API, new this year, as an industry standard, has JSON fields like this "nextAccessTim...