The Land Of Opportunity

It’s been *checks watch* about 38 minutes since I last thought about NAT, so it’s probably time to sit down and write some more about it.  I’ve got an image to uphold after all.  I wrote about my position on NAT a couple of posts ago, and in it I discussed NAT64.  I railed against it much the same as introducing any kind of NAT into IPv6.  Ivan Pepelnjak, a very well respected and frighteningly intelligent networking rock star, listened to the Packet Pushers show that fueled my rant and read my blog post.  He then posted an article where he takes NAT64 and puts it into proper perspective.  I read through it, and guess what?

He’s absolutely right.

Yep, Ivan nailed that one.  NAT64, which is the process of translating IPv6 addresses into IPv4 addresses, has a use when it comes to allowing the IPv6 Internet to access content that is still stuck on the IPv4 Internet.  Without some sort of translation mechanism, those IPv6-only hosts will be walled off from the IPv4 Internet in general.  The other methods he discusses are either completely insane, like Carrier-grade NAT (NAT444), or are impractical from a support standpoint, like dual-stacking.  I happen to think dual-stacking is the way to go with this, but I don’t want to be the local ISP trying to support a D-Link router running a dual stack when someone’s mom calls for support.

Ivan’s final point of the article hits home in a way that should make people sit up and pay attention.  “The proper way to tackle this issue is to make your content available over IPv4 and IPv6. IPv4 clients won’t notice it and IPv6 clients will use native IPv6 connectivity bypassing NAT64.”  He’s spot on with this one too.  If you build your content aware of both IPv4 and IPv6, you won’t have any real issues when it comes to IPv6-only hosts.  I’m going to take this one step further, though.  Let me ask a question that I think really cuts to the heart of the Internet in general when it comes to content creation and consumption:

What content would you access that is IPv4-only?

Right now, that question would be answered with “everything”, since IPv6 adoption is spotty at best.  However, with World IPv6 Day looming in less than a month, the sponsor list is growing quickly.  Google, Yahoo, & Facebook are already on board, and 163 more companies are ready to flip the switch as well.  If you think about it, there’s a great importance that should be attached to making your content IPv6 accessible.  In my IPv6 presentation, I talked about the impact of new content providers in the APNIC region creating things that you won’t be able to see if you are on the IPv4 Internet, since they are out of IPv4 addresses totally at this point, for all intents and purposes.  However, look at it from the perspective of an IPv4-only content provider.  You’ve got all this great content that you want to serve out to your audience.  Many of your audience members are starting to hear about IPv6 and wonder how it will be implemented.  More still, like those in the APNIC region, are unable to view your IPv4 content right now.  For those hopping on the IPv6-only Internet, it probably looks a lot like it did back in Vint Cerf’s day – a whole lot of nothing.  If you want to stake your claim for your content, are you going to wait for someone to come out with a NAT64 appliance?  Are you going to sit around until an IPv6-to-IPv4 transition is possible on a load balancer?  If you are, you had best start packing up your office, because you won’t stick around for long.  The handwriting is already on the wall.

World of Warcraft, the largest Massively Multiplayer Online Role-Playing Game (MMORPG) enabled IPv6 connectivity in their recent v4.1.0 patch.  They’ve been talking about it since March.  Now, those 10 million subscribers won’t have to worry about NAT64 if they get assigned an IPv6-only prefix.  They’ll just keep on playing the same way they’ve always played.  I think it’s going to end up being the same for 75% of the services that you use today.  Things like e-mail, calendaring, and popular websites will be IPv6 ready well ahead of any kind of IPv4 exhaustion.  Those that rely on advertising revenue won’t hesitate to get IPv6 enabled so as to not lose out on an untapped market of IPv6-only hosts.

Tom’s Take

NAT isn’t pretty.  It’s a necessary evil.  It has uses, and as Ivan pointed out they can be pretty important to keep the content-rich Internet from looking like a barren desert.  But at the same time, there is a path away from the need to slap a NAT64 band-aid on things.  By enabling IPv6 now, you avoid the expense and hassle of needing to wait for NAT64 to be finalized and argued about until the vendors are blue in the face.  You, as a content provider, can serve your content and ads and subscriptions to a whole new world of consumers in this new land of opportunity while the IPv4-only world gets left by the wayside, trying to figure out how to patch the problem rather than fixing it right the first time.

As a side note here, if you are at all interested in IPv6 and its implementation and impact, you need to sign up for Ivan’s excellent webinars.  He’s a genius when it comes to MPLS, IPv6, and datacenter networking.  In fact, do yourself a favor and save money by just buying a subscription to all of them.  At $199, it might sound like a pricey purchase, but since you’re going to want to listen to everything he’s got to say, it works out to be a great investment in your future.

I Hate NAT! Or Do I…?

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.