My rebuttal to “NAT not a problem” contingent

I attended a meeting recently in which a well respected ‘Net Insider declared that NAT is not a problem for the Internet. Part of their basis for such a position is that “Skype works.”

There is certainly technical accuracy in that statement. However, there is also a very practical reality that NAT is holding progress back. There are technical ways to “deal with NAT” and make an application “work” from the user’s perspective, but that doesn’t mean it works well, in a way that is in the common interest of the Internet and the people.

But I’m not going to talk about the drivers based on the technical aspects of NAT. I’m going to talk about the practical drivers and the ultimate practical effect of NAT.

I deal with real vendors, real developers, with real budgets, funded by private enterprise, and driven by corporate objectives. NAT is hard to do “right” especially in a way that promotes interoperability and other good aspects of the ‘Net we once knew. The result is, these companies essentially “give up” on dealing with NAT at the edge and deploy network-centric solutions, like media gateways, session border controllers, and such. This seems like an easy and “reasonable” solution, but in fact it has far-reaching consequences.

For one thing, it neutralizes any progress on peer-to-peer or end-to-end interoperability. No one cares – the people spending the money, deploying real devices/services throw up their hands. Supporting any end-to-end interoperability is off the radar and receiving no corporate sponsorship. And it’s got a network effect (in the “herd” sense) too. If you approach a firm with any idea that would benefit from dealing with NAT at the edge, you hit a brick wall. The response will be “Nobody else is asking for that.” Of course not, because they have given up too. It’s not because NAT technically prohibits it, but it makes the barriers too high.

Even, Skype, the poster-child for the “NAT is not a problem” advocates, actually highlights some of the exact reasons why NAT is, in fact, a scourge of cancerous proportions. Skype indeed has some clever hacks to overcome NAT and firewalls. It is really the only application where the company put a priority on NAT traversal technology. However, it’s not all good for NAT’s case.

For starters, Skype is closed and has no network-level interoperability at all. It’s so closed, many companies and other organizations refuse to permit it on their networks. Unless Ebay fixes some things, you can expect that trend to continue. Again, NAT is a big factor in the lack of interoperability. Lack of interoperability is bad because it centralizes and fragments innovation (think 75 years of AT&T labs, vs. 25 years of the interoperable Internet).

Secondly, the Skype NAT hacks depend on super-nodes, and ultimately, nodes that are not behind NAT. If every Skype node were behind a restrictive NAT, the whole Skype network would fail. Skype would have to deploy NAT-free servers of their own. Skype essentially creates an overlay network, routing calls through nodes that aren’t restricted by NAT at all, or have NATs Skype can deal with. This can result in a very inefficient path, and a lot of overhead on the network. It NEVER is the most efficient way to route the call, which would be directly between the two end-points.

Another practical reality driven by NAT is that none of the manufacturers are telling their ODMs (the companies in China that write the code in your typical Linksys box) to fix NAT. This means that none of the devices that will be available for consumers to buy in the foreseeable future are putting anything near the Skype efforts into making NAT work – they have “given up” because nobody is asking for end-to-end. Part of it is because it’s hard and the skills to do it right are just not there at a lot of these ODMs, but part of it is also this status quo kind of thinking, where “NAT is not a problem.” The result is, network-centric applications, network-centric control, and weak to no interoperability. And all this is driven by NAT. It’s not necessarily a technical deficiency of NAT (although there are plenty of those too), but it is a practical result, and it’s bad for you and me and the Internet at large.

You could argue that this “not NAT’s fault” and that these companies should just implement things properly. Yeah. Good luck with that. The reality is, if we believe in the benefits of end-to-end, we should do all we can to make that practical for the people that actually decide what happens, which is not the IETF or academia anymore – it’s average joe companies with corporate agendas.