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.

Tom’s Take

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.