It’s hard to believe that it’s been eight years since I wrote my most controversial post ever. I get all kinds of comments on my NAT66 post even to this day. I’ve been told I’m a moron, an elitist, and someone that doesn’t understand how the Internet works. I’ve also had some good comments that highlight a specific need for tools like NAT66. I wanted to catch up with everything and ask a very important question.
Every Tool Has A Purpose
APNIC had a great post about NAT66 back in 2018. You should totally read it. I consider it a fair review of the questions surrounding NAT’s use in 2020. Again, NAT has a purpose and when used properly and sparingly for that purpose it works well. In the case of the article, Marco Cilloni (@MCilloni) lays out the need to use NAT66 to use IPv6 at his house due to ISP insanity and the latency overhead of using tunnels with Hurricane Electric. In this specific case, NAT66 was a good tool for him to use to translate his /128 address to something useable in his network.
If you’re brave, you should delve into the comments. A couple of my favorite passages:
People from your side completely fail to understand that while NAT was not designed for security, it did bring security, in particular for home users.
Either the IPv6 community sobers up and starts actively supporting NAT or you can kiss the IPv6 protocol goodbye. I’ve put many many hours into IPv6 integration and I’m starting to realize it’s a doomed protocol and should be scraped.
It’s obvious to me a decade later that there are two camps of people that discuss NAT66: Those that are using it for a specific purpose. And those that think it has to be enabled because they use it with IPv4 networks. An example of the former:
Pieter knew what he needed to do to make it work and he did it. Not because it was something that he configured on his home router to make the Internet work. But he also knew this wasn’t the optimal solution. When you can’t change the ISP router to accept RAs you need a workaround. There are a ton of stories I get from people just like Pieter that involve a workaround or a specific thing like provider-independent address space not being available. These are the kinds of situations that tools like NAT were designed to solve.
X, Why, Z
Let’s get back to my earlier question: WHY?
For those that believe that NAT66 needs to be used everywhere, why? Is it because you’re used to using RFC1918 address space to conserve addresses? Maybe you don’t like the idea of your MAC address “leaking” onto the Internet? How about providing enhanced security, as the commenters above mentioned? There’s even a comment on my original post from late last year about using NAT to force redirects for DNS entries to avoid having Google overriding DNS on his Android phone. Why?
For me, this always comes back to the same answer I give again and again. NAT, used for a purpose, isn’t inherently evil or wrong. It’s when people start using it for things it wasn’t designed for and breaking every other thing that it becomes a crutch and a problem. And those problematic solutions always cause issues somewhere down the line.
NAT44 broke FTP. It broke end-to-end communications. It created the need for big, hungry middle boxes to track state of connections. It conflated addressing and firewall functions. Anyone that screams at me and tells me that NAT provides security by obscuring addresses usually has an edge firewall doing NAT for them. In a true one-to-one NAT configuration, accessing the public or global IP address of the host in question does nothing to halt the traffic from being passed through. People who talk to be about address obfuscation with NAT44 or NAT66 usually mean PAT, not NAT. They want one address masquerading as all the addresses in their organization to “hide” themselves from the Internet.
Why does NAT need to solve those problems? I get the complexity of using provider independent (PI) space internally and the need to configure BGP to avoid asymmetric routing. Especially if your upstream provider isn’t paying attention to communities or attributes you’re using to avoid creating a transit network or weight traffic to prefer one link over the other. NAT may be a good short-term solution for you in these cases. But do you really want to run NAT66 for the next decade because of a policy issue with your ISP? That, to me, is the ultimate in passive-aggressive configuration. Why not just jump through hoops instead of hammering out a real solution?
I may sound like a 5-year-old, but “WHY” is really the most important question you can ask. Why do you need NAT66? Why do you even need IPv6? Is it a requirement for a contract? Maybe you have to enable it to allow your application to be uploaded to the walled garden store for your mobile provider. Maybe you just want to play around with it and get an Hurricane Electric Sage t-shirt. But if you can’t answer “WHY” then all the other things you want aren’t going to make sense.
I don’t run my HE.net tunnel at home any longer. I didn’t have an advantage in running IPv6 and I had more than a few headaches that had to be addressed. There will come a day when I want to do more with IPv6, but that’s going to require more bandwidth than I have right now. I still listen to IPv6 podcasts all the time, like the excellent IPv6 Buzz featuring my friend Ed Horley. Even the experts are bullish about the adoption of IPv6 but not ignorant of the challenges. And these guys run a business doing IPv6.
For those of you that are already limbering up your fingers to leave me a comment, stop and ask yourself “WHY” first. Why do you need NAT66? Is it because you have a specific problem you can’t solve any other way? Or is it because you need NAT66 to be there just like ISDN dialer maps and reserved VLANs on switches? To me, even past my days in the trenches as an engineer, the days of needing NAT everywhere are long gone. The IPv4 Internet relies on NAT. We are hobbled by that fact. VPNs need NAT traversal. Game consoles and VoIP devices need to be NAT-aware, which increases complexity.
The IPv6 Internet doesn’t need to be like that. Let’s teach the “right” way to do things. You don’t need NAT66 for privacy. RFC 4941 exists for that. You don’t need to think NAT66 provides security. That’s what perimeter devices are for. Anything more complicated than those two “simple” cases is going to be an exercise in frustration. You don’t need to bellow from the rooftops that NAT is a necessary and mandatory piece of all Internet traffic. Instead, come back to “WHY”. Why do two devices need a middle box to translate for them and hold state information? Why can’t my ISP provide me the address space I want or the connectivity options that make this work easily? The more “WHY” questions you ask, the more the answers will come. If you just want to fold your arms together and claim that NAT is needed because “This is the way,” you may find yourself alone on the Island of NAT sooner than you think.
My identity as the “I Hate NAT” guy is pretty solid at this point in my life. It’s too late to change now. Sure, I don’t hate NAT completely. It’s like a vulture to me. It serves a specific purpose but having it everywhere is almost always problematic. By now, the only way I can work against the needless expansion of NAT is to ask hard questions. Ironically enough, the hard questions aren’t multi-part essays that require an open-book test to resolve. Often, the hardest questions can just be a single word that forces you to question what you need and why you need it.
What a wonderful post, thank you! I very much appreciate the nuanced approach of not vilifying NAT, but also not blindly recommending it. The WHY approach is exactly the point.
That said, I suspect that the use cases where the WHY has a good answer are actually very frequent, and they WHY is usually not technical. One scenario that comes to mind is city governments or school districts, where politicians favor tax cuts or highly-visible spending, and can’t always be convinced to budget $$$ on proper perimeter devices or the staff to configure and maintain it. Small businesses often face similar pressures. These are very frequently networks protected by nothing more than a $50 consumer-grade NAT router. Us IT guys understand and prioritize the implications, but even if the politicians, or business people struggling to keep a business afloat, understand it, they may have to juggle other priorities and not be able to do more than NAT.
What about when you want additional networks on a host, dynamically? Think about using VMs or Docker.
If you rent a server or a VM from a provider, they’re likely to either give you a single IPv6 address, or a /64 to yourself. If you’re lucky, the provider might actually send you that /64 to your link-local address like Hetzner do (https://wiki.hetzner.de/index.php/Netzkonfiguration_Debian/en#Additional_IP_Addresses_.28Virtualization.29 ), so if you’ve configured your address as a /128, you get a bunch of extra addresses to use internally. Detecting when that is happening is pretty much impossible — you have to know it’s being done, and configure your interfaces and docker / libvirt / virtualbox / vmware manually.
Let’s say I’m running Docker on OSX. That runs in a Linux VM sitting atop OSX. What if the user got an address via DHCPv6? Yay, we might be able to do prefix delegation and maybe get a few bits of network mask routed to it.
What about those networks that only do SLAAC? Docker could choose to see that you have a /64 prefix length on your external interface and assign /96s on each network it creates and does neighbor discovery proxying. That might silently fail though if there’s port security preventing it.
What if the user changes WiFi: they close their laptop at work, open it at home, everything resumes, but now there’s a different prefix and all the containers need new addressing. Maybe the app doesn’t like not having a configured IP address and crashes! User searches for the issue, finds it’s IPv6 related, disables IPv6. We’ve been here before.
All these problems can be solved by NAT66. Either use a ULA prefix inside, and make sure the host (suffix) part of the /64 is unique among all networks, and then you can NAT66 just the network (prefix) part and do proxy neighbor discovery. Or if that’s seen as not reliable enough, full NAT66 masquerading on that ULA which allows you to appear to the outside world as just a single address. Even better, you could go IPv6 only inside, and if the external interface only has an IPv4 address, spin up DNS64/NAT64 — it’s already using dnsmasq most likely as a nameserver!
Should a home, enterprise, or cloud provider network be doing NAT66 at the border? No. It’s needlessly incorporating state into the forwarding plane, for very little benefit, and discarding all the benefits of having IPv6 in the first place.
Should a host do NAT66 to provide namespaces / bridges / tunnels with IPv6 addressing? Absolutely. It’s the right solution. You can’t reliably determine what the “right” thing to do with IPv6 addressing internally in Docker, so it makes absolute sense that without NAT66 they would have IPv6 disabled by default.
Does that make sense? I realize it’s a fringe case, but if your developers aren’t exposed to IPv6 in their preferred environment, how are they ever going to think about rolling it out in production except as an address on their front-end load-balancer?
So in my opinion RFC 4941 doesn’t exactly solve the issue of privacy in the same way NAT did. My understanding it is randomized everything after the /64 prefix you are given so websites can still identify a device by the /64 prefix without issue. Even if you get 2 /64 prefixes it can only inflate the number of devices at a particular prefix so all its done is given more information about devices as a location not less. With NAT you could technically with enough work determine how many devices may be at a particular address but it required looking at other data than just the address.
Also I would argue that while NAT did break FTP and some other protocols the number of people it affected was and continues to be quite small. For the home user they will never notice the difference between NAT and PAT and Stateful Firewall and even no firewall. However one of the advantages of putting devices on PI and NAT by default is if there is a software error internet access is cut where as with a stateful firewall its possible to disable and expose all devices without any warning to the user. This coupled with the fact that most home users barely understand computers in the first place it would appear that NAT for home users is safer. Also in regards to consoles I would state its likely easier to have home consoles be able to request a one to one address than to assume every device needs to have one to one connectivity whenever few actually do.
a bit of a clarification. When you say NAT66, do you mean NPT or some hypothetical asymmetric NAT for IPv6.
We don’t need NAT66. It breaks the end-to-end principle. But also, ISPs and hosting providers need to be better at accepting and forwarding route advertisements so that the end-to-end principle always works.
At the same time … effective use of IPv6 requires that we get out of the habit of hard coding IP addresses into everything. SLAAC and/or DHCPv6 plus Dynamic DNS makes the whole network portable. Cloud providers do it and you should too.