[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