[e2e] Internet Draft and survey on P2P in the presence of NAT

Henning Schulzrinne hgs at cs.columbia.edu
Wed Apr 9 08:24:47 PDT 2003


Unfortunately, many users aren't given a choice in the matter, at least 
at reasonable cost. I would certainly prefer to not have to deal with this.

In general, I think the NAT issue illustrates a problem that will only 
get larger: an ever larger fraction of time, financial resources and 
research will be spent on maintaining legacy systems. Apparently, this 
fraction has already reached well above 80% in many IT organizations. In 
our case, the two primary legacy costs seem to be
- insecure protocols, protocol implementations and operating systems
- insufficient address space

Networking will become like civil engineering, where the vast majority 
of time and money is spent on maintaining and patching up a crumbling 
and decrepit infrastructure, rather than designing new roads, public 
transportation, bridges or structures.

Henning

David P. Reed wrote:

> This is all great work, but I have to say that if we had used true 
> subnet routers instead of NAT we'd be way better off.
> 
> How many lines of code will be needed to bypass NATs in SIP 
> implementations 5 years from now?   And how many new firewall and NAT 
> systems will be invented that continue to screw up perfectly sensible 
> end-to-end applications?
> 
> This wouldn't even be a respectable research topic if ...
> 
> At 10:20 PM 4/8/2003 -0400, Henning Schulzrinne wrote:
> 
>> There's been a lot more recent work on NAT traversal in the SIP 
>> working group and surroundings. See, for example, the recent ICE draft 
>> by J. Rosenberg that combines a number of NAT traversal techniques.
>>
>> Bryan Ford wrote:
>>
>>> Hi end2enders,
>>> I have been working on collecting and consolidating information about 
>>> making peer-to-peer applications work seamlessly with NAT (you know, 
>>> that evil anti-end2end technology we all love to hate :)), and have 
>>> just released the first version of an Internet Draft on which I would 
>>> be grateful to hear your comments:
>>>         http://www.pdos.lcs.mit.edu/~baford/nat/draft-ford-natp2p-00.txt
>>> In addition, to get a better sense of the compatibility of these 
>>> techniques with widely deployed NATs, I wrote a short NAT tester 
>>> program that basically works like a simple STUN (rfc3489) client and 
>>> outputs relevant stats, and a friend set up an on-line database to 
>>> collect results.  If you are behind or have access to a NAT that 
>>> isn't already listed in the database, we'd greatly appreciate if you 
>>> could run the client and enter the results you get.  The program 
>>> (source, Linux binary, FreeBSD binary) and database are at:
>>>         http://www.pdos.lcs.mit.edu/~baford/nat/
>>> Thanks for your time!
>>> Bryan
>>
>>




More information about the end2end-interest mailing list