组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）<br />
E-mail：ouyang@china-pub.com<br />
译者：司亮亮（sihaitian&nbsp;&nbsp;&nbsp;sihaitian@163.net）<br />
译文发布时间：2002-1-18<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;B.&nbsp;Carpenter<br />
Request&nbsp;for&nbsp;Comments:&nbsp;2101&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;J.&nbsp;Crowcroft<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Y.&nbsp;Rekhter<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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;IAB<br />
February&nbsp;1997<br />
<br />
IPv4今日地址行为<br />
（RFC&nbsp;2101——&nbsp;IPv4&nbsp;Address&nbsp;Behaviour&nbsp;Today）<br />
<br />
本备忘录的状态<br />
本备忘录提供Internet通讯所需的信息，它并不指定Internet的某一方面的标准。本备<br />
忘录的发布不受任何限制。<br />
版权声明<br />
&nbsp;&nbsp;&nbsp;Copyright&nbsp;(C)&nbsp;The&nbsp;Internet&nbsp;Society&nbsp;(2001).&nbsp;&nbsp;All&nbsp;Rights&nbsp;Reserved.<br />
摘要<br />
这个注释的主要作用是使网络现有的对32位IPv4地址空间的解释更清楚，自从它最初<br />
被定义后，它的意义已经发生了本质的改变。将有一小节介绍IPv6与IPv4地址的主要的相<br />
似点和不同点。<br />
<br />
目录<br />
1.&nbsp;介绍	2<br />
2.&nbsp;术语	2<br />
3.&nbsp;标准的属性	3<br />
4.&nbsp;纵览IPv4地址空间的现状	3<br />
4.1.&nbsp;地址不再全局唯一定位	4<br />
4.2.&nbsp;地址不再全是临时唯一.	5<br />
4.3.&nbsp;多播和广播.	5<br />
4.4.&nbsp;小结	6<br />
5.&nbsp;IPv6&nbsp;讨论	6<br />
附录：	7<br />
对IPv4地址分配和路由的正确实践。	7<br />
安全性讨论	8<br />
鸣谢	8<br />
参考书	8<br />
作者地址	10<br />
<br />
1.&nbsp;介绍<br />
这个注释的主要作用是使网络现有的对32位IPv4地址空间的解释更清楚，自从它最初<br />
在1981年[RFC&nbsp;791]被定义后，它的意义已经发生了本质的改变。<br />
这个解释将有助于协议设计者，产品制造商，Internet服务提供商和用户站点。它&nbsp;的目<br />
的是随着Internet近几年的成指数级的增长所带来的实质上的改变，避免大家对IP地址的误<br />
解。将有一小节介绍IPv6与IPv4地址的主要的相似点和不同点。<br />
2.&nbsp;术语<br />
在计算机网络中，目录，命名，网络地址和路由的概念是显然不同的，必须被独立的分<br />
析&nbsp;[RFC&nbsp;1498]。然而，“网络地址”（从这里开始缩写为“地址”）的定义可以被细分为至少<br />
两个的观点也是很重要的，命名“标示”和“定位”，在rfc791出版以前这个可能是少为人<br />
知的。<br />
在这篇文档中，术语“主机”指&nbsp;是产生或终止IPv4包的系统，“路由”指的是一些转<br />
发IPv4包从从一个主机或路由到其它主机或路由&nbsp;的系统。<br />
就这篇文档的目的，一个“identifier”是贯穿两个主机之间一次交流会话的整个生存时<br />
间的位串，去标示其中的一个主机就如讨论的另一个一样。一个标示用于验证输入包的源（主<br />
机）对交流的另一方是真正毫无疑问的，例如：在伪TCP&nbsp;头[RFC793]&nbsp;或在IP安全协会<br />
[RFC1825]。习惯上，在每一个数据包中的源IPv4地址中都用于此目的。<br />
注意有时另一个“identifier”的定义被使用。这篇文档不着重讨论。结束点标示符的一<br />
些事情。<br />
就这篇文档而言，“locator”是一个位串，用于确认在什么地方一个特定的包必须不同。<br />
例如：它的服务器在网络拓扑结构中去定位可联结目标主机的位置。习惯上&nbsp;，在每一个数<br />
据包中的IPv4目标地址都用于此用途。IP路由协议说明了&nbsp;IPv4地址作为定位和路由表的<br />
组成是基于那些分配路径的（它们有自己的定位）要求去知道一条通往特定主机定位的路径。<br />
标示和定位都需要唯一性，但彼此的需要是不同的，一般认为标示必须在一系列互相交<br />
流的主机中保持唯一，而定位必须在每一个互相交流的路由（我们叫它路由区域）中保持唯<br />
一。同时定位必须在一个给定的&nbsp;路由区域中保持唯一，这种唯一性（不是可路由性）可以<br />
扩展到更多的区域。这样相对于一系列定位不唯一（复用）的区域，我们更容易区分一系列<br />
唯一定位的区域。<br />
标示和定位都需要生存时间，但它们的需要是不同的。标示必须在两个互相交流的主机<br />
的最大生存时间内有效。定位只要在路由的机械设备需要的时候有效就可以（在一次通讯中<br />
它可以比生存时间短或长一些）。<br />
还有一个历史的偶然的事实必须注意，在RFC&nbsp;791和RFC&nbsp;793中标示和定位在IP头（源<br />
和目的地址）中都用同样的地址空间和字段表示，在传统的Internet主机中，标示可以用定<br />
位来表示，这正如空间的唯一性（单一的）和暂时的唯一性（永恒不变的）。<br />
这些唯一性条件在路由（IPv4的定位可用的基础）和传输协议（一些依赖IP进行连接<br />
的）的设计和假设中起了很大的影响。一个地址的空间唯一性是说它为接口标示和一个主机<br />
的标示服务，就好象关键字对路由表的作用。一个地址的暂时的唯一性是说对于TCP实现<br />
来说不象IP地址一样，需要保持关于远端的状态。所以IP地址可以被用于端到端的IP安<br />
全性和绑定到上层会话。<br />
一般来说，IPv4地址用做定位比用做标示更加重要，无论什么时候，在两种使用之间<br />
发生冲突时，定位的使用是主要的。也就是说，在分发一个数据包时它已经被认为更加有效。<br />
接着该担心提供一个不能被分发的数据包时如何去标示端点。换句话说，在路由协议中这将<br />
是集中工作，在地址习惯用法的其它方面几乎没有什么具体的工作。<br />
3.&nbsp;标准的属性<br />
无论上面提到的什么规范，很容易理解标示和定位的标准的属性。标示应该在一开始就<br />
分配，永不改变，永不被重用。定位用于描述主机在网络拓扑结构上的位置，无论什么时候<br />
都可以随着拓扑的改变而改变。<br />
不幸的是没有一个上述的标准可以在IPv4地址中看到。这篇文档其余部分将对现在流<br />
行的现状做简要介绍。<br />
4.&nbsp;纵览IPv4地址空间的现状<br />
事实上，IPv4地址不再是全局唯一的，也不是都有无限的生存时间。<br />
4.1.&nbsp;地址不再全局唯一定位<br />
RFC&nbsp;1918显示公司的网络是如何工作的，a.k.a.内部局域网，也许适当的重用一个<br />
IPv4地址空间的子集来形成多路由区域是有必要的。在两个（或更多）的路由区域边<br />
界，我们可以找到一个用于使区域之间的交流可用的设备的范围。<br />
在一个范围的结尾是一个纯粹的应用层网关（ALG），这样的设备作为应用层数据<br />
流的端点，对终端用户是可见的。例如：当在路由区域A的终端用户Ua想与在路由区<br />
域B的终端用户Ub交流的时候，Ua首先明确的同A与B&nbsp;之间交流的ALG建立连接，<br />
只有经过这样Ua可以和Ub建立通信。我们称呼这样的网关为“不透明的”ALG.<br />
另一种形式的ALG与终端用户的通讯是透明的。用上面的例子，在一个透明的<br />
ALG，在开始和Ub通信前，Ua将不需要明确的和ALG建立连接。这样将建立对Ua<br />
透明的连接&nbsp;，使的Ua&nbsp;将只可以看到与Ub的连接。<br />
为了完成的目的，注意经过ALG的通讯并不是导致网络头的改变的必要的原因，<br />
一个ALG&nbsp;仅仅用于在一个会话开始时的认证，在离开ALG后，通讯将自然的继续进<br />
行。<br />
不透明和透明的ALG都需要（通过定义）理解应用数据流的对象和语义。从网络<br />
层结构看来，ALG是很简单的，在每一个区域中它们将表现为Internet主机，例如：它<br />
们作为通讯的始端和终端。<br />
在系列的另一方面是关于网络地址转换（NAT）[RFC1631]。在这个文档中我们定<br />
义NAT作为一个设备，它仅仅修改网络层和传输层头，但它不清楚应用层数据流的对<br />
象/语义（用我们的术语也就是描述在RFC1631上的一个同时具有&nbsp;NAT&nbsp;和ALG&nbsp;的功<br />
能设备。）。<br />
作为一个标准，NAT被用在使用私有地址的公司网络&nbsp;[RFC1918]和使用公用地址<br />
的Internet之间，NAT改变发往Internet的数据包的源IPv4地址，也改变来自Internet<br />
的数据包的目&nbsp;的IPv4地址。当一个NAT采用地址复用技术用在互相联络的路由区域<br />
时，例如：在两个内部网的直线连接时，NAT将修改双方的IP头中的地址。既然NAT<br />
修改IP头中的地址，NAT同样也修改传输（例如：TCP,UDP）伪头的效验和。经过观<br />
察可以发现，当互相联络的路由区域采用地址复用时，在网络和传输头的一系列操作被<br />
NAT完成同时做为一个透明的ALG完成在网络层和传输层的一系列操作的子集。<br />
通过定义，NAT不清楚一个应用数据流的对象和语义。因此，NAT&nbsp;不支持在应用<br />
层传输IP地址的应用（例如：FTP&nbsp;的PORT&nbsp;或者PASV&nbsp;命令[RFC&nbsp;959]）。另一方面，<br />
NAT&nbsp;可以支持一些不在应用层传输IP地址的应用。比较而言，&nbsp;ALG只支持应用代码。<br />
可以断定NAT&nbsp;和ALG&nbsp;都有自己的限制，这个可以限制它们的用处，把NAT&nbsp;和<br />
ALG&nbsp;的功能合用在一个简单的设备可以克服一些，但不是全部限制。这个设备可以用<br />
NAT功能进行不传输IP地址的应用，当处理传输IP地址的应用时则依赖ALG功能。<br />
例如：一个这样的设备将用NAT&nbsp;功能去处理FTP数据连接，同时用ALG功能去处理<br />
FTP控制连接。然而，这样一个设备将不能完全处理一个传输IP地址的应用，当设备<br />
不支持经过ALG功能的应用时，宁愿处理它用NAT功能。<br />
通过ALG或NAT的通信也包括改变网络头（特指源和目的地址），同样转换传输<br />
头。既然IP安全认证头假设在网络头的地址是被端到端的预先保留，通过ALG或NAT<br />
我们不清楚在通信的一对主机中该如何支持基于安全的IP认证。既然IP是安全的，当<br />
用于信任时加密端到端的整个传输层，还是不清楚ALG和NAT是如何根据它们的要求<br />
修改加密数据包的。换句话说，在用于认证和信任时，ALG和NAT在两个不同的IP<br />
安全域中&nbsp;都被强制分界，除非设计了用于此目的特殊的增强的&nbsp;IP安全策略。<br />
经过ALG&nbsp;和NAT进行中间连接的路由区域依赖DNS[RFC&nbsp;1035]。特别的，对于<br />
一个给定的（中间连接）路由区域，哪怕在整个系列中网络层地址不再是唯一的，高质<br />
量的域名服务需要唯一性的存在于整个系列中。然而，一个运行NAT&nbsp;和ALG&nbsp;的站点<br />
可能需要两个DNS服务器，一个是NAT&nbsp;或ALG内部的，一个是其外部的，对标示的<br />
查询给出不同的答案。更详细的讨论看[kre]。DNS&nbsp;安全[RFC&nbsp;2065]&nbsp;，同时假设动态<br />
DNS更新[dns2]&nbsp;在NAT/ALG边界不在有效，所以，我们必须假设外部的DNS服务器<br />
通过其它的机器获得了至少一部分的路由表。<br />
作为总结，自从RFC&nbsp;1918，我们还没有真正的改变过地址空间的唯一性，就好象<br />
公认是有多个空间，例如：通过NAT或ALG（看上面的讨论）每个空间一直是个路由<br />
区域比如是个内部网，可能连接到别的内部网，或者是Internet&nbsp;，地址的暂时的唯一性<br />
在RFC1918中仍没有改变。<br />
4.2.&nbsp;地址不再全是临时唯一.<br />
注意，一旦地址的意义在地址空间的某个地方改变，在每个地方都会有一些现象改<br />
变。事实上这个已经发生了。<br />
IPv4地址块是为许多年分配的年代史，例如：在网络拓扑更为有效。这个导致路<br />
由表的持续的增长；难以伸缩。今天阶级路由(CIDR&nbsp;[RFC&nbsp;1518],&nbsp;[RFC&nbsp;1519])作为一个<br />
在路由区域中提高路由的伸缩性的设备。尤其是在Internet中。（附录对CIDR&nbsp;有详细<br />
的解释）。<br />
可伸缩性的CIDR基于地址分配对网络拓扑的最大影响的假设，地址信息集合的边<br />
界不再需要用一个简单的组织填充，--他们可能跨过多个组织（例如：提供者和他的用<br />
户）。因此，如果一个用户改变他的供给者，然后可以避免在Internet路由系统中添加<br />
附加的头，用户需要被重新编号。<br />
改变提供者只是被重新编号的一个可能。信息文档[RFC1900]&nbsp;显示为什么重新编<br />
号是一个不断增长的事件。在DHCP&nbsp;[RFC154]&nbsp;和PPP&nbsp;[RFC]中升级了动态地址分配的<br />
使用。<br />
总而言之，随着DHCP&nbsp;和PPP&nbsp;的发展和进化，而且重新编号好象是将成为一个一<br />
般事件，IP地址的意义已经深深的被改变了。空间&nbsp;的唯一性也将一样，只要地址一直<br />
是有效的定位。不能再保证暂时的的唯一性，它可能非常的短，很有可能比一个TCP<br />
连接时间还短。就这方面看，IP&nbsp;地址不再是一个好的标示。这将对端到端的安全有些<br />
影响，而且将破坏通用的TCP形式。<br />
4.3.&nbsp;多播和广播.<br />
既然我们讨论多播&nbsp;[RFC1112]，我们必须把对&nbsp;IP地址意义的争论转化为对源和目<br />
标地址的意义的思考。一个目的多播地址（例如：一个拓扑中的的扩展到主机组的定位）<br />
可以经过一个NAT，而且它不必限定在一个内部网（或者在公共Internet）。它的生存<br />
时间也很短。<br />
一个&nbsp;广播&nbsp;地址的概念具有语义上定位任何施行相等的功能的一组系统的一个地<br />
址。，它永远不可能作为一个在本文定义的标示来服务，所以它不是唯一的标示主机。<br />
就这一方面来说，暂时的的唯一性，或有用的生存时间对一个IP地址的影响将是比建<br />
立一个TCP连接更短的时间。<br />
在这里，我们已经用TCP简单的描述了一个联合的想法—许多基于应用的UDP&nbsp;<br />
（或在IP&nbsp;之上的别的系统层）在接受或发送第一个数据包以前分配状态，基于源和/<br />
或目标。所有的都被暂时唯一性的存在所影响，而仅仅只有路由结构受空间唯一性改变<br />
的影响。<br />
4.4.&nbsp;小结<br />
网络的经常的重组&nbsp;取决于动态地址的分配和不断的增长，IPv4地址的暂时的唯一<br />
性将不再是全局授权，而只是将他们的使用作为标示放在服务请求中。空间在路由区域<br />
中的唯一性根据内部网的增加来决定不再授权，中间路由区域经过ALG或者NAT而逐<br />
渐完善。在这种规则下，这样的相互连接比直接连接的内部网将有更少的功能。实践中，<br />
功能的不同可能是也可能不是什么事情，依赖于分散的环路。<br />
5.&nbsp;IPv6&nbsp;讨论<br />
正如暂时的的唯一性的讨论（好象标示的行为），IPv6的模型与IPv4的模型很相似，只<br />
不过多了些。IP6将在IPv6主机中提供自动配置IPv6地址的机制。前缀的改变，需要全局<br />
所有的主机的IPv6地址在一个给定的前缀下改变，这是可以想象的。因此，IPv6将扩大这<br />
个存在的问题：去寻找稳定的标示用于端到端的安全和如TCP状态会话绑定。<br />
IAB&nbsp;感觉这是不幸运的，而且到IPv6的转换将是提供端到端的暂时的唯一标示的高层<br />
协议一个理想的原因。这些标识符的准确的天性要求更深的学习。<br />
正如对&nbsp;空间唯一（好似定位的行为）关心，IPv6地址空间是如此的大以致于地址的短<br />
缺，查询接近于RFC1918的类似地址转换，是难于想象的。虽然并不缺少IPv6地址，在<br />
IPv6[RFC&nbsp;1884，第2.4.8节]仍然有一个定义好的机制去包容硬件-本地地址和网站-本地地<br />
址。IPv6的这些属性不能阻止从IPv6中分离路由区域，如果这样描述（在多安全域的结果）。<br />
在现有情形下，我们不能标示一个在多IPv6路由区域中将需要的原因，它也很难于给定一<br />
个预先定义的答案对是否将只有一个，或者多于一个IPv6路由区域。如果假设将有多于一<br />
个的IPv6路由区域，这种区域将通过ALG&nbsp;和NAT&nbsp;互相连接。考虑到在IPv4中，这样ALG&nbsp;<br />
和NAT&nbsp;表现为标示。<br />
附录：<br />
对IPv4地址分配和路由的正确实践。<br />
初始化IP地址结构，同时IP路由将围绕网络数目分类的想法来设计（A/B/C类网）<br />
[RFC&nbsp;790]。在Internet&nbsp;90年代早期的&nbsp;成长要求了两个方面的重要性的改进，在Internet&nbsp;<br />
路由系统的可伸缩性上，就好象对IP地址空间的利用。IP地址空间的类结构化和路由<br />
按类分配导致相对需要得到不充分的结果，所以，在1992-1993年代，Internet接受了<br />
无阶级的内部域路由（CIDR）[RFC&nbsp;1380]，[RFC&nbsp;1518]，[RFC&nbsp;1519]。CIDR&nbsp;成就了一<br />
个新的地址分配方案，新的路由协议，和一个新的IP地址结构。<br />
CIDR&nbsp;通过在独立子网和网络的基础上扩展了阶级路由的想法来提高Internet&nbsp;路<br />
由系统的伸缩性。允许路由信息的集合不只停留在独立子网和网络的层次上。同时在独<br />
立站点的层次上，就比如在ISP（Internet&nbsp;服务提供商）的层次上。所以一个组织（站<br />
点）能在组织以内为所有目的充当一个集成者。同样的，一个提供者在他的用户内可以<br />
成为所有的目标的集成者（建立到提供者的直接连接）。<br />
扩展阶级路由的想法到独立的站点和提供者层次，允许站点和提供者作为路由信息<br />
（需要改变地址分配过程）和路由协议的集成者。在早期的CIDR中，在独立网络数字<br />
层的基础上分配个站点地址时没有对地址集成的需要做任何考虑，基于CIDR的地址分<br />
配建议地址分配时应该这样做：用站点和提供者去作为地址信息的集成者，这样的分配<br />
是“基于集成”。为了从“基于集成”的地址分配方案受益，CIDR介绍了一个中间域<br />
路由协议(BGP-4)&nbsp;[RFC&nbsp;1771,&nbsp;&nbsp;RFC&nbsp;1772]在独立站点和提供者层次上提供路由信息集<br />
成的性能。<br />
CIDR&nbsp;由消除网络类的观点改进地址空间利用，并且用连续的可变尺寸(&nbsp;2&nbsp;的力量&nbsp;)&nbsp;<br />
的地址块代替它&nbsp;。在需要大量的地址空间而且已经提供了大量的地址空间的情况下，<br />
提供一个好的对比&nbsp;[RFC&nbsp;1466]。它也便于基于集合的地址分配。消除网络分类的想法<br />
需要在路由协议中建立新的兼容性（内部和外部域之间都是），IP转发。特殊的CIDR<br />
兼容的协议需要处理到达的用不同长度的地址前缀表示的（地址）信息，而且，转发需<br />
要实现最长长度的匹配”算法。在[RFC1817]中描述了CIDR&nbsp;对路由协议的影响。<br />
CIDR&nbsp;的伸缩性基于地址分配对网络拓扑的最大影响的假设，尤其是在站点层次<br />
上，与提供者的相互连接，使得站点和提供者形成一个集合。如果一个站点改变它的提<br />
供者，然后去避免在Internet&nbsp;路由系统添加附加的头，站点需要去重新编号。同时，CIDR&nbsp;<br />
不需要每一个站点通过改变它的提供者来实现重新编号，这一点反应很重要：如果没有<br />
一个改变它的提供者的站点重新编码，Internet路由系统当处理大量需要处理的路由信<br />
息时有可能崩溃。<br />
包括“基于集合”的地址分配（升级路由系统的可伸缩性），和支持站点性能的需<br />
要去改变它们的提供者（去完成升级）需要对重编站点来说要求实践解决。在迅速增长<br />
的Internet路由系统对包括头的需要好象使重新编号越来越普遍[RFC1900]。<br />
对Internet&nbsp;路由系统伸缩性的需要，和用CIDR作为伸缩性的主要机制，是对<br />
Internet的地址分配和管理政策所作出的进一步结果。加上“借地址”政策的进化作为<br />
一个可提供的“地址私有”政策的进一步结果[RFC2008]。<br />
自从IP地址的第一次指定[RFC791]，IP地址和路由不停的进化。一些地址和路由<br />
规则已经遭到反对，一些规则已经被保留，同时新规则也被推出。现在的Internet路由<br />
和地址（基于CIDR）是一个进化的步骤，趋向于使用层次去包括全球Internet路由表。<br />
安全性讨论<br />
IP&nbsp;地址模型在安全方面的影响以在这篇文档的4.1小节和第五节讨论。<br />
鸣谢<br />
This&nbsp;document&nbsp;was&nbsp;developed&nbsp;in&nbsp;the&nbsp;IAB.&nbsp;Constructive&nbsp;comments&nbsp;were&nbsp;received&nbsp;from&nbsp;<br />
Ran&nbsp;Atkinson,&nbsp;Jim&nbsp;Bound,&nbsp;Matt&nbsp;Crawford,&nbsp;Tony&nbsp;Li,&nbsp;Michael&nbsp;A.&nbsp;Patton,&nbsp;Jeff&nbsp;Schiller.&nbsp;Earlier&nbsp;<br />
private&nbsp;communications&nbsp;from&nbsp;Noel&nbsp;Chiappa&nbsp;helped&nbsp;to&nbsp;clarify&nbsp;the&nbsp;concepts&nbsp;of&nbsp;locators&nbsp;and&nbsp;<br />
identifiers.<br />
参考书<br />
[RFC&nbsp;791]&nbsp;Postel,&nbsp;J.,&nbsp;"Internet&nbsp;Protocol",&nbsp;STD&nbsp;5,&nbsp;RFC&nbsp;791,&nbsp;September&nbsp;1981.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;790]&nbsp;Postel,&nbsp;J.,&nbsp;"Assigned&nbsp;Numbers",&nbsp;September&nbsp;1981.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;959]&nbsp;Postel,&nbsp;J.,&nbsp;and&nbsp;J.&nbsp;Reynolds,&nbsp;"File&nbsp;Transfer&nbsp;Protocol",&nbsp;STD9,&nbsp;RFC&nbsp;959,&nbsp;October&nbsp;<br />
1985.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1035]&nbsp;Mockapetris,&nbsp;P.,&nbsp;"Domain&nbsp;Names&nbsp;-&nbsp;Implementation&nbsp;and&nbsp;Specification",&nbsp;STD&nbsp;<br />
13,&nbsp;RFC&nbsp;1035,&nbsp;November&nbsp;1987.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1112]&nbsp;Deering,&nbsp;S.,&nbsp;"Host&nbsp;Extensions&nbsp;for&nbsp;Ip&nbsp;Multicasting",&nbsp;STD&nbsp;5,RFC&nbsp;1112,&nbsp;<br />
September&nbsp;1989.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1380]&nbsp;Gross,&nbsp;P.,&nbsp;and&nbsp;P.&nbsp;Almquist,&nbsp;"IESG&nbsp;Deliberations&nbsp;on&nbsp;Routing&nbsp;and&nbsp;Addressing",&nbsp;<br />
RFC&nbsp;1380,&nbsp;November&nbsp;1992.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1466]&nbsp;Gerich,&nbsp;E.,&nbsp;"Guidelines&nbsp;for&nbsp;Management&nbsp;of&nbsp;Ip&nbsp;Address&nbsp;Space",&nbsp;RFC&nbsp;1466,&nbsp;<br />
May&nbsp;1993.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1498]&nbsp;Saltzer,&nbsp;J.,&nbsp;"On&nbsp;the&nbsp;Naming&nbsp;and&nbsp;Binding&nbsp;of&nbsp;Network&nbsp;Destinations",&nbsp;RFC&nbsp;<br />
1498,&nbsp;August&nbsp;1993&nbsp;(originally&nbsp;published&nbsp;1982).<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1518]&nbsp;Rekhter,&nbsp;Y.,&nbsp;and&nbsp;T.&nbsp;Li,&nbsp;"An&nbsp;Architecture&nbsp;for&nbsp;Ip&nbsp;Address&nbsp;Allocation&nbsp;with&nbsp;<br />
CIDR",&nbsp;RFC&nbsp;1518,&nbsp;September&nbsp;1993.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1519]&nbsp;Fuller,&nbsp;V.,&nbsp;Li,&nbsp;T.,&nbsp;Yu,&nbsp;J.,&nbsp;and&nbsp;K.&nbsp;Varadhan,&nbsp;"Classless&nbsp;Inter-Domain&nbsp;Routing&nbsp;<br />
(CIDR):&nbsp;an&nbsp;Address&nbsp;Assignment&nbsp;and&nbsp;Aggregation&nbsp;Strategy",&nbsp;RFC&nbsp;1519,&nbsp;September&nbsp;<br />
1993.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1541]&nbsp;Droms,&nbsp;R.,&nbsp;"Dynamic&nbsp;Host&nbsp;Configuration&nbsp;Protocol",&nbsp;RFC&nbsp;1541,&nbsp;October&nbsp;<br />
1993.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1661]&nbsp;Simpson,&nbsp;W.,&nbsp;"The&nbsp;Point-to-Point&nbsp;Protocol&nbsp;(PPP)",&nbsp;STD&nbsp;51,&nbsp;RFC&nbsp;1661,&nbsp;July&nbsp;<br />
1994.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1771]&nbsp;Rekhter,&nbsp;Y.,&nbsp;and&nbsp;T.&nbsp;Li,&nbsp;"A&nbsp;Border&nbsp;Gateway&nbsp;Protocol&nbsp;4&nbsp;(BGP-4)",&nbsp;RFC&nbsp;1771,&nbsp;<br />
March&nbsp;1995.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1772]&nbsp;Rekhter,&nbsp;Y.,&nbsp;and&nbsp;P.&nbsp;Gross,&nbsp;"Application&nbsp;of&nbsp;the&nbsp;Border&nbsp;Gateway&nbsp;Protocol&nbsp;in&nbsp;<br />
the&nbsp;Internet",&nbsp;RFC&nbsp;1772,&nbsp;March&nbsp;1995.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1817]&nbsp;Rekhter,&nbsp;Y.,&nbsp;"CIDR&nbsp;and&nbsp;Classful&nbsp;Routing",&nbsp;RFC&nbsp;1817,&nbsp;September&nbsp;1995.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1825]&nbsp;Atkinson,&nbsp;R.,&nbsp;"Security&nbsp;Architecture&nbsp;for&nbsp;the&nbsp;Internet&nbsp;Protocol",&nbsp;RFC&nbsp;1825,&nbsp;<br />
September&nbsp;1995.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1900]&nbsp;Carpenter,&nbsp;B.,&nbsp;and&nbsp;Y.&nbsp;Rekhter,&nbsp;"Renumbering&nbsp;Needs&nbsp;Work",&nbsp;RFC&nbsp;1900,&nbsp;<br />
February&nbsp;1996.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1918]&nbsp;Rekhter,&nbsp;Y.,&nbsp;&nbsp;Moskowitz,&nbsp;B.,&nbsp;Karrenberg,&nbsp;D.,&nbsp;de&nbsp;Groot,&nbsp;G.&nbsp;J.,&nbsp;and&nbsp;E.&nbsp;Lear,&nbsp;<br />
"Address&nbsp;Allocation&nbsp;for&nbsp;Private&nbsp;Internets",&nbsp;RFC&nbsp;1918,&nbsp;February&nbsp;1996.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;1933]&nbsp;Gilligan,&nbsp;R.,&nbsp;and&nbsp;E.&nbsp;Nordmark,&nbsp;"Transition&nbsp;Mechanisms&nbsp;for&nbsp;IPv6&nbsp;Hosts&nbsp;and&nbsp;<br />
Routers",&nbsp;RFC&nbsp;1933,&nbsp;April&nbsp;1996.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;2008]&nbsp;Rekhter,&nbsp;Y.,&nbsp;and&nbsp;T.&nbsp;Li,&nbsp;"Implications&nbsp;of&nbsp;&nbsp;Various&nbsp;Address&nbsp;Allocation&nbsp;<br />
Policies&nbsp;for&nbsp;Internet&nbsp;Routing",&nbsp;RFC&nbsp;2008,&nbsp;October&nbsp;1996.<br />
<br />
&nbsp;&nbsp;&nbsp;[kre]&nbsp;Elz,&nbsp;R.,&nbsp;et.&nbsp;al.,&nbsp;"Selection&nbsp;and&nbsp;Operation&nbsp;of&nbsp;Secondary&nbsp;DNS&nbsp;Servers",&nbsp;Work&nbsp;in&nbsp;<br />
Progress.<br />
<br />
&nbsp;&nbsp;&nbsp;[RFC&nbsp;2065]&nbsp;Eastlake,&nbsp;E.,&nbsp;and&nbsp;C.&nbsp;Kaufman,&nbsp;"Domain&nbsp;Name&nbsp;System&nbsp;Security&nbsp;Extensions",&nbsp;<br />
RFC&nbsp;2065,&nbsp;January&nbsp;1997.<br />
<br />
&nbsp;&nbsp;&nbsp;[dns2]&nbsp;Vixie,&nbsp;P.,&nbsp;et.&nbsp;al.,&nbsp;"Dynamic&nbsp;Updates&nbsp;in&nbsp;the&nbsp;Domain&nbsp;Name&nbsp;System&nbsp;(DNS&nbsp;<br />
UPDATE)",&nbsp;Work&nbsp;in&nbsp;Progress.<br />
<br />
作者地址<br />
<br />
&nbsp;&nbsp;&nbsp;Brian&nbsp;E.&nbsp;Carpenter<br />
&nbsp;&nbsp;&nbsp;Computing&nbsp;and&nbsp;Networks&nbsp;Division<br />
&nbsp;&nbsp;&nbsp;CERN<br />
&nbsp;&nbsp;&nbsp;European&nbsp;Laboratory&nbsp;for&nbsp;Particle&nbsp;Physics<br />
&nbsp;&nbsp;&nbsp;1211&nbsp;Geneva&nbsp;23,&nbsp;Switzerland<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;brian@dxcoms.cern.ch<br />
<br />
&nbsp;&nbsp;&nbsp;Jon&nbsp;Crowcroft<br />
&nbsp;&nbsp;&nbsp;Dept.&nbsp;of&nbsp;Computer&nbsp;Science<br />
&nbsp;&nbsp;&nbsp;University&nbsp;College&nbsp;London<br />
&nbsp;&nbsp;&nbsp;London&nbsp;WC1E&nbsp;6BT,&nbsp;UK<br />
<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;j.crowcroft@cs.ucl.ac.uk<br />
<br />
&nbsp;&nbsp;&nbsp;Yakov&nbsp;Rekhter<br />
&nbsp;&nbsp;&nbsp;Cisco&nbsp;systems<br />
&nbsp;&nbsp;&nbsp;170&nbsp;West&nbsp;Tasman&nbsp;Drive<br />
&nbsp;&nbsp;&nbsp;San&nbsp;Jose,&nbsp;CA,&nbsp;USA<br />
<br />
&nbsp;&nbsp;&nbsp;Phone:&nbsp;+1&nbsp;914&nbsp;528&nbsp;0090<br />
&nbsp;&nbsp;&nbsp;Fax:&nbsp;+1&nbsp;408&nbsp;526-4952<br />
&nbsp;&nbsp;&nbsp;EMail:&nbsp;yakov@cisco.com<br />
<br />
RFC&nbsp;2101——&nbsp;IPv4&nbsp;Address&nbsp;Behaviour&nbsp;Today&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;IPv4今日地址行为<br />
<br />
<br />
1<br />
RFC文档中文翻译计划&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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />