组织：中国互动出版网（http://www.china-pub.com/）<br />
RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm)<br />
E-mail：ouyang@china-pub.com<br />
译者：刘伟娜（superwinner&nbsp;&nbsp;&nbsp;starfield@xanet.edu.cn）<br />
译文发布时间：2001－5－7<br />
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须<br />
保留本文档的翻译及版权信息。<br />
<br />
向IPng&nbsp;过渡和其他考虑的白皮书<br />
(RFC&nbsp;1671&nbsp;IPng&nbsp;White&nbsp;Paper&nbsp;on&nbsp;Transition&nbsp;and&nbsp;Other&nbsp;Considerations)<br />
<br />
备忘录状态<br />
<br />
&nbsp;&nbsp;&nbsp;This&nbsp;memo&nbsp;provides&nbsp;information&nbsp;for&nbsp;the&nbsp;Internet&nbsp;community.&nbsp;&nbsp;This&nbsp;memo<br />
&nbsp;&nbsp;&nbsp;does&nbsp;not&nbsp;specify&nbsp;an&nbsp;Internet&nbsp;standard&nbsp;of&nbsp;any&nbsp;kind.&nbsp;&nbsp;Distribution&nbsp;of<br />
&nbsp;&nbsp;&nbsp;this&nbsp;memo&nbsp;is&nbsp;unlimited.<br />
摘要<br />
本文是响应RFC&nbsp;1550&nbsp;而向IETF&nbsp;IPng&nbsp;领域提交的文件。本文的发布并不意味着I&nbsp;P&nbsp;n&nbsp;<br />
g&nbsp;领域接受文中所表达的任何思想。评议请提交给b&nbsp;i&nbsp;g&nbsp;-&nbsp;i&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;@&nbsp;m&nbsp;u&nbsp;n&nbsp;n&nbsp;a&nbsp;r&nbsp;i&nbsp;.&nbsp;o&nbsp;z&nbsp;.&nbsp;a&nbsp;<br />
u&nbsp;邮件列表。<br />
总结<br />
本白皮书在所选领域勾画了I&nbsp;P&nbsp;n&nbsp;g&nbsp;某些通用需求。下面表示的是逐级过渡的需求：<br />
(1)&nbsp;在网络的每级和每层实现互通。<br />
(2)&nbsp;包头转换被认为是有害的。<br />
(3)&nbsp;共存。<br />
(4)&nbsp;IPv4&nbsp;到I&nbsp;P&nbsp;n&nbsp;g&nbsp;地址映射。<br />
(5)&nbsp;双栈主机。<br />
(6)&nbsp;域名系统(&nbsp;D&nbsp;N&nbsp;S&nbsp;)。<br />
(7)&nbsp;智能双栈代码。<br />
(8)&nbsp;智能管理工具。<br />
接受某些关于物理和逻辑组播的论点，并建议需要一个I&nbsp;P&nbsp;n&nbsp;g&nbsp;在AT&nbsp;M&nbsp;上运行的模型。<br />
最后，本文建议的策略选路、计费和安全防火墙等需求，需要所有I&nbsp;P&nbsp;n&nbsp;g&nbsp;包携带所涉及事<br />
务处理类型的踪迹，以及它们的源和目的地址。<br />
过渡和发展<br />
显然过渡需要几年的时间，同时网络中的每个站点不得不决定它自己的阶段过渡计划。<br />
只有那些最小的站点可能在I&nbsp;S&nbsp;P&nbsp;的压力下，考虑一步到位(“标志日”)的过渡。此外，一<br />
旦决定采用I&nbsp;P&nbsp;n&nbsp;g&nbsp;，那么I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;和所有用I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;协议集的专用网在下一十年(或<br />
更长)的活动，将受到I&nbsp;P&nbsp;n&nbsp;g&nbsp;发展的强大影响。用户站点注视着决策，是否和他们过去所看<br />
到的在改变程序设计语言或操作系统时所用的同样方法来改变I&nbsp;P&nbsp;v&nbsp;4&nbsp;。向I&nbsp;P&nbsp;n&nbsp;g&nbsp;转变可能<br />
不是必然的结果。他们主要担心是，改变是否能使成本和影响生产的风险减到最低。<br />
这样的担心立刻对I&nbsp;P&nbsp;n&nbsp;g&nbsp;过渡和发展的模型产生了强大的约束。这些约束中的某些列<br />
在下面，并对每种约束赋予简短的解释。<br />
术语“I&nbsp;P&nbsp;v&nbsp;4&nbsp;主机”是一个和今天的主机运行同样内容，而没有维护版本及配置改变<br />
的主机。“I&nbsp;P&nbsp;n&nbsp;g&nbsp;主机”是一个运行I&nbsp;P&nbsp;新版本，经过重新配置的主机。它类似于路由器。<br />
1.	网络的每级和每层实现互通<br />
这是主要约束。计算机系统、路由器和应用软件厂商肯定不会协调他们产品的发布日期。<br />
用户将继续运行他们的老设备和软件。因此，I&nbsp;P&nbsp;v&nbsp;4&nbsp;和I&nbsp;P&nbsp;n&nbsp;g&nbsp;主机和路由器的任何组合必<br />
须能互通(即加入到U&nbsp;D&nbsp;P&nbsp;和T&nbsp;C&nbsp;P&nbsp;会话中)。一个I&nbsp;P&nbsp;v&nbsp;4&nbsp;包必须能找到从任何I&nbsp;P&nbsp;v&nbsp;4&nbsp;主机<br />
到其他任何I&nbsp;P&nbsp;v&nbsp;4&nbsp;或I&nbsp;P&nbsp;n&nbsp;g&nbsp;主机的路径，反之亦然，穿过I&nbsp;P&nbsp;v&nbsp;4&nbsp;和I&nbsp;P&nbsp;n&nbsp;g&nbsp;路由器的混合<br />
路径，I&nbsp;P&nbsp;v&nbsp;4&nbsp;主机无需修改。I&nbsp;P&nbsp;v&nbsp;4路由器无需修改可与I&nbsp;P&nbsp;n&nbsp;g&nbsp;路由器互通。另外，一个<br />
“明白”I&nbsp;P&nbsp;v&nbsp;4&nbsp;但还“不明白”I&nbsp;P&nbsp;n&nbsp;g&nbsp;的应用软件包必须能在运行I&nbsp;P&nbsp;v&nbsp;4&nbsp;的计算机系统上<br />
运行，并和I&nbsp;P&nbsp;n&nbsp;g&nbsp;主机通信。例如，欧洲的一个老P&nbsp;C机应该可访问美国的N&nbsp;I&nbsp;C&nbsp;服务器，<br />
即使N&nbsp;I&nbsp;C&nbsp;服务器运行的是I&nbsp;P&nbsp;n&nbsp;g&nbsp;，且北美的选路机制只是部分地变换过。或者某个公司<br />
某个部门的一个C&nbsp;类网络应该保持对运行I&nbsp;P&nbsp;n&nbsp;g&nbsp;的公司服务器完全的访问，尽管C&nbsp;类网<br />
络内部什么也没有改变。<br />
(并不要求一个只能在I&nbsp;P&nbsp;v&nbsp;4&nbsp;上运行的应用程序到一个I&nbsp;P&nbsp;n&nbsp;g&nbsp;主机上运行。因此，我们<br />
承认某些主机一直要等到所有它们的应用程序是I&nbsp;P&nbsp;n&nbsp;g&nbsp;兼容后才能升级。换句话说，我们<br />
承认某种程度上A&nbsp;P&nbsp;I&nbsp;要改变。然而，即使这样的放松，还是有争议的，甚至有些厂商要求<br />
在I&nbsp;P&nbsp;n&nbsp;g&nbsp;主机上严格保持IPv4&nbsp;API&nbsp;。)<br />
2.&nbsp;包头转换被认为是有害的<br />
该作者相信在任何过渡情况下，要求I&nbsp;P&nbsp;v&nbsp;4&nbsp;和I&nbsp;P&nbsp;n&nbsp;g&nbsp;间动态包头转换将会造成几乎是<br />
不可克服的实际困难：<br />
(1)&nbsp;可以认为I&nbsp;P&nbsp;n&nbsp;g&nbsp;功能将是I&nbsp;P&nbsp;v&nbsp;4&nbsp;功能的一个超集。然而，协议间的成功转换要求<br />
被转换的两个协议的功能事实上应该相同。为此，应用需要知道它们什么时候通过<br />
IPng&nbsp;API&nbsp;和设在网络中某处的转换器与I&nbsp;P&nbsp;v&nbsp;4&nbsp;主机互通，以便只用I&nbsp;P&nbsp;v&nbsp;4&nbsp;功能。<br />
这是不现实的约束。<br />
(2)&nbsp;转换器的管理对大的站点而言是完全行不通的，除非转换机制是完全隐蔽和自动<br />
的。特别是任何转换机制要求为每个主机中的表格(如D&nbsp;N&nbsp;S&nbsp;表或路由器表)人工地<br />
保持专门标志以指示需要转换，这样做是完全不可能进行管理的。在一个有几千台<br />
运行多种操作系统的主机的站点上，主机在不同软件版本上前进或后退，使得继续<br />
用这种方法来不断跟踪所需要的这些标志的状态是不可能的。整个I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;的<br />
多样化，将会导致混乱、复合的失效模式和困难的诊断。特别是不可能遵守(&nbsp;1&nbsp;)的<br />
约束。<br />
实践中为了避免混乱，对转换所需要的知识、所涉及的站点将决不泄漏，并且如果<br />
还没有这样的知识的话，当需要时，应用程序不能将其本身限制在I&nbsp;P&nbsp;v&nbsp;4&nbsp;功能上。<br />
为了避免混淆，此处所讨论的包头转换和地址转换(&nbsp;N&nbsp;AT&nbsp;)不是同一件事。本文不<br />
讨论地址转换。本文不详细处理性能议题，但转换的另一个明显缺点是带来必然的<br />
开销。<br />
3.&nbsp;共存<br />
I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;基础设施(不论是公用的还是专用的)必须允许I&nbsp;P&nbsp;v&nbsp;4&nbsp;和I&nbsp;P&nbsp;n&nbsp;g&nbsp;在同一路由<br />
器和同一物理路径上共存。<br />
为了在不要求主机步调一致地更新，及不使用转换器的情况下，网络基础设施能更新至<br />
I&nbsp;P&nbsp;n&nbsp;g&nbsp;，共存是必须的。<br />
值得注意的是，这种需求并不强制使用有关公共的或是分离的方法来进行选路。作为共<br />
存机制，也不排斥使用封装。<br />
4.&nbsp;IPv4&nbsp;到I&nbsp;P&nbsp;n&nbsp;g&nbsp;地址映射<br />
人们必须明白过渡期间会遇到什么问题。虽然I&nbsp;P&nbsp;n&nbsp;g&nbsp;地址的自动配置可能是所期望的<br />
目的，如果在给定的站点上，I&nbsp;P&nbsp;v&nbsp;4&nbsp;和I&nbsp;P&nbsp;n&nbsp;g&nbsp;地址之间有一个可选的简单映射，那么过渡<br />
的管理就会大大简化。<br />
因此，I&nbsp;P&nbsp;n&nbsp;g&nbsp;地址空间应包含I&nbsp;P&nbsp;v&nbsp;4&nbsp;地址的映射，这样(如果一个站点或服务供应商愿<br />
意做的话)一个系统的I&nbsp;P&nbsp;v&nbsp;4&nbsp;地址能机械地被转换成I&nbsp;P&nbsp;n&nbsp;g&nbsp;地址，大多数倾向于加一个前<br />
缀。对每个站点而言，前缀不一定是相同的，可能至少是服务供应商指定的。<br />
这并不意味着这种地址映射会用作动态转换(虽然有可能是)，或将I&nbsp;P&nbsp;v&nbsp;4&nbsp;选路嵌入I&nbsp;P&nbsp;n&nbsp;<br />
g&nbsp;选路内(虽然有可能是)。主要目的是简化网络运行者的过渡规划。<br />
顺便指出，这样的需求实际上没有假设I&nbsp;P&nbsp;v&nbsp;4&nbsp;地址是全球唯一的。在建立I&nbsp;P&nbsp;v&nbsp;4&nbsp;和I&nbsp;P&nbsp;<br />
n&nbsp;g&nbsp;选路域与分级之间的关系上也没有太多帮助。没有理由设想它们之间是1&nbsp;：1&nbsp;对应关系。<br />
5.&nbsp;双栈主机<br />
无转换的逐步过渡是很难想象的，除非大部分主机同时能运行I&nbsp;P&nbsp;n&nbsp;g&nbsp;和I&nbsp;P&nbsp;v&nbsp;4&nbsp;。如果<br />
A&nbsp;想和B(&nbsp;I&nbsp;P&nbsp;n&nbsp;g&nbsp;主机)以及和C&nbsp;(&nbsp;I&nbsp;P&nbsp;v&nbsp;4&nbsp;主机)交谈，于是A&nbsp;或者B&nbsp;必须能运行I&nbsp;P&nbsp;v&nbsp;4&nbsp;和<br />
I&nbsp;P&nbsp;n&nbsp;g&nbsp;两者。换句话说，所有运行I&nbsp;P&nbsp;n&nbsp;g&nbsp;主机必须仍能运行I&nbsp;P&nbsp;v&nbsp;4&nbsp;。只能运行I&nbsp;P&nbsp;n&nbsp;g&nbsp;的<br />
主机在过渡期间是不允许的。<br />
这样的需求并不意味着I&nbsp;P&nbsp;n&nbsp;g&nbsp;主机真的有两种完全分离的I&nbsp;P&nbsp;实现(双栈和双A&nbsp;P&nbsp;I&nbsp;)，<br />
但是表现出好像是分离的。封装是兼容的(即两个栈中的一个可为另一个封装包)。<br />
显然，对双栈主机的管理，由于上面提到的地址映射而简化了。除了I&nbsp;P&nbsp;v&nbsp;4&nbsp;地址以外，<br />
只有站点前缀必须配置(人工或动态地)。<br />
在双栈主机中，即使IPng&nbsp;API&nbsp;和IPv4&nbsp;API&nbsp;是作为一个单个实体实现的，但在逻辑上是<br />
可区别的。应用程序将从A&nbsp;P&nbsp;I&nbsp;得知它们在用I&nbsp;P&nbsp;n&nbsp;g&nbsp;还是I&nbsp;P&nbsp;v&nbsp;4&nbsp;。<br />
6.&nbsp;DNS<br />
双栈要求隐含了D&nbsp;N&nbsp;S&nbsp;必须给I&nbsp;P&nbsp;n&nbsp;g&nbsp;主机回答I&nbsp;P&nbsp;v&nbsp;4&nbsp;和I&nbsp;P&nbsp;n&nbsp;g&nbsp;两者的地址，或将两<br />
者编码在一起的单个回答。<br />
如果在D&nbsp;N&nbsp;S&nbsp;中，一个主机附属于一个I&nbsp;P&nbsp;n&nbsp;g&nbsp;地址，但该主机实际上还没有运行I&nbsp;P&nbsp;n&nbsp;<br />
g&nbsp;，尤如在I&nbsp;P&nbsp;n&nbsp;g&nbsp;空间中出现一个黑洞—见下一点。<br />
7.&nbsp;智能双栈代码<br />
双栈代码可从D&nbsp;N&nbsp;S&nbsp;得到两个地址，用哪一个呢？多年的过渡期间I&nbsp;n&nbsp;t&nbsp;e&nbsp;r&nbsp;n&nbsp;e&nbsp;t&nbsp;将包含<br />
黑洞。例如，从I&nbsp;P&nbsp;n&nbsp;g&nbsp;主机A&nbsp;到I&nbsp;P&nbsp;n&nbsp;g&nbsp;主机B&nbsp;路上某处有时(不可预测)会遇到只运行I&nbsp;P&nbsp;<br />
v&nbsp;4&nbsp;的路由器，它将丢弃I&nbsp;P&nbsp;n&nbsp;g&nbsp;包。同样，D&nbsp;N&nbsp;S&nbsp;的状态也不一定与现实是一致的。D&nbsp;N&nbsp;S&nbsp;<br />
声称知道I&nbsp;P&nbsp;n&nbsp;g&nbsp;地址的主机可能在一特别的时刻并没有运行I&nbsp;P&nbsp;n&nbsp;g&nbsp;，因此到那个主机的I&nbsp;P&nbsp;<br />
n&nbsp;g&nbsp;包在传递时将被丢弃。知道一个主机具有I&nbsp;P&nbsp;v&nbsp;4&nbsp;和I&nbsp;P&nbsp;n&nbsp;g&nbsp;两种地址并没有给出有关黑<br />
洞的信息。对此必须有一种解决方案，这方案不能依赖于人工保持的信息。(如果这个不解<br />
决，双栈方法是不会好于转换方法的。)<br />
8.&nbsp;智能管理工具<br />
过渡期间需要一整套管理工具。为什么I&nbsp;P&nbsp;n&nbsp;g&nbsp;路由不同于I&nbsp;P&nbsp;v&nbsp;4&nbsp;路由？如果要转换的<br />
话，该发生在何处？何处有黑洞？(宇宙学家喜欢同样的工具。)今天的主机是否真正有I&nbsp;P&nbsp;n&nbsp;<br />
g&nbsp;能力？<br />
组播<br />
众所周知，I&nbsp;P&nbsp;n&nbsp;g&nbsp;必须支持组播应用，体系结构上一个明显的规则是：不论是L&nbsp;A&nbsp;N&nbsp;还<br />
是WA&nbsp;N&nbsp;线路，组播包不应在同一线路上经过两次。如果做不到这点，则意味着同时组播<br />
的事务处理最大数量会减半。<br />
L&nbsp;A&nbsp;N&nbsp;上的I&nbsp;P&nbsp;v&nbsp;4&nbsp;的一个负面特征是：轻率地使用物理广播包，诸如A&nbsp;R&nbsp;P&nbsp;(各种非I&nbsp;E&nbsp;<br />
T&nbsp;F&nbsp;盲目模仿者)协议。在大的L&nbsp;A&nbsp;N&nbsp;上，这将导致一系列不希望有的后果(经常是由于差的<br />
产品或差的用户，而不是协议设计本身造成的。)如有可能的话，体系结构上明显的规则是<br />
改用单播(或最坏情况，用组播)来代替物理广播。<br />
ATM<br />
网络工业界正在AT&nbsp;M&nbsp;上大量投资。没有I&nbsp;P&nbsp;n&nbsp;g&nbsp;提案似乎是可取的(从获得管理部门批<br />
准的意义上)，除非它是“AT&nbsp;M&nbsp;兼容”的，也就是要有一个如何运行在AT&nbsp;M&nbsp;网络上清晰<br />
的模型。虽然不马上需要一个像RFC&nbsp;1577&nbsp;那样十分详细的文件，但必须显示该基本模型是<br />
能工作的。<br />
类似的论点同样可用于X&nbsp;.&nbsp;2&nbsp;5&nbsp;、帧中继、S&nbsp;M&nbsp;D&nbsp;S&nbsp;等，但AT&nbsp;M&nbsp;是当前呼声最高的。<br />
策略选路与计费<br />
遗憾的是，这不能被忽略，许多人对此感兴趣。基金代理希望业务流流经提供基金的线<br />
路，且在以后他们要知道有多少业务流。计费信息也可用作网络规划和反向付费的根据。<br />
所以I&nbsp;P&nbsp;n&nbsp;g&nbsp;及它的选路过程允许根据详细的源和目的地址来指定业务流的途径。(作为<br />
一个例子，从M&nbsp;I&nbsp;T&nbsp;物理系输出的业务流和任何其他系输出的业务流可能通过不同的路由到<br />
C&nbsp;E&nbsp;R&nbsp;N&nbsp;。)<br />
满足该需求的一个简单途径是坚持I&nbsp;P&nbsp;n&nbsp;g&nbsp;必须支持基于供应商的寻址和选路方案。<br />
业务流的计费要求同样的详细程度(甚至更详细，例如f&nbsp;t&nbsp;p&nbsp;的业务流是多少，w&nbsp;w&nbsp;w&nbsp;的<br />
业务流又是多少)。<br />
两者都需要花费时间和金钱，并且不仅影响I&nbsp;P&nbsp;层，所以I&nbsp;P&nbsp;n&nbsp;g&nbsp;不该回避它们。<br />
安全性考虑<br />
公司网络运行者和校园网络运行者曾受到过好几次安全问题的困扰，他们对待此事比许<br />
多协议专家更认真。实际上，许多公司网络运行者希望在向I&nbsp;P&nbsp;n&nbsp;g&nbsp;过渡中，作为一个比其<br />
他任何议题更为紧迫的议题，安全性能得以改善。<br />
因为I&nbsp;P&nbsp;n&nbsp;g&nbsp;估计是一个数据报协议，限制了它为端到端的安全性所能做的工作，I&nbsp;P&nbsp;n&nbsp;g&nbsp;<br />
必须允许路由器中有比I&nbsp;P&nbsp;v&nbsp;4&nbsp;更有效的防火墙。特别需要基于源和目的地址以及事务处理<br />
类型的高效的业务流阻挡。<br />
看来需要同样的特征允许策略选路和详细计费来改善防火墙的安全性。讨论这些特征的<br />
细节超出了本文范围，但是看来不大可能在边界路由器中限制实现细节。为了检查有害的业<br />
务流，允许基于策略的源选路和/或允许详细计费，包必须携带某些三重验证的踪迹(源、目<br />
的地、事务处理)。可能所有I&nbsp;P&nbsp;n&nbsp;g&nbsp;可以在每个包中以某种格式携带源和目的地的标识符，<br />
但是标识事务处理的类型或甚至于个别的事务处理，是一个额外需求。<br />
声明和致谢<br />
以下是个人观点，未必代表我老板的观点。<br />
近几年来，CERN已经通过三个网络的过渡(由John&nbsp;Gamble&nbsp;解决的I&nbsp;P&nbsp;v&nbsp;4&nbsp;重编号，由Mike&nbsp;<br />
Gerard解决的Apple&nbsp;Talk从阶段I&nbsp;向阶段I&nbsp;I&nbsp;的过渡，以及由Denise&nbsp;Heagerty&nbsp;解决的DECnet&nbsp;<br />
阶段I&nbsp;V向DECnet&nbsp;/OSI&nbsp;选路的过渡)。如果没有从他们那儿获取知识，我是不能写出这个文<br />
件的。我也从许多人，特别是从I&nbsp;P&nbsp;n&nbsp;g&nbsp;董事会的各个成员的讨论或作品中，获益非浅。多<br />
位董事会成员及波音公司的Bruce&nbsp;L&nbsp;Hutfless&nbsp;提出了意义帮助阐明本文。不过意见是我本<br />
人的，并非董事会全体成员的共同意见。<br />
RFC&nbsp;1671&nbsp;IPng&nbsp;White&nbsp;Paper&nbsp;on&nbsp;Transition&nbsp;and&nbsp;Other&nbsp;Considerations&nbsp;<br />
向IPng&nbsp;过渡和其他考虑的白皮书<br />
1<br />
<br />
1<br />
RFC文档中文翻译计划<br />