Network Working Group D. Senie
Request for Comments: 3235 Amaranth Networks Inc.
Category: Informational January 2002
Network Working Group D. Senie
Request for Comments: 3235 Amaranth Networks Inc.
Category: Informational January 2002
Network Address Translator (NAT)-Friendly Application Design Guidelines
网络地址转换器（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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document discusses those things that application designers might wish to consider when designing new protocols. While many common Internet applications will operate cleanly in the presence of Network Address Translators, others suffer from a variety of problems when crossing these devices. Guidelines are presented herein to help ensure new protocols and applications will, to the extent possible, be compatible with NAT (Network Address Translation).
本文档讨论了应用程序设计者在设计新协议时可能需要考虑的事项。虽然许多常见的互联网应用程序在有网络地址转换器的情况下可以干净地运行，但其他应用程序在穿越这些设备时会遇到各种各样的问题。本文提供的指南有助于确保新协议和应用程序尽可能与NAT（网络地址转换）兼容。
Other documents that describe Network Address Translation (NAT) discuss the Terminology and Considerations [RFC2663] and Protocol Issues [RFC3022], [RFC3027] or discuss the implications of NAT [RFC2993]. All of those relate to various issues with the NAT mechanism, effects on protocols and effects upon general Internet architecture.
描述网络地址转换（NAT）的其他文件讨论了术语和注意事项[RFC2663]和协议问题[RFC3022]、[RFC3027]或讨论了NAT的含义[RFC2993]。所有这些都与NAT机制的各种问题、对协议的影响以及对通用Internet架构的影响有关。
It is the focus of this document to provide recommendations to authors of new protocols about the effects to consider when designing new protocols such that special handling is not required at NAT gateway points.
本文档的重点是为新协议的作者提供关于设计新协议时要考虑的效果的建议，以便在NAT网关点不需要特殊处理。
When a protocol is unable to pass cleanly through a NAT, the use of an Application Level Gateway (ALG) may still permit operation of the protocol. Depending on the encoding used in a protocol, an ALG may be difficult or easy to construct, though in some cases it may not be possible at all. While adjunct to NAT, the formulation of protocols that cannot directly operate through NAT should be considered such
当协议无法干净地通过NAT时，应用程序级网关（ALG）的使用可能仍然允许协议的操作。根据协议中使用的编码，ALG可能很难或很容易构造，尽管在某些情况下可能根本不可能。虽然是NAT的附属品，但不能通过NAT直接运行的协议的制定应被视为是这样的
that the ALG design may be simple and automated. ALGs typically operate inside small routers along with the NAT component. Ideally, the ALG should be simple and not require excessive computation or state storage.
ALG设计可能简单且自动化。ALG通常与NAT组件一起在小型路由器内运行。理想情况下，ALG应该是简单的，不需要过多的计算或状态存储。
Many of the same issues in application design that create issues for NAT (and thus can require ALG support) are also issues for firewalls. An application designer would do well to keep this in mind, as any protocol that does require special handling by NAT or firewall products will be more difficult to deploy than those that require no special handling.
应用程序设计中为NAT造成问题（因此可能需要ALG支持）的许多相同问题也是防火墙的问题。应用程序设计者最好记住这一点，因为任何需要NAT或防火墙产品进行特殊处理的协议都比不需要特殊处理的协议更难部署。
Network Address Translation presents a challenge to some existing applications. In many cases, it should be possible for developers of new applications to avoid problems if they understand the issues. This document aims to provide the application designer with information on what things they can do and what to avoid when trying to build applications that are able to function across NAT.
网络地址转换对一些现有的应用程序提出了挑战。在许多情况下，如果新应用程序的开发人员理解问题，他们应该能够避免问题。本文档旨在向应用程序设计师提供信息，说明他们在尝试构建能够跨NAT运行的应用程序时可以做什么，以及避免做什么。
The proliferation of NAT, especially in homes and small offices cannot be dismissed. The marketing of these technologies to homes and small businesses is often focused on a single-computer environment, and thus providers only give out a single IP address to each user. NAT has become a popular choice for connecting more than a single system per location.
NAT的泛滥，尤其是在家庭和小型办公室，不容忽视。这些技术向家庭和小型企业的营销通常集中在单个计算机环境上，因此提供商只向每个用户提供一个IP地址。NAT已成为每个位置连接多个系统的流行选择。
Clearly the most common problem associated with NAT implementations is the passing of addressing data between stations. Where possible, applications should find alternatives to such schemes. Studying a few existing protocols will serve to highlight the different approaches possible.
显然，与NAT实现相关的最常见问题是站点之间的寻址数据传递。在可能的情况下，申请者应找到此类计划的替代方案。研究一些现有的协议将有助于强调可能的不同方法。
Two common forms of Traditional NAT exist. With Basic NAT, only the IP addresses of packets are altered by the NAT implementation. Many applications will operate correctly with Basic NAT. The other common form is Network Address Port Translation. With NAPT, both the IP addresses and the source and destination ports (for TCP and UDP) are potentially altered by the gateway. As such, applications passing only port number information will work with Basic NAT, but not with NAPT.
存在两种常见的传统NAT形式。对于基本NAT，NAT实现只改变数据包的IP地址。许多应用程序将使用基本NAT正常运行。另一种常见形式是网络地址端口转换。使用NAPT，网关可能会更改IP地址以及源端口和目标端口（对于TCP和UDP）。因此，仅传递端口号信息的应用程序将使用基本NAT，而不使用NAPT。
Application designers should strive for compatibility with NAPT, as this form of NAT is the most widely deployed. This is also the form of NAT that will likely see the greatest penetration in homes and small offices. Not all applications lend themselves to the architectural model imposed by NAPT.
应用程序设计者应该努力与NAPT兼容，因为这种形式的NAT是部署最广泛的。这也是NAT的形式，在家庭和小型办公室中可能会看到最大的渗透。并非所有应用程序都适用于NAPT强加的体系结构模型。
Application designers who work within the constraints of NAT, and who do not rely on the presence of ALGs will generally find the easier acceptance in user communities where NAT is common. When designing a new application or service, the requirement for an ALG will limit deployment until the required additional code is incorporated into the many devices which implement NAT.
在NAT约束范围内工作且不依赖ALG存在的应用程序设计人员通常会发现NAT常见的用户社区更容易接受。在设计新的应用程序或服务时，ALG的要求将限制部署，直到所需的附加代码被合并到许多实现NAT的设备中。
Each of the areas called out below are examples of issues to consider when building an application. This list is likely not comprehensive, but does cover a number of important issues and considerations.
下面列出的每个区域都是构建应用程序时要考虑的问题的例子。这份清单可能并不全面，但确实涵盖了一些重要问题和考虑因素。
3.1 Issues and Recommendations affecting all types of Network Address Translators
3.1 影响所有类型网络地址转换器的问题和建议
Peer to peer applications are problematic in a NAT world. Client-server applications are more generally workable. Peer-to-peer applications rely on each peer being reachable as a server (i.e., bound to a listening port, and able to accept connections) for the other to connect to. With NAPT, there are likely many machines behind one address. With other types of NAT such as Basic NAT with Static Address Assignment (providing one-to-one mappings), there is a greater chance of making such applications work.
对等应用程序在NAT世界中是有问题的。客户机-服务器应用程序通常更可行。对等应用程序依赖于每个对等方都可以作为服务器访问（即绑定到侦听端口，并且能够接受连接），以供另一方连接。使用NAPT，一个地址后面可能有许多机器。对于其他类型的NAT，例如具有静态地址分配的基本NAT（提供一对一映射），使此类应用程序工作的可能性更大。
Some implementations of NAT can be made to function for UDP-based peer-to-peer applications. This capability is dependent on the methodology used to implement the UDP sessions in the NAT device. If the NAT device tracks the tuple (private address, private port, public port) then it is possible for an outbound UDP packet to establish a channel by which incoming traffic can flow from a source other than that originally contacted by the system. The source IP address is NOT used in this case to match incoming packets to UDP sessions, allowing any source address using the UDP port number to be translated.
NAT的一些实现可以用于基于UDP的对等应用程序。此功能取决于用于在NAT设备中实现UDP会话的方法。如果NAT设备跟踪元组（专用地址、专用端口、公共端口），则出站UDP数据包可以建立一个通道，通过该通道，进入的流量可以从系统最初接触的源以外的源流出。在这种情况下，源IP地址不用于将传入数据包与UDP会话匹配，从而允许转换使用UDP端口号的任何源地址。
NAT devices which track source and destination IP addresses, in addition to port numbers, will not permit third-party packets. NAT is often implemented in conjunction along with stateful-inspection firewall functionality. As such the latter implementation of UDP association tracking would be considered more secure.
除了端口号之外，跟踪源和目标IP地址的NAT设备将不允许第三方数据包。NAT通常与状态检查防火墙功能一起实现。因此，UDP关联跟踪的后一种实现将被认为更安全。
NAT/Firewall device implementations could be constructed to have a software switch within them, permitting the consumer the ability to select whether they want the greater security, or greater ability to run peer-to-peer applications.
NAT/防火墙设备实现可以构造为在其内部具有软件交换机，从而允许消费者能够选择他们是想要更高的安全性，还是想要更高的运行对等应用程序的能力。
Use of IPSec for end-to-end security will not function in the presence of a NAT implementation. Application designers may want to explore the use of Transport Layer Security (TLS) [RFC2246] as a transport mode that will traverse NAT cleanly. See [RFC2709] for additional discussion on combining NAT with Tunnel-mode IPSec security on the same device.
在存在NAT实现的情况下，使用IPSec实现端到端安全将无法正常工作。应用程序设计者可能希望探索将传输层安全性（TLS）[RFC2246]作为一种干净地穿越NAT的传输模式的使用。有关在同一设备上结合NAT和隧道模式IPSec安全性的更多讨论，请参阅[RFC2709]。
Applications should, where possible, use fully qualified domain names rather than IP addresses when referring to IP endpoints. When endpoints are across a NAT gateway, private addresses must not be allowed to leak to the other endpoint. An example of where this can happen today is with the HTTP and HTML protocols. It is possible for web pages to be specified with numeric IP addresses, rather than with names, for example http://192.168.1.10/index.html could be used as a URL, but would likely create a problem if this address is on a server located behind a NAT gateway. Users outside the gateway would not be able to reach the address 192.168.1.10, and so would not see the page.
应用程序在引用IP端点时，应尽可能使用完全限定的域名，而不是IP地址。当端点跨NAT网关时，不得允许私有地址泄漏到另一个端点。今天，HTTP和HTML协议就是这样一个例子。例如，可以使用数字IP地址而不是名称来指定网页http://192.168.1.10/index.html 可以用作URL，但如果此地址位于NAT网关后面的服务器上，则可能会产生问题。网关之外的用户将无法访问地址192.168.1.10，因此无法看到该页面。
Further exacerbating the problem is the possibility of duplicate addresses between realms. If a server offers a link with a private address space IP address embedded within it, such as 192.168.1.10, the page referenced may resolve to a system on the local network the browser is on, but would be a completely different server. The resulting confusion to end-users would be significant. Sessions involving multiple NAT implementations would be exceptionally vulnerable to address reuse issues of this sort.
使问题进一步恶化的是两个领域之间存在地址重复的可能性。如果服务器提供的链接中嵌入了专用地址空间IP地址（如192.168.1.10），则引用的页面可能解析为浏览器所在的本地网络上的系统，但可能是完全不同的服务器。最终用户由此产生的困惑将是巨大的。涉及多个NAT实现的会话极易解决此类重用问题。
Not all NAT devices implement multicast routing protocols. Application designers should verify whether the devices in the networks where their applications will be deployed are able to process multicast traffic if their applications rely on that capability.
并非所有NAT设备都实现多播路由协议。如果应用程序依赖于多播流量，应用程序设计者应验证其应用程序将部署的网络中的设备是否能够处理多播流量。
With the exception of statically configured NAT bindings, applications should not assume address mapping will be maintained from one session (association between machines, for whatever protocol for a period of time) to another. An example of this is RSVP, which forms one connection to reserve the resources, then the actual session for which resources were reserved is started. The sessions
除了静态配置的NAT绑定之外，应用程序不应该假设地址映射将从一个会话（机器之间的关联，在一段时间内用于任何协议）维护到另一个会话。例如RSVP，它形成一个连接来保留资源，然后启动为其保留资源的实际会话。会议
do not necessarily overlap. There is no guarantee that the NAT implementation will keep the binding association. As such, applications that rely on subsequent sessions being mapped to the same host IP address may not function without an ALG.
不一定重叠。不能保证NAT实现将保持绑定关联。因此，如果没有ALG，依赖于映射到同一主机IP地址的后续会话的应用程序可能无法运行。
Another consideration is the number of addressing realms. It is entirely possible to have multiple levels of NAT implementations between the two end points involved. As such, one must think about the lifetime of such mappings at all such levels.
另一个考虑因素是寻址域的数量。在涉及的两个端点之间，完全有可能有多个级别的NAT实现。因此，我们必须考虑所有这些级别的映射的生命周期。
Load balancers and other devices may use a single IP address and port to map to multiple actual end points. Many products implement variations on this theme, sometimes using NAT, sometimes using other technologies. The lack of guarantee of mapping is important to understand, since the mapping to one actual system to another may not survive across such intermediate boxes.
负载平衡器和其他设备可以使用单个IP地址和端口映射到多个实际端点。许多产品实现了这个主题的变体，有时使用NAT，有时使用其他技术。缺乏对映射的保证很重要，因为从一个实际系统到另一个实际系统的映射可能无法跨越这些中间框。
Don't assume systems know their own IP addresses. A system behind a NAT may be reachable via a particular IP address, but that address may not be recognized by the system itself. Consider the case of Static, one-to-one mapping using Basic NAT. A server in this context will have an IP address from the private realm, and may not know the public address which maps to it. Similarly, some such systems may not know their own DNS names, while others may. This is largely dependent on the configuration of the servers and the network within the private realm.
不要假设系统知道自己的IP地址。NAT后面的系统可以通过特定的IP地址访问，但系统本身可能无法识别该地址。考虑使用基本NAT的静态、一对一映射的情况。此上下文中的服务器将具有来自私有领域的IP地址，并且可能不知道映射到它的公共地址。类似地，一些这样的系统可能不知道自己的DNS名称，而其他系统可能不知道自己的DNS名称。这在很大程度上取决于服务器和私有领域内网络的配置。
As many of the issues specifically address NAPT issues, this section will group these issues. NAPT is the most common form of NAT in actual deployment in routers, especially in smaller offices and home offices.
由于许多问题专门针对NAPT问题，本节将对这些问题进行分组。NAPT是路由器实际部署中最常见的NAT形式，尤其是在小型办公室和家庭办公室中。
Avoid the use of IP address and port number information within the payload of packets. While in some cases ALGs will permit such protocols to function, this presupposes every NAT device can be updated in a timely fashion to support a new protocol. Since this is unlikely, application writers are urged to avoid placing addressing information in payloads all together.
避免在数据包的有效负载中使用IP地址和端口号信息。虽然在某些情况下，ALGs将允许此类协议发挥作用，但前提是每个NAT设备都可以及时更新以支持新协议。由于这种情况不太可能发生，因此建议应用程序编写者避免将寻址信息全部放在有效负载中。
In addition to avoiding addresses and port numbers within packet payloads, it is important to avoid assumptions of (address, port) tuples are unique beyond the scope of the present session. Load balancing devices implementing NAT may, for example, map subsequent sessions to other systems in the private realm.
除了避免数据包有效负载中的地址和端口号之外，重要的是避免假设（地址、端口）元组在当前会话范围之外是唯一的。例如，实现NAT的负载平衡设备可以将后续会话映射到私有领域中的其他系统。
Independent sessions, such as used by POP or SMTP, are preferred to protocols that attempt to manage a bundle of related sessions, such as FTP. The term "session" here is used to refer to any association between end systems, and may be using any transport protocol or combination of protocols (UDP, TCP, SCTP).
独立会话（如POP或SMTP使用的会话）优先于尝试管理一组相关会话（如FTP）的协议。这里的术语“会话”用于指终端系统之间的任何关联，并且可以使用任何传输协议或协议组合（UDP、TCP、SCTP）。
In the FTP protocol, port information is passed over one TCP connection and is used to construct a second TCP connection for passing the actual data. Use of a separate connection to transfer the file data makes determination of file end quite simple, however other schemes could be envisioned which could use a single connection.
在FTP协议中，端口信息通过一个TCP连接传递，并用于构造第二个TCP连接以传递实际数据。使用单独的连接来传输文件数据使得文件结束的确定非常简单，但是可以设想使用单个连接的其他方案。
The HTTP protocol, for example, uses a header and content length approach to passing data. In this model, all data is transferred over the single TCP connection, with the header portion indicating the length of the data to follow. HTTP has evolved to allow multiple objects to be passed on a single connection (thereby cutting the connection establishment overhead). Clearly a new file transfer function could be built that would perform most of the functions of FTP without the need for additional TCP connections.
例如，HTTP协议使用头和内容长度方法来传递数据。在这个模型中，所有数据都通过单个TCP连接传输，头部部分指示要遵循的数据长度。HTTP已经发展到允许在单个连接上传递多个对象（从而减少连接建立开销）。显然，可以构建一个新的文件传输功能，它可以执行FTP的大部分功能，而不需要额外的TCP连接。
The goal is to keep to single connections where possible. This keeps us from needing to pass addressing information of any sort across the network. However, multiplexing traffic over a single connection can create problems as well.
目标是尽可能保持单一连接。这使我们不需要通过网络传递任何类型的寻址信息。但是，通过单个连接多路传输流量也会产生问题。
Origination of connections is an important consideration. Where possible, the client should originate all connections. The FTP protocol is the most obvious example, where by default the server opens the data connection to a port on the client (the client having specified the port number via a PORT command over the control TCP session).
连接的起源是一个重要的考虑因素。在可能的情况下，客户端应发起所有连接。FTP协议是最明显的示例，默认情况下，服务器打开到客户端上某个端口的数据连接（客户端通过控制TCP会话上的端口命令指定了端口号）。
As pointed out in [RFC1579], the use of the passive open option in FTP (PASV) remedies this situation as the client is responsible for opening the connection in this case. With client-opened connections, the standard functions of NAPT will process the request as it would any other simple TCP connection, and so an ALG is not required.
正如[RFC1579]中指出的，在FTP（PASV）中使用被动打开选项可以补救这种情况，因为在这种情况下，客户端负责打开连接。对于客户端打开的连接，NAPT的标准函数将像处理任何其他简单TCP连接一样处理请求，因此不需要ALG。
In cases where session bundles are unavoidable, each session in the bundle should originate from the same end station.
在无法避免会话捆绑的情况下，捆绑中的每个会话都应来自同一终端站。
NAPT gateways must track which sessions are alive, and flush old sessions. TCP has clear advantages in this area, since there are specific beginning and end of session indicators in the packets (SYN and FIN packets). While UDP works for some types of applications with NAT, there can be issues when that data is infrequent. Since there is no clean way to know when an end station has finished using a UDP session, NAT implementations use timeouts to guess when a UDP session completes. If an application doesn't send data for a long period of time, the NAT translation may time out.
NAPT网关必须跟踪哪些会话处于活动状态，并刷新旧会话。TCP在这方面具有明显的优势，因为在数据包（SYN和FIN数据包）中有特定的会话开始和结束指示器。虽然UDP适用于具有NAT的某些类型的应用程序，但当数据不频繁时可能会出现问题。由于无法清楚地知道终端站何时完成了UDP会话的使用，NAT实现使用超时来猜测UDP会话何时完成。如果应用程序长时间不发送数据，NAT转换可能会超时。
NAT implementations also use timers to guess when TCP sessions have disappeared. While TCP sessions should disappear only after FIN packets are exchanged, it is possible that such packets may never come, for example if both end stations die. As such, the NAT implementation must use a timer for cleaning up its resources.
NAT实现还使用计时器猜测TCP会话何时消失。虽然TCP会话只有在交换FIN数据包后才会消失，但这样的数据包可能永远不会出现，例如，如果两个终端站都死了。因此，NAT实现必须使用计时器来清理其资源。
NAT implementers in many cases provide several timeouts, one for live TCP sessions, one for TCP sessions on which a FIN has been seen, and one for UDP sessions. It is best when such flexibility is provided, but some implementations appear to apply a single timer to all traffic.
在许多情况下，NAT实现者提供了几个超时，一个用于实时TCP会话，一个用于看到FIN的TCP会话，另一个用于UDP会话。提供这种灵活性是最好的，但有些实现似乎将单个计时器应用于所有流量。
Protocols other than TCP and UDP can work with Traditional NAT in many cases, provided they are not carrying addressing information. For NAPT implementations use of any protocols other than TCP and UDP will be problematic unless or until such protocols are programmed into the implementations.
在许多情况下，TCP和UDP以外的协议可以与传统NAT一起工作，前提是它们不携带寻址信息。对于NAPT实现，使用TCP和UDP以外的任何协议都会有问题，除非或直到这些协议被编程到实现中。
It's important to note that NAPT deployments are based on the assumption of a client-server application model, with the clients in the private realm.
需要注意的是，NAPT部署基于客户机-服务器应用程序模型的假设，客户机位于私有领域。
Applications should attempt to avoid fragmentation when packets pass over NAPT devices. While not always practical or possible, there are failures that can occur with NAPT. Specifically, if two stations in the private realm pick matching fragmentation identifiers, and talk to the same remote host, it may be impossible to determine which fragments belong to which session. A clever NAPT implementation could track fragmentation identifiers and map those into a unique space, though it is not clear how many do so.
当数据包通过NAPT设备时，应用程序应尝试避免碎片。虽然NAPT并不总是可行或可能的，但也可能出现故障。具体来说，如果私有领域中的两个站点选择匹配的碎片标识符，并与同一远程主机通信，则可能无法确定哪些碎片属于哪个会话。一个聪明的NAPT实现可以跟踪碎片标识符，并将它们映射到一个唯一的空间中，尽管不清楚有多少这样做。
Ideally, applications should limit packet size, use Path MTU Discovery or both. Unfortunately, at least some firewall/NAT devices block Path MTU Discovery, apparently believing all ICMP packets are evil.
理想情况下，应用程序应该限制数据包大小，使用路径MTU发现或两者兼而有之。不幸的是，至少有一些防火墙/NAT设备阻止了路径MTU发现，显然认为所有ICMP数据包都是邪恶的。
Some implementations of NAT may implement fragment reassembly prior to Forwarding, however many do not. Application designers are advised to design assuming the devices do not reassemble fragments.
NAT的一些实现可以在转发之前实现片段重组，但是许多实现没有。建议应用程序设计人员假设设备不重新组装片段进行设计。
If only Basic NAT implementations are involved, not NAPT, then many of the issues above do not apply. This is not to say that this form of NAT is better or worse than NAPT. Application designers may think they could just specify users must use Basic NAT, and many application issues would go away. This is unrealistic, however, as many users have no real alternative to NAPT due to the way their providers sell service.
如果只涉及基本的NAT实现，而不涉及NAPT，那么上面的许多问题都不适用。这并不是说这种形式的NAT比NAPT好或坏。应用程序设计者可能认为他们可以指定用户必须使用基本NAT，许多应用程序问题就会消失。然而，这是不现实的，因为由于供应商销售服务的方式，许多用户没有NAPT的真正替代品。
Many of the issues raised earlier still apply to Basic NAT, and many protocols will not function correctly without assistance.
前面提出的许多问题仍然适用于基本NAT，许多协议在没有帮助的情况下无法正常运行。
Applications that use only the information in the IP and TCP or UDP headers for communication (in other words, do not pass any additional addressing information in the payload of the packets), are clearly easier to support in a NAT environment. Where possible, applications designers should try to limit themselves in this area.
在NAT环境中，只使用IP和TCP或UDP报头中的信息进行通信的应用程序（换句话说，不在数据包的有效负载中传递任何额外的寻址信息）显然更容易支持。在可能的情况下，应用程序设计人员应该尽量限制自己在这一领域。
This comes back to the same recommendation made for NAPT, that being to use a single connection whenever possible.
这又回到了为NAPT提出的相同建议，即尽可能使用单个连接。
The X windowing system, for example, uses fixed port numbers to address X servers. With X, the server (display) is addressed via ports 6000 through 6000 + n. These map to hostname:0 through hostname:n server displays. Since only the address and port are used, the NAT administrator could map these ports to one or more private addresses, yielding a functioning solution.
例如，X窗口系统使用固定端口号来寻址X服务器。对于X，服务器（显示器）通过端口6000到6000+n寻址。通过主机名：n服务器显示，这些映射到主机名：0。由于只使用地址和端口，NAT管理员可以将这些端口映射到一个或多个专用地址，从而生成一个正常工作的解决方案。
The X example, in the case of NAPT, requires configuration of the NAT implementation. This results in the ability for no more than one station inside the NAT gateway to use such a protocol. This approach to the problem is thus OK for NAT but not recommended for NAPT environments.
对于NAPT，X示例需要配置NAT实现。这导致NAT网关内只有一个站点能够使用这种协议。因此，这种解决问题的方法适用于NAT，但不推荐用于NAPT环境。
As with NAPT, transporting IP address and/or port number information in the payload is likely to cause trouble. As stated earlier, load balancers and similar platforms may well map the same IP address and port number to a completely different system. Thus it is problematic to assume an address or port number which is valid in the realm on one side of a NAT is valid on the other side.
与NAPT一样，在有效负载中传输IP地址和/或端口号信息可能会导致故障。如前所述，负载平衡器和类似平台很可能将相同的IP地址和端口号映射到完全不同的系统。因此，假设NAT一侧的域中有效的地址或端口号在另一侧有效是有问题的。
Bi-directional NAT makes use of DNS mapping of names to point sessions originating outside the private realm to servers in the private realm. Through use of a DNS-ALG [RFC2694], lookups are performed to find the proper host and packets are sent to that host.
双向NAT利用名称的DNS映射，将源于私有领域之外的点会话映射到私有领域中的服务器。通过使用DNS-ALG[RFC2694]，执行查找以找到合适的主机，并将数据包发送到该主机。
Requirements for applications are the same as for Basic NAT. Addresses are mapped one-to-one to servers. Unlike Traditional NAT devices, Bi-directional NAT devices (in conjunction with DNS-ALG) are amenable to peer-to-peer applications.
应用程序的要求与基本NAT相同。地址被一一映射到服务器。与传统的NAT设备不同，双向NAT设备（结合DNS-ALG）适合于对等应用。
Twice NAT is address translation where both source and destination IP addresses are modified due to addressing conflicts between two private realms. Two bi-directional NAT boxes connected together would essentially perform the same task, though a common address space that is not otherwise used by either private realm would be required.
两次NAT是地址转换，由于两个私有领域之间的地址冲突，源和目标IP地址都会被修改。两个连接在一起的双向NAT盒基本上可以执行相同的任务，不过需要一个公共地址空间，而这两个地址空间都不需要被任何一个私有领域使用。
Requirements for applications to work in the Twice NAT environment are the same as for Basic NAT. Addresses are mapped one to one.
应用程序在两次NAT环境中工作的要求与基本NAT相同。地址被一一映射。
Multi-homed NAT is the use of multiple NAT implementations to provide redundancy. The multiple implementations share configuration information so that sessions might continue in the event of a fail-over. Unless the multiple implementations share the same external addresses, sessions will have to restart regardless.
多宿NAT是使用多个NAT实现来提供冗余。多个实现共享配置信息，以便在发生故障转移时会话可以继续。除非多个实现共享相同的外部地址，否则会话必须重新启动。
Requirements for multi-homed NAT are the same as for Basic NAT or NAPT, depending on how the multi-homed NAT is implemented and configured.
多宿NAT的要求与基本NAT或NAPT的要求相同，具体取决于多宿NAT的实现和配置方式。
Realm Specific IP is described in [RFC2663] and defined in [RSIP] and related documents. Clients within a private realm using RSIP are aware of the delineation between private and public, and access a server to allocate address (and optionally port) information for use in conversing with hosts in the public realm. By doing this, clients create packets that need not be altered by the RSIP server on their way to the remote host. This technique can permit IPSec to function, and potentially makes any application function as if there were no special processing involved at all.
领域特定IP在[RFC2663]中进行了描述，并在[RSIP]和相关文档中进行了定义。使用RSIP的私有领域内的客户机知道私有和公共之间的划分，并访问服务器以分配地址（以及可选的端口）信息，用于与公共领域中的主机进行对话。通过这样做，客户端创建的数据包不需要在发送到远程主机的过程中被RSIP服务器更改。这种技术可以允许IPSec正常工作，并可能使任何应用程序都像根本不需要特殊处理一样工作。
RSIP uses a view of the world in which there are only two realms, the private and public. This isn't always the case. Situations with multiple levels of NAT implementations are growing. For example, some ISPs are handing out [RFC1918] addresses to their dialup users, rather than obtaining real addresses. Any user of such an ISP who also uses a NAT implementation will see two levels of NAT, and the advantages of RSIP will have been wasted.
RSIP使用的世界观只有两个领域，私人和公共。事实并非总是如此。多层次NAT实现的情况正在增加。例如，一些ISP向拨号用户发送[RFC1918]地址，而不是获取真实地址。任何使用NAT实现的ISP用户都会看到两个级别的NAT，而RSIP的优势将被浪费。
Resource utilization on the NAT gateway should be considered. An application that opens and closes many TCP connections, for example, will use up more resources on the NAT router than an application performing all transfers over a single TCP connection. HTTP 1.0 opened a connection for each object on a web page, whereas HTTP 1.1 permits the TCP session to be held open for additional objects that may need to be transferred. Clearly the latter imposes a lower overhead on the NAT gateway, as it is only maintaining state on a single connection instead of multiple connections.
应考虑NAT网关上的资源利用率。例如，打开和关闭多个TCP连接的应用程序将比通过单个TCP连接执行所有传输的应用程序消耗更多NAT路由器上的资源。HTTP 1.0为网页上的每个对象打开了连接，而HTTP 1.1允许TCP会话为可能需要传输的其他对象保持打开状态。显然，后者在NAT网关上施加了较低的开销，因为它只维护单个连接上的状态，而不是多个连接上的状态。
New session establishment will typically remain a software function even in implementations where the packet-by-packet translation work is handled by hardware forwarding engines. While high-performance NAT boxes may be built, protocols that open many sessions instead of multiplexing will be slower than those that do not.
即使在由硬件转发引擎处理逐包翻译工作的实现中，新会话建立通常仍将是软件功能。虽然可以构建高性能的NAT盒，但打开许多会话而不是多路复用的协议将比不打开的协议慢。
Applications with different types of data, such as interactive conferencing, require separate streams for the different types of data. In such cases the protocol needs of each stream must be optimized. While the goal of multiplexing over a single session is preferred, clearly there are cases where this is impractical.
具有不同类型数据的应用程序（如交互式会议）需要为不同类型的数据提供不同的流。在这种情况下，必须优化每个流的协议需求。虽然在单个会话上多路复用的目标是首选的，但显然在某些情况下这是不切实际的。
The latency of NAT translation overhead is implementation dependent. On a per-packet basis, for established sessions only the source or destination IP address is replaced, the source or destination port (for NAPT) and the checksums for IP, and TCP or UDP are recalculated.
NAT转换开销的延迟取决于实现。在每个数据包的基础上，对于已建立的会话，仅替换源或目标IP地址，重新计算源或目标端口（用于NAPT）以及IP、TCP或UDP的校验和。
The functionality can be efficiently implemented in hardware or software.
该功能可以在硬件或软件中有效地实现。
Network Address Translators have implications for IPSec, as noted above. When application developers are considering whether their applications function with NAT implementations, care should be given to selection of security methodology. Transport Layer Security (TLS) [RFC2246] operates across translation boundaries. End-to-end IPSec will prove problematic in many cases.
如上所述，网络地址转换器对IPSec有影响。当应用程序开发人员考虑其应用程序是否使用NAT实现时，应注意选择安全方法。传输层安全（TLS）[RFC2246]跨翻译边界运行。端到端IPSec在许多情况下都会出现问题。
[RFC1579] Bellovin, S., "Firewall Friendly FTP", RFC 1579, February 1994.
[RFC1579]Bellovin，S.，“防火墙友好FTP”，RFC1579，1994年2月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[RFC2246]Dierks，T.和C.Allen，“TLS协议版本1.0”，RFC2246，1999年1月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator (NAT)", RFC 3027, January 2001.
[RFC3027]Holdrege，M.和P.Srisuresh，“IP网络地址转换器（NAT）的协议复杂性”，RFC 3027，2001年1月。
[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月。
[RFC2709] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999.
[RFC2709]Srisuresh，P.，“NAT域的隧道模式IPsec安全模型”，RFC 2709，1999年10月。
[RFC3102] Borella, M., Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RFC3102]Borella，M.，Lo，J.，Grabelsky，D.和G.黑山，“特定领域知识产权：框架”，RFC 3102，2001年10月。
[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月。
[RFC2694] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.
[RFC2694]Srisuresh，P.，Tsirtsis，G.，Akkiraju，P.和A.Heffernan，“网络地址转换器的DNS扩展（DNS_ALG）”，RFC 26941999年9月。
I'd like to thank Pyda Srisuresh for his invaluable input and feedback, and Keith Moore for his extensive comments.
我要感谢Pyda Srisuresh的宝贵意见和反馈，感谢Keith Moore的广泛评论。
Daniel Senie Amaranth Networks Inc. 324 Still River Road Bolton, MA 01740
Daniel Senie Amaranth Networks Inc.马萨诸塞州博尔顿市斯蒂尔河路324号01740
Phone: (978) 779-6813 EMail: dts@senie.com
电话：（978）779-6813电子邮件：dts@senie.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
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编辑功能的资金目前由互联网协会提供。