Original copyright: Copyright (c) The Internet Society (2003) .all Rights Reserved. Original address: http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt translation copyright declaration: please reference The author or website of this article indicates: http://blog.9cbs.Net/hxhbluestar to respect the translator's labor results!
3.3.3. Peers Separated by Multiple Nats client is behind multi-layer NAT, respectively
In some topologies involving multiple NAT devices, it is not possible for two clients to establish an "optimal" P2P route between them without specific knowledge of the topology. Consider for example the following situation.
There is a multi-layer NAT device in some network topology. If you are not familiar with the knowledge of the network topology, you must create a "ideal" end connection is basically impossible. Let's take a look at this situation:
Suppose NAT X is a large industrial NAT deployed by an internet service provider (ISP) to multiplex many customers onto a few public IP addresses, and NATs A and B are small consumer NAT gateways deployed independently by two of the ISP's customers to multiplex their private home networks onto respective ISP-provided IP addresses Only server S and NAT X have globally routable IP addresses their;. the "public" IP addresses used by NAT A and NAT B are actually private to the ISP's addressing realm, while client A's and B's Addresses in Turn Are Private To The Addressing Realms of Nat a and b, respectively.
Each Client Initiates An Outgoing Connection To Server S AS Before, Causeing Nats A and B Each To Create A Single Public / Private Translation, And Causeing Nat x To Establish a Public / Private Translation for Each Session.
If NAT X is a large industrial NAT configured by Internet Service Providers (ISP), it uses a small amount of public IP address to provide services for some customer base; Nat A and Nat B are two customer base for ISP. A small-sized independent NAT gateway configured, providing IP addresses for private home networks of their own customer bases. Only Server S and NAT X have a public network fixed IP address, and Nat A and Nat B have the "public" IP address of the ISP actually "private" for ISP's addressing domain. At this time, the address of Client A For Nat A address field is "private", Client B's address is also "private" for NAT B's addressing domain. Still with previous, each client has established a "out" connection to server S, causing NATA and NAT B to make a public / private conversion, and cause NAT X to establish a public / private / private Conversion. (That is to convert private addresses into the process of public network, NAT's essential work)
Now suppose clients A and B attempt to establish a direct peer-to- peer UDP connection. The optimal method would be for client A to send messages to client B's public address at NAT B, 192.168.1.2:31000 in the ISP's addressing realm, and for client B to send messages to A's public address at NAT B, namely 192.168.1.1:30000. Unfortunately, A and B have no way to learn these addresses, because server S only sees the "global" public addresses of the clients, 155.99.25.11:62000 and 155.99.25.11:62001.Even if A and B had some way to learn these addresses, there is still no guarantee that they would be usable because the address assignments in the ISP's private addressing realm might conflict with unrelated address assignments in the clients' private realms. The clients therefore have no choice but to use their global public addresses as seen by S for their P2P communication, and rely on NAT X to provide loopback translation.
Let us now assume that Client A and Client B want to create a close-end UDP directly connected. The ideal method should be that the client A sends a message to Client B On the NAT B's public address 192.168.1.2:31000, this address is in the address domain of ISP; and the Client B also sends a message to Client a in NAT B On the public network address, that is, 192.168.1.1:30000; if you can send this, the problem is solved. Unfortunately, Client A and Client B will not know this address of the other party at all, because Server S only records their true public network address 155.99.25.11:62000 and 155.99.25.11:62001. Even if Client A and Client B have known these addresses, they cannot guarantee that this can be called because these addresses are allocated by ISP's private addressing domain, which may be allocated by private domains. Unrelated client address conflicts Therefore, if you want to perform end-to-end communication between the client, don't choose, you can only do it through their true public network address; and NAT X must support "loopback translation". Row. 3.3.4. Consistent port bindings Keep port binding
The hole punching technique has one main caveat: it works only if both NATs are cone NATs (or non-NAT firewalls), which maintain a consistent port binding between a given (private IP, private UDP) pair and a (public IP, public UDP) pair for as long as that UDP port is in use. Assigning a new public port for each new session, as a symmetric NAT does, makes it impossible for a UDP application to reuse an already-established translation for communication with different external destinations . Since cone NATs are the most widespread, the UDP hole punching technique is fairly broadly applicable; nevertheless a substantial fraction of deployed NATs are symmetric and do not support the technique.
There is a little more important when using "UDP Cole Technology": it can only work in both NAT (or simply no nat); these NAT remains in use in its own public network UDP port. Holding the binding of ports - [Private IP, Private UDP Port] Pairs of [Public IP, Public UDP Port]. If each new session is assigned a new public port like Symmetricnat, the UDP application wants to talk to other external clients, which cannot be repeatedly used to establish a good communication conversion.
With the promotion of CONE NAT, "UDP Covered Technology" is also increasingly widely used. However, there is still a small part of the network using Symmetric Nat, so in this small part of the network environment, "UDP hole technology" cannot be used.
