Principles of UDP Holes

Finally, I found a satisfactory explanation of UDP punching principle, attached the text, and sorted out the source code.

3.3. UDP hole punching UDP Punching Technology

The third technique, and the one of primary interest in this document, is widely known as "UDP hole punching. "UDP hole punching relies on the properties of common firewalland cone NATs to allow appropriately designed peer-to-peer applications to" punch holes "through the Middlebox and establish direct connectivity with each other, even when both communicating hosts may lie behind middleboxes. this technique was mentioned briefly in section 5.1 of RFC 3027 [NAT-PROT], and has been informally described elsewhere on the Internet [Kegel] and used in some recent protocols [Teredo, Ice]. as the name implies, unfortunately, this technique works reliably only with UDP.

 

The third technology, which is also to be studied in this article, is the famous "UDP hole-hitting technology". The UDP hole-hitting technology relies on public firewalls and cone Nat, allow appropriate and planned end-to-end applications to "hole" through NAT, even if both hosts are behind Nat. This technology is introduced in section 5.1 [Nat Prot] of rfc3027, and informal descriptions are made in Internet [Kegel], and some latest protocols are also applied, for example, in the [Teredo, Ice] Protocol. However, we should note that, as its name is, the reliability of UDP Punching Technology depends on UDP.

 

We will consider two specific scenarios, and how applications can be designed to handle both of them gracefully. in the first situation, representing the common case, two clients desiring direct peer-to-peer communication reside behind two different NATs. in the second, the two clients actually reside behind the same Nat, but do not necessarily know that they do.

 

Here we will consider two typical scenarios to introduce how applications on both sides of the connection communicate as planned. In the first scenario, we assume that both clients are in different NAT scenarios; in the second scenario, we assume that both clients are in the same Nat, but they do not know each other (they are in the same Nat ).

 

3.3.1. Client Communication after the peers behind different NATs are in different NAT

 

Suppose clients a and B both have private IP addresses and lie behind different network address translators. the peer-to-peer application running on clients A and B and on server s each use UDP port 1234 .? A and B have each initiated UDP communication sessions with server s, causing Nat a to assign its own public UDP port 62000 FOR A's session with S, and causing Nat B to assign its port 31000 to B's session with s, respectively.

 

Assume that both client a and client B have their own private IP addresses and are running in different NAT locations. End-to-end programs run between Client A, client B, and S, and they all open UDP port 1234. Client A and client B first establish communication sessions with S. At this time, Nat a allocates its UDP port 62000 to the sessions of Client A and S, nat B also allocates its UDP port 31000 to the sessions between client B and S. As shown in:

 

Now suppose that client a wants to establish a UDP communication session directly with client B .? If a simply starts sending UDP messages to B's public address, 138.76.29.7: 31000, then Nat B will typically discard these incoming messages (unless it is a full cone Nat ), because the source address and port number does not match those of S, with which the original outgoing session was established. similarly, if B simply starts sending UDP messages to a's public address, then Nat a will typically discard these messages.

 

If Client A wants to establish a direct UDP communication connection with client B at this time, if client a simply sends a UDP message to the public address 138.76.29.7: 31000 of client B, nat B will discard this information without consideration (unless Nat B is a full cone Nat), because the address information contained in this UDP information, the address of server s stored in Nat B does not match that of client B and server S. Similarly, if client B does the same thing, UDP messages sent will also be discarded by Nat.

 

Suppose a starts sending UDP messages to B's public address, however, and simultaneously relays a request through Server s to B, asking B to start sending UDP messages to a's public address .? A's outgoing messages directed to B's Public Address (138.76.29.7: 31000) Cause Nat a to open up a new communication session between a's private address and B's public address. at the same time, B's messages to a's Public Address (155.99.25.11: 62000) cause Nat B to open up a new communication session between B's private address and a's public address. once the new UDP sessions have been opened up in each ction, Client A and B can communicate with each other directly without further burden on the "Introduction" server S.

 

If client a starts to send a UDP message to the public address of client B, and at the same time, he sends an invitation message to client B through S transit, request client B to send a UDP message to the public address of Client. The public IP address (138.76.29.7: 31000) of Client A to client B) as a result, Nat a opens a new communication session between the private address of Client A and the Public Address of client B, nat B also opens a new communication session between the private address of client B and the Public Address of Client A (155.99.25.11: 62000. Once the new UDP session is opened to the other party, the client a and client B can communicate directly without the need for S to bridge the line. (This is the so-called hole-hitting technology )!

 

The UDP hole punching technique has several useful properties. once a direct peer-to-peer UDP connection has been established between two clients behind middleboxes, either party on that connection can in turn take over the role of "introducer" and help the other party establish peer-to-peer connections with additional peers, minimizing the load on the initial introduction server S. the Application Does not need to attempt to detect explicitly what kind of Middlebox it is behind, if any [stun], since the procedure above will establish peer-to-peer communication channels equally well if either or both clients do not happen to be behind a Middlebox .? The hole punching technique even works automatically with multiple NATs, where one or both clients are removed from the public internet via two or more levels of address translation.

 

UDP punching technology has many practical aspects: First, once the direct connection between the end-to-end after Nat is established, the two sides of the connection can take turns as the "matchmaker" of the other side ", introduce the other party to other clients, which greatly reduces the workload of server S. Second, the application does not need to care whether the NAT belongs to cone or symmetric, if either or both parties are not in the NAT status, a good communication channel can be established between them based on the above-mentioned steps. Third, the Punching Technology can automatically communicate with each other after multiple Nat operations, no matter how many layers of NAT are connected to the Internet.

C # source code download