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

[Saikat Guha]

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,
-- 
Saikat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://zgp.org/pipermail/p2p-hackers/attachments/20060127/c2c1dbb9/attachment.pgp