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?