[99662] in North American Network Operators' Group
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action:
daemon@ATHENA.MIT.EDU (Perry Lorier)
Tue Oct 2 05:41:16 2007
Date: Tue, 02 Oct 2007 22:35:11 +1300
From: Perry Lorier <perry@meta.net.nz>
CC: North American Noise and Off-topic Gripes <nanog@merit.edu>
In-Reply-To: <20071002030749.GB14344@internode.com.au>
Errors-To: owner-nanog@merit.edu
> What has happened? Well, application protocols have evolved to
> accommodate NAT weirdness (e.g., SIP NAT discovery), and NATs have
> undergone incremental improvements, and almost no end-users care about
> NATs. As long as they can use the Google, BitTorrent and Skype, most
> moms and dads neither know nor care about any technical impediments
> NATs erect between them and their enjoyment of the Internet.
Except every service that used to work using direct TCP connections has
either moved to UDP, or moved towards having unNATted boxes that people
can relay through.
While NAT traversal for TCP is theoretically possible, it relies on
rarely used features of TCP (Simultaneous open) and good timing, both of
which are likely to cause issues. I've never heard of a successful real
world application successfully doing this. (Feel free to educate me if
you know of a realworld application in common use that does do TCP NAT
traversal and has it work a significant amount of the time).
Even p2p apps like bittorrent rely on the fact that there are /some/
people /somewhere/ in the swarm that have either configured their NAT to
allow pinholing or don't have any NAT between them and the Internet.
Plastered everywhere over anything P2P filetransfer related is "poor
performance? Add a pinhole to your NAT box!" suggesting quite strongly
that NAT is causing large problems for P2P swarms.
NAT is hurting applications today, and applications aren't getting
deployed (or even written) because of problems NAT causes.
