[arin-ppml] An article of interest to the community....

[Owen DeLong]

On Aug 30, 2011, at 6:31 PM, Mike Burns wrote:

> Hi Paul,
> 
> 80 is not the only port.
> Remember port 21's problem with port 20?
> That screwed up Nat right from the getgo, but how long did it take for passive ftp to appear?
> I use multi-level Nat every day and I manipulate ports which carry http, https, Radius, ftp, voip, vnc, Xbox, MagicJack, Netflix, Skype, etc, etc. Tcp and udp. Every day.
> .
> Rendezous servers allow for Nat traversal while at the same time providing access security. Stun and SIP work and UpNP also works.
> 

All of these things are true for a single layer of NAT to a limited extent.

Oh, and your claim that STUN works -- Uh, Geoff Huston yesterday presented statistics showing that it has roughly a 45% failure rate.

This all gets much much worse when you introduce any (let alone all) of the following:
	+	Multiple layers of NAT
	+	Carrier Operated NAT
	+	NAT on the server side of the connection (yes, this has been proposed)
	+	Overlapping addresses in different regions of the NAT process
	+	NATs which do not support uPNP or NAT-PMP

It may work in your particular limited circumstance for some subset of users and some subset of applications, but, that is not the whole internet and it isn't even a particularly good microcosm of the variety of applications (both existing and being prevented) that exist on the internet. NAT hampers many applications, increases the cost and code base of others and flat out prevents some from coming to realization.

> I don't know how closely bound bandwidth growth is to Moore's Law, but the market has decided that including "state" in the form of  Nat is an acceptable practice. In fact Nat has been at the edges doing stateful stuff for 15 years, and Cisco and Juniper have big iron boxes for CGN.
> 

State at the edge is very different from state in the core. The market lacks proper technical understanding of these concepts and also tends to lack foresight into the natural long-term results of it's short-term decisions. The market is fickle and short-sighted by definition. The market means that Cisco and Juniper will build whatever technology they believe they can sell. Many cable MSOs are implementing CGN, for example, not because they are trying to prolong the life of IPv4 or delay their IPv6 rollout, but, because they have a need to continue to support certain limited IPv4 functionality during the transition.

> The documents I posted earlier were written by people whose understanding of this issue is not limited to the crippled web-centric mindset you erroneously apply to me. Like your speculator commentary, it's an ad hominem which does not advance your position.
> 
> What applications is Nat holding back?
> 

Frankly, since they don't see the light of day due to the engineering constraints of NAT preventing their development, it is hard to speculate as to what they are. I know that development of new multiplayer games has been hampered and that NAT is oft lamented at GDCs. NAT also prevents innovation in the areas of subscriber self-publication of content, end-user run services, etc.

Further, while this isn't an example of an application being held back, GoToMyXX (GoToMyPC, BackToMyMac, GoToMeeting, etc.) are examples of applications that are basically unnecessary outside of NAT where simple end-to-end connectivity would obviate the need for these rendezvous services. While you and/or the market may consider these parasite applications to be a good thing that increases revenue for some group, as an end-user, I regard them as parasites sucking money out of what should simply be a basic part of network access simply due to artificial limitations imposed on that network by NAT.

Owen