We been doing this at Vonage since 2001. This was our "secrete sauce", since at the time there wasn't a well documented or an industry standard on how to do this. Eventually SIP through NAT papers and RFC's did appear, but we already had our way of doing it that was just as effective.<p>We found that renewing the NAT entry at a rate of once per 20 seconds was good enough. This made it work through all the routers and gateways we came across.<p>EDIT: SIP is short for Session Initiation Protocol. Its the protocol used to connect VOIP phone calls. We used UDP. SIP's standard port is 5060 and 5061. We had to switch to port 10,000 (any port other than the standard) because too many high end routers and gateways would manipulate our packets. These routers were trying to implement SIP through NAT on their own. I applauded their efforts but it caused problems for us. I still remember the day that I took it upon myself to change production to use port 10,000. I was really scared I was going to break something but everything worked out in the end.
Strange to see this relatively old article appear. NATs are still with us. The main progress has been WebRTC. Otherwise, researcher who looked at TCP at the time (e.g., stunt) for simiulataneous TCP Syn packets failed. It was too hard to synchronize timing.
Most middleware still ignores NATs and hopes it will go away (it won't). NATs are the reason REST won over CORBA et al.
I wonder why this comes up here. This is a quite old method. I think it is used in many peer-to-peer applications. I'm quite sure that Skype has used it also in the past.<p>We have also implemented that in our game OpenLieroX. We call it UDP NAT traversal if you search for it in the code.<p>Main code:
<a href="https://github.com/albertz/openlierox/" rel="nofollow">https://github.com/albertz/openlierox/</a><p>UDP master server:
<a href="https://github.com/albertz/openlierox/tree/0.59/tools/UDPMasterServer" rel="nofollow">https://github.com/albertz/openlierox/tree/0.59/tools/UDPMas...</a>
Adam Ierymenko (@api here and reddit) has a modern and concise take on NAT<p><a href="https://www.zerotier.com/blog/state-of-nat-traversal.shtml" rel="nofollow">https://www.zerotier.com/blog/state-of-nat-traversal.shtml</a>
Plug: <a href="https://github.com/selvakn/p2p-port-forward" rel="nofollow">https://github.com/selvakn/p2p-port-forward</a>
Based on <a href="https://www.zerotier.com/" rel="nofollow">https://www.zerotier.com/</a>
Keep in mind that this paper was outdated the moment it was published and announced on p2p-hackers mailing list [1].<p>It doesn't deal with the "long tail" of NAT devices that increment/decrement ports in (somewhat) predictable manner and _most importantly_ it describes hole punching as a <i>client</i>-driven process.<p>The latter is the crucial point. By tasking a dedicated (mediating) server with coordinating the punching sequence it becomes possible to time the process much more precisely and to help predictions to actually match the reality. Combined with a bit smarter port predication it brings the success rate from 80% to 95-97%... or at least it did 10 years ago when I was using this for Hamachi P2P VPN, though I suspect that very little has changed in terms of NAT type distribution since then.<p>[1] <a href="http://copilotco.com/mail-archives/p2p-hackers.2005/msg00126.html" rel="nofollow">http://copilotco.com/mail-archives/p2p-hackers.2005/msg00126...</a>
I didn't read the whole thing so maybe it's addressed, but from what I understand it sends packets to both private and public IPs of the person you want to talk to, and use the first one you get an answer from.<p>What if the private IP from the other peer is in another NAT, but in your local NAT, you have another peer with that same private IP? He would answer you, and would would establish communication with the wrong peer?<p>Probably would need an extra step to validate the peer's public IP address is also the same?
If I could piggyback on the topic here, can anyone speak to the practical usage of these (or other) techniques on mobile devices? Are there working peer-to-peer apps?
This is a wonderfully succinct description of the topic and probably the most approachable explanation I have read. Really interesting that this was written in 2005 since the concepts described form the basis of how the later WebRTC and its supporting infrastructure STUN/TURN work.<p>As brilliant a hack as hole punching is I hope someday we can move to a world of IPv6 where it is no longer necessary.
overlay network are a good solution to NAT i think, i'd say they should be anonymous but something that's just private like cjdns is pretty good too. there are some performance and latency issues to deal with, but when you overlay you don't have to wait for network operators to fix NAT.