Network Working Group S. Guha, Ed.
Request for Comments: 5382 Cornell U.
BCP: 142 K. Biswas
Category: Best Current Practice Cisco Systems
B. Ford
MPI-SWS
S. Sivakumar
Cisco Systems
P. Srisuresh
Kazeon Systems
October 2008
Network Working Group S. Guha, Ed.
Request for Comments: 5382 Cornell U.
BCP: 142 K. Biswas
Category: Best Current Practice Cisco Systems
B. Ford
MPI-SWS
S. Sivakumar
Cisco Systems
P. Srisuresh
Kazeon Systems
October 2008
NAT Behavioral Requirements for TCP
TCP的NAT行为需求
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
This document defines a set of requirements for NATs that handle TCP that would allow many applications, such as peer-to-peer applications and online games to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.
本文档定义了处理TCP的NAT的一组要求，这将允许许多应用程序（如对等应用程序和在线游戏）一致工作。开发满足这组需求的NAT将大大增加这些应用程序正常运行的可能性。
Table of Contents
目录
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. TCP Connection Initiation . . . . . . . . . . . . . . . . . . 4
4.1. Address and Port Mapping Behavior . . . . . . . . . . . . 5
4.2. Internally Initiated Connections . . . . . . . . . . . . . 5
4.3. Externally Initiated Connections . . . . . . . . . . . . . 7
5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . 10
6. Application Level Gateways . . . . . . . . . . . . . . . . . . 12
7. Other Requirements Applicable to TCP . . . . . . . . . . . . . 12
7.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 12
7.2. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . 13
7.3. ICMP Responses to TCP Packets . . . . . . . . . . . . . . 13
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informational References . . . . . . . . . . . . . . . . . 18
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. TCP Connection Initiation . . . . . . . . . . . . . . . . . . 4
4.1. Address and Port Mapping Behavior . . . . . . . . . . . . 5
4.2. Internally Initiated Connections . . . . . . . . . . . . . 5
4.3. Externally Initiated Connections . . . . . . . . . . . . . 7
5. NAT Session Refresh . . . . . . . . . . . . . . . . . . . . . 10
6. Application Level Gateways . . . . . . . . . . . . . . . . . . 12
7. Other Requirements Applicable to TCP . . . . . . . . . . . . . 12
7.1. Port Assignment . . . . . . . . . . . . . . . . . . . . . 12
7.2. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . 13
7.3. ICMP Responses to TCP Packets . . . . . . . . . . . . . . 13
8. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
11.2. Informational References . . . . . . . . . . . . . . . . . 18
This document is adjunct to [BEHAVE-UDP], which defines many terms relating to NATs, lays out general requirements for all NATs, and sets requirements for NATs that handle IP and unicast UDP traffic. The purpose of this document is to set requirements for NATs that handle TCP traffic.
本文档是[BEHAVE-UDP]的补充，它定义了许多与NAT相关的术语，列出了所有NAT的一般要求，并为处理IP和单播UDP通信的NAT设置了要求。本文档的目的是为处理TCP流量的NAT设置要求。
The requirements of this specification apply to traditional NATs as described in [RFC2663].
本规范的要求适用于[RFC2663]中所述的传统NAT。
This document only covers the TCP aspects of NAT traversal. Middlebox behavior that is not necessary for network address translation of TCP is out of scope. Packet inspection above the TCP layer and firewalls are out of scope except for Application Level Gateway (ALG) behavior that may interfere with NAT traversal. Application and OS aspects of TCP NAT traversal are out of scope. Signaling-based approaches to NAT traversal, such as Middlebox Communication (MIDCOM) and Universal Plug and Play (UPnP), that directly control the NAT are out of scope. Finally, TCP connections intended for the NAT (e.g., an HTTP or Secure Shell Protocol (SSH) management interface) and TCP connections initiated by the NAT (e.g., reliable syslog client) are out of scope.
本文档仅涵盖NAT遍历的TCP方面。TCP的网络地址转换不需要的中间盒行为超出范围。TCP层和防火墙上方的数据包检查超出范围，但可能干扰NAT遍历的应用程序级网关（ALG）行为除外。TCP NAT遍历的应用程序和操作系统方面超出了范围。直接控制NAT的基于信令的NAT穿越方法，如中间盒通信（MIDCOM）和通用即插即用（UPnP）已超出范围。最后，用于NAT的TCP连接（例如HTTP或安全外壳协议（SSH）管理接口）和由NAT启动的TCP连接（例如可靠的syslog客户端）超出范围。
Network Address Translators (NATs) hinder connectivity in applications where sessions may be initiated to internal hosts. Readers may refer to [RFC3022] for detailed information on traditional NATs. [BEHAVE-UDP] lays out the terminology and requirements for NATs in the context of IP and UDP. This document supplements these by setting requirements for NATs that handle TCP traffic. All definitions and requirements in [BEHAVE-UDP] are inherited here.
网络地址转换器（NAT）会妨碍应用程序中的连接，在应用程序中，会话可能会启动到内部主机。读者可参考[RFC3022]了解传统NAT的详细信息。[BEHAVE-UDP]列出了IP和UDP上下文中NAT的术语和要求。本文档通过设置处理TCP流量的NAT的要求来补充这些要求。[BEHAVE-UDP]中的所有定义和要求在此继承。
[RFC4614] chronicles the evolution of TCP from the original definition [RFC0793] to present-day implementations. While much has changed in TCP with regards to congestion control and flow control, security, and support for high-bandwidth networks, the process of initiating a connection (i.e., the 3-way handshake or simultaneous-open) has changed little. It is the process of connection initiation that NATs affect the most. Experimental approaches such as T/TCP [RFC1644] have proposed alternate connection initiation approaches, but have been found to be complex and susceptible to denial-of-service attacks. Modern operating systems and NATs consequently primarily support the 3-way handshake and simultaneous-open modes of connection initiation as described in [RFC0793].
[RFC4614]记录了TCP从最初的定义[RFC0793]到现在的实现的演变过程。虽然TCP在拥塞控制和流量控制、安全性以及对高带宽网络的支持方面发生了很大变化，但启动连接的过程（即，三向握手或同时打开）变化不大。NAT对连接启动的影响最大。诸如T/TCP[RFC1644]等实验性方法已经提出了替代的连接启动方法，但已被发现非常复杂，容易受到拒绝服务攻击。因此，现代操作系统和NAT主要支持[RFC0793]中所述的3路握手和连接启动的同时打开模式。
Recently, many techniques have been devised to make peer-to-peer TCP applications work across NATs. [STUNT], [NATBLASTER], and [P2PNAT] describe Unilateral Self-Address Fixing (UNSAF) mechanisms that allow peer-to-peer applications to establish TCP through NATs. These approaches require only endpoint applications to be modified and work with standards compliant OS stacks. The approaches, however, depend on specific NAT behavior that is usually, but not always, supported by NATs (see [TCPTRAV] and [P2PNAT] for details). Consequently, a complete TCP NAT traversal solution is sometimes forced to rely on public TCP relays to traverse NATs that do not cooperate. This document defines requirements that ensure that TCP NAT traversal approaches are not forced to use data relays.
最近，已经设计了许多技术来使对等TCP应用程序跨NAT工作。[STUNT]、[NATBLASTER]和[P2PNAT]描述了允许对等应用程序通过NAT建立TCP的单边自地址修复（UNSAF）机制。这些方法只需要修改端点应用程序，并使用符合标准的操作系统堆栈。然而，这些方法取决于特定的NAT行为，而NAT通常（但并非总是）支持这些行为（有关详细信息，请参见[TCPTRAV]和[P2PNAT]）。因此，一个完整的TCP NAT穿越解决方案有时被迫依赖公共TCP中继来穿越不合作的NAT。本文档定义了确保TCP NAT遍历方法不被强制使用数据中继的要求。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
"NAT" in this specification includes both "Basic NAT" and "Network Address/Port Translator (NAPT)" [RFC2663]. The term "NAT Session" is adapted from [NAT-MIB] and is defined as follows.
本规范中的“NAT”包括“基本NAT”和“网络地址/端口转换器（NAPT）”[RFC2663]。术语“NAT会话”改编自[NAT-MIB]，定义如下。
NAT Session - A NAT session is an association between a TCP session as seen in the internal realm and a TCP session as seen in the external realm, by virtue of NAT translation. The NAT session will provide the translation glue between the two session representations.
NAT会话-NAT会话是通过NAT转换在内部域中看到的TCP会话和外部域中看到的TCP会话之间的关联。NAT会话将在两个会话表示之间提供转换粘合剂。
This document uses the term "TCP connection" (or just "connection") to refer to individual TCP flows identified by the 4-tuple (source and destination IP address and TCP port) and the initial sequence numbers (ISN).
本文档使用术语“TCP连接”（或简称“连接”）来指代由4元组（源和目标IP地址和TCP端口）和初始序列号（ISN）标识的单个TCP流。
This document uses the term "address and port mapping" (or just "mapping") as defined in [BEHAVE-UDP] to refer to state at the NAT necessary for network address and port translation of TCP connections. This document also uses the terms "Endpoint-Independent Mapping", "Address-Dependent Mapping", "Address and Port-Dependent Mapping", "filtering behavior", "Endpoint-Independent Filtering", "Address-Dependent Filtering", "Address and Port-Dependent Filtering", "Port assignment", "Port overloading", "hairpinning", and "External source IP address and port" as defined in [BEHAVE-UDP].
本文档使用[BEHAVE-UDP]中定义的术语“地址和端口映射”（或简称“映射”）来表示TCP连接的网络地址和端口转换所需的NAT状态。本文档还使用了术语“端点无关映射”、“地址相关映射”、“地址和端口相关映射”、“过滤行为”、“端点无关过滤”、“地址相关过滤”、“地址和端口相关过滤”、“端口分配”、“端口重载”、“发夹”等[BEHAVE-UDP]中定义的“外部源IP地址和端口”。
This section describes various NAT behaviors applicable to TCP connection initiation.
本节介绍适用于TCP连接启动的各种NAT行为。
A NAT uses a mapping to translate packets for each TCP connection. A mapping is dynamically allocated for connections initiated from the internal side, and potentially reused for certain subsequent connections. NAT behavior regarding when a mapping can be reused differs for different NATs as described in [BEHAVE-UDP].
NAT使用映射为每个TCP连接转换数据包。映射是为从内部启动的连接动态分配的，并且可能会被某些后续连接重用。关于何时可以重用映射的NAT行为对于不同的NAT是不同的，如[BEHAVE-UDP]中所述。
Consider an internal IP address and TCP port (X:x) that initiates a TCP connection to an external (Y1:y1) tuple. Let the mapping allocated by the NAT for this connection be (X1':x1'). Shortly thereafter, the endpoint initiates a connection from the same (X:x) to an external address (Y2:y2) and gets the mapping (X2':x2') on the NAT. As per [BEHAVE-UDP], if (X1':x1') equals (X2':x2') for all values of (Y2:y2), then the NAT is defined to have "Endpoint-Independent Mapping" behavior. If (X1':x1') equals (X2':x2') only when Y2 equals Y1, then the NAT is defined to have "Address-Dependent Mapping" behavior. If (X1':x1') equals (X2':x2') only when (Y2:y2) equals (Y1:y1), possible only for consecutive connections to the same external address shortly after the first is terminated and if the NAT retains state for connections in TIME_WAIT state, then the NAT is defined to have "Address and Port-Dependent Mapping" behavior. This document introduces one additional behavior where (X1':x1') never equals (X2':x2'), that is, for each connection a new mapping is allocated; in such a case, the NAT is defined to have "Connection-Dependent Mapping" behavior.
考虑一个内部IP地址和TCP端口（x:x），它启动了一个TCP连接到外部（y1:y1）元组。让NAT为此连接分配的映射为（X1'：X1'）。此后不久，端点启动从相同（X:X）到外部地址（Y2:Y2）的连接，并获取NAT上的映射（X2'：X2'）。根据[BEHAVE-UDP]，如果（X1'：X1'）对于（Y2:Y2）的所有值等于（X2'：X2'），则NAT被定义为具有“端点独立映射”行为。如果仅当Y2等于Y1时（X1'：X1'）等于（X2'：X2'），则NAT被定义为具有“地址依赖映射”行为。如果（X1'：X1'）仅当（Y2:Y2）等于（Y1:Y1）时才等于（X2'：X2'），则仅可能在第一个外部地址终止后不久连续连接到同一外部地址，并且如果NAT在时间等待状态下保留连接状态，则NAT被定义为具有“地址和端口依赖映射”行为。本文档介绍了一个附加行为，其中（X1'：X1'）从不等于（X2'：X2'），即为每个连接分配一个新映射；在这种情况下，NAT被定义为具有“连接依赖映射”行为。
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior for TCP.
REQ-1:NAT必须具有TCP的“端点独立映射”行为。
Justification: REQ-1 is necessary for UNSAF methods to work. Endpoint-Independent Mapping behavior allows peer-to-peer applications to learn and advertise the external IP address and port allocated to an internal endpoint such that external peers can contact it (subject to the NAT's security policy). The security policy of a NAT is independent of its mapping behavior and is discussed later in Section 4.3. Having Endpoint-Independent Mapping behavior allows peer-to-peer applications to work consistently without compromising the security benefits of the NAT.
理由：UNSAF方法工作需要REQ-1。端点独立映射行为允许对等应用程序了解并公布分配给内部端点的外部IP地址和端口，以便外部对等方可以联系它（取决于NAT的安全策略）。NAT的安全策略独立于其映射行为，稍后将在第4.3节中讨论。具有端点无关的映射行为允许对等应用程序一致地工作，而不会损害NAT的安全优势。
An internal endpoint initiates a TCP connection through a NAT by sending a SYN packet. The NAT allocates (or reuses) a mapping for the connection, as described in the previous section. The mapping defines the external IP address and port used for translation of all packets for that connection. In particular, for client-server
内部端点通过发送SYN数据包通过NAT启动TCP连接。NAT为连接分配（或重用）映射，如前一节所述。映射定义用于转换该连接的所有数据包的外部IP地址和端口。特别是对于客户机-服务器
applications where an internal client initiates the connection to an external server, the mapping is used to translate the outbound SYN, the resulting inbound SYN-ACK response, the subsequent outbound ACK, and other packets for the connection. This method of connection initiation corresponds to the 3-way handshake (defined in [RFC0793]) and is supported by all NATs.
当内部客户端启动与外部服务器的连接时，映射用于转换出站SYN、生成的入站SYN-ACK响应、后续出站ACK以及连接的其他数据包。这种连接启动方法对应于三向握手（在[RFC0793]中定义），并且受到所有NAT的支持。
Peer-to-peer applications use an alternate method of connection initiation termed simultaneous-open (Fig. 8, [RFC0793]) to traverse NATs. In the simultaneous-open mode of operation, both peers send SYN packets for the same TCP connection. The SYN packets cross in the network. Upon receiving the other end's SYN packet, each end responds with a SYN-ACK packet, which also cross in the network. The connection is considered established once the SYN-ACKs are received. From the perspective of the NAT, the internal host's SYN packet is met by an inbound SYN packet for the same connection (as opposed to a SYN-ACK packet during a 3-way handshake). Subsequent to this exchange, both an outbound and an inbound SYN-ACK are seen for the connection. Some NATs erroneously block the inbound SYN for the connection in progress. Some NATs block or incorrectly translate the outbound SYN-ACK. Such behavior breaks TCP simultaneous-open and prevents peer-to-peer applications from functioning correctly behind a NAT.
对等应用程序使用一种称为同步打开（图8，[RFC0793]）的连接启动替代方法来穿越NAT。在同时打开的操作模式下，两个对等方为相同的TCP连接发送SYN数据包。SYN数据包在网络中交叉。在接收到另一端的SYN数据包后，每一端用SYN-ACK数据包进行响应，该数据包也在网络中交叉。一旦接收到SYN ACK，连接即被视为已建立。从NAT的角度来看，内部主机的SYN数据包由相同连接的入站SYN数据包满足（与3路握手期间的SYN-ACK数据包相反）。在此交换之后，将看到连接的出站和入站SYN-ACK。某些NAT错误地阻止正在进行的连接的入站SYN。某些NAT阻塞或错误地转换出站SYN-ACK。这种行为会破坏TCP同步打开，并阻止对等应用程序在NAT后正常运行。
In order to provide network address translation service for TCP, it is necessary for a NAT to correctly receive, translate, and forward all packets for a connection that conform to valid transitions of the TCP State-Machine (Fig. 6, [RFC0793]).
为了为TCP提供网络地址转换服务，NAT必须正确接收、转换和转发符合TCP状态机有效转换的连接的所有数据包（图6，[RFC0793]）。
REQ-2: A NAT MUST support all valid sequences of TCP packets (defined in [RFC0793]) for connections initiated both internally as well as externally when the connection is permitted by the NAT. In particular: a) In addition to handling the TCP 3-way handshake mode of connection initiation, A NAT MUST handle the TCP simultaneous-open mode of connection initiation.
REQ-2:NAT必须支持所有有效的TCP数据包序列（在[RFC0793]中定义），以便在NAT允许连接时，在内部和外部启动连接。特别是：a）除了处理连接启动的TCP 3路握手模式外，NAT还必须处理连接启动的TCP同时打开模式。
Justification: The intent of this requirement is to allow standards compliant TCP stacks to traverse NATs no matter what path the stacks take through the TCP state-machine and no matter which end initiates the connection as long as the connection is permitted by the filtering policy of the NAT (filtering policy is described in the following section). a) In addition to TCP packets for a 3-way handshake, A NAT must be prepared to accept an inbound SYN and an outbound SYN-ACK for an internally initiated connection in order to support simultaneous-open.
理由：此要求的目的是允许符合标准的TCP堆栈遍历NAT，无论堆栈通过TCP状态机的路径是什么，也不管哪个端启动连接，只要NAT的过滤策略允许连接（过滤策略将在下一节中描述）。a）除了用于3路握手的TCP数据包外，NAT还必须准备好接受内部启动连接的入站SYN和出站SYN-ACK，以便支持同时打开。
The NAT allocates a mapping for the first connection initiated by an internal endpoint to an external endpoint. In some scenarios, the NAT's policy may allow this mapping to be reused for connections initiated from the external side to the internal endpoint. Consider as before an internal IP address and port (X:x) that is assigned (or reuses) a mapping (X1':x1') when it initiates a connection to an external (Y1:y1). An external endpoint (Y2:y2) attempts to initiate a connection with the internal endpoint by sending a SYN to (X1':x1'). A NAT can choose to either allow the connection to be established, or to disallow the connection. If the NAT chooses to allow the connection, it translates the inbound SYN and routes it to (X:x) as per the existing mapping. It also translates the SYN-ACK generated by (X:x) in response and routes it to (Y2:y2), and so on. Alternately, the NAT can disallow the connection by filtering the inbound SYN.
NAT为内部端点发起的第一个连接分配到外部端点的映射。在某些场景中，NAT的策略可能允许将此映射重新用于从外部端到内部端点的连接。先考虑一个内部IP地址和端口（x:x），当它启动到外部（y1:y1）的连接时，分配（或重用）映射（x1′：x1′）。外部端点（Y2:Y2）尝试通过向（X1'：X1'）发送SYN来启动与内部端点的连接。NAT可以选择允许建立连接，也可以选择不允许连接。如果NAT选择允许连接，它将转换入站SYN并根据现有映射将其路由到（X:X）。它还转换（X:X）生成的SYN-ACK作为响应，并将其路由到（Y2:Y2），以此类推。或者，NAT可以通过过滤入站SYN来禁止连接。
A NAT may allow an existing mapping to be reused by an externally initiated connection if its security policy permits. Several different policies are possible as described in [BEHAVE-UDP]. If a NAT allows the connection initiation from all (Y2:y2), then it is defined to have "Endpoint-Independent Filtering" behavior. If the NAT allows connection initiations only when Y2 equals Y1, then the NAT is defined to have "Address-Dependent Filtering" behavior. If the NAT allows connection initiations only when (Y2:y2) equals (Y1:y1), then the NAT is defined to have "Address and Port-Dependent Filtering" behavior (possible only shortly after the first connection has been terminated but the mapping is still active). One additional filtering behavior defined in this document is when the NAT does not allow any connection initiations from the external side; in such cases, the NAT is defined to have "Connection-Dependent Filtering" behavior. The difference between "Address and Port-Dependent Filtering" and "Connection-Dependent Filtering" behavior is that the former permits an inbound SYN during the TIME_WAIT state of the first connection to initiate a new connection while the latter does not.
如果NAT的安全策略允许，它可以允许外部启动的连接重用现有映射。如[BEHAVE-UDP]中所述，可以使用几种不同的策略。如果NAT允许从所有用户（Y2:Y2）启动连接，那么它被定义为具有“端点独立过滤”行为。如果NAT仅在Y2等于Y1时才允许连接启动，则NAT被定义为具有“地址相关过滤”行为。如果NAT仅在（Y2:Y2）等于（Y1:Y1）时才允许连接启动，则NAT被定义为具有“地址和端口相关过滤”行为（仅在第一次连接终止后不久可能，但映射仍处于活动状态）。本文档中定义的另一个过滤行为是NAT不允许从外部发起任何连接；在这种情况下，NAT被定义为具有“依赖于连接的过滤”行为。“地址和端口相关过滤”和“连接相关过滤”行为之间的区别在于前者允许入站SYN在第一个连接的等待状态期间启动新连接，而后者不允许。
REQ-3: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" behavior for TCP. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-Dependent Filtering" behavior. a) The filtering behavior MAY be an option configurable by the administrator of the NAT. b) The filtering behavior for TCP MAY be independent of the filtering behavior for UDP.
REQ-3：如果应用程序透明性是最重要的，建议NAT对TCP具有“端点独立过滤”行为。如果更严格的过滤行为是最重要的，建议NAT具有“地址相关过滤”行为。a） 过滤行为可能是NAT管理员可配置的选项。b） TCP的过滤行为可能独立于UDP的过滤行为。
Justification: The intent of this requirement is to allow peer-to-peer applications that do not always initiate connections from the internal side of the NAT to continue to work in the presence of NATs. This behavior also allows applications behind a BEHAVE compliant NAT to inter-operate with remote endpoints that are behind non-BEHAVE compliant (legacy) NATs. If the remote endpoint's NAT does not have Endpoint-Independent Mapping behavior but has only one external IP address, then an application can still traverse the combination of the two NATs if the local NAT has Address-Dependent Filtering. Section 9 contains a detailed discussion on the security implications of this requirement.
理由：该要求的目的是允许不总是从NAT内部启动连接的对等应用程序在NAT存在的情况下继续工作。此行为还允许行为兼容NAT后面的应用程序与非行为兼容（遗留）NAT后面的远程端点进行交互操作。如果远程端点的NAT没有与端点无关的映射行为，但只有一个外部IP地址，则如果本地NAT具有依赖于地址的筛选，则应用程序仍然可以遍历两个NAT的组合。第9节详细讨论了该要求的安全影响。
If the inbound SYN packet is filtered, either because a corresponding mapping does not exist or because of the NAT's filtering behavior, a NAT has two basic choices: to ignore the packet silently, or to signal an error to the sender. Signaling an error through ICMP messages allows the sender to quickly detect that the SYN did not reach the intended destination. Silently dropping the packet, on the other hand, allows applications to perform simultaneous-open more reliably.
如果由于相应的映射不存在或由于NAT的过滤行为而过滤入站SYN数据包，则NAT有两个基本选择：以静默方式忽略数据包，或向发送方发送错误信号。通过ICMP消息发出错误信号允许发送方快速检测到SYN未到达预期目的地。另一方面，静默地丢弃数据包允许应用程序更可靠地执行同步打开。
Silently dropping the SYN aids simultaneous-open as follows. Consider that the application is attempting a simultaneous-open and the outbound SYN from the internal endpoint has not yet crossed the NAT (due to network congestion or clock skew between the two endpoints); this outbound SYN would otherwise have created the necessary mapping at the NAT to allow translation of the inbound SYN. Since the outbound SYN did not reach the NAT in time, the inbound SYN cannot be processed. If a NAT responds to the premature inbound SYN with an error message that forces the external endpoint to abandon the connection attempt, it hinders applications performing a TCP simultaneous-open. If instead the NAT silently ignores the inbound SYN, the external endpoint retransmits the SYN after a TCP timeout. In the meantime, the NAT creates the mapping in response to the (delayed) outbound SYN such that the retransmitted inbound SYN can be routed and simultaneous-open can succeed. The downside to this behavior is that in the event the inbound SYN is erroneous, the remote side does not learn of the error until after several TCP timeouts.
静默地放下SYN辅助同步打开，如下所示。考虑应用程序正在尝试同时打开，并且来自内部端点的出站SYN还没有跨越NAT（由于网络拥塞或两个端点之间的时钟偏移）；否则，此出站SYN将在NAT上创建必要的映射，以允许对入站SYN进行转换。由于出站SYN未及时到达NAT，因此无法处理入站SYN。如果NAT以错误消息响应过早的入站SYN，迫使外部端点放弃连接尝试，则会妨碍应用程序执行TCP同时打开。如果NAT以静默方式忽略入站SYN，则外部端点会在TCP超时后重新传输SYN。同时，NAT创建映射以响应（延迟的）出站SYN，从而可以路由重新传输的入站SYN，同时打开也可以成功。这种行为的缺点是，在入站SYN出错的情况下，远程端直到几次TCP超时后才知道错误。
NAT support for simultaneous-open as well as quickly signaling errors are both important for applications. Unfortunately, there is no way for a NAT to signal an error without forcing the endpoint to abort a potential simultaneous-open: TCP RST and ICMP Port Unreachable packets require the endpoint to abort the attempt while the ICMP Host and Network Unreachable errors may adversely affect other connections to the same host or network [RFC1122].
NAT对同时开放和快速信令错误的支持对于应用程序都很重要。不幸的是，NAT无法在不强制端点中止潜在的同时打开的情况下发出错误信号：TCP RST和ICMP端口不可访问数据包要求端点中止尝试，而ICMP主机和网络不可访问错误可能会对到同一主机或网络的其他连接产生不利影响[RFC1122]。
In addition, when an unsolicited SYN is received by the NAT, the NAT may not know whether the application is attempting a simultaneous-open (and that it should therefore silently drop the SYN) or whether the SYN is in error (and that it should notify the sender).
此外，当NAT接收到未经请求的SYN时，NAT可能不知道应用程序是否正在尝试同时打开（因此它应该无声地删除SYN），或者SYN是否出错（并且它应该通知发送方）。
REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet for at least 6 seconds after the packet is received. If during this interval the NAT receives and translates an outbound SYN for the connection the NAT MUST silently drop the original unsolicited inbound SYN packet. Otherwise, the NAT SHOULD send an ICMP Port Unreachable error (Type 3, Code 3) for the original SYN, unless REQ-4a applies. a) The NAT MUST silently drop the original SYN packet if sending a response violates the security policy of the NAT.
REQ-4：NAT在接收到未经请求的入站SYN数据包后至少6秒钟内不得响应该数据包。如果在此间隔期间，NAT接收并转换连接的出站SYN，则NAT必须无声地丢弃原始的未经请求的入站SYN数据包。否则，NAT应为原始SYN发送ICMP端口不可访问错误（类型3，代码3），除非REQ-4a适用。a） 如果发送响应违反NAT的安全策略，则NAT必须静默地丢弃原始SYN数据包。
Justification: The intent of this requirement is to allow simultaneous-open to work reliably in the presence of NATs as well as to quickly signal an error in case the unsolicited SYN is in error. As of writing this memo, it is not possible to achieve both; the requirement therefore represents a compromise. The NAT should tolerate some delay in the outbound SYN for a TCP simultaneous-open, which may be due to network congestion or loose synchronization between the endpoints. If the unsolicited SYN is not part of a simultaneous-open attempt and is in error, the NAT should endeavor to signal the error in accordance with [RFC1122]. a) There may, however, be reasons for the NAT to rate-limit or omit such error notifications, for example, in the case of an attack. Silently dropping the SYN packet when under attack allows simultaneous-open to work without consuming any extra network bandwidth or revealing the presence of the NAT to attackers. Section 9 mentions the security considerations for this requirement.
理由：该要求的目的是允许同时打开在NAT存在的情况下可靠工作，以及在未经请求的SYN出错的情况下快速发出错误信号。在撰写本备忘录时，不可能同时实现这两个目标；因此，这一要求是一种折衷。对于TCP同时打开，NAT应能容忍出站SYN中的一些延迟，这可能是由于网络拥塞或端点之间的松散同步造成的。如果未经请求的SYN不是同时打开尝试的一部分并且出错，则NAT应尽力根据[RFC1122]发出错误信号。a） 然而，NAT可能有理由限制或忽略此类错误通知，例如，在发生攻击的情况下。当受到攻击时，静默地丢弃SYN数据包允许同时打开，而不会消耗任何额外的网络带宽，也不会向攻击者透露NAT的存在。第9节提到了该要求的安全考虑因素。
For NATs that combine NAT functionality with end-host functionality (e.g., an end-host that also serves as a NAT for other hosts behind it), REQ-4 above applies only to SYNs intended for the NAT'ed hosts and not to SYNs intended for the NAT itself. One way to determine whether the inbound SYN is intended for a NAT'ed host is to allocate NAT mappings from one port range, and allocate ports for local endpoints from a different non-overlapping port range. More dynamic implementations can be imagined.
对于将NAT功能与终端主机功能相结合的NAT（例如，也作为其后面其他主机的NAT的终端主机），上述REQ-4仅适用于NAT主机的SYN，而不适用于NAT本身的SYN。确定入站SYN是否用于NAT主机的一种方法是从一个端口范围分配NAT映射，并从不同的非重叠端口范围为本地端点分配端口。可以想象更多的动态实现。
A NAT maintains state associated with in-progress and established connections. Because of this, a NAT is susceptible to a resource-exhaustion attack whereby an attacker (or virus) on the internal side attempts to cause the NAT to create more state than for which it has resources. To prevent such an attack, a NAT needs to abandon sessions in order to free the state resources.
NAT维护与正在进行和已建立的连接相关联的状态。因此，NAT容易受到资源耗尽攻击的影响，即内部的攻击者（或病毒）试图使NAT创建比其拥有资源更多的状态。为了防止这种攻击，NAT需要放弃会话以释放状态资源。
A common method that is applicable only to TCP is to preferentially abandon sessions for crashed endpoints, followed by closed TCP connections and partially open connections. A NAT can check if an endpoint for a session has crashed by sending a TCP keep-alive packet and receiving a TCP RST packet in response. If the NAT cannot determine whether the endpoint is active, it should not abandon the session until the TCP connection has been idle for some time. Note that an established TCP connection can stay idle (but live) indefinitely; hence, there is no fixed value for an idle-timeout that accommodates all applications. However, a large idle-timeout motivated by recommendations in [RFC1122] can reduce the chances of abandoning a live session.
一种仅适用于TCP的常用方法是优先放弃崩溃端点的会话，然后是关闭的TCP连接和部分打开的连接。NAT可以通过发送TCP保持活动数据包并接收TCP RST数据包作为响应来检查会话的端点是否已崩溃。如果NAT无法确定端点是否处于活动状态，则在TCP连接空闲一段时间之前，它不应放弃会话。请注意，已建立的TCP连接可以无限期地保持空闲（但处于活动状态）；因此，不存在适用于所有应用程序的空闲超时的固定值。但是，由[RFC1122]中的建议引起的较大空闲超时可以减少放弃实时会话的机会。
A TCP connection passes through three phases: partially open, established, and closing. During the partially open phase, endpoints synchronize initial sequence numbers. The phase is initiated by the first SYN for the connection and extends until both endpoints have sent a packet with the ACK flag set (TCP states: SYN_SENT and SYN_RCVD). ACKs in both directions mark the beginning of the established phase where application data can be exchanged indefinitely (TCP states: ESTABLISHED, FIN_WAIT_1, FIN_WAIT_2, and CLOSE_WAIT). The closing phase begins when both endpoints have terminated their half of the connection by sending a FIN packet. Once FIN packets are seen in both directions, application data can no longer be exchanged, but the stacks still need to ensure that the FIN packets are received (TCP states: CLOSING and LAST_ACK).
TCP连接经历三个阶段：部分打开、建立和关闭。在部分打开阶段，端点同步初始序列号。该阶段由连接的第一个SYN启动，并一直延伸到两个端点都发送了设置了ACK标志的数据包（TCP状态：SYN_sent和SYN_RCVD）。两个方向上的确认标志着建立阶段的开始，在此阶段可以无限期地交换应用程序数据（TCP状态：已建立、FIN_WAIT_1、FIN_WAIT_2和CLOSE_WAIT）。当两个端点都通过发送FIN数据包终止了其一半连接时，关闭阶段开始。一旦在两个方向上看到FIN数据包，就不能再交换应用程序数据，但堆栈仍需要确保接收到FIN数据包（TCP状态：CLOSING and LAST_ACK）。
TCP connections can stay in established phase indefinitely without exchanging any packets. Some end-hosts can be configured to send keep-alive packets on such idle connections; by default, such keep-alive packets are sent every 2 hours if enabled [RFC1122]. Consequently, a NAT that waits for slightly over 2 hours can detect idle connections with keep-alive packets being sent at the default rate. TCP connections in the partially open or closing phases, on the other hand, can stay idle for at most 4 minutes while waiting for in-flight packets to be delivered [RFC1122].
TCP连接可以无限期地保持在已建立的阶段，而无需交换任何数据包。一些终端主机可以配置为在这种空闲连接上发送保持活动的数据包；默认情况下，如果启用，则每2小时发送一次此类保持活动状态的数据包[RFC1122]。因此，等待稍超过2小时的NAT可以检测空闲连接，并以默认速率发送保持活动的数据包。另一方面，处于部分打开或关闭阶段的TCP连接在等待传输中的数据包时最多可以保持空闲4分钟[RFC1122]。
The "established connection idle-timeout" for a NAT is defined as the minimum time a TCP connection in the established phase must remain idle before the NAT considers the associated session a candidate for removal. The "transitory connection idle-timeout" for a NAT is defined as the minimum time a TCP connection in the partially open or closing phases must remain idle before the NAT considers the associated session a candidate for removal. TCP connections in the TIME_WAIT state are not affected by the "transitory connection idle-timeout".
NAT的“已建立连接空闲超时”定义为在NAT将相关会话视为删除候选会话之前，TCP连接在已建立阶段必须保持空闲的最短时间。NAT的“临时连接空闲超时”定义为在NAT将相关会话视为删除候选会话之前，TCP连接在部分打开或关闭阶段必须保持空闲的最短时间。处于TIME_WAIT状态的TCP连接不受“临时连接空闲超时”的影响。
REQ-5: If a NAT cannot determine whether the endpoints of a TCP connection are active, it MAY abandon the session if it has been idle for some time. In such cases, the value of the "established connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. The value of the "transitory connection idle-timeout" MUST NOT be less than 4 minutes. a) The value of the NAT idle-timeouts MAY be configurable.
REQ-5：如果NAT无法确定TCP连接的端点是否处于活动状态，则如果会话已空闲一段时间，它可能会放弃会话。在这种情况下，“已建立连接空闲超时”的值不得小于2小时4分钟。“临时连接空闲超时”的值不得小于4分钟。a） NAT空闲超时的值可以配置。
Justification: The intent of this requirement is to minimize the cases where a NAT abandons session state for a live connection. While some NATs may choose to abandon sessions reactively in response to new connection initiations (allowing idle connections to stay up indefinitely in the absence of new initiations), other NATs may choose to proactively reap idle sessions. In cases where the NAT cannot actively determine if the connection is alive, this requirement ensures that applications can send keep-alive packets at the default rate (every 2 hours) such that the NAT can passively determine that the connection is alive. The additional 4 minutes allows time for in-flight packets to cross the NAT.
理由：该要求的目的是尽量减少NAT放弃实时连接会话状态的情况。虽然一些NAT可能会选择响应新的连接启动而主动放弃会话（允许空闲连接在没有新启动的情况下无限期地保留），但其他NAT可能会选择主动获取空闲会话。在NAT无法主动确定连接是否处于活动状态的情况下，此要求确保应用程序可以以默认速率（每2小时）发送保持活动状态的数据包，以便NAT可以被动地确定连接是否处于活动状态。额外的4分钟允许飞行中的数据包穿越NAT。
NAT behavior for handling RST packets, or connections in TIME_WAIT state is left unspecified. A NAT MAY hold state for a connection in TIME_WAIT state to accommodate retransmissions of the last ACK. However, since the TIME_WAIT state is commonly encountered by internal endpoints properly closing the TCP connection, holding state for a closed connection may limit the throughput of connections through a NAT with limited resources. [RFC1337] describes hazards associated with TIME_WAIT assassination.
处理RST数据包或处于TIME_WAIT状态的连接的NAT行为未指定。NAT可以在时间等待状态中保持连接的状态，以适应最后一个ACK的重新传输。但是，由于正确关闭TCP连接的内部端点通常会遇到TIME_WAIT状态，因此保持关闭连接的状态可能会限制通过资源有限的NAT的连接吞吐量。[RFC1337]描述了与等待时间暗杀相关的危险。
The handling of non-SYN packets for connections for which there is no active mapping is left unspecified. Such packets may be received if the NAT silently abandons a live connection, or abandons a connection in TIME_WAIT state before the 4 minute TIME_WAIT period expires. The decision to either silently drop such packets or to respond with a TCP RST packet is left up to the implementation.
对于没有活动映射的连接，未指定对非SYN数据包的处理。如果NAT以静默方式放弃实时连接，或者在4分钟时间等待期到期之前以时间等待状态放弃连接，则可以接收此类分组。要么静默地丢弃这样的数据包，要么使用TCP RST数据包进行响应，这取决于实现。
NAT behavior for notifying endpoints when abandoning live connections is left unspecified. When a NAT abandons a live connection, for example due to a timeout expiring, the NAT MAY either send TCP RST packets to the endpoints or MAY silently abandon the connection.
未指定放弃活动连接时通知端点的NAT行为。当NAT放弃实时连接时，例如由于超时过期，NAT可以向端点发送TCP RST数据包，也可以默默地放弃连接。
Sending a RST notification allows endpoint applications to recover more quickly; however, notifying the endpoints may not always be possible if, for example, session state is lost due to a power failure.
发送RST通知允许端点应用程序更快地恢复；然而，例如，如果会话状态由于电源故障而丢失，则通知端点可能并不总是可能的。
Application Level Gateways (ALGs) in certain NATs modify IP addresses and TCP ports embedded inside application protocols. Such ALGs may interfere with UNSAF methods or protocols that try to be NAT-aware and must therefore be used with extreme caution.
某些NAT中的应用程序级网关（ALG）修改嵌入在应用程序协议中的IP地址和TCP端口。此类ALG可能会干扰尝试感知NAT的UNSAF方法或协议，因此必须极其小心地使用。
REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED that all of those ALGs (except for FTP [RFC0959]) be disabled by default.
REQ-6：如果NAT包括影响TCP的ALG，建议默认情况下禁用所有这些ALG（FTP[RFC0959]除外）。
Justification: The intent of this requirement is to prevent ALGs from interfering with UNSAF methods. The default state of an FTP ALG is left unspecified because of legacy concerns: as of writing this memo, a large fraction of legacy FTP clients do not enable passive (PASV) mode by default and require an ALG to traverse NATs.
理由：本要求旨在防止ALG干扰UNSAF方法。由于遗留问题，FTP ALG的默认状态未指定：在编写本备忘录时，很大一部分遗留FTP客户端默认情况下不启用被动（PASV）模式，需要ALG遍历NAT。
A list of general and UDP-specific NAT behavioral requirements are described in [BEHAVE-UDP]. A list of ICMP-specific NAT behavioral requirements are described in [BEHAVE-ICMP]. The requirements listed below reiterate the requirements from these two documents that directly affect TCP. The following requirements do not relax any requirements in [BEHAVE-UDP] or [BEHAVE-ICMP].
[BEHAVE-UDP]中描述了一般和UDP特定NAT行为要求的列表。[BEHAVE-ICMP]中描述了ICMP特定NAT行为要求的列表。下面列出的要求重申了这两个文件中直接影响TCP的要求。以下要求不会放宽[BEHAVE-UDP]或[BEHAVE-ICMP]中的任何要求。
NATs that allow different internal endpoints to simultaneously use the same mapping are defined in [BEHAVE-UDP] to have a "Port assignment" behavior of "Port overloading". Such behavior is undesirable, as it prevents two internal endpoints sharing the same mapping from establishing simultaneous connections to a common external endpoint.
允许不同内部端点同时使用相同映射的NAT在[BEHAVE-UDP]中定义为具有“端口重载”的“端口分配”行为。这种行为是不可取的，因为它会阻止共享同一映射的两个内部端点同时建立到公共外部端点的连接。
REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading" for TCP.
REQ-7:NAT不得具有TCP“端口重载”的“端口分配”行为。
Justification: This requirement allows two applications on the internal side of the NAT to consistently communicate with the same destination.
理由：这一要求允许NAT内部的两个应用程序一致地与同一目的地通信。
NAT behavior for preserving the source TCP port range for connections is left unspecified. Some applications expect the source TCP port to be in the well-known range (TCP ports from 0 to 1023). The "r" series of commands (rsh, rcp, rlogin, etc.) are an example. NATs that preserve the range from which the source port is picked allow such applications to function properly through the NAT; however, by doing so the NAT may compromise the security of the application in certain situations; applications that depend only on the IP address and source TCP port range for security (the "r" commands, for example) cannot distinguish between an attacker and a legitimate user behind the same NAT.
保留连接的源TCP端口范围的NAT行为未指定。一些应用程序希望源TCP端口在已知范围内（TCP端口从0到1023）。“r”系列命令（rsh、rcp、rlogin等）就是一个例子。保留源端口选取范围的NAT允许此类应用程序通过NAT正常运行；然而，在某些情况下，NAT这样做可能会损害应用程序的安全性；仅依赖IP地址和源TCP端口范围进行安全保护的应用程序（例如，“r”命令）无法区分同一NAT背后的攻击者和合法用户。
NATs that forward packets originating from an internal address, destined for an external address that matches the active mapping for an internal address, back to that internal address are defined in [BEHAVE-UDP] as supporting "hairpinning". If the NAT presents the hairpinned packet with an external source IP address and port (i.e., the mapped source address and port of the originating internal endpoint), then it is defined to have "External source IP address and port" for hairpinning. Hairpinning is necessary to allow two internal endpoints (known to each other only by their external mapped addresses) to communicate with each other. "External source IP address and port" behavior for hairpinning avoids confusing implementations that expect the external source IP address and port.
[BEHAVE-UDP]将源自内部地址、目的地为与内部地址的活动映射匹配的外部地址的数据包转发回该内部地址的NAT定义为支持“发夹”。如果NAT使用外部源IP地址和端口（即，原始内部端点的映射源地址和端口）呈现发夹数据包，则将其定义为具有用于发夹的“外部源IP地址和端口”。头发固定是允许两个内部端点（仅通过其外部映射地址相互了解）相互通信所必需的。头发固定的“外部源IP地址和端口”行为避免了混淆预期外部源IP地址和端口的实现。
REQ-8: A NAT MUST support "hairpinning" for TCP. a) A NAT's hairpinning behavior MUST be of type "External source IP address and port".
REQ-8:NAT必须支持TCP的“发夹”。a） NAT的发夹行为必须是“外部源IP地址和端口”类型。
Justification: This requirement allows two applications behind the same NAT that are trying to communicate with each other using their external addresses. a) Using the external source address and port for the hairpinned packet is necessary for applications that do not expect to receive a packet from a different address than the external address they are trying to communicate with.
理由：此要求允许同一NAT后面的两个应用程序尝试使用其外部地址相互通信。a） 如果应用程序不希望从与其尝试通信的外部地址不同的地址接收数据包，则需要使用发夹数据包的外部源地址和端口。
Several TCP mechanisms depend on the reception of ICMP error messages triggered by the transmission of TCP segments. One such mechanism is path MTU discovery [RFC1191], which is required for the correct
有几种TCP机制依赖于TCP段传输触发的ICMP错误消息的接收。一种这样的机制是路径MTU发现[RFC1191]，这是正确操作所必需的
operation of TCP. The current path MTU discovery mechanism requires the sender of TCP segments to be notified of ICMP "Datagram Too Big" responses.
TCP的操作。当前路径MTU发现机制要求将ICMP“数据报太大”响应通知TCP段的发送方。
REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination Unreachable (Type 3) messages.
REQ-9：如果NAT转换TCP，它应该转换ICMP目标不可访问（类型3）消息。
Justification: Translating ICMP Destination Unreachable messages, particularly the "Fragmentation Needed and Don't Fragment was Set" (Type 3, Code 4) message avoids communication failures ("black holes" [RFC2923]). Furthermore, TCP's connection establishment and maintenance mechanisms also behave much more efficiently when ICMP Destination Unreachable messages arrive in response to outgoing TCP segments.
理由：翻译ICMP目的地不可访问的消息，特别是“需要碎片且未设置碎片”（类型3，代码4）消息可避免通信故障（“黑洞”[RFC2923]）。此外，当ICMP目的地不可访问消息响应传出TCP段到达时，TCP的连接建立和维护机制也会更加有效。
REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping or TCP connection for which the ICMP was generated.
REQ-10：接收任何类型的ICMP消息不得终止为其生成ICMP的NAT映射或TCP连接。
Justification: This is necessary for reliably performing TCP simultaneous-open where a remote NAT may temporarily signal an ICMP error.
理由：在远程NAT可能临时发出ICMP错误信号的情况下，这对于可靠地执行TCP同时打开是必要的。
A NAT that supports all of the mandatory requirements of this specification (i.e., the "MUST") and is compliant with [BEHAVE-UDP], is "compliant with this specification". A NAT that supports all of the requirements of this specification (i.e., included the "RECOMMENDED") and is fully compliant with [BEHAVE-UDP] is "fully compliant with all the mandatory and recommended requirements of this specification".
支持本规范所有强制性要求（即“必须”）且符合[BEHAVE-UDP]的NAT为“符合本规范”。支持本规范所有要求（即包括“推荐”）且完全符合[BEHAVE-UDP]的NAT是“完全符合本规范所有强制性和推荐要求”。
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior for TCP.
REQ-1:NAT必须具有TCP的“端点独立映射”行为。
REQ-2: A NAT MUST support all valid sequences of TCP packets (defined in [RFC0793]) for connections initiated both internally as well as externally when the connection is permitted by the NAT. In particular: a) In addition to handling the TCP 3-way handshake mode of connection initiation, A NAT MUST handle the TCP simultaneous-open mode of connection initiation.
REQ-2:NAT必须支持所有有效的TCP数据包序列（在[RFC0793]中定义），以便在NAT允许连接时，在内部和外部启动连接。特别是：a）除了处理连接启动的TCP 3路握手模式外，NAT还必须处理连接启动的TCP同时打开模式。
REQ-3: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" behavior for TCP. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-Dependent Filtering" behavior.
REQ-3：如果应用程序透明性是最重要的，建议NAT对TCP具有“端点独立过滤”行为。如果更严格的过滤行为是最重要的，建议NAT具有“地址相关过滤”行为。
a) The filtering behavior MAY be an option configurable by the administrator of the NAT. b) The filtering behavior for TCP MAY be independent of the filtering behavior for UDP.
a) 过滤行为可能是NAT管理员可配置的选项。b） TCP的过滤行为可能独立于UDP的过滤行为。
REQ-4: A NAT MUST NOT respond to an unsolicited inbound SYN packet for at least 6 seconds after the packet is received. If during this interval the NAT receives and translates an outbound SYN for the connection the NAT MUST silently drop the original unsolicited inbound SYN packet. Otherwise, the NAT SHOULD send an ICMP Port Unreachable error (Type 3, Code 3) for the original SYN, unless REQ-4a applies. a) The NAT MUST silently drop the original SYN packet if sending a response violates the security policy of the NAT.
REQ-4：NAT在接收到未经请求的入站SYN数据包后至少6秒钟内不得响应该数据包。如果在此间隔期间，NAT接收并转换连接的出站SYN，则NAT必须无声地丢弃原始的未经请求的入站SYN数据包。否则，NAT应为原始SYN发送ICMP端口不可访问错误（类型3，代码3），除非REQ-4a适用。a） 如果发送响应违反NAT的安全策略，则NAT必须静默地丢弃原始SYN数据包。
REQ-5: If a NAT cannot determine whether the endpoints of a TCP connection are active, it MAY abandon the session if it has been idle for some time. In such cases, the value of the "established connection idle-timeout" MUST NOT be less than 2 hours 4 minutes. The value of the "transitory connection idle-timeout" MUST NOT be less than 4 minutes. a) The value of the NAT idle-timeouts MAY be configurable.
REQ-5：如果NAT无法确定TCP连接的端点是否处于活动状态，则如果会话已空闲一段时间，它可能会放弃会话。在这种情况下，“已建立连接空闲超时”的值不得小于2小时4分钟。“临时连接空闲超时”的值不得小于4分钟。a） NAT空闲超时的值可以配置。
REQ-6: If a NAT includes ALGs that affect TCP, it is RECOMMENDED that all of those ALGs (except for FTP [RFC0959]) be disabled by default.
REQ-6：如果NAT包括影响TCP的ALG，建议默认情况下禁用所有这些ALG（FTP[RFC0959]除外）。
The following requirements reiterate requirements from [BEHAVE-UDP] or [BEHAVE-ICMP] that directly affect TCP. This document does not relax any requirements in [BEHAVE-UDP] or [BEHAVE-ICMP].
以下要求重申了[BEHAVE-UDP]或[BEHAVE-ICMP]中直接影响TCP的要求。本文件并未放宽[BEHAVE-UDP]或[BEHAVE-ICMP]中的任何要求。
REQ-7: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading" for TCP.
REQ-7:NAT不得具有TCP“端口重载”的“端口分配”行为。
REQ-8: A NAT MUST support "hairpinning" for TCP. a) A NAT's hairpinning behavior MUST be of type "External source IP address and port".
REQ-8:NAT必须支持TCP的“发夹”。a） NAT的发夹行为必须是“外部源IP地址和端口”类型。
REQ-9: If a NAT translates TCP, it SHOULD translate ICMP Destination Unreachable (Type 3) messages.
REQ-9：如果NAT转换TCP，它应该转换ICMP目标不可访问（类型3）消息。
REQ-10: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping or TCP connection for which the ICMP was generated.
REQ-10：接收任何类型的ICMP消息不得终止为其生成ICMP的NAT映射或TCP连接。
[BEHAVE-UDP] discusses security considerations for NATs that handle IP and unicast UDP traffic. Security concerns specific to handling TCP packets are discussed in this section.
[BEHAVE-UDP]讨论处理IP和单播UDP流量的NAT的安全注意事项。本节将讨论特定于处理TCP数据包的安全问题。
Security considerations for REQ-1: This requirement does not introduce any TCP-specific security concerns.
REQ-1的安全注意事项：此要求不引入任何TCP特定的安全问题。
Security considerations for REQ-2: This requirement does not introduce any TCP-specific security concerns. Simultaneous-open and other transitions in the TCP state machine are by-design and necessary for TCP to work correctly in all scenarios. Further, this requirement only affects connections already in progress as authorized by the NAT in accordance with its policy.
REQ-2的安全注意事项：此要求不引入任何TCP特定的安全问题。根据设计，TCP状态机中的同时打开和其他转换是TCP在所有场景中正常工作所必需的。此外，该要求仅影响NAT根据其政策授权的已在进行中的连接。
Security considerations for REQ-3: The security provided by the NAT is governed by its filtering behavior as addressed in [BEHAVE-UDP]. Connection-Dependent Filtering behavior is most secure from a firewall perspective, but severely restricts connection initiations through a NAT. Endpoint-Independent Filtering behavior, which is most transparent to applications, requires an attacker to guess the IP address and port of an active mapping in order to get his packet to an internal host. Address-Dependent Filtering, on the other hand, is less transparent than Endpoint-Independent Filtering but more transparent than Connection-Dependent Filtering; it is more secure than Endpoint-Independent Filtering as it requires an attacker to additionally guess the address of the external endpoint for a NAT session associated with the mapping and be able to receive packets addressed to the same. While this protects against most attackers on the Internet, it does not necessarily protect against attacks that originate from behind a remote NAT with a single IP address that is also translating a legitimate connection to the victim.
REQ-3的安全注意事项：NAT提供的安全性由其过滤行为控制，如[BEHAVE-UDP]中所述。从防火墙的角度来看，依赖于连接的过滤行为是最安全的，但严重限制了通过NAT启动连接。与端点无关的过滤行为对应用程序最为透明，它要求攻击者猜测活动映射的IP地址和端口，以便将其数据包发送到内部主机。另一方面，地址相关过滤不如端点无关过滤透明，但比连接相关过滤更透明；它比独立于端点的过滤更安全，因为它要求攻击者额外猜测与映射相关的NAT会话的外部端点地址，并能够接收发往该地址的数据包。虽然这可以防止互联网上的大多数攻击者，但它不一定能够防止来自具有单个IP地址的远程NAT背后的攻击，该IP地址还可以将合法连接转换为受害者。
Security considerations for REQ-4: This document recommends that a NAT respond to unsolicited inbound SYN packets with an ICMP error delayed by a few seconds. Doing so may reveal the presence of a NAT to an external attacker. Silently dropping the SYN makes it harder to diagnose network problems and forces applications to wait for the TCP stack to finish several retransmissions before reporting an error. An implementer must therefore understand and carefully weigh the effects of not sending an ICMP error or rate-limiting such ICMP errors to a very small number.
REQ-4的安全注意事项：本文档建议NAT对ICMP错误延迟几秒钟的未经请求的入站SYN数据包作出响应。这样做可能会向外部攻击者透露NAT的存在。静默删除SYN会使诊断网络问题变得更加困难，并迫使应用程序在报告错误之前等待TCP堆栈完成多次重新传输。因此，实施者必须理解并仔细权衡不发送ICMP错误或将此类ICMP错误限制在非常小的范围内的影响。
Security considerations for REQ-5: This document recommends that a NAT that passively monitors TCP state keep idle sessions alive for at least 2 hours 4 minutes or 4 minutes depending on the state of the connection. If a NAT is under attack, it may attempt to actively determine the liveliness of a TCP connection or let the NAT administrator configure more conservative timeouts.
REQ-5的安全注意事项：本文档建议被动监视TCP状态的NAT将空闲会话保持活动状态至少2小时4分钟或4分钟，具体取决于连接状态。如果NAT受到攻击，它可能会尝试主动确定TCP连接的活跃性，或者让NAT管理员配置更保守的超时。
Security considerations for REQ-6: This requirement does not introduce any TCP-specific security concerns.
REQ-6的安全注意事项：此要求不引入任何TCP特定的安全问题。
Security considerations for REQ-7: This requirement does not introduce any TCP-specific security concerns.
REQ-7的安全注意事项：此要求不引入任何TCP特定的安全问题。
Security considerations for REQ-8: This requirement does not introduce any TCP-specific security concerns.
REQ-8的安全注意事项：此要求不引入任何TCP特定的安全问题。
Security considerations for REQ-9: This requirement does not introduce any TCP-specific security concerns.
REQ-9的安全注意事项：此要求不引入任何TCP特定的安全问题。
Security considerations for REQ-10: This requirement does not introduce any TCP-specific security concerns.
REQ-10的安全注意事项：此要求不引入任何TCP特定的安全问题。
NAT implementations that modify TCP sequence numbers (e.g., for privacy reasons or for ALG support) must ensure that TCP packets with Selective Acknowledgement (SACK) notifications [RFC2018] are properly handled.
修改TCP序列号的NAT实现（例如出于隐私原因或ALG支持）必须确保正确处理带有选择性确认（SACK）通知[RFC2018]的TCP数据包。
NAT implementations that modify local state based on TCP flags in packets must ensure that out-of-window TCP packets are properly handled. [RFC4953] summarizes and discusses a variety of solutions designed to prevent attackers from affecting TCP connections.
基于数据包中的TCP标志修改本地状态的NAT实现必须确保正确处理窗口外TCP数据包。[RFC4953]总结并讨论了旨在防止攻击者影响TCP连接的各种解决方案。
Joe Touch contributed the mechanism for handling unsolicited inbound SYNs. Thanks to Mark Allman, Francois Audet, Lars Eggert, Paul Francis, Fernando Gont, Sam Hartman, Paul Hoffman, Dave Hudson, Cullen Jennings, Philip Matthews, Tom Petch, Magnus Westerlund, and Dan Wing for their many contributions, comments, and suggestions.
Joe Touch提供了处理未经请求的入站SYN的机制。感谢马克·奥尔曼、弗朗索瓦·奥德特、拉尔斯·艾格特、保罗·弗朗西斯、费尔南多·冈特、萨姆·哈特曼、保罗·霍夫曼、戴夫·哈德森、卡伦·詹宁斯、菲利普·马修斯、汤姆·佩奇、马格努斯·韦斯特隆德和丹·温的众多贡献、评论和建议。
[BEHAVE-UDP] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[BEHAVE-UDP]Audet，F.和C.Jennings，“单播UDP的网络地址转换（NAT）行为要求”，BCP 127，RFC 4787，2007年1月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[RFC0959]Postel，J.和J.Reynolds，“文件传输协议”，标准9，RFC 959，1985年10月。
[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]Braden，R.，“互联网主机的要求-通信层”，标准3，RFC 1122，1989年10月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[BEHAVE-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP protocol", Work in Progress, June 2008.
[BEHAVE-ICMP]Srisuresh，P.，Ford，B.，Sivakumar，S.，和S.Guha，“ICMP协议的NAT行为要求”，正在进行的工作，2008年6月。
[NAT-MIB] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and C. Wang, "Definitions of Managed Objects for Network Address Translators (NAT)", RFC 4008, March 2005.
[NAT-MIB]Rohit，R.，Srisuresh，P.，Raghunarayan，R.，Pai，N.，和C.Wang，“网络地址转换器（NAT）管理对象的定义”，RFC 4008，2005年3月。
[NATBLASTER] Biggadike, A., Ferullo, D., Wilson, G., and A. Perrig, "NATBLASTER: Establishing TCP connections between hosts behind NATs", Proceedings of the ACM SIGCOMM Asia Workshop (Beijing, China), April 2005.
[NATBLASTER]Biggadike，A.，Ferullo，D.，Wilson，G.，和A.Perrig，“NATBLASTER:在NATs背后的主机之间建立TCP连接”，ACM SIGCOMM亚洲研讨会论文集（中国北京），2005年4月。
[P2PNAT] Ford, B., Srisuresh, P., and D. Kegel, "Peer-to-peer communication across network address translators", Proceedings of the USENIX Annual Technical Conference (Anaheim, CA), April 2005.
[P2PNAT]Ford，B.，Srisuresh，P.，和D.Kegel，“跨网络地址转换器的点对点通信”，USENIX年度技术会议记录（加利福尼亚州阿纳海姆），2005年4月。
[RFC1337] Braden, B., "TIME-WAIT Assassination Hazards in TCP", RFC 1337, May 1992.
[RFC1337]Braden，B.，“TCP中的等待时间暗杀危险”，RFC 1337，1992年5月。
[RFC1644] Braden, B., "T/TCP -- TCP Extensions for Transactions Functional Specification", RFC 1644, July 1994.
[RFC1644]Braden，B，“T/TCP——事务功能规范的TCP扩展”，RFC16441994年7月。
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, October 1996.
[RFC2018]Mathis，M.，Mahdavi，J.，Floyd，S.，和A.Romanow，“TCP选择性确认选项”，RFC 2018，1996年10月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, September 2000.
[RFC2923]Lahey，K.，“路径MTU发现的TCP问题”，RFC 29232000年9月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A Roadmap for Transmission Control Protocol (TCP) Specification Documents", RFC 4614, September 2006.
[RFC4614]Duke，M.，Braden，R.，Eddy，W.，和E.Blanton，“传输控制协议（TCP）规范文件路线图”，RFC 46142006年9月。
[RFC4953] Touch, J., "Defending TCP Against Spoofing Attacks", RFC 4953, July 2007.
[RFC4953]Touch，J.“保护TCP免受欺骗攻击”，RFC 4953，2007年7月。
[STUNT] Guha, S. and P. Francis, "NUTSS: A SIP based approach to UDP and TCP connectivity", Proceedings of the ACM SIGCOMM Workshop on Future Directions in Network Architecture (Portland, OR), August 2004.
[特技]Guha，S.和P.Francis，“NUTSS：基于SIP的UDP和TCP连接方法”，ACM SIGCOMM网络体系结构未来方向研讨会论文集（俄勒冈州波特兰），2004年8月。
[TCPTRAV] Guha, S. and P. Francis, "Characterization and Measurement of TCP Traversal through NATs and Firewalls", Proceedings of the Internet Measurement Conference (Berkeley, CA), October 2005.
[TCPTRAV]Guha，S.和P.Francis，“通过NAT和防火墙的TCP穿越的特征和测量”，互联网测量会议记录（加利福尼亚州伯克利），2005年10月。
Authors' Addresses
作者地址
Saikat Guha (editor) Cornell University 331 Upson Hall Ithaca, NY 14853 US Phone: +1 607 255 1008 EMail: saikat@cs.cornell.edu
Saikat Guha（编辑）康奈尔大学331 Upson Hall Ithaca，NY 14853美国电话：+1 607 255 1008电子邮件：saikat@cs.cornell.edu
Kaushik Biswas Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134 US Phone: +1 408 525 5134 EMail: kbiswas@cisco.com
Kaushik Biswas Cisco Systems，Inc.170 West Tasman Dr.San Jose，CA 95134美国电话：+1 408 525 5134电子邮件：kbiswas@cisco.com
Bryan Ford Max Planck Institute for Software Systems Campus Building E1 4 D-66123 Saarbruecken Germany Phone: +49-681-9325657 EMail: baford@mpi-sws.org
布莱恩·福特·马克斯·普朗克软件系统研究所校园大楼E1 4 D-66123德国萨尔布鲁肯电话：+49-681-9325657电子邮件：baford@mpi-sws.org
Senthil Sivakumar Cisco Systems, Inc. 7100-8 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709-4987 US Phone: +1 919 392 5158 EMail: ssenthil@cisco.com
Senthil Sivakumar Cisco Systems，Inc.地址：美国北卡罗来纳州三角研究园14987号Kit Creek Road邮政信箱7100-8邮编：27709-4987电话：+1 919 392 5158电子邮件：ssenthil@cisco.com
Pyda Srisuresh Kazeon Systems, Inc. 1161 San Antonio Rd. Mountain View, CA 94043 US Phone: +1 408 836 4773 EMail: srisuresh@yahoo.com
Pyda Srisuresh Kazeon Systems，Inc.加利福尼亚州圣安东尼奥路1161号山景城94043美国电话：+1 408 836 4773电子邮件：srisuresh@yahoo.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.