Network Working Group T. Hain
Request for Comments: 2993 Microsoft
Category: Informational November 2000
Network Working Group T. Hain
Request for Comments: 2993 Microsoft
Category: Informational November 2000
Architectural Implications of NAT
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 (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
Abstract
摘要
In light of the growing interest in, and deployment of network address translation (NAT) RFC-1631, this paper will discuss some of the architectural implications and guidelines for implementations. It is assumed the reader is familiar with the address translation concepts presented in RFC-1631.
鉴于人们对网络地址转换（NAT）RFC-1631越来越感兴趣，本文将讨论一些架构含义和实现指南。假设读者熟悉RFC-1631中提出的地址转换概念。
Table of Contents
目录
1. Introduction................................................... 2
2. Terminology.................................................... 4
3. Scope.......................................................... 6
4. End-to-End Model............................................... 7
5. Advantages of NATs............................................. 8
6. Problems with NATs............................................ 10
7. Illustrations................................................. 13
7.1 Single point of failure...................................... 13
7.2. ALG complexity............................................. 14
7.3. TCP state violations........................................ 15
7.4. Symmetric state management................................. 16
7.5. Need for a globally unique FQDN when advertising public
services................................................... 18
7.6. L2TP tunnels increase frequency of address collisions...... 19
7.7. Centralized data collection system report correlation...... 20
8. IPv6.......................................................... 21
9. Security Considerations....................................... 22
10. Deployment Guidelines........................................ 23
11. Summary...................................................... 24
12. References................................................... 27
1. Introduction................................................... 2
2. Terminology.................................................... 4
3. Scope.......................................................... 6
4. End-to-End Model............................................... 7
5. Advantages of NATs............................................. 8
6. Problems with NATs............................................ 10
7. Illustrations................................................. 13
7.1 Single point of failure...................................... 13
7.2. ALG complexity............................................. 14
7.3. TCP state violations........................................ 15
7.4. Symmetric state management................................. 16
7.5. Need for a globally unique FQDN when advertising public
services................................................... 18
7.6. L2TP tunnels increase frequency of address collisions...... 19
7.7. Centralized data collection system report correlation...... 20
8. IPv6.......................................................... 21
9. Security Considerations....................................... 22
10. Deployment Guidelines........................................ 23
11. Summary...................................................... 24
12. References................................................... 27
13. Acknowledgments.............................................. 28
14. Author's Address............................................. 28
15. Full Copyright Statement..................................... 29
13. Acknowledgments.............................................. 28
14. Author's Address............................................. 28
15. Full Copyright Statement..................................... 29
Published in May 1994, written by K. Egevang and P. Francis, RFC-1631 [2] defined NAT as one means to ease the growth rate of IPv4 address use. But the authors were worried about the impact of this technology. Several places in the document they pointed out the need to experiment and see what applications may be adversely affected by NAT's header manipulations, even before there was any significant operational experience. This is further evidenced in a quote from the conclusions: 'NAT has several negative characteristics that make it inappropriate as a long term solution, and may make it inappropriate even as a short term solution.'
RFC-1631[2]于1994年5月发表，由K.Egevang和P.Francis撰写，将NAT定义为缓解IPv4地址使用增长率的一种手段。但作者担心这项技术的影响。在文件中的几个地方，他们指出需要进行实验，看看哪些应用程序可能会受到NAT标头操作的不利影响，甚至在有任何重要的操作经验之前。结论中引用的一句话进一步证明了这一点：“NAT有几个负面特征，使其不适合作为长期解决方案，甚至可能使其不适合作为短期解决方案。”
Now, six years later and in spite of the prediction, the use of NATs is becoming widespread in the Internet. Some people are proclaiming NAT as both the short and long term solution to some of the Internet's address availability issues and questioning the need to continue the development of IPv6. The claim is sometimes made that NAT 'just works' with no serious effects except on a few legacy applications. At the same time others see a myriad of difficulties caused by the increasing use of NAT.
六年后的今天，尽管有这样的预测，NAT的使用在互联网上变得越来越普遍。一些人宣称NAT是解决某些互联网可用性问题的短期和长期解决方案，并质疑继续发展IPv6的必要性。有时有人声称NAT“只起作用”，除了少数遗留应用程序外，不会产生严重影响。同时，其他人也看到了NAT使用的增加所带来的种种困难。
The arguments pro & con frequently take on religious tones, with each side passionate about its position.
赞成和反对的争论经常带有宗教色彩，双方都对自己的立场充满激情。
- Proponents bring enthusiasm and frequently cite the most popular applications of Mail & Web services as shining examples of NAT transparency. They will also point out that NAT is the feature that finally breaks the semantic overload of the IP address as both a locator and the global endpoint identifier (EID). - An opposing view of NAT is that of a malicious technology, a weed which is destined to choke out continued Internet development. While recognizing there are perceived address shortages, the opponents of NAT view it as operationally inadequate at best, bordering on a sham as an Internet access solution. Reality lies somewhere in between these extreme viewpoints.
- 支持者们带来了热情，并经常引用最流行的邮件和Web服务应用程序作为NAT透明度的光辉例子。他们还将指出，NAT是最终打破IP地址作为定位器和全局端点标识符（EID）的语义过载的功能另一种反对NAT的观点认为NAT是一种恶意技术，它注定会扼杀互联网的持续发展。虽然认识到存在明显的地址短缺，但NAT的反对者认为它充其量在操作上是不充分的，近乎于一种虚假的互联网接入解决方案。现实就在这些极端观点之间。
In any case it is clear NAT affects the transparency of end-to-end connectivity for transports relying on consistency of the IP header, and for protocols which carry that address information in places other than the IP header. Using a patchwork of consistently configured application specific gateways (ALG's), endpoints can work around some of the operational challenges of NAT. These operational challenges vary based on a number of factors including network and
在任何情况下，NAT都会影响依赖于IP报头一致性的传输的端到端连接的透明度，以及在IP报头以外的位置承载该地址信息的协议的透明度。通过使用一致配置的特定于应用程序的网关（ALG）的补丁，端点可以解决NAT的一些操作难题。这些运营挑战因许多因素而有所不同，包括网络和
application topologies and the specific applications in use. It can be relatively easy to deal with the simplest case, with traffic between two endpoints running over an intervening network with no parallel redundant NAT devices. But things can quickly get quite complicated when there are parallel redundant NAT devices, or where there are more distributed and multi-point applications like multi-party document sharing. The complexity of coordinating the updates necessary to work around NAT grows geometrically with the number of endpoints. In a large environment, this may require concerted effort to simultaneously update all endpoints of a given application or service.
应用程序拓扑和正在使用的特定应用程序。处理最简单的情况相对容易，两个端点之间的通信量在没有并行冗余NAT设备的干预网络上运行。但是，如果存在并行冗余NAT设备，或者存在更多分布式和多点应用程序（如多方文档共享），事情会很快变得非常复杂。协调NAT所需的更新的复杂性随着端点的数量呈几何级数增长。在大型环境中，这可能需要协同工作来同时更新给定应用程序或服务的所有端点。
The architectural intent of NAT is to divide the Internet into independent address administrations, (also see "address realms", RFC-2663 [3]) specifically facilitating casual use of private address assignments RFC-1918 [4]. As noted by Carpenter, et al RFC-2101 [5], once private use addresses were deployed in the network, addresses were guaranteed to be ambiguous. For example, when simple NATs are inserted into the network, the process of resolving names to or from addresses becomes dependent on where the question was asked. The result of this division is to enforce a client/server architecture (vs. peer/peer) where the servers need to exist in the public address realm.
NAT的体系结构意图是将互联网划分为独立的地址管理（另请参见“地址领域”，RFC-2663[3]），特别是方便随意使用专用地址分配RFC-1918[4]。正如Carpenter等人RFC-2101[5]所指出的，一旦在网络中部署了专用地址，地址就保证是不明确的。例如，当将简单的NAT插入网络时，将名称解析到地址或从地址解析名称的过程取决于问题的提出位置。这种划分的结果是实施一种客户机/服务器体系结构（与对等机/对等机相比），其中服务器需要存在于公共广播领域中。
A significant factor in the success of the Internet is the flexibility derived from a few basic tenets. Foremost is the End-to-End principle (discussed further below), which notes that certain functions can only be performed in the endpoints, thus they are in control of the communication, and the network should be a simple datagram service that moves bits between these points. Restated, the endpoint applications are often the only place capable of correctly managing the data stream. Removing this concern from the lower layer packet-forwarding devices streamlines the forwarding process, contributing to system-wide efficiency.
互联网成功的一个重要因素是源自一些基本原则的灵活性。最重要的是端到端原则（下文将进一步讨论），它指出某些功能只能在端点中执行，因此它们控制着通信，网络应该是一个简单的数据报服务，在这些点之间移动位。重申一下，端点应用程序通常是唯一能够正确管理数据流的地方。从较低层分组转发设备中消除此问题可简化转发过程，有助于提高系统范围的效率。
Another advantage is that the network does not maintain per connection state information. This allows fast rerouting around failures through alternate paths and to better scaling of the overall network. Lack of state also removes any requirement for the network nodes to notify each other as endpoint connections are formed or dropped. Furthermore, the endpoints are not, and need not be, aware of any network components other than the destination, first hop router(s), and an optional name resolution service. Packet integrity is preserved through the network, and transport checksums and any address-dependent security functions are valid end-to-end.
另一个优点是网络不维护每个连接的状态信息。这允许通过备用路径围绕故障快速重新路由，并更好地扩展整个网络。缺少状态也消除了在端点连接形成或断开时网络节点相互通知的任何要求。此外，端点不知道也不需要知道除目的地、第一跳路由器和可选名称解析服务之外的任何网络组件。数据包的完整性通过网络得以保持，传输校验和和和任何地址相关的安全功能都是端到端有效的。
NAT devices (particularly the NAPT variety) undermine most of these, basic advantages of the end-to-end model, reducing overall flexibility, while often increasing operational complexity and impeding diagnostic capabilities. NAT variants such as RSIP [6] have recently been proposed to address some of the end-to-end concerns. While these proposals may be effective at providing the private node with a public address (if ports are available), they do not eliminate several issues like network state management, upper layer constraints like TCP_TIME_WAIT state, or well-known-port sharing. Their port multiplexing variants also have the same DNS limitations as NAPT, and each host requires significant stack modifications to enable the technology (see below).
NAT设备（尤其是NAPT设备）破坏了端到端模型的大部分基本优势，降低了总体灵活性，同时往往增加了操作复杂性，阻碍了诊断能力。诸如RSIP[6]等NAT变体最近被提出用于解决一些端到端问题。虽然这些方案在为私有节点提供公共地址（如果端口可用）方面可能是有效的，但它们并不能消除网络状态管理、上层约束（如TCP_TIME_WAIT state）或众所周知的端口共享等问题。它们的端口多路复用变体也具有与NAPT相同的DNS限制，并且每个主机都需要对堆栈进行重大修改以启用该技术（见下文）。
It must be noted that firewalls also break the end-to-end model and raise several of the same issues that NAT devises do, while adding a few of their own. But one operational advantage with firewalls is that they are generally installed into networks with the explicit intent to interfere with traffic flow, so the issues are more likely to be understood or at least looked at if mysterious problems arise. The same issues with NAT devices can sometimes be overlooked since NAT devices are frequently presented as transparent to applications.
必须注意的是，防火墙也打破了端到端的模式，并提出了一些与NAT设计相同的问题，同时增加了一些自己的问题。但防火墙的一个操作优势是，它们通常安装在网络中，明确意图干扰交通流，因此，如果出现神秘问题，这些问题更容易被理解或至少被观察。NAT设备的同样问题有时也会被忽略，因为NAT设备通常对应用程序是透明的。
One thing that should be clearly stated up front is, that attempts to use a variant of NAT as a simple router replacement may create several significant issues that should be addressed before deployment. The goal of this document is to discuss these with the intent to raise awareness.
有一件事需要事先明确说明，尝试使用NAT的变体作为简单的路由器替换可能会产生一些重要问题，这些问题应该在部署之前解决。本文件旨在讨论这些问题，以提高认识。
Recognizing that many of these terms are defined in detail in RFC 2663 [3], the following are summaries as used in this document.
鉴于RFC 2663[3]中对其中许多术语进行了详细定义，以下是本文件中使用的总结。
NAT - Network Address Translation in simple form is a method by which IP addresses are mapped from one address administration to another. The NAT function is unaware of the applications traversing it, as it only looks at the IP headers.
NAT-简单形式的网络地址转换是一种将IP地址从一个地址管理映射到另一个地址管理的方法。NAT函数不知道应用程序正在遍历它，因为它只查看IP头。
ALG - Application Layer Gateway: inserted between application peers to simulate a direct connection when some intervening protocol or device prevents direct access. It terminates the transport protocol, and may modify the data stream before forwarding.
ALG-应用层网关：在应用程序对等点之间插入，以模拟在某些干预协议或设备阻止直接访问时的直接连接。它终止传输协议，并且可以在转发之前修改数据流。
NAT/ALG - combines ALG functions with simple NAT. Generally more useful than pure NAT, because it embeds components for specific applications that would not work through a pure NAT.
NAT/ALG-将ALG函数与简单NAT结合起来。通常比纯NAT更有用，因为它为特定应用程序嵌入了无法通过纯NAT工作的组件。
DNS/ALG - a special case of the NAT/ALG, where an ALG for the DNS service interacts with the NAT component to modify the contents of a DNS response.
DNS/ALG—NAT/ALG的特例，其中DNS服务的ALG与NAT组件交互以修改DNS响应的内容。
Firewall - access control point that may be a special case of an ALG, or packet filter.
防火墙-访问控制点，可能是ALG或数据包过滤器的特例。
Proxy - A relay service designed into a protocol, rather than arbitrarily inserted. Unlike an ALG, the application on at least one end must be aware of the proxy.
代理-设计成协议的中继服务，而不是任意插入。与ALG不同，至少一端的应用程序必须知道代理。
Static NAT - provides stable one-to-one mapping between address spaces.
静态NAT-在地址空间之间提供稳定的一对一映射。
Dynamic NAT - provides dynamic mapping between address spaces normally used with a relatively large number of addresses on one side (private space) to a few addresses on the other (public space).
动态NAT-提供地址空间之间的动态映射，通常使用的地址空间一侧（专用空间）相对较多的地址，另一侧（公共空间）则有几个地址。
NAPT - Network Address Port Translation accomplishes translation by multiplexing transport level identifiers of multiple addresses from one side, simultaneously into the transport identifiers of a single address on the other. See 4.1.2 of RFC-2663. This permits multiple endpoints to share and appear as a single IP address.
NAPT-网络地址端口转换通过将多个地址的传输级别标识符从一端复用到另一端的单个地址的传输标识符来完成转换。见RFC-2663的4.1.2。这允许多个端点共享并显示为单个IP地址。
RSIP - Realm Specific IP allows endpoints to acquire and use the public address and port number at the source. It includes mechanisms for the private node to request multiple resources at once. RSIP clients must be aware of the address administration boundaries, which specific administrative area its peer resides in for each application, and the topology for reaching the peer. To complete a connection, the private node client requests one or more addresses and/or ports from the appropriate RSIP server, then initiates a connection via that RSIP server using the acquired public resources. Hosts must be updated with specific RSIP software to support the tunneling functions.
RSIP-领域特定IP允许端点获取并使用源位置的公共地址和端口号。它包括私有节点一次请求多个资源的机制。RSIP客户端必须知道地址管理边界、每个应用程序的对等方所在的特定管理区域以及到达对等方的拓扑。为了完成连接，专用节点客户端从相应的RSIP服务器请求一个或多个地址和/或端口，然后使用获取的公共资源通过该RSIP服务器启动连接。必须使用特定的RSIP软件更新主机，以支持隧道功能。
VPN - For purposes of this document, Virtual Private Networks technically treat an IP infrastructure as a multiplexing substrate, allowing the endpoints to build virtual transit pathways, over which they run another instance of IP. Frequently the 2nd instance of IP uses a different set of IP addresses.
VPN——在本文档中，虚拟专用网络在技术上将IP基础设施视为多路复用基板，允许端点构建虚拟传输路径，并在该路径上运行另一个IP实例。第二个IP实例通常使用不同的IP地址集。
AH - IP Authentication Header, RFC-2401 [7], which provides data integrity, data origin authentication, and an optional anti-replay service.
AH-IP身份验证头，RFC-2401[7]，提供数据完整性、数据源身份验证和可选的反重放服务。
ESP - Encapsulating Security Payload protocol, RFC 2401, may provide data confidentiality (encryption), and limited traffic flow confidentiality. It also may provide data integrity, data origin authentication, and an anti-replay service.
ESP封装安全有效负载协议RFC 2401可提供数据机密性（加密）和有限的流量机密性。它还可以提供数据完整性、数据源身份验证和反重播服务。
Address administration - coordinator of an address pool assigned to a collection of routers and end systems.
地址管理-分配给路由器和终端系统集合的地址池的协调器。
Addressing realm - a collection of routers and end systems exchanging locally unique location knowledge. (Further defined in RFC-2663 NAT Terminology.) NAT is used a means to distribute address allocation authority and provide a mechanism to map addresses from one address administration into those of another administration.
寻址域-交换本地唯一位置知识的路由器和终端系统的集合。（在RFC-2663 NAT术语中进一步定义。）NAT用于分配地址分配权限，并提供一种机制，将地址从一个地址管理映射到另一个地址管理。
In discussing the architectural impact of NATs on the Internet, the first task is defining the scope of the Internet. The most basic definition is; a concatenation of networks built using IETF defined technologies. This simple description does not distinguish between the public network known as the Internet, and the private networks built using the same technologies (including those connected via NAT). Rekhter, et al in RFC-1918 defined hosts as public when they need network layer access outside the enterprise, using a globally unambiguous address. Those that need limited or no access are defined as private. Another way to view this is in terms of the transparency of the connection between any given node and the rest of the Internet.
在讨论NAT对Internet架构的影响时，第一项任务是定义Internet的范围。最基本的定义是；使用IETF定义的技术构建的网络连接。这个简单的描述并没有区分称为Internet的公共网络和使用相同技术构建的专用网络（包括通过NAT连接的网络）。Rekhter等人在RFC-1918中将主机定义为公共主机，当它们需要在企业外部使用一个全局明确的地址进行网络层访问时。那些需要有限或不需要访问的被定义为私有。另一种看法是，任何给定节点与Internet其余部分之间的连接是否透明。
The ultimate resolution of public or private is found in the intent of the network in question. Generally, networks that do not intend to be part of the greater Internet will use some screening technology to insert a barrier. Historically barrier devices between the public and private networks were known as Firewalls or Application Gateways, and were managed to allow approved traffic while blocking everything else. Increasingly, part of the screening technology is a NAT, which manages the network locator between the public and private-use address spaces, and then, using ALGs adds support for protocols that are incompatible with NAT. (Use of NAT within a private network is possible, and is only addressed here in the context that some component of the private network is used as a common transit service between the NAT attached stubs.)
公共或私人的最终解决方案是在相关网络的意图中找到的。一般来说，不打算成为更大互联网一部分的网络将使用一些筛选技术来插入屏障。历史上，公共和私有网络之间的屏障设备被称为防火墙或应用程序网关，并被管理为允许批准的流量，同时阻止其他一切。越来越多的屏蔽技术是NAT，它管理公用和专用地址空间之间的网络定位器，然后使用ALG增加对与NAT不兼容的协议的支持。（在专用网络中使用NAT是可能的，并且仅在专用网络的某些组件用作NAT连接存根之间的公共传输服务的上下文中讨论。）
RFC-1631 limited the scope of NAT discussions to stub appendages of a public Internet, that is, networks with a single connection to the rest of the Internet. The use of NAT in situations in which a network has multiple connections to the rest of the Internet is significantly more complex than when there is only a single
RFC-1631将NAT讨论的范围限制在公共互联网的存根附件上，即只与互联网其余部分连接的网络。在一个网络与互联网其余部分有多个连接的情况下，使用NAT要比只有一个连接的情况复杂得多
connection since the NATs have to be coordinated to ensure that they have a consistent understanding of address mapping for each individual device.
连接，因为NAT必须协调，以确保它们对每个单独设备的地址映射有一致的理解。
The concept of the End-to-End model is reviewed by Carpenter in Internet Transparency [8]. One of the key points is "state should be maintained only in the endpoints, in such a way that the state can only be destroyed when the endpoint itself breaks"; this is termed "fate-sharing". The goal behind fate-sharing is to ensure robustness. As networks grow in size, likelihood of component failures affecting a connection becomes increasingly frequent. If failures lead to loss of communication, because key state is lost, then the network becomes increasingly brittle, and its utility degrades. However, if an endpoint itself fails, then there is no hope of subsequent communication anyway. Therefore the End-to-End model argues that as much as possible, only the endpoints should hold critical state.
Carpenter在《互联网透明度》中对端到端模型的概念进行了审查[8]。其中一个关键点是“状态应仅在端点中保持，这样，只有当端点本身断开时，状态才能被破坏”；这被称为“命运分享”。命运分享背后的目标是确保稳健性。随着网络规模的增长，影响连接的组件故障的可能性变得越来越频繁。如果故障导致通信中断，因为密钥状态丢失，那么网络就会变得越来越脆弱，其效用也会下降。但是，如果端点本身失败，那么无论如何都不可能进行后续通信。因此，端到端模型认为，尽可能只有端点应保持临界状态。
For NATs, this aspect of the End-to-End model translates into the NAT becoming a critical infrastructure element: if it fails, all communication through it fails, and, unless great care is taken to assure consistent, stable storage of its state, even when it recovers the communication that was passing through it will still fail (because the NAT no longer translates it using the same mappings). Note that this latter type of failure is more severe than the failure of a router; when a router recovers, any communication that it had been forwarding previous can continue to be successfully forwarded through it.
对于NAT，端到端模型的这一方面转化为NAT成为一个关键的基础设施元素：如果NAT发生故障，通过它进行的所有通信都会失败，并且，除非非常小心地确保其状态的一致、稳定存储，即使当它恢复通过它的通信时，仍然会失败（因为NAT不再使用相同的映射对其进行转换）。请注意，后一种类型的故障比路由器的故障更严重；当路由器恢复时，它先前转发的任何通信都可以继续通过它成功转发。
There are other important facets to the End-to-End model:
端到端模型还有其他重要方面：
- when state is held in the interior of the network, then traffic dependent on that state cannot be routed around failures unless somehow the state is replicated to the fail-over points, which can be very difficult to do in a consistent yet efficient and timely fashion. - a key principle for scaling networks to large size is to push state-holding out to the edges of the network. If state is held by elements in the core of the network, then as the network grows the amount of state the elements must holds likewise grows. The capacities of the elements can become severe chokepoints and the number of connections affected by a failure also grows. - if security state must be held inside the network (see the discussion below), then the possible trust models the network can support become restricted.
- 当状态保持在网络内部时，依赖于该状态的流量不能在故障周围路由，除非以某种方式将状态复制到故障转移点，这可能很难以一致但高效且及时的方式完成。-将网络扩展到大尺寸的一个关键原则是将状态保持到网络的边缘。如果状态由网络核心中的元素持有，那么随着网络的增长，元素必须持有的状态量也随之增长。元件的容量可能成为严重的阻塞点，受故障影响的连接数量也会增加。-如果必须在网络内部保持安全状态（请参阅下面的讨论），则网络可以支持的可能信任模型将受到限制。
A network for which endpoints need not trust network service providers has a great deal more security flexibility than one which does. (Picture, for example, a business traveler connecting from their hotel room back to their home office: should they have to trust the hotel's networking staff with their security keys?, or the staff of the ISP that supplies the hotel with its networking service? How about when the traveler connects over a wireless connection at an airport?)
端点不需要信任网络服务提供商的网络比信任网络服务提供商的网络具有更大的安全灵活性。（例如，想象一个商务旅行者从酒店房间连接回他们的总公司：他们应该信任酒店的网络工作人员和他们的安全密钥吗？还是应该信任为酒店提供网络服务的ISP的工作人员？当旅行者在机场通过无线连接时如何？）
Related to this, RFC-2101 notes: Since IP Security authentication headers assume that the addresses in the network header are preserved end-to-end, it is not clear how one could support IP Security-based authentication between a pair of hosts communicating through either an ALG or a NAT.
与此相关，RFC-2101注意到：由于IP安全认证头假定网络头中的地址是端到端保留的，因此不清楚如何支持通过ALG或NAT通信的一对主机之间基于IP安全的认证。
In addition, there are distributed applications that assume that IP addresses are globally scoped, globally routable, and all hosts and applications have the same view of those addresses. Indeed, a standard technique for such applications to manage their additional control and data connections is for one host to send to another the address and port that the second host should connect to. NATs break these applications. Similarly, there are other applications that assume that all upper layer ports from a given IP address map to the same endpoint, and port multiplexing technologies like NAPT and RSIP break these. For example, a web server may desire to associate a connection to port 80 with one to port 443, but due to the possible presence of a NATPT, the same IP address no longer ensures the same host.
此外，还有一些分布式应用程序假定IP地址是全局范围的、全局可路由的，并且所有主机和应用程序都具有相同的地址视图。实际上，此类应用程序管理其附加控制和数据连接的标准技术是，一台主机向另一台主机发送第二台主机应连接的地址和端口。NAT破坏了这些应用程序。类似地，还有其他应用程序假定给定IP地址的所有上层端口映射到同一端点，而端口复用技术（如NAPT和RSIP）则会破坏这些应用程序。例如，web服务器可能希望将到端口80的连接与到端口443的连接相关联，但是由于可能存在NATPT，相同的IP地址不再确保相同的主机。
Limiting such applications is not a minor issue: much of the success of the Internet today is due to the ease with which new applications can run on endpoints without first requiring upgrades to infrastructure elements. If new applications must have the NATs upgraded in order to achieve widespread deployment, then rapid deployment is hindered, and the pace of innovation slowed.
限制这类应用程序不是一个小问题：当今互联网的成功很大程度上是由于新应用程序可以轻松地在端点上运行，而无需首先升级基础设施元素。如果新应用程序必须升级NAT才能实现广泛部署，那么快速部署就会受到阻碍，创新的步伐也会放缓。
A quick look at the popularity of NAT as a technology shows that it tackles several real world problems when used at the border of a stub domain.
快速回顾一下NAT作为一种技术的流行情况，可以发现它在存根域边界使用时解决了几个实际问题。
- By masking the address changes that take place, from either dial-access or provider changes, minimizes impact on the local network by avoiding renumbering. - Globally routable addresses can be reused for intermittent access customers. This pushes the demand for addresses towards the number of active nodes rather than the total number of nodes.
- 通过屏蔽发生的地址更改（来自拨号访问或提供商更改），通过避免重新编号，将对本地网络的影响降至最低。-全局可路由地址可重复用于间歇访问客户。这将地址需求推向活动节点的数量，而不是节点的总数。
- There is a potential that ISP provided and managed NATs would lower support burden since there could be a consistent, simple device with a known configuration at the customer end of an access interface. - Breaking the Internet into a collection of address authorities limits the need for continual justification of allocations allows network managers to avoid the use of more advanced routing techniques such as variable length subnets. - Changes in the hosts may not be necessary for applications that don't rely on the integrity of the packet header, or carry IP addresses in the payload. - Like packet filtering Firewalls, NAPT, & RSIP block inbound connections to all ports until they are administratively mapped.
- ISP提供和管理的NAT有可能降低支持负担，因为在访问接口的客户端可能有一个具有已知配置的一致、简单的设备。-将Internet划分为一组地址权限限制了对分配的持续合理性的需要，从而使网络管理员能够避免使用更先进的路由技术，如可变长度子网。-对于不依赖数据包报头完整性或负载中携带IP地址的应用程序，可能不需要更改主机。-与包过滤防火墙一样，NAPT和RSIP阻止所有端口的入站连接，直到它们被管理映射。
Taken together these explain some of the strong motivations for moving quickly with NAT deployment. Traditional NAT [2] provides a relatively simple function that is easily understood.
综上所述，这些因素解释了快速部署NAT的一些强烈动机。传统的NAT[2]提供了一个相对简单、易于理解的功能。
Removing hosts that are not currently active lowers address demands on the public Internet. In cases where providers would otherwise end up with address allocations that could not be aggregated, this improves the load on the routing system as well as lengthens the lifetime of the IPv4 address space. While reclaiming idle addresses is a natural byproduct of the existing dynamic allocation, dial-access devices, in the dedicated connection case this service could be provided through a NAT. In the case of a NAPT, the aggregation potential is even greater as multiple end systems share a single public address.
删除当前未处于活动状态的主机可以降低公共Internet上的地址需求。如果提供程序最终无法聚合地址分配，则这将提高路由系统上的负载，并延长IPv4地址空间的生存期。虽然回收空闲地址是现有动态分配、拨号访问设备的自然副产品，但在专用连接情况下，此服务可以通过NAT提供。在NAPT的情况下，由于多个终端系统共享一个公共广播，聚合潜力更大。
By reducing the potential customer connection options and minimizing the support matrix, it is possible that ISP provided NATs would lower support costs.
通过减少潜在的客户连接选项和最小化支持矩阵，ISP提供的NAT可能会降低支持成本。
Part of the motivation for NAT is to avoid the high cost of renumbering inherent in the current IPv4 Internet. Guidelines for the assignment of IPv4 addresses RFC-2050 [9] mean that ISP customers are currently required to renumber their networks if they want to switch to a new ISP. Using a NAT (or a firewall with NAT functions) means that only the Internet facing IP addresses must be changed and internal network nodes do not need to be reconfigured. Localizing address administration to the NAT minimizes renumbering costs, and simultaneously provides for a much larger local pool of addresses than is available under current allocation guidelines. (The registry guidelines are intended to prolong the lifetime of the IPv4 address space and manage routing table growth, until IPv6 is ready or new routing technology reduces the pressure on the routing table. This is accomplished by managing allocations to match actual demand and to enforce hierarchical addressing. An unfortunate byproduct of the
NAT的部分动机是避免当前IPv4互联网固有的重新编号的高成本。IPv4地址分配指南RFC-2050[9]意味着，如果ISP客户想要切换到新的ISP，他们当前需要重新编号其网络。使用NAT（或具有NAT功能的防火墙）意味着只需更改面向Internet的IP地址，而无需重新配置内部网络节点。将地址管理本地化到NAT可以最大限度地降低重新编号的成本，同时提供比当前分配准则下更大的本地地址池。（注册表指南旨在延长IPv4地址空间的生存期并管理路由表的增长，直到IPv6就绪或新的路由技术减轻了路由表的压力。这是通过管理分配来实现的，以匹配实际需求并强制实施分层寻址。这是
current guidelines is that they may end up hampering growth in areas where it is difficult to sort out real need from potential hoarding.) NAT is effective at masking provider switching or other requirements to change addresses, thus mitigates some of the growth issues.
当前的指导方针是，它们最终可能会阻碍那些难以从潜在囤积中分辨出实际需求的地区的增长。）NAT有效地屏蔽了提供商切换或其他更改地址的要求，从而缓解了一些增长问题。
NAT deployments have been raising the awareness of protocol designers who are interested in ensuring that their protocols work end-to-end. Breaking the semantic overload of the IP address will force applications to find a more appropriate mechanism for endpoint identification and discourage carrying the locator in the data stream. Since this will not work for legacy applications, RFC-1631 discusses how to look into the packet and make NAT transparent to the application (i.e.: create an application gateway). This may not be possible for all applications (such as IP based authentication in SNMP), and even with application gateways in the path it may be necessary to modify each end host to be aware when there are intermediaries modifying the data.
NAT部署提高了协议设计者的意识，他们对确保协议端到端工作感兴趣。打破IP地址的语义过载将迫使应用程序找到更合适的端点识别机制，并阻止在数据流中携带定位器。由于这不适用于遗留应用程序，RFC-1631讨论了如何查看数据包并使NAT对应用程序透明（即：创建应用程序网关）。这可能不可能适用于所有应用程序（例如SNMP中基于IP的身份验证），即使路径中有应用程序网关，也可能需要修改每个终端主机，以便在有中介修改数据时知道。
Another popular practice is hiding a collection of hosts that provide a combined service behind a single IP address (i.e.: web host load sharing). In many implementations this is architecturally a NAT, since the addresses are mapped to the real destination on the fly. When packet header integrity is not an issue, this type of virtual host requires no modifications to the remote applications since the end client is unaware of the mapping activity. While the virtual host has the CPU performance characteristics of the total set of machines, the processing and I/O capabilities of the NAT/ALG device bound the overall performance as it funnels the packets back and forth.
另一种流行做法是将提供组合服务的主机集合隐藏在单个IP地址后面（即web主机负载共享）。在许多实现中，这在体系结构上是一个NAT，因为地址是动态映射到实际目的地的。当包头完整性不是问题时，这种类型的虚拟主机不需要修改远程应用程序，因为终端客户端不知道映射活动。虽然虚拟主机具有整套机器的CPU性能特征，但NAT/ALG设备的处理和I/O能力在来回传输数据包时限制了总体性能。
- NATs break the flexible end-to-end model of the Internet. - NATs create a single point where fates are shared, in the device maintaining connection state and dynamic mapping information. - NATs complicate the use of multi-homing by a site in order to increase the reliability of their Internet connectivity. (While single routers are a point of fate sharing, the lack of state in a router makes creating redundancy trivial. Indeed, this is on of the reasons why the Internet protocol suite developed using a connectionless datagram service as its network layer.) - NATs inhibit implementation of security at the IP level. - NATs enable casual use of private addresses. These uncoordinated addresses are subject to collisions when companies using these addresses merge or want to directly interconnect using VPNs. - NATs facilitate concatenating existing private name spaces with the public DNS.
- NAT打破了互联网灵活的端到端模式NAT在维护连接状态和动态映射信息的设备中创建一个共享命运的单点。-NAT使站点使用多主服务变得复杂，以提高其Internet连接的可靠性。（虽然单个路由器是命运共享点，但路由器中缺少状态使得创建冗余变得微不足道。事实上，这是使用无连接数据报服务作为其网络层开发Internet协议套件的原因之一。）-NAT禁止在IP级别实现安全性。-NAT允许随意使用私有地址。当使用这些地址的公司合并或希望使用VPN直接互连时，这些不协调的地址会发生冲突。-NAT有助于将现有的私有名称空间和公共DNS连接起来。
- Port versions (NAPT and RSIP) increase operational complexity when publicly published services reside on the private side. - NATs complicated or may even invalidate the authentication mechanism of SNMPv3. - Products may embed a NAT function without identifying it as such.
- 当公开发布的服务驻留在私有端时，端口版本（NAPT和RSIP）增加了操作复杂性。-NAT使SNMPv3的身份验证机制变得复杂甚至失效。-产品可能嵌入NAT功能，而无需将其标识为NAT功能。
By design, NATs impose limitations on flexibility. As such, extended thought about the introduced complications is called for. This is especially true for products where the NAT function is a hidden service, such as load balancing routers that re-write the IP address to other public addresses. Since the addresses may be all in publicly administered space these are rarely recognized as NATs, but they break the integrity of the end-to-end model just the same.
根据设计，NAT限制了灵活性。因此，需要对引入的并发症进行深入思考。对于NAT功能是隐藏服务的产品尤其如此，例如将IP地址重新写入其他公共地址的负载平衡路由器。由于地址可能都在公共管理的空间中，因此很少被识别为NAT，但它们同样破坏了端到端模型的完整性。
NATs place constraints on the deployment of applications that carry IP addresses (or address derivatives) in the data stream, and they operate on the assumption that each session is independent. However, there are applications such as FTP and H.323 that use one or more control sessions to set the characteristics of the follow-on sessions in their control session payload. Other examples include SNMP MIBs for configuration, and COPS policy messages. Applications or protocols like these assume end-to-end integrity of addresses and will fail when traversing a NAT. (TCP was specifically designed to take advantage of, and reuse, the IP address in combination with its ports for use as a transport address.) To fix how NATs break such applications, an Application Level Gateway needs to exist within or alongside each NAT. An additional gateway service is necessary for each application that may imbed an address in the data stream. The NAT may also need to assemble fragmented datagrams to enable translation of the application stream, and then adjust TCP sequence numbers, prior to forwarding.
NAT对在数据流中携带IP地址（或地址衍生物）的应用程序的部署施加了限制，并且它们在假设每个会话都是独立的情况下运行。然而，有些应用程序（如FTP和H.323）使用一个或多个控制会话在其控制会话有效负载中设置后续会话的特征。其他示例包括用于配置的SNMP MIB和COPS策略消息。像这样的应用程序或协议假定地址的端到端完整性，并且在穿越NAT时将失败。（TCP专门设计用于利用和重用IP地址及其端口，以用作传输地址。）要解决NAT如何破坏此类应用程序，应用程序级网关需要存在于每个NAT内或旁边。对于可能在数据流中嵌入地址的每个应用程序，都需要额外的网关服务。NAT可能还需要组装碎片数据报，以支持应用程序流的转换，然后在转发之前调整TCP序列号。
As noted earlier, NATs break the basic tenet of the Internet that the endpoints are in control of the communication. The original design put state control in the endpoints so there would be no other inherent points of failure. Moving the state from the endpoints to specific nodes in the network reduces flexibility, while it increases the impact of a single point failure. See further discussion in Illustration 1 below.
如前所述，NAT打破了互联网的基本原则，即端点控制通信。最初的设计将状态控制放在端点中，这样就不会有其他固有的故障点。将状态从端点移动到网络中的特定节点会降低灵活性，同时会增加单点故障的影响。请参阅下面图1中的进一步讨论。
In addition, NATs are not transparent to all applications, and managing simultaneous updates to a large array of ALGs may exceed the cost of acquiring additional globally routable addresses. See further discussion in Illustration 2 below.
此外，NAT对所有应用程序都不是透明的，同时管理对大量ALG的更新可能会超过获取额外全局可路由地址的成本。请参阅下面插图2中的进一步讨论。
While RSIP addresses the transparency and ALG issues, for the specific case of an individual private host needing public access, there is still a node with state required to maintain the connection.
虽然RSIP解决了透明度和ALG问题，但对于需要公共访问的单个私有主机的特定情况，仍然存在一个节点，其状态需要维护连接。
Dynamic NAT and RSIP will eventually violate higher layer assumptions about address/port number reuse as defined in RFC-793 [10] RFC-1323 [11]. The TCP state, TCP_TIME_WAIT, is specifically designed to prevent replay of packets between the 4-tuple of IP and port for a given IP address pair. Since the TCP state machine of a node is unaware of any previous use of RSIP, its attempt to connect to the same remote service that its neighbor just released (which is still in TCP_TIME_WAIT) may fail, or with a larger sequence number may open the prior connection directly from TCP_TIME_WAIT state, at the loss of the protection afforded by the TCP_TIME_WAIT state (further discussion in 2.6 of RFC-2663 [3]).
动态NAT和RSIP最终将违反RFC-793[10]RFC-1323[11]中定义的关于地址/端口号重用的高层假设。TCP状态，TCP_TIME_WAIT，专门设计用于防止在给定IP地址对的4元组IP和端口之间重播数据包。由于节点的TCP状态机不知道以前是否使用过RSIP，因此其尝试连接到其邻居刚刚发布的同一远程服务（仍处于TCP_TIME_WAIT状态）可能会失败，或者序列号较大的节点可能会直接从TCP_TIME_WAIT状态打开先前的连接，在失去TCP_TIME_WAIT状态提供的保护时（RFC-2663[3]的2.6中进一步讨论）。
For address translators (which do not translate ports) to comply with the TCP_TIME_WAIT requirements, they must refrain from assigning the same address to a different host until a period of 2*MSL has elapsed since the last use of the address, where MSL is the Maximum Segment Lifetime defined in RFC-793 as two minutes. For address-and-port translators to comply with this requirement, they similarly must refrain from assigning the same host/port pair until 2*MSL has elapsed since the end of its first use. While these requirements are simple to state, they can place a great deal of pressure on the NAT, because they temporarily reduce the pool of available addresses and ports. Consequently, it will be tempting or NAT implementers to ignore or shorten the TCP_TIME_WAIT requirements, at the cost of some of TCP's strong reliability. Note that in the case where the strong reliability is in fact compromised by the appearance of an old packet, the failure can manifest itself as the receiver accepting incorrect data. See further discussion in Illustration 3 below.
为了使地址转换器（不转换端口）符合TCP_TIME_WAIT要求，它们必须避免将同一地址分配给不同的主机，直到自上次使用地址起经过2*MSL的时间段，其中MSL是RFC-793中定义的最大段生存时间，为两分钟。为了使地址和端口转换器符合此要求，它们同样必须避免分配相同的主机/端口对，直到其第一次使用结束后经过2*MSL。虽然这些要求很容易说明，但它们会给NAT带来很大的压力，因为它们会暂时减少可用地址和端口池。因此，NAT或NAT实现者可能会忽略或缩短TCP_时间_等待要求，而以牺牲TCP的某些强大可靠性为代价。请注意，在强可靠性实际上因旧数据包的出现而受到损害的情况下，故障可能表现为接收器接收不正确的数据。请参阅下面插图3中的进一步讨论。
It is sometimes argued that NATs simply function to facilitate "routing realms", where each domain is responsible for finding addresses within its boundaries. Such a viewpoint clouds the limitations created by NAT with the better-understood need for routing management. Compartmentalization of routing information is correctly a function of routing protocols and their scope of application. NAT is simply a means to distribute address allocation authority and provide a mechanism to map addresses from one address realm into those of another realm.
有时有人认为NAT的作用只是为了促进“路由领域”，即每个域负责在其边界内查找地址。这样的观点掩盖了NAT带来的限制，使人们更容易理解路由管理的需要。路由信息的划分是路由协议及其应用范围的正确功能。NAT只是一种分配地址分配权限的方法，并提供一种将地址从一个地址域映射到另一个地址域的机制。
In particular, it is sometimes erroneously believed that NATs serve to provide routing isolation. In fact, if someone were to define an OSPF ALG it would actually be possible to route across a NAT boundary. Rather than NAT providing the boundary, it is the experienced operators who know how to limit network topology that serve to avoid leaking addresses across a NAT. This is an operational necessity given the potential for leaked addresses to introduce inconsistencies into the public infrastructure.
特别是，有时人们错误地认为NAT用于提供路由隔离。事实上，如果有人定义OSPF ALG，那么实际上就有可能通过NAT边界进行路由。不是NAT提供边界，而是有经验的操作员知道如何限制网络拓扑以避免NAT地址泄漏。考虑到泄露的地址可能会给公共基础设施带来不一致，这是一种操作上的必要性。
One of the greatest concerns from the explosion of NATs is the impact on the fledgling efforts at deploying network layer end-to-end IP security. One fundamental issue for IPSec is that with both AH and ESP, the authentication check covers the TCP/UDP checksum (which in turn covers the IP address). When a NAT changes the IP address, the checksum calculation will fail, and therefore authentication is guaranteed to fail. Attempting to use the NAT as a security boundary fails when requirement is end-to-end network layer encryption, since only the endpoints have access to the keys. See further discussion in Illustration 4 below.
NAT爆炸带来的最大问题之一是对部署网络层端到端IP安全的初期工作的影响。IPSec的一个基本问题是，对于AH和ESP，身份验证检查覆盖TCP/UDP校验和（反过来覆盖IP地址）。当NAT更改IP地址时，校验和计算将失败，因此身份验证将保证失败。当要求端到端网络层加密时，尝试使用NAT作为安全边界失败，因为只有端点可以访问密钥。请参阅下面图4中的进一步讨论。
Finally, while the port multiplexing variants of NAT (popular because they allow Internet access through a single address) work modestly well for connecting private hosts to public services, they create management problems for applications connecting from public toward private. The concept of a well-known port is undermined because only one private side system can be mapped through the single public-side port number. This will affect home networks, when applications like multi-player Internet games can only be played on one system at a time. It will also affect small businesses when only one system at a time can be operated on the standard port to provide web services. These may sound like only medium-grade restrictions for the present, but as a basic property of the Internet, not to change years into the future, it is highly undesirable. The issue is that the public toward private usage requires administrative mapping for each target prior to connection. If the ISP chooses to provide a standardized version of these to lower configuration options, they may find the support costs of managing the ALGs will exceed the cost of additional address space. See further discussion in Illustration 6 below.
最后，虽然NAT的端口多路复用变体（流行是因为它们允许通过单个地址进行Internet访问）在将私有主机连接到公共服务方面表现良好，但它们为从公共连接到私有的应用程序带来了管理问题。知名港口的概念受到了破坏，因为只有一个专用港口系统可以通过单个公共港口编号进行映射。当多人网络游戏等应用程序一次只能在一个系统上玩时，这将影响家庭网络。当一次只能在标准端口上运行一个系统以提供web服务时，这也会影响小型企业。这些可能听起来只是目前的中等限制，但作为互联网的一项基本属性，多年以后不会改变，这是非常不可取的。问题在于，从公共到私有的使用需要在连接之前对每个目标进行管理映射。如果ISP选择提供标准化版本以降低配置选项，他们可能会发现管理ALG的支持成本将超过额外地址空间的成本。请参阅下面图6中的进一步讨论。
A characteristic of stateful devices like NATs is the creation of a single point of failure. Attempts to avoid this by establishing redundant NATs, creates a new set of problems related to timely communication of the state, and routing related failures. This encompasses several issues such as update frequency, performance impact of frequent updates, reliability of the state update transaction, a-priori knowledge of all nodes needing this state information, and notification to end nodes of alternatives. (This notification could be accomplished with a routing protocol, which might require modifications to the hosts so they will listen.)
有状态设备（如NAT）的一个特点是创建单点故障。试图通过建立冗余NAT来避免这种情况，这会产生一组新的问题，这些问题与状态的及时通信以及路由相关的故障有关。这包括几个问题，例如更新频率、频繁更新的性能影响、状态更新事务的可靠性、需要此状态信息的所有节点的先验知识，以及向终端节点通知备选方案。（此通知可通过路由协议完成，该协议可能需要修改主机以使其能够侦听。）
-------- --------
| Host A |-----| Host B |
-------- | --------
-----------------
| |
------ ------
| AD 1 | | AD 2 |
------ ------
\ /
--------
/Internet\
----------
-------- --------
| Host A |-----| Host B |
-------- | --------
-----------------
| |
------ ------
| AD 1 | | AD 2 |
------ ------
\ /
--------
/Internet\
----------
--------
Illustration 1
--------
Illustration 1
In the traditional case where Access Device (AD) 1 & 2 are routers, the single point of failure is the end Host, and the only effort needed to maintain the connections through a router or link failure is a simple routing update from the surviving router. In the case where the ADs are a NAT variant there will be connection state maintained in the active path that would need to be shared with alternative NATs. When the Hosts have open connections through either NAT, and it fails, the application connections will drop unless the state had been previously moved to the surviving NAT. The hosts will still need to acquire a routing redirect. In the case of RSIP, the public side address pool would also need to be shared between the ADs to allow movement. This sharing creates another real-time operational complexity to prevent conflicting assignments at connection setup. NAT as a technology creates a point fate sharing outside the endpoints, in direct contradiction to the original Internet design goals.
在接入设备（AD）1和2是路由器的传统情况下，单点故障是终端主机，通过路由器或链路故障维护连接所需的唯一努力是从幸存路由器进行简单的路由更新。在ADs是NAT变体的情况下，活动路径中将保持连接状态，需要与备用NAT共享。当主机通过任一NAT打开连接并失败时，应用程序连接将断开，除非该状态先前已移动到幸存的NAT。主机仍需要获取路由重定向。在RSIP的情况下，公共侧地址池也需要在广告之间共享，以允许移动。这种共享会造成另一种实时操作复杂性，以防止在连接设置时分配冲突。NAT作为一种技术，在端点之外创建了一个点命运共享，这与最初的互联网设计目标直接矛盾。
In the following example of a proposed corporate network, each NAT/ALG was to be one or more devices at each physical location, and there were to be multiple physical locations per diagramed connection. The logistics of simply updating software on this scale is cumbersome, even when all the devices are the same manufacturer and model. While this would also be true with routers, it would be unnecessary for all devices to run a consistent version for an application to work across an arbitrary path.
在提议的公司网络的以下示例中，每个NAT/ALG将是每个物理位置处的一个或多个设备，并且每个有图连接将有多个物理位置。即使所有设备都是相同的制造商和型号，在这种规模上简单地更新软件的后勤工作也很麻烦。虽然路由器也是如此，但所有设备都不必运行一致的版本，应用程序就可以跨任意路径工作。
----------------------------------------
| Corporate Network |
| Asia |------| Americas |------| Europe |
------ ---------- --------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs|
-------- -------- --------
| | |
--------------------------------------------
| Internet |
--------------------------------------------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs|
-------- -------- --------
| | |
------------------ -------------- ----------------
Home Telecommuters Branch Offices Partner Networks
------------------ -------------- ----------------
----------------------------------------
| Corporate Network |
| Asia |------| Americas |------| Europe |
------ ---------- --------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs|
-------- -------- --------
| | |
--------------------------------------------
| Internet |
--------------------------------------------
| | |
-------- -------- --------
|NAT/ALGs| |NAT/ALGs| |NAT/ALGs|
-------- -------- --------
| | |
------------------ -------------- ----------------
Home Telecommuters Branch Offices Partner Networks
------------------ -------------- ----------------
--------
Illustration 2
--------
Illustration 2
The full range of upper layer architectural assumptions that are broken by NAT technologies may not be well understood without a very large-scale deployment, because it sometimes requires the diversity that comes with large-scale use to uncover unusual failure modes. The following example illustrates an instance of the problem discussed above in section 6.
如果不进行大规模部署，NAT技术破坏的上层架构假设的全部范围可能无法很好地理解，因为有时需要大规模使用带来的多样性来发现异常故障模式。以下示例说明了上文第6节中讨论的问题的一个实例。
-------- --------
| Host A |-----| Host B |
-------- | --------
--------
|NAT/RSIP|
--------
|
--------
|Internet|
--------
|
---------
| Web |
| Server |
---------
-------- --------
| Host A |-----| Host B |
-------- | --------
--------
|NAT/RSIP|
--------
|
--------
|Internet|
--------
|
---------
| Web |
| Server |
---------
--------
Illustration 3
--------
Illustration 3
Host A completes its transaction and closes the web service on TCP port 80, and the RSIP releases the public side address used for Host A. Host B attempts to open a connection to the same web service, and the NAT assigns then next free public side address which is the same one A just released. The source port selection rules on Host B happen to lead it to the same choice that A used. The connect request from Host B is rejected because the web server, conforming to the TCP specifications, has that 4-tuple in TIME WAIT for 4 minutes. By the time a call from Host B gets through to the helpdesk complaining about no access, the requested retry will work, so the issue is marked as resolved, when it in fact is an on-going, but intermittent, problem.
主机A完成其事务并关闭TCP端口80上的web服务，RSIP释放用于主机A的公共端地址。主机B尝试打开与同一web服务的连接，然后NAT分配下一个可用的公共端地址，即刚刚释放的公共端地址。主机B上的源端口选择规则恰好导致它使用与主机A相同的选择。来自主机B的连接请求被拒绝，因为符合TCP规范的web服务器使该4元组在时间上等待4分钟。当主机B的电话接通到服务台，抱怨无法访问时，请求的重试将起作用，因此问题被标记为已解决，而实际上它是一个持续但间歇性的问题。
Operational management of networks incorporating stateful packet modifying device is considerably easier if inbound and outbound packets traverse the same path. (Otherwise it's a headache to keep state for the two directions synchronized.) While easy to say, even with careful planning it can be difficult to manage using a connectionless protocol like IP. The problem of creating redundant connections is ensuring that routes advertised to the private side reach the end nodes and map to the same device as the public side route advertisements. This state needs to persist throughout the lifetime of sessions traversing the NAT, in spite of frequent or simultaneous internal and external topology churn. Consider the following case where the -X- links are broken, or flapping.
如果入站数据包和出站数据包通过相同的路径，则结合有状态数据包修改设备的网络的操作管理将相当容易。（否则，保持两个方向的状态同步是一件令人头疼的事情。）虽然说起来容易，但即使经过仔细的规划，使用IP这样的无连接协议也很难管理。创建冗余连接的问题是确保向专用端播发的路由到达终端节点，并映射到与公共端路由播发相同的设备。这种状态需要在穿越NAT的会话的整个生命周期内保持，尽管内部和外部拓扑频繁或同时发生变化。请考虑以下情况：-X链路断开或拍动。
-------- --------
| Host A | | Host B |
| Foo | | Bar |
-------- --------
| |
---- ----
|Rtr1|---X1---|Rtr2|
---- ----
| |
---- ----
|NAT1| |NAT2|
---- ----
| |
--------------
|Rtr Rtr|
| / Internet \ | ---
|Rtr----X2---Rtr|----|DNS|
-------------- ---
| |
| |
-------- --------
| Host C | | Host D |
-------- --------
-------- --------
| Host A | | Host B |
| Foo | | Bar |
-------- --------
| |
---- ----
|Rtr1|---X1---|Rtr2|
---- ----
| |
---- ----
|NAT1| |NAT2|
---- ----
| |
--------------
|Rtr Rtr|
| / Internet \ | ---
|Rtr----X2---Rtr|----|DNS|
-------------- ---
| |
| |
-------- --------
| Host C | | Host D |
-------- --------
--------
Illustration 4
--------
Illustration 4
To preserve a consistent view of routing, the best path to the Internet for Routers 1 & 2 is via NAT1, while the Internet is told the path to the address pool managed by the NATs is best found through NAT1. When the path X1 breaks, Router 2 would attempt to switch to NAT2, but the external return path would still be through NAT1. This is because the NAT1 device is advertising availability of a pool of addresses. Directly connected routers in this same situation would advertise the specific routes that existed after the loss. In this case, redundancy was useless.
为了保持路由的一致性，路由器1和2到Internet的最佳路径是通过NAT1，而Internet被告知到NATs管理的地址池的路径最好通过NAT1找到。当路径X1中断时，路由器2将尝试切换到NAT2，但外部返回路径仍将通过NAT1。这是因为NAT1设备正在公布地址池的可用性。在这种情况下，直接连接的路由器将公布丢失后存在的特定路由。在这种情况下，冗余是无用的。
Consider the case that the path between Router 1 & 2 is up, and some remote link in the network X2 is down. It is also assumed that DNS returns addresses for both NATs when queried for Hosts A or B. When Host D tries to contact Host B, the request goes through NAT2, but due to the internal routing, the reply is through NAT1. Since the state information for this connection is in NAT2, NAT1 will provide a new mapping. Even if the remote path is restored, the connection will not be made because the requests are to the public IP of NAT2, while the replies are from the public IP of NAT1.
考虑路由器1和2之间的路径上升的情况，并且网络X2中的一些远程链路被关闭。还假设在查询主机A或主机B时，DNS返回两个NAT的地址。当主机D尝试联系主机B时，请求通过NAT2，但由于内部路由，回复通过NAT1。由于此连接的状态信息在NAT2中，NAT1将提供一个新的映射。即使恢复了远程路径，也不会建立连接，因为请求来自NAT2的公共IP，而应答来自NAT1的公共IP。
In a third case, both Host A & B want to contact Host D, when the remote link X2 in the Internet breaks. As long as the path X1 is down, Host B is able to connect, but Host A is cut off. Without a thorough understanding of the remote topology (unlikely since Internet providers tend to consider that sensitive proprietary information), the administrator of Hosts A & B would have no clue why one worked and the other didn't. As far as he can tell the redundant paths through the NATs are up but only one connection works. Again, this is due to lack of visibility to the topology that is inherent when a stateful device is advertising availability to a pool rather than the actual connected networks.
在第三种情况下，当Internet中的远程链路X2中断时，主机a和B都希望联系主机D。只要路径X1断开，主机B就可以连接，但主机A被切断。如果没有对远程拓扑的彻底理解（互联网提供商倾向于考虑敏感的专有信息），主机A& B的管理员将不知道为什么一个工作而另一个没有。据他所知，通过NAT的冗余路径已启动，但只有一个连接工作。同样，这是由于当有状态设备向池而不是实际连接的网络宣传可用性时，缺乏对拓扑的可见性。
In any network topology, individual router or link failures may present problems with insufficient redundancy, but the state maintenance requirements of NAT present an additional burden that is not as easily understood or resolved.
在任何网络拓扑中，单个路由器或链路故障都可能会出现冗余不足的问题，但NAT的状态维护要求会带来额外的负担，这是不容易理解或解决的。
The primary feature of NATs is the 'simple' ability to connect private networks to the public Internet. When the private network exists prior to installing the NAT, it is unlikely and unnecessary that its name resolver would use a registered domain. As noted in RFC 1123 [12] DNS queries may be resolved via local multicast. Connecting the NAT device, and reconfiguring it's resolver to proxy for all external requests allows access to the public network by hosts on the private network. Configuring the public DNS for the set of private hosts that need inbound connections would require a registered domain (either private, or from the connecting ISP) and a unique name. At this point the partitioned name space is concatenated and hosts would have different names based on inside vs. outside queries.
NAT的主要特点是能够“简单”地将专用网络连接到公共互联网。如果在安装NAT之前存在专用网络，则其名称解析程序不太可能也没有必要使用已注册的域。如RFC 1123[12]中所述，DNS查询可以通过本地多播来解决。连接NAT设备，并将其解析程序重新配置为代理所有外部请求，允许专用网络上的主机访问公共网络。为需要入站连接的一组专用主机配置公共DNS需要注册域（专用域或来自连接的ISP）和唯一名称。此时，已分区的名称空间被连接起来，主机将根据内部查询和外部查询具有不同的名称。
-------- --------
| Host A | | Host B |
| Foo |-----| Bar |
-------- | -------- ---
|-------------|DNS|
--- ---
|NAT|
---
|
-------- ---
|Internet|----|DNS|
-------- ---
|
---
|NAT|
--- ---
|-------------|DNS|
-------- | -------- ---
| Host C |-----| Host D |
| Foo | | Bar |
-------- --------
-------- --------
| Host A | | Host B |
| Foo |-----| Bar |
-------- | -------- ---
|-------------|DNS|
--- ---
|NAT|
---
|
-------- ---
|Internet|----|DNS|
-------- ---
|
---
|NAT|
--- ---
|-------------|DNS|
-------- | -------- ---
| Host C |-----| Host D |
| Foo | | Bar |
-------- --------
--------
Illustration 5
--------
Illustration 5
Everything in this simple example will work until an application embeds a name. For example, a Web service running on Host D might present embedded URL's of the form http://D/bar.html, which would work from Host C, but would thoroughly confuse Host A. If the embedded name resolved to the public address, Host A would be happy, but Host C would be looking for some remote machine. Using the public FQDN resolution to establishing a connection from Host C to D, the NAT would have to look at the destination rather than simply forwarding the packet out to the router. (Normal operating mode for a NAT is translate & forward out the other interface, while routers do not send packets back on the same interface they came from.) The NAT did not create the name space fragmentation, but it facilitates attempts to merge networks with independent name administrations.
在应用程序嵌入名称之前，这个简单示例中的所有内容都将正常工作。例如，在主机D上运行的Web服务可能会显示以下形式的嵌入URLhttp://D/bar.html，这将从主机C开始工作，但会彻底混淆主机A。如果嵌入的名称解析为公共地址，主机A将很高兴，但主机C将寻找某台远程计算机。使用公共FQDN解析来建立从主机C到主机D的连接，NAT必须查看目的地，而不是简单地将数据包转发到路由器。（NAT的正常操作模式是将另一个接口转换并转发出去，而路由器不会将数据包发送回它们来自的同一个接口。）NAT没有创建名称空间碎片，但它有助于尝试将网络与独立的名称管理合并。
The recent mass growth of the Internet has been driven by support of low cost publication via the web. The next big push appears to be support of Virtual Private Networks (VPNs) frequently accomplished using L2TP. Technically VPN tunnels treat an IP infrastructure as a multiplexing substrate allowing the endpoints to build what appear to be clear pathways from end-to-end. These tunnels redefine network visibility and increase the likelihood of address collision when
最近互联网的大规模增长是由通过网络的低成本出版物的支持推动的。下一个重大推动似乎是支持经常使用L2TP实现的虚拟专用网络（VPN）。从技术上讲，VPN隧道将IP基础设施视为多路复用基板，允许端点从端到端构建看似清晰的路径。这些隧道重新定义了网络可见性，并增加了发生冲突时地址冲突的可能性
traversing multiple NATs. Address management in the private space behind NATs will become a significant burden, as there is no central body capable of, or willing to do it. The lower burden for the ISP is actually a transfer of burden to the local level, because administration of addresses and names becomes both distributed and more complicated.
穿越多个NAT。NAT背后的私有空间中的地址管理将成为一个重大负担，因为没有一个中央机构能够或愿意这样做。ISP的较低负担实际上是将负担转移到本地级别，因为地址和名称的管理变得更加分散和复杂。
As noted in RFC-1918, the merging of private address spaces can cause an overlap in address use, creating a problem. L2TP tunnels will increase the likelihood and frequency of that merging through the simplicity of their establishment. There are several configurations of address overlap which will cause failure, but in the simple example shown below the private use address of Host B matches the private use address of the VPN pool used by Host A for inbound connections. When Host B tries to establish the VPN interface, Host A will assign it an address from its pool for inbound connections, and identify the gateway for Host B to use. In the example, Host B will not be able to distinguish the remote VPN gateway address of Host A from its own private address on the physical interface, thus the connection will fail. Since private use addresses are by definition not publicly coordinated, as the complexity of the VPN mesh increases so does the likelihood that there will be a collision that cannot be resolved.
如RFC-1918所述，私有地址空间的合并可能会导致地址使用重叠，从而产生问题。L2TP隧道将通过其建设的简单性增加合并的可能性和频率。有几种地址重叠配置会导致故障，但在下面显示的简单示例中，主机B的专用地址与主机A用于入站连接的VPN池的专用地址匹配。当主机B尝试建立VPN接口时，主机A将从其池中为其分配入站连接的地址，并标识主机B要使用的网关。在该示例中，主机B将无法将主机A的远程VPN网关地址与其在物理接口上自己的专用地址区分开来，因此连接将失败。由于根据定义，私用地址不是公开协调的，随着VPN网格复杂性的增加，出现无法解决的冲突的可能性也随之增加。
--------------- ----------------
| 10.10.10.10 |--------L2TP-------| Assigned by A |
| Host A | --- --- | Host B |
| 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 |
--------------- --- --- ----------------
--------------- ----------------
| 10.10.10.10 |--------L2TP-------| Assigned by A |
| Host A | --- --- | Host B |
| 10.1.1.1 |--|NAT|-----|NAT|--| 10.10.10.10 |
--------------- --- --- ----------------
--------
Illustration 6
--------
Illustration 6
It has been reported that NAT introduces additional challenges when intrusion detection systems attempt to correlate reports between sensors inside and outside the NAT. While the details of individual systems are beyond the scope of this document, it is clear that a centralized system with monitoring agents on both sides of the NAT would also need access to the current NAT mappings to get this right. It would also be critical that the resulting data be indexed properly if there were agents behind multiple NATs using the same address range for the private side.
据报道，当入侵检测系统试图在NAT内外的传感器之间关联报告时，NAT带来了额外的挑战。虽然单个系统的详细信息超出了本文档的范围，但很明显，在NAT两侧都有监控代理的集中式系统也需要访问当前的NAT映射才能正确实现这一点。如果在多个NAT后面有代理使用私有端的相同地址范围，则正确索引生成的数据也是至关重要的。
This also applies to management data collected via SNMP. Any time the data stream carries an IP address; the central collector or ALG will need to manipulate the data based on the current mappings in the
这也适用于通过SNMP收集的管理数据。数据流携带IP地址的任何时间；中央收集器或ALG将需要基于中的当前映射操作数据
NAT.
纳特。
It has been argued that IPv6 is no longer necessary because NATs relieve the address space constraints and allow the Internet to continue growing. The reality is they point out the need for IPv6 more clearly than ever. People are trying to connect multiple machines through a single access line to their ISP and have been willing to give up some functionality to get that at minimum cost.
有人认为IPv6不再是必要的，因为NAT减轻了地址空间的限制，并允许Internet继续增长。事实是，他们比以往任何时候都更清楚地指出了IPv6的必要性。人们正试图通过一条接入线将多台机器连接到他们的ISP，并愿意放弃一些功能，以最低的成本获得这些功能。
Frequently the reason for cost increases is the perceived scarcity (therefore increased value) of IPv4 addresses, which would be eliminated through deployment of IPv6. This crisis mentality is creating a market for a solution to a problem already solved with greater flexibility by IPv6.
成本增加的原因通常是IPv4地址的稀缺性（因此价值增加），这将通过部署IPv6来消除。这种危机心态正在创造一个解决问题的市场，IPv6已经以更大的灵活性解决了这个问题。
If NAT had never been defined, the motivation to resolve the dwindling IPv4 address space would be a much greater. Given that NATs are enabling untold new hosts to attach to the Internet daily, it is difficult to ascertain the actual impact to the lifetime of IPv4, but NAT has certainly extended it. It is also difficult to determine the extent of delay NAT is causing for IPv6, both by relieving the pressure, and by redirecting the intellectual cycles away from the longer-term solution.
如果NAT从未定义过，那么解决IPv4地址空间不断缩小的问题的动机将更大。考虑到NAT每天都能让数不清的新主机连接到Internet，很难确定它对IPv4生命周期的实际影响，但NAT确实延长了它。另外，很难确定NAT对IPv6造成的延迟程度，这既可以缓解压力，也可以将智能周期从长期解决方案中转移出去。
But at the same time NAT functionality may be a critical facilitator in the deployment of IPv6. There are already 100 million or more computers running IPv4 on data networks. Some of these networks are connected to and thus part of the Internet and some are on private isolated networks. It is inconceivable that we could have a "flag day" and convert all of the existing IPv4 nodes to IPv6 at the same time. There will be a very long period of coexistence while both IPv4 and IPv6 are being used in the Internet and in private networks. The original IPv6 transition plan relied heavily on having new IPv6 nodes also be able to run IPv4 - a "dual stack" approach. When the dual stack node looks up another node in the DNS it will get back a IPv4 or an IPv6 address in response. If the response is an IPv4 address then the node uses IPv4 to contact the other node. And if the response is an IPv6 address then IPv6 can be used to make the contact. Turning the NAT into a 6to4 [13]router enables widespread deployment of IPv6 while providing an IPv4 path if IPv6 is unavailable. While this maintains the current set of issues for IPv4 connections, it reestablishes the end-to-end principle for IPv6 connections.
但同时，NAT功能可能是IPv6部署的关键促进因素。已经有1亿台或更多的计算机在数据网络上运行IPv4。这些网络中的一些连接到互联网，因此是互联网的一部分，而另一些则位于专用隔离网络上。不可想象的是，我们会有一个“卖旗日”，同时将所有现有的IPv4节点转换为IPv6。在互联网和专用网络中同时使用IPv4和IPv6时，将有一个非常长的共存期。最初的IPv6过渡计划在很大程度上依赖于让新的IPv6节点也能够运行IPv4——一种“双栈”方法。当双栈节点在DNS中查找另一个节点时，它将返回IPv4或IPv6地址作为响应。如果响应是IPv4地址，则节点使用IPv4与其他节点联系。如果响应是IPv6地址，则可以使用IPv6进行联系。将NAT转变为6to4[13]路由器可以广泛部署IPv6，同时在IPv6不可用时提供IPv4路径。虽然这保留了IPv4连接的当前问题集，但它重新建立了IPv6连接的端到端原则。
An alternative methodology would be to translate the packets between IPv6 and IPv4 at the boarders between IPv4 supporting networks and IPv6 supporting networks. The need for this functionality was recognized in [RFC 1752], the document that recommended to the IETF that IPv6 be developed and recommended that a set of working groups be established to work on a number of specific problems. Header translation (i.e, NAT) was one of those problems.
另一种方法是在IPv4支持网络和IPv6支持网络之间的边界上，在IPv6和IPv4之间转换数据包。[RFC 1752]中确认了对该功能的需求，该文件向IETF建议开发IPv6，并建议成立一组工作组来处理一些特定问题。标题翻译（即NAT）就是这些问题之一。
Of course, NATs in an IPv6 to IPv4 translation environment encounter all of the same problems that NATs encounter in a pure IPv4 and the environment and cautions in this document apply to both situations.
当然，IPv6到IPv4转换环境中的NAT会遇到与纯IPv4和环境中的NAT相同的问题，本文档中的注意事项适用于这两种情况。
NAT (particularly NAPT) actually has the potential to lower overall security because it creates the illusion of a security barrier, but does so without the managed intent of a firewall. Appropriate security mechanisms are implemented in the end host, without reliance on assumptions about routing hacks, firewall filters, or missing NAT translations, which may change over time to enable a service to a neighboring host. In general, defined security barriers assume that any threats are external, leading to practices that make internal breaches much easier.
NAT（尤其是NAPT）实际上有可能降低整体安全性，因为它会造成安全屏障的假象，但这样做没有防火墙的管理意图。在终端主机中实现适当的安全机制，而不依赖于关于路由攻击、防火墙过滤器或丢失NAT转换的假设，这些假设可能会随着时间的推移而改变，从而使服务能够提供给相邻主机。一般来说，定义的安全壁垒假设任何威胁都是外部的，导致更容易发生内部违规的做法。
IPsec RFC-2401 [7] defines a set of mechanisms to support packet-level authentication and encryption for use in IP networks. While this may be less efficient than application-level security but in the words of RFC-1752 [14] "support for basic packet-level authentication will provide for the adoption of a much needed, widespread, security infrastructure throughout the Internet."
IPsec RFC-2401[7]定义了一组机制，以支持IP网络中使用的数据包级身份验证和加密。虽然这可能不如应用程序级安全有效，但用RFC-1752[14]的话来说，“对基本数据包级身份验证的支持将使整个互联网采用急需的、广泛的安全基础设施。”
NATs break IPsec's authentication and encryption technologies because these technologies depend on an end-to-end consistency of the IP addresses in the IP headers, and therefore may stall further deployment of enhanced security across the Internet. NATs raise a number of specific issues with IPsec. For example;
NAT破坏了IPsec的身份验证和加密技术，因为这些技术依赖于IP报头中IP地址的端到端一致性，因此可能会阻止在Internet上进一步部署增强的安全性。NAT会引起IPsec的一些特定问题。例如
- Use of AH is not possible via NAT as the hash protects the IP address in the header. - Authenticated certificates may contain the IP address as part of the subject name for authentication purposes. - Encrypted Quick Mode structures may contain IP addresses and ports for policy verifications. - The Revised Mode of public key encryption includes the peer identity in the encrypted payload.
- 无法通过NAT使用AH，因为哈希保护标头中的IP地址。-经过身份验证的证书可能包含IP地址，作为身份验证目的的主体名称的一部分。-加密的快速模式结构可能包含用于策略验证的IP地址和端口。-修改后的公钥加密模式包括加密有效负载中的对等身份。
It may be possible to engineer and work around NATs for IPsec on a case-by-case basis, but at the cost of restricting the trust model, as discussed in section 4 above. With all of the restrictions placed on deployment flexibility, NATs present a significant obstacle to security integration being deployed in the Internet today.
可以根据具体情况设计和解决IPsec的NAT，但代价是限制信任模型，如上文第4节所述。由于对部署灵活性的所有限制，NAT对当今Internet中部署的安全集成构成了重大障碍。
As noted in the RFC-2694 [15], the DNS/ALG cannot support secure DNS name servers in the private domain. Zone transfers between DNSsec servers will be rejected when necessary modifications are attempted. It is also the case that DNS/ALG will break any modified, signed responses. This would be the case for all public side queries of private nodes, when the DNS server is on the private side. It would also be true for any private side queries for private nodes, when the DNS server is on the public side. Digitally signed records could be modified by the DNS/ALG if it had access to the source authentication key. DNSsec has been specifically designed to avoid distribution of this key, to maintain source authenticity. So NATs that use DNS/ALG to repair the namespace resolutions will either; break the security when modifying the record, or will require access to all source keys to requested resolutions.
如RFC-2694[15]中所述，DNS/ALG不能支持私有域中的安全DNS名称服务器。尝试进行必要的修改时，DNSsec服务器之间的区域传输将被拒绝。DNS/ALG也会破坏任何修改的、已签名的响应。当DNS服务器位于私有端时，私有节点的所有公共端查询都是这种情况。当DNS服务器位于公共端时，对于私有节点的任何私有端查询也是如此。如果DNS/ALG可以访问源身份验证密钥，则可以修改数字签名记录。DNSsec专门设计用于避免分发此密钥，以保持源代码的真实性。因此，使用DNS/ALG修复名称空间解析的NAT将：；修改记录时破坏安全性，或者需要访问所有源密钥才能获得请求的分辨率。
Security mechanisms that do not protect or rely on IP addresses as identifiers, such as TLS [16], SSL [17], or SSH [18] may operate in environments containing NATs. For applications that can establish and make use of this type of transport connection, NATs do not create any additional complications. These technologies may not provide sufficient protection for all applications as the header is exposed, allowing subversive acts like TCP resets. RFC-2385 [19] discusses the issues in more detail.
不保护或不依赖IP地址作为标识符的安全机制，如TLS[16]、SSL[17]或SSH[18]可以在包含NAT的环境中运行。对于可以建立和使用这种类型的传输连接的应用程序，NAT不会产生任何额外的复杂性。这些技术可能无法为所有应用程序提供足够的保护，因为报头是公开的，从而允许诸如TCP重置之类的颠覆行为。RFC-2385[19]更详细地讨论了这些问题。
Arguments that NATs may operate in a secure mode preclude true End-to-End security, as the NAT becomes the security endpoint. Operationally the NAT must be managed as part of the security domain, and in this mode the packets on the unsecured side of the NAT are fully exposed.
NAT可能在安全模式下运行的参数排除了真正的端到端安全性，因为NAT成为安全端点。从操作上讲，NAT必须作为安全域的一部分进行管理，在这种模式下，NAT不安全侧的数据包完全公开。
Given that NAT devices are being deployed at a fairly rapid pace, some guidelines are in order. Most of these cautionary in nature and are designed to make sure that the reader fully understands the implications of the use of NATs in their environment.
鉴于NAT设备正在以相当快的速度部署，一些指导原则是合适的。其中大多数本质上是警告性的，旨在确保读者充分理解在其环境中使用NAT的含义。
- Determine the mechanism for name resolution, and ensure the appropriate answer is given for each address administration. Embedding the DNS server, or a DNS ALG in the NAT device will likely be more manageable than trying to synchronize independent DNS systems across administrations.
- 确定名称解析机制，并确保为每个地址管理提供适当的答案。在NAT设备中嵌入DNS服务器或DNS ALG可能比尝试跨管理同步独立DNS系统更易于管理。
- Is the NAT configured for static one to one mappings, or will it dynamically manage them? If dynamic, make sure the TTL of the DNS responses is set to 0, and that the clients pay attention to the don't cache notification. - Will there be a single NAT device, or parallel with multiple paths? If single, consider the impact of a device failure. If multiple, consider how routing on both sides will insure the packets flow through the same box over the connection lifetime of the applications. - Examine the applications that will need to traverse the NAT and verify their immunity to address changes. If necessary provide an appropriate ALG or establish a VPN to isolate the application from the NAT. - Determine need for public toward private connections, variability of destinations on the private side, and potential for simultaneous use of public side port numbers. NAPTs increase administration if these apply. - Determine if the applications traversing the NAPT or RSIP expect all ports from the public IP address to be the same endpoint. Administrative controls to prevent simultaneous access from multiple private hosts will be required if this is the case. - If there are encrypted payloads, the contents cannot be modified unless the NAT is a security endpoint, acting as a gateway between security realms. This precludes end-to-end confidentiality, as the path between the NAT and endpoint is exposed. - Determine the path for name resolutions. If hosts on the private side of a NAPT or RSIP server need visibility to each other, a private side DNS server may be required. - If the environment uses secure DNS records, the DNS/ALG will require access to the source authentication keys for all records to be translated. - When using VPNs over NATs, identify a clearinghouse for the private side addresses to avoid collisions. - Assure that applications used both internally and externally avoid embedding names, or use globally unique ones. - When using RSIP, recognize the scope is limited to individual private network connecting to the public Internet. If other NATs are in the path (including web-server load-balancing devices), the advantage of RSIP (end-to-end address/port pair use) is lost. - For RSIP, determine the probability of TCP_Time_Wait collisions when subsequent private side hosts attempt to contact a recently disconnected public side service.
- NAT是为静态一对一映射配置的，还是将动态管理它们？如果是动态的，请确保DNS响应的TTL设置为0，并且客户端注意不缓存通知。-会有一个NAT设备，还是多路径并行？如果是单一的，考虑设备故障的影响。如果是多个，那么考虑两边的路由将确保包在应用程序的连接生命周期内流过同一个盒子。检查需要遍历NAT的应用程序，并验证它们对地址更改的免疫力。如有必要，提供适当的ALG或建立VPN以将应用程序与NAT隔离。-确定从公共到私有连接的需求、私有端目的地的可变性以及同时使用公共端端口号的可能性。如果适用，NAPTs将增加管理。-确定遍历NAPT或RSIP的应用程序是否希望来自公共IP地址的所有端口都是相同的端点。在这种情况下，需要管理控制以防止多个专用主机同时访问。-如果存在加密的有效负载，则不能修改内容，除非NAT是安全端点，充当安全领域之间的网关。这排除了端到端的机密性，因为NAT和端点之间的路径是公开的。-确定名称解析的路径。如果NAPT或RSIP服务器的专用端上的主机需要彼此可见，则可能需要专用端DNS服务器。-如果环境使用安全DNS记录，DNS/ALG将要求访问所有要翻译记录的源身份验证密钥。-在NAT上使用VPN时，为专用端地址确定一个交换所，以避免冲突。-确保内部和外部使用的应用程序避免嵌入名称，或使用全局唯一的名称。-在使用RSIP时，应认识到范围仅限于连接到公共互联网的个人专用网络。如果路径中有其他NAT（包括web服务器负载平衡设备），RSIP（端到端地址/端口对使用）的优势将丧失。-对于RSIP，确定后续私有端主机尝试联系最近断开连接的公共端服务时TCP_Time_Wait冲突的概率。
Over the 6-year period since RFC-1631, the experience base has grown, further exposing concerns raised by the original authors. NAT breaks a fundamental assumption of the Internet design; the endpoints are in control. Another design principle, 'keep-it-simple' is being overlooked as more features are added to the network to work around the complications created by NATs. In the end, overall flexibility and manageability are lowered, and support costs go up to deal with the problems introduced.
自RFC-1631以来的6年中，经验基础不断增长，进一步暴露了原作者提出的担忧。NAT打破了互联网设计的基本假设；端点处于控制状态。另一个设计原则“保持简单”被忽略了，因为网络增加了更多功能，以解决NAT带来的复杂问题。最终，总体灵活性和可管理性降低，处理引入的问题的支持成本增加。
Evangelists, for and against the technology, present their cases as righteous while downplaying any rebuttals.
福音传道者，无论是支持还是反对这项技术，都会以正义的姿态陈述自己的观点，同时淡化任何反驳。
- NATs are a 'fact of life', and will proliferate as an enhancement that sustains the existing IPv4 infrastructure. - NATs are a 'necessary evil' and create an administrative burden that is not easily resolved. More significantly, they inhibit the roll out of IPsec, which will in turn slow growth of applications that require a secure infrastructure.
- NAT是“生活中的事实”，并将作为支持现有IPv4基础设施的增强而扩散。-NAT是一种“必要的邪恶”，造成了不易解决的行政负担。更重要的是，它们抑制了IPsec的推出，这将反过来减缓需要安全基础设施的应用程序的增长。
In either case, NATs require strong applicability statements, clearly declaring what works and what does not.
在这两种情况下，NAT都需要强大的适用性声明，清楚地声明哪些有效，哪些无效。
An overview of the pluses and minuses:
优缺点概述：
NAT advantages NAT disadvantages
-------------------------------- --------------------------------
Masks global address changes Breaks end-to-end model
Eases renumbering when providers Facilitates concatenation of
change multiple name spaces
Breaks IPsec
Stateful points of failure
Address administrations avoid Requires source specific DNS reply
justifications to registries or DNS/ALG
DNS/ALG breaks DNSsec replies
Lowers address utilization Enables end-to-end address
conflicts
Lowers ISP support burden Increases local support burden and
complexity
Transparent to end systems in some Unique development for each app
cases
Load sharing as virtual host Performance limitations with scale
Delays need for IPv4 replacement May complicate integration of IPv6
NAT advantages NAT disadvantages
-------------------------------- --------------------------------
Masks global address changes Breaks end-to-end model
Eases renumbering when providers Facilitates concatenation of
change multiple name spaces
Breaks IPsec
Stateful points of failure
Address administrations avoid Requires source specific DNS reply
justifications to registries or DNS/ALG
DNS/ALG breaks DNSsec replies
Lowers address utilization Enables end-to-end address
conflicts
Lowers ISP support burden Increases local support burden and
complexity
Transparent to end systems in some Unique development for each app
cases
Load sharing as virtual host Performance limitations with scale
Delays need for IPv4 replacement May complicate integration of IPv6
There have been many discussions lately about the value of continuing with IPv6 development when the market place is widely deploying IPv4 NATs. A shortsighted view would miss the point that both have a role, because NATs address some real-world issues today, while IPv6 is targeted at solving fundamental problems, as well as moving forward. It should be recognized that there will be a long co-existence as applications and services develop for IPv6, while the lifetime of the existing IPv4 systems will likely be measured in decades. NATs are a diversion from forward motion, but they do enable wider participation at the present state. They also break a class of applications, which creates the need for complex work-around scenarios.
当市场广泛部署IPv4 NAT时，最近有很多关于继续IPv6开发的价值的讨论。短视的观点会忽略两者都有作用这一点，因为NAT解决了当今的一些现实问题，而IPv6的目标是解决根本问题，并向前迈进。应该认识到，随着IPv6应用程序和服务的发展，IPv4系统将长期共存，而现有IPv4系统的生命周期可能需要几十年的时间来衡量。NAT是向前运动的一种转移，但在目前的状态下，NAT确实能让更广泛的参与。它们还破坏了一类应用程序，这就需要复杂的变通方案。
Efforts to enhance general security in the Internet include IPsec and DNSsec. These technologies provide a variety of services to both authenticate and protect information during transit. By breaking these technologies, NAT and the DNS/ALG work-around, hinder deployment of enhanced security throughout the Internet.
加强互联网总体安全的努力包括IPsec和DNSsec。这些技术提供了多种服务，用于在传输过程中对信息进行身份验证和保护。通过破坏这些技术，NAT和DNS/ALG得以解决，阻碍了在整个互联网上部署增强的安全性。
There have also been many questions about the probability of VPNs being established that might raise some of the listed concerns. While it is hard to predict the future, one way to avoid ALGs for each application is to establish a L2TP over the NATs. This restricts the NAT visibility to the headers of the tunnel packets, and removes its effects from all applications. While this solves the ALG issues, it raises the likelihood that there will be address collisions as arbitrary connections are established between uncoordinated address spaces. It also creates a side concern about how an application establishes the necessary tunnel.
关于VPN建立的可能性也存在许多问题，这可能会引起一些列出的问题。虽然很难预测未来，但为每个应用避免ALG的一种方法是在NAT上建立L2TP。这将NAT可见性限制在隧道数据包的头上，并从所有应用程序中移除其影响。虽然这解决了ALG问题，但由于在不协调的地址空间之间建立了任意连接，因此提高了地址冲突的可能性。它还产生了一个次要问题，即应用程序如何建立必要的通道。
The original IP architecture is powerful because it provides a general mechanism on which other things (yet unimagined) may be built. While it is possible to build a house of cards, time and experience have lead to building standards with more structural integrity. IPv6 is the long-term solution that retains end-to-end transparency as a principle. NAT is a technological diversion to sustain the lifetime of IPv4.
最初的IP体系结构是强大的，因为它提供了一种通用的机制，在这种机制上可以构建其他东西（但无法想象）。虽然可以建造一座纸牌屋，但时间和经验已导致建筑标准具有更大的结构完整性。IPv6是一种长期解决方案，它将端到端的透明性作为一项原则。NAT是维持IPv4生存期的一种技术转移。
1 Bradner, S., " The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
1 Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
2 Egevang, K. and P. Francis, "The IP Network Address Translator", RFC 1631, May 1994.
2 Egevang，K.和P.Francis，“IP网络地址转换器”，RFC16311994年5月。
3 Srisuresh, P. and M. Holdrege, "NAT Terminology and Considerations", RFC 2663, August 1999.
3 Srisuresh，P.和M.Holdrege，“NAT术语和注意事项”，RFC 2663，1999年8月。
4 Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
4 Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
5 Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behavior Today", RFC 2101, February 1997.
5 Carpenter，B.，Crowcroft，J.和Y.Rekhter，“今天的IPv4地址行为”，RFC 21011997年2月。
6 M. Borella, D. Grabelsky, J., K. Tuniguchi, "Realm Specific IP: Protocol Specification", Work in Progress, March 2000.
6 M.Borella，D.Grabelsky，J.，K.Tuniguchi，“领域特定IP：协议规范”，正在进行的工作，2000年3月。
7 Kent, S. and R. Atkinson, "Security Architecture for IP", RFC 2401, November 1998.
7 Kent，S.和R.Atkinson，“IP的安全架构”，RFC 2401，1998年11月。
8 Carpenter, B., "Internet Transparency", RFC 2775, February 2000.
8 Carpenter，B.，“互联网透明度”，RFC 27752000年2月。
9 Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
9哈伯德，K.，科斯特斯，M.，康拉德，D.，卡伦伯格，D.和J.波斯特尔，“互联网注册IP分配指南”，BCP 12，RFC 2050，1996年11月。
10 Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
10 Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
11 Jacobson, V., Braden, R. and L. Zhang, "TCP Extension for High-Speed Paths", RFC 1185, October 1990.
11 Jacobson，V.，Braden，R.和L.Zhang，“高速路径的TCP扩展”，RFC 11851990年10月。
12 Braden, R., "Requirements for Internet Hosts", STD 3, RFC 1123, October 1989.
12 Braden，R.，“互联网主机的要求”，标准3，RFC 1123，1989年10月。
13 Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels", Work in Progress.
13 Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域而无显式隧道”，工作正在进行中。
14 Bradner, S. and A. Mankin, "Recommendation for IPng", RFC 1752, January 1995.
14 Bradner，S.和A.Mankin，“IPng建议”，RFC 1752，1995年1月。
15 Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to NAT", RFC 2694, September 1999.
15 Srisuresh，P.，Tsirtsis，G.，Akkiraju，P.和A.Heffernan，“NAT的DNS扩展”，RFC 26941999年9月。
16 Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246, January 1999.
16 Dierks，T.和C.Allen，“TLS协议”，RFC 2246，1999年1月。
17 http://home.netscape.com/eng/ssl3/ssl-toc.html, March 1996.
17http://home.netscape.com/eng/ssl3/ssl-toc.html，1996年3月。
18 T. Ylonen, et al., "SSH Protocol Architecture", Work in Progress, August 1998.
18 T.Ylonen等人，“SSH协议架构”，正在进行的工作，1998年8月。
19 Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
19 Heffernan，A.，“通过TCP MD5签名选项保护BGP会话”，RFC 2385，1998年8月。
Valuable contributions to this document came from the IAB, Vern Paxson (lbl), Scott Bradner (harvard), Keith Moore (utk), Thomas Narten (ibm), Yakov Rekhter (cisco), Pyda Srisuresh, Matt Holdrege (lucent), and Eliot Lear (cisco).
IAB、Vern Paxson（lbl）、Scott Bradner（哈佛）、Keith Moore（utk）、Thomas Narten（ibm）、Yakov Rekhter（思科）、Pyda Srisuresh、Matt Holdrege（朗讯）和Eliot Lear（思科）对本文件做出了宝贵贡献。
Tony Hain Microsoft One Microsoft Way Redmond, Wa. USA
Tony Hain微软公司位于华盛顿州雷德蒙市的一家微软公司。美国
Phone: 1-425-703-6619 EMail: tonyhain@microsoft.com
电话：1-425-703-6619电子邮件：tonyhain@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
版权所有（C）互联网协会（2000年）。版权所有。
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编辑功能的资金目前由互联网协会提供。