组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：党红梅（snowlily   danghongmei@263.net）
译文发布时间：2001－5－7
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必
须保留本文档的翻译及版权信息。


Network Working Group                                          T. Dixon
Request for Comments: 1454                                         RARE
                                                               May 1993


下一代IP提议的比较
（RFC1454 Comparison of Proposals for Next Version of IP）

本备忘录的状态
本文为I n t e r n e t 社区提供信息，不指定I n t e r n e t 标准，它的分发不受限制。
摘要
本文是R A R E 技术报告( RT C ( 9 3 ) 0 0 4 )经过稍许编辑后重印的。
下面是对目前下一代I P 的三个主要提议特点的简短总结。本文并不打算作为详尽的或
最终的文本(最后给出简要的参考文献目录以提供更多的信息源)，但可作为讨论这些提案时
的参考，由R A R E 和R I P E 来协调。应该承认这些提案本身是“推动目标”的，它反映
了在华盛顿举行的第2 5 届I E T F 会议的见解是完全正确的。Ross Callon 和Paul Ts u c h i 
y a 对原始草案的评议也包括在内。有一个时期，术语I P v 7 用来指I P 的下一个版本，但
该术语与一个特别提案有关，所以现在用术语I P n g 来标识下一代I P 。
在个别讨论提案前，本文先对为解决问题和达到特定目标的机制作一般性的讨论。
目录
1. 为何当前的IP 不足 2
2. 提案具有的共同点 3
2.1 较长的地址 3
2.2 基本原理 3
2.3 源选路 3
2.4 封装 4
2.5 组播 4
2.6 分段 4
2.7 包的生存期 4
3. 提案略为提及的内容 5
3.1 资源预留 5
3.2 地址分配策略 5
3.3 自动配置 5
3.4 应用接口/应用协议改变 6
3.5 DNS 改变 6
4. 提案中没有真正提到的 7
4.1 拥塞避免 7
4.2 移动主机 7
4.3 计费 7
4.4 安全性 7
5. 提案的不同点 7
5.1 PIP 8
5.2 SIP 8
5.3 TUBA 9
6. 过渡计划 9
7. 随意评议 9
8. 安全问题 10
9. 作者联系方法 10

