正文共：7777 字 5 图，预估阅读时间：7 分钟
RFC3027：Protocol Complications with the IP Network Address Translator，January 2001这份备忘录为互联网社区提供了信息。它没有指定任何类型的互联网标准。这份备忘录的分发是无限的。
版权所有（C）互联网协会（2001）。保留所有权利。
当终端节点不在同一地址域中，并在桥接域的过程中寻求IP网络地址转换器（Network Address Translator，NAT）的帮助时，许多互联网应用程序可能会受到不利影响。NAT设备本身无法在所有情况下提供必要的应用程序/协议透明度，并在可能的情况下寻求应用层网关（Application Level Gateways，ALG）的帮助以提供透明度。本文档的目的是确定在途中突破NAT的协议和应用程序。该文档还试图确定任何已知的解决方法。不可能在单个文档中捕获所有突破NAT的应用程序。本文试图捕捉尽可能多的信息，但绝不是全面的报道。我们希望报道能为未涵盖的应用程序提供足够的线索。
本文档要求读者熟悉[NAT-TERM]中描述的NAT设备的术语和功能。简而言之，NAT试图为需要与不同地址域通信的终端主机提供透明的路由解决方案。NAT在路由过程中修改终端节点地址（在数据包的IP报文头内），并维护这些更新的状态，以便将与会话相关的数据包透明地路由到任一领域中的正确终端节点。在可能的情况下，特定于应用程序的ALG可以与NAT结合使用，以提供应用程序级的透明度。与NAT不同，ALG的功能是特定于应用程序的，可能需要检查和重组IP有效载荷。
以下部分试图列出已知在途中受到NAT设备影响的应用程序。然而，这绝不是所有已知的NAT复杂协议和应用程序的完整列表，而只是作者收集的列表的一个子集。同样重要的是要注意，本文档并非旨在倡导NAT，而是指出NAT设备在传输过程中协议和应用程序的复杂性。
[NAT-TERM]和[NAT-TRAD]（传统 IP 网络地址转换（传统 NAT））有部分列出了NAT设备的问题和限制的具体性质。本节将重申其中一些限制，以总结NAT破坏的协议的特征。
当IP数据包在有效载荷中包含特定领域的IP地址或端口信息时，许多应用程序在NAT过程中会失败。在某些情况下，ALG可能能够提供变通方法。但是，如果数据包有效载荷是IPsec保护的（或通过传输或应用程序级安全机制保护的），则应用程序必然会失败。
使用控制连接建立数据流的捆绑会话应用程序，如FTP、H.323、SIP和RTSP，通常也会在途中被NAT设备破坏。这是因为这些应用程序在控制会话内交换地址和端口参数，以建立数据会话和会话方向。NAT无法知道捆绑会话的相互依赖性，并将每个会话视为彼此无关。在这种情况下，应用程序可能会因各种原因而失败。失败的两个最可能的原因是：（a）控制有效载荷中的寻址信息是特定于领域的，一旦数据包穿过发起领域就无效，（b）控制会话允许数据会话以NAT可能不允许的方向发起。
当DNS名称用于控制有效载荷时，如果NAT与数据会话方向没有冲突，NAT设备与DNS-ALG结合可能能够提供必要的应用程序级透明度。然而，对于许多此类应用程序（例如FTP）来说，使用DNS名称代替特定领域的IP地址可能不是一种选择。
当在有效载荷中指定了特定于领域的寻址，并且有效载荷未加密时，ALG在某些情况下可能能够提供必要的解决方案，使应用程序在各个领域透明运行。ALG的复杂性取决于处理有效载荷和维护状态所需的应用程序级知识。
点对点应用程序比基于客户端-服务器的应用程序更有可能在NAT过程中中断。与客户端-服务器应用程序不同，点到点应用程序可以由任何对等方发起。当对等体分布在私有和公共领域时，来自外部领域的会话与来自私有领域中主机的会话一样有可能。外部对等体只有在提前知道外部分配的IP地址或FQDN时，才能在私有领域中定位其对等体。只有当途中NAT设备支持DNS-ALG时，才能进行FQDN名称到分配地址的映射。点到点应用程序的示例包括交互式游戏、互联网电话和基于事件的协议（如即时消息）。
这在传统NAT中尤其是一个问题，在双向NAT中可能不是问题，双向NAT允许双向会话。
针对传统NAT的这类问题，一种可能的解决方案是让私有主机与作为其代表的服务器保持出站连接，以访问全球路由的互联网。
NAPT的IP分片化在任何单个应用程序中都不是问题，而是渗透到所有TCP/UDP应用程序中。该问题在[NAT-TRAD]中有详细描述。简而言之，问题如下。比如说，两个私有主机向同一个目标主机发送了分片化的TCP/UDP数据包。而且，它们碰巧使用了相同的分片标识符。当目标主机从同一分配的主机地址接收到携带相同分片id的两个不相关的数据包时，目标主机无法确定数据包属于两个会话中的哪一个。因此，两个会话都将被损坏。
NAT很可能会破坏需要在连续会话中保留地址映射的应用程序。这些应用程序要求在会话之间保留私有到外部的地址映射，以便在后续的会话交互中可以重用相同的外部地址。NAT无法知道这一要求，可能会在会话之间将外部地址重新分配给不同的主机。
试图防止NAT丢弃地址映射将需要应用程序的NAT扩展协议，该协议将允许应用程序通知NAT设备保留映射。或者，可能需要ALG与NAT交互，以防止地址映射被NAT丢弃。
当私有主机的数量大于可用于将私有地址映射到的外部地址时，这是一个问题。以NAPT支持的私有领域中的主机启动的rlogin服务为例。Rlogin服务客户端使用众所周知的Rlogin端口512作为其TCP端口ID。私有领域中只有一个主机可以启动该服务。这是一个试图使用从根本上需要比可用地址更多的公共地址的服务的案例。NAT设备可以保存地址，但不能创建更多地址。
NAT基本上是通过修改路由中的终端节点地址（在IP报文头内）来操作的。另一方面，IPsec AH标准[IPsec AH]（AH：RFC2402-IP Authentication Header）明确设计用于检测IP数据包报文头的更改。因此，当NAT更改IP报文头中的地址信息时，接收更改后的数据包的目标主机将使数据包无效，因为报文头的内容已被更改。因此，穿越NAT的IPsec AH保护数据包将无法到达目标应用程序。
IPsec ESP（[IPsec ESP]）（ESP：RFC2406-IP Encapsulating Security Payload）加密的数据包可能仅在有限的情况下被NAT设备在途中更改。对于TCP/UDP数据包，当IP报文头中的地址发生变化时，NAT需要更新TCP/UDP报文头中的校验和。但是，由于TCP/UDP标头由ESP加密，NAT将无法进行此校验和更新。因此，在传输模式ESP中加密的TCP/UDP数据包在穿越NAT设备时，将无法在接收端通过TCP/UDP校验和验证，并且根本无法到达目标应用程序。
互联网密钥交换协议IKE可能会在主模式、野蛮模式和快速模式下将IP地址作为节点标识符传递。为了使IKE协商正确通过NAT，需要修改这些有效载荷。然而，这些有效载荷通常受到哈希的保护或被加密所掩盖。即使在IKE有效载荷中不使用IP地址并且IKE协商可能不间断发生的情况下，从IKE完成协商到IPsec在应用程序上使用密钥，在NAT上保留私有到外部地址映射也存在困难。最后，如前所述，端到端IPsec的使用无论如何都会受到严重阻碍（IPsec：RFC2401-互联网协议的安全架构）。
出于所有实际目的，端到端IPsec不可能在NAT过程中实现。
Kerberos 4票证已加密。因此，无法编写ALG。当KDC收到票证请求时，它会在返回的票证中包含源IP地址。并非所有Kerberos 4服务都会实际检查源IP地址。AFS是Kerberos 4服务的一个很好的例子，但它不是。不检查的服务在途中对NAT设备并不挑剔。Kerberos票证与请求票证的IP地址和使用票证的服务相关联。
K4票证（响应）包含一个IP地址，描述了客户端从KDC的角度从TGT检索票证所使用的接口。如果KDC跨NAT网关，并且只要所有Kerberos服务也跨NAT网关即可。专用网络上的最终用户不会注意到任何问题。
还有一个警告，NAT对客户端和KDC之间的连接使用与客户端和应用服务器之间的连接相同的私有主机地址映射。解决这个问题的一个方法是在整个票证生命周期内保持与远程服务器的任意连接打开，以免NAT丢弃地址绑定。或者，需要部署ALG以确保NAT在票证的生命周期内以及在向私有主机发出票证和私有主机使用票证之间不会更改地址绑定。
但是，该票将在NAPT私有领域内的任何主机上有效。如果没有NAPT，攻击者需要能够欺骗正在进行的连接的源IP地址，以便在不同的主机上使用被盗的票证。使用NAPT，攻击者只需从NAPT的私人领域获得一张票即可。当然，这是假设NAPT私有域不是一个受信任的网络——这并不奇怪，因为许多攻击都发生在组织内部。
与Kerberos 4一样，Kerberos 5票证也是加密的。因此，无法编写ALG。
在Kerberos 5中，客户端指定票证应有效的IP地址列表，或者它可以要求对所有IP地址都有效的票证。通过请求全IP地址票证或包含NAPT设备地址的票证，您可以让krb5与NAPT设备一起工作，尽管它不是很透明（它要求客户端的行为与其他情况不同）。MIT krb5 1.0实现对于客户端请求的IP地址没有任何可配置性（它总是要求提供其接口地址集），并且与NAT的交互不好。MIT krb5 1.1实现允许您在krb5.conf中的某个位置放置“noaddresses”来请求所有IP地址的有效票证。
K5票证（响应）包含客户终端节点请求的IP地址，票证将被视为有效。如果使用Kerberos身份验证访问的服务位于NAT的公共端，则Kerberos身份验证将失败，因为NAT（基本NAT或NAPT）使用的IP地址不在可接受的地址列表中。
Kerberos 5中有两种解决方法，都降低了票证的安全性。第一种方法是让NAPT私有领域中的客户端在票证的IP列表中指定NAPT的公共IP地址。但这导致了与K4相同的安全问题。此外，对于私有域中的客户端来说，要找到NAPT的公共IP地址并不明显。这将改变终端主机上的应用程序行为。
第二种方法是从K5票证中删除所有IP地址，但这会使票证被盗更加严重，因为票证可以在任何地方使用。不仅仅是在专用网络中。
X窗口系统是基于TCP的。然而，与大多数其他应用程序相比，这些应用程序的客户端-服务器关系是相反的。X服务器或Open windows服务器是显示/鼠标/键盘单元（即控制实际windows界面的单元）。客户端是驱动Windows界面的应用程序。
某些计算机在同一台计算机上运行多个X Windows服务器。第一台X Windows服务器位于TCP端口6000。第一个Open Windows服务器可以位于端口6000或端口2000（更灵活）。这里我们将主要参考X窗口系统进行说明。
X-term将IP地址从客户端传输到服务器，以设置DISPLAY变量。设置时，DISPLAY变量用于从主机上的X客户端到工作站上的X服务器的后续连接。DISPLAY变量在TELNET协商期间以内联方式发送，如下所示
DISPLAY=<local-ip-addr>:<server>.<display>其中，通过查看与用于连接到<server>的套接字相关联的本地ip地址来检索<local ip addr>。<server>决定应使用哪个端口（6000+<server>）进行连接<display>用于指示应使用连接到X服务器的监视器，但对于本讨论并不重要。
使用的<local ip addr>不是DNS名称，因为：
a.如果不对本地IP地址执行反向DNS查找，本地计算机将无法知道其DNS名称
b.无法保证反向DNS查找返回的名称确实映射回本地IP地址。
c.最后，如果没有DNSSEC，使用DNS地址可能不安全，因为它们很容易被欺骗。除非禁用DNSSEC，否则NAT和DNS-ALG无法工作。
此应用程序的一个常见用途是人们从家里的X终端拨入公司办公室。例如，X客户端在NAT公共端的主机上运行，X服务器在NAT私有端的主机中运行。DISPLAY变量以某种方式内联传输到X客户端正在运行的主机。传输DISPLAY变量内容的进程不知道NAT的地址。
如果传输DISPLAY变量的信道未加密，NAT设备可能会请求ALG的帮助来替换IP地址，并将有效显示范围内的端口（端口6000及更高）配置为网关。或者，NAT可以被配置为监听传入连接，以提供对X服务器的访问，而不需要ALG。但是，这种方法通过提供对X服务器的访问来增加安全风险，否则这些访问将不可用。由于ALG篡改了IP地址，因此也不可能使用MIT-MAGIC-COKIE-1以外的X授权方法。MIT-MAGIC-COKIE-1是所有记录在案的X授权方法中最不安全的。
当使用START_TLS时，根据证书中提供的信息，NAT可能会导致客户端证书验证问题。
RSH使用多个会话来支持stdout和stderr的单独流。随机端口号从客户端内联传输到服务器，用作stderr端口。stderr套接字是从服务器到客户端的连接。与FTP不同，没有与PASV模式等效的模式。对于传统NAT来说，这是一个问题，因为传统NAT不允许传入会话。
RLOGIN不使用多个会话。但是，由于票证问题和使用多个会话，受Kerberos保护的RSH和RLOGIN版本将无法在NAT环境中工作。
本文档主要解决与传统NAT相关的问题，特别是NAPT。
FTP（FTP：文件传输协议）是一个基于TCP的应用程序，用于在两台主机之间可靠地传输文件。FTP使用捆绑会话方法来实现这一点。
FTP由客户端访问FTP服务器上众所周知的端口号21发起。这被称为FTP控制会话。通常，额外的数据会话伴随着控制会话。默认情况下，数据会话将从服务器上的TCP端口20到用于启动控制会话的TCP端口客户端。然而，在FTP控制会话中，可以使用ASCII编码的PORT和PASV命令和响应来更改数据会话端口。
例如，FTP客户端位于NAT支持的专用网络中。需要FTP ALG来监视FTP控制会话（对于PORT和PASV模式），以识别FTP数据会话端口号，并使用外部有效的地址和端口号修改专用地址和端口编号。此外，必须更新序列号和确认号、TCP校验和、IP数据包长度和校验和。因此，必须调整该流的所有后续数据包中的序列号以及TCP ACK字段和校验和。
在极少数情况下，增加数据包的大小可能会导致其超过给定传输链路的MTU。然后，数据包必须被分段，这可能会影响性能。或者，如果数据包设置了DF位，它将被ICMP拒绝，然后发起主机将不得不执行路径MTU发现。这可能会对性能产生不利影响。
但是请注意，如果控制命令通道是安全的，ALG将无法在命令交换中更新IP地址。
当AUTH与Kerberos 4、Kerberos 5和TLS一起使用时，FTP也会出现与X-Term/Telnet相同的问题。
最后，值得注意的是RFC 2428（IPv6和NAT的FTP扩展）的第4节，该节描述了如何使用新的FTP端口命令（EPSV ALL）来允许NAT设备快速跟踪FTP协议，如果远程服务器接受“EPSV ALL”，则无需通过ALG进一步处理。
RSVP位于传输层的协议栈中，在IP（IPv4或IPv6）之上运行。然而，与其他传输协议不同，RSVP不传输应用程序数据，而是像其他互联网控制协议（例如ICMP、IGMP、路由协议）一样工作。RSVP消息使用协议号46在支持RSVP的路由器之间作为原始IP数据包逐跳发送。其目的是在终端系统和第一（或最后）跳路由器之间使用原始IP数据包。然而，这可能并不总是可能的，因为并非所有系统都能进行原始网络I/O。因此，可以将RSVP消息封装在UDP数据包中，用于端系统通信。UDP封装的RSVP消息被发送到端口1698（如果由端系统发送）或端口1699（如果由支持RSVP的路由器发送）。有关RSVP消息的UDP封装的更多信息；请参阅RFC 2205的附录C。
RSVP会话是一种具有特定目的地和传输层协议的数据流，其定义如下：
目标地址：数据包的目标IP地址。这可能是单播或组播地址。
协议ID：IP协议ID（例如UDP或TCP）。
目标端口：一个通用的目标端口，用于在IP层之上的层进行解复用。
NAT设备在支持RSVP时存在独特的问题。两个问题是：
a.RSVP消息对象可能包含IP地址。结果是，RSVP-ALG必须能够根据消息的方向和类型替换IP地址。例如，如果外部发送者要向内部接收者发送RSVP Path消息，RSVP会话将指定外部发送者认为是内部接收者的IP地址的IP地址。然而，当RSVP Path消息到达NAT设备时，必须更改RSVP会话以反映接收器内部使用的IP地址。必须对所有包含IP地址的消息对象采取类似的操作。
b.RSVP提供了一种方法，即RSVP Integrity对象，来保证RSVP消息的完整性。问题是，由于第一点，NAT设备必须能够更改RSVP消息中的IP地址。但是，当完成此操作时，由于RSVP消息已更改，RSVP Integrity对象不再有效。因此，当使用RSVP完整性对象时，RSVP-ALG将无法工作。
DNS（主机名/域名服务器）是一种基于TCP/UDP的协议。对于在NAT私有域中使用本地DNS服务器的主机来说，域名是一个问题。应在私有域内的权威名称服务器上配置私有域中主机的DNS名称到地址映射。外部和内部主机都可以访问此服务器进行名称解析。DNS-ALG需要对DNS查询和响应执行地址到名称的转换。[DNS-ALG]详细描述了DNS-ALG。如果DNS数据包按照DNSSEC进行加密/身份验证，则DNS_ALG将失败，因为它将无法执行有效载荷修改。
使用DNS解析器将DNS名称解析为IP地址的应用程序假定地址分配可用，以供特定于应用程序的会话重用。因此，DNS-ALG将需要在DNS查询之后的预配置时间内保持地址分配（在私有地址和外部地址之间）的有效性。
或者，如果不需要私有域中的名称服务器，私有域主机可以简单地指向外部名称服务器进行外部名称查找。当名称服务器位于外部域中时，不需要ALG。
SMTP是一种基于TCP的协议（[SMTP]），由sendmail等互联网电子邮件程序用于将基于TCP的电子邮件发送到众所周知的端口25。邮件服务器可以位于私有域内或私有域外。但是，必须为服务器分配一个可由外部主机访问的全局名称和地址。当邮件服务器位于专用域内时，入站SMTP会话必须从其外部分配的地址重定向到专用主机。当邮件服务器位于外部域中时，不需要特殊的映射。
一般来说，邮件系统被配置为所有用户指定一个集中地址（例如fooboo@company.com)，而不是包括单个主机（例如fooboo@hostA.company.com). 中心地址必须在外部主机可访问的DNS名称服务器中指定MX记录。
在大多数情况下，邮件消息不包含对私有IP地址的引用，也不包含通过外部不可见的名称指向内容数据的链接。但是，某些邮件确实在“已接收：”字段中包含中继邮件的MTA的IP地址。出于调试目的或由于缺少DNS记录，某些邮件在“邮件发件人：”字段中使用IP地址代替FQDN。
如果一个或多个MTA位于私有域中的NAT后面，并且邮件消息没有通过签名或加密密钥进行保护，则可以使用SMTP-ALG来转换MTA注册的IP地址信息。如果MTA具有静态地址映射，则转换将在很长一段时间内跨领域有效。
如果没有ALG，仅通过NAT可能会阻碍或阻止跟踪邮件路由的能力。在调试邮件问题或追踪滥用邮件的用户时，这可能会导致问题。
SIP（参考[SIP]）可以在TCP或UDP上运行，但默认情况下在同一端口5060上运行。
当与UDP一起使用时，对SIP请求的响应不会到达请求来自的源端口。相反，SIP消息包含响应应发送到的端口号。SIP在请求传输的响应中使用ICMP端口不可达错误。请求消息通常在连接的套接字上发送。如果将响应发送到请求中的源端口，则处理请求的每个线程都必须在其发送请求的套接字上进行侦听。但是，通过允许响应到达单个端口，可以使用单个线程进行侦听。
服务器可能更喜欢在消息中放置每个连接的套接字的源端口。然后，每个线程可以分别监听响应。由于响应的端口号可能不会到达请求的源端口，因此SIP通常不会穿越NAT，需要SIP-ALG。
SIP消息携带由MIME类型定义的任意内容。对于多媒体会话，这通常是会话描述协议（SDP RFC 2327）。SDP可以指定用于多媒体交换的IP地址或端口。在穿越NAT时，这些可能会失去意义。因此，SIP-ALG需要智能来破译和翻译领域相关信息。
SIP在其指定信令地址的Contact、To和From字段中携带URL。这些URL的主机端口部分可以包含IP地址或域名。一旦穿越NAT，这些地址或域名可能无效。
作为SIP-ALG的替代方案，SIP支持一个代理服务器，该服务器可以与NAT共存，并在全局重要的NAT端口上运行。这样的代理将具有本地特定的配置。
在默认模式下，RealAudio客户端（例如，在私有域中）访问TCP端口7070，以启动与真实音频服务器（例如，位于外部域中）的对话，并在播放过程中交换控制消息（例如：暂停或停止音频流）。音频会话参数作为字节流嵌入到TCP控制会话中。
实际的音频流量在基于UDP的传入数据包（源自服务器）上以相反的方向传输，这些数据包指向6970-7170范围内的端口。
因此，在传统NAT设备上，RealAudio默认被破坏。解决这个问题的方法是ALG检查TCP流量，以确定音频会话参数，并有选择地为TCP控制会话中商定的端口启用入站UDP会话。或者，ALG可以简单地将所有指向端口6970-7170的入站UDP会话重定向到私有域中的客户端地址。
对于双向NAT，您不需要ALG。双向NAT可以简单地将TCP和UDP会话中的每一个视为2个不相关的会话，并执行IP和TCP/UDP报文头级转换。
读者可以联系RealNetworks，了解如何使他们的应用程序通过NAT和防火墙设备工作的详细指南。
H.323很复杂，使用动态端口，并包含多个UDP流。以下是对相关问题的总结：
H.323呼叫由许多不同的同时连接组成。至少有两个连接是TCP。对于纯音频会议，最多可以建立4个不同的UDP“连接”。
除一个连接外，所有连接都连接到临时（动态）端口。
可以从私有域和外部域发起呼叫。为了使会议有用，外部用户需要能够直接与内部用户的桌面系统建立通话。
地址和端口号在“下一个更高”连接的数据流中交换。例如，H.245连接的端口号是在Q.931数据流中建立的。（这使得ALG特别难以修改这些数据流中的地址。）更糟糕的是，例如，在Q.931中，可以指定H.245连接应该是安全的（加密的）。如果会话是加密的，则ALG不可能解密数据流，除非它可以访问共享密钥。
大多数控制信息在ASN.1中编码（只有Q.931协议数据单元或PDU中的用户用户信息是ASN.1编码的（每个Q.931 PDU的其他部分没有编码）。对于那些不熟悉ASN.1的人来说，只需说这是一个复杂的编码方案，它最终不会为地址信息带来固定的字节偏移。事实上，连接到同一目的地的同一应用程序的同一版本可能会协商包含不同的选项，从而改变字节偏移量。
下面是用户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地址。
还要注意，如果H.323网关位于NAT边界内，ALG必须了解各种网关发现方案，并适应这些方案。或者，如果只有H.323主机/终端在NAT边界内并试图向网守注册，则注册消息中的IP信息必须由NAT转换。
SNMP是一种基于UDP的网络管理协议。SNMP有效载荷可能包含IP地址，也可能通过索引将IP地址引用到表中。因此，当专用网络内的设备由外部节点管理时，通过NAT设备的SNMP数据包可能包含与外部域无关的信息。在某些情况下，如[SNMP-ALG]所述，SNMP ALG可用于将特定领域的地址透明地转换为全局唯一的地址。这种ALG假设静态地址映射和双向NAT。它只能适用于SNMP-ALG实现所理解的数据类型集（文本约定）和给定的MIB模块集。此外，替换SNMP有效载荷中的IP地址可能会导致通信失败，原因是消息大小的变化或词典排序的变化。
使SNMP ALG对所有管理应用程序完全透明并不是一项可实现的任务。当启用身份验证（以及可选的隐私）时，ALG将遇到SNMPv3安全功能的问题，除非ALG可以访问安全密钥。[NAT-ARCH]还暗示了通过NAT进行SNMP管理的潜在问题。
或者，[SNMP-APPL]中定义的SNMP代理可以与NAT结合使用，将SNMP消息转发到外部SNMP引擎（反之亦然）。SNMP代理根据私有域上下文进行定制，因此可以独立于所访问的特定托管对象类型进行操作。代理解决方案将要求外部管理应用程序了解代理转发器，并且需要配置正在管理的各个节点，以将其SNMP流量（通知和请求）定向到代理转发器。
Activision Games的设计是NAT友好的，这样游戏就不需要ALG来通过传统的NAT设备透明地工作。私有域中的游戏玩家可以与同一域或外部域中的其他玩家一起玩。Activision游戏协议是专有的，基于UDP。地址服务器使用UDP端口号21157，预计位于全局地址域中。
游戏玩家首先连接到地址服务器，并在初始连接消息中发送他们的私有IP地址信息（如私有IP地址和UDP端口号）。服务器从连接消息中记录私有地址信息，从IP和UDP标头中记录外部地址信息。然后，服务器将游戏玩家的私有和外部地址信息发送给所有其他对等玩家。此时，每个游戏玩家都知道其他对等方的私有和公共地址信息。在此之后，每个客户端都会打开彼此之间的对称直接连接，并使用首先工作的地址（私有或外部）。
现在，客户端可以直接与其他客户端进行会话（或者）他们可以通过游戏服务器与其他客户端会话。关键是允许重用用于与游戏服务器初始连接的相同（全局地址，分配的UDP端口）元组，以用于与客户端的所有后续连接。游戏玩家被所有其他对等玩家识别为（私有地址，UDP端口）或（全局地址，分配的UDP端口）之一。因此，只要游戏玩家正在与一个或多个其他玩家进行会话，NAT上元组之间的绑定就应该保持不变。
从私有主机打开与外部领域中的游戏服务器的连接是没有问题的。NAT所要做的就是提供路由透明性，并保留相同的私有到外部地址绑定，只要与外部节点至少有一个游戏会话。但是，NAPT配置必须允许在同一分配的全局地址/端口上同时进行多个UDP连接。
上述方法存在一些问题。例如，客户端可以尝试联系一个私人地址，但当该私人地址位于其他领域时，该私人地址可能正在本地使用。如果被错误联系的节点有其他服务或没有为UDP端口注册服务，则Activision连接消息预计会被删除。在不太可能的情况下，注册的应用程序选择解释消息，结果可能是不可预测的。
读者可以参考Activision了解有关此协议功能和设计的专有详细信息。
作者衷心感谢Bernard Aboba、Bill Sommerfield、Dave Cridland、Greg Hudson、Henning Schulzline、Jeffrey Altman、Keith Moore、Thomas Narten、Vernon Shriver和其他为编写本文件提供宝贵意见的人。特别感谢Dan Kegel分享Activision游戏的设计方法。
[NAT-TERM]中概述的安全考虑与所有NAT设备相关。本文档不需要额外的安全考虑。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.[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).[SNMP-ALG] Raz, D., Schoenwaelder, J. and B. Sugla, "An SNMP Application Level Gateway for Payload Address Translation", RFC 2962, October 2000.[SNMP-APPL] Levi, D., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999.[NAT-ARCH] Hain, T. "Architectural Implications of NAT", RFC 2993, November 2000.[SMTP] Postel, J., "Simple Mail Transfer Protocol", STDl 10, RFC 821, August 1982.[FTP] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)", STD 9, RFC 959, October 1985.[SIP] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.[X Windows] Scheifler, B., "FYI on the X Window System", FYI 6, RFC 1198, January 1991.[RSVP] Braden, R., Zhang. L., Berson. S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.[DNS-TERMS] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.[DNS-IMPL] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.[DNS-ALG] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999.[IPsec] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.[IPsec-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.[IPsec-AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.[IPsec-DOCS] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.[NAT-SEC] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT Domains", RFC 2709, October 1999.[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.[ADDR-BEHA] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, February 1997.
版权所有（C）互联网协会（2001）。保留所有权利。
本文件及其翻译可复制并提供给他人，对其进行评论或以其他方式解释或协助其实施的衍生作品可全部或部分制作、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权声明或对互联网协会或其他互联网组织的引用，除非是为了制定互联网标准而需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或者需要将其翻译成英语以外的语言。
上述授予的有限权限是永久性的，互联网协会或其继承人或受让人不会撤销。
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于使用本文件中的信息不会侵犯任何权利或对适销性或特定用途适用性的任何暗示保证。
RFC编辑器功能的资金目前由互联网协会提供。
长按二维码
关注我们吧
