2

In order for two hosts behind two different NATs to be able to establish a P2P connection, they must both have each other's public endpoints (address/port). In order for each host to become aware of its own public endpoint, it can communicate with a known public server that returns to the host its public endpoint as seen by the server. See STUN (RFC5389).

In order for this mechanism to work, the NAT must consistently translate the same private endpoint to the same public endpoint regardless of the destination endpoint.

Would it be a good idea to implement a P2P application that depends on this particular NAT behavior (i.e. is it common enough)? Does Skype and/or other popular P2P applications have other fallback mechanisms?

EDIT: It looks like a NAT in which a different port is chosen per destination is called a "Symmetric NAT". In addition, some symmetric NATs increment the port number enabling a possibility of guessing the proper port.

Now I suppose the question is: Roughly what percentage of NATs are symmetric NATs, and what percentage of those use random port assignments vs. something like incrementing?

bsirang
  • 473
  • 4
  • 14
  • 1
    Google for "nat punchthrough", I think that should be right up your alley but I'm not 100% sure. – dutt Jan 25 '13 at 21:24
  • @dutt Yes thanks. That's more or less the concept. It looks like the type of NAT that would be problematic NAT is referred to as "Symmetric NAT" according to http://www.jenkinssoftware.com/raknet/manual/natpunchthrough.html – bsirang Jan 25 '13 at 22:22
  • 1
    What about using UPnP to abstract the NAT problem? – Spidey Jan 25 '13 at 22:30
  • 1
    http://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment – selbie Jan 25 '13 at 23:41
  • Here's my "in a nutshell" answer: http://stackoverflow.com/questions/8523330/programming-p2p-application/8524609#8524609 – selbie Jan 26 '13 at 00:01
  • @selbie Thanks for the link. Basically your steps reaffirm my basic approach. I'm hoping to avoid a relay fallback as well as UPnP, and with that I'm hoping that it will still work for almost 100% of configurations these days. – bsirang Jan 26 '13 at 01:10
  • @bsirang - There are scenarios that will require a relay. Primarily where both users have a "symmetric NAT". Also, corporate firewalls in which user's only connectivity is to TCP ports 80 or 443 will often require a relay that supports bridging to/from HTTP. So if you are are ok with 80-90% NAT traversal success, you can skip the relay scenario. Also, as a shameless plug, use my stun server code: www.stunprotocol.org – selbie Jan 26 '13 at 01:33
  • @selbie I am ok with not supporting environments in which outbound connectivity is blocked. Where did you get the 80-90% figure? I am hoping to get an answer on the frequency of "symmetric NATs" so that I can understand what percentage of users (not behind a corporate firewall) would be cut off. – bsirang Jan 26 '13 at 02:04
  • Symmetric NATs in the home are on the decline, but they do exist virtually as a result of a firewall scenario in the workplace. From our testing and telemetry measurements (of a well known communication product), direct connectivity was on the order of 85%. But would vary depending on the day of the week as less users ran our software from work over the weekend. – selbie Jan 26 '13 at 21:02

2 Answers2

2

You can use standard STUN/TURN/ICE protocols from IETF: http://rtcbits.blogspot.com/2012/10/what-is-ice-interactive-connectivity.html

According to Google Gtalk statistics these mechanisms solve the P2P connection without relaying traffic in 92% of the cases. https://developers.google.com/talk/libjingle/important_concepts

ggarber
  • 8,300
  • 5
  • 27
  • 32
-1

STUN can only handle 85% of the cases! TURN can handle 100% but is really expensive to use. So what to use? neither of the two

Use ICE. It is the direct combination of STUN servers and TURN servers! That way you will have 100% reliability but you will only relay on a server 15% of the traffic.

Gilles
  • 9,269
  • 4
  • 34
  • 53
Zezinho Oliveira
  • 29
  • 4