Problem: the Internet is running out of addresses. Clean solution: create more addresses by increasing the address length from 32 to 128 bits. Messy solution: have multiple systems share a single 32-bit address through Network Address Translation (NAT). After years of applying the messy NAT solution, it looks like we're going to run out of 32-bit IPv4 addresses within the next three years or so anyway, so those who want to connect to the Internet after 2011 or 2012 will probably have to use IPv6. But everyone else will still be on IPv4, so we need some way for IPv6 users to talk to IPv4 users. Could the much-maligned NAT be the solution?

Because of the large address space, IPv6 doesn't need NAT to conserve addresses, so many IPv6 proponents have been looking forward to a future without NAT. In a five-page article, however, Network World suggests that the Internet Engineering Task Force is considering adding NAT to IPv6. In its current form, NAT introduces a number of problems. It works just fine when end-users initiate a connection to a server, but it gets in the way when two end-users want to talk directly, such as when transferring files using an instant messaging client or with Apple's back-to-my-Mac service. There are ways to avoid these problems, but every application interacts with NAT differently, so there are often combinations that won't work.

What we're actually working on in the IETF—yes, my name appears on some of the working documents—isn't IPv6 NAT as such. We're trying to find a reasonable way to translate between the IPv6 and IPv4 worlds. Just translating an IPv6 packet to an IPv4 packet isn't all that hard, provided you have an IPv4 address for every IPv6 address that needs translation.

But the whole reason why we need IPv6 in the first place is that we don't have an IPv4 address for every user—let alone every device—that wants to connect to the Internet. So just translating the protocols isn't enough: just like a home with several computers that share a single Internet connection with a single IPv4 address, several IPv6 users who share a translator will have to share an IPv4 address. This is where NAT comes in: it's only applied when an IPv6 system talks to an IPv4 system, not when two IPv6 systems are communicating.

From time to time, IETF-ers speak up in favor of NAT in IPv6, suggesting that we should just get over ourselves as (enterprise) users have grown to like the fact that a single address can hide an entire network. However, if we were to design NAT for IPv6, it would look very different from NAT as it exists today.

Being able to have stable internal addressing despite changing connectivity to the rest of the world can be very useful. An airplane that connects to different ground stations during a flight, for example, may want to avoid renumbering all the internet-connected systems on board each time it hooks up with a different ground station. However, with IPv6 there is no need to make all the devices on board share a single address as it's actually much easier to translate one range of IPv6 addresses to another range of IPv6 addresses—this requires much less meddling with protocols and applications.

So far, nobody has seriously suggested a one-to-one IPv6 NAT, let alone standardizing an address sharing NAT for IPv6. But that lack of standardization didn't really stop anyone from doing NAT with IPv4, either... In any event, it looks like after next week's IETF meeting in Dublin, IPv6 may not be as architecturally pristine as it was once envisioned to be. But we're not ready to throw out the baby with the bath water just yet.