rfc1752.txt

RFC规范的翻译稿

*需要对特殊鉴别算法的支持
*需要对秘密标题的支持
*需要对特殊秘密算法的支持
*“防火墙IPng 框架”被开发出来
2 背景
1980年初，即使是最有远见的TCP/IP开发者也没有想到因特网今天遇到的标度困难。1987年估计在将来的某个模糊点设计一个100000个网络的地址需求。[Callon87]我们将于1996年到达该标记点。在不久的将来，会出现许多互联网络的逼真投影。[Vecchi94, Taylor94]
而且，尽管当前32位IPv6地址结构能在16.7百万个网络上枚举超过40亿的主机，但即使是在理论基础上，实际地址的分配效率远小于该数目。[Huitema94]这种低效率被用A，B，C类地址分配的间隔所扩大。
在1990年8月的温哥华IETF会议中，Frank Solensky, Phill Gross 和Sue Hares计划当前分配速率将于1994年三月耗尽B类空间。
在B类地址的地方分配若干C类地址的补救办法介绍了其自身的问题，通过在主要路由器已经在以一个惊人的速率增长时扩展路由表的大小。
我们面临着要么接受限制增长速度和极限因特网的大小，要么接受用改变新技术或工艺的方法来中断网络的难题。
IETF于1991年11月在圣达菲的IETF会议上形成路由和地址（ROAD）组来探索该难题并指导IETF的发表。ROAD组于1992年3月在圣地亚哥的IETF会议上汇报了其工作。[Gross92]推荐标准的冲击涉及从“立即”到“长久”并包含采纳CIDR路由集合提议[Fuller93]来降低路由表增长的速率并推荐请求提议“为了更大的因特网地址，建立工作组来探索分离逼近”。
1992年春末，IAB发表了“IP 版本7”[IAB92]，同时发表在在ROAD组的CIDR签注中并推荐“一种直接的IETF研究计划来准备一个详细和有组织的计划，把CLNP作为IPv7的基础使用”。经过激烈的讨论后，IETF决定拒绝IAB的推荐标准并发表了由ROAD组推荐的提议请求。该请求于1992年7月在波士顿IETF会议上发表并建立了一些工作组来响应它。
在1993年7月阿姆斯特丹会议期间，一个IPng(IP下一代)决策处理（ipdecide）BOF会议召开。BOF“打算帮助再次把焦点放在非常重要的在IPng候选人中作出选择的课题上。BOF着重谁能带头为群体作出推荐标准并且应该用什么标准来达到该推荐标准的发表上”。[Carpen93]
3 IPng说明
1993年9月, Phill Gross,发表“IPng说明”的IESG主席。[Gross94]在该备注中他概述了ipdecide BOF的结果并在阿姆斯特丹完全公开了IESG。
*IETF需要向IPng的终止发展
*IESG有责任为因特网群体开发IPng推荐标准
*推荐标准制作处理过程应该公开并由IESG预先出版
*作为该过程的一部分，IPng WCs能带来新的里程碑和辅助IESG的其他指导
*在最终IESG推荐标准前应有足够的群体评论机会
备注还宣告了“一个暂时的，特别的，特殊IPng发行处理‘领域’”。Phill查询了当前IESG的两个成员，Allison Mankin(传输服务领域)和Scott Bradner(操作需求领域)，来担当新领域的主管。领域主管被给予了一个怎样调查各种各样IPng提议和怎样将其推荐标准作为IETF标准特殊权利。还需要制作一个特殊推荐标准。
*建立一个IPng董事会
*确保跟随着一个完全开放的过程
*开发紧急标准的理解和一个利用地址分配速率和路由表增长速率的时间约束
*如果批准，推荐采用分配原则的变动
*定义基于时间限制理解的IPng研究计划的范围
*开发一套清晰，简明的技术需求和IPng决议标准
*开发一套有关接受哪位当前IPng候选人的推荐标准
4 IPng领域
IPng领域形成以后，我们恢复了董事会。（附录B）董事会成员因其普通和特殊的技术专长而被选出。要求个人用其自身管理来批准过程中的参与者并确认他们懂得IETF处理。
我们着重确保一个宽带光谱所蕴涵的知识。主管是安全，路由，广大用户需求，终端厂商，Unix和非Unix平台，路由器厂商，理论研究者，协议体系和操作区域的，国家的和国际网络方面的专家。另外，董事会的一些成员已深入了每个IPng提议工作组。
董事会行使制定方向和该领域主管所需的预审阅实体的职能。董事会忙于每两周一次的会议访问，参与内部发函清单并积极响应广泛的因特网发函清单。董事会于1994年3月的西雅图和1994年7月的多伦多IETF会议期间举行开放式的会议。为确保IPng处理尽可能开放，我们在这些会议中做了笔记并将其出版了。另外，我们把内部IPng发函清单档案放在匿名的FTP网站上。（Hsdndev.harvard.edu:pub/IPng.）
5 ALE工作组
在耗尽IPv4地址空间之前为了决定IPng研究计划的范围，我们需要对时间剩余进行合理估计。如果时间剩余大约与展开配置的所需相同，则我们要选择能调整地址局限性的IPng，因为我们不需要开发任何其他特性的足够时间。如果还有更多的可利用时间，我们可考虑其他的改进。
IETF于1993年生成了一个地址生存期期望值（ALE）工作组来“开发基于当前已知和可利用技术的IPv4地址空间剩余生存期的估计”。[Solens93a] Cisco 系统公司的Tony Li和FTP软件的Frank Solensky是联合主席。IETF还掌管工作组来考虑是否开发更苛刻的地址分配并且应用原则要为转换提供更多时间。
5.1 ALE 投影
ALE工作组于1993年11月休斯顿，[Solens93b]1994年3月西雅图[Bos93]，和1994年7月多伦多[Solens94]IETF会议期间相遇。他们在西雅图会议上计划，随后在多伦多会议上确定使用当前分配统计学，因特网将于2005和2011年间耗尽IPv4地址空间。
IPv4-ale的某些成员和广阔因特网发函清单在查询该投影可靠性中调用。它由于过于乐观和过于悲观而受到批评。
有些人指出该类型投影在IP应用中造成了无范例替换的假设。如果有人要开发一个新的“应用杀手”。IP地址需求增长的结果使之成为对可利用时间的高估。
可能还存在用于产生投影数据的问题。InterNIC（因特网信息中心）在大程序块中分配地址给区域网络信息中心（NIC）和网络供应商。NIC和供应商将地址重分配给用户。ALE投影利用InterNIC分配而不考虑终端用户地址分配的实际速率。由于数据精确性似乎很高，，故他们用该方式制作投影。由于假设大块分配速率将继续进行，而它不属于这种情况，故使用已删除数据时可能增加一个级别的高估。
这些因素降低了ALE估计的可靠性，但总的来说，他们需要IPv4地址空间中充分的时间剩余来考虑当考虑开发，测试，和配置时间需求时，在IPng中除扩展地址大小外增加其他特性。
5.2 路由表大小
因特网图象缩放中的另一篇文章是增加中心路由器所需路由表的大小。采用CIDR块地址分配和聚集路由暂时缩小表的大小，但现在他们都再次扩展了。供应商需要在该集合中对其路由做更猛烈的广告。供应商必须建议新用户为整个因特网群体的最好利益对其网络进行重编号。
如果该文章被忽视和找不到能跟上表大小增长的路由器，则IPv4地址空间的耗尽问题是未决议。执行CIDR之前，中心路由表以大约1.5倍存储技术的速率在增长。
我们还应注意尽管IPng地址是以集合思想设计的，转换IPng不能解决路由表大小问题除非严格分配地址来最大化该集合的影响。路由的有效广告能被保持下来因为如果用户决定更换供应商，IPng包括地址自动配置机制来允许简单的重编号。从多个供应商处接受服务的用户可限制任何路由集合的极限效率。[Rekhter94]
5.3 地址分配原则推荐标准
IESG主席掌管IPng领域来考虑更严格的分配原则推荐标准，利用已分配地址，或作出一系列努力来对因特网的重要部分进行重编号。[Gross94]
以ALE投影的观点，IPng领域主管认可当前地址分配原则。任何人都不能对已分配的未充分利用地址进行利用或对因特网的主要部分进行强制性的重编号。我们鼓励网络服务供应商在对用户网络进行重编号以便确定供应商的CIDR分配方面协助新用户。
ALE工作组建议我们考虑在A类未分配地址空间外分配CIDR类型地址块。IPng领域主管赞成该推荐标准。
6 IPng技术需求
IESG在RFC1380[Gross92]中提供了标准类型的概要，我们把它用于决定IPng协议的适合性。IETF精练了对带有选择标准BOF推荐标准的适当标准的理解，该标准于1992年11月在华盛顿IETF会议期间制定。我们需要增加一些决定需求的附加输入并发行一个论文命令。[Bradner93]该命令，作为RFC1550发行，想到达传统IETF客户的内外层用最广泛的应用来获取对数据网络协议需求的最广泛理解。
我们收到响应RFC1550请求（附录E）的21张论文，和从各种行业获得的回应；有线电视行业[Vecchi94]，网络式行业[Taylor94]，和电力行业[Skelton94]。此外，我们还收到涉及到军事应用[Adam94,Syming94,Green94]，ATM[Brazd94]，移动性[Simpson94]，帐目管理[Brown94]，路由[Estrin94a，Chiappa94]，安全性[Adam94，Bell94b，Brit94，Green94，Vecchi94，Flei94]，大型网络公司[Britt94，Fleisch94]，转换[Carpen94a，Heager94]，市场接受度[Curran94，Britt94]，主机执行[Bound94]，和一些其他文章。[Bello94a，Clark94，Ghisel94]
这些论文，于1994年3月在西雅图IETF会议期间召开的下一代需求（ngreq）BOF（由Jon Crowcroft和Frank Kastenholz主管），有关IPng领域董事会和大型网络发函清单的讨论都被Frank Kastenholz和Craig Partridge在修订其早期标准草案[Kasten92]中用于产生“选择下一代IP（IPng）的技术标准”[Kasten94]。该文献是IESG主席管辖内所需的“清晰和简明的技术需求和IPng决定标准”。我们把这些文献作为评估IPng提议时的基本原则。
6.1 IPng技术标准文献
文献中描述的标准包括：（取自于Kasten94）
*完整说明-提议必须完整描述被提议的协议。我们必须通过参考特殊文献选择一个IPng，而不是将来操作。
*结构简单-IP层协议应尽可能简单，除了IP层，将函数定位于别处能在协议层得到更适当地处理。
*标度-IPng协议必须允许至少10*9大小叶网络的鉴别和寻址（并且更加适合）
*拓扑复杂度-路由结构和IPng协议必须允许多种不同网络拓扑。他们不能假设网络的物理结构是一棵树。
*执行-技术状态，商业级路由器必须能以通常使用的，商业上可获得的，高速多媒体的速度处理和传送IPng通信量
*坚固的服务-网络服务及其联合路由和控制协议必须坚固
*转换-协议必须有来自于IPv4的简单转换设计
*多媒体独立性-协议必须通过许多不同LAN，MAN和WAN多媒体网络执行，该网络有从每秒一位到每秒几百千兆范围的独立连接速度
*数据报服务-协议必须支持不可靠数据报发送服务
*配置简单-协议必须承认简单和大量分布式的配置和操作。需要主机和路由器的自动配置。
*安全性-IPng必须提供一个安全网络层
*独特的命名-IPng必须为全球，普遍存在的因特网中所有IP层对象指定独特的命名。这些名字也许有或没有任何定位，拓扑，或路由有效性
*访问标准-定义IPng及其联合协议的协议应能象IPv4和相关RFC那样可自由访问和重分配。没有对执行或出售IPng软件的相关说明注册费。
*多点传送支持-协议必须支持单点传送和多点传送。需要多点传送的动态和自动路由
*可扩展性-协议必须能扩展；它必须能通过扩展来满足将来因特网的服务需求。扩展必须是不需要网络软件升级就可实现的
*服务类型-协议必须允许网络设备用特殊服务类型联合信息包并为其提供该类型指定的服务
*移动性-协议必须支持可移动主机，网络和因特网
*控制协议-协议必须包含对测试和调试网络的基本支持。（例如PING和TRACEROUTE）
*通道支持-IPng必须允许用户在基本因特网架构顶端建立个人因特网。必须支持基于IP的个人因特网和非基于IP的个人因特网（例如CLNP或AppleTalk）
7 IPng协议
IPng领域形成的时候，IETF已把一个相当大数目的IETF研究计划瞄准于解析因特网中的编址和路由问题。已经做出了一些提议并且有些提议达到了受工作组特许的水平。许多这样的组随后合并成了一个更一致的组。这些研究计划代表了对我们所面临的文章的不同观点和寻找不同方面的最优化解决办法。
1992年2月因特网群体发展成4个分离的IPng提议[Gross92]，“CNAT” [Callon92a]，“IP Encaps”[Binden92a]，“Nimrod”[Chiappa91]，和“简单CLNP”[Callon92b]。1992年12月，又形成了三个提议；“P因特网协议”（PIP）[Tsuchiya92]，“简易因特网协议”（SIP）[Deering92]，和“TP/IX”[Ullmann93]。1992年3月的圣地亚哥IETF会议后，“简单CLNP”发展成“含有更大地址的TCP和UDP”（TUBA）[Callon92c]并且“IP Encaps”发展成“IP地址封装”（IPAE）[Hinden92b]。
1993年11月，IPAE与SIP合并但仍保留SIP的名字。这个组与PIP合并，合成工作组叫做“简易因特网协议+”（SIPP）。与此同时，TP/IX工作组将其名字改为“因特网公用体系”（CATNIP）。
这些提议没一个是错的。由于因特网的扩展，所有这些提议在为我们面临的障碍提供一条途径时起作用。IPng领域的任务是确保IETF能理解所提供的提议，从提议中学习并且在提供将来最好的建立基础时，为解析基本文章的最佳路径提供一个推荐标准。
IPng领域评估了三种RFC1550论文CAATNIP[McGovern94]，SIPP[Hinden94a]和TUBA[Ford94a]中描述的IPng提议。IESG把Nimrod作为一个象IPng候选人一样的研究项目进行了查看。由于Nimrod描绘了将来可能的因特网路由策略，我们需要一篇描述任何需求的论文。Nimrod将把IPng加到处理请求中去。[Chiappa94]
7.1 CATNIP
“因特网普通架构（CATNIP）”被构思成一个收敛协议。CATNIP与CLNP，IP和IPX结合起来。CATNIP设计为任意传输层协议提供使用方法，例如：TP4，CLTP，TCP，UDP，IPX和SPX，运行于任何网络层协议格式：CLNP，IP（第四版），IPX，和CATNIP。要注意细节，对于传输层协议（例如TCP）来说一个终端使用一个网络层且其他终端使用其他网络协议的适当操作是可能的，例如：CLNP。[McGovern94]
“目标是为了提供因特网，OSI，和Novell协议间的公共范围，并把因特网技术推向刻度和下一代网络技术的实现。”
“CATNIP支持OSI网络服务通路点（NSAP）格式地址。它用高速缓存处理提供高速执行路由中下一个中继段的快速鉴别，就象获得一个有效高速缓存处理时，允许省略地址的网络标题的缩写。网络层标题的固定部分运载着高速缓存处理。”[Sukonnik94]
7.2 SIPP
“简易因特网协议+（SIPP）是IP的新版本，它被设计成从IPv4进化来的版本。它是IPv4的自然增量。其设计目的不是去掉IPv4的基本步骤。IPv4的运行功能保存在SIPP中。不能运行的功能已被删除了。它可被视为网络设备中的一个标准软件升级程序的安装并能与当前IPv4共同使用。其配置策略是不被设计成任何“标记”。SIPP被设计成在高速操作网络（例如：ATM）中能很好的运行并且同时对低带宽网络（例如：无线电）依然有效。此外，它还为不久将来所需要的新网络功能性提供了一个平台。”[Hinden94b]
“SIPP将IP地址的大小从32位增加到64位，以支持更高级别地址层次和更大数目的可寻址节点。SIPP编址能用一个等同于IPv4稀疏信号源和记录路由选件的装置，通过一个用以鉴别拓扑区域而非单个节点的叫做“串地址”的新地址类型，以64位为一个单元进行进一步扩展。”
“SIPP通过用已编码的IP头选件留出更有效传输的方式进行改变，选件长度的限制较松，未来引介新选件更灵活。它还具有一个新性能，通过被添加来对属于为发送端请求特殊处理的特殊通信“流”信息包进行标记，例如：服务或“实时间”服务的非默认属性。”
7.3 TUBA
“CLNP编址网络（TUBA）上的TCP/UDP协议寻找最小化与迁移到新IP地址空间联合的冒险性。此外，协议被允许因特网标度的请求所激发，这暗示着在大型宽带因特网中的因特网应用的方法。因此建议保存因特网传输和应用协议继续不改变操作，除了32位IP地址用更大地址代替。TUBA并不意味着要完全迁移到OSI上。它只意味着用CLNP，TCP，UDP代替IP，传统TCP/IP应用能在CLNP顶层运行。”[Callon92c]
"TUBA研究计划能扩展利用地址发送因特网信息包的性能，它能支持比当前因特网协议（IP）地址空间更高层次的地址。TUBA指定在特殊TCP和UDP中继续使用因特网传输协议，除了其ISO 8473 （CLNP）信息包封装。它允许继续使用因特网应用协议，例如：FTP，SMTP，TELNET等。TUBA寻找通过转换将当前系统从IPv4升级到ISO/IEC 8473 （CLNP）和相应大型网络服务通路点（NSAP）地址空间的使用方法。”[Knopper94]
“TUBA协议使用基于因特网主机（在CLNP上运行因特网应用）和DNS服务（返回更大地址）逐步更新的简单，长期的迁移协议。该协议需要更新路由器来支持CLNP（除了IP）的传送。尽管，该协议即不需要封装也不需要转换信息包和地址映射。IP地址和NSAP地址能在迁移期间被分配和独立使用。IP和CLNP信息包的传送和发送能独立完成。[Callon92c]
8 IPng协议审阅
IPng董事会在其每两周一次的电信会议并通过其发函清单讨论并审阅了后选提议。此外，大型因特网发函清单成员讨论了提议的许多方面，特别是当领域主管提出了许多刺激讨论的特殊问题时。[Big]
要求董事会每个成员为1994年5月19日和20日在芝加哥举行的会议评估一项预备提议。该会议以每个与会者的观点展开圆桌会议，包括领域主管，董事会和受工作组主席邀请的许多客人，每人一项提议。[Knopper94b]我们出版了这些评论和每个提议的更详细概略作为备注。
下表概述了根据IP标准文献需求的三个评审提议。他们不需要反映领域主管的观点。“Yes”代表审阅者觉得该提议满足指定标准。“No”代表审阅者觉得该提议不满足指定标准。“Mixed”代表审阅者有不同意见。“Unknow”代表审阅者觉得文件未提到该标准。
                           CATNIP          SIPP            TUBA
                           ------          ----            ----
   完整说明             no              yes             mostly
   简易性               no              no              no
   标度                 yes             yes             yes
   拓扑曲线             yes             yes             yes
   运行                 mixed           mixed           mixed
   坚固服务            mixed           mixed           yes
   转换                 mixed           no              mixed
   多媒体独立性        yes             yes             yes
   数据报               yes             yes             yes
   配置简单            unknown         mixed           mixed
   安全性               unknown         mixed           mixed
   独特命名             mixed           mixed           mixed
   访问标准            yes             yes             mixed
   多点传送             unknown         yes             mixed