组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：spacelu（spacelu&nbsp;&nbsp;wuchun_lu@china.com）<br />
译文发布时间：2001-5-11<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
<br />
Network&nbsp;Working&nbsp;Group&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;P.&nbsp;Srisuresh<br />
Request&nbsp;for&nbsp;Comments:&nbsp;3022&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Jasmine&nbsp;Networks<br />
Obsoletes:&nbsp;1631&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;K.&nbsp;Egevang<br />
Category:&nbsp;Informational&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Intel&nbsp;Corporation<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;January&nbsp;2001<br />
<br />
<br />
传统IP网络地址转换（传统NAT）<br />
(RFC3022&nbsp;Traditional&nbsp;IP&nbsp;Network&nbsp;Address&nbsp;Translator&nbsp;(Traditional&nbsp;NAT))<br />
<br />
备忘录状态<br />
&nbsp;&nbsp;&nbsp;这个备忘录为因特网社区提供信息。它没有详细说明任何一种网络标准。这个备忘录的<br />
发布没有限制。<br />
<br />
版权声明<br />
版权属于因特网社会（2001）。保留所有权利。<br />
<br />
<br />
前言<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;在这个文档中描述的IP地址转换操作扩展了RFC1631介绍的地址转换和包括了一类<br />
的网络地址和TCP/UDP端口转换。另外，这个文档更正了RFC1631的校验适用算法和试图<br />
详细讨论NAT操作和限制。<br />
摘要：<br />
基于基本NAT的基本网络地址转换是IP地址从一个组到另外一个组映射的一种方式，<br />
对终端用户是透明的。网络地址端口转换或NAPT是很多网络地址和它们的TCP/UDP（传<br />
输控制协议/用户数据报协议）端口转换成一个唯一的网络地址和它的TCP/UDP端口。同时，<br />
参考传统NAT这两个操作提供一种机制，这种机制用全球唯一注册地址连接私人地址领域<br />
到外部领域。<br />
1．	介绍<br />
IP地址转换的需要的提出是因为一个网络的IP内部地址不能用在外部网不论是因为人<br />
原因还是因为它们在外部网不合法。在一个局域网的网络拓补学可以用很多方式改变，顾客<br />
可以改变他们的提供商，公司骨干可能重组或则提供商可能合并或分裂。不论外部网随着时<br />
间何时改变，局域网所在的节点被附以的地址肯定随着外部网的改变而改变。用户可能在这<br />
种方式的改变被隐藏在区域里，因为集中改变到单一地址转换路由器中。<br />
基本地址转换将（在很多情况下，除了[NAT-TERM]和这个文档第6部分所有指的）允<br />
许在局域网中的主机可以透明的连接外部网和可以连接外部网中可选的主机。网络组织<br />
的建立首先是为了局域网内部的应用，还有和广域网的连接需要是这个规划的很好候补。<br />
许多小公司，家庭办公室（SOHO）用户和电信员工在它们的办公室有多个网络节点运<br />
行TCP/UDP应用程序，但是服务提供商只有给他们在远程连通路由提供唯一的IP地址。<br />
这个远程连接用户渐增的社区将从NAPT中获得好处，NAPT将允许在局域网中有多个<br />
节点同时用路由器附以的唯一IP地址连接远程网络。<br />
用这种方式有许多局限性。属于一个会议的所有请求和应答强制路游通过相同的<br />
NAT路由器。一种确认的方式将是有一个基于唯一残缺网段路由的NAT，在那所有的IP<br />
包或者从那个起始或者以那个为目的地。还有其他方法用多NAT设备来确保这个规则。<br />
例如，一个单一能够拥有两个不同的出口到不同的提供者和局部网络的主机之间的会议<br />
能够穿过NAT设备到达外部主机的最好途径。当一个NAT路由器不正常&nbsp;，其他的路由<br />
器能够路由所有连接。但是在这中方法下有可能有一个警告，因为再次路由的流量可能<br />
在新的NAT路由交换时间里交换失败。一种解决这个问题的方法是路由器共享相同的<br />
NAT配置和交换状态信息一保证互相失败备份。<br />
&nbsp;&nbsp;&nbsp;地址转换是独立的应用，经常伴随特殊应用网关（ALOGS）执行有效负荷检测<br />
和变换。FTP是NAT设备里最常用ALG功能。要求ALG干涉的应用一定不能有他们自<br />
己的有效负荷编码，因为那样可能影响到使ALG失笑，直到ALG有解密有效负荷的主<br />
键。<br />
&nbsp;&nbsp;&nbsp;这个方法有个缺陷是取消了IP地址点对点的意义，和在网络中用增加的状态来<br />
补偿。总之，通过IPSec保证的点对点IP网络层安全不能适用于终端主机，如果有NAT<br />
设备路由。但是，这个方法的优点是它在不需要变换主机和路由器的情况下安装。<br />
在这篇文章里一些概念的定义例如“地址域”，“透明路由”，“TV端口”，“ALG”<br />
和其它概念可以在NAT-TERM里找到。<br />
2．	传统NAT概述：<br />
&nbsp;&nbsp;&nbsp;在这个文档里描述的地址转换操作是根据“传统NAT”。其它的NAT在这个文档里<br />
没有给以描述。在大部分情况下，传统NAT允许在局域网的主机透明的和外部主机连接。<br />
在传统NAT中，从局域网到广域网方式是单一方向的。相反方向的两个任务可能允许预<br />
选择主机状态地址影射的异常。基本NAT和NAPT是不同的两种传统NAT，因为基本<br />
NAT地址转换只是限于IP地址，然而NAPT的地址转换包括IP地址转换和传输认证（例<br />
如TCP/UDP端口或ICMP询问ID）。<br />
&nbsp;&nbsp;除了提到的那些外，贯穿这篇文章的地址转换或NAT属于传统NAT，也就是基本NAT<br />
和NAPT。只有如底下图一中所描述的残段网可能配置成执行地址转换。<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
2.1基本NAT的概述：<br />
基本NAT的操作如下。拥有一系列IP地址的残域能够和外部网络通讯，通过映射<br />
本地地址成全球统一地址。如果本地节点数量等于或小于有效通用地址的数量，每个本<br />
地地址都能保证映射到。另外，能够多个出口到广域网的节点数受通用地址的数量限制。<br />
单一本地地址应该映射成一个专门的全球通用地址来保证连通外部或者通过一个公共地<br />
址来与外部连接。多路同时任务可以从一个本地节点进行初始化，用相同的地址映射。<br />
在一个残域里的地址只是在本地有效而在此域外却是无效的。但是，在一个残域里<br />
的地址可以被任何其他的残域从新使用。例如，一个单一类A地址能够被许多残域地址<br />
所使用。在每一个残域和主干网的出口点安装NAT。如果有多个出口，每个出口应该有<br />
相同的转换表。<br />
例如，如图2，残域A和B内部都用类A地址段10.0.0.0/8[RFC1918]。残域A的<br />
NAT附议C类地址段198.76.29.0/24，而残域B的NAT附议C类地址段198.76.28.0/24。<br />
C类地址是全球通用的唯一地址，其他NAT都不能用它们。<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
当残域A主机10.33.96.5试图发送一个包到残域B主机10.81.13.22时，用全球通用地址<br />
198.76.28.4作为目标主机地址，然后送包到第一个路由器。残域路由器对网络198.76.28.4<br />
有一个静态所以包可以继续往前到广域网路由器。但是，NAT在包被继续向前送之前转<br />
换源地址10.33.96.5成198.76.29.7。相应的，IP包往回传时依据相同的地址转换。<br />
&nbsp;&nbsp;&nbsp;需要注意的是主机或路由器不要改变。例如，针对残域A主机，198.76.28.4是残域B<br />
中的地址。在绝大多数情况下，地址转换对目标主机是通明的。当然，这个只是一个简<br />
单的例子。还有很多问题待解决。<br />
2.2&nbsp;NAPT概述：<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;有一种说法，一个组织有一个局域网和一个广域网连接到服务提供商。局域网络的<br />
残域路由器附议在广域网连接中的有效地址而此组织中剩余的节点拥有只是在本地有效<br />
的IP地址。在这种情况下，局域网的多个节点允许多个连接到广域网，在NAPT的帮助<br />
下用登记的唯一IP地址。NAPT允许映射两个类型（登记IP地址，TV端口数）到两个<br />
类型（&nbsp;&nbsp;登记IP地址，TV端口数）。这种模型符合大部分小公司家庭公司（SOHO）团<br />
体用服务提供商提供的登记IP地址连接广域网的要求。这个模型能够扩展趁允许内部连<br />
接通过映射登记IP地址的每一个服务TV端口的本地节点。<br />
&nbsp;&nbsp;&nbsp;在下面的图3中，残域A内部用A类地址段10.0.0.0/8。残域路由器接口被服务提供<br />
商附以IP地址138.76.28.4.<br />
&nbsp;&nbsp;&nbsp;当残域A主机10.0.0.10发送一个远程登陆包到主机138.76.29.7,用全球通用地址<br />
138.76.29.7作为目标地址，然后送包到第一个路由器。残域路由器有一个子网<br />
138.76.0.0/16静态路由，所以包可以继续往前传送到广域网。但是，在包被网前传之前，<br />
NAPT&nbsp;转换IP和TCP包头里源地址10.0.0.10和源TCP端口3017成通用唯一地址<br />
138.76.28.4和唯一TCP端口。在往回传的包经过同样的地址和TCP端口转换。和上边<br />
一样，我们必修注意，这个转换不需要改变主机或路由器。这个转换是完全透明的。<br />
	&nbsp;&nbsp;&nbsp;&nbsp;在这个设置中，只有TCP/UDP任务允许且必须从本地局域网中初始化。但是，有<br />
