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.

3 comments for “My rebuttal to “NAT not a problem” contingent

  1. I agree with your characterization of the problems created by NAT and also Skype’s approach has its limits. I also feel that over a period of time, we have become addicted to NAT and are exploiting it beneficially. So we have to "live with NATs". I think, in many instances (like consumer deployments, which seems to be your focus here) one can achieve the benefits of end-to-end by using UPnP in both the NAT and the clients. It will be instructive to know of your thoughts on this matter.


  2. Hi Aswath. If we indeed have to live with NAT (and since nobody but me seems to care about it, we probably do), then we sure as heck could use with some better standardization and improved clarity and consistency for restoring end-to-end apps (without the overhead of Skype-like solutions).

    I personally don’t like uPnP as a solution, but I don’t care. If it worked and were standard, I could live with it. But that’s the exact problem we have now. None of these NAT boxes work in consistent ways and it changes every week (with the next rev of ODM code from overseas) even on the same box with the exact same model number.

    UPnP, for example, essentially doesn’t work in practice. There’s no use building devices that rely on it, because (a) it’s not ubiquitous, and (b) implementations are not consistent or reliable. These are the problems that need to get solved, and I don’t care if the solution is UPnP or ICE or whatever, so long as there were pressure in the marketplace for companies to actually implement something that worked consistently and reliably.

    Right now, that’s what missing. No one is telling these vendors that their stuff is broken and that they need to fix it. And that pressure has to be hard (as in economic value) since solving the problem requires competencies at the ODM levels that is not presently in place. So the market will have to demand that this problem be solved, and it’s not on anyone’s agenda today.

    And it doesn’t help, when top experts say "NAT is not a problem."

  3. So what are some actual applications that you want to implement that require NAT traversal? If p2p is so wonderful, why are there so few good applications. What do you want to build?

Comments are closed.