Thanks to Packet Pushers episode 43, it appears that I’m going to be known as Tom the Networking Nerd, the guy that hates NAT. I suppose that’s as good as anything to be known for, and the trick to being a famous celebrity blogger is getting yourself a hook, like Apple Fanboy or General Grumpy Networking Guy. I know that I made some pretty bold statements during the show, and while some of it may have been playing into a image, I’d like to take a few words to clarify my position on why I dislike NAT.
Network Address Translation goes all the way back to RFC 2663. At its heart, it is simply a mechanism for modifying IP packets and the information in their headers when the cross a routed boundary. As I said in my IPv6 presentation, I do really believe that basic NAT serves a purpose in a network. As a protocol, NAT isn’t inherently bad or good. Instead, it is the application of the protocol by people that colors it in my eyes. Allow me to give an example that I feel is very similar to NAT: Bittorrent. I think the Bittorrent is a very useful protocol for file downloading. By using the number of users accessing a file to amplify the speed at which it is downloaded, it helps alleviate the effect of having thousands of people downloading a file at once. It also has built-in error correction, as each file piece is hashed upon receipt. It’s very useful for downloading large, error-prone files like Linux ISOs or even World of Warcraft patches. However, Bittorrent has an evil side. Since it is so useful for downloading large files or collections of files, it has been appropriated by the underground file sharing movement as a method for distributing movies, games, and applications less-than-legally. The opponents of this activity say that Bittorrent encourages people to break the law, much in the same was the the motion picture industry argued that VCRs encouraged movie piracy back in the 1980’s. The counter argument here is that Bittorrent isn’t good or bad, instead the intentions of the user must be taken into account. I feel the same way about NAT.
NAT breaks things. End-to-end communications between nodes are disrupted by NAT boundaries. VoIP packets die when they hit NAT walls. VPNs don’t particularly care for it either. We’ve had to come up with things like STUN and ICE to workaround a workaround. It’s getting embarrassing when you have to fix the fix that you put in place. That’s not to say that NAT doesn’t have its good points, however.
NAT is great when two companies need to merge and have the same address space be in use during the transition. NAT is a good idea if you need to obscure IP addresses for some reason. Note that I didn’t say anything about securing them. If you hear a security “expert” claim that NAT provides security, you have my explicit permission to beat them within an inch of their life. Beyond a few cases, I think NAT has been used as a kind of “Internet duct tape” and has been stretched long past its original use case into something dastardly. I realize that without RFC 1918 and Port Address Translation (PAT), we would have run out of IPv4 addresses long ago. NAT has become a necessary tool in the IPv4 world, and I accept that. However, the paradigm of NAT is started to be extended into IPv6 unecessarily. That’s the part that I don’t agree with.
People are looking at IPv6 and wondering how to apply their IPv4 knowledge to it. That in and of itself is nothing new. When I was first learning how to do VoIP stuff, I used my networking background to assimilate new terms. I used to say things like, “Oh! A calling search space is just like an access list.” While it was great for me when I was just learning, I found out later than metaphor wasn’t quite accurate. In much the same way, network engi…rock stars are starting to plan IPv6 deployments and they are looking for analogies for the IPv4 things they are used to. When they don’t see things like NAT or RFC 1918, it makes IPv6 feel alien to them. For proof of this, you need not look any further than RFC 1884 – site local addresses. This was an idea to reserve fec0::/10 for use only within a specific site. While link-local addressing has many uses, the idea of what amounts to RFC 1918 addresses for IPv6 is kind of silly. Why not just use your IPv6 global addresses instead? RFC 3879 thankfully removed site local addressing from our lexicon for the time being, until it was reintroduced again in RFC 4193 with a slighly different name. The same thing happened (in my opinion) with NAT-PT. People were looking for something they saw in IPv4 in IPv6 unnecessarily.
I feel that NAT in IPv6 will encourage laziness. I know there is no such thing as infinite address space, but we’ve got enough address space right now to outlast this Internet and whatever the next revision is going to look like. If we allow NAT64 to take hold in the networking world, we are giving our blessing to people to keep doing the same things they’ve been doing with IPv4 all over again. It’s the networking equivalent of the famous Santayana quote, “Those who forget the past are doomed to repeat it.” If we allow people to implement IPv6-as-IPv4, we aren’t going to do ourselves any favors. Many of the non-address space related reasons to go to IPv6 evaporate when NAT is introduced. We eliminate wonderful things like end-to-end communications solely for the sake of ease-of-configuration. Bah, I say.
I’ve always been a proponent of building it right the first time. Even if it takes a little long to learn how to do it, as long as the implementation is done correctly at the end everything will work out. As an integrator, a large portion of my time is spent cleaning up after other people’s mistakes. All too often in IT, we patch a problem and declare it “good enough” only to spend twice as long down the road fixing what we should have fixed the last time. If we start using NAT unnecessarily in IPv6, it will come back to bite us down the road. People will avoid using IPv6 internally because “it’s too much trouble”, and just use NAT64 to talk to the IPv6 Internet. A lot of good work will have been for naught due to the laziness of some.
There are already a lot of v4-to-v6 transition mechanisms out there. F5 is looking at using load balancers to do 4-to-6 translation. Proxy servers can help. Tunneling can be had in any flavor you want, even the much-hated Teredo protocol. Incidentally, Teredo was developed because Microsoft needed a specification to get around…NAT boundaries. If we absolutely need to do something other than the ideal of running dual stack, we can use some of the other mechanisms that have been devised that will allow us to transition to where we need to be rather than coming back to our old NAT kludge.
I once was able to work on a network that didn’t have NAT. Globally routable IP addresses as far as the eye could see. And yet, due to a voice implementation that didn’t have enough address space, NAT still came back to bite me in the ass over and over again. You can see why that might make me grumpy.
In the end, I really don’t hate NAT as much as I might let on. Yes, it’s a necessary evil in IPv4. I don’t want people to keep using it as a crutch instead of designing proper networks with good security policies. I want people to start thinking about IPv6 as a great new opportunity instead of thinking about it in the same old way. If designers had kept thinking about phones in the same old way, we would never have gotten the iPhone or the Nexus S. If computer designers had thought about portable PCs in the same old way, we wouldn’t have iPads or Galaxy Tabs or Chrome CR-48s. I want to encourage people to solve problems with the new tools they have been given rather than falling back on broken ideas from the 90s. I may not be as opposed to NAT64 if it had an expiration date. Use it if you want, but be sure to have it out of your network no later than December 21, 2012 or the world will end. I suppose I could live with that. But it doesn’t mean I have to like NAT.
Thank you for this clarification. I’ve heard you hate on nat several times and always wanted more details. After reading the above post, I want to make sure I approach IPv6 properly, and don’t make any mistakes when implementing it in the network I am responsible for. I have to admit that I’m not very well versed in IPv6, but I want to be. Can you suggest some good resources I can look to for guidance as I plan/prepare for my 4 to 6 transition? Books, websites, classes, etc?
Pingback: Happy Twitterversary To Me! | The Networking Nerd
Pingback: Motivating for Enterprise IPv6 Adoption | The Networking Nerd
I think I have found someone who shared this big love for NAT with me 🙂
what about A+P ?
Pingback: Why Do We Hate NAT? « Layer3
Pingback: IPv6, NAT, and the SME – A Response | The Networking Nerd
I agree with your hate for the NAT. Btw you said: “NAT is a good idea if you need to obscure IP addresses for some reason. ” how could we do that on IPv6? That’s quite important nowdays.
I think you may like http://otacon22.com/2013/01/15/network-address-translation-an-abomination-and-horror/
@Tom: Eliminating NAT from IPv6 to facilitate end-to-end communication is fine, and really required as NAT causes a lot of problem on that front. But how do you enable IP address obscurity in IPv6? You have written that NAT doesn’t provide security but isn’t obscurity an added layer of security that can’t be ignored?
my question is IPv6 and private addresses. are we gonna be able to have private IPv6 addresses in the LAN and not use NAT. as far as i understand, if you are not using NAT, you have to use the addresses that the ISP gives you.
Pingback: CCIE Version 5: Out With The Old | The Networking Nerd
At risk of getting beaten to an inch of my life, I disagree with your claim that NAT is not security. It isn’t good security, but it is the only security (other than antivirus) millions of households have.
With 20/20 hindsight four years after your original post, we now know that consumer-grade router manufacturers are taking the easy way out and simply blindly pass through IPv6, while NAT does prevent inbound connections. That is a security impact.
NAT causes problems, no question. It also has value beyond extending IPv4 (and beyond securing home networks).
Pingback: Don’t Be My Guest | The Networking Nerd
Here we are, 2022, and dual wan failover with a ds-lite primary uplink and lte backup forces me to use the abomination that is nat64. Provider A refuses to hand out ipv6 without their modem being the dslite endpoint and handing out a single /64, meanwhile provider B charges a lot /GB.
Its messy, but simple and it works.