Network Working Group F. Audet, Ed.
Request for Comments: 4787 Nortel Networks
BCP: 127 C. Jennings
Category: Best Current Practice Cisco Systems
January 2007
Network Working Group F. Audet, Ed.
Request for Comments: 4787 Nortel Networks
BCP: 127 C. Jennings
Category: Best Current Practice Cisco Systems
January 2007
Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
单播UDP的网络地址转换（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.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document defines basic terminology for describing different types of Network Address Translation (NAT) behavior when handling Unicast UDP and also defines a set of requirements that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.
本文档定义了用于描述处理单播UDP时不同类型的网络地址转换（NAT）行为的基本术语，还定义了一组允许许多应用程序（如多媒体通信或在线游戏）一致工作的要求。开发满足这组需求的NAT将大大增加这些应用程序正常运行的可能性。
Table of Contents
目录
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Network Address and Port Translation Behavior . . . . . . . . 5
4.1. Address and Port Mapping . . . . . . . . . . . . . . . . . 5
4.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Port Assignment Behavior . . . . . . . . . . . . . . . 9
4.2.2. Port Parity . . . . . . . . . . . . . . . . . . . . . 11
4.2.3. Port Contiguity . . . . . . . . . . . . . . . . . . . 11
4.3. Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 12
4.4. Conflicting Internal and External IP Address Spaces . . . 13
5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 15
6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 16
7. Application Level Gateways . . . . . . . . . . . . . . . . . . 17
8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 18
9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 19
10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 20
11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 20
12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 21
13. Security Considerations . . . . . . . . . . . . . . . . . . . 24
14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 25
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
16.1. Normative References . . . . . . . . . . . . . . . . . . . 26
16.2. Informative References . . . . . . . . . . . . . . . . . . 26
1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Network Address and Port Translation Behavior . . . . . . . . 5
4.1. Address and Port Mapping . . . . . . . . . . . . . . . . . 5
4.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Port Assignment Behavior . . . . . . . . . . . . . . . 9
4.2.2. Port Parity . . . . . . . . . . . . . . . . . . . . . 11
4.2.3. Port Contiguity . . . . . . . . . . . . . . . . . . . 11
4.3. Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 12
4.4. Conflicting Internal and External IP Address Spaces . . . 13
5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 15
6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 16
7. Application Level Gateways . . . . . . . . . . . . . . . . . . 17
8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 18
9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 19
10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 20
11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 20
12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 21
13. Security Considerations . . . . . . . . . . . . . . . . . . . 24
14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 25
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
16.1. Normative References . . . . . . . . . . . . . . . . . . . 26
16.2. Informative References . . . . . . . . . . . . . . . . . . 26
The purpose of this specification is to define a set of requirements for NATs that would allow many applications, such as multimedia communications or online gaming, to work consistently. Developing NATs that meet this set of requirements will greatly increase the likelihood that these applications will function properly.
本规范的目的是定义NAT的一组要求，以允许许多应用程序（如多媒体通信或在线游戏）一致工作。开发满足这组需求的NAT将大大增加这些应用程序正常运行的可能性。
The requirements of this specification apply to Traditional NATs as described in [RFC2663].
本规范的要求适用于[RFC2663]中所述的传统NAT。
This document is meant to cover NATs of any size, from small residential NATs to large Enterprise NATs. However, it should be understood that Enterprise NATs normally provide much more than just NAT capabilities; for example, they typically provide firewall functionalities. A comprehensive description of firewall behaviors and associated requirements is specifically out-of-scope for this specification. However, this specification does cover basic firewall aspects present in NATs (see Section 5).
本文件旨在涵盖任何规模的NAT，从小型住宅NAT到大型企业NAT。然而，应该理解的是，企业NAT通常不仅仅提供NAT功能；例如，它们通常提供防火墙功能。对防火墙行为和相关要求的全面描述超出了本规范的范围。然而，本规范确实涵盖了NAT中存在的基本防火墙方面（参见第5节）。
Approaches using directly signaled control of middle boxes are out of scope.
使用直接信号控制中间盒的方法超出范围。
UDP Relays (e.g., Traversal Using Relay NAT [TURN]) are out of scope.
UDP中继（例如，使用中继NAT[TURN]进行遍历）超出范围。
Application aspects are out of scope, as the focus here is strictly on the NAT itself.
应用程序方面超出了范围，因为这里的重点是NAT本身。
This document only covers aspects of NAT traversal related to Unicast UDP [RFC0768] over IP [RFC0791] and their dependencies on other protocols.
本文档仅涵盖与IP上的单播UDP[RFC0768]及其对其他协议的依赖性相关的NAT遍历方面。
Network Address Translators (NATs) are well known to cause very significant problems with applications that carry IP addresses in the payload (see [RFC3027]). Applications that suffer from this problem include Voice Over IP and Multimedia Over IP (e.g., SIP [RFC3261] and H.323 [ITU.H323]), as well as online gaming.
众所周知，网络地址转换器（NAT）会给在有效负载中承载IP地址的应用程序带来非常严重的问题（请参阅[RFC3027]）。受此问题影响的应用包括IP语音和IP多媒体（例如SIP[RFC3261]和H.323[ITU.H323]），以及在线游戏。
Many techniques are used to attempt to make realtime multimedia applications, online games, and other applications work across NATs. Application Level Gateways [RFC2663] are one such mechanism. STUN [RFC3489bis] describes a UNilateral Self-Address Fixing (UNSAF) mechanism [RFC3424]. Teredo [RFC4380] describes an UNSAF mechanism consisting of tunnelling IPv6 [RFC2460] over UDP/IPv4. UDP Relays have also been used to enable applications across NATs, but these are generally seen as a solution of last resort. Interactive
许多技术被用于尝试使实时多媒体应用程序、在线游戏和其他应用程序跨NAT工作。应用程序级网关[RFC2663]就是这样一种机制。STUN[RFC3489bis]描述了一种单边自地址固定（UNSAF）机制[RFC3424]。Teredo[RFC4380]描述了一种UNSAF机制，该机制包括通过UDP/IPv4对IPv6[RFC2460]进行隧道传输。UDP中继也被用于跨NAT启用应用程序，但这些通常被视为最后的解决方案。互动的
Connectivity Establishment [ICE] describes a methodology for using many of these techniques and avoiding a UDP relay, unless the type of NAT is such that it forces the use of such a UDP relay. This specification defines requirements for improving NATs. Meeting these requirements ensures that applications will not be forced to use UDP relay.
连接建立[ICE]描述了一种方法，用于使用其中许多技术并避免UDP中继，除非NAT的类型强制使用这种UDP中继。本规范规定了改进NAT的要求。满足这些要求可确保应用程序不会被迫使用UDP中继。
As pointed out in UNSAF [RFC3424], "From observations of deployed networks, it is clear that different NAT box implementations vary widely in terms of how they handle different traffic and addressing cases". This wide degree of variability is one factor in the overall brittleness introduced by NATs and makes it extremely difficult to predict how any given protocol will behave on a network traversing NAT. Discussions with many of the major NAT vendors have made it clear that they would prefer to deploy NATs that were deterministic and caused the least harm to applications while still meeting the requirements that caused their customers to deploy NATs in the first place. The problem NAT vendors face is that they are not sure how best to do that or how to document their NATs' behavior.
正如UNSAF[RFC3424]所指出的，“从对已部署网络的观察来看，很明显，不同的NAT盒实现在如何处理不同的流量和寻址情况方面存在很大差异”。这种广泛的可变性是NAT引入的整体脆弱性的一个因素，使得预测任何给定协议在穿越NAT的网络上的行为变得极其困难。与许多主要NAT供应商的讨论表明，他们更愿意部署确定性的NAT，并且对应用程序造成的危害最小，同时仍能满足客户首先部署NAT的要求。NAT供应商面临的问题是，他们不确定如何最好地做到这一点，或者如何记录他们的NAT行为。
The goals of this document are to define a set of common terminology for describing the behavior of NATs and to produce a set of requirements on a specific set of behaviors for NATs.
本文档的目标是定义一组用于描述NAT行为的通用术语，并针对NAT的一组特定行为生成一组需求。
This document forms a common set of requirements that are simple and useful for voice, video, and games, which can be implemented by NAT vendors. This document will simplify the analysis of protocols for deciding whether or not they work in this environment and will allow providers of services that have NAT traversal issues to make statements about where their applications will work and where they will not, as well as to specify their own NAT requirements.
本文档形成了一组通用的需求，这些需求对于语音、视频和游戏来说既简单又有用，可由NAT供应商实现。本文档将简化对协议的分析，以确定协议是否在此环境中工作，并允许存在NAT穿越问题的服务提供商声明其应用程序将在何处工作和将在何处不工作，以及指定其自己的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]中所述进行解释。
Readers are urged to refer to [RFC2663] for information on NAT taxonomy and terminology. Traditional NAT is the most common type of NAT device deployed. Readers may refer to [RFC3022] for detailed information on traditional NAT. Traditional NAT has two main varieties -- Basic NAT and Network Address/Port Translator (NAPT).
有关NAT分类和术语的信息，请读者参考[RFC2663]。传统NAT是部署的最常见的NAT设备类型。读者可参考[RFC3022]了解传统NAT的详细信息。传统的NAT主要有两种：基本NAT和网络地址/端口转换器（NAPT）。
NAPT is by far the most commonly deployed NAT device. NAPT allows multiple internal hosts to share a single public IP address simultaneously. When an internal host opens an outgoing TCP or UDP session through a NAPT, the NAPT assigns the session a public IP
NAPT是目前最常用的NAT设备。NAPT允许多个内部主机同时共享一个公共IP地址。当内部主机通过NAPT打开传出TCP或UDP会话时，NAPT将为会话分配公共IP
address and port number, so that subsequent response packets from the external endpoint can be received by the NAPT, translated, and forwarded to the internal host. The effect is that the NAPT establishes a NAT session to translate the (private IP address, private port number) tuple to a (public IP address, public port number) tuple, and vice versa, for the duration of the session. An issue of relevance to peer-to-peer applications is how the NAT behaves when an internal host initiates multiple simultaneous sessions from a single (private IP, private port) endpoint to multiple distinct endpoints on the external network. In this specification, the term "NAT" refers to both "Basic NAT" and "Network Address/Port Translator (NAPT)".
地址和端口号，以便NAPT可以接收来自外部端点的后续响应数据包，并将其转换和转发到内部主机。其效果是NAPT建立NAT会话，在会话期间将（私有IP地址、私有端口号）元组转换为（公共IP地址、公共端口号）元组，反之亦然。与对等应用程序相关的一个问题是，当内部主机从单个（专用IP、专用端口）端点向外部网络上的多个不同端点同时发起多个会话时，NAT的行为如何。在本规范中，术语“NAT”指的是“基本NAT”和“网络地址/端口转换器（NAPT）”。
This document uses the term "session" as defined in RFC 2663: "TCP/ UDP sessions are uniquely identified by the tuple of (source IP address, source TCP/UDP ports, target IP address, target TCP/UDP Port)".
本文档使用RFC 2663中定义的术语“会话”：“TCP/UDP会话由（源IP地址、源TCP/UDP端口、目标IP地址、目标TCP/UDP端口）的元组唯一标识”。
This document uses the term "address and port mapping" as the translation between an external address and port and an internal address and port. Note that this is not the same as an "address binding" as defined in RFC 2663.
本文档使用术语“地址和端口映射”作为外部地址和端口与内部地址和端口之间的转换。请注意，这与RFC 2663中定义的“地址绑定”不同。
This document uses IANA terminology for port ranges, i.e., "Well Known Ports" is 0-1023, "Registered" is 1024-49151, and "Dynamic and/or Private" is 49152-65535, as defined in http://www.iana.org/assignments/port-numbers.
本文档使用IANA术语表示端口范围，即“已知端口”为0-1023，“注册端口”为1024-49151，“动态和/或专用端口”为49152-65535，如中所定义http://www.iana.org/assignments/port-numbers.
STUN [RFC3489] used the terms "Full Cone", "Restricted Cone", "Port Restricted Cone", and "Symmetric" to refer to different variations of NATs applicable to UDP only. Unfortunately, this terminology has been the source of much confusion, as it has proven inadequate at describing real-life NAT behavior. This specification therefore refers to specific individual NAT behaviors instead of using the Cone/Symmetric terminology.
STUN[RFC3489]使用术语“全锥”、“受限锥”、“端口受限锥”和“对称”来表示仅适用于UDP的NAT的不同变体。不幸的是，这个术语一直是许多困惑的根源，因为它已经证明不足以描述现实生活中的NAT行为。因此，本规范引用特定的单个NAT行为，而不是使用锥形/对称术语。
This section describes the various NAT behaviors applicable to NATs.
本节介绍适用于NAT的各种NAT行为。
When an internal endpoint opens an outgoing session through a NAT, the NAT assigns the session an external IP address and port number so that subsequent response packets from the external endpoint can be received by the NAT, translated, and forwarded to the internal endpoint. This is a mapping between an internal IP address and port IP:port and external IP:port tuple. It establishes the translation
当内部端点通过NAT打开传出会话时，NAT会为会话分配外部IP地址和端口号，以便NAT可以接收、转换和转发外部端点的后续响应数据包。这是内部IP地址与端口IP:port和外部IP:port元组之间的映射。它建立了翻译
that will be performed by the NAT for the duration of the session. For many applications, it is important to distinguish the behavior of the NAT when there are multiple simultaneous sessions established to different external endpoints.
这将在会话期间由NAT执行。对于许多应用程序，当有多个同时建立到不同外部端点的会话时，区分NAT的行为是很重要的。
The key behavior to describe is the criteria for reuse of a mapping for new sessions to external endpoints, after establishing a first mapping between an internal X:x address and port and an external Y1:y1 address tuple. Let's assume that the internal IP address and port X:x are mapped to X1':x1' for this first session. The endpoint then sends from X:x to an external address Y2:y2 and gets a mapping of X2':x2' on the NAT. The relationship between X1':x1' and X2':x2' for various combinations of the relationship between Y1:y1 and Y2:y2 is critical for describing the NAT behavior. This arrangement is illustrated in the following diagram:
要描述的关键行为是在内部X:X地址和端口与外部Y1:Y1地址元组之间建立第一个映射后，重新使用新会话到外部端点的映射的标准。让我们假设内部IP地址和端口X:X被映射到第一个会话的X1'：X1'。然后，端点从X:X发送到外部地址Y2:Y2，并在NAT上获得X2'：X2'的映射。对于Y1:Y1和Y2:Y2之间关系的各种组合，X1'：X1'和X2'：X2'之间的关系对于描述NAT行为至关重要。该布置如下图所示：
E
+------+ +------+ x
| Y1 | | Y2 | t
+--+---+ +---+--+ e
| Y1:y1 Y2:y2 | r
+----------+ +----------+ n
| | a
X1':x1' | | X2':x2' l
+--+---+-+
...........| NAT |...............
+--+---+-+ I
| | n
X:x | | X:x t
++---++ e
| X | r
+-----+ n
a
l
E
+------+ +------+ x
| Y1 | | Y2 | t
+--+---+ +---+--+ e
| Y1:y1 Y2:y2 | r
+----------+ +----------+ n
| | a
X1':x1' | | X2':x2' l
+--+---+-+
...........| NAT |...............
+--+---+-+ I
| | n
X:x | | X:x t
++---++ e
| X | r
+-----+ n
a
l
Address and Port Mapping
地址和端口映射
The following address and port mapping behavior are defined:
定义了以下地址和端口映射行为：
Endpoint-Independent Mapping:
端点无关映射：
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. Specifically, X1':x1' equals X2':x2' for all values of Y2:y2.
NAT对从相同的内部IP地址和端口（X:X）发送到任何外部IP地址和端口的后续数据包重用端口映射。具体而言，对于Y2:Y2的所有值，X1'：X1'等于X2'：X2'。
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. Specifically, X1':x1' equals X2':x2' if and only if, Y2 equals Y1.
NAT对从相同的内部IP地址和端口（X:X）发送到相同的外部IP地址的后续数据包重用端口映射，而不考虑外部端口。具体地说，X1'：X1'等于X2'：X2'当且仅当Y2等于Y1。
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. Specifically, X1':x1' equals X2':x2' if and only if, Y2:y2 equals Y1:y1.
当映射仍处于活动状态时，NAT会对从相同的内部IP地址和端口（X:X）发送到相同的外部IP地址和端口的后续数据包重用端口映射。具体来说，X1'：X1'等于X2'：X2'当且仅当Y2:Y2等于Y1:Y1。
It is important to note that these three possible choices make no difference to the security properties of the NAT. The security properties are fully determined by which packets the NAT allows in and which it does not. This is determined by the filtering behavior in the filtering portions of the NAT.
需要注意的是，这三种可能的选择对NAT的安全属性没有影响。安全属性完全由NAT允许和不允许的数据包决定。这由NAT的过滤部分中的过滤行为确定。
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior.
REQ-1:NAT必须具有“端点独立映射”行为。
Justification: In order for UNSAF methods to work, REQ-1 needs to be met. Failure to meet REQ-1 will force the use of a UDP relay, which is very often impractical.
理由：为了使UNSAF方法发挥作用，需要满足REQ-1。未能满足REQ-1将强制使用UDP中继，这通常是不切实际的。
Some NATs are capable of assigning IP addresses from a pool of IP addresses on the external side of the NAT, as opposed to just a single IP address. This is especially common with larger NATs. Some NATs use the external IP address mapping in an arbitrary fashion (i.e., randomly): one internal IP address could have multiple external IP address mappings active at the same time for different sessions. These NATs have an "IP address pooling" behavior of "Arbitrary". Some large Enterprise NATs use an IP address pooling behavior of "Arbitrary" as a means of hiding the IP address assigned to specific endpoints by making their assignment less predictable. Other NATs use the same external IP address mapping for all sessions associated with the same internal IP address. These NATs have an "IP address pooling" behavior of "Paired". NATs that use an "IP address pooling" behavior of "Arbitrary" can cause issues for applications that use multiple ports from the same endpoint, but that do not negotiate IP addresses individually (e.g., some applications using RTP and RTCP).
有些NAT能够从NAT外部的IP地址池中分配IP地址，而不仅仅是一个IP地址。这在较大的NAT中尤其常见。某些NAT以任意方式（即随机）使用外部IP地址映射：一个内部IP地址可以同时为不同会话激活多个外部IP地址映射。这些NAT具有“任意”的“IP地址池”行为。隐藏特定于企业的IP地址意味着将其“大IP池”分配为可预测的NAT。其他NAT对与相同内部IP地址关联的所有会话使用相同的外部IP地址映射。这些NAT具有“配对”的“IP地址池”行为。使用“任意”的“IP地址池”行为的NAT可能会导致使用来自同一端点的多个端口但不单独协商IP地址的应用程序出现问题（例如，某些使用RTP和RTCP的应用程序）。
REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" behavior of "Paired". Note that this requirement is not applicable to NATs that do not support IP address pooling.
REQ-2：建议NAT具有“配对”的“IP地址池”行为。请注意，此要求不适用于不支持IP地址池的NAT。
Justification: This will allow applications that use multiple ports originating from the same internal IP address to also have the same external IP address. This is to avoid breaking peer-to-peer applications that are not capable of negotiating the IP address for RTP and the IP address for RTCP separately. As such it is envisioned that this requirement will become less important as applications become NAT-friendlier with time. The main reason why this requirement is here is that in a peer-to-peer application, you are subject to the other peer's mistake. In particular, in the context of SIP, if my application supports the extensions defined in [RFC3605] for indicating RTP and RTCP addresses and ports separately, but the other peer does not, there may still be breakage in the form of the stream losing RTCP packets. This requirement will avoid the loss of RTP in this context, although the loss of RTCP may be inevitable in this particular example. It is also worth noting that RFC 3605 is unfortunately not a mandatory part of SIP [RFC3261]. Therefore, this requirement will address a particularly nasty problem that will prevail for a significant period of time.
理由：这将允许使用源自相同内部IP地址的多个端口的应用程序也具有相同的外部IP地址。这是为了避免中断无法分别协商RTP的IP地址和RTCP的IP地址的对等应用程序。因此，随着时间的推移，应用程序变得更加NAT友好，预计这一需求将变得不那么重要。这一要求出现在这里的主要原因是，在对等应用程序中，您会受到其他对等方错误的影响。特别是，在SIP的上下文中，如果我的应用程序支持[RFC3605]中定义的用于分别指示RTP和RTCP地址和端口的扩展，但另一个对等方不支持，则仍可能以流丢失RTCP数据包的形式出现中断。在这种情况下，该要求将避免RTP的损失，尽管在这个特定示例中RTCP的损失可能是不可避免的。还值得注意的是，RFC 3605不幸不是SIP[RFC3261]的强制性部分。因此，这项要求将解决一个在相当长一段时间内普遍存在的特别棘手的问题。
This section uses the following diagram for reference.
本节使用下图作为参考。
E
+-------+ +-------+ x
| Y1 | | Y2 | t
+---+---+ +---+---+ e
| Y1:y1 Y2:y2 | r
+---------+ +---------+ n
| | a
X1':x1' | | X2':x2' l
+--+---+--+
...........| NAT |...............
+--+---+--+ I
| | n
+---------+ +---------+ t
| X1:x1 X2:x2 | e
+---+---+ +---+---+ r
| X1 | | X2 | n
+-------+ +-------+ a
l
E
+-------+ +-------+ x
| Y1 | | Y2 | t
+---+---+ +---+---+ e
| Y1:y1 Y2:y2 | r
+---------+ +---------+ n
| | a
X1':x1' | | X2':x2' l
+--+---+--+
...........| NAT |...............
+--+---+--+ I
| | n
+---------+ +---------+ t
| X1:x1 X2:x2 | e
+---+---+ +---+---+ r
| X1 | | X2 | n
+-------+ +-------+ a
l
Port Assignment
港口分配
Some NATs attempt to preserve the port number used internally when assigning a mapping to an external IP address and port (e.g., x1=x1', x2=x2'). This port assignment behavior is referred to as "port preservation". In case of port collision, these NATs attempt a variety of techniques for coping. For example, some NATs will overridden the previous mapping to preserve the same port. Other NATs will assign a different IP address from a pool of external IP addresses; this is only possible as long as the NAT has enough external IP addresses; if the port is already in use on all available external IP addresses, then these NATs will pick a different port (i.e., they don't do port preservation anymore).
一些NAT试图保留在分配到外部IP地址和端口的映射时内部使用的端口号（例如，x1=x1'，x2=x2'）。此端口分配行为称为“端口保留”。在端口冲突的情况下，这些NAT尝试各种技术来应对。例如，某些NAT将覆盖以前的映射以保留相同的端口。其他NAT将从外部IP地址池中分配不同的IP地址；这只有在NAT有足够的外部IP地址时才可能；如果端口已经在所有可用的外部IP地址上使用，那么这些NAT将选择不同的端口（即，它们不再进行端口保留）。
Some NATs use "Port overloading", i.e., they always use port preservation even in the case of collision (i.e., X1'=X2' and x1=x2=x1'=x2'). Most applications will fail if the NAT uses "Port overloading".
一些NAT使用“端口过载”，即即使在发生冲突的情况下（即X1'=X2'和X1=X2=X1'=X2'），它们也始终使用端口保留。如果NAT使用“端口重载”，大多数应用程序都会失败。
A NAT that does not attempt to make the external port numbers match the internal port numbers in any case is referred to as "no port preservation".
在任何情况下都不尝试使外部端口号与内部端口号匹配的NAT称为“无端口保留”。
When NATs do allocate a new source port, there is the issue of which IANA-defined range of port to choose. The ranges are "well-known" from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/ private" from 49152 through 65535. For most protocols, these are destination ports and not source ports, so mapping a source port to a source port that is already registered is unlikely to have any bad effects. Some NATs may choose to use only the ports in the dynamic range; the only downside of this practice is that it limits the number of ports available. Other NAT devices may use everything but the well-known range and may prefer to use the dynamic range first, or possibly avoid the actual registered ports in the registered range. Other NATs preserve the port range if it is in the well-known range. [RFC0768] specifies that the source port is set to zero if no reply packets are expected. In this case, it does not matter what the NAT maps it to, as the source port will not be used. However, many common OS APIs do not allow a user to send from port zero, applications do not use port zero, and the behavior of various existing NATs with regards to a packet with a source of port zero is unknown. This document does not specify any normative behavior for a NAT when handling a packet with a source port of zero which means that applications cannot count on any sort of deterministic behavior for these packets.
当NAT分配一个新的源端口时，就有一个问题，即选择哪个IANA定义的端口范围。范围从0到1023“众所周知”，从1024到49151“注册”，从49152到65535“动态/私有”。对于大多数协议，它们是目标端口而不是源端口，因此将源端口映射到已注册的源端口不太可能产生任何不良影响。一些NAT可能选择只使用动态范围内的端口；这种做法的唯一缺点是限制了可用端口的数量。其他NAT设备可以使用除已知范围之外的所有设备，并且可能更喜欢首先使用动态范围，或者可能避免注册范围中的实际注册端口。如果端口范围在已知范围内，其他NAT将保留该端口范围。[RFC0768]指定如果不需要应答数据包，则将源端口设置为零。在这种情况下，NAT将其映射到什么并不重要，因为将不使用源端口。然而，许多常见的操作系统API不允许用户从零端口发送，应用程序不使用零端口，并且各种现有NAT对于具有零端口源的数据包的行为是未知的。当处理源端口为零的数据包时，本文档没有为NAT指定任何规范性行为，这意味着应用程序不能依赖这些数据包的任何确定性行为。
REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading".
REQ-3:NAT不得具有“端口重载”的“端口分配”行为。
a) If the host's source port was in the range 0-1023, it is RECOMMENDED the NAT's source port be in the same range. If the host's source port was in the range 1024-65535, it is RECOMMENDED that the NAT's source port be in that range.
a) 如果主机的源端口在0-1023范围内，建议NAT的源端口在同一范围内。如果主机的源端口在1024-65535范围内，建议NAT的源端口在该范围内。
Justification: This requirement must be met in order to enable two applications on the internal side of the NAT both to use the same port to try to communicate with the same destination. NATs that implement port preservation have to deal with conflicts on ports, and the multiple code paths this introduces often result in nondeterministic behavior. However, it should be understood that when a port is randomly assigned, it may just randomly happen to be assigned the same port. Applications must, therefore, be able to deal with both port preservation and no port preservation.
理由：为了使NAT内部的两个应用程序都能够使用相同的端口尝试与相同的目的地通信，必须满足此要求。实现端口保留的NAT必须处理端口上的冲突，而这引入的多个代码路径通常会导致不确定性行为。然而，应该理解的是，当一个端口被随机分配时，它可能恰好被随机分配到同一个端口。因此，应用程序必须能够同时处理港口保全和非港口保全。
a) Certain applications expect the source UDP port to be in the well-known range. See the discussion of Network File System port expectations in [RFC2623] for an example.
a) 某些应用程序希望源UDP端口在已知范围内。有关示例，请参见[RFC2623]中对网络文件系统端口期望的讨论。
Some NATs preserve the parity of the UDP port, i.e., an even port will be mapped to an even port, and an odd port will be mapped to an odd port. This behavior respects the [RFC3550] rule that RTP use even ports, and RTCP use odd ports. RFC 3550 allows any port numbers to be used for RTP and RTCP if the two numbers are specified separately; for example, using [RFC3605]. However, some implementations do not include RFC 3605, and do not recognize when the peer has specified the RTCP port separately using RFC 3605. If such an implementation receives an odd RTP port number from the peer (perhaps after having been translated by a NAT), and then follows the RFC 3550 rule to change the RTP port to the next lower even number, this would obviously result in the loss of RTP. NAT-friendly application aspects are outside the scope of this document. It is expected that this issue will fade away with time, as implementations improve. Preserving the port parity allows for supporting communication with peers that do not support explicit specification of both RTP and RTCP port numbers.
一些NAT保留UDP端口的奇偶性，即偶数端口将映射到偶数端口，奇数端口将映射到奇数端口。此行为遵守[RFC3550]规则，即RTP使用偶数端口，RTCP使用奇数端口。RFC 3550允许RTP和RTCP使用任何端口号（如果两个端口号分别指定）；例如，使用[RFC3605]。但是，一些实现不包括RFC 3605，并且不识别对等方何时使用RFC 3605单独指定RTCP端口。如果这样的实现从对等方接收奇数RTP端口号（可能在被NAT转换之后），然后遵循RFC 3550规则将RTP端口更改为下一个更低的偶数，这显然会导致RTP丢失。NAT友好的应用方面不在本文档的范围内。随着实现的改进，这个问题预计会随着时间的推移逐渐消失。保留端口奇偶校验允许支持与不支持RTP和RTCP端口号明确规范的对等方的通信。
REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" behavior of "Yes".
REQ-4：建议NAT的“端口奇偶校验保留”行为为“是”。
Justification: This is to avoid breaking peer-to-peer applications that do not explicitly and separately specify RTP and RTCP port numbers and that follow the RFC 3550 rule to decrement an odd RTP port to make it even. The same considerations apply, as per the IP address pooling requirement.
理由：这是为了避免中断没有明确和单独指定RTP和RTCP端口号，并且遵循RFC 3550规则减少奇数RTP端口以使其偶数的对等应用程序。根据IP地址池要求，同样的考虑也适用。
Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. These NATs do things like sequential assignment or port reservation. Sequential port assignment assumes that the application will open a mapping for RTP first and then open a mapping for RTCP. It is not practical to enforce this requirement on all applications. Furthermore, there is a problem with glare if many applications (or endpoints) are trying to open mappings simultaneously. Port preservation is also problematic since it is wasteful, especially considering that a NAT cannot reliably distinguish between RTP over UDP and other UDP packets where there is no contiguity rule. For those reasons, it would be too complex to attempt to preserve the contiguity rule by suggesting specific NAT behavior, and it would certainly break the deterministic behavior rule.
某些NAT试图保留RTCP=RTP+1的端口连续性规则。这些NAT执行顺序分配或端口预留等操作。顺序端口分配假定应用程序将首先为RTP打开映射，然后为RTCP打开映射。在所有应用程序上强制执行此要求是不实际的。此外，如果许多应用程序（或端点）试图同时打开映射，则眩光会出现问题。端口保留也是有问题的，因为它是浪费的，特别是考虑到NAT不能可靠地区分UDP上的RTP和其他没有连续性规则的UDP数据包。出于这些原因，试图通过建议特定的NAT行为来保持连续性规则将过于复杂，而且肯定会打破确定性行为规则。
In order to support both RTP and RTCP, it will therefore be necessary that applications follow rules to negotiate RTP and RTCP separately, and account for the very real possibility that the RTCP=RTP+1 rule
因此，为了同时支持RTP和RTCP，应用程序必须遵循规则分别协商RTP和RTCP，并考虑RTCP=RTP+1规则的实际可能性
will be broken. As this is an application requirement, it is outside the scope of this document.
将被打破。由于这是一项应用要求，因此不在本文件的范围内。
NAT mapping timeout implementations vary, but include the timer's value and the way the mapping timer is refreshed to keep the mapping alive.
NAT映射超时实现各不相同，但包括计时器的值以及刷新映射计时器以保持映射活动的方式。
The mapping timer is defined as the time a mapping will stay active without packets traversing the NAT. There is great variation in the values used by different NATs.
映射计时器被定义为一个映射在没有数据包通过NAT的情况下保持活动状态的时间。不同NAT使用的值差异很大。
REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two minutes, unless REQ-5a applies.
REQ-5：NAT UDP映射计时器不得在两分钟内过期，除非REQ-5a适用。
a) For specific destination ports in the well-known port range (ports 0-1023), a NAT MAY have shorter UDP mapping timers that are specific to the IANA-registered application running over that specific destination port.
a) 对于众所周知的端口范围（端口0-1023）中的特定目标端口，NAT可能具有较短的UDP映射计时器，这些计时器特定于在该特定目标端口上运行的IANA注册应用程序。
b) The value of the NAT UDP mapping timer MAY be configurable.
b) NAT UDP映射计时器的值可以配置。
c) A default value of five minutes or more for the NAT UDP mapping timer is RECOMMENDED.
c) 建议NAT UDP映射计时器的默认值为5分钟或更长时间。
Justification: This requirement is to ensure that the timeout is long enough to avoid too-frequent timer refresh packets.
理由：此要求是为了确保超时时间足够长，以避免计时器刷新数据包过于频繁。
a) Some UDP protocols using UDP use very short-lived connections. There can be very many such connections; keeping them all in a connections table could cause considerable load on the NAT. Having shorter timers for these specific applications is, therefore, an optimization technique. It is important that the shorter timers applied to specific protocols be used sparingly, and only for protocols using well-known destination ports that are known to have a shorter timer, and that are known not to be used by any applications for other purposes.
a) 一些使用UDP的UDP协议使用非常短的连接。可能有很多这样的联系；将它们全部保存在连接表中可能会对NAT造成相当大的负载。因此，为这些特定应用程序提供更短的时间是一种优化技术。重要的是，应用于特定协议的较短计时器应尽量少用，并且仅适用于使用已知具有较短计时器且已知不会被任何应用程序用于其他目的的已知目标端口的协议。
b) Configuration is desirable for adapting to specific networks and troubleshooting.
b) 需要配置以适应特定网络和故障排除。
c) This default is to avoid too-frequent timer refresh packets.
c) 此默认设置是为了避免计时器刷新数据包过于频繁。
Some NATs keep the mapping active (i.e., refresh the timer value) when a packet goes from the internal side of the NAT to the external side of the NAT. This is referred to as having a NAT Outbound refresh behavior of "True".
当数据包从NAT的内部侧转到NAT的外部侧时，一些NAT保持映射活动（即刷新计时器值）。这称为NAT出站刷新行为为“True”。
Some NATs keep the mapping active when a packet goes from the external side of the NAT to the internal side of the NAT. This is referred to as having a NAT Inbound Refresh Behavior of "True".
当一个数据包从NAT的外部到达NAT的内部时，一些NAT保持映射活动。这称为NAT入站刷新行为为“True”。
Some NATs keep the mapping active on both, in which case, both properties are "True".
有些NAT在两个属性上都保持映射活动，在这种情况下，两个属性都是“True”。
REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound refresh behavior" of "True".
REQ-6:NAT映射刷新方向的“NAT出站刷新行为”必须为“真”。
a) The NAT mapping Refresh Direction MAY have a "NAT Inbound refresh behavior" of "True".
a) NAT映射刷新方向的“NAT入站刷新行为”可能为“True”。
Justification: Outbound refresh is necessary for allowing the client to keep the mapping alive.
理由：出站刷新是允许客户端保持映射活动的必要条件。
a) Inbound refresh may be useful for applications with no outgoing UDP traffic. However, allowing inbound refresh may allow an external attacker or misbehaving application to keep a mapping alive indefinitely. This may be a security risk. Also, if the process is repeated with different ports, over time, it could use up all the ports on the NAT.
a) 入站刷新对于没有传出UDP通信的应用程序可能很有用。但是，允许入站刷新可能会允许外部攻击者或行为不端的应用程序无限期地保持映射活动。这可能是一种安全风险。此外，如果在不同的端口上重复该过程，随着时间的推移，它可能会耗尽NAT上的所有端口。
Many NATs, particularly consumer-level devices designed to be deployed by nontechnical users, routinely obtain their external IP address, default router, and other IP configuration information for their external interface dynamically from an external network, such as an upstream ISP. The NAT, in turn, automatically sets up its own internal subnet in one of the private IP address spaces assigned to this purpose in [RFC1918], typically providing dynamic IP configuration services for hosts on this internal network.
许多NAT，特别是设计由非技术用户部署的消费者级设备，通常从外部网络（如上游ISP）动态获取其外部IP地址、默认路由器和其外部接口的其他IP配置信息。反过来，NAT会在[RFC1918]中为此目的分配的一个专用IP地址空间中自动设置自己的内部子网，通常为该内部网络上的主机提供动态IP配置服务。
Auto-configuration of NATs and private networks can be problematic, however, if the NAT's external network is also in RFC 1918 private address space. In a common scenario, an ISP places its customers behind a NAT and hands out private RFC 1918 addresses to them. Some of these customers, in turn, deploy consumer-level NATs, which, in effect, act as "second-level" NATs, multiplexing their own private RFC 1918 IP subnets onto the single RFC 1918 IP address provided by the ISP. There is no inherent guarantee, in this case, that the ISP's "intermediate" privately-addressed network and the customer's internal privately-addressed network will not use numerically identical or overlapping RFC 1918 IP subnets. Furthermore, customers of consumer-level NATs cannot be expected to have the technical
但是，如果NAT的外部网络也在RFC1918专用地址空间中，NAT和专用网络的自动配置可能会有问题。在一个常见的场景中，ISP将其客户置于NAT后面，并向他们分发专用RFC1918地址。这些客户中的一些反过来部署消费者级NAT，实际上，这些NAT充当“第二级”NAT，将他们自己的专用RFC 1918 IP子网多路复用到ISP提供的单个RFC 1918 IP地址上。在这种情况下，无法保证ISP的“中间”专用寻址网络和客户的内部专用寻址网络不会使用数字相同或重叠的RFC 1918 IP子网。此外，不能指望消费者级NAT的客户拥有技术支持
knowledge to prevent this scenario from occurring by manually configuring their internal network with non-conflicting RFC 1918 subnets.
通过手动配置具有非冲突RFC 1918子网的内部网络来防止这种情况发生的知识。
NAT vendors need to design their NATs to ensure that they function correctly and robustly even in such problematic scenarios. One possible solution is for the NAT to ensure that whenever its external link is configured with an RFC 1918 private IP address, the NAT automatically selects a different, non-conflicting RFC 1918 IP subnet for its internal network. A disadvantage of this solution is that, if the NAT's external interface is dynamically configured or re-configured after its internal network is already in use, then the NAT may have to renumber its entire internal network dynamically if it detects a conflict.
NAT供应商需要设计他们的NAT，以确保即使在这种有问题的场景中，它们也能正确、稳健地运行。一种可能的解决方案是，NAT确保每当其外部链路配置RFC 1918专用IP地址时，NAT都会自动为其内部网络选择一个不同的、不冲突的RFC 1918 IP子网。该解决方案的一个缺点是，如果NAT的外部接口在其内部网络已经使用后被动态配置或重新配置，那么NAT可能必须在检测到冲突时动态地重新编号其整个内部网络。
An alternative solution is for the NAT to be designed so that it can translate and forward traffic correctly, even when its external and internal interfaces are configured with numerically overlapping IP subnets. In this scenario, for example, if the NAT's external interface has been assigned an IP address P in RFC 1918 space, then there might also be an internal node I having the same RFC 1918 private IP address P. An IP packet with destination address P on the external network is directed at the NAT, whereas an IP packet with the same destination address P on the internal network is directed at node I. The NAT therefore needs to maintain a clear operational distinction between "external IP addresses" and "internal IP addresses" to avoid confusing internal node I with its own external interface. In general, the NAT needs to allow all internal nodes (including I) to communicate with all external nodes having public (non-RFC 1918) IP addresses, or having private IP addresses that do not conflict with the addresses used by its internal network.
另一种解决方案是设计NAT，使其能够正确地转换和转发流量，即使其外部和内部接口配置有数字重叠的IP子网。在该场景中，例如，如果NAT的外部接口已在RFC 1918空间中分配了IP地址P，则也可能存在具有相同RFC 1918专用IP地址P的内部节点I。外部网络上具有目的地地址P的IP分组指向NAT，而内部网络上具有相同目的地址P的IP数据包指向节点I。因此，NAT需要在“外部IP地址”和“内部IP地址”之间保持清晰的操作区别，以避免将内部节点I与其自身的外部接口混淆。通常，NAT需要允许所有内部节点（包括I）与具有公共（非RFC 1918）IP地址或具有与其内部网络使用的地址不冲突的私有IP地址的所有外部节点通信。
REQ-7: A NAT device whose external IP interface can be configured dynamically MUST either (1) automatically ensure that its internal network uses IP addresses that do not conflict with its external network, or (2) be able to translate and forward traffic between all internal nodes and all external nodes whose IP addresses numerically conflict with the internal network.
REQ-7：可以动态配置外部IP接口的NAT设备必须（1）自动确保其内部网络使用与其外部网络不冲突的IP地址，或（2）能够在所有内部节点和IP地址与内部网络冲突的所有外部节点之间转换和转发流量。
Justification: If a NAT's external and internal interfaces are configured with overlapping IP subnets, then there is, of course, no way for an internal host with RFC 1918 IP address Q to initiate a direct communication session to an external node having the same RFC 1918 address Q, or to other external nodes with IP addresses that numerically conflict with the internal subnet. Such nodes can still open communication sessions indirectly via NAT traversal techniques, however, with the help of a third-party server, such as a STUN server having a public, non-RFC 1918 IP address. In
理由：如果NAT的外部和内部接口配置有重叠的IP子网，则具有RFC 1918 IP地址Q的内部主机当然无法启动与具有相同RFC 1918地址Q的外部节点的直接通信会话，或到IP地址与内部子网在数字上冲突的其他外部节点。然而，在第三方服务器（例如具有公共、非RFC 1918ip地址的STUN服务器）的帮助下，这样的节点仍然可以通过NAT遍历技术间接地打开通信会话。在里面
this case, nodes with conflicting private RFC 1918 addresses on opposite sides of the second-level NAT can communicate with each other via their respective temporary public endpoints on the main Internet, as long as their common, first-level NAT (e.g., the upstream ISP's NAT) supports hairpinning behavior, as described in Section 6.
在这种情况下，在第二级NAT的相对侧具有冲突的私有RFC 1918地址的节点可以通过其各自在主因特网上的临时公共端点彼此通信，只要其公共的第一级NAT（例如，上游ISP的NAT）支持发夹行为，如第6节所述。
This section describes various filtering behaviors observed in NATs.
本节描述在NAT中观察到的各种过滤行为。
When an internal endpoint opens an outgoing session through a NAT, the NAT assigns a filtering rule for the mapping between an internal IP:port (X:x) and external IP:port (Y:y) tuple.
当内部端点通过NAT打开传出会话时，NAT会为内部IP:port（X:X）和外部IP:port（Y:Y）元组之间的映射分配筛选规则。
The key behavior to describe is what criteria are used by the NAT to filter packets originating from specific external endpoints.
要描述的关键行为是NAT使用什么标准来过滤来自特定外部端点的数据包。
Endpoint-Independent Filtering:
端点独立筛选：
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地址足以允许任何数据包返回到内部端点。
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:
与地址和端口相关的筛选：
This is similar to the previous behavior, except that the external port is also relevant. 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地址和端口。
REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have an "Endpoint-Independent Filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have an "Address-Dependent Filtering" behavior.
REQ-8：如果应用程序透明性是最重要的，建议NAT具有“端点独立过滤”行为。如果更严格的过滤行为是最重要的，建议NAT具有“地址相关过滤”行为。
a) The filtering behavior MAY be an option configurable by the administrator of the NAT.
a) 过滤行为可能是NAT管理员可配置的选项。
Justification: The recommendation to use Endpoint-Independent Filtering is aimed at maximizing application transparency; in particular, for applications that receive media simultaneously from multiple locations (e.g., gaming), or applications that use rendezvous techniques. However, it is also possible that, in some circumstances, it may be preferable to have a more stringent filtering behavior. Filtering independently of the external endpoint is not as secure: An unauthorized packet could get through a specific port while the port was kept open if it was lucky enough to find the port open. In theory, filtering based on both IP address and port is more secure than filtering based only on the IP address (because the external endpoint could, in reality, be two endpoints behind another NAT, where one of the two endpoints is an attacker). However, such a policy could interfere with applications that expect to receive UDP packets on more than one UDP port. Using Endpoint-Independent Filtering or Address-Dependent Filtering instead of Address and Port-Dependent Filtering on a NAT (say, NAT-A) also has benefits when the other endpoint is behind a non-BEHAVE compliant NAT (say, NAT-B) that does not support REQ-1. When the endpoints use ICE, if NAT-A uses Address and Port-Dependent Filtering, connectivity will require a UDP relay. However, if NAT-A uses Endpoint-Independent Filtering or Address-Dependent Filtering, ICE will ultimately find connectivity without requiring a UDP relay. Having the filtering behavior being an option configurable by the administrator of the NAT ensures that a NAT can be used in the widest variety of deployment scenarios.
理由：建议使用端点独立过滤的目的是最大限度地提高应用程序的透明度；特别是，对于同时从多个位置接收媒体的应用程序（例如，游戏），或使用会合技术的应用程序。然而，也可能在某些情况下，最好具有更严格的过滤行为。独立于外部端点进行过滤并不安全：未经授权的数据包可能通过特定端口，而该端口保持打开状态，前提是它幸运地发现该端口打开。理论上，基于IP地址和端口的过滤比仅基于IP地址的过滤更安全（因为实际上，外部端点可能是另一个NAT后面的两个端点，其中一个端点是攻击者）。但是，这样的策略可能会干扰期望在多个UDP端口上接收UDP数据包的应用程序。当另一个端点位于不支持REQ-1的不符合行为的NAT（例如NAT-B）后面时，在NAT（例如NAT-a）上使用端点独立过滤或地址依赖过滤而不是地址和端口依赖过滤也有好处。当端点使用ICE时，如果NAT-A使用地址和端口相关过滤，则连接将需要UDP中继。然而，如果NAT-A使用端点独立过滤或地址依赖过滤，ICE最终将在不需要UDP中继的情况下找到连接。将过滤行为作为NAT管理员可配置的选项，可以确保NAT可以在最广泛的部署场景中使用。
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 and is illustrated below.
如果两台主机（称为X1和X2）位于同一NAT后面并交换流量，则NAT可以在NAT外部为X2分配一个地址，称为X2'：X2'。如果X1将流量发送到X2'：X2'，它将发送到NAT，NAT必须将流量从X1中继到X2。这被称为发夹，如下所示。
NAT
+----+ from X1:x1 to X2':x2' +-----+ X1':x1'
| X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+---
+----+ | v |
| v |
| v |
| v |
+----+ from X1':x1' to X2:x2 | v | X2':x2'
| X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+---
+----+ +-----+
NAT
+----+ from X1:x1 to X2':x2' +-----+ X1':x1'
| X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+---
+----+ | v |
| v |
| v |
| v |
+----+ from X1':x1' to X2:x2 | v | X2':x2'
| X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+---
+----+ +-----+
Hairpinning Behavior
发夹行为
Hairpinning allows two endpoints on the internal side of the NAT to communicate even if they only use each other's external IP addresses and ports.
发夹允许NAT内部的两个端点进行通信，即使它们只使用彼此的外部IP地址和端口。
More formally, a NAT that supports hairpinning forwards packets originating from an internal address, X1:x1, destined for an external address X2':x2' that has an active mapping to an internal address X2:x2, back to that internal address, X2:x2. Note that typically X1' is the same as X2'.
更正式地说，支持发夹的NAT将源自内部地址X1:X1、目的地为外部地址X2'：X2'的数据包转发回内部地址X2:X2。请注意，通常X1'与X2'相同。
Furthermore, the NAT may present the hairpinned packet with either an internal (X1:x1) or an external (X1':x1') source IP address and port. Therefore, the hairpinning NAT behavior can be either "External source IP address and port" or "Internal source IP address and port". "Internal source IP address and port" may cause problems by confusing implementations that expect an external IP address and port.
此外，NAT可以向发夹分组提供内部（X1:X1）或外部（X1’：X1’）源IP地址和端口。因此，发夹NAT行为可以是“外部源IP地址和端口”或“内部源IP地址和端口”。“内部源IP地址和端口”可能会由于混淆预期外部IP地址和端口的实现而导致问题。
REQ-9: A NAT MUST support "Hairpinning".
要求9:NAT必须支持“发夹”。
a) A NAT Hairpinning behavior MUST be "External source IP address and port".
a) NAT发夹行为必须是“外部源IP地址和端口”。
Justification: This requirement is to allow communications between two endpoints behind the same NAT when they are trying each other's external IP addresses.
理由：该要求允许在同一NAT后面的两个端点尝试彼此的外部IP地址时进行通信。
a) Using the external source IP address is necessary for applications with a restrictive policy of not accepting packets from IP addresses that differ from what is expected.
a) 对于具有不接受来自不同于预期的IP地址的数据包的限制性策略的应用程序，必须使用外部源IP地址。
Certain NATs have implemented Application Level Gateways (ALGs) for various protocols, including protocols for negotiating peer-to-peer sessions, such as SIP.
某些NAT已经为各种协议实现了应用级网关（ALG），包括用于协商对等会话的协议，如SIP。
Certain NATs have these ALGs turned on permanently, others have them turned on by default but allow them to be turned off, and others have them turned off by default but allow them be turned on.
某些NAT将这些ALG永久打开，其他NAT将其默认打开但允许关闭，其他NAT将其默认关闭但允许打开。
NAT ALGs may interfere with UNSAF methods or protocols that try to be NAT-aware and therefore must be used with extreme caution.
NAT ALG可能会干扰尝试感知NAT的UNSAF方法或协议，因此必须极其小心地使用。
REQ-10: To eliminate interference with UNSAF NAT traversal mechanisms and allow integrity protection of UDP communications, NAT ALGs for UDP-based protocols SHOULD be turned off. Future standards track specifications that define ALGs can update this to recommend the defaults for the ALGs that they define.
REQ-10：为了消除对UNSAF NAT遍历机制的干扰并允许UDP通信的完整性保护，应关闭基于UDP协议的NAT ALG。未来的标准跟踪定义ALG的规范，可以对此进行更新，以推荐它们定义的ALG的默认值。
a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the NAT administrator to enable or disable each ALG separately.
a) 如果NAT包括ALG，建议NAT允许NAT管理员分别启用或禁用每个ALG。
Justification: NAT ALGs may interfere with UNSAF methods.
理由：NAT ALGs可能会干扰UNSAF方法。
a) This requirement allows the user to enable those ALGs that are necessary to aid in the operation of some applications without enabling ALGs, which interfere with the operation of other applications.
a) 此要求允许用户在不启用ALG的情况下启用辅助某些应用程序运行所需的ALG，因为ALG会干扰其他应用程序的运行。
The classification of NATs is further complicated by the fact that, under some conditions, the same NAT will exhibit different behaviors. This has been seen on NATs that preserve ports or have specific algorithms for selecting a port other than a free one. If the external port that the NAT wishes to use is already in use by another session, the NAT must select a different port. This results in different code paths for this conflict case, which results in different behavior.
NAT的分类更加复杂，因为在某些情况下，相同的NAT会表现出不同的行为。这在保留端口或使用特定算法来选择自由端口以外的端口的NAT上可以看到。如果NAT希望使用的外部端口已被另一个会话使用，则NAT必须选择其他端口。这将导致此冲突案例的不同代码路径，从而导致不同的行为。
For example, if three hosts X1, X2, and X3 all send from the same port x, through a port preserving NAT with only one external IP address, called X1', the first one to send (i.e., X1) will get an external port of x, but the next two will get x2' and x3' (where these are not equal to x). There are NATs where the External NAT mapping characteristics and the External Filter characteristics change between the X1:x and the X2:x mapping. To make matters worse, there are NATs where the behavior may be the same on the X1:x and X2:x mappings, but different on the third X3:x mapping.
例如，如果三台主机X1、X2和X3都从同一端口x发送，则通过仅具有一个外部IP地址（称为X1'）的端口保留NAT发送，第一台要发送的主机（即X1）将获得一个外部端口x，但下两台主机将获得X2'和X3'（其中它们不等于x）。存在外部NAT映射特性和外部滤波器特性在X1:x和X2:x映射之间变化的NAT。更糟糕的是，有些NAT在X1:x和X2:x映射上的行为可能相同，但在第三个X3:x映射上的行为不同。
Another example is that some NATs have an "Endpoint-Independent Mapping", combined with "Port Overloading", as long as two endpoints are not establishing sessions to the same external direction, but then switch their behavior to "Address and Port-Dependent Mapping"
另一个例子是，一些NAT具有“端点独立映射”，并结合“端口重载”，只要两个端点不建立指向相同外部方向的会话，而是将其行为切换到“地址和端口依赖映射”
without "Port Preservation" upon detection of these conflicting sessions establishments.
在检测到这些冲突的会议场所后，没有“港口保护”。
Any NAT that changes the NAT Mapping or the Filtering behavior without configuration changes, at any point in time, under any particular conditions, is referred to as a "non-deterministic" NAT. NATs that don't are called "deterministic".
在任何特定条件下，在任何时间点改变NAT映射或过滤行为而不改变配置的任何NAT称为“非确定性”NAT。不确定的NAT称为“确定性”。
Non-deterministic NATs generally change behavior when a conflict of some sort happens, i.e., when the port that would normally be used is already in use by another mapping. The NAT mapping and External Filtering in the absence of conflict is referred to as the Primary behavior. The behavior after the first conflict is referred to as Secondary and after the second conflict is referred to as Tertiary. No NATs have been observed that change on further conflicts, but it is certainly possible that they exist.
非确定性NAT通常会在发生某种冲突时改变行为，例如，当正常使用的端口已被另一个映射使用时。在没有冲突的情况下，NAT映射和外部过滤被称为主要行为。第一次冲突后的行为称为第二次冲突，第二次冲突后的行为称为第三次冲突。没有观察到NAT会因进一步的冲突而改变，但它们肯定有可能存在。
REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT change the NAT translation (Section 4) or the Filtering (Section 5) Behavior at any point in time, or under any particular conditions.
REQ-11:NAT必须具有确定性行为，即在任何时间点或任何特定条件下，NAT不得改变NAT转换（第4节）或过滤（第5节）行为。
Justification: Non-deterministic NATs are very difficult to troubleshoot because they require more intensive testing. This non-deterministic behavior is the root cause of much of the uncertainty that NATs introduce about whether or not applications will work.
理由：非确定性NAT很难排除故障，因为它们需要更密集的测试。这种不确定性行为是NAT引入的关于应用程序是否工作的许多不确定性的根本原因。
When a NAT sends a packet toward a host on the other side of the NAT, an ICMP message may be sent in response to that packet. That ICMP message may be sent by the destination host or by any router along the network path. The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address. Such ICMP messages SHOULD be rewritten by the NAT (specifically, the IP headers and the ICMP payload) and forwarded to the appropriate internal or external host. The NAT needs to perform this function for as long as the UDP mapping is active. Receipt of any sort of ICMP message MUST NOT destroy the NAT mapping. A NAT that performs the functions described in the paragraph above is referred to as "support ICMP Processing".
当NAT向NAT另一侧的主机发送数据包时，可以发送ICMP消息以响应该数据包。该ICMP消息可由目标主机或网络路径上的任何路由器发送。NAT的默认配置不应根据ICMP消息的源IP地址过滤ICMP消息。此类ICMP消息应由NAT重写（特别是IP头和ICMP负载），并转发到适当的内部或外部主机。只要UDP映射处于活动状态，NAT就需要执行此功能。接收任何类型的ICMP消息不得破坏NAT映射。执行上文所述功能的NAT称为“支持ICMP处理”。
There is no significant security advantage to blocking ICMP Destination Unreachable packets. Additionally, blocking ICMP Destination Unreachable packets can interfere with application failover, UDP Path MTU Discovery (see [RFC1191] and [RFC1435]), and traceroute. Blocking any ICMP message is discouraged, and blocking ICMP Destination Unreachable is strongly discouraged.
阻止ICMP目标无法访问的数据包没有显著的安全优势。此外，阻止ICMP目标无法访问的数据包可能会干扰应用程序故障切换、UDP路径MTU发现（请参阅[RFC1191]和[RFC1435]）和跟踪路由。不建议阻止任何ICMP消息，强烈建议阻止无法访问ICMP目标。
REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping.
REQ-12：接收任何类型的ICMP消息不得终止NAT映射。
a) The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address.
a) NAT的默认配置不应根据ICMP消息的源IP地址过滤ICMP消息。
b) It is RECOMMENDED that a NAT support ICMP Destination Unreachable messages.
b) 建议NAT支持ICMP目标无法访问的消息。
Justification: This is easy to do and is used for many things including MTU discovery and rapid detection of error conditions, and has no negative consequences.
理由：这很容易做到，并用于许多事情，包括MTU发现和错误条件的快速检测，并且没有负面后果。
When the MTU of the adjacent link is too small, fragmentation of packets going from the internal side to the external side of the NAT may occur. This can occur if the NAT is doing Point-to-Point over Ethernet (PPPoE), or if the NAT has been configured with a small MTU to reduce serialization delay when sending large packets and small higher-priority packets, or for other reasons.
当相邻链路的MTU太小时，可能发生从NAT的内部侧到外部侧的分组的分段。如果NAT正在通过以太网进行点对点（PPPoE），或者如果NAT配置了小型MTU以减少发送大型数据包和小型高优先级数据包时的序列化延迟，或者由于其他原因，则可能会发生这种情况。
It is worth noting that many IP stacks do not use Path MTU Discovery with UDP packets.
值得注意的是，许多IP堆栈不使用UDP数据包的路径MTU发现。
The packet could have its Don't Fragment bit set to 1 (DF=1) or 0 (DF=0).
数据包的“不分段”位可以设置为1（DF=1）或0（DF=0）。
REQ-13: If the packet received on an internal IP address has DF=1, the NAT MUST send back an ICMP message "Fragmentation needed and DF set" to the host, as described in [RFC0792].
REQ-13：如果在内部IP地址上接收的数据包的DF=1，则NAT必须向主机发回ICMP消息“需要分段并设置DF”，如[RFC0792]所述。
a) If the packet has DF=0, the NAT MUST fragment the packet and SHOULD send the fragments in order.
a) 如果数据包的DF=0，NAT必须对数据包进行分段，并按顺序发送这些分段。
Justification: This is as per RFC 792.
理由：这符合RFC 792。
a) This is the same function a router performs in a similar situation [RFC1812].
a) 这与路由器在类似情况下执行的功能相同[RFC1812]。
For a variety of reasons, a NAT may receive a fragmented packet. The IP packet containing the header could arrive in any fragment, depending on network conditions, packet ordering, and the implementation of the IP stack that generated the fragments.
出于各种原因，NAT可以接收分段分组。包含报头的IP数据包可能以任何片段的形式到达，这取决于网络条件、数据包顺序以及生成片段的IP堆栈的实现。
A NAT that is capable only of receiving fragments in order (that is, with the header in the first packet) and forwarding each of the fragments to the internal host is described as "Received Fragments Ordered".
仅能够按顺序接收片段（即，头部在第一个分组中）并将每个片段转发到内部主机的NAT被描述为“已接收片段已排序”。
A NAT that is capable of receiving fragments in or out of order and forwarding the individual fragments (or a reassembled packet) to the internal host is referred to as "Receive Fragments Out of Order". See the Security Considerations section of this document for a discussion of this behavior.
能够接收有序或无序的片段并将单个片段（或重新组装的数据包）转发到内部主机的NAT称为“无序接收片段”。有关此行为的讨论，请参阅本文档的“安全注意事项”部分。
A NAT that is neither of these is referred to as "Receive Fragments None".
两者都不是的NAT称为“无接收片段”。
REQ-14: A NAT MUST support receiving in-order and out-of-order fragments, so it MUST have "Received Fragment Out of Order" behavior.
REQ-14:NAT必须支持按顺序和无序接收片段，因此它必须具有“按顺序接收片段”行为。
a) A NAT's out-of-order fragment processing mechanism MUST be designed so that fragmentation-based DoS attacks do not compromise the NAT's ability to process in-order and unfragmented IP packets.
a) NAT无序碎片处理机制的设计必须确保基于碎片的DoS攻击不会损害NAT处理有序和未碎片IP数据包的能力。
Justification: See Security Considerations.
理由：参见安全注意事项。
The requirements in this section are aimed at minimizing the complications caused by NATs to applications, such as realtime communications and online gaming. The requirements listed earlier in the document are consolidated here into a single section.
本节中的要求旨在最大限度地减少NAT对实时通信和在线游戏等应用程序造成的复杂性。本文件前面列出的要求在此合并为一个章节。
It should be understood, however, that applications normally do not know in advance if the NAT conforms to the recommendations defined in this section. Peer-to-peer media applications still need to use normal procedures, such as ICE [ICE].
然而，应该理解的是，应用程序通常不会事先知道NAT是否符合本节中定义的建议。对等媒体应用程序仍然需要使用正常的过程，如ICE[ICE]。
A NAT that supports all the mandatory requirements of this specification (i.e., the "MUST"), is "compliant with this specification". A NAT that supports all the requirements of this specification (i.e., including the "RECOMMENDED") is "fully compliant with all the mandatory and recommended requirements of this specification".
支持本规范所有强制性要求（即“必须”）的NAT“符合本规范”。支持本规范所有要求（即，包括“推荐”）的NAT“完全符合本规范的所有强制性和推荐要求”。
REQ-1: A NAT MUST have an "Endpoint-Independent Mapping" behavior.
REQ-1:NAT必须具有“端点独立映射”行为。
REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" behavior of "Paired". Note that this requirement is not applicable to NATs that do not support IP address pooling.
REQ-2：建议NAT具有“配对”的“IP地址池”行为。请注意，此要求不适用于不支持IP地址池的NAT。
REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port overloading".
REQ-3:NAT不得具有“端口重载”的“端口分配”行为。
a) If the host's source port was in the range 0-1023, it is RECOMMENDED the NAT's source port be in the same range. If the host's source port was in the range 1024-65535, it is RECOMMENDED that the NAT's source port be in that range.
a) 如果主机的源端口在0-1023范围内，建议NAT的源端口在同一范围内。如果主机的源端口在1024-65535范围内，建议NAT的源端口在该范围内。
REQ-4: It is RECOMMENDED that a NAT have a "Port parity preservation" behavior of "Yes".
REQ-4：建议NAT的“端口奇偶校验保留”行为为“是”。
REQ-5: A NAT UDP mapping timer MUST NOT expire in less than two minutes, unless REQ-5a applies.
REQ-5：NAT UDP映射计时器不得在两分钟内过期，除非REQ-5a适用。
a) For specific destination ports in the well-known port range (ports 0-1023), a NAT MAY have shorter UDP mapping timers that are specific to the IANA-registered application running over that specific destination port.
a) 对于众所周知的端口范围（端口0-1023）中的特定目标端口，NAT可能具有较短的UDP映射计时器，这些计时器特定于在该特定目标端口上运行的IANA注册应用程序。
b) The value of the NAT UDP mapping timer MAY be configurable.
b) NAT UDP映射计时器的值可以配置。
c) A default value of five minutes or more for the NAT UDP mapping timer is RECOMMENDED.
c) 建议NAT UDP映射计时器的默认值为5分钟或更长时间。
REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound refresh behavior" of "True".
REQ-6:NAT映射刷新方向的“NAT出站刷新行为”必须为“真”。
a) The NAT mapping Refresh Direction MAY have a "NAT Inbound refresh behavior" of "True".
a) NAT映射刷新方向的“NAT入站刷新行为”可能为“True”。
REQ-7 A NAT device whose external IP interface can be configured dynamically MUST either (1) Automatically ensure that its internal network uses IP addresses that do not conflict with its external network, or (2) Be able to translate and forward traffic between all internal nodes and all external nodes whose IP addresses numerically conflict with the internal network.
REQ-7可动态配置外部IP接口的NAT设备必须（1）自动确保其内部网络使用的IP地址与其外部网络不冲突，或（2）能够在所有内部节点和IP地址与内部网络冲突的所有外部节点之间转换和转发流量。
REQ-8: If application transparency is most important, it is RECOMMENDED that a NAT have "Endpoint-Independent Filtering" behavior. If a more stringent filtering behavior is most important, it is RECOMMENDED that a NAT have "Address-Dependent Filtering" behavior.
REQ-8：如果应用程序透明性是最重要的，建议NAT具有“端点独立过滤”行为。如果更严格的过滤行为是最重要的，建议NAT具有“地址相关过滤”行为。
a) The filtering behavior MAY be an option configurable by the administrator of the NAT.
a) 过滤行为可能是NAT管理员可配置的选项。
REQ-9: A NAT MUST support "Hairpinning".
要求9:NAT必须支持“发夹”。
a) A NAT Hairpinning behavior MUST be "External source IP address and port".
a) NAT发夹行为必须是“外部源IP地址和端口”。
REQ-10: To eliminate interference with UNSAF NAT traversal mechanisms and allow integrity protection of UDP communications, NAT ALGs for UDP-based protocols SHOULD be turned off. Future standards track specifications that define an ALG can update this to recommend the ALGs on which they define default.
REQ-10：为了消除对UNSAF NAT遍历机制的干扰并允许UDP通信的完整性保护，应关闭基于UDP协议的NAT ALG。未来的标准跟踪定义ALG的规范，可以对此进行更新，以推荐定义默认值的ALG。
a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow the NAT administrator to enable or disable each ALG separately.
a) 如果NAT包括ALG，建议NAT允许NAT管理员分别启用或禁用每个ALG。
REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT change the NAT translation (Section 4) or the Filtering (Section 5) Behavior at any point in time, or under any particular conditions.
REQ-11:NAT必须具有确定性行为，即在任何时间点或任何特定条件下，NAT不得改变NAT转换（第4节）或过滤（第5节）行为。
REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the NAT mapping.
REQ-12：接收任何类型的ICMP消息不得终止NAT映射。
a) The NAT's default configuration SHOULD NOT filter ICMP messages based on their source IP address.
a) NAT的默认配置不应根据ICMP消息的源IP地址过滤ICMP消息。
b) It is RECOMMENDED that a NAT support ICMP Destination Unreachable messages.
b) 建议NAT支持ICMP目标无法访问的消息。
REQ-13 If the packet received on an internal IP address has DF=1, the NAT MUST send back an ICMP message "Fragmentation needed and DF set" to the host, as described in [RFC0792].
REQ-13如果在内部IP地址上接收的数据包的DF=1，则NAT必须向主机发回ICMP消息“需要分段并设置DF”，如[RFC0792]所述。
a) If the packet has DF=0, the NAT MUST fragment the packet and SHOULD send the fragments in order.
a) 如果数据包的DF=0，NAT必须对数据包进行分段，并按顺序发送这些分段。
REQ-14: A NAT MUST support receiving in-order and out-of-order fragments, so it MUST have "Received Fragment Out of Order" behavior.
REQ-14:NAT必须支持按顺序和无序接收片段，因此它必须具有“按顺序接收片段”行为。
a) A NAT's out-of-order fragment processing mechanism MUST be designed so that fragmentation-based DoS attacks do not compromise the NAT's ability to process in-order and unfragmented IP packets.
a) NAT无序碎片处理机制的设计必须确保基于碎片的DoS攻击不会损害NAT处理有序和未碎片IP数据包的能力。
NATs are often deployed to achieve security goals. Most of the recommendations and requirements in this document do not affect the security properties of these devices, but a few of them do have security implications and are discussed in this section.
NAT的部署通常是为了实现安全目标。本文档中的大多数建议和要求不会影响这些设备的安全属性，但其中一些建议和要求确实具有安全含义，本节将对此进行讨论。
This document recommends that the timers for mapping be refreshed on outgoing packets (see REQ-6) and does not make recommendations about whether or not inbound packets should update the timers. If inbound packets update the timers, an external attacker can keep the mapping alive forever and attack future devices that may end up with the same internal address. A device that was also the DHCP server for the private address space could mitigate this by cleaning any mappings when a DHCP lease expired. For unicast UDP traffic (the scope of this document), it may not seem relevant to support inbound timer refresh; however, for multicast UDP, the question is harder. It is expected that future documents discussing NAT behavior with multicast traffic will refine the requirements around handling of the inbound refresh timer. Some devices today do update the timers on inbound packets.
本文档建议在传出数据包上刷新映射计时器（请参阅REQ-6），并且不建议入站数据包是否应更新计时器。如果入站数据包更新计时器，则外部攻击者可以使映射永远保持活动状态，并攻击可能最终使用相同内部地址的未来设备。同时也是专用地址空间的DHCP服务器的设备可以通过在DHCP租约到期时清除任何映射来缓解此问题。对于单播UDP流量（本文档的范围），支持入站计时器刷新似乎不相关；然而，对于多播UDP，问题就更难了。预计未来讨论NAT行为和多播流量的文档将细化对入站刷新计时器处理的要求。如今，有些设备确实会更新入站数据包上的计时器。
This document recommends that the NAT filters be specific to the external IP address only (see REQ-8) and not to the external IP address and UDP port. It can be argued that this is less secure than using the IP and port. Devices that wish to filter on IP and port do still comply with these requirements.
本文档建议NAT筛选器仅针对外部IP地址（请参阅REQ-8），而不针对外部IP地址和UDP端口。可以说，这比使用IP和端口更不安全。希望在IP和端口上进行过滤的设备仍然符合这些要求。
Non-deterministic NATs are risky from a security point of view. They are very difficult to test because they are, well, non-deterministic. Testing by a person configuring one may result in the person thinking it is behaving as desired, yet under different conditions, which an attacker can create, the NAT may behave differently. These requirements recommend that devices be deterministic.
从安全角度来看，非确定性NAT是有风险的。它们很难测试，因为它们是不确定的。由配置NAT的人员进行测试可能会导致该人员认为它的行为符合要求，但在攻击者可以创建的不同条件下，NAT的行为可能会有所不同。这些要求建议设备具有确定性。
This document requires that NATs have an "external NAT mapping is endpoint independent" behavior. This does not reduce the security of devices. Which packets are allowed to flow across the device is determined by the external filtering behavior, which is independent of the mapping behavior.
本文档要求NAT具有“外部NAT映射与端点无关”的行为。这不会降低设备的安全性。允许哪些数据包在设备上流动由外部过滤行为决定，外部过滤行为独立于映射行为。
When a fragmented packet is received from the external side, and the packets are out of order so that the initial fragment does not arrive first, many systems simply discard the out-of-order packets. Moreover, since some networks deliver small packets ahead of large ones, there can be many out-of-order fragments. NATs that are capable of delivering these out-of-order packets are possible, but they need to store the out-of-order fragments, which can open up a
当从外部接收到碎片数据包时，数据包的顺序发生了变化，因此初始碎片不会首先到达，许多系统会简单地丢弃这些顺序错误的数据包。此外，由于一些网络在大数据包之前发送小数据包，因此可能会有许多无序碎片。能够传递这些无序数据包的NAT是可能的，但它们需要存储无序片段，这可能会打开
Denial-of-Service (DoS) opportunity, if done incorrectly. Fragmentation has been a tool used in many attacks, some involving passing fragmented packets through NATs, and others involving DoS attacks based on the state needed to reassemble the fragments. NAT implementers should be aware of [RFC3128] and [RFC1858].
拒绝服务（DoS）机会，如果操作不正确。碎片一直是许多攻击中使用的工具，一些攻击涉及通过NAT传递碎片数据包，另一些攻击涉及基于重新组装碎片所需状态的DoS攻击。NAT实现者应该知道[RFC3128]和[RFC1858]。
The IAB has studied the problem of "Unilateral Self Address Fixing", which is the general process by which a client attempts to determine its address in another realm on the other side of a NAT through a collaborative protocol reflection mechanism [RFC3424].
IAB研究了“单边自我地址固定”问题，这是一个一般过程，通过该过程，客户机试图通过协作协议反射机制确定其在NAT另一端另一领域的地址[RFC3424]。
This specification does not, in itself, constitute an UNSAF application. It consists of a series of requirements for NATs aimed at minimizing the negative impact that those devices have on peer-to-peer media applications, especially when those applications are using UNSAF methods.
本规范本身并不构成UNSAF应用程序。它包括一系列NAT要求，旨在最大限度地减少这些设备对对等媒体应用程序的负面影响，特别是当这些应用程序使用UNSAF方法时。
Section 3 of UNSAF lists several practical issues with solutions to NAT problems. This document makes recommendations to reduce the uncertainty and problems introduced by these practical issues with NATs. In addition, UNSAF lists five architectural considerations. Although this is not an UNSAF proposal, it is interesting to consider the impact of this work on these architectural considerations.
UNSAF第3节列出了几个实际问题以及NAT问题的解决方案。本文件提出了减少NAT实际问题带来的不确定性和问题的建议。此外，UNSAF列出了五个架构方面的考虑。虽然这不是一个不安全的建议，但考虑到这项工作对这些建筑考虑的影响是有趣的。
Arch-1: The scope of this is limited to UDP packets in NATs like the ones widely deployed today. The "fix" helps constrain the variability of NATs for true UNSAF solutions such as STUN.
Arch-1：其范围仅限于NAT中的UDP数据包，就像今天广泛部署的数据包一样。“修复”有助于限制NAT对于真正的UNSAF解决方案（如STUN）的可变性。
Arch-2: This will exit at the same rate that NATs exit. It does not imply any protocol machinery that would continue to live after NATs were gone, or make it more difficult to remove them.
Arch-2：这将以与NATs退出相同的速率退出。这并不意味着任何协议机制会在NAT消失后继续存在，或者使移除它们变得更加困难。
Arch-3: This does not reduce the overall brittleness of NATs, but will hopefully reduce some of the more outrageous NAT behaviors and make it easer to discuss and predict NAT behavior in given situations.
Arch-3：这并没有降低NAT的整体脆弱性，但有望减少一些更令人不快的NAT行为，并使讨论和预测特定情况下的NAT行为变得更容易。
Arch-4: This work and the results [RESULTS] of various NATs represent the most comprehensive work at IETF on what the real issues are with NATs for applications like VoIP. This work and STUN have pointed out, more than anything else, the brittleness NATs introduce and the difficulty of addressing these issues.
Arch-4：这项工作和各种NAT的结果[结果]代表了IETF关于NAT在VoIP等应用中的真正问题的最全面的工作。这项工作和STUN已经指出，NAT带来的脆弱性以及解决这些问题的困难比其他任何东西都要多。
Arch-5: This work and the test results [RESULTS] provide a reference model for what any UNSAF proposal might encounter in deployed NATs.
Arch-5：这项工作和测试结果[结果]为任何UNSAF提案在部署的NAT中可能遇到的问题提供了参考模型。
The editor would like to acknowledge Bryan Ford, Pyda Srisuresh, and Dan Kegel for their multiple contributions on peer-to-peer communications across a NAT. Dan Wing contributed substantial text on IP fragmentation and ICMP behavior. Thanks to Rohan Mahy, Jonathan Rosenberg, Mary Barnes, Melinda Shore, Lyndsay Campbell, Geoff Huston, Jiri Kuthan, Harald Welte, Steve Casner, Robert Sanders, Spencer Dawkins, Saikat Guha, Christian Huitema, Yutaka Takeda, Paul Hoffman, Lisa Dusseault, Pekka Savola, Peter Koch, Jari Arkko, and Alfred Hoenes for their contributions.
编辑要感谢Bryan Ford、Pyda Srisuresh和Dan Kegel对NAT上的点对点通信做出的多方面贡献。Dan Wing就IP碎片和ICMP行为提供了大量文本。感谢Rohan Mahy、Jonathan Rosenberg、Mary Barnes、Melinda Shore、Lyndsay Campbell、Geoff Huston、Jiri Kuthan、Harald Welte、Steve Casner、Robert Sanders、Spencer Dawkins、Saikat Guha、Christian Huitema、Yutaka Takeda、Paul Hoffman、Lisa Dusseault、Pekka Savola、Peter Koch、Jari Arkko和Alfred Hones的贡献。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[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月。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU Discovery", RFC 1435, March 1993.
[RFC1435]Knowles，S.，“来自Path MTU发现经验的IESG建议”，RFC 1435，1993年3月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858]Ziemba，G.，Reed，D.，和P.Trana，“IP片段过滤的安全考虑”，RFC 1858，1995年10月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", RFC 2623, June 1999.
[RFC2623]Eisler，M.，“NFS版本2和版本3的安全问题以及NFS协议对RPCSEC_GSS和Kerberos V5的使用”，RFC 2623，1999年6月。
[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月。
[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月。
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[RFC3027]Holdrege，M.和P.Srisuresh，“IP网络地址转换器的协议复杂性”，RFC 3027，2001年1月。
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3128]Miller，I.，“防止微小碎片攻击的变体（RFC 1858）”，RFC 31281001年6月。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424]Daigle，L.和IAB，“网络地址转换中单边自地址固定（UNSAF）的IAB考虑”，RFC 34242002年11月。
[RFC3489] 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.
[RFC3489]Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[RFC3605]Huitema，C.，“会话描述协议（SDP）中的实时控制协议（RTCP）属性”，RFC3605，2003年10月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC3489bis] Rosenberg, J., "Simple Traversal Underneath Network Address Translators (NAT) (STUN)", Work in Progress, October 2006.
[RFC3489bis]Rosenberg，J.，“网络地址转换器（NAT）（STUN）下的简单遍历”，正在进行的工作，2006年10月。
[ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2006.
[ICE]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历方法”，正在进行的工作，2006年10月。
[RESULTS] Jennings, C., "NAT Classification Test Results", Work in Progress, October 2006.
[结果]Jennings，C.，“NAT分类测试结果”，正在进行的工作，2006年10月。
[TURN] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal Underneath NAT (STUN)", Work in Progress, October 2006.
[TURN]Rosenberg，J.，“通过NAT下的简单遍历（STUN）获取中继地址”，正在进行的工作，2006年10月。
[ITU.H323] "Packet-based Multimedia Communications Systems", ITU-T Recommendation H.323, July 2003.
[ITU.H323]“基于分组的多媒体通信系统”，ITU-T建议H.323，2003年7月。
Authors' Addresses
作者地址
Francois Audet (editor) Nortel Networks 4655 Great America Parkway Santa Clara, CA 95054 US
弗朗索瓦·奥德特（编辑）北电网络4655美国加利福尼亚州圣克拉拉大美洲大道95054
Phone: +1 408 495 2456
EMail: audet@nortel.com
Phone: +1 408 495 2456
EMail: audet@nortel.com
Cullen Jennings Cisco Systems 170 West Tasman Drive MS: SJC-21/2 San Jose, CA 95134 US
Cullen Jennings Cisco Systems 170西塔斯曼大道MS:SJC-21/2美国加利福尼亚州圣何塞95134
Phone: +1 408 902 3341
EMail: fluffy@cisco.com
Phone: +1 408 902 3341
EMail: fluffy@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。