On 2 Apr 2010, at 17:18, Dan Wing wrote: -----Original Message----- >> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On >> Behalf Of Sabahattin Gucukoglu >> Sent: Wednesday, March 31, 2010 5:43 PM >> To: ietf@ietf.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
