On 2 Apr 2010, at 17:18, Dan Wing wrote:
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Sabahattin Gucukoglu
Sent: Wednesday, March 31, 2010 5:43 PM
To: ietf(_at_)ietf(_dot_)org
Subject: NAT Traversal With ICMP Replies
http://samy.pl/pwnat/
The idea is that NATs let back ICMP replies and send them to
hosts behind them if they suspect them to be responses to
messages sent from those hosts. So, by making the reply
fixed and having a server behind a NAT continuously sending
the ICMP query that would elicit it, a server can learn a
client's IP address, and thus begin communication without a
central rendezvous server.
An interesting idea, for sure.
Several drawbacks, though, including no provision for multiple
PWNAT devices behind the same NAT. Varying the ICMP query
address could resolve that, to some degree (modulo birthday
collisions).
It might not be super
efficient, and there's the question of whose network gets all
these ICMP messages.
http://ws.arin.net/whois/?queryinput=3.0.0.0
Yes. We could solve the worst of both problems by assigning a *small* IANA
block and arranging a blackhole for it. We only need to trigger NAT behaviour,
and we get to control the ICMP payload that should be expected. Hamachi has
nicked the 5/8 assignment, for its own use, to avoid overlapping private spaces
(they aren't routed, of course, it's just for the communicating nodes on the
UDP-encapsulated, NAT-traversing network).
Although I'm absolutely no fan of NAT, I can't help thinking this little
technique might just help some, considering the only alternative is
peer-mediated communications. It should even work for DSLite deployment since
the NATs are upstream.
Cheers,
Sabahattin
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf