[p2p-hackers] Work on NAT-friendly DHTs?

[Luca Piccarreta]

Hi Saikat,
thanks for the note.
I really hope you're not right! :)
 From a commercial point of view network providers don't like
P2P, at least, they prefer P2P to stay inside their network.
It's "subsidization": servers pay for bandwidth, client  pay much less.
P2P is trying to subvert the client-server paradygm...
So, I wouldn't really be surprised if network provider /corporate NATs
would implement endpoint-dependent filtering (#3).
After all, it is coherent with the client/server model.
Residential NATs (wireless adsl routers, or whatever) have bundled
#3 model for improved security, I guess. I can see no other reason for
that, definitely not a technical one. The role of the NAT should just be 
routing
packets to the most likely packet destination.
The role of a firewall is filtering unsolicited packets.
Model #3 is, to my eyes, NAT+firewall.
But unsolicited packet filtering is already built in windows, nowadays...
Who knows!
And about ipv6... yes the switch from ipv4 to ipv6 will be likely made
through NATs usage, but what model? #2 or #3?
My fear is that network providers, very often coincident with telephony
providers, don't really like the idea of ubiquitous P2P. Who would pay
for phone calls? Who would pay for VideoTelephony? Voice traffic
is in many cases already over IP, and is paid so much more than data
traffic (in terms of MBytes). So if they can do something to stop P2P,
or confine it in their network, they will....
(I talk from experience, in Italy there is a fiber provider, 10MBits/s: P2P
is fantastic, get a movie in 10 minutes... but the firewall is... #3. There
was some voice that file sharing servers were hosted by the provider
itself! If they made it possible to make P2P with outside the network,
their outbound pipes would be saturated immediately)

Just a bunch of confused thoughts....

Luca.


Saikat Guha ha scritto:
> On Sat, 2006-01-28 at 00:17 +0100, Luca Piccarreta wrote:
>   
>> 1) NAT in itself (just address translation)-> not a big problem
>> 2) "endpoint-independent  filtering" -> not a big problem
>> 3) "endpoint-dependent filtering" ->big trouble for Kademlia.
>>     
>
> FWIW, many major vendors refuse to implement anything other than #3.
> There may still be vendors that are willing to consider #2 advertising
> "application transparency", but a majority of the NATs are going to have
> the more stringent setting #3. 
>
> The RFC does not prefer one over the other; developers clearly prefer
> #2, vendors prefer #3 [NAT-RFC]. In fact, #3-type NATs already
> outnumbers #2-type NATs by a factor of 16! [TCP-NAT]
>
> Furthermore as more and more applications become NAT-aware; "application
> transparency" will become an increasingly thin ground for vendors to
> compete on. I would expect the proportion of #3-NATs to increase beyond
> the 94% mark from last year.
>
> [NAT-RFC]
> http://www.ietf.org/internet-drafts/draft-ietf-behave-nat-udp-04.txt
>
> [TCP-NAT] http://nutss.gforge.cis.cornell.edu/pub/imc05-tcpnat/
>
> cheers,
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers at zgp.org
> http://zgp.org/mailman/listinfo/p2p-hackers
> _______________________________________________
> Here is a web page listing P2P Conferences:
> http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences
>