1. 为何当前的IP 不足
该问题已经由R O A D 小组研究并阐述过，原因如下：
· IP B 类地址空间耗尽。
· IP 地址空间会全部耗尽。
· 地址分配的非分级结构导致平面的选路空间。
虽然I E S G 对于新的I P 要求比简单选路和寻址议题更深入一步，但正是这些议题使
扩展当前协议成为不实际的选择。因而，对提出的各种协议的大部分讨论和开发集中在这些
专门问题上。
对这些问题的近期补救办法，包括使用C I D R 提案( C I D R 允许以C 类网络的集聚
来选路)以及以发挥C I D R 优势的方式分配C 类网络地址的分配策略。支持C I D R 的选
路协议有O S P F 和B G P 4 。以上这些都不是新I P ( I P n g )必须具备的先决条件，但是
必须延长当前I n t e r n e t 的生存期，以满足长期解决方案工作的要求。Ross Callon 指出为
延长I P 生存期有其他选择，他的一些想法已被列在T U B A 清单中。正在考虑可使I n t e r 
n e t 进一步增长的长期提案。这些提案的时间进度如下：
· 12 月1 5 日提出作为RFC 的议题选择准则。
· 2 月1 2 日两个可互操作的实施就绪。
· 2 月2 6 日第二个提案的草案文件就绪。
有远大的目标是在1 9 9 3 年3 月在哥伦比亚举行的第2 6 届I E T F 会议上能作出提
案贯彻应用的决定。
当前可选的候选对象有：
· PIP(P IP —一个全新的协议)。
· TUBA(具有大地址的T C P / U D P —用ISO CLNP)。
· SIP(简单I P —具有较大地址和较少选项的I P )。
Robert Ullman 有一个更好的提案，不过我对它了解不多。与每个提案候选对象相联系
的是过渡计划，但大都独立于提案本身且包含的元素可分开采用，即使对I P v 4 ，也还要
延长当前的设备和系统的生存期。
2. 提案具有的共同点
2.1 较长的地址
所有的提案都为较长的地址字段做了准备，不仅增加了可寻址系统的数量，也方便了路
由集聚的地址分级分配。
2.2 基本原理
提案也起源于世界性的“选路实现”观点—也就是说集中在网络内的选路内部部件而不
是集中在终端用户或应用看得见的网络服务上。这或许是不可避免的，尤其是给生产可互操
作的设备的时间非常紧。然而在第2 5 届I E T F 会议上少数真正的用户代表显然不高兴，
因为他们支持最终必须采用新的主机设备。
提案中有一个内置的假设，就是I P n g 企图成为一个环球协议：也就是同一网络层协
议将可用在同一局域网上的主机之间、主机和路由器之间、同一自治域的路由器之间和不同
自治域的路由器之间。在定义分开的“接入”协议和“远程”协议上有某些优点，这在需求
中没有排除。尽管这是I n t e r n e t 内少有的重要变革机会，但要求加速开发和低风险导致
提案数不断递增，而不是从根本上变革到经过很好验证的已有的技术上。
一个未进一步陈述的假设是体系结构的目标定在单个连接的主机。目前，要设计允许主
机有多个接口，并和单个连接的主机相比，可从增加的带宽和可靠性中获益(是地址属于接
口而不属于主机的缘故)的I P v 4 网络很困难。正如这些文件中提到的，倾向于拓扑是否存
在限制。已经认定不一定是P I P 或T U B A 提案的制约，但是相信这是一个议题，到现在
为止还没有出现在相当的准则中。
2.3 源选路
已有的IPv4 对源指定路由已有保证，然而很少用，(有人要反驳我吗？)部分原因是由
于需要了解直至路由器级的网络的内部结构。源路由通常是需要使用的，当用户根据策略，
要求源和目的地之间的业务倾向或强令通过特殊行政管理域时，源路由也可被行政管理域内
的路由器用来指定通过特殊的逻辑拓扑。源指定的选路需要一些性质不同的部件：
(1) 根据技术规范中源的策略来选择路由。
(2) 路由的选择要与其策略相适应。
(3) 用已标识的路由对业务流做标记。
(4) 为已加标记的业务流相应地选路由。
这些步骤不是完全独立的。在这种方法中，第( 3 )步标识的路由可能会约束前面步骤中
能被选择的路由种类。目的地不可避免地、或者通过告知准备接受的策略，或者通过一个协
商过程，加入到源路由的技术规范中去。
所有提案都是通过在每个包中加一串直接地址(或许部分地指定)来标记源路由。没有规
定一个主机取得指定这些直接地址所需信息的过程(这个阶段不完全不合理，但期望有更多
的信息)。这些决定的负面后果是：
· 根据必须指定的直接地址数，包头会变得很长(虽然当前有指定的机构或想象该机构
只指定直接地址的重要部分)。
· 如果个别的直接地址不再可达到，源路由可能必须周期性地重新指定。
正面影响是：
· 域间路由器不必了解策略，只是机械地跟随源路由。
· 路由器不必存储标识路由的上下文，因为信息被指定在每个包头中。
· 路由服务器可定位在网络的任何地方，只要主机知道如何找到它们。
2.4 封装
封装是将一个网络层包封装到另一个包中，以使有效的包能直接通过一条路径，否则就
不能到达能移去最外面包的路由器，并指引结果包到它的目的地。封装需要：
(1) 在包中有一指示位，以指示它包含另一个包。
(2) 路由器具备这样的功能，它能在收到一个包后，移去封装并再启动包转发进程。
所有提案都支持封装。由源进行的合适的封装可能会获得源选路的效果。
2.5 组播
所有提案都能协调在地址规范许可的多种范围的组播。I n t e r n e t 范围的组播尚待进
一步研究。
2.6 分段
所有提案都支持中间路由器对包的分段，然而最近的一些讨论，主张从提案中取消该机
制，而改为使用M T U 发现过程以避免中间分段。这样的决定实际上排除在网络上使用报
文计数序列编号的传输协议(如O S I 传输协议)，只有用字节计数并确认的协议(如T C P )
才能在一个连接激活期间处理M T U 还原。O S I 传输协议可能不会特别地与I P 界有关
联，但是它可能与提供多协议服务的供应商有关联，但是应该注意到对于I P n g 支持的服
务类型的影响。
2.7 包的生存期
I P v 4 中的“生存期”( T T L )字段在每种情况下，作为一个简单的段计数被重新计算，
很大程度上以实施方便为基础。虽然老的T T L 很大程度上以这种方式实现，但它以服务于
体系结构为目的，在网络中为一个包的生存期设置了一个上限。如果该字段作为一个跳计数
而重新计算，那么必定对网络中包的最大生存期有其他的技术规范，所以源主机能保证网络
层分段标识符和传输层序列号，当存在混淆危险时，从来不会有重用的危险。事实上，有三
个分开的议题：
(1) 防止选路形成回路(由跳计数解决)。
(2) 限制网络层包的生存期(需要，但目前为止未指定)，支持传输层的设想。
(3) 允许源对包设置更多限制(例如在拥塞情况下丢弃老的实时业务流，让位给新的业务
流，这是一个选项，到目前为止还没作规定)。
3. 提案略为提及的内容
3.1 资源预留
应用日益要求确定的带宽和传输延时，两者对实时视频和音频传送都是必须的。这样的
应用需要过程向网络指出它们的需求以及必要的资源预留。这样的过程在某种程度上类似于
源路由选择。
(1) 源提出需求的技术规范。
(2) 确认需求能被满足。
(3) 用需求来标记业务流。
(4) 为已加标记的业务流相应地选路由。
按照同样资源需求规定路线发送的业务流有时也称其为流。流的标识需要一个建立过
程，人们可能设想与建立源路由使用同样的过程，但两者是有区别的，表现在：
· 在一条路径上的所有路由器必须同意并参予资源预留。
· 由此在每个路由器中相对直接地保持前后关系和短的流标识。
· 在失效时，网络可选择重定路由。
每个提案用各种方法来携带流标识，然而这是目前十分超前的研究。没有确定建立机制。
实际上预留资源过程是一个高层次的问题。源选路和资源预留间的交互作用，还需进一步试
验：虽然两者性质截然不同，实现的制约也不一样，但两个不同的机制将使得在选择路由时，
既要满足策略，又要满足性能指标，变得困难。
3.2 地址分配策略
在I P v 4 中，地址与系统捆绑在一起是长期的。且在多数情况下，能与D N S 名字互
相交换使用。默许地接受地址和一个特殊系统的联系，在IPng 中可能更为短暂。提案之一
的PIP 是使系统的标识和它的地址之间有区别，并允许捆绑能暂时改变。没有提案规定地
址生存期的限制，也未规定地址分配方式必须受特殊协议的约束。例如，由IPng 提供的较
大的地址空间中分配分级地址的高位部分，可以选择是根据与地理位置相关方式，还是参照
服务供应商方式。基于地理位置的地址是不变的，也易于分配，但意味着在分配区域内有重
新退化到“平面”地址的危险，除非采取确实的拓扑上的限制。基于供应商的地址分配会造
成地址改变(如果供应商改变)或多个地址(如果多个供应商)。移动主机(依赖于基础技术)不论
是基于地理位置还是基于供应商方案都会出现问题。
对地址分配方案以及对地址生存期的影响没有严密的提案，假设捆绑名字到地址的已有
的DNS 模型仍然有效是不可能的。
值得提出的是，在地址分配机制和可能采用的自动配置方法之间有交互作用。
3.3 自动配置
对当前I P 服务用户最大的担忧是维护基本配置信息的管理工作，诸如为主机分配名字
和地址，并要保证信息正确地反映在D N S 中。部分问题是由不良的实施造成的(或者盲目
相信v i和a w k 是网络管理工具)。不过许多问题通过使过程更自动化而得到减轻。这些可
能性(有些是互斥的)有：
· 分配主机地址使用相对恒定的值，如LAN 地址。
· 在子网内定义一个动态地址分配协议。
· 定义“通用地址”，通过使用它，主机不需预先配置便可达本地服务器( D N S 、路
由服务器等)。
· 通过检索D N S ，主机便能确定它们的名字。
· 当主机配置改变时，由主机更新它们的名字/地址捆绑。
当很多提案提及某些以上的可能性时，选择合适的解决方案在一定程度上依赖于地址分
配策略。同时，动态配置引起某些困难的理性和实际议题(确切地说，地址的作用是什么？
从什么意义上来讲，当一个主机地址改变时，还是同一个主机吗？如何处理D N S 映射的
动态变化，又如何对它们进行身份验证)。
提案小组会发现大部分问题在他们讨论范围以外。当定义和选择I P n g 的候选者时，
像“系统”这样的议题没有很好的讨论，看来是一种疏忽。参加者意识到了这一点，看来即
使做了决定，某些观念还会在更多的读者范围内重新研究。
然而I P 不可能在非技术环境中对有专利权的连网系统(如N e t w a r e 、A p p l e Ta l k )
产生影响，在体系结构中或供应商都没有严格地采用自动配置。我坚信在人们头脑中对如何
解决这些议题有想法，只是没有写在纸上而已。
3.4 应用接口/应用协议改变
一些公共应用协议(如F T P 、R P C 等)已经确定专门传送3 2 位I P 地址，无疑还有
其他标准的和专用的协议。也有许多应用简单地把I P 地址当成3 2 位整数来处理。甚至用
B S D 套接字试图不透明地处理地址的一些应用，也不明白如何分析语法或打印长地址(即
使套接字结构大到足够容纳它们)。
因此，每个提案需要指定机制，以便当变换发生时，允许已存在的应用程序和接口运行
在新的环境下。对于T C P 和I P n g (也能运行I P v 4 )，有一个程序设计接口参考技术规范
是有用的，它允许开发者现在就开始改变应用程序。从指定过渡机制的所有提案中，就能推
断出已存在的应用兼用性。现在还没有迹象表示一个新的接口技术规范独立于所选的协议。
3.5 DNS 改变
显然，必须要有能支持新的、长地址的名字到地址的映射服务。所有提案都认为这种服
务应该由具有合适定义的新资源记录的D N S 来提供。关于为响应某种查询，用返回“A ”
记录信息的合适性，以及什么信息该首先请求的讨论正在进行。在为建立正确地址所必须的
询问次数和由于返回非期望信息破坏已存在的执行过程之间存在着折衷。
为自动配置使用D N S 和寻址方案反向转换的规模的讨论很热烈，但没有实质性进展。
4. 提案中没有真正提到的
4.1 拥塞避免
I P v 4 中路由器用“源抑制”控制报文，向源指示拥塞并有可能不久会丢失包。T U B 
A / P I P有一“遭受拥塞”位，它给目的地提供类似的信息。但这些技术规范都没有提供如
何使用这些设施的详细说明。因而近年来有许多研究分析实体，他们建议这样的设施不仅可
以用来报告拥塞(向传输协议提供信息)，也可减少通过网络层的延迟。每种提案都提供某种
形式的拥塞信令，但没有一个指定它使用的机制(或分析该机制实际上是否可用)。
作为网络服务的用户，目前大约有3 0 %的丢弃率，且仅在5 0 0 英里内来回时间就多
至2 秒。我对某些提案感兴趣的是网络服务在额外负载的情况下性能下降得很少。
4.2 移动主机
移动主机的一个特征是相对快地移动它们的物理位置和到网络拓扑的连接点。显然对寻
址和选路是重要的(不管是地理的还是拓扑的)。到目前为止，没有解决方案的详细技术规范，
看来这是一个认识问题。
4.3 计费
I E S G 的选择准则只要求提案不会阻止为审计和收费目的而进行的信息收集，因此没
有提案考虑潜在的计费机制。
4.4 安全性
“网络层安全性议题有待进一步研究”，最好每个候选者都能扩展以显示能提供一定程
度的安全性，例如对抗地址欺骗。当资源分配特性允许某些主机为特殊应用要求大量可用带
宽时，这一点特别重要。
值得提出的是，提供某种程度的安全性意味着在网络内人工配置安全信息，还必须考虑
与自动配置目标的关系。
5. 提案的不同点
每个提案互不相同，正像不同于I P v 4 一样，原理差别虽小，但会产生重大影响(地址
规模的扩充，原理上仅是一个小的差别)。主要的特性差别是：
· PIP
P I P 有一个创新的头格式，从而简化了分级、策略和虚电路选路。头中也有一个“含
糊”的字段，它的语义在不同的行政管理域可以有不同的定义，它的使用和解释在穿越边界
时协商解决，还没有指定控制协议。
· SIP
S I P 提供了“最小者”方法—从I P v 4 头中移去所有不常用的字段，并将地址长度扩
展到6 4 位。控制协议基于对I C M P 的修改。该提案有处理效率高和易于熟悉的优点。
· TUBA
T U B A 基于CLNP(ISO 8473)和ES-IS(ISO 9542)控制协议。T U B A 是考虑为了T C P 
和U D P能在C L N P 网络上运行。倾向于T U B A 的主要论点是认为能处理网络层协议
的路由器已经存在，可扩展的地址提供了宽范围的可供“未来验证”的余量，同时是一个标
准和产品会聚的机会。
5.1 PIP
P I P 包头包含了一个指令集，供路由器中的转发处理器完成对包的某些动作。在传统
协议中，某些字段的内容隐含某些动作。P I P 为源端编写指引包通过网络选路的小“程序”
提供了灵活性。
P I P 地址长度实际上不受限制：网络拓扑分级的每一级成为地址的一部分，同时地址
随网络拓扑改变而改变。在完全分级的网络拓扑中，每级所需的选路信息数量可以非常小。
因而在实际上，分级的级数将更多地由商界和实用因素来决定，而不是受任何特定的选路协
议的制约。一个明显优点是地址的高位部分在本地交换时可以省略，低位部分在源路由中可
以省略，减少了主机系统需要知道的拓扑信息数量。
这里有一个假设，就是P I P 地址易于改变，所以为了标识，给系统指定另一个参数P I 
P 标识符。不清楚该参数有何用途，它不能同等地受到D N S 名字的服务(更加紧凑，但同
样不需要携带在每个包中，但需要一个额外的检索)。因此，提出了这样的问题：两个潜在
可通信的主机系统如何找到可使用的正确的地址。
P I P 最复杂的部分莫过于某些头字段的意义是由特定域中相互之间的合同来确定的。
专门处理设施的语义(如排队优先级)是全球登记的，但实际使用和在包头中为这些设施申请
的编码在不同的域中可以是不同的。在两个域之间用不同编码的边界路由器必须从一种编码
映射成另一种。因为路由器和其他域在物理上不一定是相邻的，而是通过“隧道”，因此一
个路由器必须了解的潜在编码规则数十分大。相对于更熟悉的“选项”而言，虽然用这样的
方案可以节省包头的空间，但是协商这些设施使用和编码的复杂性导致成本增加，以及在每
个域边界上对包的再编码，这些才是关心的主题。虽然主机为它们的本地域有可能“预编译”
编码规则，还是存在许多潜在的实施上的困难。
虽然P I P 在三个提案中提供了最大的灵活性，但对于“希望可用”的情况还需进行更
多工作，使其潜在的优点和缺点能暴露得更具体。
5.2 SIP
S I P 是一个简单而具有较大地址和较少选项的I P 。它的主要优点是甚至比I P v 4 更
容易处理。
它的主要缺点是：
· 如果3 2 位地址不够的话，那么6 4 位地址在可预见的未来是否就够了，还远远不
清楚。
· 虽然在头字段中有少量“保留”位，但S I P 支持新特性的扩展不明显。真是没有
其他什么可说的！
5.3 TUBA
ISO CLNS 的特征相当有名，协议与I P v 4 有很强的文化上的相似性，然而有2 0 字
节供网络层寻址。除了谬误的(不是这儿发明的)偏见之外，反对T U B A 的主要争论在于T 
U B A 太像I P v 4了。除了更大、更灵活的地址外，别无其他贡献。采样试验证明路由器
能高效地处理非常长的地址，但同时长的头很少不给网络带宽带来负面影响。
对建议的控制协议(ISO 9542)有下列异议：
· 根据我以前的经验，如果要合理地容纳大的局域网，路由器发现主机的过程将是低
效的，而且会消耗路由器资源，同时在主机上需要十分精确的时间分辨力。T U B A 支持者
建议，根据最近的经验，A R P 不适用了，但是我想本议题还需要检验。
· 重定向机制实际上是基于LAN 地址，而不是网络地址，意思是本地路由器将复合
的选路决定交给同一L A N 上其他路由器。同样，重定向方案(如I P v 4 中的方案)重定向
到网络地址会造成不必要的额外跳数。要分析哪个解决方案比较好，依赖于构筑的情况。客
观地说，该协议的路由器发现部分提供了一个其他提案所没有的机制。通过该机制，主机能
定位就近的网关，并能自动配置它们的地址。
6. 过渡计划
为使“老”主机能与“新”主机对话，显然需要一个过渡：
(1) IPng 主机也能用I P v 4 ，或
(2) 通过一个中间系统转换。
或者：
(1) 系统间的基础设施有能力承载I P n g 和I P v 4 ，或
(2) 网络的某些部分用隧道或转换方法将一个协议附在另一个协议中。
各种提案拥护的过渡计划只是简单地将上述方案进行组合。经验表明，不管选择那个协
议，事实上以上情况都会发生。
隧道/转换过程的一个问题是必须携带在穿过网络中的I P v 4 隧道时的附加信息(外加
地址部分)，这可以在数据封装在I P v 4 包前加一个附加的“头”来实现，或者通过将信息
编码作为新IPv4 选项类型来实现。
在前一种情况下，可能要正确地映射出错报文会有困难，因为原始包在返回前被截取；
后一种情况，包有被丢弃的危险(因为I P v 4 选项不是自描述的，新的选项可能无法通过I P 
v 4 路由器)。这就是为了支持I P n g 隧道方法而引入I P v 4 的“新”版本的理由。
另一个替代方案(在该方案中，I P n g 主机有两个栈，基础设施可以支持、也可以不支
持I P n g 或I P v 4 )当然需要一个机制来解决用哪个协议做试验。
7. 随意评议
这是I n t e r n e t 协议中发生的首次根本性改变。因为I n t e r n e t 是一个可管理的实
体，它的发展是与美国政府合同紧密联系的。或许I E T F / I E S G / I A B 组织结构不可避
免地无法管理如此大幅度的改变，但希望提议的新结构在促进共识上获得更大成功。值得注
意的是许多觉察到的O S I 过程问题(如进步慢，在琐事上派别内争，聚焦在最低层共同特
性解决方案上，缺乏对终端用户的考虑等)，用它们来处理I P n g 是危险的，同时关注着由
网络设计的广泛参与所带来的困难会到什么程度。
三个主要提案在I P n g 上很少有实质性的差别，但选择I P n g 的竞争过程如不成功就
是失败。在这方面，选择过程的结果没有什么特别意义，但在过程本身中为了修复Internet 工
程过程的社会和技术凝聚力，或许是必要的。

8. 安全问题
本文档不讨论有关安全问题

9. 作者联系方法

   Tim Dixon
   RARE Secretariat
   Singel 466-468
   NL-1017AW Amsterdam
   (Netherlands)

   Phone: +31 20 639 1131 or + 44 91 232 0936
   EMail: dixon@rare.nl or Tim.Dixon@newcastle.ac.uk

RFC1454: Comparison of Proposals for Next Version of IP  下一代IP提议的比较


1
RFC文档中文翻译计划