Network Working Group M. Holdrege
Request for Comments: 3027 ipVerse
Category: Informational P. Srisuresh
Jasmine Networks
January 2001
Network Working Group M. Holdrege
Request for Comments: 3027 ipVerse
Category: Informational P. Srisuresh
Jasmine Networks
January 2001
Protocol Complications with the IP Network Address Translator
IP网络地址转换器的协议复杂性
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 (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
Many internet applications can be adversely affected when end nodes are not in the same address realm and seek the assistance of an IP Network Address Translator (NAT) enroute to bridge the realms. The NAT device alone cannot provide the necessary application/protocol transparency in all cases and seeks the assistance of Application Level Gateways (ALGs) where possible, to provide transparency. The purpose of this document is to identify the protocols and applications that break with NAT enroute. The document also attempts to identify any known workarounds. It is not possible to capture all applications that break with NAT in a single document. This document attempts to capture as much information as possible, but is by no means a comprehensive coverage. We hope the coverage provides sufficient clues for applications not covered.
当终端节点不在同一地址域中并在路由过程中寻求IP网络地址转换器（NAT）的帮助以桥接这些域时，许多internet应用程序可能会受到不利影响。NAT设备本身无法在所有情况下提供必要的应用程序/协议透明度，并在可能的情况下寻求应用程序级网关（ALG）的帮助以提供透明度。本文档的目的是确定在路由过程中与NAT中断的协议和应用程序。该文件还试图确定任何已知的解决办法。不可能在单个文档中捕获所有与NAT冲突的应用程序。本文档试图捕获尽可能多的信息，但决不是全面的报道。我们希望覆盖范围为未覆盖的应用程序提供足够的线索。
Table of Contents
目录
1.0 Introduction .............................................. 2
2.0 Common Characteristics of Protocols broken by NAT ......... 2
3.0 Protocols that cannot work with NAT enroute ............... 4
4.0 Protocols that can work with the aid of an ALG ............ 8
5.0 Protocols designed explicitly to work with NAT enroute .... 16
6.0 Acknowledgements .......................................... 17
7.0 Security Considerations ................................... 17
8.0 References ................................................ 17
9.0 Authors' Addresses ........................................ 19
10.0 Full Copyright Statement ................................ 20
1.0 Introduction .............................................. 2
2.0 Common Characteristics of Protocols broken by NAT ......... 2
3.0 Protocols that cannot work with NAT enroute ............... 4
4.0 Protocols that can work with the aid of an ALG ............ 8
5.0 Protocols designed explicitly to work with NAT enroute .... 16
6.0 Acknowledgements .......................................... 17
7.0 Security Considerations ................................... 17
8.0 References ................................................ 17
9.0 Authors' Addresses ........................................ 19
10.0 Full Copyright Statement ................................ 20
This document requires the reader to be familiar with the terminology and function of NAT devices as described in [NAT-TERM]. In a nutshell, NAT attempts to provide a transparent routing solution to end hosts requiring communication to disparate address realms. NAT modifies end node addresses (within the IP header of a packet) en-route and maintains state for these updates so that datagrams pertaining to a session are transparently routed to the right end-node in either realm. Where possible, application specific ALGs may be used in conjunction with NAT to provide application level transparency. Unlike NAT, the function of ALG is application specific and would likely require examination and recomposition of IP payload.
本文件要求读者熟悉[NAT-TERM]中所述NAT设备的术语和功能。简而言之，NAT试图为需要与不同地址域通信的终端主机提供透明的路由解决方案。NAT在路由过程中修改终端节点地址（在数据包的IP报头内），并维护这些更新的状态，以便与会话相关的数据报透明地路由到任一域中的右端节点。在可能的情况下，特定于应用程序的ALG可与NAT结合使用，以提供应用程序级别的透明度。与NAT不同，ALG的功能是特定于应用程序的，可能需要检查和重新配置IP有效负载。
The following sections attempt to list applications that are known to have been impacted by NAT devices enroute. However, this is by no means a comprehensive list of all known protocols and applications that have complications with NAT - rather just a subset of the list gathered by the authors. It is also important to note that this document is not intended to advocate NAT, but rather to point out the complications with protocols and applications when NAT devices are enroute.
以下各节试图列出已知在途中受到NAT设备影响的应用程序。然而，这并不是所有已知的NAT协议和应用程序的综合列表，而只是作者收集的列表的一个子集。还需要注意的是，本文档并非旨在提倡NAT，而是指出NAT设备在途中时协议和应用程序的复杂性。
[NAT-TERM] and [NAT-TRAD] have sections listing the specific nature of problems and limitations to NAT devices. Some of these limitations are being restated in this section to summarize characteristics of protocols that are broken by NAT.
[NAT-TERM]和[NAT-TRAD]章节列出了问题的具体性质和NAT设备的限制。本节将重申其中一些限制，以总结NAT破坏的协议的特征。
A wide range of applications fail with NAT enroute when IP packets contain realm-specific IP address or port information in payload. An ALG may be able to provide work around in some cases. But, if the packet payload is IPsec secured (or secure by a transport or application level security mechanisms), the application is bound to fail.
当IP数据包在有效负载中包含领域特定的IP地址或端口信息时，许多应用程序在NAT途中失败。在某些情况下，ALG可能能够提供解决方案。但是，如果数据包有效负载是IPsec安全的（或由传输或应用程序级安全机制保护），则应用程序注定会失败。
Bundled session applications such as FTP, H.323, SIP and RTSP, which use a control connection to establish a data flow are also usually broken by NAT devices enroute. This is because these applications exchange address and port parameters within control session to establish data sessions and session orientations. NAT cannot know the inter-dependency of the bundled sessions and would treat each
捆绑会话应用程序（如FTP、H.323、SIP和RTSP）使用控制连接来建立数据流，通常也会在路由过程中被NAT设备破坏。这是因为这些应用程序在控制会话中交换地址和端口参数，以建立数据会话和会话方向。NAT无法知道捆绑会话的相互依赖性，并且会处理每个会话
session to be unrelated to one another. Applications in this case can fail for a variety of reasons. Two most likely reasons for failures are: (a) addressing information in control payload is realm-specific and is not valid once packet crosses the originating realm, (b) control session permits data session(s) to originate in a direction that NAT might not permit.
会话必须彼此无关。在这种情况下，应用程序可能由于各种原因而失败。失败的两个最可能的原因是：（a）控制有效负载中的寻址信息是特定于域的，并且一旦数据包穿过发起域就无效，（b）控制会话允许数据会话以NAT可能不允许的方向发起。
When DNS names are used in control payload, NAT device in conjunction with a DNS-ALG might be able to offer the necessary application level transparency, if NAT has no contention with data session orientation. However, using DNS names in place of realm-specific IP addresses may not be an option to many of these applications (e.g., FTP).
当DNS名称用于控制有效负载时，如果NAT与数据会话定向没有冲突，NAT设备与DNS-ALG结合可能能够提供必要的应用程序级透明度。但是，对于许多应用程序（例如FTP），使用DNS名称代替特定领域的IP地址可能不是一个选项。
When realm-specific addressing is specified in payload, and the payload is not encrypted, an ALG may in some cases be able to provide the work around necessary to make the applications run transparently across realms. The complexity of ALG depends on the application level knowledge required to process payload and maintain state.
当在有效负载中指定了领域特定的寻址，并且有效负载未加密时，ALG在某些情况下可能能够提供使应用程序跨领域透明运行所需的变通方法。ALG的复杂性取决于处理有效负载和维护状态所需的应用程序级知识。
Peer-to-peer applications more than client-server based applications are likely to break with NAT enroute. Unlike Client-server applications, Peer-to-peer applications can be originated by any of the peers. When peers are distributed across private and public realms, a session originated from an external realm is just as likely as the session from a host in private realm. External peers will be able to locate their peers in private realm only when they know the externally assigned IP address or the FQDN ahead of time. FQDN name to assigned address mapping can happen only so long as the enroute NAT device supports DNS-ALG. Examples of Peer-to-peer applications include interactive games, Internet telephony and event-based protocols (such as Instant-Messaging).
与基于客户端服务器的应用程序相比，对等应用程序更有可能在路由过程中与NAT中断。与客户机-服务器应用程序不同，对等应用程序可以由任何对等方发起。当对等点分布在私有和公共领域时，来自外部领域的会话与来自私有领域中主机的会话一样可能。只有当外部对等方提前知道外部分配的IP地址或FQDN时，它们才能在私有领域中定位它们的对等方。只有在途中NAT设备支持DNS-ALG的情况下，才能发生FQDN名称到分配地址的映射。对等应用程序的示例包括交互式游戏、互联网电话和基于事件的协议（如即时消息）。
This is particularly a problem with traditional NAT and may be less of an issue with bi-directional NAT, where sessions are permitted in both directions.
这对于传统NAT来说是一个特别的问题，对于双向NAT来说可能不是什么问题，因为双向NAT都允许会话。
A possible work-around for this type of problem with traditional-NAT is for private hosts to maintain an outbound connection with a server acting as their representative to the globally routed Internet.
对于传统NAT的这类问题，一种可能的解决方法是让私有主机与作为其全球路由Internet代表的服务器保持出站连接。
IP fragmentation with NAPT enroute is not an issue with any single application, but pervades across all TCP/UDP applications. The problem is described in detail in [NAT-TRAD]. Briefly, the problem goes as follows. Say, two private hosts originated fragmented
NAPT途中IP碎片不是任何单个应用程序的问题，而是遍及所有TCP/UDP应用程序。该问题在[NAT-TRAD]中有详细描述。简而言之，问题如下。比如说，两个私人主机
TCP/UDP packets to the same destination host. And, they happened to use the same fragmentation identifier. When the target host receives the two unrelated datagrams, carrying same fragmentation id, and from the same assigned host address, the target host is unable to determine which of the two sessions the datagrams belong to. Consequently, both sessions will be corrupted.
将TCP/UDP数据包发送到同一目标主机。而且，他们碰巧使用了相同的碎片标识符。当目标主机从同一个分配的主机地址接收到两个携带相同碎片id的不相关数据报时，目标主机无法确定数据报属于这两个会话中的哪一个会话。因此，两个会话都将被损坏。
NAT will most likely break applications that require address mapping to be retained across contiguous sessions. These applications require the private-to-external address mapping to be retained between sessions so the same external address may be reused for subsequent session interactions. NAT cannot know this requirement and may reassign external address to different hosts between sessions.
NAT很可能会中断需要在连续会话之间保留地址映射的应用程序。这些应用程序要求在会话之间保留私有到外部地址的映射，以便在后续会话交互中重用相同的外部地址。NAT无法了解此要求，可能会在会话之间将外部地址重新分配给不同的主机。
Trying to keep NAT from discarding an address mapping would require a NAT extension protocol to the application that would allow the application to inform the NAT device to retain the mappings. Alternately, an ALG may be required to interact with NAT to keep the address mapping from being discarded by NAT.
试图阻止NAT丢弃地址映射需要NAT扩展协议到应用程序，该协议允许应用程序通知NAT设备保留映射。或者，可能需要ALG与NAT交互，以防止地址映射被NAT丢弃。
This is a problem when the number of private hosts is larger than the external addresses available to map the private addresses into. Take for example the rlogin service initiated from a host in private realm supported by NAPT. Rlogin service clients use well-known rlogin port 512 as their TCP port ID. No more than one host in private realm can initiate the service. This is a case of trying to use a service that fundamentally requires more public addresses than are available. NAT devices can conserve addresses, but they cannot create more addresses.
当专用主机的数量大于可将专用地址映射到的外部地址时，这是一个问题。以NAPT支持的私有领域中的主机启动的rlogin服务为例。Rlogin服务客户端使用众所周知的Rlogin端口512作为其TCP端口ID。私有领域中不能有多个主机启动该服务。这是一个试图使用基本上需要比可用地址更多公共地址的服务的案例。NAT设备可以保存地址，但不能创建更多地址。
NAT fundamentally operates by modifying end node addresses (within the IP header) en-route. The IPsec AH standard [IPsec-AH] on the other hand is explicitly designed to detect alterations to IP packet header. So when NAT alters the address information enroute in IP header, the destination host receiving the altered packet will invalidate the packet since the contents of the headers have been altered. The IPsec AH secure packet traversing NAT will simply not reach the target application, as a result.
NAT基本上是通过在路由中修改终端节点地址（在IP报头内）来运行的。另一方面，IPsec AH标准[IPsec AH]明确设计用于检测IP数据包头的更改。因此，当NAT在IP报头的途中更改地址信息时，接收更改后的数据包的目标主机将使数据包无效，因为报头的内容已更改。因此，通过NAT的IPsec AH安全数据包将无法到达目标应用程序。
IPsec ESP ([IPsec-ESP]) encrypted packets may be altered by NAT device enroute only in a limited number of cases. In the case of TCP/UDP packets, NAT would need to update the checksum in TCP/UDP headers, when an address in IP header is changed. However, as the TCP/UDP header is encrypted by the ESP, NAT would not be able to make this checksum update. As a result, TCP/UDP packets encrypted in transport mode ESP, traversing a NAT device will fail the TCP/UDP checksum validation on the receiving end and will simply not reach the target application.
IPsec ESP（[IPsec ESP]）加密的数据包只能在有限的情况下由NAT设备在途中更改。对于TCP/UDP数据包，当IP报头中的地址更改时，NAT需要更新TCP/UDP报头中的校验和。但是，由于TCP/UDP报头由ESP加密，NAT将无法进行此校验和更新。因此，在传输模式ESP中加密的TCP/UDP数据包在穿越NAT设备时，将无法通过接收端的TCP/UDP校验和验证，并且无法到达目标应用程序。
Internet Key Exchange Protocol IKE can potentially pass IP addresses as node identifiers during Main, Aggressive and Quick Modes. In order for an IKE negotiation to correctly pass through a NAT, these payloads would need to be modified. However, these payloads are often protected by hash or obscured by encryption. Even in the case where IP addresses are not used in IKE payloads and an IKE negotiation could occur uninterrupted, there is difficulty with retaining the private-to-external address mapping on NAT from the time IKE completed negotiation to the time IPsec uses the key on an application. In the end, the use of end-to-end IPsec is severely hampered anyway, as described earlier.
Internet密钥交换协议IKE可能在主模式、主动模式和快速模式下将IP地址作为节点标识符传递。为了使IKE协商正确通过NAT，需要修改这些有效负载。然而，这些有效载荷通常受到散列的保护或被加密所掩盖。即使在IKE有效负载中不使用IP地址并且IKE协商可能不间断地发生的情况下，也很难在NAT上保留从IKE完成协商到IPsec在应用程序上使用密钥的私有到外部地址映射。最后，如前所述，端到端IPsec的使用受到严重阻碍。
For all practical purposes, end-to-end IPsec is impossible to accomplish with NAT enroute.
出于所有实际目的，在NAT路由中不可能实现端到端IPsec。
Kerberos 4 tickets are encrypted. Therefore, an ALG cannot be written. When the KDC receives a ticket request, it includes the source IP address in the returned ticket. Not all Kerberos 4 services actually check source IP addresses. AFS is a good example of a Kerberos 4 service which does not. Services which don't check are not picky about NAT devices enroute. Kerberos tickets are tied to the IP address that requested the ticket and the service with which to use the ticket.
Kerberos 4票据是加密的。因此，无法写入ALG。当KDC收到票证请求时，它在返回的票证中包含源IP地址。并非所有Kerberos 4服务都会检查源IP地址。AFS是Kerberos 4服务的一个很好的例子，它不支持。不检查的服务在途中对NAT设备并不挑剔。Kerberos票证绑定到请求票证的IP地址以及使用票证的服务。
The K4 ticket (response) contains a single IP address describing the interface used by the client to retrieve the ticket from the TGT from the perspective of KDC. This works fine if the KDC is across a NAT gateway and as long as all of the Kerberos services are also across a NAT gateway. The end user on private network will not notice any problems.
K4票证（响应）包含一个IP地址，该地址描述了客户端用于从KDC的角度从TGT检索票证的接口。如果KDC跨NAT网关，并且只要所有Kerberos服务也跨NAT网关，那么这种方法就可以正常工作。专用网络上的最终用户不会注意到任何问题。
There is also the caveat that NAT uses the same address mapping for the private host for the connection between the client and the KDC as for the connection between the client and the application server. A work around this problem would be to keep an arbitrary connection open to remote server during throughout the ticket lifetime, so as
还有一点需要注意的是，NAT对客户端和KDC之间的连接使用与客户端和应用服务器之间的连接相同的专用主机地址映射。解决此问题的一个方法是在整个票证生命周期内保持远程服务器的任意连接处于打开状态，以便
not to let NAT drop the address binding. Alternately, an ALG will need to be deployed to ensure that NAT would not change address bindings during the lifetime of a ticket and between the time a ticket is issued to private host and the time the ticket is used by private host.
不要让NAT丢弃地址绑定。或者，需要部署ALG，以确保NAT在票证的生命周期内，以及在向专用主机发出票证和专用主机使用票证之间不会更改地址绑定。
But, the ticket will be valid from any host within the private realm of NAPT. Without NAPT, an attacker needs to be able to spoof the source IP addresses of a connection that is being made in order to use a stolen ticket on a different host. With NAPT, all the attacker needs to do from the private realm of NAPT is to simply gain possession of a ticket. Of course, this assumes, NAPT private domain is not a trusted network - not surprisingly, since many attacks occur from inside the organization.
但是，票证将在NAPT私有领域内的任何主机上有效。如果没有NAPT，攻击者需要能够伪造正在建立的连接的源IP地址，以便在不同主机上使用被盗的票证。有了NAPT，攻击者只需从NAPT的私有领域获得一张票据即可。当然，这假设NAPT private domain不是一个受信任的网络——这并不奇怪，因为许多攻击都是从组织内部发生的。
Just as with Kerberos 4, Kerberos 5 tickets are encrypted. Therefore, an ALG cannot be written.
与Kerberos 4一样，Kerberos 5票据也是加密的。因此，无法写入ALG。
In Kerberos 5, the client specifies a list of IP addresses which the ticket should be valid for, or it can ask for a ticket valid for all IP addresses. By asking for an all-IP-addresses ticket or a ticket containing the NAPT device address, you can get krb5 to work with an NAPT device, although it isn't very transparent (it requires the clients to behave differently than they otherwise would). The MIT krb5 1.0 implementation didn't have any configurability for what IP addresses the client asked for (it always asked for the set of its interface addresses) and did not interact well with NAT. The MIT krb5 1.1 implementation allows you to put "noaddresses" somewhere in krb5.conf to request all-IP-addresses-valid tickets.
在Kerberos 5中，客户机指定了票证应有效的IP地址列表，或者它可以请求对所有IP地址有效的票证。通过请求一个全IP地址票证或一个包含NAPT设备地址的票证，您可以让krb5使用NAPT设备，尽管它不是非常透明（它要求客户端的行为与其他方式不同）。MIT krb5 1.0实现对于客户端要求的IP地址没有任何可配置性（它总是要求提供其接口地址集），并且与NAT的交互不好。MIT krb5 1.1实现允许您在krb5.conf中的某个位置放置“noaddress”，以请求所有IP地址的有效票证。
The K5 ticket (response) contains IP addresses, as requested by the client node, from which the ticket is to be considered valid. If the services being accessed with Kerberos authentication are on the public side of the NAT, then the Kerberos authentication will fail because the IP address used by the NAT (basic NAT or NAPT) is not in the list of acceptable addresses.
K5票证（响应）包含客户端节点请求的IP地址，票证将从中被视为有效。如果使用Kerberos身份验证访问的服务位于NAT的公共端，则Kerberos身份验证将失败，因为NAT使用的IP地址（基本NAT或NAPT）不在可接受地址列表中。
There are two workarounds in Kerberos 5 both of which reduce the security of the tickets. The first is to have the clients in NAPT private realm specify the public IP address of the NAPT in the ticket's IP list. But this leads to the same security problem detailed for K4. Plus, it is not obvious for the client in the private domain to find out the public IP Address of the NAPT. That would be a change of application behavior on end-host.
kerberos5中有两种解决方法，它们都会降低票据的安全性。第一种方法是让NAPT私有领域中的客户端在票证的IP列表中指定NAPT的公共IP地址。但这导致了与K4相同的安全问题。另外，对于私有域中的客户端来说，查找NAPT的公共IP地址并不明显。这将改变终端主机上的应用程序行为。
The second method is to remove all IP addresses from the K5 tickets but this now makes theft of the ticket even worse since the tickets can be used from anywhere. Not just from within the private network.
第二种方法是从K5票据中删除所有IP地址，但这使得票据被盗情况更加严重，因为票据可以在任何地方使用。不仅仅是从专用网络内部。
The X Windowing system is TCP based. However, the client-server relationship with these applications is reverse compared to most other applications. The X server or Open-windows server is the display/mouse/keyboard unit (i.e., the one that controls the actual Windows interface). The clients are the application programs driving the Windows interface.
X窗口系统是基于TCP的。但是，与大多数其他应用程序相比，与这些应用程序的客户机-服务器关系是相反的。X服务器或Open windows服务器是显示/鼠标/键盘单元（即控制实际windows界面的单元）。客户端是驱动Windows界面的应用程序。
Some machines run multiple X Windows servers on the same machine. The first X Windows server is at TCP port 6000. The first Open Windows server can be at port 6000 or port 2000 (more flexible). We will mainly refer X windowing system for illustration purposes here.
某些计算机在同一台计算机上运行多个X Windows服务器。第一台X Windows服务器位于TCP端口6000。第一个打开的Windows服务器可以位于端口6000或端口2000（更灵活）。为了便于说明，我们将主要参考X窗口系统。
X-term Transmits IP addresses from the client to the server for the purpose of setting the DISPLAY variable. When set the DISPLAY variable is used for subsequent connections from X clients on the host to an X server on the workstation. The DISPLAY variable is sent inline during the TELNET negotiations as
为了设置显示变量，X-term将IP地址从客户端传输到服务器。设置时，显示变量用于从主机上的X客户端到工作站上的X服务器的后续连接。显示变量在TELNET协商期间内联发送，如下所示：
DISPLAY=<local-ip-addr>:<server>.<display>
DISPLAY=<local-ip-addr>:<server>.<display>
where the <local-ip-addr> is retrieved by looking at the local ip address associated with the socket used to connect to <server>. The <server> determines which port (6000 + <server>) should be used to make the connection. <display> is used to indicate which monitor attached to the X server should be used but is not important to this discussion.
其中通过查看与用于连接到<server>的套接字关联的本地ip地址来检索<local ip addr>。<server>确定应使用哪个端口（6000+<server>）进行连接<display>用于指示应使用连接到X服务器的监视器，但对本讨论不重要。
The <local-ip-addr> used is not a DNS name because:
使用的<local ip addr>不是DNS名称，因为：
. The is no ability for the local machine to know its DNS name without performing a reverse DNS lookup on the local-ip-addr
. 如果不在本地ip地址上执行反向DNS查找，则本地计算机无法知道其DNS名称
. There is no guarantee that the name returned by a reverse DNS lookup actually maps back to the local IP address.
. 无法保证反向DNS查找返回的名称实际映射回本地IP地址。
. Lastly, without DNSSEC, it may not be safe to use DNS addresses because they can easily be spoofed. NAT and DNS-ALG cannot work unless DNSSEC is disabled.
. 最后，如果没有DNSSEC，使用DNS地址可能不安全，因为它们很容易被欺骗。除非禁用DNSSEC，否则NAT和DNS-ALG无法工作。
A common use of this application is people dialing in to corporate offices from their X terminals at home. Say, the X client is running on a host on the public side of the NAT and X server is running on a
此应用程序的一个常见用途是人们从家中的X终端拨入公司办公室。比如说，X客户机运行在NAT公共端的主机上，X服务器运行在NAT公共端的主机上
host on the private side of the NAT. The DISPLAY variable is transmitted inline to the host the X client is running in some way. The process transmitting the contents of the DISPLAY variable does not know the address of the NAT.
主机位于NAT的私有端。DISPLAY变量以某种方式内联传输到X客户机正在运行的主机。传输显示变量内容的进程不知道NAT的地址。
If the channel transmitting the DISPLAY variable is not encrypted, NAT device might solicit the help of an ALG to replace the IP address and configure a port in the valid display range (ports 6000 and higher) to act as a gateway. Alternately, NAT may be configured to listen for incoming connections to provide access to the X Server(s), without requiring an ALG. But, this approach increases the security risk by providing access to the X server that would not otherwise be available. As the ALG tampers with the IP addresses it will also not be possible for X Authorization methods other than MIT-MAGIC-COOKIE-1 to be used. MIT-MAGIC-COOKIE-1 is the least secure of all the documented X Authorization methods.
如果传输显示变量的通道未加密，NAT设备可能会请求ALG的帮助以替换IP地址，并将有效显示范围内的端口（端口6000及以上）配置为网关。或者，NAT可以配置为侦听传入连接以提供对X服务器的访问，而不需要ALG。但是，这种方法通过提供对X服务器的访问而增加了安全风险，否则X服务器将不可用。由于ALG篡改IP地址，因此除了MIT-MAGIC-COOKIE-1之外，X授权方法也不可能被使用。MIT-MAGIC-COOKIE-1是所有已记录的X授权方法中最不安全的。
When START_TLS is used there may be client certificate verification problems caused by the NAT depending on the information provided in the certificate.
使用START_TLS时，根据证书中提供的信息，NAT可能会导致客户端证书验证问题。
RSH uses multiple sessions to support separate streams for stdout and stderr. A random port number is transmitted inline from the client to the server for use as stderr port. The stderr socket is a connection back from the server to the client. And unlike FTP, there is no equivalent to PASV mode. For traditional NAT, this is a problem as traditional NAT would not permit incoming sessions.
RSH使用多个会话来支持stdout和stderr的单独流。随机端口号从客户端内联传输到服务器，用作stderr端口。stderr套接字是从服务器到客户端的连接。与FTP不同的是，没有与PASV模式等效的模式。对于传统NAT，这是一个问题，因为传统NAT不允许传入会话。
RLOGIN does not use multiple sessions. But the Kerberos protected versions of RSH and RLOGIN will not work in a NAT environment due to the ticket problems and the use of multiple sessions.
RLOGIN不使用多个会话。但是，由于票证问题和使用多个会话，受Kerberos保护的RSH和RLOGIN版本将无法在NAT环境中工作。
This document predominantly addresses problems associated with Traditional NAT, especially NAPT.
本文档主要解决与传统NAT相关的问题，尤其是NAPT。
FTP is a TCP based application, used to reliably transfer files between two hosts. FTP uses bundled session approach to accomplish this.
FTP是基于TCP的应用程序，用于在两台主机之间可靠地传输文件。FTP使用捆绑会话方法来实现这一点。
FTP is initiated by a client accessing a well-known port number 21 on the FTP server. This is called the FTP control session. Often, an additional data session accompanies the control session. By default,
FTP由访问FTP服务器上众所周知的端口号21的客户端启动。这称为FTP控制会话。通常，控制会话会伴随一个额外的数据会话。默认情况下，
the data session would be from TCP port 20 on server to the TCP port client used to initiate control session. However, the data session ports may be altered within the FTP control sessions using ASCII encoded PORT and PASV commands and responses.
数据会话将从服务器上的TCP端口20连接到用于启动控制会话的TCP端口客户端。但是，可以使用ASCII编码端口和PASV命令和响应在FTP控制会话中更改数据会话端口。
Say, an FTP client is in a NAT supported private network. An FTP ALG will be required to monitor the FTP control session (for both PORT and PASV modes) to identify the FTP data session port numbers and modify the private address and port number with the externally valid address and port number. In addition, the sequence and acknowledgement numbers, TCP checksum, IP packet length and checksum have to be updated. Consequently the sequence numbers in all subsequent packets for that stream must be adjusted as well as TCP ACK fields and checksums.
例如，FTP客户端位于NAT支持的专用网络中。需要FTP ALG来监控FTP控制会话（对于端口和PASV模式），以识别FTP数据会话端口号，并使用外部有效的地址和端口号修改专用地址和端口号。此外，必须更新序列号和确认号、TCP校验和、IP数据包长度和校验和。因此，必须调整该流的所有后续数据包中的序列号以及TCP ACK字段和校验和。
In rare cases, increasing the size of the packet could cause it to exceed the MTU of a given transport link. The packet would then have to be fragmented which could affect performance. Or, if the packet has the DF bit set, it would be ICMP rejected and the originating host would then have to perform Path MTU Discovery. This could have an adverse effect on performance.
在极少数情况下，增加数据包的大小可能导致其超过给定传输链路的MTU。然后，数据包必须被分割，这可能会影响性能。或者，如果数据包设置了DF位，它将被ICMP拒绝，并且发起主机将必须执行路径MTU发现。这可能会对性能产生不利影响。
Note however, if the control command channel is secured, it will be impossible for an ALG to update the IP addresses in the command exchange.
注意：但是，如果控制命令通道是安全的，ALG将无法更新命令交换中的IP地址。
When AUTH is used with Kerberos 4, Kerberos 5, and TLS, the same problems that occur with X-Term/Telnet occur with FTP.
当AUTH与Kerberos 4、Kerberos 5和TLS一起使用时，与X-Term/Telnet相同的问题也会出现在FTP中。
Lastly, it is of interest to note section 4 of RFC 2428 (FTP extensions for IPv6 and NATs) which describes how a new FTP port command (EPSV ALL) can be used to allow NAT devices to fast-track the FTP protocol, eliminating further processing through ALG, if the remote server accepts "EPSV ALL".
最后，值得注意的是RFC 2428（IPv6和NAT的FTP扩展）的第4节，该节描述了如果远程服务器接受“EPSV ALL”，如何使用新的FTP端口命令（EPSV ALL）来允许NAT设备快速跟踪FTP协议，从而消除通过ALG进行的进一步处理。
RSVP is positioned in the protocol stack at the transport layer, operating on top of IP (either IPv4 or IPv6). However, unlike other transport protocols, RSVP does not transport application data but instead acts like other Internet control protocols (for example, ICMP, IGMP, routing protocols). RSVP messages are sent hop-by-hop between RSVP-capable routers as raw IP datagrams using protocol number 46. It is intended that raw IP datagrams should be used between the end systems and the first (or last) hop router. However, this may not always be possible as not all systems can do raw network I/O. Because of this, it is possible to encapsulate RSVP messages within UDP datagrams for end-system communication. UDP-encapsulated
RSVP位于传输层的协议栈中，在IP（IPv4或IPv6）之上运行。但是，与其他传输协议不同，RSVP不传输应用程序数据，而是与其他Internet控制协议（例如，ICMP、IGMP、路由协议）类似。RSVP消息在支持RSVP的路由器之间逐跳发送，作为原始IP数据报，使用协议编号46。计划在终端系统和第一（或最后）跳路由器之间使用原始IP数据报。但是，这可能并不总是可能的，因为并非所有系统都可以进行原始网络I/O。因此，可以将RSVP消息封装在UDP数据报中，用于最终系统通信。UDP封装
RSVP messages are sent to either port 1698 (if sent by an end system) or port 1699 (if sent by an RSVP-enabled router). For more information concerning UDP encapsulation of RSVP messages; consult Appendix C of RFC 2205.
RSVP消息被发送到端口1698（如果由终端系统发送）或端口1699（如果由启用RSVP的路由器发送）。有关RSVP消息的UDP封装的更多信息；参考RFC 2205的附录C。
An RSVP session, a data flow with a particular destination and transport-layer protocol, is defined by:
RSVP会话是具有特定目的地和传输层协议的数据流，其定义如下：
Destination Address - the destination IP address for the data packets. This may be either a unicast or a multicast address.
目标地址-数据包的目标IP地址。这可以是单播或多播地址。
Protocol ID - the IP protocol ID (for example, UDP or TCP).
协议ID—IP协议ID（例如，UDP或TCP）。
Destination Port - a generalized destination port that is used for demultiplexing at a layer above the IP layer.
目标端口-用于在IP层之上的层上解复用的通用目标端口。
NAT devices are presented with unique problems when it comes to supporting RSVP. Two issues are:
NAT设备在支持RSVP时遇到了独特的问题。两个问题是：
1. RSVP message objects may contain IP addresses. The result is that an RSVP-ALG must be able to replace the IP addresses based upon the direction and type of the message. For example, if an external sender were to send an RSVP Path message to an internal receiver, the RSVP session will specify the IP address that the external sender believes is the IP address of the internal receiver. However, when the RSVP Path message reaches the NAT device, the RSVP session must be changed to reflect the IP address that is used internally for the receiver. Similar actions must be taken for all message objects that contain IP addresses.
1. RSVP消息对象可能包含IP地址。结果是，RSVP-ALG必须能够根据消息的方向和类型替换IP地址。例如，如果外部发送方将向内部接收方发送RSVP Path消息，则RSVP会话将指定外部发送方认为是内部接收方IP地址的IP地址。但是，当RSVP Path消息到达NAT设备时，必须更改RSVP会话以反映接收器内部使用的IP地址。对于包含IP地址的所有消息对象，必须采取类似的操作。
2. RSVP provides a means, the RSVP Integrity object, to guarantee the integrity of RSVP messages. The problem is that because of the first point, a NAT device must be able to change IP addresses within the RSVP messages. However, when this is done, the RSVP Integrity object is no longer valid as the RSVP message has been changed. Therefore an RSVP-ALG will not work when RSVP Integrity Object is used.
2. RSVP提供了一种手段，即RSVP Integrity对象，以保证RSVP消息的完整性。问题是，由于第一点，NAT设备必须能够更改RSVP消息中的IP地址。但是，完成此操作后，由于RSVP消息已更改，RSVP Integrity对象不再有效。因此，当使用RSVP Integrity对象时，RSVP-ALG将不起作用。
DNS is a TCP/UDP based protocol. Domain Names are an issue for hosts which use local DNS servers in NAT private realm. DNS name to address mapping for hosts in private domain should be configured on an authoritative name server within private domain. This server would be accessed by external and internal hosts alike for name resolutions. A DNS-ALG would be required to perform address to name conversions on DNS queries and responses. [DNS-ALG] describes DNS-ALG
DNS是基于TCP/UDP的协议。域名是NAT私有领域中使用本地DNS服务器的主机的问题。应在私有域内的权威名称服务器上配置私有域中主机的DNS名称到地址映射。外部主机和内部主机都可以访问此服务器以进行名称解析。需要DNS-ALG对DNS查询和响应执行地址到名称的转换。[DNS-ALG]描述了DNS-ALG
in detail. If DNS packets are encrypted/authenticated per DNSSEC, then DNS_ALG will fail because it won't be able to perform payload modifications.
详细地如果根据DNSSEC对DNS数据包进行加密/身份验证，则DNS\u ALG将失败，因为它将无法执行有效负载修改。
Applications using DNS resolver to resolve a DNS name into an IP address, assume availability of address assignment for reuse by the application specific session. As a result, DNS-ALG will be required to keep the address assignment (between private and external addresses) valid for a pre-configured period of time, past the DNS query.
使用DNS解析程序将DNS名称解析为IP地址的应用程序，假定地址分配可用，以供特定于应用程序的会话重用。因此，DNS-ALG需要在预先配置的时间段内（在专用地址和外部地址之间）保持地址分配的有效性，超过DNS查询。
Alternately, if there isn't a need for a name server within private domain, private domain hosts could simply point to an external name server for external name lookup. No ALG is required when the name server is located in external domain.
或者，如果在私有域中不需要名称服务器，私有域主机可以简单地指向外部名称服务器进行外部名称查找。当名称服务器位于外部域中时，不需要ALG。
SMTP is a TCP based protocol ([SMTP]), used by Internet email programs such as sendmail to send TCP-based email messages to well-known port 25. The mail server may be located within or outside private domain. But, the server must be assigned a global name and address, accessible by external hosts. When mail server is located within private domain, inbound SMTP sessions must be redirected to the private host from its externally assigned address. No special mapping is required when Mail server is located in external domain.
SMTP是一种基于TCP的协议（[SMTP]），由sendmail等Internet电子邮件程序用于将基于TCP的电子邮件发送到众所周知的端口25。邮件服务器可能位于私有域之内或之外。但是，必须为服务器分配一个可由外部主机访问的全局名称和地址。当邮件服务器位于专用域中时，入站SMTP会话必须从其外部分配的地址重定向到专用主机。当邮件服务器位于外部域中时，不需要特殊映射。
Generally speaking, mail systems are configured such that all users specify a single centralized address (such as fooboo@company.com), instead of including individual hosts (such as fooboo@hostA.company.com). The central address must have an MX record specified in the DNS name server accessible by external hosts.
一般来说，邮件系统的配置使得所有用户都指定一个集中的地址（例如fooboo@company.com)，而不包括单个主机（例如fooboo@hostA.company.com). 中心地址必须在外部主机可访问的DNS名称服务器中指定MX记录。
In the majority of cases, mail messages do not contain reference to private IP addresses or links to content data via names that are not visible to outside. However, some mail messages do contain IP addresses of the MTAs that relay the message in the "Received: " field. Some mail messages use IP addresses in place of FQDN for debug purposes or due to lack of a DNS record, in "Mail From: " field.
在大多数情况下，邮件消息不包含对私有IP地址的引用，也不包含通过外部不可见的名称指向内容数据的链接。但是，有些邮件确实包含在“Received:”字段中中继邮件的MTA的IP地址。出于调试目的或由于缺少DNS记录，某些邮件消息在“邮件发件人：”字段中使用IP地址代替FQDN。
If one or more MTAs were to be located behind NAT in a private domain, and the mail messages are not secured by signature or cryptographic keys, an SMTP-ALG may be used to translate the IP address information registered by the MTAs. If the MTAs have static address mapping, the translation would be valid across realms for long periods of time.
如果一个或多个MTA位于私有域中NAT的后面，并且邮件消息没有通过签名或加密密钥进行保护，则可以使用SMTP-ALG转换MTA注册的IP地址信息。如果MTA具有静态地址映射，那么转换将在很长一段时间内跨域有效。
The ability to trace the mail route may be hampered or prevented by NAT alone, without the ALG. This can cause problems when debugging mail problems or tracking down abusive users of mail.
在没有ALG的情况下，仅NAT可能会妨碍或阻止跟踪邮件路由的能力。在调试邮件问题或跟踪滥用邮件的用户时，这可能会导致问题。
SIP (Refer [SIP]) can run on either TCP or UDP, but by default on the same port 5060.
SIP（参考[SIP]）可以在TCP或UDP上运行，但默认情况下在同一端口5060上运行。
When used with UDP, a response to a SIP request does not go to the source port the request came from. Rather the SIP message contains the port number the response should be sent to. SIP makes use of ICMP port unreachable errors in the response to request transmissions. Request messages are usually sent on the connected socket. If responses are sent to the source port in the request, each thread handling a request would have to listen on the socket it sent the request on. However, by allowing responses to come to a single port, a single thread can be used for listening instead.
与UDP一起使用时，对SIP请求的响应不会发送到该请求来自的源端口。相反，SIP消息包含响应应该发送到的端口号。SIP利用请求传输响应中的ICMP端口不可访问错误。请求消息通常通过连接的套接字发送。如果响应被发送到请求中的源端口，那么处理请求的每个线程都必须侦听它发送请求的套接字。但是，通过允许响应到达单个端口，可以使用单个线程进行侦听。
A server may prefer to place the source port of each connected socket in the message. Then each thread can listen for responses separately. Since the port number for a response may not go to the source port of the request, SIP will not normally traverse a NAT and would require a SIP-ALG.
服务器可能更愿意在消息中放置每个连接套接字的源端口。然后每个线程可以分别侦听响应。由于响应的端口号可能不会到达请求的源端口，因此SIP通常不会遍历NAT，并且需要SIP-ALG。
SIP messages carry arbitrary content, which is defined by a MIME type. For multimedia sessions, this is usually the Session Description Protocol (SDP RFC 2327). SDP may specify IP addresses or ports to be used for the exchange of multimedia. These may loose significance when traversing a NAT. Thus a SIP-ALG would need the intelligence to decipher and translate realm-relevant information.
SIP消息包含由MIME类型定义的任意内容。对于多媒体会话，这通常是会话描述协议（SDP RFC 2327）。SDP可以指定用于多媒体交换的IP地址或端口。当穿越NAT时，这些可能失去意义。因此，SIP-ALG需要情报来破译和翻译领域相关信息。
SIP carries URL's in its Contact, To and From fields that specify signaling addresses. These URL's can contain IP addresses or domain names in the host port portion of the URL. These may not be valid once they traverse a NAT.
SIP在其联系人中携带URL，往返于指定信令地址的字段。这些URL可以在URL的主机端口部分包含IP地址或域名。一旦它们穿过NAT，它们可能无效。
As an alternative to an SIP-ALG, SIP supports a proxy server which could co-reside with NAT and function on the globally significant NAT port. Such a proxy would have a locally specific configuration.
作为SIP-ALG的替代方案，SIP支持一个代理服务器，该代理服务器可以与NAT共存，并在全球重要的NAT端口上运行。这样的代理将具有本地特定的配置。
In default mode, RealAudio clients (say, in a private domain) access TCP port 7070 to initiate conversation with a real-audio server (say, located an external domain) and to exchange control messages during playback (ex: pausing or stopping the audio stream). Audio session parameters are embedded in the TCP control session as byte stream.
在默认模式下，RealAudio客户端（例如，在私有域中）访问TCP端口7070以启动与真实音频服务器（例如，位于外部域）的对话，并在播放期间交换控制消息（例如：暂停或停止音频流）。音频会话参数作为字节流嵌入TCP控制会话中。
The actual audio traffic is carried in the opposite direction on incoming UDP based packets (originated from the server) directed to ports in the range of 6970-7170.
实际的音频流量在传入的基于UDP的数据包（来自服务器）上以相反的方向传输，这些数据包定向到6970-7170范围内的端口。
As a result, RealAudio is broken by default on a traditional NAT device. A work around for this would be for the ALG to examine the TCP traffic to determine the audio session parameters and selectively enable inbound UDP sessions for the ports agreed upon in the TCP control session. Alternately, the ALG could simply redirect all inbound UDP sessions directed to ports 6970-7170 to the client address in the private domain.
因此，在传统NAT设备上，RealAudio在默认情况下被破坏。解决方法是ALG检查TCP流量，以确定音频会话参数，并有选择地为TCP控制会话中商定的端口启用入站UDP会话。或者，ALG可以简单地将所有定向到端口6970-7170的入站UDP会话重定向到私有域中的客户端地址。
For bi-Directional NAT, you will not need an ALG. Bi-directional NAT could simply treat each of the TCP and UDP sessions as 2 unrelated sessions and perform IP and TCP/UDP header level translations.
对于双向NAT，您不需要ALG。双向NAT可以简单地将每个TCP和UDP会话视为两个不相关的会话，并执行IP和TCP/UDP头级别的转换。
The readers may contact RealNetworks for detailed guidelines on how their applications can be made to work, traversing through NAT and firewall devices.
读者可以联系RealNetworks，以获取有关如何通过NAT和防火墙设备使其应用程序工作的详细指南。
H.323 is complex, uses dynamic ports, and includes multiple UDP streams. Here is a summary of the relevant issues:
323非常复杂，使用动态端口，并且包含多个UDP流。以下是有关问题的摘要：
An H.323 call is made up of many different simultaneous connections. At least two of the connections are TCP. For an audio-only conference, there may be up to 4 different UDP 'connections' made.
323呼叫由许多不同的同时连接组成。至少有两个连接是TCP。对于纯音频会议，最多可以建立4个不同的UDP“连接”。
All connections except one are made to ephemeral (dynamic) ports.
除一个连接外，所有连接都连接到临时（动态）端口。
Calls can be initiated from the private as well as the external domain. For conferencing to be useful, external users need to be able to establish calls directly with internal users' desktop systems.
可以从私有域和外部域发起调用。为了使会议变得有用，外部用户需要能够直接与内部用户的桌面系统建立呼叫。
The addresses and port numbers are exchanged within the data stream of the 'next higher' connection. For example, the port number for the H.245 connection is established within the Q.931 data stream. (This makes it particularly difficult for the ALG, which will be required to modify the addresses inside these data streams.) To make matters worse, it is possible in Q.931, for example, to specify that the H.245 connection should be secure (encrypted). If a session is encrypted, it is impossible for the ALG to decipher the data stream, unless it has access to the shared key.
地址和端口号在“下一个更高”连接的数据流中交换。例如，H.245连接的端口号在Q.931数据流中建立。（这使得ALG特别难以修改这些数据流中的地址。）更糟糕的是，例如，在Q.931中，可以指定H.245连接应该是安全的（加密的）。如果会话被加密，ALG不可能解密数据流，除非它可以访问共享密钥。
Most of the control information is encoded in ASN.1 (only the User-User Information within Q.931 Protocol Data Units, or PDUs, is
大多数控制信息都编码在ASN.1中（只有Q.931协议数据单元（PDU）中的用户信息是
ASN.1-encoded (other parts of each Q.931 PDU are not encoded). For those unfamiliar with ASN.1, suffice it to say that it is a complex encoding scheme, which does not end up with fixed byte offsets for address information. In fact, the same version of the same application connecting to the same destination may negotiate to include different options, changing the byte offsets.
ASN.1编码（每个Q.931 PDU的其他部分未编码）。对于那些不熟悉ASN.1的人来说，可以说这是一种复杂的编码方案，它不会以地址信息的固定字节偏移量结束。事实上，连接到同一目的地的同一应用程序的同一版本可能会协商包括不同的选项，从而更改字节偏移量。
Below is the protocol exchange for a typical H.323 call between User A and User B. A's IP address is 88.88.88.88 and B's IP address is 99.99.99.99. Note that the Q.931 and H.245 messages are encoded in ASN.1 in the payload of an RTP packet. So to accomplish a connection through a NAT device, an H.323-ALG will be required to examine the packet, decode the ASN.1, and translate the various H.323 control IP addresses.
下面是用户a和用户B之间典型H.323呼叫的协议交换。a的IP地址为88.88.88.88，B的IP地址为99.99.99.99。请注意，Q.931和H.245消息在RTP数据包的有效负载中以ASN.1编码。因此，为了通过NAT设备实现连接，需要H.323-ALG检查数据包，解码ASN.1，并翻译各种H.323控制IP地址。
User A User B A establishes connection to B on well-known Q.931 port (1720)
用户A用户B A在著名的Q.931端口（1720）上与B建立连接
----------------------------------------------->
Q.931 Setup caller address = 88.88.88.88
caller port = 1120
callee address = 99.99.99.99
callee port = 1720
<-----------------------------------------------
Q.931 Alerting
<-----------------------------------------------
Q.931 Connect H.245 address = 99.99.99.99
H.245 port = 1092
----------------------------------------------->
Q.931 Setup caller address = 88.88.88.88
caller port = 1120
callee address = 99.99.99.99
callee port = 1720
<-----------------------------------------------
Q.931 Alerting
<-----------------------------------------------
Q.931 Connect H.245 address = 99.99.99.99
H.245 port = 1092
User A establishes connection to User B at 99.99.99.99, port 1092
用户A在99.99.99.99端口1092与用户B建立连接
<---------------------------------------------->
Several H.245 messages are exchanged (Terminal
Capability Set, Master Slave Determination and
their respective ACKs)
<---------------------------------------------->
Several H.245 messages are exchanged (Terminal
Capability Set, Master Slave Determination and
their respective ACKs)
<-----------------------------------------------
H.245 Open Logical Channel, channel = 257
RTCP address = 99.99.99.99
RTCP port = 1093
----------------------------------------------->
H.245 Open Logical Channel Ack, channel = 257
RTP address = 88.88.88.88
RTP port = 2002
(This is where User A would like RTP
data sent to)
<-----------------------------------------------
H.245 Open Logical Channel, channel = 257
RTCP address = 99.99.99.99
RTCP port = 1093
----------------------------------------------->
H.245 Open Logical Channel Ack, channel = 257
RTP address = 88.88.88.88
RTP port = 2002
(This is where User A would like RTP
data sent to)
RTCP address = 88.88.88.88
RTCP port = 2003
----------------------------------------------->
H.245 Open Logical Channel, channel = 257
RTCP address = 88.88.88.88
RTCP port = 2003
<-----------------------------------------------
H.245 Open Logical Channel Ack, channel = 257
RTP address = 99.99.99.99
RTP port = 1092
(This is where User B would like RTP data
sent to)
RTCP address = 99.99.99.99
RTP port = 1093
RTCP address = 88.88.88.88
RTCP port = 2003
----------------------------------------------->
H.245 Open Logical Channel, channel = 257
RTCP address = 88.88.88.88
RTCP port = 2003
<-----------------------------------------------
H.245 Open Logical Channel Ack, channel = 257
RTP address = 99.99.99.99
RTP port = 1092
(This is where User B would like RTP data
sent to)
RTCP address = 99.99.99.99
RTP port = 1093
Also note that if an H.323 Gateway resided inside a NAT boundary, the ALG would have to be cognizant of the various gateway discovery schemes and adapt to those schemes as well. Or if just the H.323 host/terminal was inside the NAT boundary and tried to register with a Gatekeeper, the IP information in the registration messages would have to be translated by NAT.
还要注意，如果H.323网关位于NAT边界内，则ALG必须了解各种网关发现方案并适应这些方案。或者，如果只有H.323主机/终端在NAT边界内并试图向网守注册，则注册消息中的IP信息必须由NAT翻译。
SNMP is a network management protocol based on UDP. SNMP payload may contain IP addresses or may refer IP addresses through an index into a table. As a result, when devices within a private network are managed by an external node, SNMP packets transiting a NAT device may contain information that is not relevant in external domain. In some cases, as described in [SNMP-ALG], an SNMP ALG may be used to transparently convert realm-specific addresses into globally unique addresses. Such an ALG assumes static address mapping and bi-directional NAT. It can only work for the set of data types (textual conventions) understood by the SNMP-ALG implementation and for a given set of MIB modules. Furthermore, replacing IP addresses in the SNMP payload may lead to communication failures due to changes in message size or changes in the lexicographic ordering.
SNMP是一种基于UDP的网络管理协议。SNMP有效负载可以包含IP地址，也可以通过索引将IP地址引用到表中。因此，当专用网络中的设备由外部节点管理时，传输NAT设备的SNMP数据包可能包含与外部域无关的信息。在某些情况下，如[SNMP-ALG]中所述，SNMP ALG可用于透明地将领域特定地址转换为全局唯一地址。这种ALG采用静态地址映射和双向NAT。它只能用于SNMP-ALG实现所理解的一组数据类型（文本约定）和一组给定的MIB模块。此外，替换SNMP有效负载中的IP地址可能会由于消息大小的变化或字典顺序的变化而导致通信失败。
Making SNMP ALGs completely transparent to all management applications is not an achievable task. The ALGs will run into problems with SNMPv3 security features, when authentication (and optionally privacy) is enabled, unless the ALG has access to security keys. [NAT-ARCH] also hints at potential issues with SNMP management via NAT.
使SNMP ALG对所有管理应用程序完全透明不是一项可以实现的任务。在启用身份验证（以及可选的隐私）时，ALG将在SNMPv3安全功能方面遇到问题，除非ALG可以访问安全密钥。[NAT-ARCH]还提示通过NAT进行SNMP管理的潜在问题。
Alternately, SNMP proxies, as defined in [SNMP-APPL], may be used in conjunction with NAT to forward SNMP messages to external SNMP engines (and vice versa). SNMP proxies are tailored to the private
或者，可以将[SNMP-APPL]中定义的SNMP代理与NAT结合使用，将SNMP消息转发给外部SNMP引擎（反之亦然）。SNMP代理是针对私有网络而定制的
domain context and can hence operate independent of the specific managed object types being accessed. The proxy solution will require the external management application to be aware of the proxy forwarder and the individual nodes being managed will need to be configured to direct their SNMP traffic (notifications and requests) to the proxy forwarder.
域上下文，因此可以独立于正在访问的特定托管对象类型进行操作。代理解决方案将要求外部管理应用程序了解代理转发器，并且需要对被管理的各个节点进行配置，以将其SNMP流量（通知和请求）定向到代理转发器。
Activision Games were designed to be NAT-friendly so as not to require an ALG for the games to work transparently through traditional NAT devices. Game players within a private domain can play with other players in the same domain or external domain. Activision gaming protocol is proprietary and is based on UDP. The address server uses UDP port number 21157 and is expected to be located in the global address realm.
Activision游戏设计为NAT友好型，因此不需要ALG，游戏就可以通过传统的NAT设备透明地运行。私有域中的游戏玩家可以与同一域或外部域中的其他玩家一起玩。Activision游戏协议是专有的，基于UDP。地址服务器使用UDP端口号21157，预期位于全局地址域中。
Game players connect to the address server first, and send their private IP address information (such as private IP address and UDP port number) in the initial connect message. The server notes private address information from the connect message and external address information from the IP and UDP headers. The server then sends both the private and external address information of the game player to all the other peer players. At this point, each game player knows the private and public address information of every other peer. Subsequent to this, each client opens up symmetrical direct connection to each other and uses whichever address (private or external) works first.
游戏玩家首先连接到地址服务器，并在初始连接消息中发送其私有IP地址信息（如私有IP地址和UDP端口号）。服务器记录连接消息中的私有地址信息以及IP和UDP头中的外部地址信息。然后，服务器将游戏玩家的私人和外部地址信息发送给所有其他对等玩家。在这一点上，每个游戏玩家都知道其他对等方的私人和公共地址信息。随后，每个客户机打开彼此的对称直接连接，并使用最先工作的地址（私有或外部）。
Now, the clients can have a session directly with other clients (or) they can have session with other clients via the gaming server. The key is to allow reuse of the same (global address, assigned UDP port) tuple used for initial connection to the game server for all subsequent connections to the client. A game player is recognized by one of (private address, UDP port) or (global address, assigned UDP port) by all other peer players. So, the binding between tuples should remain unchanged on NAT, so long as the gaming player is in session with one or multiple other players.
现在，客户端可以直接与其他客户端进行会话（或者）通过游戏服务器与其他客户端进行会话。关键是允许重复使用初始连接到游戏服务器时使用的相同（全局地址、分配的UDP端口）元组，以便所有后续连接到客户端。游戏玩家由所有其他对等玩家（专用地址、UDP端口）或（全局地址、分配的UDP端口）之一识别。因此，在NAT上，元组之间的绑定应该保持不变，只要游戏玩家正在与一个或多个其他玩家进行会话。
Opening a connection to a game server in external realm from a private host is no problem. All NAT would have to do is provide routing transparency and retain the same private-to-external address binding so long as there is a minimum of one gaming session with an external node. But, an NAPT configuration must allow multiple simultaneous UDP connections on the same assigned global address/port.
从私有主机打开到外部领域中游戏服务器的连接没有问题。NAT所要做的就是提供路由透明性，并保留相同的私有到外部地址绑定，只要至少有一个与外部节点的游戏会话。但是，NAPT配置必须允许在同一分配的全局地址/端口上同时进行多个UDP连接。
The above approach has some problems. For example, a client could try contacting a private address, but that private address could be in use locally, when the private address at some other realm is meant. If the node that was contacted wrongfully has some other service or no service registered for the UDP port, the Activision connect messages are expected to be simply dropped. In the unlikely event, a registered application chooses to interpret the message, the results can be unpredictable.
上述方法存在一些问题。例如，客户机可以尝试联系一个私有地址，但该私有地址可能在本地使用，而这意味着该私有地址位于其他领域。如果错误联系的节点有其他服务或没有为UDP端口注册服务，则Activision connect消息将被删除。在不太可能的情况下，注册的应用程序选择解释消息，结果可能是不可预测的。
The readers may refer to Activision for the proprietary, detailed information on the function and design of this protocol.
读者可参考Activision，了解有关本协议功能和设计的专有详细信息。
The authors would like to express sincere thanks to Bernard Aboba, Bill Sommerfield, Dave Cridland, Greg Hudson, Henning Schulzrine, Jeffrey Altman, Keith Moore, Thomas Narten, Vernon Shryver and others that had provided valuable input in preparing this document. Special thanks to Dan Kegel for sharing the Activision games design methodology.
作者谨向Bernard Aboba、Bill Sommerfield、Dave Cridland、Greg Hudson、Henning Schulzrine、Jeffrey Altman、Keith Moore、Thomas Narten、Vernon Shryver和其他人表示诚挚的感谢，他们为编写本文件提供了宝贵的投入。特别感谢Dan Kegel分享Activision游戏设计方法。
The security considerations outlined in [NAT-TERM] are relevant to all NAT devices. This document does not warrant additional security considerations.
[NAT-TERM]中概述的安全注意事项与所有NAT设备相关。本文件不保证额外的安全考虑。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TERM]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，1999年8月。
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT-TRAD]Srisuresh，P.和K.Egevang，“传统IP网络地址转换器（传统NAT）”，RFC 3022，2001年1月。
[H.323] ITU-T SG16 H.323, Intel white paper, "H.323 and Firewalls", Dave Chouinard, John Richardson, Milind Khare (with further assistance from Jamie Jason).
[H.323]ITU-T SG16 H.323，英特尔白皮书，“H.323和防火墙”，Dave Chouinard，John Richardson，Milind Khare（由Jamie Jason进一步协助）。
[SNMP-ALG] Raz, D., Schoenwaelder, J. and B. Sugla, "An SNMP Application Level Gateway for Payload Address Translation", RFC 2962, October 2000.
[SNMP-ALG]Raz，D.，Schoenwaeld，J.和B.Sugla，“用于有效负载地址转换的SNMP应用程序级网关”，RFC 29622000年10月。
[SNMP-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999.
[SNMP-APPL]Levi，D.，Meyer，P.和B.Stewart，“SNMP应用”，RFC 25731999年4月。
[NAT-ARCH] Hain, T. "Architectural Implications of NAT", RFC 2993, November 2000.
[NAT-ARCH]Hain，T.“NAT的建筑含义”，RFC 29932000年11月。
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STDl 10, RFC 821, August 1982.
[SMTP]Postel，J.，“简单邮件传输协议”，STDl 10，RFC 821，1982年8月。
[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.
[FTP]Postel，J.和J.Reynolds，“文件传输协议（FTP）”，STD 9，RFC 959，1985年10月。
[SIP] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[SIP]Handley，M.，Schulzrinne，H.，Schooler，E.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
[X Windows] Scheifler, B., "FYI on the X Window System", FYI 6, RFC 1198, January 1991.
[X Windows]Scheifler，B.，“X窗口系统上的FYI”，FYI 6，RFC 1198，1991年1月。
[RSVP] Braden, R., Zhang. L., Berson. S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RSVP]布拉登，R.，张。L.，贝尔森。S.，Herzog，S.和S.Jamin，“资源预留协议（RSVP）——第1版功能规范”，RFC 2205，1997年9月。
[DNS-TERMS] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[DNS-TERMS]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[DNS-IMPL] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[DNS-IMPL]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.
[DNS-ALG]Srisuresh，P.，Tsirtsis，G.，Akkiraju，P.和A.Heffernan，“网络地址转换器的DNS扩展（DNS_ALG）”，RFC 26941999年9月。
[IPsec] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[IPsec]Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[IPsec ESP]Kent，S.和R.Atkinson，“IP封装安全有效负载（ESP）”，RFC 2406，1998年11月。
[IPsec-AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[IPsec AH]Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[IPsec-DOCS] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[IPsec文档]Thayer，R.，Doraswamy，N.和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[NAT-SEC] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999.
[NAT-SEC]Srisuresh，P.，“NAT域的隧道模式IPsec安全模型”，RFC 2709，1999年10月。
[PRIV-ADDR] Rekhter, Y., Moskowitz, B., Karrenberg, D., G. de Groot, and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[PRIV-ADDR]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，G.de Groot和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[ADDR-BEHA] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
[ADDR-BEHA]Carpenter，B.，Crowcroft，J.和Y.Rekhter，“今天的IPv4地址行为”，RFC 21011997年2月。
Authors' Addresses
作者地址
Matt Holdrege ipVerse 223 Ximeno Ave. Long Beach, CA 90803
Matt Holdrege ipVerse加利福尼亚州长滩西门诺大道223号，邮编90803
EMail: matt@ipverse.com
EMail: matt@ipverse.com
Pyda Srisuresh Jasmine Networks, Inc. 3061 Zanker Road, Suite B San Jose, CA 95134 U.S.A.
美国加利福尼亚州圣何塞市赞克路3061号B套房Pyda Srisuresh Jasmine Networks，Inc.邮编：95134。
Phone: (408) 895-5032 EMail: srisuresh@yahoo.com
电话：（408）895-5032电子邮件：srisuresh@yahoo.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
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编辑功能的资金目前由互联网协会提供。