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.

April 13th, 2009 at 10:46 am
Yurie,
Your conclusions are right on the money. When I hear “enterprises are asking for NAT66,” I too ask, “who?” The vast majority of enterprises have not yet given much or any thought to IPv6; much of this sentiment is likely to be around “I’ll never migrate to IPv6 unless they have NAT,” without really understanding the issues, simply because they know NAT is an integral part of their IPv4 network.
That leads, in turn, to vendors, who don’t build anything unless they have an identifiable market for it. I doubt there are many enterprises driving this.
April 14th, 2009 at 10:07 am
Yurie:
I have now doubt that new and creative IPv4 NAT bandaids such as ‘carrier grade NAT’, ‘nested’ NAT, dual-stack lite, NAT64, etc.. will be needed to extend the life of IPv4 scaling by expanding NAT into carrier cores. IPv6 deployment is going too slow to address the critical scaling problems we will really see with IPv4 in 2012-2015 so expanded use of IPv4 NAT will be a necessary evil.
Another desirable NAT feature in the near future will be translation IPv4-only resources into IPv6 (NAT64) to create “IPv6 dominant” networks that don’t have the added expense (approx +15%) of operating a full dual stack everywhere.
But NAT for IPv6 seems redundant when we have stateful firewalls and intrusion prevention systems combined with IPv6 privacy addresses [RFC 3041] giving us the same “topology hiding” and security when host systems reach out to external services.
Mostly it seems that the debate on IPv6 NAT is sidelining the real story - IPv6 is being deployed TOO SLOWLY to address much of the operational pain we will see in 2012-2015 as IPv4 scaling hits its limits.it will actually take years to properly “operationalize” secure IPv6 capabilities in most carrier’s networks and enterprise infrastructure - - and we’re only 3-5 years from needing it to be operational. Taking too long to activate IPv6 as IPv4 resources dwindle could leave us with a gap in services that will affect Internet availability.
April 15th, 2009 at 10:09 am
I agree that we should be very careful about how we handle NAT in IPv6.
There are two types of NAT. The first and most common type of NAT is the one that translates ALL internal IP-addresses to ONE external IP-address (many to 1). This type of NAT is evil and destroys a lot of things such as end-to-end connectivity, requires keep-alive, etc. The other form of NAT, that translates ONE IP address to ANOTHER IP-address (1 to 1), is not necessary bad. For that type of NAT end-to-end connectivity will still work. I can see a few scenarios where NAT would make our lives easier, but as you point out, NAT is not a security feature.
April 21st, 2009 at 1:40 am
Well, I am an enterprise admin who believes in “I’ll never migrate to IPv6 unless it supports NAT.” In fact, we have an R&D group working now on studying various solutions from NAT66 to Ipv4 -> IPv6 protocol translation and a few others.
The idea is that this is OUR network. Our computers. Not the world’s. You do not get to establish a session to our equipment unless we say so. Yes, I am aware that you can use a firewall on the edge device, and fill it with a mess of rules in order to block sessions from the “wide wooly net” establishing themselves to your client PCs. The problem with that is that one mis-configuration, and suddenly, all your PCs can be “connected to” from the outside, rather than having to initiate the connection from their side. I do not in any way like that at all. That means that every single device with an IPv6 address requires a firewall installed, configured, and maintained, because there is the possibility it could be “naked to the net” without the edge devices on your network doing their job and blocking inbound connections.
The concept of having to firewall every single device inside our perimeter, and then managing all of that, (or training users to) is simply insane. We simply don’t have the resources to pull that off. Now, there is a lot of work going into protocol translation, mostly as there are reams of older devices that simply aren’t, and never will be IPv6 aware. If necessary, we’ll hang an IPv6 IP on our edge devices, and run entirely IPv4 internal.
Long story short however, we simply do not want publicly routable IP addresses inside our perimeter. This way, even if someone screws every one of our firewalls up, and everything goes horribly, horribly wrong, those systems still can’t be “attacked” directly from the outside.
NAT may not be security, but hiding in a non-routable address space certainly is a (small) part of a well rounded security effort.
Especially for companies that are severely understaffed in IT.
IPv6? Until either NAT66 or NPT46 are fairly mature, JUST SAY NO.
(Oh, and for the arrogant types who simply clain that anyone that disagrees with them “just doesn’t get it,” all I have to say is this: Thank You an deveryone like you for giving us SMTP. Your happy-rainbow thinking is exactly the kind of crap that is responsible for a mail protocol with no form of authentication or validation. Great forward planning. Maybe protocols and standards should be designed by people who have to use systems in the real world, and not by academics who haven’t gotten out to see how horrible people really are to one another outside of the ivory towers.)