UDP hole punching

UDP hole punching is a commonly used technique employed in network address translator (NAT) applications for maintaining User Datagram Protocol (UDP) packet streams that traverse the NAT. NAT traversal techniques are typically required for client-to-client networking applications on the Internet involving hosts connected in private networks, especially in peer-to-peer, Direct Client-to-Client (DCC) and Voice over Internet Protocol (VoIP) deployments.

UDP hole punching establishes connectivity between two hosts communicating across one or more network address translators. Typically, third party hosts on the public transit network are used to establish UDP port states that may be used for direct communications between the communicating hosts. Once port state has been successfully established and the hosts are communicating, port state may be maintained by either normal communications traffic, or in the prolonged absence thereof, by so-called keep-alive packets, usually consisting of empty UDP packets or packets with minimal non-intrusive content.

Overview

UDP hole punching is a method for establishing bidirectional UDP connections between Internet hosts in private networks using network address translators. The technique is not applicable in all scenarios or with all types of NATs, as NAT operating characteristics are not standardized.

Hosts with network connectivity inside a private network connected via a NAT to the Internet typically use the Session Traversal Utilities for NAT (STUN) method or Interactive Connectivity Establishment (ICE) to determine the public address of the NAT that its communications peers require. In this process another host on the public network is used to establish port mapping and other UDP port state that is assumed to be valid for direct communication between the application hosts. Since UDP state usually expires after short periods of time in the range of tens of seconds to a few minutes, and the UDP port is closed in the process, UDP hole punching employs the transmission of periodic keep-alive packets, each renewing the life-time counters in the UDP state machine of the NAT.

UDP hole punching will not work with symmetric NAT devices (also known as bi-directional NAT) which tend to be found in large corporate networks. In symmetric NAT, the NAT's mapping associated with the connection to the well known STUN server is restricted to receiving data from the well-known server, and therefore the NAT mapping the well-known server sees is not useful information to the endpoint.

In a somewhat more elaborate approach both hosts will start sending to each other, using multiple attempts. On a Restricted Cone NAT, the first packet from the other host will be blocked. After that the NAT device has a record of having sent a packet to the other machine, and will let any packets coming from this IP address and port number through. This technique is widely used in peer-to-peer software and Voice over Internet Protocol telephony. It can also be used to assist the establishment of virtual private networks operating over UDP. The same technique is sometimes extended to Transmission Control Protocol (TCP) connections, with less success due to the fact that TCP connection streams are controlled by the host OS, not the application, and sequence numbers are selected randomly; thus any NAT device that performs sequence number checking will not consider the packets to be associated with an existing connection and drop them.

Flow

Let A and B be the two hosts, each in its own private network; NA and NB are the two NAT devices with globally reachable IP addresses EIPA and EIPB respectively; S is a public server with a well-known globally reachable IP address.

  1. A and B each begin a UDP conversation with S; the NAT devices NA and NB create UDP translation states and assign temporary external port numbers EPA and EPB
  2. S examines the UDP packets to get the source port used by NA and NB (the external NAT ports EPA and EPB)
  3. S passes EIPA:EPA to B and EIPB:EPB to A
  4. A sends a packet to EIPB:EPB.
  5. NA examines A's packet and creates the following tuple in its translation table: {Source-IP-A, EPA, EIPB, EPB}
  6. B sends a packet to EIPA:EPA
  7. NB examines B's packet and creates the following tuple in its translation table: {Source-IP-B, EPB, EIPA, EPA}
  8. Depending on the state of NA's translation table when B's first packet arrives (i.e. whether the tuple {Source-IP-A, EPA, EIPB, EPB} has been created by the time of arrival of B's first packet), B's first packet is dropped (no entry in translation table) or passed (entry in translation table has been made).
  9. Depending on the state of NB's translation table when A's first packet arrives (i.e. whether the tuple {Source-IP-B, EPB, EIPA, EPA} has been created by the time of arrival of A's first packet), A's first packet is dropped (no entry in translation table) or passed (entry in translation table has been made).
  10. At worst, the second packet from A reaches B; at worst the second packet from B reaches A. Holes have been "punched" in the NAT and both hosts can communicate.

See also

References

External links

This article is issued from Wikipedia - version of the Tuesday, February 02, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.