些服务例如DNS要求内部访问。还有其它服务一个组织想允许内部任务访问。在路由器<br />
上，静态配置一个残域网众所周知的端口是可能的[RFC&nbsp;1700]，可以直接连向专门的<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
局域网节点。<br />
&nbsp;&nbsp;&nbsp;除了重定向信息类型，TCP/UDP任务和ICMP信息都可以通过NAPT路由器来控制。<br />
ICMP查询类型包和TCP/UDP包的转换类型一样，在于ICMP包头的标志域一对一地和<br />
登记IP地址的查询标志对应。在ICMP查询信息中的标志域由发送者设置并且从查询问<br />
答端毫无改变的反馈。所以，一对地址（本地IP地址，本地ICMP查询标志）通过NAPT<br />
路由器映射成一对（登记IP地址，附议的ICMP查询标志），这个过程保证从任何本地<br />
主机来的任何类型有唯一的标志。ICMP错误信息的更改在以后的章节中给以讨论，包<br />
括ICMP有效负荷的改变和IP和ICMP报头。<br />
&nbsp;&nbsp;&nbsp;在NAPT设置中，任何登记IP地址和残域网路由器的广域网接口的IP地址一样的地<br />
方，路由器必须保证区分发生于自己的TCP，UDP或ICMP查询任务&nbsp;和那些发生于局<br />
域网节点的任务。所有内部任务（包括TCP，UDP和ICMP查询任务）被假设为直接到<br />
NAT路由器作为终节点，除非目标服务端口静态映射于局域网中的不同节点。<br />
&nbsp;&nbsp;&nbsp;除了TCP，UDP和ICMP查询类型的任务不允许从本地节点由NAPT路由器传输。<br />
3.0&nbsp;任务传输过程<br />
传统NAT的传输过程和[NAT-TERM]中描述的一样。下面的部分说明和传统NAT<br />
的特殊的内容。<br />
3.1&nbsp;地址绑定：<br />
&nbsp;&nbsp;&nbsp;用基本NAT，当第一个外传任务从私有主机初始化时，一个内部私有地址绑定一个<br />
外部地址。后来，所有其它的外传任务从相同的私有地址初始化将用相同的地址绑定来<br />
传输包数据。<br />
&nbsp;&nbsp;&nbsp;对NAPT而言，在许多私有地址映射一个全球唯一地址时，绑定是从成对地址（私<br />
有IP地址，私有TV端口）到另外一对地址（指派地址，指派TV端口）。和基本NAT<br />
一样，绑定是在第一个外传任务有一对地址（私有IP地址，私有TV端口）发动时决定<br />
的。由于不是一个普通实践，有可能同时多个任务初始化一对相同地址（私有地址，私<br />
有端口）在一个私有主机中建立是可能的。在这种情况下，一对地址（私有地址，私有<br />
TV端口）的一个唯一绑定可能用于所有从相同地址主机中的任务传送的包。<br />
3.2&nbsp;地址查询和转换：<br />
在一个地址绑定或地址对绑定（假设NAPT以建立），一个软状态将用绑定来维持<br />
任何连接。属于相同任务的包将服从转换目的的任务查询。转换的确切属性将在接下去<br />
的章节中进行讨论。<br />
3．3	解开地址<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;当基于单个地址或成对地址绑定的最后一个任务终止时，绑定自己将终止。<br />
4.0&nbsp;包传输<br />
属于NAT管理任务的包经历任何方向的转换。对立包数据任务在接下去进行详细的描<br />
述。<br />
4.1	IP，TCP，UDP&nbsp;和ICMP报头操作：<br />
&nbsp;&nbsp;&nbsp;在基本NAT模型，每个包的IP头必须改变，包括IP地址（外传包的源IP地址，往里<br />
传的目的IP地址）和IP校验和。<br />
&nbsp;&nbsp;&nbsp;对TCP和UDP任务，改变包括TCP和UDP报头的校验和的更正。这是因为TCP/UDP<br />
校验和同时有一个假头包含源和目的IP地址。有一个例外，校验和为0的UDP报头不需要<br />
改变。至于ICMP查询包，由于在ICMP报头中不包含IP地址，所以不需要额外的变化。<br />
&nbsp;&nbsp;&nbsp;在NAPT模型中，IP头的变化和基本NAT中的相同。对TCP/UDP任务，在报头中变化<br />
必须扩展成包含转换TV端口（外传数据的源TV端口和内传的目的TV端口）的转换。在<br />
ICMP查询包中ICMP报头必须改变来代替查询ID和ICMP报头校验和。私有主机查询ID<br />
必须转换成外传的指派ID和内传的相信转换。ICMP报头校验和必须更正来说明查询ID转<br />
换。<br />
4.2	校验和调整<br />
NAT修正以每个包为准的，能够准确计算，因为除了简单域转换外，它们包括一个或多个<br />
校验和修正。幸运的是，我们有一个算法，它能简单有效地调整IP，TCP，UDP和ICMP<br />
报头校验和。因为所有这些报头用一个辅助校验和在转换时计算差距和把它加到校验和是足<br />
够的。下面的算法只有对偶偏移有效（如：下面optr是从报头开始必须是偶偏移）和偶数<br />
长度（如，下面的olen和nlen）。样本代码如下：<br />
&nbsp;&nbsp;<br />
Void&nbsp;checksumadjust(unsigned&nbsp;char&nbsp;*chksum,&nbsp;unsigned&nbsp;char&nbsp;*optr,&nbsp;int&nbsp;olen,&nbsp;<br />
unsigned&nbsp;char&nbsp;*nptr,&nbsp;int&nbsp;nlen)<br />
/assuming:unsigned&nbsp;char&nbsp;is&nbsp;8&nbsp;bits,&nbsp;long&nbsp;is&nbsp;32&nbsp;bits.<br />
-	chksum&nbsp;points&nbsp;to&nbsp;the&nbsp;chksum&nbsp;in&nbsp;the&nbsp;packet<br />
-	optr&nbsp;points&nbsp;to&nbsp;the&nbsp;old&nbsp;data&nbsp;in&nbsp;the&nbsp;packet<br />
-	nptr&nbsp;points&nbsp;to&nbsp;the&nbsp;new&nbsp;data&nbsp;in&nbsp;the&nbsp;packet&nbsp;*/<br />
{<br />
&nbsp;&nbsp;&nbsp;long&nbsp;x,old,new;<br />
x=chksum[0]*256+chksum[1];<br />
x=x&0xFFFF;<br />
while(olen)<br />
{<br />
&nbsp;&nbsp;&nbsp;old&nbsp;=&nbsp;optr[0]*256+optr[1];<br />
optr+=2;<br />
x-=old&oxffff;<br />
if(x&lt;=0&nbsp;){&nbsp;x--;&nbsp;x&=0xffff;}<br />
olen-=2;<br />
}<br />
while(nlen)<br />
{<br />
	new=nptr[0]*256+nptr[1];<br />
	nptr+=2;<br />
	x+=&nbsp;new&&nbsp;0xffff;<br />
&nbsp;	if(x&nbsp;&&nbsp;0x10000){&nbsp;x++;&nbsp;x&=0xffff;}<br />
	nlen-=2;<br />
}<br />
x=x&&nbsp;0xffff;<br />
chksum[0]=x/256;<br />
chksum[1]=x&0xff;<br />
}<br />
4.3&nbsp;ICMP包错误修正：<br />
ICMP错误信息的变化包括在外层的IP和ICMP报头的变化和嵌入在ICMP错误信息有<br />
效负荷报头的改变。<br />
为了使NAT对目的主机是透明的，嵌入在ICMP错误信息里的IP报头里的IP地址必<br />
须改变，嵌入IP报头的校验和域也必须改变，最后ICMP报头校验和也必须随着有效负荷<br />
的变化而变化。<br />
在NAPT设置中，如果嵌入在ICMP里的IP信息和TCP，UDP或ICMP查询包同时发<br />
生，你必须改变在TCP/UDP报头里的相应的TV端口数或ICMP查询报头里的查询标志域。<br />
最后，传输ICMP包的IP头必须改变。<br />
4.3	FTP支持<br />
&nbsp;&nbsp;&nbsp;作为最通用的一种应用之一，FTP要求一个ALG来管理控制任务有效负荷来决定保证数<br />
据传输参数。FTP&nbsp;ALG是大部分NAT执行的一个整数部分。<br />
&nbsp;&nbsp;&nbsp;FTP&nbsp;ALG表需要一个一个专门的表来纠正TCP系列和确认源FTP或目的FTP端口数。<br />
这个表里头应该有源地址，目的地址，源端口，目的端口，系列号和时间戳。新的内容只是<br />
在FTP端口命令或PASV反馈时才增加。对每一个FTP端口命令或PASV反馈系列数有可<br />
能增加或减少。系列数在外传时增加和确认数随往内传时减少。<br />
对任何NAT，FTP有效负荷局限于私有地址和它们指派的外部地址（编码成ASCII码8<br />
进制）。但是对NAPT设置，这个转换必须同时包括TCP端口（ASCII）。<br />
4.5&nbsp;DNS支持；<br />
&nbsp;&nbsp;&nbsp;考虑传统NAT任务主要是从本地外传数据，DNS&nbsp;ALG可能避免和下面的传统NAT相关<br />
使用。在局域网内部的DNS服务器维持内部主机地址或有可能外部主机地址和名字的映射。<br />
外部DNS服务器只是维持外部主机地址和名字的映射，而不对内部主机进行映射。如果一<br />
个局域网没有内部DNS服务器，所有DNS请求直接到外部DNS服务器去找外部主机的映<br />
射。<br />
4.6&nbsp;IP选项处理<br />
一个含有任何IP选项记录路由，严格源路由或松散源路由的IP数据包括记录和使用中<br />
间路由器的IP地址。NAT中间路由器可能不支持这些选项或者处理这些选项时不对地址进<br />
行转换。不对地址进行转换的结果将是在源路由中私有地址一直暴露出来。这个不会危害报<br />
文的传输路径，因为每个路由器只看下一跳的路由器。<br />
5&nbsp;混杂的问题<br />
5.1本地和通用地址的划分<br />
在这个文档里描述的NAT操作，有必要划分IP地址空间为两部分—在内部残域里使用的私<br />
有地址和通用唯一的地址。不论是私有地址还是全球通用地址给定的话，都不能重叠。<br />
交迭的问题为如下。假设在残域A的一个主机试图传送数据报到残域B中的主机，但是残<br />
域B中的全球地址和残域A的私有地址交迭。在这种情况下，在残域A中的路由器不能够<br />
从分辨它自己的私有地址和残域B的全球通用地址。<br />
5.2推荐的私有地址空间<br />
[RFC1918]已经对地址空间的分配作了推荐。因特网授权数量权威（IANA）有3个IP地址<br />
空间块，相应的为：10.0.0.0/8,172.16.0.0/12,和192.168.0.0/16。在pre-CIDR符号中，第一个<br />
为唯一的A类网络块，第二块为有16个相邻的B类网络块，第三块为有256个C类网络<br />
的网络块。一个组织内部需要用如上的IP地址不需要和IANA或因特网注册机构有任何调<br />
和。这些地址空间能够同时被许多对立组织使用，用边界路由器来执行NAT操作。<br />
5.3	NAT上路由<br />
&nbsp;&nbsp;&nbsp;路由器运行NAT不应该用局域网影响到主干网。只有有通用地址的网络才能在残域网外<br />
被识别。但是，NAT从残域边界路由器获得的全球信息能够进入残域。特别的是，NAT残<br />
域路由器有一个静态路由配置来通过广域网连接传送外部流量到服务商路由器，和服务商路<br />
由器有一个静态路由配置在广域网连接来传输NAT报文（如，目标IP地址在NAT管理通<br />
用地址范围列表里）到NAT路由器。<br />
5.4	从基本NAT到NAPT的交换<br />
&nbsp;&nbsp;&nbsp;在基本NAT设置里，当私有节点比通用地址数量多时（也就是说，一个B类私有网络<br />
映射一个C类地址网络块），外面网络连接本地节点有可能突然中断在最后一个通用地址用<br />
完之后。这个是非常不方便和受限制的。这样的情况能够安全的避免通过有选择地允许基本<br />
NAT路由器为在地址表最后一个通用地址交换成NAPT设置。这能保证局域网里主机能够<br />
和外部节点和服务能够在大部分应用中连续的连接。但是记住，如果一些基于基本NAT的<br />
应用由于交换到NAPT突然中断有可能引起混乱。<br />
6.0	NAT局限性<br />
&nbsp;&nbsp;&nbsp;广泛的说，[NAT-TERM]包括所有NAT类型的局限性。下面的部分说明传统NAT的局限<br />
性。<br />
6.1	私有和安全<br />
&nbsp;&nbsp;&nbsp;传统NAT被认为提供一种私有机制，因为任务是从主机出发的单向连接和私有主机地址<br />
的确切地址对外部网络是不可见的。增强私有性的相同特性使调试问题更加困难（包括安全<br />
问题）。如果私有网络里的一个主机用某种方式乱用因特网（例如试图攻击另外一台机器或<br />
甚至发送大的垃圾数据报），那么更加困难追击确实的原因因为主机隐藏在NAT服务器中）。<br />
6．2在局域网中根据映射通用地址NAT的ARP接口<br />
&nbsp;&nbsp;&nbsp;NAT必须只能在边缘路由器或残域中。在这个文档中提供的例子寿命了基本NAT和<br />
NAPT可以从NAT路由器维持一个广域网连接到外部路由器中。（如，服务提供商路由器）。<br />
但是，如果广域网连接由局域网连接代替和如果所有NAT映射的通用地址属于局域网段有<br />
相同的IP子网，NAT路由器将提供属于相同子网的地址范围ARP支持。根据ARP要求NAT<br />
映射通用地址用它自己的MAC地址&nbsp;在基本NAT中是必须的设置。如果一个NAT路由器<br />
不适应这些要求，在网络中没有其它节点拥有这些地址然后没有反映。<br />
&nbsp;&nbsp;&nbsp;这些设想不可能用NAPT设置除了当在NAPT映射中的单个地址不是NAT路由器的接<br />
口地址。（例如，在上面5。4中谈到的从基本NAT到NAPT&nbsp;的交换一样）。用NAT地址映<br />
射直接连接的子网范围内的一个地址可以避免在服务提供商路由器的静态路由设置。<br />
作者的意见是一个局域网连接到服务提供商路由器不是非常普通的。但是，销售商在这种情<br />
况下对支持代理ARP比较感兴趣。<br />
6．3在NAPT设置中外发TCP/UDP数据报的转换<br />
在NAPT设置中外发TCP/UDP数据报的转换（如，那些从私有主机发出的地址）注定要失<br />
败。它的原因如下：只有第一个数据片包含TCP/UDP报头，而这个数据报头对数据报的发<br />
送又是必须的。接下去的片段不包含TCP/UDP端口信息，但是包含其它第一个数据报中包<br />
含的一些标志信息。也就是说，两个私有主机发送TCP/UDP数据报到相同的目的主机。和，<br />
它们用相同的片标志。当目的主机收到这两个没有相关的数据报，它们有相同的片标志，和<br />
相同的指派主机地址，所以不可能决定数据报是属于哪个发送任务。相应的，两个任务同时<br />
崩溃。<br />
7．0&nbsp;当前实现<br />
很多行业应用商业应用，这些商业应用和这个文档中描述的NAT紧密关联。LINUX公众软<br />
件在IP伪装下有NAT。FreeBSD公众软件用NAPT来运行用作邮件收发的后台程序。但是<br />
必须注意，LINUX源程序包含GNU声明，而FreeBSD软件包含UC&nbsp;Berkeley&nbsp;声明。8。0&nbsp;安<br />
全考虑<br />
在{NAT-TERM}描述中的对任何NAT的安全考虑对传统NAT也是适用的。<br />
<br />
参考资料<br />
[NAT-TERM]&nbsp;Srisuresh,&nbsp;P.&nbsp;and&nbsp;M.&nbsp;Holdrege,&nbsp;"IP&nbsp;Network&nbsp;Address<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Translator&nbsp;(NAT)&nbsp;Terminology&nbsp;and&nbsp;Considerations",&nbsp;RFC<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2663,&nbsp;August&nbsp;1999.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1918]&nbsp;Rekhter,&nbsp;Y.,&nbsp;Moskowitz,&nbsp;B.,&nbsp;Karrenberg,&nbsp;D.,&nbsp;de&nbsp;Groot,&nbsp;G.<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and&nbsp;E.&nbsp;Lear,&nbsp;"Address&nbsp;Allocation&nbsp;for&nbsp;Private&nbsp;Internets",<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;BCP&nbsp;5,&nbsp;RFC&nbsp;1918,&nbsp;February&nbsp;1996.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1700]&nbsp;Reynolds,&nbsp;J.&nbsp;and&nbsp;J.&nbsp;Postel,&nbsp;"Assigned&nbsp;Numbers",&nbsp;STD&nbsp;2,&nbsp;RFC<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1700,&nbsp;October&nbsp;1994.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1122]&nbsp;Braden,&nbsp;R.,&nbsp;"Requirements&nbsp;for&nbsp;Internet&nbsp;Hosts&nbsp;--<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Communication&nbsp;Layers",&nbsp;STD&nbsp;3,&nbsp;RFC&nbsp;1122,&nbsp;October&nbsp;1989.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1123]&nbsp;Braden,&nbsp;R.,&nbsp;"Requirements&nbsp;for&nbsp;Internet&nbsp;Hosts&nbsp;--<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Application&nbsp;and&nbsp;Support",&nbsp;STD&nbsp;3,&nbsp;RFC&nbsp;1123,&nbsp;October&nbsp;1989.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1812]&nbsp;Baker,&nbsp;F.,&nbsp;"Requirements&nbsp;for&nbsp;IP&nbsp;Version&nbsp;4&nbsp;Routers",&nbsp;&nbsp;RFC<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1812,&nbsp;June&nbsp;1995.<br />
<br />
&nbsp;&nbsp;&nbsp;[FTP]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Postel,&nbsp;J.&nbsp;and&nbsp;J.&nbsp;Reynolds,&nbsp;"FILE&nbsp;TRANSFER&nbsp;PROTOCOL<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;(FTP)",&nbsp;STD&nbsp;9,&nbsp;RFC&nbsp;959,&nbsp;October&nbsp;1985.<br />
<br />
&nbsp;&nbsp;&nbsp;[TCP]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Defense&nbsp;Advanced&nbsp;Research&nbsp;Projects&nbsp;Agency&nbsp;Information<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Processing&nbsp;Techniques&nbsp;Office,&nbsp;"TRANSMISSION&nbsp;CONTROL<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;PROTOCOL&nbsp;(TCP)&nbsp;SPECIFICATION",&nbsp;STD&nbsp;7,&nbsp;RFC&nbsp;793,&nbsp;September<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1981.<br />
<br />
&nbsp;&nbsp;&nbsp;[ICMP]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Postel,&nbsp;J.,&nbsp;"INTERNET&nbsp;CONTROL&nbsp;MESSAGE&nbsp;(ICMP)<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;SPECIFICATION",&nbsp;STD&nbsp;5,&nbsp;RFC&nbsp;792,&nbsp;September&nbsp;1981.<br />
<br />
&nbsp;&nbsp;&nbsp;[UDP]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Postel,&nbsp;J.,&nbsp;"User&nbsp;Datagram&nbsp;Protocol&nbsp;(UDP)",&nbsp;STD&nbsp;6,&nbsp;RFC<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;768,&nbsp;August&nbsp;1980.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;2101]&nbsp;Carpenter,&nbsp;B.,&nbsp;Crowcroft,&nbsp;J.&nbsp;and&nbsp;Y.&nbsp;Rekhter,&nbsp;"IPv4&nbsp;Address<br />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Behaviour&nbsp;Today",&nbsp;RFC&nbsp;2101,&nbsp;February&nbsp;1997.<br />
RFC3022&nbsp;Traditional&nbsp;IP&nbsp;Network&nbsp;Address&nbsp;Translator&nbsp;(Traditional&nbsp;NAT)&nbsp;&nbsp;&nbsp;传统IP网络地址转换（传统NAT）<br />
<br />
<br />
1<br />
RFC文档中文翻译计划<br />