> On 2 Apr 2010, at 18:08, Dan Wing wrote: > -----Original Message----- > >> From: Sabahattin Gucukoglu [mailto:mail@xxxxxxxxxxxxxxxxxxxxxxxx] > >> Sent: Friday, April 02, 2010 9:48 AM > >> To: Dan Wing > >> Cc: ietf@xxxxxxxx > >> Subject: Re: NAT Traversal With ICMP Replies > >> On 2 Apr 2010, at 17:18, Dan Wing wrote: > >> -----Original Message----- > >>>> From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > >>>> Behalf Of Sabahattin Gucukoglu > >>>> Sent: Wednesday, March 31, 2010 5:43 PM > >>>> To: ietf@xxxxxxxx > >>>> 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'. > > Communications mediated by a peer, like STUN or TURN. It > should really be "Third-party peer-mediated communications". > It's nice to remove dependence on another peer is what I was > trying to say. I suppose. In Real Life, though, there is usually some kind of rendezvous server that is part of the game itself, the DHT to exchange peer ID's and chunk information (e.g., BitTorrent) -- which could run a STUN server. As for TURN, well, that's only needed when both peers are behind 'bad' NATs (address and port dependent filtering/mapping), and I don't know if pwnat/chownat improve upon that situation; I doubt they do (because the client doesn't know its public port number). There are other ideas floating around for DS-Lite and carrier NATs, as well, including draft-wing-softwire-port-control-protocol. > > 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). > > Of course, yes, sorry. Friday-night brain flab. Somehow I > got the idea we had the entire ICMP packet payload, but of > course we only have the headers. Would unsolicited ICMP echo > replies, containing payload, work? Dunno, seems it would depend on how paranoid the NAT is. I could imagine a NAT might only expect an ICMP echo-reply from the same IP address as the echo-request. But it is possible to send long ICMP "TTL Exceeded" messages, see Section 4.2.2.3 of RFC1812 and Section 4 of RFC4884 -- so more information can be stashed into pwnat's TTL Exceeded message. But I have been unable to engage with the author of pwnat (doesn't reply to emails), and I sincerely doubt the IETF would standardize this mechanism. That combination has reduced my personal interest in pwnat. -d _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf