概要
In recent years, the standards community has developed techniques for traversing NAT/firewall boxes with UDP (that is, establishing UDP flows between hosts behind NATs). Because of the asymmetric nature of TCP connection establishment, however, NAT traversal of TCP is more difficult. Researchers have recently proposed a variety of promising approaches for TCP NAT traversal. The success of these approaches, however, depend on how NAT boxes respond to various sequences of TCP (and ICMP) packets.
近几年，标准化连接已经发展了用UDP穿透NAT和防火墙的技术，那就是，在主机和NAT间建立UDP流。因为TCP连接建立的不对称性，所以TCP穿透NAT是比较困难的。近期，研究者们通过大量的渠道去尝试TCP穿透NAT，依赖于NAT回复的大量TCP和ICMP包的顺序，终于有方法得以成功打通NAT。
This paper presents the first broad study of NAT behavior for a comprehensive set of TCP NAT traversal techniques over a wide range of commercial NAT products. We developed a publicly available software test suite that measures the NAT's responses both to a variety of isolated probes and to complete TCP connection establishments. We test sixteen NAT products in the lab, and 93 home NATs in the wild. Using these results, as well as market data for NAT products, we estimate the likelihood of successful NAT traversal for home networks. The insights gained from this paper can be used to guide both design of TCP NAT traversal protocols and the standardization of NAT/firewall behavior, including the IPv4-IPv6 translating NATs critical for IPv6 transition.
此页介绍了一次广泛的研究，通过不同种类的NAT产品，使用一组全面的TCP穿透的技术,来学习NAT的行为。我们开发了一个公共存在的软件测试套件，不管是用大量独立的探针，还是完全建立的TCP连接，它能确认NAT的回复信息。我们在实验室中测试６种类型的NAT产品，还有在外面的９３种家庭NAT。用这些结果，只要是市场上的NAT产品的数据，我们都能估计家庭网络成功穿透这类产品的可能性。从此页中所获得的这种洞查力将可以使用于指导TCP穿透NAT协议的设计，还可以使用于使NAT或防火墙的行为标准化，包括IPv4-IPv6转换NAT的IPv6转换鉴定.
1 Introduction
1 介绍
Network address and port translators (NATs) and firewalls break the IP connectivity model by preventing hosts outside the protected network2 from initiating a connection with a host inside the protected network. If both endpoints are protected by their respective NAT or firewall, ordinary TCP cannot be established since the end initiating the TCP is outside the other end's NAT3. This is true even if the connection would be allowed according to each end's firewall security policy. For instance, if the firewall policy is that internal hosts may initiate TCP connections, and both hosts wish to initiate.
网络地址和端口映射机制和防火墙，会打破IP接连模式，防止外网终端连接内网终端，中断他们正在建立的联接。如果两台终端都处于各自的NAT和防火墙内时，当终端初使化的这个TCP连接在其它的NAT外时，这种普通的TCP接连是不能建立成功的。但是，如果终端们各自的防火墙的安全配置允可的话，那么，这个接连是可以成功的。例子：我们可以把防火墙设置为：当终端双方都希望去建立时，允许内部的主机去初使化一个TCP接连与外部主机相联。
Recent work has proposed work-arounds that establish a TCP connection without the use of proxies or tunnels [9, 5, 3, 6]. This is accomplished by setting up the necessary connection-state on the NAT through a carefully crafted exchange of TCP packets. However, not all NATs in the wild react the same way, causing these approaches to fail in various cases. Understanding such behavior in NATs and measuring how much they detract from the original goal of universal connectivity in the Internet is crucial to integrating them cleanly into the architecture.
最近，建立TCP接连工作打算不用代理和通道〔９，５，３，６〕，而是把它们聚合在一起。通过一种安全的TCP包转换步骤，在NAT上完全建立一种必须的接连状态。然而在外网上，不是所有的NAT都能这么做，还是有很多种的情况会导致这些步骤的失败。明白了NAT的行为，确认有多少在网络上的原始目的地连接，能很是清楚地把他们结合进框架中来。
The Internet architecture today is vastly different from that envisioned when TCP/IP was designed. Firewalls and NATs often make it impossible to establish a connection even if it does not violate policy. For instance, Alice and Bob may disallow unsolicited connections by hiding behind a NAT or configuring their firewalls to drop inbound SYN packets. Yet when both Alice and Bob agree to establish a connection there is no way to do so without reconfiguring their NAT since Alice's SYN is dropped by Bob's NAT and vice versa. Even so, NATs and firewalls have become a permanent part of the network infrastructure and will continue to remain so for a long time. Even if IPv6 is deployed globally, IPv4-IPv6 NATs will be needed during the lengthy transition, and IPv6 firewalls will be needed for security. As a result, mechanisms that enable two consenting hosts behind NATs to communicate with each other are needed.
网络结构演变到今天，已经与当初TCP/IP被设计时所预想的样子，有了巨大的不同。防火墙和NAT的出现，经常让网络没有办法去建立一个连接，甚至当这个连接是没有违反约束的时候也不可以。举例：Alice 和 Bob可能不允许让一个在NAT后面的没有请求的连接建立成功，或者设置他们的防火墙去丢掉返回的SYN（同步信号）包，然而当他们都同意希望去建立一个连接时，Alice的SYN包会被Bob的NAT扔掉，相反的连接也是如此，他们都没有办法建立除非重新设置他们的NAT。尽管如此，NAT和防火墙在网络下层构架中还是一个永远不可替代的部份，而且会在很长的时间内继续扮演下去。甚至当IPv6的展开全球化，在过度的转换中还是需求IPv4-IPv6 NAT来进行地址转换，而且IPv6 防火墙将会被用于安全方面。最终，我们需要一种能够会让两台在NAT后的受允许的主机互相通讯的机制。
This problem has been solved for UDP by STUN [15]. In STUN, Alice sends a UDP packet to Bob. Although this packet is dropped by Bob's NAT, it causes Alice's NAT to create local state that allows Bob's response to be directed to Alice. Bob then sends a UDP packet to Alice. Alice's NAT considers it part of the first packet's flow and routes it through, while Bob's NAT considers it a connection initiation and creates local state to route Alice's responses. This approach is used by Skype, a popular VoIP application [2]. Unfortunately, establishing TCP is more complicated. Once Alice sends her SYN packet, her OS stack as well as her NAT expect to receive a SYNACK packet from Bob in response. However, since the SYN packet was dropped, Bob's stack doesn't generate the SYNACK. Proposed workarounds to the problem are complicated, their interactions with NATs in the wild are poorly understood, and the extent to which they solve the problem is not known. Consequently applications such as the file-transfer module in Skype use contraindicated protocols like UDP. While such approaches may work, we believe it is important that wherever possible, applications use the native OS TCP stack. This is in part to avoid increasingly complex protocol stacks, but more importantly because TCP stacks have, over the years, been carefully optimized for high performance and congestion friendliness.
这个问题已经可以通过STUN[15]的UDP去解决。在STUN[15]中，Alice发送一个UDP包给Bob，尽管这个包被Bob的NAT所丢弃，这时，Bob发送一个UDP包给Alice，Alice的NAT根据第一个包流的部份东西去判断它，让他通过，当Bob的NAT考虑他是一个连接的初使化，并创建一个本地的状态去让Alice的回复通过。这个程序是Skype所使用的。SKYPE是一个流行的VoIP程序，他的操作系统栈好像他的NAT一样，期望去接收一个Bob回复来的SYN确认包。然而，当SYN包被丢弃时，Bob的栈由于收不到，不能产生一个SYN确认包。为了问题而做的计划是复杂的，他们在外部经过NAT的交流不可能成功的，并且他们解决此问题的扩展也是不能知道的。因此，那些好像在SKYPE使用的文件传输模式的程序使用不恰当的协议类似于UDP。当这些方法能工作时，程序使用的是原始的操作系统TCP协议栈，我们相信这否可能实现都很重要。这是一个方面它可以避免增加复杂的协议栈，更重要的是这几年TCP栈很小心的在高性能和用户友好性的优化，使之能更好的使用。
Overall this work makes four contributions. First, we identify and describe the complete set of NAT characteristics important to TCP NAT traversal. Second, we measure the prevalence both of these individual characteristics and of the success rate of peer-to-peer TCP connections for the various proposed approaches. Third, based on these measurements, we suggest modifications to the proposed approaches. Fourth, we provide public-domain software toolkit that can be used to measure NATs as they evolve, and as the basis of TCP NAT traversal in P2P applications. Altogether we provide insights for application developers into the inherent tradeoffs between implementation complexity and NAT-traversal success rate. Finally, our results can be used to guide the standardization process of NATs and firewalls, making them more traversal friendly without circumventing security policies.
全部的工作有四种贡献。一：我们识别并描述这一套NAT特性的设置对使用TCP进行NAT传输来说很重要，二：我们得以在大量提议的方法中去测量普遍的情况，不管是这些独立的特性的流行度还是使用TCP做P2P连接的成功率的流行度。三，根据这些测量，我们能够对这些提议出来的方法进行建议修改。四、我提供公共的软件工具包，它能被随便NAT的发展进行测量。并且，能够做为通过TCP进行P2P程序在NAT上传输的基础。总而言之，我们能提供这种洞察力，在程序发展深入到内在的固有程度上，能使用它找到在复杂的工具和NAT传输成功率之间的一种平衡点。最后，我们的结果能被用于引导标准化的NAT和防火墙程序的开发，使得它们不需要围绕严格的策略就能更加友好地穿越。
The rest of the paper is organized as follows. Section 2 discusses the proposed TCP NAT-traversal approaches. Section 3 and Section 4 explain our setup for testing NATs and the observed NAT behavior. Section 5 analyzes port-prediction and Section 6 analyzes peer-to-peer TCP establishment. Section 7 discusses related work. Section 8 concludes the paper.
接下来的内容如下：第二部份是讨论支持TCP的NAT穿透方法。第三和第四部份描述了我们的测试NAT和观察NAT的行为。第五部份分析了端口预言机制，第六部份分析了对等网的TCP建立。第７部份讨论了有关的工作，最后一部份为结束感言。
2 TCP NAT-Traversal
第二部份：TCP的NAT穿透
In this section we discuss the TCP NAT-traversal approaches that have been proposed in recent literature. In all the approaches, both ends initiate a TCP connection. The outbound SYN packet from each host creates the necessary NAT state for its own NATs. Each approach then reconciles the two TCP attempts into a single connection through different mechanisms as described in this section. The address and port to which these original SYNs are sent is determined through port prediction. Port prediction allows a host to guess the NAT mapping for a connection before sending the outbound SYN and is discussed in detail later. The approaches also require some coordination between the two hosts. This is accomplished over an out-of-band channel such as a connection proxied by a third party or a UDP/STUN session.
在这节中我们讨论的是，在最近的文献中所提出的TCP穿透NAT的方法，以及结束或开始一个TCP的连接。从各自的主机外出的SYN包，为他们自己的NAT产生可能的NAT状态。这章中，每一种方法都通过一种简单的连接，经过之前描述过的那些不同的机器，去调节两种TCP的企图。地址和端口指向那些最初的SYN包发向的通过端口预指定的地方。端口预报允许一个主机去猜测NAT映射，找到一个在发出外发的SYN包的连接，这个在之后还会讨论到。这个方法也需要两部主机之前的协作。这是完整地经过一个不得穿越的链路，就像是通过一个第三方的或是UDP/STUN会话的连接代理。
Once the direct TCP connection is established, the out-of-band channel can be closed. The reconciliation mechanism used triggers different behavior in different NATs causing the proposed approaches to fail in many instances. In addition, it is possible for either endpoint to be behind multiple NATs4 in serial. In such cases the behavior observed is a composite of the behavior of all the NATs and firewalls in the path. For brevity we shall overload the term `NAT' to mean the composite NAT/firewall.
一旦这个直接的TCP连接被建立，这个不可越的链路就能被关闭。重连机制使用触发不同的行为作用于不同的NAT，这种方法在很多的实例上会使得那些提议的方法失效。另外。那些在在NAT后。。。。这种发现行为的方法是一种在这些路径中的NAT和防火墙的行为的复合。为了简单，我们把NAT与防火墙的复合单单用NAT来复合。
(a) STUNT #1
(b) STUNT #2
(c) NATBlaster
(d) P2PNAT
Figure 1: Packets generated by various TCP NAT-traversal approaches. Solid lines are TCP/IP and ICMP packets pertaining to the connection attempt while dotted lines are control messages sent over an out-of-band channel.图１：通过大量的TCP穿透NAT方法来产生包。当虚线是控制消息被发送到一个不能穿透的链路时，实线是TCP/IP和ICMP包进行连接的意图的指示。
Approach NAT/Network Issues Linux Issues Windows Issues STUNT #1 Determining TTL Superuser priv. Superuser priv. ICMP error Setting TTL TCP Seq# changes IP Address Spoofing STUNT #2 Determining TTL Setting TTL ICMP error SYN-out SYN-in NATBlaster Determining TTL Superuser priv. Superuser priv. ICMP error Setting TTL TCP Seq# changes RAW sockets (post WinXP SP2) SYN-out SYNACK-out P2PNAT TCP simultaneous open TCP simultaneous open (pre WinXP SP2) Packet flood STUNT #1 no-TTL RST error Superuser priv. Superuser priv. TCP Seq# changes TCP simultaneous open (pre WinXP SP2) Spoofing STUNT #2 no-TTL RST error SYN-out SYN-in NATBlaster no-TTL RST error Superuser priv. Superuser priv. TCP Seq# changes RAW sockets (post WinXP SP2) SYN-out SYNACK-out TCP simultaneous open (pre WinXP SP2)