Network Working Group P. Srisuresh
Request for Comments: 5128 Kazeon Systems
Category: Informational B. Ford
M.I.T.
D. Kegel
kegel.com
March 2008
Network Working Group P. Srisuresh
Request for Comments: 5128 Kazeon Systems
Category: Informational B. Ford
M.I.T.
D. Kegel
kegel.com
March 2008
State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)
跨网络地址转换器（NAT）的对等（P2P）通信状态
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Abstract
摘要
This memo documents the various methods known to be in use by applications to establish direct communication in the presence of Network Address Translators (NATs) at the current time. Although this memo is intended to be mainly descriptive, the Security Considerations section makes some purely advisory recommendations about how to deal with security vulnerabilities the applications could inadvertently create when using the methods described. This memo covers NAT traversal approaches used by both TCP- and UDP-based applications. This memo is not an endorsement of the methods described, but merely an attempt to capture them in a document.
本备忘录记录了目前应用程序在网络地址转换器（NAT）存在的情况下建立直接通信所使用的各种方法。尽管本备忘录主要是描述性的，但安全注意事项部分就如何处理应用程序在使用所述方法时可能无意中产生的安全漏洞提出了一些纯粹的建议。本备忘录涵盖了基于TCP和UDP的应用程序所使用的NAT遍历方法。本备忘录并非对所述方法的认可，而只是试图将其记录在文档中。
Table of Contents
目录
1. Introduction and Scope ..........................................3
2. Terminology and Conventions Used ................................4
2.1. Endpoint ...................................................5
2.2. Endpoint Mapping ...........................................5
2.3. Endpoint-Independent Mapping ...............................5
2.4. Endpoint-Dependent Mapping .................................5
2.5. Endpoint-Independent Filtering .............................6
2.6. Endpoint-Dependent Filtering ...............................6
2.7. P2P Application ............................................7
2.8. NAT-Friendly P2P Application ...............................7
2.9. Endpoint-Independent Mapping NAT (EIM-NAT) .................7
2.10. Hairpinning ...............................................7
3. Techniques Used by P2P Applications to Traverse NATs ............7
3.1. Relaying ...................................................8
3.2. Connection Reversal ........................................9
3.3. UDP Hole Punching .........................................11
3.3.1. Peers behind Different NATs ........................12
3.3.2. Peers behind the Same NAT ..........................14
3.3.3. Peers Separated by Multiple NATs ...................16
3.4. TCP Hole Punching .........................................18
3.5. UDP Port Number Prediction ................................19
3.6. TCP Port Number Prediction ................................21
4. Recent Work on NAT Traversal ...................................22
5. Summary of Observations ........................................23
5.1. TCP/UDP Hole Punching .....................................23
5.2. NATs Employing Endpoint-Dependent Mapping .................23
5.3. Peer Discovery ............................................24
5.4. Hairpinning ...............................................24
6. Security Considerations ........................................24
6.1. Lack of Authentication Can Cause Connection Hijacking .....24
6.2. Denial-of-Service Attacks .................................25
6.3. Man-in-the-Middle Attacks .................................26
6.4. Security Impact from EIM-NAT Devices ......................26
7. Acknowledgments ................................................27
8. References .....................................................27
8.1. Normative References ......................................27
8.2. Informative References ....................................27
1. Introduction and Scope ..........................................3
2. Terminology and Conventions Used ................................4
2.1. Endpoint ...................................................5
2.2. Endpoint Mapping ...........................................5
2.3. Endpoint-Independent Mapping ...............................5
2.4. Endpoint-Dependent Mapping .................................5
2.5. Endpoint-Independent Filtering .............................6
2.6. Endpoint-Dependent Filtering ...............................6
2.7. P2P Application ............................................7
2.8. NAT-Friendly P2P Application ...............................7
2.9. Endpoint-Independent Mapping NAT (EIM-NAT) .................7
2.10. Hairpinning ...............................................7
3. Techniques Used by P2P Applications to Traverse NATs ............7
3.1. Relaying ...................................................8
3.2. Connection Reversal ........................................9
3.3. UDP Hole Punching .........................................11
3.3.1. Peers behind Different NATs ........................12
3.3.2. Peers behind the Same NAT ..........................14
3.3.3. Peers Separated by Multiple NATs ...................16
3.4. TCP Hole Punching .........................................18
3.5. UDP Port Number Prediction ................................19
3.6. TCP Port Number Prediction ................................21
4. Recent Work on NAT Traversal ...................................22
5. Summary of Observations ........................................23
5.1. TCP/UDP Hole Punching .....................................23
5.2. NATs Employing Endpoint-Dependent Mapping .................23
5.3. Peer Discovery ............................................24
5.4. Hairpinning ...............................................24
6. Security Considerations ........................................24
6.1. Lack of Authentication Can Cause Connection Hijacking .....24
6.2. Denial-of-Service Attacks .................................25
6.3. Man-in-the-Middle Attacks .................................26
6.4. Security Impact from EIM-NAT Devices ......................26
7. Acknowledgments ................................................27
8. References .....................................................27
8.1. Normative References ......................................27
8.2. Informative References ....................................27
The present-day Internet has seen ubiquitous deployment of Network Address Translators (NATs). There are a variety of NAT devices and a variety of network topologies utilizing NAT devices in deployments. The asymmetric addressing and connectivity regimes established by these NAT devices have created unique problems for peer-to-peer (P2P) applications and protocols, such as teleconferencing and multiplayer online gaming. These issues are likely to persist even into the IPv6 world. During the transition to IPv6, some form of NAT may be required to enable IPv4-only nodes to communicate with IPv6-only nodes [NAT-PT], although the appropriate protocols and guidelines for this use of NAT are still unresolved [NAT-PT-HIST]. Even a future "pure IPv6 world" may still include firewalls, which employ similar filtering behavior of NATs but without the address translation [V6-CPE-SEC]. The filtering behavior interferes with the functioning of P2P applications. For this reason, IPv6 applications that use the techniques described in this document for NAT traversal may also work with some firewalls that have filtering behavior similar to NATs.
在当今的互联网上，网络地址转换器（NAT）的部署无处不在。有多种NAT设备和各种网络拓扑在部署中使用NAT设备。这些NAT设备建立的非对称寻址和连接机制为对等（P2P）应用程序和协议（如电话会议和多人在线游戏）带来了独特的问题。这些问题甚至可能持续到IPv6世界。在过渡到IPv6的过程中，可能需要某种形式的NAT，以使仅IPv4的节点能够与仅IPv6的节点通信[NAT-PT]，尽管有关NAT使用的适当协议和指南尚未解决[NAT-PT-HIST]。即使是未来的“纯IPv6世界”也可能包括防火墙，防火墙采用与NAT类似的过滤行为，但没有地址转换[V6-CPE-SEC]。过滤行为会干扰P2P应用程序的功能。因此，使用本文档中描述的NAT穿越技术的IPv6应用程序也可以与某些具有类似于NAT过滤行为的防火墙一起工作。
Currently deployed NAT devices are designed primarily around the client/server paradigm, in which relatively anonymous client machines inside a private network initiate connections to public servers with stable IP addresses and DNS names. NAT devices encountered en route provide dynamic address assignment for the client machines. The illusion of anonymity (private IP addresses) and inaccessibility of the internal hosts behind a NAT device is not a problem for applications such as Web browsers, which only need to initiate outgoing connections. This illusion of anonymity and inaccessibility is sometimes perceived as a privacy benefit. As noted in Section 2.2 of [RFC4941], this perceived privacy may be illusory in a majority of cases utilizing Small-Office-Home-Office (SOHO) NATs.
目前部署的NAT设备主要是围绕客户机/服务器模式设计的，在这种模式中，私有网络中相对匿名的客户机启动到具有稳定IP地址和DNS名称的公共服务器的连接。路由过程中遇到的NAT设备为客户端计算机提供动态地址分配。NAT设备背后的匿名性（私有IP地址）和内部主机不可访问的假象对于Web浏览器等只需要启动传出连接的应用程序来说不是问题。这种匿名和不可接近的幻觉有时被视为隐私利益。如[RFC4941]第2.2节所述，在大多数使用小型办公室-家庭办公室（SOHO）NAT的情况下，这种感知隐私可能是虚幻的。
In the peer-to-peer paradigm, Internet hosts that would normally be considered "clients" not only initiate sessions to peer nodes, but also accept sessions initiated by peer nodes. The initiator and the responder might lie behind different NAT devices with neither endpoint having a permanent IP address or other form of public network presence. A common online gaming architecture, for example, involves all participating application hosts contacting a publicly addressable rendezvous server for registering themselves and discovering peer hosts. Subsequent to the communication with the rendezvous server, the hosts establish direct connections with each other for fast and efficient propagation of updates during game play. Similarly, a file sharing application might contact a well-known rendezvous server for resource discovery or searching, but establish direct connections with peer hosts for data transfer. NAT devices create problems for peer-to-peer connections because hosts behind a
在对等模式中，通常被视为“客户端”的Internet主机不仅向对等节点发起会话，而且还接受对等节点发起的会话。发起方和响应方可能位于不同的NAT设备后面，并且端点都没有永久IP地址或其他形式的公共网络存在。例如，一个常见的在线游戏体系结构涉及所有参与的应用程序主机联系一个可公开寻址的集合服务器，以注册自己并发现对等主机。在与会合服务器通信之后，主机彼此建立直接连接，以便在游戏过程中快速有效地传播更新。类似地，文件共享应用程序可能会联系知名的集合服务器以进行资源发现或搜索，但会与对等主机建立直接连接以进行数据传输。NAT设备为对等连接造成问题，因为主机位于
NAT device normally have no permanently visible public ports on the Internet to which incoming TCP or UDP connections from other peers can be directed. RFC 3235 [NAT-APPL] briefly addresses this issue.
NAT设备在Internet上通常没有永久可见的公共端口，其他对等方的传入TCP或UDP连接可以指向这些端口。RFC 3235[NAT-APPL]简要介绍了这个问题。
NAT traversal strategies that involve explicit signaling between applications and NAT devices, namely [NAT-PMP], [NSIS-NSLP], [SOCKS], [RSIP], [MIDCOM], and [UPNP] are out of the scope of this document. These techniques, if available, are a complement to the techniques described in the document. [UNSAF] is in scope.
涉及应用程序和NAT设备之间显式信令的NAT穿越策略，即[NAT-PMP]、[NSIS-NSLP]、[SOCKS]、[RSIP]、[MIDCOM]和[UPNP]，不在本文档范围内。这些技术（如果可用）是对文档中描述的技术的补充。[UNSAF]在范围内。
In this document, we summarize the currently known methods by which applications work around the presence of NAT devices, without directly altering the NAT devices. The techniques described predate BEHAVE documents ([BEH-UDP], [BEH-TCP], and [BEH-ICMP]). The scope of the document is restricted to describing currently known techniques used to establish 2-way communication between endpoints of an application. Discussion of timeouts, RST processing, keepalives, and so forth that concern a running session are outside the scope of this document. The scope is also restricted to describing techniques for TCP- and UDP-based applications. It is not the objective of this document to provide solutions to NAT traversal problems for applications in general [BEH-APP] or to a specific class of applications [ICE].
在本文档中，我们总结了当前已知的方法，通过这些方法，应用程序可以在不直接改变NAT设备的情况下绕过NAT设备。所描述的技术早于BEH-UDP、[BEH-TCP]和[BEH-ICMP]文档。本文档的范围仅限于描述用于在应用程序的端点之间建立双向通信的当前已知技术。有关正在运行的会话的超时、RST处理、保留等的讨论超出了本文档的范围。范围还限于描述基于TCP和UDP的应用程序的技术。本文件的目的不是为一般应用[BEH-APP]或特定类别的应用[ICE]提供NAT穿越问题的解决方案。
In this document, the IP addresses 192.0.2.1, 192.0.2.128, and 192.0.2.254 are used as example public IP addresses [RFC3330]. Although these addresses are all from the same /24 network, this is a limitation of the example addresses available in [RFC3330]. In practice, these addresses would be on different networks. As for the notation for ports usage, all clients use ports in the range of 1-2000 and servers use ports in the range of 20000-21000. NAT devices use ports 30000 and above for endpoint mapping.
在本文档中，IP地址192.0.2.1、192.0.2.128和192.0.2.254用作示例公共IP地址[RFC3330]。尽管这些地址都来自同一个/24网络，但这是[RFC3330]中可用示例地址的限制。实际上，这些地址将位于不同的网络上。至于端口使用的表示法，所有客户端使用的端口范围为1-2000，服务器使用的端口范围为20000-21000。NAT设备使用端口30000及以上进行端点映射。
Readers are urged to refer to [NAT-TERM] for information on NAT taxonomy and terminology. Unless prefixed with a NAT type or explicitly stated otherwise, the term NAT, used throughout this document, refers to Traditional NAT [NAT-TRAD]. Traditional NAT has two variations, namely, Basic NAT and Network Address Port Translator (NAPT). Of these, NAPT is by far the most commonly deployed NAT device. NAPT allows multiple private hosts to share a single public IP address simultaneously.
请读者参考[NAT-TERM]了解NAT分类和术语的信息。除非以NAT类型作为前缀或另有明确说明，否则本文档中使用的术语NAT指传统NAT[NAT-TRAD]。传统的NAT有两种变体，即基本NAT和网络地址端口转换器（NAPT）。其中，NAPT是目前最常用的NAT设备。NAPT允许多个私有主机同时共享一个公共IP地址。
An issue of relevance to P2P applications is how the NAT behaves when an internal host initiates multiple simultaneous sessions from a single endpoint (private IP, private port) to multiple distinct endpoints on the external network.
与P2P应用程序相关的一个问题是，当内部主机从单个端点（专用IP、专用端口）向外部网络上的多个不同端点同时发起多个会话时，NAT的行为如何。
[STUN] further classifies NAT implementations using the terms "Full Cone", "Restricted Cone", "Port Restricted Cone", and "Symmetric". Unfortunately, this terminology has been the source of much confusion. For this reason, this document adapts terminology from [BEH-UDP] to distinguish between NAT implementations.
[STUN]使用术语“全锥”、“受限锥”、“端口受限锥”和“对称”对NAT实现进行了进一步分类。不幸的是，这个术语一直是许多混乱的根源。因此，本文档采用[BEH-UDP]中的术语来区分NAT实现。
Listed below are terms used throughout this document.
下文列出了本文件中使用的术语。
An endpoint is a session-specific tuple on an end host. An endpoint may be represented differently for each IP protocol. For example, a UDP or TCP session endpoint is represented as a tuple of (IP address, UDP/TCP port).
端点是终端主机上特定于会话的元组。对于每个IP协议，端点可以不同地表示。例如，UDP或TCP会话端点表示为（IP地址、UDP/TCP端口）的元组。
When a host in a private realm initiates an outgoing session to a host in the public realm through a NAT device, the NAT device assigns a public endpoint to translate the private endpoint so that subsequent response packets from the external host can be received by the NAT, translated, and forwarded to the private endpoint. The assignment by the NAT device to translate a private endpoint to a public endpoint and vice versa is called Endpoint Mapping. NAT uses Endpoint Mapping to perform translation for the duration of the session.
当私有领域中的主机通过NAT设备向公共领域中的主机发起传出会话时，NAT设备分配一个公共端点来翻译私有端点，以便NAT可以接收、翻译来自外部主机的后续响应数据包，并将其转发到私有端点。NAT设备将私有端点转换为公共端点，反之亦然的分配称为端点映射。NAT使用端点映射在会话期间执行转换。
"Endpoint-Independent Mapping" is defined in [BEH-UDP] as follows:
“端点独立映射”在[BEH-UDP]中定义如下：
The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to any external IP address and port.
NAT对从相同的内部IP地址和端口（X:X）发送到任何外部IP地址和端口的后续数据包重用端口映射。
"Endpoint-Dependent Mapping" refers to the combination of "Address-Dependent Mapping" and "Address and Port-Dependent Mapping" as defined in [BEH-UDP]:
“端点相关映射”是指[BEH-UDP]中定义的“地址相关映射”和“地址和端口相关映射”的组合：
Address-Dependent Mapping
地址相关映射
The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external IP address, regardless of the external port.
NAT对从相同的内部IP地址和端口（X:X）发送到相同的外部IP地址的后续数据包重用端口映射，而不考虑外部端口。
Address and Port-Dependent Mapping
地址和端口相关映射
The NAT reuses the port mapping for subsequent packets sent from the same internal IP address and port (X:x) to the same external IP address and port while the mapping is still active.
当映射仍处于活动状态时，NAT会对从相同的内部IP地址和端口（X:X）发送到相同的外部IP地址和端口的后续数据包重用端口映射。
"Endpoint-Independent Filtering" is defined in [BEH-UDP] as follows:
[BEH-UDP]中对“端点独立过滤”的定义如下：
The NAT filters out only packets not destined to the internal address and port X:x, regardless of the external IP address and port source (Z:z). The NAT forwards any packets destined to X:x. In other words, sending packets from the internal side of the NAT to any external IP address is sufficient to allow any packets back to the internal endpoint.
无论外部IP地址和端口源（Z:Z）如何，NAT都只过滤出没有发送到内部地址和端口X:X的数据包。NAT转发任何目的地为X:X的数据包。换句话说，将数据包从NAT的内部发送到任何外部IP地址足以允许任何数据包返回到内部端点。
A NAT device employing the combination of "Endpoint-Independent Mapping" and "Endpoint-Independent Filtering" will accept incoming traffic to a mapped public port from ANY external endpoint on the public network.
采用“端点独立映射”和“端点独立过滤”组合的NAT设备将接受来自公共网络上任何外部端点到映射公共端口的传入流量。
"Endpoint-Dependent Filtering" refers to the combination of "Address-Dependent Filtering" and "Address and Port-Dependent Filtering" as defined in [BEH-UDP].
“端点相关过滤”是指[BEH-UDP]中定义的“地址相关过滤”和“地址和端口相关过滤”的组合。
Address-Dependent Filtering
地址相关过滤
The NAT filters out packets not destined to the internal address X:x. Additionally, the NAT will filter out packets from Y:y destined for the internal endpoint X:x if X:x has not sent packets to Y:any previously (independently of the port used by Y). In other words, for receiving packets from a specific external endpoint, it is necessary for the internal endpoint to send packets first to that specific external endpoint's IP address.
NAT过滤掉没有发送到内部地址X:X的数据包。此外，如果X:X之前没有向Y:any发送数据包（独立于Y使用的端口），则NAT将从Y:Y中过滤出发送给内部端点X:X的数据包。换句话说，为了从特定外部端点接收数据包，内部端点必须首先将数据包发送到该特定外部端点的IP地址。
Address and Port-Dependent Filtering
地址和端口相关过滤
The NAT filters out packets not destined for the internal address X:x. Additionally, the NAT will filter out packets from Y:y destined for the internal endpoint X:x if X:x has not sent packets to Y:y previously. In other words, for receiving packets from a specific external endpoint, it is necessary for the internal endpoint to send packets first to that external endpoint's IP address and port.
NAT过滤掉没有发送到内部地址X:X的数据包。此外，如果X:X之前没有向Y:Y发送数据包，则NAT将从Y:Y中过滤出发送给内部端点X:X的数据包。换句话说，为了从特定外部端点接收数据包，内部端点必须首先将数据包发送到该外部端点的IP地址和端口。
A NAT device employing "Endpoint-Dependent Filtering" will accept incoming traffic to a mapped public port from only a restricted set of external endpoints on the public network.
采用“端点相关过滤”的NAT设备将仅从公共网络上的一组受限外部端点接收到映射公共端口的传入流量。
A P2P application is an application that uses the same endpoint to initiate outgoing sessions to peering hosts as well as accept incoming sessions from peering hosts. A P2P application may use multiple endpoints for peer-to-peer communication.
P2P应用程序是一种应用程序，它使用相同的端点启动到对等主机的传出会话，以及接受来自对等主机的传入会话。P2P应用程序可以使用多个端点进行对等通信。
A NAT-friendly P2P application is a P2P application that is designed to work effectively even as peering nodes are located in distinct IP address realms, connected by one or more NATs.
NAT友好型P2P应用程序是一种P2P应用程序，其设计可有效工作，即使对等节点位于不同的IP地址域中，由一个或多个NAT连接。
One common way P2P applications establish peering sessions and remain NAT-friendly is by using a publicly addressable rendezvous server for registration and peer discovery purposes.
P2P应用程序建立对等会话并保持NAT友好的一种常见方式是使用可公开寻址的集合服务器进行注册和对等发现。
An Endpoint-Independent Mapping NAT (EIM-NAT, for short) is a NAT device employing Endpoint-Independent Mapping. An EIM-NAT can have any type of filtering behavior. BEHAVE-compliant NAT devices are good examples of EIM-NAT devices. A NAT device employing Address-Dependent Mapping is an example of a NAT device that is not EIM-NAT.
端点无关映射NAT（简称EIM-NAT）是采用端点无关映射的NAT设备。EIM-NAT可以具有任何类型的过滤行为。行为兼容NAT设备是EIM-NAT设备的好例子。采用地址相关映射的NAT设备是非EIM-NAT的NAT设备的示例。
Hairpinning is defined in [BEH-UDP] as follows:
发夹在[BEH-UDP]中定义如下：
If two hosts (called X1 and X2) are behind the same NAT and exchanging traffic, the NAT may allocate an address on the outside of the NAT for X2, called X2':x2'. If X1 sends traffic to X2':x2', it goes to the NAT, which must relay the traffic from X1 to X2. This is referred to as hairpinning.
如果两台主机（称为X1和X2）位于同一NAT后面并交换流量，则NAT可以在NAT外部为X2分配一个地址，称为X2'：X2'。如果X1将流量发送到X2'：X2'，它将发送到NAT，NAT必须将流量从X1中继到X2。这被称为发夹。
Not all currently deployed NATs support hairpinning.
并非所有当前部署的NAT都支持发夹。
This section reviews in detail the currently known techniques for implementing peer-to-peer communication over existing NAT devices, from the perspective of the application or protocol designer.
本节从应用程序或协议设计者的角度详细回顾了当前已知的用于在现有NAT设备上实现对等通信的技术。
The most reliable, but least efficient, method of implementing peer-to-peer communication in the presence of a NAT device is to make the peer-to-peer communication look to the network like client/server communication through relaying. Consider the scenario in figure 1. Two client hosts, A and B, have each initiated TCP or UDP connections to a well-known rendezvous server S. The Rendezvous Server S has a publicly addressable IP address and is used for the purposes of registration, discovery, and relay. Hosts behind NAT register with the server. Peer hosts can discover hosts behind NATs and relay all end-to-end messages using the server. The clients reside on separate private networks, and their respective NAT devices prevent either client from directly initiating a connection to the other.
在存在NAT设备的情况下实现对等通信的最可靠但效率最低的方法是通过中继使对等通信看起来像客户端/服务器通信一样。考虑图1中的场景。两台客户端主机A和B分别启动了到知名集合服务器S的TCP或UDP连接。集合服务器S具有可公开寻址的IP地址，用于注册、发现和中继。NAT后面的主机向服务器注册。对等主机可以发现NAT后面的主机，并使用服务器中继所有端到端消息。客户端驻留在单独的专用网络上，它们各自的NAT设备阻止任一客户端直接启动与另一客户端的连接。
Registry, Discovery
Combined with Relay
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry/ ^ ^ Registry/ ^ |
| | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
+--------------+ +--------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| NAT A | | NAT B |
+--------------+ +--------------+
| |
| ^ Registry/ ^ ^ Registry/ ^ |
| | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Registry, Discovery
Combined with Relay
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry/ ^ ^ Registry/ ^ |
| | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
+--------------+ +--------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| NAT A | | NAT B |
+--------------+ +--------------+
| |
| ^ Registry/ ^ ^ Registry/ ^ |
| | Relay-Req Session(A-S) | | Relay-Req Session(B-S) | |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 1: Use of a Relay Server to communicate with peers
图1：使用中继服务器与对等方通信
Instead of attempting a direct connection, the two clients can simply use the server S to relay messages between them. For example, to send a message to client B, client A simply sends the message to server S along its already established client/server connection, and server S then sends the message on to client B using its existing client/server connection with B.
这两个客户端不需要尝试直接连接，只需使用服务器在它们之间中继消息即可。例如，要向客户端B发送消息，客户端a只需将消息沿着其已建立的客户端/服务器连接发送到服务器S，然后服务器S使用其与客户端B的现有客户端/服务器连接将消息发送到客户端B。
This method has the advantage that it will always work as long as both clients have connectivity to the server. The enroute NAT device is not required to be EIM-NAT. The obvious disadvantages of relaying are that it consumes the server's processing power and network bandwidth, and communication latency between the peering clients is likely to be increased even if the server has sufficient I/O bandwidth and is located correctly topology-wise. The TURN protocol [TURN] defines a method of implementing application agnostic, session-oriented, packet relay in a relatively secure fashion.
这种方法的优点是，只要两个客户端都连接到服务器，它就会一直工作。途中NAT设备不需要是EIM-NAT。中继的明显缺点是它会消耗服务器的处理能力和网络带宽，并且即使服务器具有足够的I/O带宽并且在拓扑上正确定位，对等客户端之间的通信延迟也可能会增加。TURN协议[TURN]定义了一种以相对安全的方式实现应用程序无关、面向会话的数据包中继的方法。
The following connection reversal technique for a direct communication works only when one of the peers is behind a NAT device and the other is not. For example, consider the scenario in figure 2. Client A is behind a NAT, but client B has a publicly addressable IP address. Rendezvous Server S has a publicly addressable IP address and is used for the purposes of registration and discovery. Hosts behind a NAT register their endpoints with the server. Peer hosts discover endpoints of hosts behind a NAT using the server.
以下用于直接通信的连接反转技术仅在其中一个对等方位于NAT设备后面而另一个不在NAT设备后面时工作。例如，考虑图2中的场景。客户端A位于NAT后面，但客户端B有一个可公开寻址的IP地址。集合服务器S具有可公开寻址的IP地址，用于注册和发现。NAT后面的主机向服务器注册其端点。对等主机使用服务器发现NAT后面主机的端点。
Registry and Discovery
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:1234 | |
| |
| ^ P2P Session (A-B) ^ | P2P Session (B-A) | |
| | 192.0.2.254:1234 | | 192.0.2.1:62000 | |
| | 192.0.2.1:62000 | v 192.0.2.254:1234 v |
| |
+--------------+ |
| 192.0.2.1 | |
| | |
| NAT A | |
+--------------+ |
| |
| ^ Registry Session(A-S) ^ |
| | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | |
| |
| ^ P2P Session (A-B) ^ |
| | 192.0.2.254:1234 | |
| | 10.0.0.1:1234 | |
| |
Private Client A Public Client B
10.0.0.1:1234 192.0.2.254:1234
Registry and Discovery
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:1234 | |
| |
| ^ P2P Session (A-B) ^ | P2P Session (B-A) | |
| | 192.0.2.254:1234 | | 192.0.2.1:62000 | |
| | 192.0.2.1:62000 | v 192.0.2.254:1234 v |
| |
+--------------+ |
| 192.0.2.1 | |
| | |
| NAT A | |
+--------------+ |
| |
| ^ Registry Session(A-S) ^ |
| | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | |
| |
| ^ P2P Session (A-B) ^ |
| | 192.0.2.254:1234 | |
| | 10.0.0.1:1234 | |
| |
Private Client A Public Client B
10.0.0.1:1234 192.0.2.254:1234
Figure 2: Connection reversal using Rendezvous server
图2：使用集合服务器的连接反转
Client A has private IP address 10.0.0.1, and the application is using TCP port 1234. This client has established a connection with server S at public IP address 192.0.2.128 and port 20001. NAT A has assigned TCP port 62000, at its own public IP address 192.0.2.1, to serve as the temporary public endpoint address for A's session with S; therefore, server S believes that client A is at IP address 192.0.2.1 using port 62000. Client B, however, has its own permanent IP address, 192.0.2.254, and the application on B is accepting TCP connections at port 1234.
客户端A具有专用IP地址10.0.0.1，应用程序使用TCP端口1234。此客户端已在公共IP地址192.0.2.128和端口20001处与服务器S建立连接。NAT A已在其自己的公共IP地址192.0.2.1处分配TCP端口62000，作为A与s的会话的临时公共端点地址；因此，服务器S认为客户端A位于IP地址192.0.2.1，使用端口62000。然而，客户端B有自己的永久IP地址192.0.2.254，并且B上的应用程序正在端口1234接受TCP连接。
Now suppose client B wishes to establish a direct communication session with client A. B might first attempt to contact client A either at the address client A believes itself to have, namely, 10.0.0.1:1234, or at the address of A as observed by server S, namely, 192.0.2.1:62000. In either case, the connection will fail. In the first case, traffic directed to IP address 10.0.0.1 will
现在假设客户机B希望与客户机a建立直接通信会话。B可能首先尝试在客户机a认为自己拥有的地址（即10.0.0.1:1234）或服务器S观察到的a地址（即192.0.2.1:62000）联系客户机a。无论哪种情况，连接都将失败。在第一种情况下，定向到IP地址10.0.0.1的流量将
simply be dropped by the network because 10.0.0.1 is not a publicly routable IP address. In the second case, the TCP SYN request from B will arrive at NAT A directed to port 62000, but NAT A will reject the connection request because only outgoing connections are allowed.
因为10.0.0.1不是一个可公开路由的IP地址，所以网络可能会丢弃它。在第二种情况下，来自B的TCP SYN请求将到达指向端口62000的NAT A，但NAT A将拒绝连接请求，因为只允许传出连接。
After attempting and failing to establish a direct connection to A, client B can use server S to relay a request to client A to initiate a "reversed" connection to client B. Client A, upon receiving this relayed request through S, opens a TCP connection to client B at B's public IP address and port number. NAT A allows the connection to proceed because it is originating inside the firewall, and client B can receive the connection because it is not behind a NAT device.
在尝试建立与a的直接连接但失败后，客户机B可以使用服务器S将请求中继到客户机a，以启动与客户机B的“反向”连接。客户机a通过S接收到此中继请求后，在B的公共IP地址和端口号处打开与客户机B的TCP连接。NAT A允许连接继续进行，因为它是在防火墙内部发起的，而客户端B可以接收连接，因为它不在NAT设备后面。
A variety of current peer-to-peer applications implement this technique. Its main limitation, of course, is that it only works so long as only one of the communicating peers is behind a NAT device. If the NAT device is EIM-NAT, the public client can contact external server S to determine the specific public endpoint from which to expect Client-A-originated connection and allow connections from just those endpoints. If the NAT device is EIM-NAT, the public client can contact the external server S to determine the specific public endpoint from which to expect connections originated by client A, and allow connections from just that endpoint. If the NAT device is not EIM-NAT, the public client cannot know the specific public endpoint from which to expect connections originated by client A. In the increasingly common case where both peers can be behind NATs, the Connection Reversal method fails. Connection Reversal is not a general solution to the peer-to-peer connection problem. If neither a "forward" nor a "reverse" connection can be established, applications often fall back to another mechanism such as relaying.
当前的各种对等应用程序都实现了这种技术。当然，它的主要限制是，它只在只有一个通信对等方在NAT设备后面时才工作。如果NAT设备是EIM-NAT，则公共客户端可以与外部服务器联系，以确定特定的公共端点，从该端点期望来自客户端的连接，并允许仅从这些端点进行连接。如果NAT设备是EIM-NAT，则公共客户端可以联系外部服务器，以确定特定的公共端点，从该端点期望客户端A发起连接，并允许仅从该端点进行连接。如果NAT设备不是EIM-NAT，则公共客户端无法知道期望客户端A发起连接的特定公共端点。在两个对等方都可以在NAT后面的日益常见的情况下，连接反转方法失败。连接反转不是对等连接问题的一般解决方案。如果既不能建立“正向”连接，也不能建立“反向”连接，则应用程序通常会退回到另一种机制，如中继。
UDP hole punching relies on the properties of EIM-NATs to allow appropriately designed peer-to-peer applications to "punch holes" through the NAT device(s) enroute and establish direct connectivity with each other, even when both communicating hosts lie behind NAT devices. When one of the hosts is behind a NAT that is not EIM-NAT, the peering host cannot predictably know the mapped endpoint to which to initiate a connection. Further, the application on the host behind non-EIM-NAT would be unable to reuse an already established endpoint mapping for communication with different external destinations, and the hole punching technique would fail.
UDP穿孔依赖于EIM NAT的属性，允许适当设计的对等应用程序在路由过程中通过NAT设备“穿孔”，并彼此建立直接连接，即使两个通信主机都位于NAT设备后面。当其中一台主机位于非EIM-NAT的NAT后面时，对等主机无法预知要向其发起连接的映射端点。此外，非EIM-NAT后面的主机上的应用程序将无法重用已经建立的端点映射来与不同的外部目的地进行通信，穿孔技术将失败。
This technique was mentioned briefly in Section 5.1 of RFC 3027 [NAT-PROT], first described in [KEGEL], and used in some recent protocols [TEREDO, ICE]. Readers may refer to Section 3.4 for details on "TCP hole punching".
RFC 3027[NAT-PROT]第5.1节简要提及了该技术，首次在[KEGEL]中描述，并在一些最新协议[TEREDO，ICE]中使用。读者可参考第3.4节了解“TCP打孔”的详细信息。
We will consider two specific scenarios, and how applications are 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.
我们将考虑两个特定的场景，以及如何设计应用程序来优雅地处理它们。在第一种情况下，代表常见情况，两个希望直接对等通信的客户端驻留在两个不同的nat后面。在第二种情况下，两个客户机实际上驻留在同一个NAT后面，但不一定知道它们驻留在同一NAT后面。
Consider the scenario in figure 3. Clients A and B both have private IP addresses and lie behind different NAT devices. Rendezvous Server S has a publicly addressable IP address and is used for the purposes of registration, discovery, and limited relay. Hosts behind a NAT register their public endpoints with the server. Peer hosts discover the public endpoints of hosts behind a NAT using the server. Unlike in Section 3.1, peer hosts use the server to relay just connection initiation control messages, instead of end-to-end messages.
考虑图3中的场景。客户端A和B都有专用IP地址，位于不同的NAT设备后面。集合服务器S具有可公开寻址的IP地址，用于注册、发现和有限中继。NAT后面的主机向服务器注册其公共端点。对等主机使用服务器发现NAT后面主机的公共端点。与第3.1节不同，对等主机使用服务器仅中继连接启动控制消息，而不是端到端消息。
The peer-to-peer application running on clients A and B use UDP port 1234. The rendezvous server S uses UDP port 20001. 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.
在客户端A和B上运行的对等应用程序使用UDP端口1234。集合服务器使用UDP端口20001。A和B分别启动了与服务器S的UDP通信会话，使NAT A为A与S的会话分配其自己的公共UDP端口62000，并使NAT B分别将其端口31000分配给B与S的会话。
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31000 | | 192.0.2.1:62000 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
+--------------+ +--------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| EIM-NAT A | | EIM-NAT B |
+--------------+ +--------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31000 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31000 | | 192.0.2.1:62000 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
+--------------+ +--------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| EIM-NAT A | | EIM-NAT B |
+--------------+ +--------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31000 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 3: UDP Hole Punching to set up direct connectivity
图3：设置直接连接的UDP打孔
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 endpoint 192.0.2.254:31000, then NAT B will typically discard these incoming messages (unless it employs Endpoint-Independent Filtering), because the source address and port number do 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 endpoint, then NAT A will typically discard these messages.
现在假设客户机A希望直接与客户机B建立UDP通信会话。如果A只是开始向B的公共端点192.0.2.254:31000发送UDP消息，则NAT B通常会丢弃这些传入消息（除非它采用端点独立过滤），因为源地址和端口号与建立原始传出会话的S的地址和端口号不匹配。类似地，如果B只是开始向A的公共端点发送UDP消息，则NAT A通常会丢弃这些消息。
Suppose A starts sending UDP messages to B's public endpoint, and simultaneously relays a request through server S to B, asking B to start sending UDP messages to A's public endpoint. A's outgoing messages directed to B's public endpoint (192.0.2.254:31000) cause EIM-NAT A to open up a new communication session between A's private
假设A开始向B的公共端点发送UDP消息，同时通过服务器s向B转发请求，要求B开始向A的公共端点发送UDP消息。A发送到B的公共端点（192.0.2.254:31000）的消息会导致EIM-NAT A在A的私有端点之间打开新的通信会话
endpoint and B's public endpoint. At the same time, B's messages to A's public endpoint (192.0.2.1:62000) cause EIM-NAT B to open up a new communication session between B's private endpoint and A's public endpoint. Once the new UDP sessions have been opened up in each direction, clients A and B can communicate with each other directly without further burden on the server S. Server S, which helps with relaying connection initiation requests to peer nodes behind NAT devices, ends up like an "introduction" server to peer hosts.
端点和B的公共端点。同时，B向A的公共端点（192.0.2.1:62000）发送的消息导致EIM-NAT B在B的私有端点和A的公共端点之间打开新的通信会话。一旦新的UDP会话在各个方向上打开，客户端A和B就可以彼此直接通信，而不会对服务器S造成进一步的负担。服务器S有助于将连接启动请求中继到NAT设备后面的对等节点，最终就像是对等主机的“介绍”服务器。
The UDP hole punching technique has several useful properties. Once a direct peer-to-peer UDP connection has been established between two clients behind NAT devices, 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 the kind of NAT device it is behind, 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 NAT device. The UDP hole punching technique even works automatically with multiple NATs, where one or both clients are distant from the public Internet via two or more levels of address translation.
UDP打孔技术有几个有用的特性。一旦在NAT设备后面的两个客户端之间建立了直接的对等UDP连接，该连接上的任何一方都可以依次接管“介绍人”的角色，并帮助另一方与其他对等方建立对等连接，最小化初始引入服务器上的负载。应用程序不需要尝试检测其背后的NAT设备的类型，因为如果其中一个或两个客户端不在NAT设备后面，上述过程将同样好地建立对等通信信道。UDP打孔技术甚至可以自动处理多个NAT，其中一个或两个客户端通过两个或更多级别的地址转换与公共互联网保持距离。
Now consider the scenario in which the two clients (probably unknowingly) happen to reside behind the same EIM-NAT, and are therefore located in the same private IP address space, as in figure 4. A well-known Rendezvous Server S has a publicly addressable IP address and is used for the purposes of registration, discovery, and limited relay. Hosts behind the NAT register with the server. Peer hosts discover hosts behind the NAT using the server and relay messages using the server. Unlike in Section 3.1, peer hosts use the server to relay just control messages, instead of all end-to-end messages.
现在考虑两个客户端（可能是不知不觉地）驻留在同一个EIM-NAT后面的场景，因此位于同一个私有IP地址空间中，如图4所示。众所周知的集合服务器S具有可公开寻址的IP地址，用于注册、发现和有限中继。NAT后面的主机向服务器注册。对等主机使用服务器发现NAT后面的主机，并使用服务器中继消息。与第3.1节不同，对等主机使用服务器仅中继控制消息，而不是所有端到端消息。
Client A has established a UDP session with server S, to which the common EIM-NAT has assigned public port number 62000. Client B has similarly established a session with S, to which the EIM-NAT has assigned public port number 62001.
客户端A已与服务器S建立UDP会话，公共EIM-NAT已向其分配公共端口号62000。客户端B同样与S建立了会话，EIM-NAT已将公共端口号62001分配给该会话。
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^
| 192.0.2.128:20001 | | | 192.0.2.128:20001 |
| 192.0.2.1:62000 | | | 192.0.2.1:62001 |
|
+--------------+
| 192.0.2.1 |
| |
| EIM-NAT |
+--------------+
|
+-----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session-try1(A-B) ^ ^ P2P Session-try1(B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session-try2(A-B) ^ ^ P2P Session-try2(B-A) ^ |
| | 10.1.1.3:1234 | | 10.0.0.1:1234 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^
| 192.0.2.128:20001 | | | 192.0.2.128:20001 |
| 192.0.2.1:62000 | | | 192.0.2.1:62001 |
|
+--------------+
| 192.0.2.1 |
| |
| EIM-NAT |
+--------------+
|
+-----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session-try1(A-B) ^ ^ P2P Session-try1(B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session-try2(A-B) ^ ^ P2P Session-try2(B-A) ^ |
| | 10.1.1.3:1234 | | 10.0.0.1:1234 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 4: Use of local and public endpoints to communicate with peers
图4：使用本地和公共端点与对等方通信
Suppose that A and B use the UDP hole punching technique as outlined above to establish a communication channel using server S as an introducer. Then A and B will learn each other's public endpoints as observed by server S, and start sending each other messages at those public endpoints. The two clients will be able to communicate with each other this way as long as the NAT allows hosts on the internal network to open translated UDP sessions with other internal hosts and not just with external hosts. This situation is referred to as "Hairpinning", because packets arriving at the NAT from the private network are translated and then looped back to the private network rather than being passed through to the public network.
假设A和B使用如上所述的UDP打孔技术，使用服务器S作为介绍人建立通信通道。然后A和B将学习服务器s观察到的彼此的公共端点，并开始在这些公共端点上彼此发送消息。只要NAT允许内部网络上的主机与其他内部主机（而不仅仅是外部主机）打开转换后的UDP会话，两个客户端就可以通过这种方式相互通信。这种情况被称为“发夹”，因为从专用网络到达NAT的数据包被转换，然后循环回专用网络，而不是通过公共网络。
For example, consider P2P session-try1 above. When A sends a UDP packet to B's public endpoint, the packet initially has a source endpoint of 10.0.0.1:1234 and a destination endpoint of
例如，考虑上面的P2P SSESIN TY1。当A向B的公共端点发送UDP数据包时，该数据包最初的源端点为10.0.0.1:1234，目标端点为
192.0.2.1:62001. The NAT receives this packet, translates it to have a source endpoint of 192.0.2.1:62000 and a destination endpoint of 10.1.1.3:1234, and then forwards it on to B.
192.0.2.1:62001. NAT接收该数据包，将其转换为具有192.0.2.1:62000的源端点和10.1.1.3:1234的目标端点，然后将其转发到B。
Even if the NAT device supports hairpinning, this translation and forwarding step is clearly unnecessary in this situation, and adds latency to the dialog between A and B, besides burdening the NAT. The solution to this problem is straightforward and is described as follows.
即使NAT设备支持发夹，在这种情况下，这种转换和转发步骤显然是不必要的，并且除了增加NAT的负担之外，还增加了A和B之间对话的延迟。这个问题的解决方案很简单，描述如下。
When A and B initially exchange address information through the Rendezvous server S, they include their own IP addresses and port numbers as "observed" by themselves, as well as their public endpoints as observed by S. The clients then simultaneously start sending packets to each other at each of the alternative addresses they know about, and use the first address that leads to successful communication. If the two clients are behind the same NAT, as is the case in figure 4 above, then the packets directed to their private endpoints (as attempted using P2P session-try2) are likely to arrive first, resulting in a direct communication channel not involving the NAT. If the two clients are behind different NATs, then the packets directed to their private endpoints will fail to reach each other at all, but the clients will hopefully establish connectivity using their respective public endpoints. It is important that these packets be authenticated in some way, however, since in the case of different NATs it is entirely possible for A's messages directed at B's private endpoint to reach some other, unrelated node on A's private network, or vice versa.
当A和B最初通过集合服务器S交换地址信息时，它们包括自己“观察到”的自己的IP地址和端口号，以及S观察到的自己的公共端点。然后，客户端同时开始在它们知道的每个备选地址向彼此发送包，并使用第一个能够成功沟通的地址。如果两个客户端位于同一NAT后面，如上图4所示，则定向到它们的私有端点的数据包（如使用P2P会话-try2所尝试的）可能首先到达，从而产生不涉及NAT的直接通信信道。如果两个客户端位于不同的NAT后面，那么定向到它们的私有端点的数据包将根本无法到达彼此，但是客户端有望使用它们各自的公共端点建立连接。然而，以某种方式对这些数据包进行身份验证是很重要的，因为在不同NAT的情况下，A的消息完全有可能指向B的专用端点，从而到达A的专用网络上的其他无关节点，反之亦然。
The [ICE] protocol employs this technique effectively, in that multiple candidate endpoints (both private and public) are communicated between peering end hosts during an offer/answer exchange. Endpoints that offer the most efficient end-to-end connection(s) are selected eventually for end-to-end data transfer.
[ICE]协议有效地利用了这一技术，因为在提供/应答交换期间，对等端主机之间会通信多个候选端点（私有和公共）。最终选择提供最高效端到端连接的端点进行端到端数据传输。
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 scenario in figure 5.
在一些涉及多个NAT设备的拓扑中，两个客户端不可能在没有特定拓扑知识的情况下在它们之间建立“最佳”P2P路由。例如，考虑图5中的场景。
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^
| 192.0.2.128:20001 | | | 192.0.2.128:20001 |
| 192.0.2.1:62000 | | | 192.0.2.1:62001 |
|
+--------------+
| 192.0.2.1 |
| |
| EIM-NAT X |
| (Supporting |
| Hairpinning) |
+--------------+
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.168.1.1:30000 | | 192.168.1.2:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 192.168.1.1:30000 | | 192.168.1.2:31000 | |
| |
+--------------+ +--------------+
| 192.168.1.1 | | 192.168.1.2 |
| | | |
| EIM-NAT A | | EIM-NAT B |
+--------------+ +--------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Registry and Discovery Combined
with Limited Relay
Server S
192.0.2.128:20001
|
^ Registry Session(A-S) ^ | ^ Registry Session(B-S) ^
| 192.0.2.128:20001 | | | 192.0.2.128:20001 |
| 192.0.2.1:62000 | | | 192.0.2.1:62001 |
|
+--------------+
| 192.0.2.1 |
| |
| EIM-NAT X |
| (Supporting |
| Hairpinning) |
+--------------+
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.168.1.1:30000 | | 192.168.1.2:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 192.168.1.1:30000 | | 192.168.1.2:31000 | |
| |
+--------------+ +--------------+
| 192.168.1.1 | | 192.168.1.2 |
| | | |
| EIM-NAT A | | EIM-NAT B |
+--------------+ +--------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.1:62001 | | 192.0.2.1:62000 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 5: Use of Hairpinning in setting up direct communication
图5：在建立直接通信时使用发夹
Suppose NAT X is an EIM-NAT deployed by a large 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
假设NAT X是由大型互联网服务提供商（ISP）部署的EIM-NAT，用于将许多客户多路复用到几个公共IP地址上，NAT a和B是部署的小型消费者NAT网关
independently by two of the ISP's customers to multiplex their private home networks onto their respective ISP-provided IP addresses. Only server S and NAT X have globally routable IP addresses; 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 NATs A and B, respectively. Just as in the previous section, server S is used for the purposes of registration, discovery, and limited relay. Peer hosts use the server to relay connection initiation control messages, instead of all end-to-end messages.
由ISP的两个客户独立地将其专用家庭网络多路传输到各自ISP提供的IP地址。只有服务器S和NAT X具有全局可路由IP地址；NAT A和NAT B使用的“公共”IP地址实际上是ISP寻址域的专用地址，而客户机A和B的地址则分别是NAT A和B寻址域的专用地址。与上一节一样，服务器S用于注册、发现和有限中继。对等主机使用服务器中继连接启动控制消息，而不是所有端到端消息。
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 endpoints of the clients, 192.0.2.1:62000 and 192.0.2.1: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 endpoints as seen by S for their P2P communication, and rely on NAT X to provide hairpinning.
现在假设客户端A和B尝试建立直接的对等UDP连接。最佳方法是客户端A将消息发送到ISP寻址域中位于NAT B的客户端B的公共地址192.168.1.2:31000，客户端B将消息发送到位于NAT B的客户端B的公共地址，即192.168.1.1:30000。不幸的是，A和B无法了解这些地址，因为服务器S只能看到客户机的“全局”公共端点192.0.2.1:62000和192.0.2.1:62001。即使A和B有办法了解这些地址，也不能保证它们是可用的，因为ISP私有寻址域中的地址分配可能与客户端私有域中的无关地址分配冲突。因此，客户端别无选择，只能使用S所看到的全局公共端点进行P2P通信，并依赖NAT X提供发夹。
In this section, we will discuss the "TCP hole punching" technique used for establishing direct TCP connection between a pair of nodes that are both behind EIM-NAT devices. Just as with UDP hole punching, TCP hole punching relies on the properties of EIM-NATs to allow appropriately designed peer-to-peer applications to "punch holes" through the NAT device and establish direct connectivity with each other, even when both communicating hosts lie behind NAT devices. This technique is also known sometimes as "Simultaneous TCP Open".
在本节中，我们将讨论用于在EIM-NAT设备后面的一对节点之间建立直接TCP连接的“TCP打孔”技术。与UDP打孔一样，TCP打孔依赖于EIM NAT的属性，以允许经过适当设计的对等应用程序通过NAT设备“打孔”，并彼此建立直接连接，即使两个通信主机都位于NAT设备后面。这种技术有时也称为“同步TCP开放”。
Most TCP sessions start with one endpoint sending a SYN packet, to which the other party responds with a SYN-ACK packet. It is permissible, however, for two endpoints to start a TCP session by simultaneously sending each other SYN packets, to which each party subsequently responds with a separate ACK. This procedure is known as "Simultaneous TCP Open" technique and may be found in figure 6 of the original TCP specification ([TCP]). However, "Simultaneous TCP Open" is not implemented correctly on many systems, including NAT devices.
大多数TCP会话从一个端点发送SYN数据包开始，另一方用SYN-ACK数据包响应。然而，允许两个端点通过同时发送彼此的SYN数据包来启动TCP会话，随后各方用单独的ACK响应SYN数据包。这个过程被称为“同步TCP开放”技术，可以在原始TCP规范（[TCP]）的图6中找到。然而，“同步TCP开放”并没有在许多系统上正确实现，包括NAT设备。
If a NAT device receives a TCP SYN packet from outside the private network attempting to initiate an incoming TCP connection, the NAT device will normally reject the connection attempt by either dropping the SYN packet or sending back a TCP RST (connection reset) packet. In the case of SYN timeout or connection reset, the application endpoint will continue to resend a SYN packet, until the peer does the same from its end.
如果NAT设备从试图启动传入TCP连接的专用网络外部接收到TCP SYN数据包，则NAT设备通常会通过丢弃SYN数据包或发送回TCP RST（连接重置）数据包来拒绝连接尝试。在SYN超时或连接重置的情况下，应用程序端点将继续重新发送SYN数据包，直到对等端从其末端执行相同的操作。
Let us consider the case where a NAT device supports "Simultaneous TCP Open" sessions. When a SYN packet arrives with source and destination endpoints that correspond to a TCP session that the NAT device believes is already active, then the NAT device would allow the packet to pass through. In particular, if the NAT device has just recently seen and transmitted an outgoing SYN packet with the same address and port numbers, then it will consider the session active and allow the incoming SYN through. If clients A and B can each initiate an outgoing TCP connection with the other client timed so that each client's outgoing SYN passes through its local NAT device before either SYN reaches the opposite NAT device, then a working peer-to-peer TCP connection will result.
让我们考虑NAT设备支持“同时TCP开放”会话的情况。当SYN数据包到达时，其源和目标端点对应于NAT设备认为已处于活动状态的TCP会话，则NAT设备将允许该数据包通过。特别是，如果NAT设备最近刚刚看到并发送具有相同地址和端口号的输出SYN分组，那么它将考虑会话活动并允许传入SYN通过。如果客户端A和B都可以启动与另一个客户端的传出TCP连接，使每个客户端的传出SYN在任一SYN到达另一个NAT设备之前通过其本地NAT设备，则将产生一个工作的对等TCP连接。
This technique may not always work reliably for the following reason(s). If either node's SYN packet arrives at the remote NAT device too quickly (before the peering node had a chance to send the SYN packet), then the remote NAT device may either drop the SYN packet or reject the SYN with a RST packet. This could cause the local NAT device in turn to close the new NAT session immediately or initiate end-of-session timeout (refer to Section 2.6 of [NAT-TERM]) so as to close the NAT session at the end of the timeout. Even as both peering nodes simultaneously initiate continued SYN retransmission attempts, some remote NAT devices might not let the incoming SYNs through if the NAT session is in an end-of-session timeout state. This in turn would prevent the TCP connection from being established.
由于以下原因，此技术可能无法始终可靠工作。如果任一节点的SYN包到达远程NAT设备的速度过快（在对等节点有机会发送SYN包之前），则远程NAT设备可以丢弃SYN包或使用RST包拒绝SYN。这可能导致本地NAT设备立即关闭新的NAT会话或启动会话结束超时（请参阅[NAT-TERM]第2.6节），以便在超时结束时关闭NAT会话。即使两个对等节点同时启动持续的SYN重传尝试，如果NAT会话处于会话结束超时状态，一些远程NAT设备可能不会让传入的SYN通过。这反过来会阻止TCP连接的建立。
In reality, the majority of NAT devices (more than 50%) support Endpoint-Independent Mapping and do not send ICMP errors or RSTs in response to unsolicited incoming SYNs. As a result, the Simultaneous TCP Open technique does work across NAT devices in the majority of TCP connection attempts ([P2P-NAT], [TCP-CHARACT]).
事实上，大多数NAT设备（超过50%）支持端点独立映射，并且不会发送ICMP错误或RST来响应未经请求的传入SYN。因此，在大多数TCP连接尝试（[P2P-NAT]、[TCP-CHARACT]）中，同步TCP开放技术确实可以跨NAT设备工作。
A variant of the UDP hole punching technique exists that allows peer-to-peer UDP sessions to be created in the presence of some NATs implementing Endpoint-Dependent Mapping. This method is sometimes called the "N+1" technique [BIDIR] and is explored in detail by Takeda [SYM-STUN]. The method works by analyzing the behavior of the
UDP穿孔技术的一种变体允许在某些NAT实现端点相关映射的情况下创建对等UDP会话。这种方法有时被称为“N+1”技术[BIDIR]，武田[SYM-STUN]对此进行了详细探讨。该方法通过分析
NAT and attempting to predict the public port numbers it will assign to future sessions. The public ports assigned are often predictable because most NATs assign mapping ports in sequence.
NAT并尝试预测它将分配给未来会话的公共端口号。分配的公共端口通常是可预测的，因为大多数NAT按顺序分配映射端口。
Consider the scenario in figure 6. Two clients, A and B, each behind a separate NAT, have established separate UDP connections with rendezvous server S. Rendezvous server S has a publicly addressable IP address and is used for the purposes of registration and discovery. Hosts behind a NAT register their endpoints with the server. Peer hosts discover endpoints of the hosts behind NAT using the server.
考虑图6中的场景。两个客户端（A和B）分别位于一个单独的NAT后面，它们与集合服务器S建立了单独的UDP连接。集合服务器S有一个可公开寻址的IP地址，用于注册和发现。NAT后面的主机向服务器注册其端点。对等主机使用服务器发现NAT后面主机的端点。
Registry and Discovery
Server S
192.0.2.128:20001
|
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31001 | | 192.0.2.1:62001 | |
| | 192.0.2.1:62001 | | 192.0.2.254:31001 | |
| |
+---------------------+ +--------------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| NAT A | | NAT B |
| (Endpoint-Dependent | | (Endpoint-Dependent|
| Mapping) | | Mapping) |
+---------------------+ +--------------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31001 | | 192.0.2.1:62001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Registry and Discovery
Server S
192.0.2.128:20001
|
|
+----------------------------+----------------------------+
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 192.0.2.1:62000 | | 192.0.2.254:31000 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31001 | | 192.0.2.1:62001 | |
| | 192.0.2.1:62001 | | 192.0.2.254:31001 | |
| |
+---------------------+ +--------------------+
| 192.0.2.1 | | 192.0.2.254 |
| | | |
| NAT A | | NAT B |
| (Endpoint-Dependent | | (Endpoint-Dependent|
| Mapping) | | Mapping) |
+---------------------+ +--------------------+
| |
| ^ Registry Session(A-S) ^ ^ Registry Session(B-S) ^ |
| | 192.0.2.128:20001 | | 192.0.2.128:20001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
| ^ P2P Session (A-B) ^ ^ P2P Session (B-A) ^ |
| | 192.0.2.254:31001 | | 192.0.2.1:62001 | |
| | 10.0.0.1:1234 | | 10.1.1.3:1234 | |
| |
Client A Client B
10.0.0.1:1234 10.1.1.3:1234
Figure 6: UDP Port Prediction to set up direct connectivity
图6：设置直接连接的UDP端口预测
NAT A has assigned its UDP port 62000 to the communication session between A and S, and NAT B has assigned its port 31000 to the session between B and S. By communicating with server S, A and B learn each other's public endpoints as observed by S. Client A now starts sending UDP messages to port 31001 at address 192.0.2.254 (note the port number increment), and client B simultaneously starts sending messages to port 62001 at address 192.0.2.1. If NATs A and B assign port numbers to new sessions sequentially, and if not much time has passed since the A-S and B-S sessions were initiated, then a working bidirectional communication channel between A and B should result. A's messages to B cause NAT A to open up a new session, to which NAT A will (hopefully) assign public port number 62001, because 62001 is next in sequence after the port number 62000 it previously assigned to the session between A and S. Similarly, B's messages to A will cause NAT B to open a new session, to which it will (hopefully) assign port number 31001. If both clients have correctly guessed the port numbers each NAT assigns to the new sessions, then a bidirectional UDP communication channel will have been established.
NAT A已将其UDP端口62000分配给A和S之间的通信会话，而NAT B已将其端口31000分配给B和S之间的会话。通过与服务器S通信，A和B了解S观察到的彼此的公共端点。客户端A现在开始向地址为192.0.2.254的端口31001发送UDP消息（注意端口号增量），客户端B同时开始向地址为192.0.2.1的端口62001发送消息。如果NAT A和B按顺序为新会话分配端口号，并且如果自A-S和B-S会话启动以来没有过多少时间，则A和B之间应该会产生一个工作的双向通信通道。A向B发送的消息会导致NAT A停止打开一个新会话，NAT a将（希望）为其分配公共端口号62001，因为62001是其先前分配给a和S之间会话的端口号62000之后的下一个顺序。类似地，B给a的消息将导致NAT B打开一个新会话，NAT B将（希望）为其打开一个新会话分配端口号31001。如果两个客户端都正确猜测了每个NAT分配给新会话的端口号，则将建立双向UDP通信通道。
Clearly, there are many things that can cause this trick to fail. If the predicted port number at either NAT already happens to be in use by an unrelated session, then the NAT will skip over that port number and the connection attempt will fail. If either NAT sometimes or always chooses port numbers non-sequentially, then the trick will fail. If a different client behind NAT A (or B, respectively) opens up a new outgoing UDP connection to any external destination after A (B) establishes its connection with S but before sending its first message to B (A), then the unrelated client will inadvertently "steal" the desired port number. This trick is therefore much less likely to work when either NAT involved is under load.
显然，有很多事情会导致这一伎俩失败。如果两个NAT中预测的端口号恰好已被一个不相关的会话使用，则NAT将跳过该端口号，连接尝试将失败。如果NAT有时或总是不按顺序选择端口号，那么该技巧将失败。如果NAT a（或B）后面的另一个客户端在a（B）与S建立连接后，但在向B（a）发送第一条消息之前，打开了到任何外部目标的新传出UDP连接，则不相关的客户端将无意中“窃取”所需的端口号。因此，当涉及的NAT中的任何一个都处于负载状态时，此技巧不太可能起作用。
Since in practice an application implementing this trick would still need to work even when one of the NATs employs Endpoint-Independent Mapping, the application would need to detect beforehand what kind of NAT is involved on either end and modify its behavior accordingly, increasing the complexity of the algorithm and the general brittleness of the network. Finally, port number prediction has little chance of working if either client is behind two or more levels of NAT and the NAT(s) closest to the client employs Endpoint-Dependent Mapping.
由于在实践中，即使其中一个NAT采用端点无关映射，实现此技巧的应用程序仍然需要工作，因此应用程序需要事先检测两端涉及哪种NAT，并相应地修改其行为，增加了算法的复杂性和网络的脆弱性。最后，如果任一客户端位于两个或两个以上NAT级别之后，并且距离客户端最近的NAT使用端点相关映射，则端口号预测工作的可能性很小。
This is a variant of the "TCP Hole Punching" technique to set up direct peer-to-peer TCP sessions across NATs employing Address-Dependent Mapping.
这是“TCP打孔”技术的一种变体，用于使用地址相关映射跨NAT建立直接对等TCP会话。
Unfortunately, this trick may be even more fragile and timing-sensitive than the UDP port number prediction trick described earlier. First, predicting the public port a NAT would assign could be wrong. In addition, if either client's SYN arrives at the opposite NAT device too quickly, then the remote NAT device may reject the SYN with a RST packet, causing the local NAT device in turn to close the new session and make future SYN retransmission attempts using the same port numbers futile.
不幸的是，这个技巧可能比前面描述的UDP端口号预测技巧更脆弱，对时间更敏感。首先，预测NAT将分配的公共端口可能是错误的。此外，如果任一客户端的SYN到达对方NAT设备的速度过快，则远程NAT设备可能会使用RST包拒绝SYN，从而导致本地NAT设备依次关闭新会话，并使使用相同端口号的未来SYN重新传输尝试无效。
[P2P-NAT] has a detailed discussion on the UDP and TCP hole punching techniques for NAT traversal. [P2P-NAT] also lists empirical results from running a test program [NAT-CHECK] across a number of commercial NAT devices. The results indicate that UDP hole punching works widely on more than 80% of the NAT devices, whereas TCP hole punching works on just over 60% of the NAT devices tested. The results also indicate that TCP or UDP hairpinning is not yet widely available on commercial NAT devices, as less than 25% of the devices passed the tests ([NAT-CHECK]) for Hairpinning. Readers may also refer to [JENN-RESULT] and [SAIK-RESULT] for empirical test results in classifying publicly available NAT devices. [JENN-RESULT] provides results of NAT classification using tests spanning across different IP protocols. [SAIK-RESULT] focuses exclusively on classifying NAT devices by the TCP behavioral characteristics.
[P2P-NAT]详细讨论了用于NAT穿越的UDP和TCP打孔技术。[P2P-NAT]还列出了在许多商用NAT设备上运行测试程序[NAT-CHECK]的实证结果。结果表明，UDP打孔在80%以上的NAT设备上广泛工作，而TCP打孔在60%以上的NAT设备上工作。结果还表明，TCP或UDP发夹尚未在商用NAT设备上广泛使用，因为只有不到25%的设备通过了发夹测试（[NAT-CHECK]）。读者还可以参考[JENN-RESULT]和[SAIK-RESULT]了解对公开NAT设备进行分类的经验测试结果。[JENN-RESULT]使用跨不同IP协议的测试提供NAT分类结果。[SAIK-RESULT]专注于根据TCP行为特征对NAT设备进行分类。
[TCP-CHARACT] and [NAT-BLASTER] focus on TCP hole punching, exploring and comparing several alternative approaches. [NAT-BLASTER] takes an analytical approach, analyzing different cases of observed NAT behavior and ways applications might address them. [TCP-CHARACT] adopts a more empirical approach, measuring the commonality of different types of NAT behavior relevant to TCP hole punching. This work finds that using more sophisticated techniques than those used in [P2P-NAT], up to 88% of currently deployed NATs can support TCP hole punching.
[TCP-CHARACT]和[NAT-BLASTER]专注于TCP打孔，探索并比较了几种替代方法。[NAT-BLASTER]采用分析方法，分析观察到的NAT行为的不同情况以及应用程序可能解决这些问题的方法。[TCP-CHARACT]采用了一种更加经验性的方法，测量与TCP打孔相关的不同类型NAT行为的共性。这项工作发现，使用比[P2P-NAT]中使用的技术更复杂的技术，目前部署的NAT中多达88%可以支持TCP打孔。
[TEREDO] is a NAT traversal service that uses relay technology to connect IPv4 nodes behind NAT devices to IPv6 nodes, external to the NAT devices. [TEREDO] provides for peer communication across NAT devices by tunneling packets over UDP, across the NAT device(s) to a relay node. Teredo relays act as Rendezvous servers to relay traffic from private IPv4 nodes to the nodes in the external realm and vice versa.
[TEREDO]是一种NAT穿越服务，它使用中继技术将NAT设备后面的IPv4节点连接到NAT设备外部的IPv6节点。[TEREDO]通过UDP将数据包隧道传输到NAT设备上的中继节点，提供NAT设备上的对等通信。Teredo中继充当会合服务器，将流量从专用IPv4节点中继到外部域中的节点，反之亦然。
[ICE] is a NAT traversal protocol for setting up media sessions between peer nodes for a class of multi-media applications. [ICE] requires peering nodes to run the Simple Traversal of the UDP Protocol through NAT (STUN) protocol [STUN] on the same port number
[ICE]是一种NAT穿越协议，用于为一类多媒体应用程序在对等节点之间建立媒体会话。[ICE]要求对等节点在同一端口号上通过NAT（STUN）协议[STUN]运行UDP协议的简单遍历
used to terminate media session(s). Applications that use signaling protocols such as SIP ([SIP]) may embed the NAT traversal attributes for the media session within the signaling sessions and use the offer/answer type of exchange between peer nodes to set up end-to-end media session(s) across NAT devices. [ICE-TCP] is an extension of ICE for TCP-based media sessions.
用于终止媒体会话。使用诸如SIP（[SIP]）的信令协议的应用程序可以将媒体会话的NAT遍历属性嵌入信令会话中，并使用对等节点之间交换的提供/应答类型来跨NAT设备建立端到端媒体会话。[ICE-TCP]是ICE的扩展，用于基于TCP的媒体会话。
A number of online gaming and media-over-IP applications, including Instant Messaging applications, use the techniques described in the document for peer-to-peer connection establishment. Some applications may use multiple distinct rendezvous servers for registration, discovery, and relay functions for load balancing, among other reasons. For example, the well-known media-over-IP application "Skype" uses a central public server for login and different public servers for end-to-end relay function.
许多在线游戏和IP媒体应用程序（包括即时消息应用程序）使用文档中描述的技术建立对等连接。除其他原因外，一些应用程序可能使用多个不同的集合服务器进行注册、发现和中继功能以实现负载平衡。例如，众所周知的IP媒体应用程序“Skype”使用中央公共服务器进行登录，使用不同的公共服务器进行端到端中继功能。
TCP/UDP hole punching appears to be the most efficient existing method of establishing direct TCP/UDP peer-to-peer communication between two nodes that are both behind NATs. This technique has been used with a wide variety of existing NATs. However, applications may need to prepare to fall back to simple relaying when direct communication cannot be established.
TCP/UDP穿孔似乎是在NAT后面的两个节点之间建立直接TCP/UDP对等通信的最有效的现有方法。这项技术已用于各种现有的NAT。然而，当无法建立直接通信时，应用程序可能需要准备退回到简单中继。
The TCP/UDP hole punching technique has a caveat in that it works only when the traversing NAT is EIM-NAT. When the NAT device enroute is not EIM-NAT, the application is unable to reuse an already established endpoint mapping for communication with different external destinations and the technique would fail. However, many of the NAT devices deployed in the Internet are EIM-NAT devices. That makes the TCP/UDP hole punching technique broadly applicable [P2P-NAT]. Nevertheless, a substantial fraction of deployed NATs do employ Endpoint-Dependent Mapping and do not support the TCP/UDP hole punching technique.
TCP/UDP打孔技术有一个警告，即它仅在穿越NAT为EIM-NAT时有效。当NAT设备在途中不是EIM-NAT时，应用程序无法重用已建立的端点映射以与不同的外部目的地进行通信，该技术将失败。然而，部署在Internet上的许多NAT设备都是EIM-NAT设备。这使得TCP/UDP打孔技术具有广泛的适用性[P2P-NAT]。然而，部署的NAT中有相当一部分确实采用了端点相关映射，并且不支持TCP/UDP打孔技术。
NATs Employing Endpoint-Dependent Mapping weren't a problem with client-server applications such as Web browsers, which only need to initiate outgoing connections. However, in recent times, P2P applications such as Instant Messaging and Voice-over-IP have been in wide use. NATs employing Endpoint-Dependent Mapping are not suitable for P2P applications as techniques such as TCP/UDP hole punching will not work across these NAT devices.
使用端点相关映射的NAT对于客户端服务器应用程序（如Web浏览器）来说不是问题，因为它们只需要启动传出连接。然而，近年来，即时消息和IP语音等P2P应用得到了广泛的应用。采用端点相关映射的NAT不适用于P2P应用程序，因为TCP/UDP打孔等技术无法在这些NAT设备上工作。
Application peers may be present within the same NAT domain or external to the NAT domain. In order for all peers (those within or external to the NAT domain) to discover the application endpoint, an application may choose to register its private endpoints in addition to public endpoints with the rendezvous server.
应用程序对等方可能存在于同一NAT域内或NAT域外部。为了让所有对等方（NAT域内或NAT域外的对等方）发现应用程序终结点，应用程序可以选择向集合服务器注册其私有终结点以及公共终结点。
Support for hairpinning is highly beneficial to allow hosts behind EIM-NAT to communicate with other hosts behind the same NAT device through their public, possibly translated, endpoints. Support for hairpinning is particularly useful in the case of large-capacity NATs deployed as the first level of a multi-level NAT scenario. As described in Section 3.3.3, hosts behind the same first-level NAT but different second-level NATs do not have a way to communicate with each other using TCP/UDP hole punching techniques, unless the first-level NAT also supports hairpinning. This would be the case even when all NAT devices in a deployment preserve endpoint identities.
对发夹的支持非常有利于允许EIM-NAT后面的主机通过公共端点（可能是转换的端点）与同一NAT设备后面的其他主机通信。对于作为多级NAT场景的第一级部署的大容量NAT，对发夹的支持尤其有用。如第3.3.3节所述，同一第一级NAT但不同第二级NAT后面的主机无法使用TCP/UDP打孔技术相互通信，除非第一级NAT也支持发夹。即使部署中的所有NAT设备都保留端点标识，情况也是如此。
This document does not inherently create new security issues. Nevertheless, security risks may be present in the techniques described. This section describes security risks the applications could inadvertently create in attempting to support direct communication across NAT devices.
本文档本身不会产生新的安全问题。然而，所述技术中可能存在安全风险。本节描述了应用程序在尝试支持跨NAT设备的直接通信时可能无意中产生的安全风险。
Applications must use appropriate authentication mechanisms to protect their connections from accidental confusion with other connections as well as from malicious connection hijacking or denial-of-service attacks. Applications effectively must interact with multiple distinct IP address domains, but are not generally aware of the exact topology or administrative policies defining these address domains. While attempting to establish connections via TCP/UDP hole punching, applications send packets that may frequently arrive at an entirely different host than the intended one.
应用程序必须使用适当的身份验证机制来保护其连接，以免与其他连接发生意外混淆，并防止恶意连接劫持或拒绝服务攻击。应用程序必须有效地与多个不同的IP地址域交互，但通常不知道定义这些地址域的确切拓扑或管理策略。当尝试通过TCP/UDP打孔建立连接时，应用程序发送的数据包可能经常到达与预期主机完全不同的主机。
For example, many consumer-level NAT devices provide Dynamic Host Configuration Protocol (DHCP) services that are configured by default to hand out site-local IP addresses in a particular address range. Say, a particular consumer NAT device, by default, hands out IP addresses starting with 192.168.1.100. Most private home networks using that NAT device will have a host with that IP address, and many of these networks will probably have a host at address 192.168.1.101
例如，许多消费者级NAT设备提供动态主机配置协议（DHCP）服务，这些服务默认配置为在特定地址范围内分发站点本地IP地址。比如说，一个特定的消费者NAT设备，默认情况下，会发出以192.168.1.100开头的IP地址。大多数使用NAT设备的私有家庭网络都会有一台具有该IP地址的主机，而这些网络中的许多可能会有一台位于192.168.1.101的主机
as well. If host A at address 192.168.1.101 on one private network attempts to establish a connection by UDP hole punching with host B at 192.168.1.100 on a different private network, then as part of this process host A will send discovery packets to address 192.168.1.100 on its local network, and host B will send discovery packets to address 192.168.1.101 on its network. Clearly, these discovery packets will not reach the intended machine since the two hosts are on different private networks, but they are very likely to reach SOME machine on these respective networks at the standard UDP port numbers used by this application, potentially causing confusion, especially if the application is also running on those other machines and does not properly authenticate its messages.
也如果一个专用网络上地址为192.168.1.101的主机A试图通过UDP打孔与另一个专用网络上地址为192.168.1.100的主机B建立连接，则作为此过程的一部分，主机A将向其本地网络上地址为192.168.1.100的主机B发送发现数据包，主机B将向其网络上的地址192.168.1.101发送发现数据包。显然，由于两台主机位于不同的专用网络上，这些发现数据包将不会到达目标机器，但它们很可能以此应用程序使用的标准UDP端口号到达这些各自网络上的某些机器，这可能会造成混淆，特别是如果应用程序也在其他机器上运行，并且没有正确验证其消息。
This risk due to aliasing is therefore present even without a malicious attacker. If one endpoint, say, host A, is actually malicious, then without proper authentication the attacker could cause host B to connect and interact in unintended ways with another host on its private network having the same IP address as the attacker's (purported) private address. Since the two endpoint hosts A and B presumably discovered each other through a public rendezvous server S, providing registration, discovery, and limited relay services, and neither S nor B has any means to verify A's reported private address, applications may be advised to assume that any IP address they find to be suspect until they successfully establish authenticated two-way communication.
因此，即使没有恶意攻击者，也存在由于别名而导致的这种风险。如果一个端点（例如主机A）实际上是恶意的，那么如果没有适当的身份验证，攻击者可能会导致主机B在其专用网络上以非预期方式连接并与另一台主机进行交互，该主机的IP地址与攻击者（声称的）专用地址相同。由于两个端点主机A和B可能通过提供注册、发现和有限中继服务的公共集合服务器S相互发现，并且S和B都没有任何方法来验证A报告的私有地址，建议应用程序在成功建立经过身份验证的双向通信之前，假定发现的任何IP地址都是可疑的。
Applications and the public servers that support them must protect themselves against denial-of-service attacks, and ensure that they cannot be used by an attacker to mount denial-of-service attacks against other targets. To protect themselves, applications and servers must avoid taking any action requiring significant local processing or storage resources until authenticated two-way communication is established. To avoid being used as a tool for denial-of-service attacks, applications and servers must minimize the amount and rate of traffic they send to any newly discovered IP address until after authenticated two-way communication is established with the intended target.
支持它们的应用程序和公共服务器必须保护自己免受拒绝服务攻击，并确保攻击者不会使用它们对其他目标发起拒绝服务攻击。为了保护自身，在建立经过身份验证的双向通信之前，应用程序和服务器必须避免采取任何需要大量本地处理或存储资源的操作。为了避免被用作拒绝服务攻击的工具，应用程序和服务器必须将发送到任何新发现的IP地址的通信量和速率降至最低，直到与目标建立经过身份验证的双向通信。
For example, applications that register with a public rendezvous server can claim to have any private IP address, or perhaps multiple IP addresses. A well-connected host or group of hosts that can collectively attract a substantial volume of connection attempts (e.g., by offering to serve popular content) could mount a denial-of-service attack on a target host C simply by including C's IP address in its own list of IP addresses it registers with the rendezvous server. There is no way the rendezvous server can verify
例如，在公共集合服务器上注册的应用程序可以声称拥有任何私有IP地址，或者可能有多个IP地址。一个连接良好的主机或一组主机，如果能够共同吸引大量的连接尝试（例如，通过提供流行内容服务），只需将C的IP地址包含在其向集合服务器注册的IP地址列表中，就可以在目标主机C上发起拒绝服务攻击。集合服务器无法验证
the IP addresses, since they could well be legitimate private network addresses useful to other hosts for establishing network-local communication. The application protocol must therefore be designed to size- and rate-limit traffic to unverified IP addresses in order to avoid the potential damage such a concentration effect could cause.
IP地址，因为它们很可能是对其他主机建立网络本地通信有用的合法专用网络地址。因此，应用程序协议必须设计为将流量大小和速率限制在未经验证的IP地址，以避免这种集中效应可能造成的潜在损害。
Any network device on the path between a client and a public rendezvous server can mount a variety of man-in-the-middle attacks by pretending to be a NAT. For example, suppose host A attempts to register with rendezvous server S, but a network-snooping attacker is able to observe this registration request. The attacker could then flood server S with requests that are identical to the client's original request except with a modified source IP address, such as the IP address of the attacker itself. If the attacker can convince the server to register the client using the attacker's IP address, then the attacker can make itself an active component on the path of all future traffic from the server AND other hosts to the original client, even if the attacker was originally only able to snoop the path from the client to the server.
在客户端和公共会合服务器之间的路径上的任何网络设备都可以通过伪装成NAT来装载各种中间人攻击。例如，假设主机A尝试向集合服务器S注册，但网络窥探攻击者能够观察到此注册请求。然后，攻击者可以向服务器发送与客户端原始请求相同的请求，但不包括修改的源IP地址，如攻击者自身的IP地址。如果攻击者能够说服服务器使用攻击者的IP地址注册客户端，则攻击者可以使自己成为从服务器和其他主机到原始客户端的所有未来流量路径上的活动组件，即使攻击者最初只能窥探从客户端到服务器的路径。
The client cannot protect itself from this attack by authenticating its source IP address to the rendezvous server, because in order to be NAT-friendly the application must allow intervening NATs to change the source address silently. This appears to be an inherent security weakness of the NAT paradigm. The only defense against such an attack is for the client to authenticate and potentially encrypt the actual content of its communication using appropriate higher-level identities, so that the interposed attacker is not able to take advantage of its position. Even if all application-level communication is authenticated and encrypted, however, this attack could still be used as a traffic analysis tool for observing who the client is communicating with.
客户端无法通过向集合服务器验证其源IP地址来保护自己免受此攻击，因为为了使NAT友好，应用程序必须允许介入的NAT以静默方式更改源地址。这似乎是NAT范式固有的安全弱点。针对此类攻击的唯一防御措施是客户端使用适当的更高级别标识对其通信的实际内容进行身份验证和潜在加密，以便插入的攻击者无法利用其位置。但是，即使所有应用程序级通信都经过身份验证和加密，此攻击仍然可以用作流量分析工具，用于观察客户端与谁通信。
Designing NAT devices to preserve endpoint identities does not weaken the security provided by the NAT device. For example, a NAT device employing Endpoint-Independent Mapping and Endpoint-Dependent Filtering is no more "promiscuous" than a NAT device employing Endpoint-Dependent Mapping and Endpoint-Dependent Filtering. Filtering incoming traffic aggressively using Endpoint-Dependent Filtering while employing Endpoint-Independent Mapping allows a NAT device to be friendly to applications without compromising the principle of rejecting unsolicited incoming traffic.
设计NAT设备以保留端点身份不会削弱NAT设备提供的安全性。例如，采用端点无关映射和端点相关过滤的NAT设备并不比采用端点相关映射和端点相关过滤的NAT设备更“混乱”。在采用端点无关映射的同时，使用端点相关过滤积极过滤传入流量，使得NAT设备对应用程序友好，而不会影响拒绝未经请求的传入流量的原则。
Endpoint-Independent Mapping could arguably increase the predictability of traffic emerging from the NAT device, by revealing the relationships between different TCP/UDP sessions and hence about the behavior of applications running within the enclave. This predictability could conceivably be useful to an attacker in exploiting other network- or application-level vulnerabilities. If the security requirements of a particular deployment scenario are so critical that such subtle information channels are of concern, then perhaps the NAT device was not to have been configured to allow unrestricted outgoing TCP/UDP traffic in the first place. A NAT device configured to allow communication originating from specific applications at specific ports, or via tightly controlled application-level gateways, may accomplish the security requirements of such deployment scenarios.
端点无关映射可以通过揭示不同TCP/UDP会话之间的关系，从而了解飞地内运行的应用程序的行为，从而提高NAT设备流量的可预测性。这种可预测性可能有助于攻击者利用其他网络或应用程序级漏洞。如果特定部署场景的安全性要求非常关键，以至于需要关注这些微妙的信息通道，那么NAT设备可能没有被配置为首先允许不受限制的传出TCP/UDP流量。NAT设备配置为允许来自特定端口的特定应用程序的通信，或通过严格控制的应用程序级网关的通信，可实现此类部署场景的安全要求。
The authors wish to thank Henrik Bergstrom, David Anderson, Christian Huitema, Dan Wing, Eric Rescorla, and other BEHAVE work group members for their valuable feedback on early versions of this document. The authors also wish to thank Francois Audet, Kaushik Biswas, Spencer Dawkins, Bruce Lowekamp, and Brian Stucker for agreeing to be technical reviewers for this document.
作者希望感谢Henrik Bergstrom、David Anderson、Christian Huitema、Dan Wing、Eric Rescorla和其他BEHAVE工作组成员对本文件早期版本的宝贵反馈。作者还要感谢Francois Audet、Kaushik Biswas、Spencer Dawkins、Bruce Lowkamp和Brian Stucker同意担任本文件的技术评审员。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TERM]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT-TRAD]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[BEH-UDP] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[BEH-UDP]Audet，F.，Ed.，和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[BEH-APP] Ford, B., Srisuresh, P., and D. Kegel, "Application Design Guidelines for Traversal through Network Address Translators", Work in Progress, March 2007.
[BEH-APP]Ford，B.，Srisuresh，P.，和D.Kegel，“通过网络地址转换器进行遍历的应用程序设计指南”，正在进行的工作，2007年3月。
[BEH-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP protocol", Work in Progress, February 2008.
[BEH-ICMP]Srisuresh，P.，Ford，B.，Sivakumar，S.，和S.Guha，“ICMP协议的NAT行为要求”，正在进行的工作，2008年2月。
[BEH-TCP] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", Work in Progress, April 2007.
[BEH-TCP]Guha，S.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，在建工程，2007年4月。
[BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working
Committee, "Bidirectional Peer-to-Peer Communication
with Interposing Firewalls and NATs", August 2001.
http://www.peer-to-peerwg.org/tech/nat/
[BIDIR] Peer-to-Peer Working Group, NAT/Firewall Working
Committee, "Bidirectional Peer-to-Peer Communication
with Interposing Firewalls and NATs", August 2001.
http://www.peer-to-peerwg.org/tech/nat/
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2007.
[ICE]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历方法”，正在进行的工作，2007年10月。
[ICE-TCP] Rosenberg, J., "TCP Candidates with Interactive Connectivity Establishment (ICE)", Work in Progress, July 2007.
[ICE-TCP]Rosenberg，J.，“具有交互式连接建立（ICE）的TCP候选者”，正在进行的工作，2007年7月。
[JENN-RESULT] Jennings, C., "NAT Classification Test Results", Work in Progress, July 2007.
[JENN-RESULT]Jennings，C.，“NAT分类测试结果”，正在进行的工作，2007年7月。
[KEGEL] Kegel, D., "NAT and Peer-to-Peer Networking", July
1999. http://www.alumni.caltech.edu/~dank/peer-nat.html
[KEGEL] Kegel, D., "NAT and Peer-to-Peer Networking", July
1999. http://www.alumni.caltech.edu/~dank/peer-nat.html
[MIDCOM] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.
[MIDCOM]Srisuresh，P.，Kuthan，J.，Rosenberg，J.，Molitor，A.，和A.Rayhan，“中间盒通信架构和框架”，RFC 3303，2002年8月。
[NAT-APPL] Senie, D., "Network Address Translator (NAT)-Friendly Application Design Guidelines", RFC 3235, January 2002.
[NAT-APPL]Senie，D.，“网络地址转换器（NAT）-友好的应用程序设计指南”，RFC 3235，2002年1月。
[NAT-BLASTER] Biggadike, A., Ferullo, D., Wilson, G., and Perrig, A., "Establishing TCP Connections Between Hosts Behind NATs", ACM SIGCOMM ASIA Workshop, April 2005.
[NAT-BLASTER]Biggadike，A.，Ferullo，D.，Wilson，G.，和Perrig，A.，“在NAT背后的主机之间建立TCP连接”，ACM SIGCOMM亚洲研讨会，2005年4月。
[NAT-CHECK] Ford, B., "NAT check Program" available online as http://midcom-p2p.sourceforge.net, February 2005.
[NAT-CHECK]福特，B.，“NAT-CHECK计划”在线提供http://midcom-p2p.sourceforge.net，2005年2月。
[NAT-PMP] Cheshire, S., Krochmal, M., and K. Sekar, "NAT Port Mapping Protocol (NAT-PMP)", Work in Progress, October 2006.
[NAT-PMP]Cheshire，S.，Krochmal，M.，和K.Sekar，“NAT端口映射协议（NAT-PMP）”，正在进行的工作，2006年10月。
[NAT-PROT] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[NAT-PROT]Holdrege，M.和P.Srisuresh，“IP网络地址转换器的协议复杂性”，RFC 3027，2001年1月。
[NAT-PT] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[NAT-PT]Tsirtsis，G.和P.Srisuresh，“网络地址转换-协议转换（NAT-PT）”，RFC 2766，2000年2月。
[NAT-PT-HIST] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
[NAT-PT-HIST]Aoun，C.和E.Davies，“将网络地址转换器-协议转换器（NAT-PT）移至历史状态的原因”，RFC 4966，2007年7月。
[NSIS-NSLP] Stiemerling, M., Tschofenig, H., Aoun, C., and E. Davies, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", Work in Progress, July 2007.
[NSIS-NSLP]Stieemerling，M.，Tschofenig，H.，Aoun，C.，和E.Davies，“NAT/防火墙NSIS信令层协议（NSLP）”，正在进行的工作，2007年7月。
[P2P-NAT] Ford, B., Srisuresh, P., and Kegel, D., "Peer-to-Peer Communication Across Network Address Translators", Proceedings of the USENIX Annual Technical Conference (Anaheim, CA), April 2005.
[P2P-NAT]Ford，B.，Srisuresh，P.，和Kegel，D.，“跨网络地址转换器的点对点通信”，USENIX年度技术会议记录（加利福尼亚州阿纳海姆），2005年4月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330]IANA，“特殊用途IPv4地址”，RFC33302002年9月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941]Narten，T.，Draves，R.，和S.Krishnan，“IPv6中无状态地址自动配置的隐私扩展”，RFC 49412007年9月。
[RSIP] Borella, M., Lo, J., Grabelsky, D., and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIP]Borella，M.，Lo，J.，Grabelsky，D.，和G.黑山，“特定领域知识产权：框架”，RFC 3102，2001年10月。
[SAIK-RESULT] Guha, Saikat, "NAT STUNT Results" available online as https://www.guha.cc/saikat/stunt-results.php.
[SAIK-RESULT]Guha，Saikat，“NAT特技表演结果”在线提供https://www.guha.cc/saikat/stunt-results.php.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[SIP]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[SOCKS] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and L. Jones, "SOCKS Protocol Version 5", RFC 1928, March 1996.
[袜子]Leech，M.，Ganis，M.，Lee，Y.，Kuris，R.，Koblas，D.，和L.Jones，“袜子协议版本5”，RFC 19281996年3月。
[STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[STUN]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[SYM-STUN] Takeda, Y., "Symmetric NAT Traversal using STUN", Work in Progress, June 2003.
[SYM-STUN]武田，Y.，“使用STUN的对称NAT穿越”，正在进行的工作，2003年6月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]Postel，J.，“传输控制协议”，STD 7，RFC 793，1981年9月。
[TCP-CHARACT] Guha, S., and Francis, P., "Characterization and Measurement of TCP Traversal through NATs and Firewalls", Proceedings of Internet Measurement Conference (IMC), Berkeley, CA, October 2005, pp. 199- 211.
[TCP-CHARACT]Guha，S.和Francis，P.，“通过NAT和防火墙的TCP穿越的特征和测量”，互联网测量会议记录（IMC），加利福尼亚州伯克利，2005年10月，第199-211页。
[TEREDO] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[TEREDO]Huitema，C.，“TEREDO：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[TURN] Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", Work in Progress, January 2008.
[TURN]Rosenberg，J.，Mahy，R.，和P.Matthews，“使用NAT周围的中继进行遍历（TURN）：NAT会话遍历实用程序的中继扩展（STUN）”，正在进行的工作，2008年1月。
[UNSAF] Daigle, L., Ed., and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[UNSAF]Daigle，L.，Ed.，和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized
Device Control Protocol V 1.0", November 2001,
http://www.upnp.org/standardizeddcps/igd.asp
[UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized
Device Control Protocol V 1.0", November 2001,
http://www.upnp.org/standardizeddcps/igd.asp
[V6-CPE-SEC] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service", Work in Progress, June 2007.
[V6-CPE-SEC]Woodyatt，J.，“提供住宅IPv6互联网服务的客户场所设备中推荐的简单安全功能”，正在进行的工作，2007年6月。
Authors' Addresses
作者地址
Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 USA
美国加利福尼亚州山景城圣安东尼奥路1161号Pyda Srisuresh Kazeon Systems，Inc.94043
Phone: (408)836-4773 EMail: srisuresh@yahoo.com
电话：（408）836-4773电子邮件：srisuresh@yahoo.com
Bryan Ford Laboratory for Computer Science Massachusetts Institute of Technology 77 Massachusetts Ave. Cambridge, MA 02139 USA
美国马萨诸塞州剑桥市马萨诸塞大道77号麻省理工学院计算机科学布莱恩·福特实验室，邮编：02139
Phone: (617) 253-5261
EMail: baford@mit.edu
Web: http://www.brynosaurus.com/
Phone: (617) 253-5261
EMail: baford@mit.edu
Web: http://www.brynosaurus.com/
Dan Kegel Kegel.com 901 S. Sycamore Ave. Los Angeles, CA 90036 USA
Dan Kegel.com美国加利福尼亚州洛杉矶桑树大道南901号，邮编90036
Phone: 323 931-6717
EMail: dank@kegel.com
Web: http://www.kegel.com/
Phone: 323 931-6717
EMail: dank@kegel.com
Web: http://www.kegel.com/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.