Network Working Group P. Srisuresh
Request for Comments: 2663 M. Holdrege
Category: Informational Lucent Technologies
August 1999
Network Working Group P. Srisuresh
Request for Comments: 2663 M. Holdrege
Category: Informational Lucent Technologies
August 1999
IP Network Address Translator (NAT) Terminology and Considerations
IP网络地址转换器（NAT）术语和注意事项
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Preface
前言
The motivation behind this document is to provide clarity to the terms used in conjunction with Network Address Translators. The term "Network Address Translator" means different things in different contexts. The intent of this document is to define the various flavors of NAT and standardize the meaning of terms used.
本文档背后的动机是为与网络地址转换器一起使用的术语提供清晰的说明。术语“网络地址转换器”在不同的上下文中有不同的含义。本文件旨在定义NAT的各种风格，并标准化所用术语的含义。
The authors listed are editors for this document and owe the content to contributions from members of the working group. Large chunks of the document titled, "IP Network Address Translator (NAT)" were extracted almost as is, to form the initial basis for this document. The editors would like to thank the authors Pyda Srisuresh and Kjeld Egevang for the same. The editors would like to thank Praveen Akkiraju for his contributions in describing NAT deployment scenarios. The editors would also like to thank the IESG members Scott Bradner, Vern Paxson and Thomas Narten for their detailed review of the document and adding clarity to the text.
所列作者是本文件的编辑，其内容应归功于工作组成员的贡献。标题为“IP网络地址转换器（NAT）”的文档中的大块内容几乎按原样提取，以构成本文档的初始基础。编辑们同样要感谢作者Pyda Srisuresh和Kjeld Egevang。编辑们要感谢Praveen Akkiraju在描述NAT部署场景方面的贡献。编辑们还要感谢IESG成员斯科特·布拉德纳、弗恩·帕克森和托马斯·纳滕对该文件进行了详细审查，并使文本更加清晰。
Abstract
摘要
Network Address Translation is a method by which IP addresses are mapped from one realm to another, in an attempt to provide transparent routing to hosts. Traditionally, NAT devices are used to connect an isolated address realm with private unregistered addresses to an external realm with globally unique registered addresses. This document attempts to describe the operation of NAT devices and the associated considerations in general, and to define the terminology used to identify various flavors of NAT.
网络地址转换是一种将IP地址从一个领域映射到另一个领域的方法，旨在为主机提供透明的路由。传统上，NAT设备用于将具有私有未注册地址的隔离地址域连接到具有全局唯一注册地址的外部域。本文档试图描述NAT设备的操作和相关注意事项，并定义用于识别各种NAT风格的术语。
The need for IP Address translation arises when a network's internal IP addresses cannot be used outside the network either because they are invalid for use outside, or because the internal addressing must be kept private from the external network.
当网络的内部IP地址不能在网络外部使用时，就需要进行IP地址转换，这可能是因为它们在外部使用时无效，或者是因为内部地址必须对外部网络保密。
Address translation allows (in many cases, except as noted in sections 8 and 9) hosts in a private network to transparently communicate with destinations on an external network and vice versa. There are a variety of flavors of NAT and terms to match them. This document attempts to define the terminology used and to identify various flavors of NAT. The document also attempts to describe other considerations applicable to NAT devices in general.
地址转换允许（在许多情况下，除第8节和第9节所述外）专用网络中的主机与外部网络上的目的地进行透明通信，反之亦然。NAT有多种口味和术语可与之匹配。本文档试图定义所使用的术语，并确定NAT的各种风格。本文件还试图描述一般适用于NAT设备的其他注意事项。
Note, however, this document is not intended to describe the operations of individual NAT variations or the applicability of NAT devices.
然而，请注意，本文件并不打算描述单个NAT变体的操作或NAT设备的适用性。
NAT devices attempt to provide a transparent routing solution to end hosts trying to communicate from disparate address realms. This is achieved by modifying end node addresses en-route and maintaining state for these updates so that datagrams pertaining to a session are routed to the right end-node in either realm. This solution only works when the applications do not use the IP addresses as part of the protocol itself. For example, identifying endpoints using DNS names rather than addresses makes applications less dependent of the actual addresses that NAT chooses and avoids the need to also translate payload contents when NAT changes an IP address.
NAT设备试图为试图从不同地址域进行通信的终端主机提供透明的路由解决方案。这是通过修改路由中的终端节点地址并维护这些更新的状态来实现的，以便与会话相关的数据报路由到任一域中的右端节点。此解决方案仅在应用程序不使用IP地址作为协议本身的一部分时有效。例如，使用DNS名称而不是地址来识别端点，可以减少应用程序对NAT选择的实际地址的依赖性，并避免在NAT更改IP地址时也需要转换有效负载内容。
The NAT function cannot by itself support all applications transparently and often must co-exist with application level gateways (ALGs) for this reason. People looking to deploy NAT based solutions need to determine their application requirements first and assess the NAT extensions (i.e., ALGs) necessary to provide application transparency for their environment.
NAT功能本身不能透明地支持所有应用程序，因此通常必须与应用程序级网关（ALG）共存。希望部署基于NAT的解决方案的人员需要首先确定其应用程序需求，并评估为其环境提供应用程序透明性所需的NAT扩展（即ALG）。
IPsec techniques which are intended to preserve the Endpoint addresses of an IP packet will not work with NAT enroute for most applications in practice. Techniques such as AH and ESP protect the contents of the IP headers (including the source and destination addresses) from modification. Yet, NAT's fundamental role is to alter the addresses in the IP header of a packet.
IPsec技术旨在保留IP数据包的端点地址，但实际上在大多数应用程序的NAT途中，IPsec技术不起作用。AH和ESP等技术可以保护IP头的内容（包括源地址和目标地址）不被修改。然而，NAT的基本作用是改变数据包IP报头中的地址。
Terms most frequently used in the context of NAT are defined here for reference.
在NAT上下文中最常用的术语在此定义以供参考。
An address realm is a network domain in which the network addresses are uniquely assigned to entities such that datagrams can be routed to them. Routing protocols used within the network domain are responsible for finding routes to entities given their network addresses. Note that this document is limited to describing NAT in IPv4 environment and does not address the use of NAT in other types of environment. (e.g. IPv6 environments)
地址域是一个网络域，其中网络地址被唯一地分配给实体，以便数据报可以路由到实体。网络域中使用的路由协议负责查找到给定网络地址的实体的路由。请注意，本文档仅限于描述IPv4环境中的NAT，不涉及NAT在其他类型环境中的使用。（如IPv6环境）
The term "transparent routing" is used throughout the document to identify the routing functionality that a NAT device provides. This is different from the routing functionality provided by a traditional router device in that a traditional router routes packets within a single address realm.
术语“透明路由”在整个文档中用于标识NAT设备提供的路由功能。这与传统路由器设备提供的路由功能不同，传统路由器在单个地址域内路由数据包。
Transparent routing refers to routing a datagram between disparate address realms, by modifying address contents in the IP header to be valid in the address realm into which the datagram is routed. Section 3.2 has a detailed description of transparent routing.
透明路由是指在不同的地址域之间路由数据报，方法是修改IP报头中的地址内容，使其在数据报路由到的地址域中有效。第3.2节详细描述了透明路由。
Connection or session flows are different from packet flows. A session flow indicates the direction in which the session was initiated with reference to a network interface. Packet flow is the direction in which the packet has traveled with reference to a network interface. Take for example, an outbound telnet session. The telnet session consists of packet flows in both inbound and outbound directions. Outbound telnet packets carry terminal keystrokes and inbound telnet packets carry screen displays from the telnet server.
连接或会话流与数据包流不同。会话流指示会话相对于网络接口启动的方向。数据包流是数据包相对于网络接口的移动方向。以出站telnet会话为例。telnet会话由入站和出站方向的数据包流组成。出站telnet数据包携带终端按键，入站telnet数据包携带来自telnet服务器的屏幕显示。
For purposes of discussion in this document, a session is defined as the set of traffic that is managed as a unit for translation. TCP/UDP sessions are uniquely identified by the tuple of (source IP address, source TCP/UDP port, target IP address, target TCP/UDP port). ICMP query sessions are identified by the tuple of (source IP address, ICMP query ID, target IP address). All other sessions are characterized by the tuple of (source IP address, target IP address, IP protocol).
为了在本文档中进行讨论，会话被定义为作为翻译单元进行管理的一组通信量。TCP/UDP会话由（源IP地址、源TCP/UDP端口、目标IP地址、目标TCP/UDP端口）的元组唯一标识。ICMP查询会话由（源IP地址、ICMP查询ID、目标IP地址）的元组标识。所有其他会话都以元组（源IP地址、目标IP地址、IP协议）为特征。
Address translations performed by NAT are session based and would include translation of incoming as well as outgoing packets belonging to that session. Session direction is identified by the direction of the first packet of that session (see sec 2.5).
NAT执行的地址转换是基于会话的，包括对属于该会话的传入和传出数据包的转换。会话方向由该会话的第一个数据包的方向标识（见第2.5节）。
Note, there is no guarantee that the idea of a session, determined as above by NAT, will coincide with the application's idea of a session. An application might view a bundle of sessions (as viewed by NAT) as a single session and might not even view its communication with its peers as a session. Not all applications are guaranteed to work across realms, even with an ALG (defined below in section 2.9) enroute.
注意，不能保证NAT确定的会话想法与应用程序的会话想法一致。应用程序可能将会话包（由NAT查看）视为单个会话，甚至可能不会将其与对等方的通信视为会话。并非所有应用程序都能跨领域工作，即使在途中有ALG（定义见下文第2.9节）。
For the reminder of this document, we will refer TCP/UDP ports associated with an IP address simply as "TU ports".
为了提醒您注意本文档，我们将与IP地址关联的TCP/UDP端口简称为“TU端口”。
For most TCP/IP hosts, TU port range 0-1023 is used by servers listening for incoming connections. Clients trying to initiate a connection typically select a source TU port in the range of 1024- 65535. However, this convention is not universal and not always followed. Some client stations initiate connections using a source TU port number in the range of 0-1023, and there are servers listening on TU port numbers in the range of 1024-65535.
对于大多数TCP/IP主机，侦听传入连接的服务器使用TU端口范围0-1023。尝试启动连接的客户端通常选择1024-65535范围内的源TU端口。然而，这项公约并不普遍，也不总是得到遵守。有些客户端站使用0-1023范围内的源TU端口号启动连接，有些服务器监听1024-65535范围内的TU端口号。
A list of assigned TU port services may be found in RFC 1700 [Ref 2].
分配的TU端口服务列表可在RFC 1700[参考文献2]中找到。
The first packet of every TCP session tries to establish a session and contains connection startup information. The first packet of a TCP session may be recognized by the presence of SYN bit and absence of ACK bit in the TCP flags. All TCP packets, with the exception of the first packet, must have the ACK bit set.
每个TCP会话的第一个数据包尝试建立会话，并包含连接启动信息。TCP会话的第一个分组可以通过TCP标志中存在SYN位和不存在ACK位来识别。除第一个数据包外，所有TCP数据包都必须设置ACK位。
However, there is no deterministic way of recognizing the start of a UDP based session or any non-TCP session. A heuristic approach would be to assume the first packet with hitherto non-existent session parameters (as defined in section 2.3) as constituting the start of new session.
但是，没有确定的方法来识别基于UDP的会话或任何非TCP会话的开始。一种启发式方法是假设第一个数据包具有迄今为止不存在的会话参数（如第2.3节中所定义），构成新会话的开始。
The end of a TCP session is detected when FIN is acknowledged by both halves of the session or when either half receives a segment with the RST bit in TCP flags field. However, because it is impossible for a NAT device to know whether the packets it sees will actually be delivered to the destination (they may be dropped between the NAT device and the destination), the NAT device cannot safely assume that the segments containing FINs or SYNs will be the last packets of the session (i.e., there could be retransmissions). Consequently, a session can be assumed to have been terminated only after a period of
当FIN被会话的两个部分确认时，或者当任一部分接收到TCP标志字段中带有RST位的段时，会检测到TCP会话的结束。然而，由于NAT设备不可能知道它所看到的数据包是否将实际发送到目的地（它们可能在NAT设备和目的地之间丢弃），NAT设备不能安全地假定包含FINs或SYN的段将是会话的最后一个数据包（即，可能存在重传）。因此，可以假定会话仅在一段时间后终止
4 minutes subsequent to this detection. The need for this extended wait period is described in RFC 793 [Ref 7], which suggests a TIME-WAIT duration of 2 * MSL (Maximum Segment Lifetime) or 4 minutes.
检测后4分钟。RFC 793[Ref 7]中描述了延长等待时间的必要性，其建议的等待时间为2*MSL（最大段寿命）或4分钟。
Note that it is also possible for a TCP connection to terminate without the NAT device becoming aware of the event (e.g., in the case where one or both peers reboot). Consequently, garbage collection is necessary on NAT devices to clean up unused state about TCP sessions that no longer exist. However, it is not possible in the general case to distinguish between connections that have been idle for an extended period of time from those that no longer exist. In the case of UDP-based sessions, there is no single way to determine when a session ends, since UDP-based protocols are application specific.
请注意，TCP连接也可能在NAT设备不知道事件的情况下终止（例如，在一个或两个对等点重新启动的情况下）。因此，NAT设备上需要进行垃圾收集，以清除不再存在的TCP会话的未使用状态。但是，在一般情况下，无法区分长时间空闲的连接和不再存在的连接。对于基于UDP的会话，没有单一的方法来确定会话何时结束，因为基于UDP的协议是特定于应用程序的。
Many heuristic approaches are used to terminate sessions. You can make the assumption that TCP sessions that have not been used for say, 24 hours, and non-TCP sessions that have not been used for a couple of minutes, are terminated. Often this assumption works, but sometimes it doesn't. These idle period session timeouts vary a great deal both from application to application and for different sessions of the same application. Consequently, session timeouts must be configurable. Even so, there is no guarantee that a satisfactory value can be found. Further, as stated in section 2.3, there is no guarantee that NAT's view of session termination will coincide with that of the application.
许多启发式方法用于终止会话。您可以假设24小时内未使用的TCP会话和几分钟内未使用的非TCP会话将被终止。这种假设通常有效，但有时无效。这些空闲期会话超时在不同的应用程序之间以及同一应用程序的不同会话之间都有很大的差异。因此，会话超时必须是可配置的。即使如此，也不能保证能够找到令人满意的值。此外，如第2.3节所述，不能保证NAT对会话终止的看法与应用程序的看法一致。
Another way to handle session terminations is to timestamp entries and keep them as long as possible and retire the longest idle session when it becomes necessary.
处理会话终止的另一种方法是为条目添加时间戳，并尽可能长地保留它们，并在必要时退出最长的空闲会话。
A Global or Public Network is an address realm with unique network addresses assigned by Internet Assigned Numbers Authority (IANA) or an equivalent address registry. This network is also referred as External network during NAT discussions.
全球或公共网络是一个地址域，具有由互联网分配号码管理局（IANA）或等效地址注册表分配的唯一网络地址。在NAT讨论期间，该网络也称为外部网络。
A private network is an address realm independent of external network addresses. Private network may also be referred alternately as Local Network. Transparent routing between hosts in private realm and external realm is facilitated by a NAT router.
专用网络是独立于外部网络地址的地址域。专用网络也可以交替地称为本地网络。NAT路由器促进了私有域和外部域中主机之间的透明路由。
RFC 1918 [Ref 1] has recommendations on address space allocation for private networks. Internet Assigned Numbers Authority (IANA) has three blocks of IP address space, namely 10/8, 172.16/12, and 192.168/16 set aside for private internets. In pre-CIDR notation, the
RFC1918[参考文献1]对专用网络的地址空间分配提出了建议。互联网分配号码管理局（IANA）有三块IP地址空间，即10/8、172.16/12和192.168/16，专门用于私人互联网。在CIDR之前的表示法中
first block is nothing but a single class A network number, while the second block is a set of 16 contiguous class B networks, and the third block is a set of 256 contiguous class C networks.
第一个块只不过是一个a类网络编号，而第二个块是一组16个连续的B类网络，第三个块是一组256个连续的C类网络。
An organization that decides to use IP addresses in the address space defined above can do so without coordination with IANA or any other Internet registry such as APNIC, RIPE and ARIN. The address space can thus be used privately by many independent organizations at the same time. However, if those independent organizations later decide they wish to communicate with each other or the public Internet, they will either have to renumber their networks or enable NAT on their border routers.
决定在上述地址空间中使用IP地址的组织可以在不与IANA或任何其他互联网注册中心（如APNIC、RIME和ARIN）协调的情况下使用IP地址。因此，地址空间可以同时被许多独立组织私自使用。然而，如果这些独立组织后来决定彼此通信或通过公共互联网进行通信，它们将不得不对其网络重新编号或在其边界路由器上启用NAT。
Not all applications lend themselves easily to translation by NAT devices; especially those that include IP addresses and TCP/UDP ports in the payload. Application Level Gateways (ALGs) are application specific translation agents that allow an application on a host in one address realm to connect to its counterpart running on a host in different realm transparently. An ALG may interact with NAT to set up state, use NAT state information, modify application specific payload and perform whatever else is necessary to get the application running across disparate address realms.
并非所有的应用程序都易于通过NAT设备进行翻译；特别是那些在有效负载中包含IP地址和TCP/UDP端口的。应用程序级网关（ALG）是特定于应用程序的转换代理，它允许一个地址域中主机上的应用程序透明地连接到另一个地址域中主机上运行的对应程序。ALG可以与NAT交互以设置状态、使用NAT状态信息、修改特定于应用程序的有效负载以及执行使应用程序在不同的地址域中运行所需的任何其他操作。
ALGs may not always utilize NAT state information. They may glean application payload and simply notify NAT to add additional state information in some cases. ALGs are similar to Proxies, in that, both ALGs and proxies facilitate Application specific communication between clients and servers. Proxies use a special protocol to communicate with proxy clients and relay client data to servers and vice versa. Unlike Proxies, ALGs do not use a special protocol to communicate with application clients and do not require changes to application clients.
ALG可能并不总是利用NAT状态信息。在某些情况下，它们可以收集应用程序负载，并简单地通知NAT添加额外的状态信息。ALG与代理类似，因为ALG和代理都促进客户端和服务器之间特定于应用程序的通信。代理使用特殊协议与代理客户端通信，并将客户端数据中继到服务器，反之亦然。与代理不同，ALG不使用特殊协议与应用程序客户端通信，也不需要更改应用程序客户端。
Network Address Translation is a method by which IP addresses are mapped from one address realm to another, providing transparent routing to end hosts. There are many variations of address translation that lend themselves to different applications. However, all flavors of NAT devices should share the following characteristics.
网络地址转换是一种将IP地址从一个地址域映射到另一个地址域的方法，提供到终端主机的透明路由。地址转换有许多变体，适用于不同的应用。然而，所有风格的NAT设备都应该具有以下特点。
a) Transparent Address assignment. b) Transparent routing through address translation. (routing here refers to forwarding packets, and not exchanging routing information) c) ICMP error packet payload translation.
a) 透明地址分配。b） 通过地址转换的透明路由。（这里的路由指的是转发数据包，而不是交换路由信息）c）ICMP错误数据包有效负载转换。
Below is a diagram illustrating a scenario in which NAT is enabled on a stub domain border router, connected to the Internet through a regional router made available by a service provider.
下图说明了一个场景，其中NAT在存根域边界路由器上启用，通过服务提供商提供的区域路由器连接到Internet。
\ | / . /
+---------------+ WAN . +-----------------+/
|Regional Router|----------------------|Stub Router w/NAT|---
+---------------+ . +-----------------+\
. | \
. | LAN
. ---------------
Stub border
\ | / . /
+---------------+ WAN . +-----------------+/
|Regional Router|----------------------|Stub Router w/NAT|---
+---------------+ . +-----------------+\
. | \
. | LAN
. ---------------
Stub border
Figure 1: A typical NAT operation scenario
图1：典型的NAT操作场景
NAT binds addresses in private network with addresses in global network and vice versa to provide transparent routing for the datagrams traversing between address realms. The binding in some cases may extend to transport level identifiers (such as TCP/UDP ports). Address binding is done at the start of a session. The following sub-sections describe two types of address assignments.
NAT将专用网络中的地址与全局网络中的地址绑定，反之亦然，以便为地址域之间的数据报提供透明路由。在某些情况下，绑定可能扩展到传输级别标识符（如TCP/UDP端口）。地址绑定在会话开始时完成。以下小节描述了两种类型的地址分配。
In the case of static address assignment, there is one-to-one address mapping for hosts between a private network address and an external network address for the lifetime of NAT operation. Static address assignment ensures that NAT does not have to administer address management with session flows.
在静态地址分配的情况下，在NAT操作的生存期内，主机在专用网络地址和外部网络地址之间存在一对一的地址映射。静态地址分配确保NAT不必使用会话流管理地址管理。
In this case, external addresses are assigned to private network hosts or vice versa, dynamically based on usage requirements and session flow determined heuristically by NAT. When the last session using an address binding is terminated, NAT would free the binding so that the global address could be recycled for later use. The exact nature of address assignment is specific to individual NAT implementations.
在这种情况下，根据NAT试探性地确定的使用要求和会话流，动态地将外部地址分配给专用网络主机，反之亦然。当使用地址绑定的最后一个会话终止时，NAT将释放绑定，以便全局地址可以循环使用。地址分配的确切性质特定于各个NAT实现。
A NAT router sits at the border between two address realms and translates addresses in IP headers so that when the packet leaves one realm and enters another, it can be routed properly. Because NAT devices have connections to multiple address realms, they must be careful to not improperly propagate information (e.g., via routing protocols) about networks from one address realm into another, where such an advertisement would be deemed unacceptable.
NAT路由器位于两个地址域之间的边界，并在IP报头中转换地址，以便当数据包离开一个域进入另一个域时，可以正确路由。由于NAT设备连接到多个地址域，因此它们必须小心，不要将有关网络的信息（例如，通过路由协议）从一个地址域不当地传播到另一个地址域，因为这样的广告将被视为不可接受。
There are three phases to Address translation, as follows. Together these phases result in creation, maintenance and termination of state for sessions passing through NAT devices.
翻译分为三个阶段，如下所示。这些阶段共同导致通过NAT设备的会话状态的创建、维护和终止。
Address binding is the phase in which a local node IP address is associated with an external address or vice versa, for purposes of translation. Address binding is fixed with static address assignments and is dynamic at session startup time with dynamic address assignments. Once the binding between two addresses is in place, all subsequent sessions originating from or to this host will use the same binding for session based packet translation.
地址绑定是为了转换，本地节点IP地址与外部地址相关联或与外部地址相关联的阶段。地址绑定在静态地址分配中是固定的，在会话启动时在动态地址分配中是动态的。一旦两个地址之间的绑定到位，来自或到该主机的所有后续会话都将使用相同的绑定进行基于会话的数据包转换。
New address bindings are made at the start of a new session, if such an address binding didn't already exist. Once a local address is bound to an external address, all subsequent sessions originating from the same local address or directed to the same local address will use the same binding.
如果新的地址绑定不存在，则会在新会话开始时进行新的地址绑定。将本地地址绑定到外部地址后，来自同一本地地址或指向同一本地地址的所有后续会话都将使用相同的绑定。
The start of each new session will result in the creation of a state to facilitate translation of datagrams pertaining to the session. There can be many simultaneous sessions originating from the same host, based on a single address binding.
每个新会话的启动将导致创建一个状态，以便于转换与会话相关的数据报。基于单个地址绑定，可以有多个来自同一主机的并发会话。
Once a state is established for a session, all packets belonging to the session will be subject to address lookup (and transport identifier lookup, in some cases) and translation.
一旦为会话建立状态，属于该会话的所有数据包都将进行地址查找（在某些情况下，还将进行传输标识符查找）和转换。
Address or transport identifier translation for a datagram will result in the datagram forwarding from the origin address realm to the destination address realm with network addresses appropriately updated.
数据报的地址或传输标识符转换将导致数据报从源地址域转发到目标地址域，并适当更新网络地址。
Address unbinding is the phase in which a private address is no longer associated with a global address for purposes of translation. NAT will perform address unbinding when it believes that the last session using an address binding has terminated. Refer section 2.6 for some heuristic ways to handle session terminations.
地址解除绑定是专用地址不再与全局地址关联以进行转换的阶段。当NAT认为使用地址绑定的最后一个会话已终止时，它将执行地址解除绑定。有关处理会话终止的一些启发式方法，请参阅第2.6节。
All ICMP error messages (with the exception of Redirect message type) will need to be modified, when passed through NAT. The ICMP error message types needing NAT modification would include Destination-Unreachable, Source-Quench, Time-Exceeded and Parameter-Problem. NAT should not attempt to modify a Redirect message type.
所有ICMP错误消息（重定向消息类型除外）在通过NAT时都需要修改。需要修改NAT的ICMP错误消息类型包括目标不可访问、源猝灭、超出时间和参数问题。NAT不应尝试修改重定向消息类型。
Changes to ICMP error message will include changes to the original IP packet (or portions thereof) embedded in the payload of the ICMP error message. In order for NAT to be completely transparent to end hosts, the IP address of the IP header embedded in the payload of the ICMP packet must be modified, the checksum field of the same IP header must correspondingly be modified, and the accompanying transport header. The ICMP header checksum must also be modified to reflect changes made to the IP and transport headers in the payload. Furthermore, the normal IP header must also be modified.
对ICMP错误消息的更改将包括对嵌入ICMP错误消息有效负载中的原始IP数据包（或其部分）的更改。为了使NAT对终端主机完全透明，必须修改嵌入ICMP数据包有效负载中的IP报头的IP地址，必须相应修改同一IP报头的校验和字段，以及相应的传输报头。还必须修改ICMP报头校验和，以反映对有效负载中的IP和传输报头所做的更改。此外，还必须修改普通IP报头。
There are many variations of address translation that lend themselves to different applications. NAT flavors listed in the following sub-sections are by no means exhaustive, but they do capture the significant differences that abound.
地址转换有许多变体，适用于不同的应用。以下小节中列出的NAT口味并非详尽无遗，但它们确实抓住了大量存在的显著差异。
The following diagram will be used as a base model to illustrate NAT flavors. Host-A, with address Addr-A is located in a private realm, represented by the network N-Pri. N-Pri is isolated from external network through a NAT router. Host-X, with address Addr-X is located in an external realm, represented by the network N-Ext. NAT router with two interfaces, each attached to one of the realms provides transparent routing between the two realms. The interface to the external realm is assigned an address of Addr-Nx and the interface to private realm is assigned an address of Addr-Np. Further, it may be understood that addresses Addr-A and Addr-Np correspond to N-Pri network and the addresses Addr-X and Addr-Nx correspond to N-Ext network.
下图将用作基础模型来说明NAT的风格。地址为Addr-A的主机A位于专用域中，由网络N-Pri表示。N-Pri通过NAT路由器与外部网络隔离。地址为Addr-X的Host-X位于外部域中，由网络N-Ext表示。NAT路由器具有两个接口，每个接口连接到一个域，可在两个域之间提供透明路由。外部领域的接口被分配一个地址Addr Nx，而私有领域的接口被分配一个地址Addr Np。此外，可以理解，地址Addr-A和Addr-Np对应于N-Pri网络，而地址Addr-X和Addr-Nx对应于N-Ext网络。
________________
( )
( External ) +--+
( Address Realm )-- |__|
( (N-Ext) ) /____\
(________________) Host-X
| (Addr-X)
|(Addr-Nx)
+--------------+
| |
| NAT router |
| |
+--------------+
|(Addr-Np)
|
----------------
( )
+--+ ( Private )
|__|------( Address Realm )
/____\ ( (N-pri) )
Host-A (________________)
(Addr-A)
________________
( )
( External ) +--+
( Address Realm )-- |__|
( (N-Ext) ) /____\
(________________) Host-X
| (Addr-X)
|(Addr-Nx)
+--------------+
| |
| NAT router |
| |
+--------------+
|(Addr-Np)
|
----------------
( )
+--+ ( Private )
|__|------( Address Realm )
/____\ ( (N-pri) )
Host-A (________________)
(Addr-A)
Figure 2: A base model to illustrate NAT terms.
图2：用于说明NAT术语的基本模型。
Traditional NAT would allow hosts within a private network to transparently access hosts in the external network, in most cases. In a traditional NAT, sessions are uni-directional, outbound from the private network. This is in contrast with Bi-directional NAT, which permits sessions in both inbound and outbound directions. A detailed description of Bi-directional NAT may be found in section 4.2.
在大多数情况下，传统NAT允许专用网络中的主机透明地访问外部网络中的主机。在传统的NAT中，会话是单向的，从专用网络出站。这与双向NAT形成对比，双向NAT允许入站和出站方向的会话。有关双向NAT的详细说明，请参见第4.2节。
The following is a description of the properties of realms supported by traditional NAT. IP addresses of hosts in external network are unique and valid in external as well as private networks. However, the addresses of hosts in private network are unique only within the private network and may not be valid in the external network. In other words, NAT would not advertise private networks to the external realm. But, networks from the external realm may be advertised within the private network. The addresses used within private network must not overlap with the external addresses. Any given address must either be a private address or an external address; not both.
下面是对传统NAT支持的领域属性的描述。外部网络中主机的IP地址在外部网络和专用网络中都是唯一和有效的。但是，专用网络中的主机地址仅在专用网络中是唯一的，在外部网络中可能无效。换句话说，NAT不会向外部领域宣传私有网络。但是，来自外部领域的网络可以在专用网络内进行广告。专用网络内使用的地址不得与外部地址重叠。任何给定地址必须是私人地址或外部地址；不是两者都有。
A traditional NAT router in figure 2 would allow Host-A to initiate sessions to Host-X, but not the other way around. Also, N-Ext is routable from within N-Pri, whereas N-Pri may not be routable from N-Ext.
图2中的传统NAT路由器允许Host-A启动到Host-X的会话，但不是相反。此外，N-Ext可从N-Pri内部路由，而N-Pri可能无法从N-Ext路由。
Traditional NAT is primarily used by sites using private addresses that wish to allow outbound sessions from their site.
传统NAT主要由使用私有地址的站点使用，这些站点希望允许从其站点进行出站会话。
There are two variations to traditional NAT, namely Basic NAT and NAPT (Network Address Port Translation). These are discussed in the following sub-sections.
传统NAT有两种变体，即基本NAT和NAPT（网络地址端口转换）。这些将在以下小节中讨论。
With Basic NAT, a block of external addresses are set aside for translating addresses of hosts in a private domain as they originate sessions to the external domain. For packets outbound from the private network, the source IP address and related fields such as IP, TCP, UDP and ICMP header checksums are translated. For inbound packets, the destination IP address and the checksums as listed above are translated.
使用基本NAT时，会留出一个外部地址块，用于在私有域中的主机发起会话时将其地址转换到外部域。对于从专用网络出站的数据包，将转换源IP地址和相关字段，如IP、TCP、UDP和ICMP报头校验和。对于入站数据包，将转换上面列出的目标IP地址和校验和。
A Basic NAT router in figure 2 may be configured to translate N-Pri into a block of external addresses, say Addr-i through Addr-n, selected from the external network N-Ext.
图2中的基本NAT路由器可配置为将N-Pri转换为从外部网络N-Ext中选择的外部地址块，例如Addr-i到Addr-N。
NAPT extends the notion of translation one step further by also translating transport identifier (e.g., TCP and UDP port numbers, ICMP query identifiers). This allows the transport identifiers of a number of private hosts to be multiplexed into the transport identifiers of a single external address. NAPT allows a set of hosts to share a single external address. Note that NAPT can be combined with Basic NAT so that a pool of external addresses are used in conjunction with port translation.
NAPT通过转换传输标识符（例如TCP和UDP端口号、ICMP查询标识符）进一步扩展了转换的概念。这允许将多个专用主机的传输标识符多路复用到单个外部地址的传输标识符中。NAPT允许一组主机共享一个外部地址。请注意，NAPT可以与基本NAT结合使用，以便将外部地址池与端口转换结合使用。
For packets outbound from the private network, NAPT would translate the source IP address, source transport identifier and related fields such as IP, TCP, UDP and ICMP header checksums. Transport identifier can be one of TCP/UDP port or ICMP query ID. For inbound packets, the destination IP address, destination transport identifier and the IP and transport header checksums are translated.
对于从专用网络出站的数据包，NAPT将转换源IP地址、源传输标识符和相关字段，如IP、TCP、UDP和ICMP报头校验和。传输标识符可以是TCP/UDP端口或ICMP查询ID之一。对于入站数据包，将转换目标IP地址、目标传输标识符以及IP和传输头校验和。
A NAPT router in figure 2 may be configured to translate sessions originated from N-Pri into a single external address, say Addr-i.
图2中的NAPT路由器可配置为将源自N-Pri的会话转换为单个外部地址，如Addr-i。
Very often, the external interface address Addr-Nx of NAPT router is used as the address to map N-Pri to.
通常，NAPT路由器的外部接口地址Addr Nx被用作映射N-Pri的地址。
With a Bi-directional NAT, sessions can be initiated from hosts in the public network as well as the private network. Private network addresses are bound to globally unique addresses, statically or dynamically as connections are established in either direction. The name space (i.e., their Fully Qualified Domain Names) between hosts in private and external networks is assumed to be end-to-end unique. Hosts in external realm access private realm hosts by using DNS for address resolution. A DNS-ALG must be employed in conjunction with Bi-Directional NAT to facilitate name to address mapping. Specifically, the DNS-ALG must be capable of translating private realm addresses in DNS Queries and responses into their external realm address bindings, and vice versa, as DNS packets traverse between private and external realms.
使用双向NAT，可以从公共网络和专用网络中的主机启动会话。当在任一方向建立连接时，专用网络地址被静态或动态地绑定到全局唯一地址。假定专用网络和外部网络中主机之间的名称空间（即其完全限定的域名）是端到端唯一的。外部领域中的主机通过使用DNS进行地址解析来访问私有领域主机。DNS-ALG必须与双向NAT结合使用，以促进名称到地址的映射。具体地说，DNS-ALG必须能够将DNS查询和响应中的私有领域地址转换为其外部领域地址绑定，反之亦然，因为DNS数据包在私有领域和外部领域之间移动。
The address space requirements outlined for traditional NAT routers are applicable here as well.
传统NAT路由器的地址空间要求也适用于此。
A Bi-directional NAT router in figure 2 would allow Host-A to initiate sessions to Host-X, and Host-X to initiate sessions to Host-A. Just as with traditional NAT, N-Ext is routable from within N-Pri, but N-Pri may not be routable from N-Ext.
图2中的双向NAT路由器允许主机A向主机X发起会话，主机X向主机A发起会话。与传统NAT一样，N-Ext可以从N-Pri内部路由，但N-Pri可能无法从N-Ext路由。
Twice NAT is a variation of NAT in that both the source and destination addresses are modified by NAT as a datagram crosses address realms. This is in contrast to Traditional-NAT and Bi-Directional NAT, where only one of the addresses (either source or destination) is translated. Note, there is no such term as 'Once-NAT'.
两次NAT是NAT的一种变体，当数据报跨越地址域时，源地址和目标地址都被NAT修改。这与传统的NAT和双向NAT不同，后者只转换一个地址（源地址或目标地址）。注意，没有“一次NAT”这样的术语。
Twice NAT is necessary when private and external realms have address collisions. The most common case where this would happen is when a site had (improperly) numbered its internal nodes using public addresses that have been assigned to another organization. Alternatively, a site may have changed from one provider to another, but chosen to keep (internally) the addresses it had been assigned by the first provider. That provider might then later reassign those addresses to someone else. The key issue in such cases is that the address of the host in the external realm may have been assigned the
当私有和外部领域存在地址冲突时，需要两次NAT。最常见的情况是，站点使用分配给其他组织的公共地址对其内部节点进行了（不正确）编号。或者，站点可能已从一个提供商更改为另一个提供商，但选择保留（内部）由第一个提供商分配的地址。该提供者随后可能会将这些地址重新分配给其他人。这种情况下的关键问题是，外部领域中的主机地址可能已分配给
same address as a host within the local site. If that address were to appear in a packet, it would be forwarded to the internal node rather than through the NAT device to the external realm. Twice-NAT attempts to bridge these realms by translating both source and destination address of an IP packet, as the packet transitions realms.
与本地站点中的主机地址相同。如果该地址出现在数据包中，它将被转发到内部节点，而不是通过NAT设备转发到外部领域。两次NAT尝试通过转换IP数据包的源地址和目标地址来桥接这些领域，因为数据包转换为领域。
Twice-NAT works as follows. When Host-A wishes to initiate a session to Host-X, it issues a DNS query for Host-X. A DNS-ALG intercepts the DNS query, and in the response returned to Host-A the DNS-ALG replaces the address for Host-X with one that is properly routable in the local site (say Host-XPRIME). Host A then initiates communication with Host-XPRIME. When the packets traverse the NAT device, the source IP address is translated (as in the case of traditional NAT) and the destination address is translated to Host-X. A similar translation is performed on return packets coming from Host-X.
两次NAT的工作原理如下。当Host-A希望启动到Host-X的会话时，它会发出Host-X的DNS查询。DNS-ALG拦截DNS查询，并在返回给Host-A的响应中，DNS-ALG将Host-X的地址替换为可在本地站点中正确路由的地址（如Host XPRIME）。然后，主机A启动与主机XPRIME的通信。当数据包穿过NAT设备时，源IP地址被转换（与传统NAT的情况相同），目标地址被转换为Host-X。对来自Host-X的返回数据包执行类似的转换。
The following is a description of the properties of realms supported by Twice-NAT. Network address of hosts in external network are unique in external networks, but not within private network. Likewise, the network address of hosts in private network are unique only within the private network. In other words, the address space used in private network to locate hosts in private and public networks is unrelated to the address space used in public network to locate hosts in private and public networks. Twice NAT would not be allowed to advertise local networks to the external network or vice versa.
下面是对两次NAT支持的领域属性的描述。外部网络中主机的网络地址在外部网络中是唯一的，但在专用网络中不是唯一的。同样，专用网络中主机的网络地址仅在专用网络中是唯一的。换句话说，专用网络中用于在专用和公用网络中定位主机的地址空间与公用网络中用于在专用和公用网络中定位主机的地址空间无关。两次NAT将不允许向外部网络播发本地网络，反之亦然。
A Twice NAT router in figure 2 would allow Host-A to initiate sessions to Host-X, and Host-X to initiate sessions to Host-A. However, N-Ext (or a subset of N-Ext) is not routable from within N-Pri, and N-Pri is not routable from N-Ext.
图2中的两次NAT路由器将允许主机A向主机X发起会话，主机X向主机A发起会话。但是，N-Ext（或N-Ext的子集）不能从N-Pri内路由，N-Pri也不能从N-Ext路由。
Twice NAT is typically used when address space used in a Private network overlaps with addresses used in the Public space. For example, say a private site uses the 200.200.200.0/24 address space which is officially assigned to another site in the public internet. Host_A (200.200.200.1) in Private space seeks to connect to Host_X (200.200.200.100) in Public space. In order to make this connection work, Host_X's address is mapped to a different address for Host_A and vice versa. The twice NAT located at the Private site border may be configured as follows:
当专用网络中使用的地址空间与公共空间中使用的地址重叠时，通常使用两次NAT。例如，假设一个私有站点使用200.200.200.0/24地址空间，该地址空间正式分配给公共internet中的另一个站点。私人空间中的主机_A（200.200.200.1）寻求连接到公共空间中的主机_X（200.200.200.100）。为了使此连接正常工作，主机_X的地址映射到主机_a的不同地址，反之亦然。位于专用站点边界的两次NAT可配置如下：
Private to Public : 200.200.200.0/24 -> 138.76.28.0/24
Public to Private : 200.200.200.0/24 -> 172.16.1.0/24
Private to Public : 200.200.200.0/24 -> 138.76.28.0/24
Public to Private : 200.200.200.0/24 -> 172.16.1.0/24
Datagram flow : Host_A(Private) -> Host_X(Public)
Datagram flow : Host_A(Private) -> Host_X(Public)
a) Within private network
a) 专用网络内
DA: 172.16.1.100 SA: 200.200.200.1
DA:172.16.1.100 SA:200.200.200.1
b) After twice-NAT translation
b) 经过两次NAT翻译
DA: 200.200.200.100 SA: 138.76.28.1
DA:200.200.200.100 SA:138.76.28.1
Datagram flow Host_X (Public) -> Host_A (Private)
数据报流主机（公用）->主机（专用）
a) Within Public network
a) 公共网络内
DA: 138.76.28.1 SA: 200.200.200.100
DA:138.76.28.1 SA:200.200.200.100
b) After twice-NAT translation, in private network
b) 经过两次NAT转换后，在专用网络中
SA: 200.200.200.1 DA: 172.16.1.100
SA:200.200.200.1 DA:172.16.1.100
There are limitations to using NAT. For example, requests and responses pertaining to a session must be routed via the same NAT router, as a NAT router maintains state information for sessions established through it. For this reason, it is often suggested that NAT routers be operated on a border router unique to a stub domain, where all IP packets are either originated from the domain or destined to the domain. However, such a configuration would turn a NAT router into a single point of failure.
使用NAT有一些限制。例如，与会话相关的请求和响应必须通过相同的NAT路由器路由，因为NAT路由器维护通过它建立的会话的状态信息。出于这个原因，通常建议NAT路由器在存根域特有的边界路由器上运行，其中所有IP数据包要么来自该域，要么发往该域。然而，这样的配置会使NAT路由器变成单点故障。
In order for a private network to ensure that connectivity with external networks is retained even as one of the NAT links fail, it is often desirable to multihome the private network to same or multiple service providers with multiple connections from the private domain, be it from same or different NAT boxes.
为了使专用网络确保即使在其中一个NAT链路发生故障时仍保持与外部网络的连接，通常需要将专用网络多址到具有来自专用域的多个连接的相同或多个服务提供商，无论是来自相同或不同的NAT盒。
For example, a private network could have links to two different providers and the sessions from private hosts could flow through the NAT router with the best metric for a destination. When one of NAT routers fail, the other could route traffic for all connections.
例如，一个专用网络可以有到两个不同提供商的链接，并且来自专用主机的会话可以以目的地的最佳度量流经NAT路由器。当一个NAT路由器发生故障时，另一个可以为所有连接路由流量。
Multiple NAT boxes or multiple links on the same NAT box, sharing the same NAT configuration can provide fail-safe backup for each other. In such a case, it is necessary for backup NAT device to exchange state information so that a backup NAT can take on session load transparently when the primary NAT fails. NAT backup becomes simpler, when configuration is based on static maps.
共享相同NAT配置的多个NAT盒或同一NAT盒上的多个链路可以为彼此提供故障安全备份。在这种情况下，备份NAT设备有必要交换状态信息，以便在主NAT失败时，备份NAT可以透明地承担会话负载。当配置基于静态映射时，NAT备份变得更简单。
"Realm Specific IP" (RSIP) is used to characterize the functionality of a realm-aware host in a private realm, which assumes realm-specific IP address to communicate with hosts in private or external realm.
“领域特定IP”（RSIP）用于描述私有领域中领域感知主机的功能，它假定领域特定IP地址与私有或外部领域中的主机通信。
A "Realm Specific IP Client" (RSIP client) is a host in a private network that adopts an address in an external realm when connecting to hosts in that realm to pursue end-to-end communication. Packets generated by hosts on either end in such a setup would be based on addresses that are end-to-end unique in the external realm and do not require translation by an intermediary process.
“领域特定IP客户端”（RSIP客户端）是专用网络中的主机，当连接到该领域中的主机以进行端到端通信时，该主机采用外部领域中的地址。在这种设置中，两端主机生成的数据包将基于在外部领域中端到端唯一的地址，并且不需要中间进程进行转换。
A "Realm Specific IP Server" (RSIP server) is a node resident on both private and external realms, that can facilitate routing of external realm packets within a private realm. These packets may either have been originated by an RSIP client or directed to an RSIP-client. RSIP-Server may also be the same node that assigns external realm addresses to RSIP-Clients.
“领域特定IP服务器”（RSIP服务器）是驻留在私有领域和外部领域上的节点，可促进私有领域内外部领域数据包的路由。这些数据包可能是由RSIP客户端发起的，也可能是定向到RSIP客户端的。RSIP服务器也可以是为RSIP客户端分配外部域地址的同一节点。
There are two variations to RSIP, namely Realm-specific Address IP (RSA-IP) and Realm-Specific Address and Port IP (RSAP-IP). These variations are discussed in the following sub-sections.
RSIP有两种变体，即领域特定地址IP（RSA-IP）和领域特定地址和端口IP（RSAP-IP）。这些变化将在以下小节中讨论。
A Realm Specific Address IP (RSA-IP) client adopts an IP address from the external address space when connecting to a host in external realm. Once an RSA-IP client assumes an external address, no other host in private or external domain can assume the same address, until that address is released by the RSA-IP client.
领域特定地址IP（RSA-IP）客户端在连接到外部领域中的主机时采用外部地址空间中的IP地址。一旦RSA-IP客户端采用外部地址，在RSA-IP客户端释放该地址之前，私有域或外部域中的任何其他主机都不能采用相同的地址。
The following is a discussion of routing alternatives that may be pursued for the end-to-end RSA-IP packets within private realm. One approach would be to tunnel the packet to the destination. The outer header can be translated by NAT as normal without affecting the addresses used in the internal header. Another approach would be to set up a bi-directional tunnel between the RSA-IP Client and the border router straddling the two address realms. Packets to and from the client would be tunneled, but packets would be forwarded as
以下是对私有领域内端到端RSA-IP数据包可能采用的路由选择的讨论。一种方法是通过隧道将数据包传输到目的地。NAT可以正常转换外部报头，而不会影响内部报头中使用的地址。另一种方法是在RSA-IP客户端和跨越两个地址域的边界路由器之间建立一个双向隧道。进出客户机的数据包将通过隧道传输，但数据包将作为
normal between the border router and the remote destination. Note, the tunnel from the client TO the border router may not be necessary. You might be able to just forward the packet directly. This should work so long as your internal network isn't filtering packets based on source addresses (which in this case would be external addresses).
边界路由器和远程目标之间正常。注意，从客户端到边界路由器的隧道可能不是必需的。您可以直接转发数据包。只要您的内部网络没有根据源地址（在本例中是外部地址）过滤数据包，这项功能就可以正常工作。
As an example, Host-A in figure 2 above, could assume an address Addr-k from the external realm and act as RSA-IP-Client to allow end-to-end sessions between Addr-k and Addr-X. Traversal of end-to-end packets within private realm may be illustrated as follows:
例如，上面图2中的主机A可以假设来自外部领域的地址Addr-k，并充当RSA IP客户端，以允许Addr-k和Addr-X之间的端到端会话。私有领域内端到端数据包的遍历可以如下所示：
First method, using NAT router enroute to translate:
===================================================
First method, using NAT router enroute to translate:
===================================================
Host-A NAT router Host-X
------ ----------- ------
Host-A NAT router Host-X
------ ----------- ------
<Outer IP header, with
src=Addr-A, Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
----------------------------->
<Outer IP header, with
src=Addr-A, Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
----------------------------->
<Outer IP header, with
src=Addr-k, Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
--------------------------->
<Outer IP header, with
src=Addr-k, Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
--------------------------->
. . .
. . .
<Outer IP header, with
src=Addr-X, Dest=Addr-k>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-k>
<---------------------------------
<Outer IP header, with
src=Addr-X, Dest=Addr-k>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-k>
<---------------------------------
<Outer IP header, with
src=Addr-X, Dest=Addr-A>,
embedding <End-to-end packet,
with src=Addr-X, Dest=Addr-k>
<--------------------------------------
<Outer IP header, with
src=Addr-X, Dest=Addr-A>,
embedding <End-to-end packet,
with src=Addr-X, Dest=Addr-k>
<--------------------------------------
Second method, using a tunnel within private realm:
==================================================
Second method, using a tunnel within private realm:
==================================================
Host-A NAT router Host-X
------ ----------- ------
Host-A NAT router Host-X
------ ----------- ------
<Outer IP header, with
src=Addr-A, Dest=Addr-Np>,
embedding
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
----------------------------->
<Outer IP header, with
src=Addr-A, Dest=Addr-Np>,
embedding
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
----------------------------->
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
------------------------------->
<End-to-end packet, with
src=Addr-k, Dest=Addr-X>
------------------------------->
. . .
. . .
<End-to-end packet, with
src=Addr-X, Dest=Addr-k>
<--------------------------------
<End-to-end packet, with
src=Addr-X, Dest=Addr-k>
<--------------------------------
<Outer IP header, with
src=Addr-Np, Dest=Addr-A>,
embedding <End-to-end packet,
with src=Addr-X, Dest=Addr-k>
<----------------------------------
<Outer IP header, with
src=Addr-Np, Dest=Addr-A>,
embedding <End-to-end packet,
with src=Addr-X, Dest=Addr-k>
<----------------------------------
There may be other approaches to pursue.
可能还有其他方法可以追求。
An RSA-IP-Client has the following characteristics. The collective set of operations performed by an RSA-IP-Client may be termed "RSA-IP".
RSA IP客户端具有以下特征。RSA IP客户端执行的操作集合可以称为“RSA-IP”。
1. Aware of the realm to which its peer nodes belong.
1. 了解其对等节点所属的领域。
2. Assumes an address from external realm when communicating with hosts in that realm. Such an address may be assigned statically or obtained dynamically (through a yet-to-be-defined protocol) from a node capable of assigning addresses from external realm. RSA-IP-Server could be the node coordinating external realm address assignment.
2. 在与外部域中的主机通信时，假定来自该域的地址。这样的地址可以静态地分配，也可以从能够从外部领域分配地址的节点动态地（通过尚未定义的协议）获得。RSA IP Server可以是协调外部域地址分配的节点。
3. Route packets to external hosts using an approach amenable to RSA-IP-Server. In all cases, RSA-IP-Client will likely need to act as a tunnel end-point, capable of encapsulating end-to-end packets while forwarding and decapsulating in the return path.
3. 使用适合RSA IP Server的方法将数据包路由到外部主机。在所有情况下，RSA IP客户端都可能需要充当隧道端点，能够在返回路径中转发和解封装时封装端到端数据包。
"Realm Specific Address IP Server" (RSA-IP server) is a node resident on both private and external realms, that facilitates routing of external realm packets specific to RSA-IP clients inside a private realm. An RSA-IP-Server may be described as having the following characteristics.
“特定领域地址IP服务器”（RSA-IP服务器）是驻留在私有领域和外部领域上的节点，它有助于路由特定于私有领域内RSA-IP客户端的外部领域数据包。RSA IP服务器可以描述为具有以下特征。
1. May be configured to assign addresses from external realm to RSA-IP-Clients, either statically or dynamically.
1. 可以配置为静态或动态地将地址从外部域分配给RSA IP客户端。
2. Must be a router resident on both the private and external address realms.
2. 必须是驻留在私有和外部地址域上的路由器。
3. Must be able to provide a mechanism to route external realm packets within private realm. Of the two approaches described, the first approach requires RSA-IP-Server to be a NAT router providing transparent routing for the outer header. This approach requires the external peer to be a tunnel end-point.
3. 必须能够提供在私有领域内路由外部领域数据包的机制。在所描述的两种方法中，第一种方法要求RSA IP服务器是NAT路由器，为外部报头提供透明路由。这种方法要求外部对等方成为隧道端点。
With the second approach, an RSA-IP-Server could be any router (including a NAT router) that can be a tunnel end-point with RSA-IP-Clients. It would detunnel end-to-end packets outbound from RSA-IP-Clients and forward to external hosts. On the return path, it would locate RSA-IP-Client tunnel, based on the destination address of the end-to-end packet and encapsulate the packet in a tunnel to forward to RSA-IP-Client.
使用第二种方法，RSA IP服务器可以是任何路由器（包括NAT路由器），可以是RSA IP客户端的隧道端点。它会将端到端数据包从RSA IP客户端卸载并转发到外部主机。在返回路径上，它将根据端到端数据包的目标地址定位RSA IP客户端隧道，并将数据包封装在隧道中以转发到RSA IP客户端。
RSA-IP-Clients may pursue any of the IPsec techniques, namely transport or tunnel mode Authentication and confidentiality using AH and ESP headers on the embedded packets. Any of the tunneling techniques may be adapted for encapsulation between RSA-IP-Client and RSA-IP-Server or between RSA-IP-Client and external host. For example, IPsec tunnel mode encapsulation is a valid type of encapsulation that ensures IPsec authentication and confidentiality for the embedded end-to-end packets.
RSA IP客户端可以采用任何IPsec技术，即使用嵌入数据包上的AH和ESP头进行传输或隧道模式身份验证和保密。任何隧道技术均可适用于RSA IP客户端和RSA IP服务器之间或RSA IP客户端和外部主机之间的封装。例如，IPsec隧道模式封装是一种有效的封装类型，可确保嵌入式端到端数据包的IPsec身份验证和机密性。
Realm Specific Address and port IP (RSAP-IP) is a variation of RSIP in that multiple private hosts use a single external address, multiplexing on transport IDentifiers (i.e., TCP/UDP port numbers and ICMP Query IDs).
领域特定地址和端口IP（RSAP-IP）是RSIP的一种变体，因为多个专用主机使用单个外部地址，在传输标识符（即TCP/UDP端口号和ICMP查询ID）上进行多路复用。
"RSAP-IP-Client" may be defined similar to RSA-IP-Client with the variation that RSAP-IP-Client assumes a tuple of (external address, transport Identifier) when connecting to hosts in external realm to pursue end-to-end communication. As such, communication with external nodes for an RSAP-IP-Client may be limited to TCP, UDP and ICMP sessions.
“RSAP IP客户端”的定义可能类似于RSA IP客户端，其变化是，RSAP IP客户端在连接到外部域中的主机以进行端到端通信时采用元组（外部地址、传输标识符）。因此，与RSAP IP客户端的外部节点的通信可能仅限于TCP、UDP和ICMP会话。
"RSAP-IP-Server" is similar to RSA-IP-Server in that it facilitates routing of external realm packets specific to RSAP-IP clients inside a private realm. Typically, an RSAP-IP-Server would also be the one to assign transport tuples to RSAP-IP-Clients.
“RSAP IP服务器”类似于RSA IP服务器，因为它有助于路由专用领域内特定于RSAP-IP客户端的外部领域数据包。通常，RSAP IP服务器也可以将传输元组分配给RSAP IP客户端。
A NAPT router enroute could serve as RSAP-IP-Server, when the outer encapsulation is TCP/UDP based and is addressed between the RSAP-IP-Client and external peer. This approach requires the external peer to be the end-point of TCP/UDP based tunnel. Using this approach, RSAP-IP-Clients may pursue any of the IPsec techniques, namely transport or tunnel mode authentication and confidentiality using AH and ESP headers on the embedded packets. Note however, IPsec tunnel mode is not a valid type of encapsulation, as a NAPT router cannot provide routing transparency to AH and ESP protocols.
当外部封装基于TCP/UDP并且在RSAP IP客户端和外部对等方之间寻址时，NAPT路由器在路由过程中可以用作RSAP IP服务器。这种方法要求外部对等方成为基于TCP/UDP的隧道的端点。使用这种方法，RSAP IP客户端可以采用任何IPsec技术，即在嵌入式数据包上使用AH和ESP报头进行传输或隧道模式认证和保密。但是，请注意，IPsec隧道模式不是有效的封装类型，因为NAPT路由器无法为AH和ESP协议提供路由透明性。
Alternately, packets may be tunneled between RSAP-IP-Client and RSAP-IP-Server such that RSAP-IP-Server would detunnel packets outbound from RSAP-IP-Clients and forward to external hosts. On the return path, RSAP-IP-Server would locate RSAP-IP-Client tunnel, based on the tuple of (destination address, transport Identifier) and encapsulate the original packet within a tunnel to forward to RSAP-IP-Client. With this approach, there is no limitation on the tunneling technique employed between RSAP-IP-Client and RSAP-IP-Server. However, there are limitations to applying IPsec based security on end-to-end packets. Transport mode based authentication and integrity may be attained. But, confidentiality cannot be permitted because RSAP-IP-Server must be able to examine the destination transport Identifier in order to identify the RSAP-IP-tunnel to forward inbound packets to. For this reason, only the transport mode TCP, UDP and ICMP packets protected by AH and ESP-authentication can traverse a RSAP-IP-Server using this approach.
或者，数据包可以在RSAP IP客户端和RSAP IP服务器之间进行隧道传输，以便RSAP IP服务器将数据包从RSAP IP客户端出站并转发到外部主机。在返回路径上，RSAP IP服务器将根据（目标地址、传输标识符）的元组定位RSAP IP客户端隧道，并将原始数据包封装在隧道中以转发给RSAP IP客户端。通过这种方法，RSAP IP客户端和RSAP IP服务器之间采用的隧道技术没有限制。但是，在端到端数据包上应用基于IPsec的安全性有一些限制。可以实现基于传输模式的认证和完整性。但是，不允许保密，因为RSAP IP服务器必须能够检查目标传输标识符，以便识别要转发入站数据包的RSAP IP隧道。因此，只有受AH和ESP身份验证保护的传输模式TCP、UDP和ICMP数据包才能使用此方法遍历RSAP IP服务器。
As an example, say Host-A in figure 2 above, obtains a tuple of (Addr-Nx, TCP port T-Nx) from NAPT router to act as RSAP-IP-Client to initiate end-to-end TCP sessions with Host-X. Traversal of end-to-end packets within private realm may be illustrated as follows. In the first method, outer layer of the outgoing packet from Host-A uses (private address Addr-A, source port T-Na) as source tuple to communicate with Host-X. NAPT router enroute translates this tuple into (Addr-Nx, Port T-Nxa). This translation is independent of RSAP-IP-Client tuple parameters used in the embedded packet.
例如，如上图2中的主机A，从NAPT路由器获得一个元组（Addr Nx，TCP端口T-Nx），用作RSAP IP客户端，以启动与主机X的端到端TCP会话。私有领域内端到端数据包的遍历可以如下所示。在第一种方法中，来自主机A的传出数据包的外层使用（专用地址Addr-A，源端口T-Na）作为源元组与主机X通信。NAPT路由器在路由过程中将该元组转换为（Addr-Nx，端口T-Nxa）。此转换与嵌入数据包中使用的RSAP IP客户端元组参数无关。
First method, using NAPT router enroute to translate:
====================================================
First method, using NAPT router enroute to translate:
====================================================
Host-A NAPT router Host-X
------ ----------- ------
Host-A NAPT router Host-X
------ ----------- ------
<Outer TCP/UDP packet, with
src=Addr-A, Src Port=T-Na,
Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>
----------------------------->
<Outer TCP/UDP packet, with
src=Addr-A, Src Port=T-Na,
Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>
----------------------------->
<Outer TCP/UDP packet, with
src=Addr-Nx, Src Port=T-Nxa,
Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>
--------------------------------------->
<Outer TCP/UDP packet, with
src=Addr-Nx, Src Port=T-Nxa,
Dest=Addr-X>,
embedding
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx, Dest=Addr-X>
--------------------------------------->
. . .
. . .
<Outer TCP/UDP packet with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nxa>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<----------------------------------
<Outer TCP/UDP packet with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nxa>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<----------------------------------
<Outer TCP/UDP packet, with
src=Addr-X, Dest=Addr-A,
Dest Port=T-Na>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<-----------------------------------
<Outer TCP/UDP packet, with
src=Addr-X, Dest=Addr-A,
Dest Port=T-Na>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<-----------------------------------
Second method, using a tunnel within private realm:
==================================================
Second method, using a tunnel within private realm:
==================================================
Host-A NAPT router Host-X
------ ----------- ------
Host-A NAPT router Host-X
------ ----------- ------
<Outer IP header, with
src=Addr-A, Dest=Addr-Np>,
embedding
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx,
Dest=Addr-X>
----------------------------->
<Outer IP header, with
src=Addr-A, Dest=Addr-Np>,
embedding
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx,
Dest=Addr-X>
----------------------------->
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx,
Dest=Addr-X>
-------------------------------->
<End-to-end packet, with
src=Addr-Nx, Src Port=T-Nx,
Dest=Addr-X>
-------------------------------->
. . .
. . .
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<----------------------------------
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<----------------------------------
<Outer IP header, with
src=Addr-Np, Dest=Addr-A>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<----------------------------------
<Outer IP header, with
src=Addr-Np, Dest=Addr-A>,
embedding
<End-to-end packet, with
src=Addr-X, Dest=Addr-Nx,
Dest Port=T-Nx>
<----------------------------------
Let us consider the case where your private network is connected to the external world via tunnels. In such a case, tunnel encapsulated traffic may or may not contain translated packets depending upon the characteristics of address realms a tunnel is bridging.
让我们考虑一下您的专用网络通过隧道连接到外部世界的情况。在这种情况下，根据隧道桥接的地址域的特性，隧道封装的业务可能包含也可能不包含转换的分组。
The following subsections discuss two scenarios where tunnels are used (a) in conjunction with Address translation, and (b) without translation.
以下小节讨论了两种情况，即隧道使用（a）与地址转换结合使用，以及（b）不使用转换。
All variations of address translations discussed in the previous section can be applicable to direct connected links as well as tunnels and virtual private networks (VPNs).
上一节讨论的地址转换的所有变体都适用于直接连接的链路以及隧道和虚拟专用网络（VPN）。
For example, a private network connected to a business partner through a VPN could employ traditional NAT to communicate with the partner. Likewise, it is possible to employ twice NAT, if the partner's address space overlapped with the private network. There could be a NAT device on one end of the tunnel or on both ends of the tunnel. In all cases, traffic across the VPN can be encrypted for security purposes. Security here refers to security for traffic across VPNs alone. End-to-end security requires trusting NAT devices within private network.
例如，通过VPN连接到业务合作伙伴的专用网络可以使用传统NAT与合作伙伴通信。同样，如果合作伙伴的地址空间与专用网络重叠，则可以使用两次NAT。隧道的一端或两端可能有NAT设备。在所有情况下，VPN上的流量都可以出于安全目的进行加密。这里的安全是指仅跨VPN的流量安全。端到端安全性要求信任专用网络中的NAT设备。
There are many instances where a private network (such as a corporate network) is spread over different locations and use public backbone for communications between those locations. In such cases, it is not desirable to do address translation, both because large numbers of hosts may want to communicate across the backbone, thus requiring large address tables, and because there will be more applications that depend on configured addresses, as opposed to going to a name server. We call such a private network a backbone-partitioned private network.
在许多情况下，专用网络（如公司网络）分布在不同的位置，并使用公共主干网在这些位置之间进行通信。在这种情况下，不希望进行地址转换，这是因为大量主机可能希望通过主干网进行通信，因此需要大型地址表，也因为将有更多的应用程序依赖于配置的地址，而不是访问名称服务器。我们称这种专用网络为主干分区专用网络。
Backbone-partitioned stubs should behave as though they were a non-partitioned stub. That is, the routers in all partitions should maintain routes to the local address spaces of all partitions. Of course, the (public) backbones do not maintain routes to any local addresses. Therefore, the border routers must tunnel (using VPNs) through the backbones using encapsulation. To do this, each NAT box will set aside a global address for tunneling.
主干分区存根的行为应与非分区存根的行为相同。也就是说，所有分区中的路由器都应该维护到所有分区的本地地址空间的路由。当然，（公共）主干网不维护到任何本地地址的路由。因此，边界路由器必须使用封装（使用VPN）穿越主干网。为此，每个NAT盒将留出一个全局地址用于隧道。
When a NAT box x in stub partition X wishes to deliver a packet to stub partition Y, it will encapsulate the packet in an IP header with destination address set to the global address of NAT box y that has been reserved for encapsulation. When NAT box y receives a packet with that destination address, it decapsulates the IP header and routes the packet internally. Note, there is no address translation in the process; merely transfer of private network packets over an external network tunnel backbone.
当存根分区x中的NAT盒x希望将数据包传送到存根分区Y时，它将数据包封装在IP报头中，目的地地址设置为NAT盒Y的全局地址，该地址已保留用于封装。当NAT盒y接收到具有该目标地址的数据包时，它将解除IP报头的封装并在内部路由该数据包。注意，在此过程中没有地址转换；仅通过外部网络隧道主干传输专用网络数据包。
NAT devices are application unaware in that the translations are limited to IP/TCP/UDP/ICMP headers and ICMP error messages only. NAT devices do not change the payload of the packets, as payloads tend to be application specific.
NAT设备不知道应用程序，因为转换仅限于IP/TCP/UDP/ICMP头和ICMP错误消息。NAT设备不会改变数据包的有效载荷，因为有效载荷往往是特定于应用程序的。
NAT devices (without the inclusion of ALGs) do not examine or modify transport payload. For this reason, NAT devices are transparent to applications in many cases. There are two areas, however, where NAT devices often cause difficulties: 1) when an application payload includes an IP address, and 2) when end-to-end security is needed. Note, this is not a comprehensive list.
NAT设备（不包括ALG）不检查或修改传输有效载荷。因此，NAT设备在许多情况下对应用程序是透明的。然而，NAT设备通常会在两个方面造成困难：1）当应用程序负载包括IP地址时，以及2）当需要端到端安全时。注意，这不是一个全面的列表。
Application layer security techniques that do not make use of or depend on IP addresses will work correctly in the presence of NAT (e.g., TLS, SSL and ssh). In contrast, transport layer techniques such as IPSec transport mode or the TCP MD5 Signature Option RFC 2385 [Ref 17] do not.
不使用或不依赖IP地址的应用层安全技术将在NAT（例如TLS、SSL和ssh）存在的情况下正常工作。相反，诸如IPSec传输模式或TCP MD5签名选项RFC 2385[Ref 17]之类的传输层技术则没有。
In IPSec transport mode, both AH and ESP have an integrity check covering the entire payload. When the payload is TCP or UDP, the TCP/UDP checksum is covered by the integrity check. When a NAT device modifies an address the checksum is no longer valid with respect to the new address. Normally, NAT also updates the checksum, but this is ineffective when AH and ESP are used. Consequently, receivers will discard a packet either because it fails the IPSec integrity check (if the NAT device updates the checksum), or because the checksum is invalid (if the NAT device leaves the checksum unmodified).
在IPSec传输模式下，AH和ESP都有覆盖整个有效负载的完整性检查。当有效负载为TCP或UDP时，TCP/UDP校验和由完整性检查覆盖。当NAT设备修改地址时，校验和对新地址不再有效。通常，NAT也会更新校验和，但在使用AH和ESP时，这是无效的。因此，接收方将丢弃数据包，因为它未通过IPSec完整性检查（如果NAT设备更新校验和），或者因为校验和无效（如果NAT设备未修改校验和）。
Note that IPsec tunnel mode ESP is permissible so long as the embedded packet contents are unaffected by the outer IP header translation. Although this technique does not work in traditional NAT deployments (i.e., where hosts are unaware that NATs are present), the technique is applicable to Realm-Specific IP as described in Section 5.0.
请注意，只要嵌入的数据包内容不受外部IP头转换的影响，IPsec隧道模式ESP是允许的。尽管此技术在传统NAT部署中不起作用（即，主机不知道存在NAT），但如第5.0节所述，此技术适用于特定领域的IP。
Note also that end-to-end ESP based transport mode authentication and confidentiality are permissible for packets such as ICMP, whose IP payload content is unaffected by the outer IP header translation.
还请注意，对于ICMP等IP有效负载内容不受外部IP报头转换影响的数据包，允许使用基于端到端ESP的传输模式身份验证和机密性。
NAT devices also break fundamental assumptions by public key distribution infrastructures such as Secure DNS RFC 2535 [Ref 18] and X.509 certificates with signed public keys. In the case of Secure
NAT设备也打破了公钥分发基础设施的基本假设，如安全DNS RFC 2535[Ref 18]和带有签名公钥的X.509证书。在安全的情况下
DNS, each DNS RRset is signed with a key from within the zone. Moreover, the authenticity of a specific key is verified by following a chain of trust that goes all the way to the DNS root. When a DNS-ALG modifies addresses (e.g., as in the case of Twice-NAT), verification of signatures fails.
DNS，每个DNS RRset都使用区域内的密钥进行签名。此外，特定密钥的真实性是通过遵循一条一直到DNS根的信任链来验证的。当DNS-ALG修改地址时（例如，在两次NAT的情况下），签名验证失败。
It may be of interest to note that IKE (Session key negotiation protocol) is a UDP based session layer protocol and is not protected by network based IPsec security. Only a portion of the individual payloads within IKE are protected. As a result, IKE sessions are permissible across NAT, so long as IKE payload does not contain addresses and/or transport IDs specific to one realm and not the other. Given that IKE is used to setup IPSec associations, and there are at present no known ways of making IPSec work through a NAT function, it is a future work item to take advantage of IKE through a NAT box.
值得注意的是，IKE（会话密钥协商协议）是基于UDP的会话层协议，不受基于网络的IPsec安全保护。IKE中只有一部分单独的有效载荷受到保护。因此，只要IKE有效负载不包含特定于一个领域而不是另一个领域的地址和/或传输ID，就可以跨NAT进行IKE会话。考虑到IKE用于设置IPSec关联，并且目前还没有已知的通过NAT功能使IPSec工作的方法，因此通过NAT盒利用IKE是未来的工作项目。
One of the most popular internet applications "FTP" would not work with the definition of NAT as described. The following sub-section is devoted to describing how FTP is supported on NAT devices. FTP ALG is an integral part of most NAT implementations. Some vendors may choose to include additional ALGs to custom support other applications on the NAT device.
最流行的互联网应用程序之一“FTP”无法使用所述的NAT定义。以下小节专门介绍如何在NAT设备上支持FTP。FTP ALG是大多数NAT实现不可或缺的一部分。一些供应商可能会选择包括其他ALG，以自定义支持NAT设备上的其他应用程序。
"PORT" command and "PASV" response in FTP control session payload identify the IP address and TCP port that must be used for the data session it supports. The arguments to the PORT command and PASV response are an IP address and a TCP port in ASCII. An FTP ALG is required to monitor and update the FTP control session payload so that information contained in the payload is relevant to end nodes. The ALG must also update NAT with appropriate data session tuples and session orientation so that NAT could set up state information for the FTP data sessions.
FTP控制会话有效负载中的“PORT”命令和“PASV”响应标识其支持的数据会话必须使用的IP地址和TCP端口。端口命令和PASV响应的参数是一个IP地址和一个ASCII格式的TCP端口。需要FTP ALG来监视和更新FTP控制会话有效负载，以便有效负载中包含的信息与终端节点相关。ALG还必须使用适当的数据会话元组和会话方向更新NAT，以便NAT可以为FTP数据会话设置状态信息。
Because the address and TCP port are encoded in ASCII, this may result in a change in the size of packet. For instance, 10,18,177,42,64,87 is 18 ASCII characters, whereas 193,45,228,137,64,87 is 20 ASCII characters. If the new size is same as the previous, only the TCP checksum needs adjustment as a result of change of data. If the new size is less than or greater than the previous, TCP sequence numbers must also be changed to reflect the change in length of FTP control data portion. A special table may be used by the ALG to correct the TCP sequence and acknowledge numbers. The sequence number and acknowledgement correction will need to be performed on all future packet of the connection.
因为地址和TCP端口是用ASCII编码的，这可能会导致数据包大小的变化。例如，10,18177,42,64,87是18个ASCII字符，而193,45228137,64,87是20个ASCII字符。如果新的大小与前一个相同，则只有TCP校验和需要根据数据的变化进行调整。如果新的大小小于或大于以前的大小，则还必须更改TCP序列号，以反映FTP控制数据部分长度的变化。ALG可以使用一个特殊的表来纠正TCP序列和确认号。需要对连接的所有未来数据包执行序列号和确认更正。
Not All applications lend themselves easily to address translation by NAT devices. Especially, the applications that carry IP address (and TU port, in case of NAPT) inside the payload. Application Level Gateways, or ALGs must be used to perform translations on packets pertaining to such applications. ALGs may optionally utilize address (and TU port) assignments made by NAT and perform translations specific to the application. The combination of NAT functionality and ALGs will not provide end-to-end security assured by IPsec. However, tunnel mode IPsec can be accomplished with NAT router serving as tunnel end point.
并不是所有的应用程序都能很容易地通过NAT设备进行翻译。特别是在有效负载中承载IP地址（以及TU端口，如果是NAPT）的应用程序。必须使用应用程序级网关或ALG对与此类应用程序相关的数据包执行翻译。ALG可以选择性地利用NAT进行的地址（和TU端口）分配，并执行特定于应用程序的翻译。NAT功能和ALG的组合将不会提供由IPsec保证的端到端安全性。然而，隧道模式IPsec可以通过NAT路由器作为隧道端点来实现。
SNMP is one such application with address content in payload. NAT routers would not translate IP addresses within SNMP payloads. It is not uncommon for an SNMP specific ALG to reside on a NAT router to perform SNMP MIB translations proprietary to the private network.
SNMP就是这样一种应用程序，其有效负载中包含地址内容。NAT路由器不会在SNMP有效负载内转换IP地址。SNMP特定ALG驻留在NAT路由器上执行专用于专用网络的SNMP MIB转换的情况并不少见。
NAT devices operate on the assumption that each session is independent. Session characteristics like session orientation, source and destination IP addresses, session protocol, and source and destination transport level identifiers are determined independently at the start of each new session.
NAT设备的运行假设每个会话都是独立的。会话特性（如会话方向、源和目标IP地址、会话协议以及源和目标传输级别标识符）在每个新会话开始时独立确定。
However, there are applications such as H.323 that use one or more control sessions to set the characteristics of the follow-on sessions in their control session payload. Such applications require use of application specific ALGs that can interpret and translate the payload, if necessary. Payload interpretation would help NAT be prepared for the follow-on data sessions.
然而，诸如H.323之类的应用程序使用一个或多个控制会话在其控制会话有效负载中设置后续会话的特征。此类应用需要使用特定于应用的ALG，如有必要，ALG可以解释和转换有效载荷。有效载荷解释将帮助NAT为后续数据会话做好准备。
NAT increases the probability of mis-addressing. For example, same local address may be bound to different global address at different times and vice versa. As a result, any traffic flow study based purely on global addresses and TU ports could be confused and might misinterpret the results.
NAT增加了误寻址的可能性。例如，相同的本地地址可能在不同的时间绑定到不同的全局地址，反之亦然。因此，任何纯粹基于全局地址和TU端口的流量研究都可能会混淆，并可能误解结果。
If a host is abusing the Internet in some way (such as trying to attack another machine or even sending large amounts of junk mail or something) it is more difficult to pinpoint the source of the trouble because the IP address of the host is hidden in a NAT router.
如果主机以某种方式滥用互联网（例如试图攻击另一台机器，甚至发送大量垃圾邮件或其他东西），则更难查明问题的根源，因为主机的IP地址隐藏在NAT路由器中。
Translation of fragmented FTP control packets is tricky when the packets contain "PORT" command or response to "PASV" command. Clearly, this is a pathological case. NAT router would need to assemble the fragments together first and then translate prior to forwarding.
当数据包包含“PORT”命令或对“PASV”命令的响应时，翻译碎片化的FTP控制数据包是很棘手的。显然，这是一个病理性病例。NAT路由器需要首先将这些片段组装在一起，然后在转发之前进行翻译。
Yet another case would be when each character of packets containing "PORT" command or response to "PASV" is sent in a separate datagram, unfragmented. In this case, NAT would simply have to let the packets through, without translating the TCP payload. Of course, the application will fail if the payload needed to be altered. The application could still work in a few cases, where the payload contents can be valid in both realms, without modifications enroute. For example, FTP originated from a private host would still work while traversing a traditional NAT or bi-directional NAT device, so long as the FTP control session employed PASV command to establish data sessions. The reason being that the address and port number specified by FTP server in the PASV response (sent as multiple unfragmented packets) is valid to the private host, as is. The NAT device will simply view the ensuing data session (also originating from private host) as an independent TCP session.
另一种情况是，包含“PORT”命令或对“PASV”的响应的数据包的每个字符都在单独的数据报中发送，没有分段。在这种情况下，NAT只需让数据包通过，而无需转换TCP负载。当然，如果需要更改有效负载，应用程序将失败。该应用程序仍然可以在少数情况下工作，其中有效负载内容可以在两个领域中都有效，而无需在途中进行修改。例如，只要FTP控制会话使用PASV命令建立数据会话，来自专用主机的FTP在穿越传统NAT或双向NAT设备时仍能工作。原因是FTP服务器在PASV响应中指定的地址和端口号（作为多个未分段的数据包发送）对专用主机是有效的。NAT设备只需将随后的数据会话（也源自专用主机）视为一个独立的TCP会话。
NAT is compute intensive even with the help of a clever checksum adjustment algorithm, as each data packet is subject to NAT lookup and modifications. As a result, router forwarding throughput could be slowed considerably. However, so long as the processing capacity of the NAT device exceeds line processing rate, this should not be a problem.
NAT是计算密集型的，即使借助于巧妙的校验和调整算法，因为每个数据包都要经过NAT查找和修改。因此，路由器转发吞吐量可能会大大降低。然而，只要NAT设备的处理能力超过线路处理速率，这就不应该是问题。
Many people view traditional NAT router as a one-way (session) traffic filter, restricting sessions from external hosts into their machines. In addition, when address assignment in NAT router is done dynamically, that makes it harder for an attacker to point to any specific host in the NAT domain. NAT routers may be used in conjunction with firewalls to filter unwanted traffic.
许多人将传统NAT路由器视为单向（会话）流量过滤器，限制从外部主机到其机器的会话。此外，当NAT路由器中的地址分配是动态完成的时，攻击者更难指向NAT域中的任何特定主机。NAT路由器可与防火墙结合使用，以过滤不需要的流量。
If NAT devices and ALGs are not in a trusted boundary, that is a major security problem, as ALGs could snoop end user traffic payload. Session level payload could be encrypted end to end, so long as the payload does not contain IP addresses and/or transport identifiers that are valid in only one of the realms. With the exception of RSIP, end-to-end IP network level security assured by current IPsec
如果NAT设备和ALG不在可信边界内，这将是一个主要的安全问题，因为ALG可能会窥探最终用户流量负载。会话级有效负载可以端到端加密，只要有效负载不包含仅在一个域中有效的IP地址和/或传输标识符。除了RSIP之外，端到端IP网络级别的安全由当前IPsec保证
techniques is not attainable with NAT devices in between. One of the ends must be a NAT box. Refer section 7.0 for a discussion on why end-to-end IPsec security cannot be assured with NAT devices along the route.
在NAT设备介于两者之间的情况下，这些技术是无法实现的。一端必须是NAT盒。请参阅第7.0节，了解为什么路由沿线的NAT设备无法确保端到端IPsec安全性。
The combination of NAT functionality, ALGs and firewalls will provide a transparent working environment for a private networking domain. With the exception of RSIP, end-to-end network security assured by IPsec cannot be attained for end-hosts within the private network (Refer section 5.0 for RSIP operation). In all other cases, if you want to use end-to-end IPsec, there cannot be a NAT device in the path. If we make the assumption that NAT devices are part of a trusted boundary, tunnel mode IPsec can be accomplished with NAT router (or a combination of NAT, ALGs and firewall) serving as tunnel end point.
NAT功能、ALG和防火墙的结合将为私有网络域提供透明的工作环境。除RSIP外，无法为专用网络内的终端主机实现由IPsec保证的端到端网络安全（RSIP操作请参阅第5.0节）。在所有其他情况下，如果要使用端到端IPsec，则路径中不能有NAT设备。如果我们假设NAT设备是可信边界的一部分，则可以使用NAT路由器（或NAT、ALGs和防火墙的组合）作为隧道端点来实现隧道模式IPsec。
NAT devices, when combined with ALGs, can ensure that the datagrams injected into Internet have no private addresses in headers or payload. Applications that do not meet these requirements may be dropped using firewall filters. For this reason, it is not uncommon to find NAT, ALG and firewall functions co-exist to provide security at the borders of a private network. NAT gateways can be used as tunnel end points to provide secure VPN transport of packet data across an external network domain.
当NAT设备与ALG结合时，可以确保注入互联网的数据报在报头或有效负载中没有私有地址。不符合这些要求的应用程序可能会使用防火墙过滤器丢弃。因此，NAT、ALG和防火墙功能共存以在专用网络边界提供安全性的情况并不少见。NAT网关可以用作隧道端点，以跨外部网络域提供分组数据的安全VPN传输。
Below are some additional security considerations associated with NAT routers.
下面是一些与NAT路由器相关的附加安全注意事项。
1. UDP sessions are inherently unsafe. Responses to a datagram could come from an address different from the target address used by sender ([Ref 4]). As a result, an incoming UDP packet might match the outbound session of a traditional NAT router only in part (the destination address and UDP port number of the packet match, but the source address and port number may not). In such a case, there is a potential security compromise for the NAT device in permitting inbound packets with partial match. This UDP security issue is also inherent to firewalls.
1. UDP会话本质上是不安全的。对数据报的响应可能来自与发送方使用的目标地址不同的地址（[Ref 4]）。因此，传入UDP数据包可能仅部分匹配传统NAT路由器的出站会话（数据包的目标地址和UDP端口号匹配，但源地址和端口号可能不匹配）。在这种情况下，NAT设备在允许部分匹配的入站数据包时存在潜在的安全隐患。这个UDP安全问题也是防火墙固有的。
Traditional NAT implementations that do not track datagrams on a per-session basis but lump states of multiple UDP sessions using the same address binding into a single unified session could compromise the security even further. This is because, the granularity of packet matching would be further limited to just the destination address of the inbound UDP packets.
传统的NAT实现不在每个会话的基础上跟踪数据报，而是将使用相同地址绑定的多个UDP会话的状态集中到单个统一会话中，这可能会进一步损害安全性。这是因为，数据包匹配的粒度将进一步限制为仅限入站UDP数据包的目标地址。
2. Multicast sessions (UDP based) are another source for security weakness for traditional-NAT routers. Once again, firewalls face the same security dilemma as the NAT routers.
2. 多播会话（基于UDP）是传统NAT路由器安全弱点的另一个来源。防火墙再次面临与NAT路由器相同的安全困境。
Say, a host on private network initiated a multicast session. Datagram sent by the private host could trigger responses in the reverse direction from multiple external hosts. Traditional-NAT implementations that use a single state to track a multicast session cannot determine for certain if the incoming UDP packet is in response to an existing multicast session or the start of new UDP session initiated by an attacker.
例如，专用网络上的主机启动了多播会话。专用主机发送的数据报可能会触发来自多个外部主机的反向响应。使用单一状态跟踪多播会话的传统NAT实现无法确定传入UDP数据包是响应现有多播会话还是由攻击者启动的新UDP会话。
3. NAT devices can be a target for attacks.
3. NAT设备可能成为攻击的目标。
Since NAT devices are Internet hosts they can be the target of a number of different attacks, such as SYN flood and ping flood attacks. NAT devices should employ the same sort of protection techniques as Internet-based servers do.
由于NAT设备是Internet主机，它们可能成为许多不同攻击的目标，例如SYN洪水攻击和ping洪水攻击。NAT设备应采用与基于互联网的服务器相同的保护技术。
REFERENCES
参考资料
[1] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[1] Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October, 1994.
[2] Reynolds，J.和J.Postel，“分配的数字”，标准2，RFC 1700，1994年10月。
[3] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[3] Braden，R.，“互联网主机的要求——通信层”，STD 3，RFC 1122，1989年10月。
[4] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[4] Braden，R.，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[5] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[5] Baker，F.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[6] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[6] Postel，J.和J.Reynolds，“文件传输协议（FTP）”，标准9，RFC 959，1985年10月。
[7] Postel, J., "Transmission Control Protocol (TCP) Specification", STD 7, RFC 793, September 1981.
[7] 《传输控制协议（TCP）规范》，标准7，RFC 793，1981年9月。
[8] Postel, J., "Internet Control Message Protocol Specification" STD 5, RFC 792, September 1981.
[8] Postel，J.，“互联网控制消息协议规范”STD 5，RFC 792，1981年9月。
[9] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, August 1980.
[9] Postel，J.，“用户数据报协议（UDP）”，STD 6，RFC 768，1980年8月。
[10] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
[10] Mogul，J.和J.Postel，“互联网标准子网程序”，STD 5，RFC 950，1985年8月。
[11] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behavior Today", RFC 2101, February 1997.
[11] Carpenter，B.，Crowcroft，J.和Y.Rekhter，“今天的IPv4地址行为”，RFC21011997年2月。
[12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[12] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[13] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[13] Kent，S.和R.Atkinson，“IP封装安全有效载荷（ESP）”，RFC 2406，1998年11月。
[14] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[14] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[15] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[15] Harkins，D.和D.Carrel，“互联网密钥交换（IKE）”，RFC 2409，1998年11月。
[16] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[16] Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[17] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[17] Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
[18] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[18] Eastlake，D.，“域名系统安全扩展”，RFC 25351999年3月。
Authors' Addresses
作者地址
Pyda Srisuresh Lucent Technologies 4464 Willow Road Pleasanton, CA 94588-8519 U.S.A.
美国加利福尼亚州普莱森顿柳树路4464号Pyda Srisuresh-Lucent Technologies，邮编94588-8519。
Phone: (925) 737-2153 Fax: (925) 737-2110 EMail: srisuresh@lucent.com
电话：（925）737-2153传真：（925）737-2110电子邮件：srisuresh@lucent.com
Matt Holdrege Lucent Technologies 1701 Harbor Bay Parkway Alameda, CA 94502
马特·霍德雷格·朗讯科技有限公司，地址：加利福尼亚州阿拉米达港湾公园路1701号，邮编：94502
Phone: (510) 769-6001 EMail: holdrege@lucent.com
电话：（510）769-6001电子邮件：holdrege@lucent.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。