> -----Original Message----- > From: Sabahattin Gucukoglu [mailto:m...@sabahattin-gucukoglu.com] > Sent: Friday, April 02, 2010 9:48 AM > To: Dan Wing > Cc: ietf@ietf.org > Subject: Re: NAT Traversal With ICMP Replies > > 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.
Not sure what you mean by 'peer-mediated communications'. > It should > even work for DSLite deployment since the NATs are upstream. As written, pwnat won't work for a large shared NAT, because all of the pwnat 'servers' are sending ICMP queries using the same 3.3.3.3 address. To make pwnat work in such an environment, each pwnat 'server' would have to choose its own, non-colliding IP address to send its ICMP queries to, and the pwnat client would need to be told that IP address (and also the pwnat's publicly-visible IP address). -d _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
