So basically here I am, opening a connection to the publicly accessible S. The router sees it and says oh wow, there's an out going connection to S_IP:S_PORT, I'll assign an R_PORT to it on my publicly visible side and will forward all traffic from S_IP:S_PORT to my internal network client.
But how does that help someone who is not S (has a different IP than S) to use this tunnel set up by router? It (R - router on the NAT) won't ignore the source IP of incoming packets (since two connections are the same only if source and destination IPs and ports are the same - 4 numbers), will it? Traffic coming from S will get forwarded, that I get, but will traffic from ANY source just coming to the appropriate port on R get forwarded just the same way?
You are right but your logic works in tcp connections, that why the method named "udp hole punching", in udp there is no handshake that means i can send you a udp packet looks like it's coming from S_IP:S_PORT.
It's a good paper for anyone starting up with the NAT traversal, but it missed few things even when it first came out, so just make sure to read more on the subject if you're actually implementing the UDP/TCP punching.
I spent 2 years on a cross platform p2p protocol with features borrowed from GameCom, RakNet, Zoidcom and the Torque Network Library (TNL). I failed, largely due to the complexity of overcoming NAT. This was before ZeroMQ and other libs made it easy to emulate TCP traffic on top of UDP (which IMHO is the way it should have worked in the first place).
What concerns me most is that IPv6 supports NAT and so I have a feeling that we will be living with it for decades to come (effectively making large swaths of the population second class citizens, as they will perceive the internet as download-only).
Does anyone know of a library that universally overcomes NAT, using STUN/UPnP/NAT-PMP and other techniques where necessary? Ideally it would work by handling the handshake and return a standard UDP port that "just works", giving the app a globally accessible public port.
But how does that help someone who is not S (has a different IP than S) to use this tunnel set up by router? It (R - router on the NAT) won't ignore the source IP of incoming packets (since two connections are the same only if source and destination IPs and ports are the same - 4 numbers), will it? Traffic coming from S will get forwarded, that I get, but will traffic from ANY source just coming to the appropriate port on R get forwarded just the same way?
Good paper.