I was first introduced to this thing called “IPv6” in 2000. At the time, I had no real network engineering background and knew little of IPv4 or how things like websites or the Internet really worked. I was (and still am) a “business guy”. So as I sat in a room of v6 savvy network and systems engineers, I had been given one purpose: Articulate the business value of the next generation Internet protocol. I heard things like “better security” and “better QoS” and any number of other erroneous qualifications for what IPv6 brings to the table. However, the one word (acronym actually) that was uttered at that meeting, which still holds today, was the elimination of Network Address Translation, or NAT.

In the decade that has passed, the IPv6 community has done a good job of stamping out any myths about the capabilities of IPv6 and accurately articulating what is the primary value proposition behind a global move to IPv6. Arguably, IPv6 is about scalability and a return to the principle of end-to-end communications. With an enormous address pool, IPv6 is capable of scaling to support trillions of devices – everything from your laptop to the thermostat in your house. It also means that we no longer require NAT (an IPv6 address shortage is not likely for many decades, if ever). Network Address Translation was devised primarily as a way to extend a dwindling pool of IPv4 resources. And it worked.

Yet, NAT introduced a new layer of complexity to the environment, which ultimately required many workarounds to accommodate new applications and solutions (see RFC 3235, RFC 2993, and RFC 4966 for some insights). It also had the side effect of “hiding” a networks topology, which ultimately made its way into the bag of trick network and security architects used to protect their infrastructure. There are camps on both sides regarding the value of NAT as a security mechanism and as a method of continuing to leverage the IPv4 address space. While I’m not religious about NAT, I’m certainly biased towards IPv6 and think there is a compelling argument that the world will ultimately be better off without NAT.

So I was concerned when I heard through the grapevine that an IPv6 NAT might seriously be in the works. This wasn’t the first time – there have been talks before. But this seemed like the first time it was getting real consideration. At the recent IETF 74 meeting in San Francisco the issue was covered in a BoF (stands for Birds of a Feather). The discussion focused on these three elements (verbatim from the last slide in the presentation):

• Do the advantages of NAT66 outweigh the problems?
• Is it better to specify NAT66 vs. letting vendors build NAT for IPV6 solutions?
• Should we form a working group to specify a NAT66 solution?

According to an article by Carolyn Duffy Marsan in Network World titled “IETF: No consensus on IPv6 NATs” the results of that discussion were mixed. However, there seems to be some momentum in this direction because a proposal for an IPv6 NAT, dubbed NAT66 is at a draft level of 2 (IETF drafts start out at 00). So what is driving these actions by the IETF? Essentially the reasons given for an IPv6 NAT solution are:

• A NAT gives organizations topology hiding – a perceived form of security – so we need it in IPv6 too
• A NAT gives organizations freedom from ISP, so if they must switch providers, they won’t incur as much renumbering effort
• Vendors are building it anyway, so let’s have a standard rather than lots of uninteroperable IPv6 NAT solution

At the aforementioned IETF meeting, Margret Wasserman of Sandstorm Enterprises, one of the NAT66 draft authors, presented the framework for NAT66 as well as some justification for chasing an IPv6 NAT solution. According to Ms. Wasserman, the need for an IPv6 NAT is based upon:

• Enterprise network operators want IPv6 NAT
• Vendors are already making IPv6 NATs to meet a market demand
• IPv6 NAT is inevitable and the IETF cannot do anything to prevent it

Treading carefully here, I’ve not seen any public demand from enterprise network operators for a form of NAT for IPv6. There have certainly been industry pundits who have offered the “it’s inevitable because we have it in IPv4” argument. But that’s basically the same as saying “That’s the way we’ve always done it” – which is a really a poor excuse and technically lazy. That isn’t to say that some enterprises have come to their vendors quietly and asked for it. But I have to wonder how well those organizations understand IPv6. Could it just be a lack of IPv6 education on their part? NAT is NOT security and the “bad guys” have already found lots of ways to penetrate your NATted network. There are solutions available for topology hiding with IPv6 (and IPv4) that don’t involve NAT.

As far as vendors implementing their own versions of NAT for IPv6, this is a tragic road which has been travelled before. There are numerous types of IPv4 NATs, all stemming from a lack of implementation standards. So the IETF does not want the same mistake repeated. I understand this. But again, I’d argue that vendors implementing IPv6 NATs don’t understand IPv6, or have some other misguided purpose for implementing a technology that doesn’t serve the long term best interest of the Internet community. Either way, I think rather than condone their lack of understanding with a sanctioned standard for IPv6 NAT, we should educate them on IPv6 and other methods for topology hiding that they can then implement in their code.

With regards to the inevitability of an IPv6 NAT, I couldn’t disagree more. In the world of technology procurement, there is less and less tolerance for non-standardized implementation. Organizations want COTS – Commercial Off-The-Shelf products. They don’t want vendor specific implementations that lock them into a solution that only interoperates with solutions from that same vendor. So instead of developing a standard for IPv6 NAT that ensures uniformity, the IETF should be developing architectural solutions that provide the greatest perceived benefit of IPv4 NAT, which is topology hiding, while preserving the opportunity to restore the end-to-end capability of IPv6. In other words – spend your time in more beneficial pursuits! Let the market work like it is supposed to. There will certainly be some instances where the buyers of vendor specific IPv6 NAT solutions get burned. But this isn’t 1998 either. The IT buyers of 2009 are far more savvy and educated and will drive cowboy IPv6 NAT implementers out of business.

Finally, I’m a bit skeptical of this notion that vendors are building IPv6 NAT solutions on their own. Frankly, many vendors haven’t had the foresight to get basic IPv6 support and feature parity integrated into their products in the first place – let alone develop proprietary technologies on top of foundational IPv6 support.

In the end, I’m hopeful that reason and a desire to advance our understanding of how networks can be transformed under IPv6 will overcome the need to maintain the status quo.