IPng的推荐标准
The Recommendation for the IP Next Generation Protocol
January 1995
目录
1 摘要 6
2 背景 7
3 IPNG说明 8
4 IPNG领域 9
5 ALE工作组 9
5.1 ALE 投影 10
5.2 路由表大小 10
5.3 地址分配原则推荐标准 11
6 IPNG技术需求 11
6.1 IPNG技术标准文献 12
7 IPNG协议 13
7.1 CATNIP 14
7.2 SIPP 14
7.3 TUBA 15
8 IPNG协议审阅 16
8.1 CATNIP审阅 16
8.2 SIPP审阅 17
8.3 TUBA的评论 18
8.4 建议审查摘要 18
9 一个修订建议 19
10 假定 20
10.1 条件证书和推荐的时间 20
10.2 地址长度 20
11 IPNG介绍 21
11.1 IPNG和IPNG标准文档 21
11.2 IPV6 23
12 IPV6总括 23
12.1 IPV6的头格式 25
12.2扩充头 27
12.2.1 HOP-by-HOP 选择头（option Header） 27
12.2.2 IPv6头选项 28
12.2.3路由头 29
12.2.4断片头 31
12.2.5鉴定头 32
12.2.6隐秘头（Privacy Header） 33
12.2.7端对端选项头 35
13 IPNG 工作组 35
14 IPNG评论家（REVIEWER） 36
15 地址的自动构建 37
16 转换 37
16.1 短期的转变 38
16.2 传输－长期 38
17.其他的地址系列 39
18.对其他IETF标准的影响 40
19.非IETF标准和产品的影响 41
20.APIS 42
21.IPNG区域和工作组的未来 42
22.安全考虑 43
23.作者通讯地址 44
附录A－推荐标准摘要 45
附录B－IPNG区域董事会 47
附录C－涉及IPNG工作组的文档 48
附录D－IPNG 建议综述 49
附录 E－RFC 1550 白皮书 49
附录 F－辅助参考 52
附录 G－答谢 57
1 摘要
当预测显示因特网地址空间将变成一个持续增长的有限资源时，IETF于1990年后期开始作出选择IPv4后继的努力。一些关于探索解决地址局限性途径的并行努力已经开始，同时提供附加操作性。IETF 于1993年后期形成IPng领域来调查各种提议并推荐了如何继续下去。我们开发了一个IPng技术标准文档并评估了其中的各种提议。发现所有的都需要达到某个等级。在此评估之后，解析以前提议中问题中的一个机构提出了修订提议。IPng 领域导控器推荐IETF作为IPng来指定该修订提议，并把精力着重放在为提议标准状态生成一套定义IPng的文献上。
协议推荐标准包括一个带有承认精确路由集合的分层地址结构的简单化标题并且能足以满足因特网可预知未来的需求。协议还包括包级鉴别和带有即插即用自动配置的加密技术。改变IP标题选项方式的设计在改进操作的同时，被编码用来增加引介新选项特性的复杂度。它还包括标记通信量流程的能力。
特别推荐标准包括：
*当前地址分配原则适当
*当前没有利用未充分使用指定网络数的需求
*当前没有对因特网主要部分进行重编号的需求
*部分未指定A类地址空间的CIDR式分配需要考虑
*“简易因特网协议+(SIPP)说明。（128 位 版本号）”[Deering94b]作为IPng基础被采纳
*列于附录C中的文献是IPng研究计划的基础
*IPng工作组已形成，由Steve Deering 和Ross Callon领导
*Rovert Hinden是IPng研究计划的文献编辑者
*指定Dave Clark为IPng审阅者
*地址自动配置工作组已形成，由Dave Katz Sue 和Thomson领导
*IPng转换工作组已形成，由Bob Gilligan 和TBA领导
*转换和共存包括测试工作组是否有特许状
*IPv6环境中非IPv6地址使用的推荐标准和非IPv6环境中IPv6地址使用的推荐标准已被开发了
*为IPng的隐含，IESG委托对所有IETF标准进行审阅
*IESG分配当前IETF工作组一项把IPng列入考虑范围内的任务
*IESG需要修订旧标准文献的地方特许了一个工作组
*Informational RFC被请求或开发用于描述一些特殊的IPng API
*IPng领域和领域董事会继续研究直到主文献于1994年后期被作为提议标准提出
*需要对鉴别标题的支持
*需要对特殊鉴别算法的支持
*需要对秘密标题的支持
*需要对特殊秘密算法的支持
*“防火墙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
可扩展性 unknown mixed mixed
服务种类 unknown yes mixed
灵活性 unknown mixed mixed
控制提议 unknown yes mixed
信道 unknown yes mixed
8.1 CATNIP审阅
所有审阅者感觉到CATNIP未被完全指定。然而，CATNIP中的许多观念是很创新的并且许多审阅者感觉到CATNIP显示了所有提议的最好版本。网络服务附件点地址（NSAP）被很好的解决了并且路由处理是很创新的。
联合三个主协议族IP，ISO-CLNP和Novell IPX的目的是值得赞美的，我们的同感是开发者未开发足够具体的计划来支持该目标的实现。
所描述的计划遭受到了尝试成为现有网络协议协会一员的复杂性。一些审阅者感到CATNIP主要将IPv4，IPX和SIPP地址映射到NSAP中，并且同样不处理当前和将来因特网的路由问题。
审阅者感到CATNIP不太支持多点传送并且不明确处理象安全性和自动配置一样的重要主题。
8.2 SIPP审阅
大多数审阅者，包括偏向于其他提议的人，感到作为一个置身其中的审阅者，SIPP是一个“剪裁讲究，美学观点上漂亮的协议，它满足今天已知网络的需求。”SIPP工作组已成为最具动态并已产生许多详述生成一个完整协议说明所有必要方面的文件。
审阅者对SIPP的最大困难是含有IPAE，SIPP的转换设计。所有人的感觉是IPAE是致命弱点且不能在运作的因特网上可靠运行。
还有一些有关适当SIPP 64位地址大小的重要分歧。尽管你能列举出64位的10*15个端节点，但还是存在关于实际路由设计引介到底有多低效的不同观点。[Huitema94]大多数人感到64位地址不能为所需层次提供足够空间来满足未来因特网的需求。
此外，由于没有人对扩展地址和在SIPP中提仪的类型概念的传送有经验，审阅者都对这种方法论不适应。审阅者还感到该设计介绍了一些重要的安全论文。
有些审阅者感到SIPP未用任何方式对路由论文编址。特别是没有对开发拓扑信息或聚集有关网络领域信息方法的尝试。
最后，大多数审阅者在SIPP自动配置设计和一般SIPP中查询了复杂性标准。
8.3 TUBA的评论
评论者大都觉得TUBA提供的最重要的事情是是基于CLNP的，并且通过因特网配置CLNP的路由器。只有很少的认为CLNP主机的配置或实际运行在CLNP上的网络是重要的。另一个对TUBA的肯定是ISO集中的可能性和IETF网络标准。很大一部分评论者指出，如果TUBA是基于一个变化的CLNP的话，现有配置基础结构的好处将丢失，而且集中的可能性也很小了。
评论者认为包括基础结构的提出等CLNP的方面在头域内缺乏详细的消息队列，缺乏流动的ID域，缺乏协议ID域，和在TUBA中的CLNP错误信息的使用。CLNP包的格式或程序不得不被修改来解决这些问题的一部分。
在TUBA团体置疑IETF修改CLNP标准的能力。在我们Houston中的介绍中，我们认为“复制和运行”是合法的进程。这也是IAB在“IP协议7”中所提到的。[IAB92]TUBA团体得有达到多数人的意见的情况是正常的。包括CLNP文档作者的许多人坚持这不是问题，IETF能够修改基础的标准，其他一些人则坚持标准只能被ISO标准进程所改动。由于对IETF压倒性的意见认为IETF必须属于今后基础的标准，TUBA公社不同的意见成为了我们要忧虑的问题。
对于一大部分的意见，虽然包括某些偏见，TUBA提议的评论者更多的混合SIPP或CATNIP。明显的RUBA满足给对对大量主机的规模的能力的必要条件，支撑灵活的布局，是独立的媒体和数据报协议。对于评论家，TUBA满足其他的IPng必要条件不是那么清楚，并且这些看法是各式各样的。
在为得到NSAP分配计划各种不同的变化的路径选择，在使用NSAPs的对策上有的不同意见。如果路由器信息的集合程度所需要的话，因特网将限制NSAP在分配实际根本的网络布局上的使用。
8.4 建议审查摘要
摘要，在这三项建议中的重要问题。SIPP和TUBA都工作在因特网环境中但是各自都有自己的问题。其中一些问题在任何一个代替IPv4前都会被纠正，更不用说传播手段使因特网变为现实。在此之前所有的问题都必须被提及。CATNIP对于所考虑的问题远不完善。
9 一个修订建议
作为上述的建议，在1994年5月19号、20号的IPng‘BigTen’上讨论了许多当前IPng建议的强度和缺点。【Knopper94b】在会上Steve Deering 和 Paul Francis，两个SIPP工作组的负责人，给sipp邮件列表发送了一个信息详细的讨论了会上的细节和一些SIPP的改变。【Deering94a】
信息表明“循环（并且不意外的）关于SIPP的公司是：”
(1 IPAE的complexity/manageability/feasibility ,和
(2 SIPP的adequacy/correctness/limitations 路径形式和编址，特别是完成“额外编
址”的稀疏源路径。
他们“建议按下面的方法来改变SIPP编址：”
* 改变地址大小从8位变为16位（固定长度）。
* 指定选择使用IEEE 802 地址的16位的自动设置地址作为最低要求（“没有ID”）。
* 对于使用互联网层地址作为连接标志符的高层协议（例如TCP），需要他们使用完整的16位地址。
* 绝对不要使用路径标题作为扩展编码。
在相当多的关于sipp的讨论和关于改变建议的大型互联网邮件记录之后，SIPP工作组公开了一个新的SIPP修订版本【Deering94b】，一个新的编址架构【Francis94】，和一个简化的传输机制【Gillig94a】。以供IPng董事会讨论。
这些建议提出了一个多重IETF研究的来自SIPP研究的基本协议的综合，受TUBA影响的自动设置和传输份额，编址架构建立CIDR工作和路径标题SDRP商议的向外发展上。
10 假定
10.1 条件证书和推荐的时间
在制作以后的推荐标准时我们使用了两个假定的公用协定；IPng条件证书提供一套合理的IPng要求，特殊推荐标准必须现在开始制作，在这个观点上IETF必须进行单一的IPng研究。
正想上面所说，IPng技术条件文档【Kasten94】在许多邮件记录上已经发展成为一个开放的风格和大规模讨论的课题。我们相信必须有一个强有力的协议对IPng所能访问的技术要求公用组件进行正确的反射。
今年春天一个最原始的在大型互联网邮件记录上的主题讨论和公开Seattle IPng董事会，对于制定IPng推荐标准是必须的。一些人觉得额外的研究会帮助解决一些关键性的现在仍未解决的问题。选择单一协议将阐明公用组的景象，聚焦在IETF上的细节，和，因为公开研究项目必须用在任何点上，没有“及时”。
我们这个团体的解释，同时这也是大多数人达成的共识，就是应当执行这种特定的推荐。这与在ipdecide BOF间阿姆斯特丹[ Gross94 ]表达的观点一致，同时也和RFC 1500白皮书[Carpen94a]里的一些观点一致。如果我们再等6个月或一年的话，也就不会有特殊的理由认为这个基础的推荐有什么值得注意的不同。无疑当前一些未解决的细节应当推迟，但是，当前IETF精力的分散限制了详细决议类型的效率。在他们的努力之后，IETF集中力量的研究对我们的进展是一个更有效的方法。
10.2 地址长度
有关IPng设计可能性的最热烈地讨论方面之一就是地址的大小和格式。在这些观点中对IPng的运行有四个不同的看法：
1）.8字节地址的观点足够满足当前和今后因特网的需要（IP地址空间的大小成方形（squaring））。如果更多的话则会浪费带宽，增加无效的指派，引起一些网络中的问题（例如突变和别的一些低效联接）
2）.这种观点认为16字节是比较好的。因为这种长度的字节更容易支持自动构建技术，同时也更容易支持当前在全球路由布局联合里复杂的网络路由布局的体系。
3）.OSI NSAPs20个字节应当被用于进行全球同一的方面。
4）.这种观点认为变化的长度地址，比16字节大或小一些，应当被用来包含上述所有的观点，更进一步，地址的大小可以被调整到适合特定的环境需求，这就确保了有能力处理将来任何网络要求。讨论出来的好的技术和工程反对了以上所有的观点。
全体没有达成一致，但是，我们明显的感到大多数人的观点是固定的16字节长度地址是在效率性，功能性，适应性和全球应用方面总体最好的选择。
11 IPng介绍
在综合大量讨论和IPng董事会的意见之后，我们推荐在“简单因特网协议细则（SIPP）（128位ver）”[ Deering94b ]里描述的协议可改编作为IPng的依据，作为因特网的下一代协议。
我们也建议通过改编在附录C列表中的其它的文档作为这个协议中特殊协议的基础。
这个提议解决了现在遇到的大部分问题，特别是在地址空间、路由、传送和地址的自动构建方面有显著的应用。
它包括SIPP工作成就的主要基础：灵活的地址自动构建特点和一个被合并的转换策略。我们相信在IPng标准文档件中它提供简略的需求，并且提供一个框架充分解决将来可预测的Iternet组织的需求。
11.1 IPng和IPng标准文档
不久我们将出版一个详细的评述，它解决的问题是IPng如何在IPng标准文档[ Kasten94 ]里处理记录的需求。接下来是我们关于IPng适合标准的一些扩充：完整的规范－－IPng规范的基础，除了转换和地址的自动构建部分需要被定稿外，其它部分都是是完整的。
* 简单机制－－该协议简单，容易解释并且很容易建立范例。
* 空间－－128位的地址空间可解决9－10个网络事件的地址需求,事实上无效的地址分配是网络路由的固有属性。
* 拓扑结构的随机性——在网络布局上除了有限的255个hops外，IPng设计空间并没有限制。
* 性能——处理的简单性。在对列开头的集中。（the alignment of the fields in the headers)和
* 头检验和的消除，允许高性能的IPng数据流的处理。
* 高质量的服务－－IPng包括不受限制、高性能的服务和包装水平的鉴定，允许控制的安全和不用单独程序的路由保护。
* 传送－－IPng传送计划很简单，实际上是对现在市场上传送方法的封装。
* 媒体性能－－IPng保持了IPv4媒体的性能，在一些相关的媒体如ATM里，它可能可以在IPng流动平台上使用。
* 数据包服务－IPng保持数据包服务并将其作为它的基本操作模式，MTU发现（discovery)通道的使用有可能在一些情况下造成数据包（datagrams）使用的复杂化
* 体系结构－－IPng将有很容易也很灵活的地址自动构建结构，它将支持从一个单独网络的节点到一个复杂的Internet深层节点模式。
* 安全－－IPng包括为认证提供的专门的体制和在网络层实行的加密机制：这个安全的模式依赖于定义的密钥管理系统的存在。
* 唯一名称－－IPng地址可以被用来做全球唯一名称标志，虽然他们有topological意义。
* 对标准的有权使用－－所有的IPng标准将作为带有无限分配的RFC被公布。
* 多点传送的支持－－IPng明确的包含对多点传送支持。
* 可扩展性－－对扩充头的使用和扩充头操作的特性将允许在需要时将新的特征加入到IPng里，用来将存在网络中的中断减少到最小。
* 服务种类－－IPng头包括一个流动的标志，它可以用来满足服务种类的不同要求。
* 随机性——被提议的IPv4随机功能将在带有IPng的情况下工作。
* 控制协议－－IPng包括IPv4控制协议特征。
* 通道支持－－IPng的封装或带有IPng的其他议议是IPng规范描述的基础特征。
11.2 IPv6
IANA组织修正IPng已经到了第6版本。该协议被称作IPv6。该备忘录的其它部分被用来描述IPv6和它的特点。这个描述是一个简单的概括，文档自身的标准应当被最后的规范引用。我们也制定了大量的关于该协议细节的详细建议，程序要求完成该协议的定义，IETF工作组，我们觉得，有必要完成这个任务。
12 IPv6总括
IPv6是因特网协议的一个新版本，它的设计被认为是对IPv4一个革命性的进步。IPv4保持IPv4通常运行的所有功能。那些不运行或者偶尔使用的功能被除掉了，或者作为可选择的功能。同时增加了一些认为有必要的新功能。
* 扩展地址和路由性能－－IP地址规模从32为增加到128位，这提供了支持大量可扩充的地址模式，更多的地址层和更简单的自动构建地址。
多点传送的路由衡量能力通过增加一个“余值”（scope）给多点传送地址即可，因此，它的性能被大大提高了。
一个被称作“串地址“（cluster address）的新的地址类型，被定义用来识别topological域而不是单个模式。在带有IPv6源通道性能的联合里，串地址允许另外的模式控制它们的通信通道。
* 简化头格式——一些IPv4头域被分离或可选择的减少信息包处理代价的公案（common－case）过程；并且在地址大小的增加下，尽量降低IPv6头的带宽。即使IPv6地址空间比IPv4地址大4倍，IPv6头也仅仅比IPv4头大2倍。
* 对扩展头和操作的支持－－放置在单独标志头的IPv6操作被定位在IPv6头和传输层头之间信息包里。因为大多数的IPv6选项头没有被检查或被沿着包裹传递路径的任何路由器处理，只到到达它的目的地。这个机制是对路由器为信息包容纳选项方面作出的一个大的改进。另一个改进是，不同于IPv4，IPv6选项可提供随意的长度，并且不受限制的达到40位字节。这个性能加在它们处理过程的方式里，允许IPv6选项使用它们，这是IPv4中没有的。
IPv6的密钥扩展特征是在一个选项里的一种编码能力，如果该选项是未知的，则这种路由器或主机应当执行的该操作，它允许将这种附加性能的配置加入到带有最小中断危险的操作网络中。
* 对鉴定和机密的支持――IPv6包括一套提供认证和数据完整鉴定支持的扩充定义。这种扩充作为IPv6的基本功能，并且为它在各个被需要的运行方面提供支持。
* IPv6也包括一个对加密算法机密性提供支持的扩充定义，对这种扩充的支持使得在各个性能方面都很强健。
* 对自动购建的支持――IPv6支持自动构建的多重模式，从在一个单独网络里即插即用的节点地址配置到DHCP提供的full－featured设备。
*对源通道的支持――IPv6包括一个扩展的功能，提供源通道头对源需求通道协议的支持（SDRP）。SDRP的作用是用通道的起始部分去补充现存的inter－domain和intra－domain
的通道协议提供的部分。【Estrin94b】
* IPv4提供的简单而灵活的转换机制――IPv6的转换机制计划主要应用于下列四个基本的需要：
－ 升级需求。现存的IPv4和路由器的安装可以在任何时候升级到IPv6，只要它不依靠于别的主机或路由器还没有升级。
－ 升级配置。在没有任何先决条件下，新的IPv6主机和路由器能够在任何时候安装。
－ 简易的地址。现存的IPv4主机或路由器要更新到IPv6时，它们可以继续使用它们现存的地址，而不需要重新分配一个新的地址。
－ 低启动代价。在为了更新现存的IPv4到IPv6系统，或配置一个新的IPv6系统的情况下，少量或没有预备的操作是必须的。
* 服务性能质量――增加的一个新的功能是，为属于特殊通信“流程”（flows）的信息包贴上标志，该特殊流程是发送者要求的特殊处理，例如，指定的服务或实时服务的性能。
12.1 IPv6的头格式
IPv6的头，虽然比IPv4的头长，它是相当的简单。IPv4头的大量功能已经被重新定位或分离掉了。
＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋＋
| 版本| 流程表 |++++++++++++++++++++++++++++++++++++++++++++++++++++++++
有效负荷长度
下一个头
转换限制
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
| |
+ 源地址
+
| |
+ +
| |
| |
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| |
| 目标地址
+
| |
| +
|++++++++++++++++++++++++++++++++++++++++++++++++++++++
* 版本――英特网协议版本号。IPng 指定为第6版本号。（4位单位空间（4－bit field））
* 流程表――该部分可被主机用来标记那些网络中需要路由器特殊处理的信息包，例如，指定的服务或实时服务的性能。（28位单位空间）
* 有效负荷长度――IPv6头信息包的剩余部分长度。在一个8位字节里，允许包括64k的有效负荷长度，如果这个域的值为0，则实际的信息包的长度将建立在端对端的选项上。（16位无符号的整数）
* 下一个头――在IPv6的头后直接的对头类型进行鉴别。下一个头使用的单位空间和IPv4协议的一样。（8位选择单位空间）
* 转换限制――用来限制通道线路的碰撞。转换限制空间被信息包前进的每个节点消耗，如果转换限制被消耗到0的话，则该信息包就消失。
* 源地址――起始发送者发送信息包的地址。（128位单位空间）
* 目标地址――接收信息包的地址空间。（如果一个操作行程头还存在，它就有可能不是最终的接收空间。（128 位单位空间）
12.2扩充头
在IPv6里，随机网络层的信息可在单独的头里被编码，放置一个信息包的IPv6头和传送层头里。这里有少量的扩展头，被一个独特的下一个头值鉴定。[来自于附录C列表文档]
12.2.1 HOP-by-HOP 选择头（option Header）
Hop-by-Hop 选择头被用来提供给被沿着信息传送路径的每个节点检查的随机信息。Hop-by-Hop 选择头被IPv6头的下一个头值认证，它有如下格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 下一个头 | Hdr Ext Len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
. .
. 操作 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* 下一个头――在Hop-by-Hop选项头后即时的头类型认证。于IPv4协议使用同样的值。（8位选择单元）
* Hdr Ext Len――在8个8位字节单元里Hop-by-Hop选项头的长度。（8位不含字符的整数）
* 选项――包含一个或多个TLV编码选项。（可变的长度值，完成Hop-by-Hop选项头的长度为8个8位字节倍数长的一个整数）
12.2.2 IPv6头选项
两个当前定义的扩充头――Hop-by-Hop选项头和端对端选项头－可以带有一个可变的类型长度值（TLV）编码“选项”，它有如下格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 选项类型 | Opt 数据长度 | 选项数据
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
* 选项类型――选项类型的检验符。（8位单元）
* Opt 数据长度――在8位字节里的该选项的数据长度。（8位不含符号的整数）
该选项内容标志符在内部被进行编码，如果处理中的IPv6节点没有检验出选项类型，则执行它们两个的最高次序：
00－忽略该选项并且继续处理该头
01－放弃该信息包
10－放弃该信息包并发送一个未被承认的ICMP类型信息给信息包的源地址，指出这个未被承认的选项类型
11－还没有定义
在只有Hop-by-Hop选项的情况下，指定选项的第三最高次序（third－highest－order）位是否是这个选项的数据，当认证头存在的情况下这应当要包含一个完整的确认计算处理来检验。在途中改变的选项数据应当不在这个计算之列。
12.2.3路由头
路由头被IPv6源使用用来对列表中的一个或多个的中间节点（或者称为topoological 串）进行“访问”（visited），一直到信息包的目的单元。这个路由头的特殊模式被设计用来支持SDRP。【Estrin94】
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 下一个头 |路由类型=1 |M|F| 保留域 | SrcRoute长度 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NextHopPtr | 精确/模糊的位掩饰（ Mask） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. 源通道 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* 下一个头――紧接路由头后的头类型标志符，使用和IPv4协议同样的值域。（8位选择器）
* 路由类型――指示这种头支持的路由类型，值必须是1。
* MRE标志――应当汇报错误。如果该位设置为1，并且有一个路由器不能进一步的传送信息包（带有一个不完全的传送源路线），作为源路线的指定，该路由器必须产生一个ICMP错误信息。如果该位被设置位0，路由器就不能进一步的传送信息包（带有一个不完全的传送源路线），作为一个指定的源路线，路由器就不发送一个错误的信息给ICMP。
* F 标志――源通道行为的失败。如果该位被设置为1，它表示如果路由器不能进一步的传送信息包（带有一个不完全的传送源通道），作为被源通道指定的路由器，它必须设置下一个Hop Pointer域的值作为源通道长度域的值，因此后来的传送将单独在目标地址的基础运行。如果这位被设置位0，它表示如果路由器不能进一步的传送信息包，（带有一个不完全的传送源通道），作为源通道指定的路由器，必须放弃该信息包。
* 保留域的（Reserved）――将传送、忽略、和接收初始化为0。
* SrcRoute长度――源通道长度－在SDRP路由头里源路由elements/hops的编码。SDRP路由头可以用这个值计算出来（长度＝SrcRoute * 16 +8）。该值可能超过24。（8位无符号的整数）
* NextHopPtr-下一个Hop Pointer－下一个处理的element/hop的索引，在源通道里初始的element/hop应当被初始化为0。当下一个Hop指示器等于源通道的长度时，源通道就完成了。（8位无符号的整数）
* 精确/模糊位模式(Mask)――精确/模糊的位模式被用来指定一个运行的决议。如果下一个Hop指示器域的值为N，并且在精确/模糊位模式域的N－th位被设置为1，它表示下一个Hop是一个精确的源通道HOP。如果该位被设置为0，它表示下一个HOP是一个模糊的源通道HOP。（24位位模式（bit pattern））
* 源通道――IPv6地址的列表指示应当遵循的信息包的路径。源通道应当包含一个unicast和串地址的随机混合。（128位字节的整数倍）
12.2.4断片头
断片头被IPv6源用来发送一个有效负荷，它比适合于MTU到它们的目的地的的路径大一些。（注意：不像 IPv4，IPv6的分裂只被源节点处理，而不能被沿着信息包传送路径上的路由器处理）断片头被前述的值为44的下一个头处理，它有如下格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 下一个头 | 保留域的（Reserved） | 碎片偏移量 |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 认证 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* 下一个头――紧接片断头的头类型的认证。它同IPv4协议使用同样的值。（8位选择器）
保留域的（Reserved）， Res－将传送、忽略和接收初始化为0。
* 碎片偏移――偏移量，占8个8位字节的单元，随带的有效负荷，相对于初始的整体的有效负荷。（13位无符号的整数）
* M标志――1＝更多的碎片；0＝最后的碎片
* 认证――指派给初始有效负荷的值，不同于当前发送给带有同样IPv6源地址、IPv6的目的地址，和片段下一个头值的别的有效负荷。（如果一个路由头当前存在，则IPv6的目的地址就是那个最终的地址）鉴定值放在所有最初的有效负荷的片段的头部分，并且目的单元被用来证实所有的属于同样初始有效负荷的片段。（32位单元）
12.2.5鉴定头
鉴定头被用来提供鉴定和确保IPv6信息包的完整性。Non- repudiation可被提供作为带有认证头的鉴定法则，但是，它不提供这个头使用的所有的鉴定法则。在紧接处理的头里，认证头被值为51的下一个头所鉴定，它有如下格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 下一个头 | Auth 数据长度 | 保留域部分 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 安全的联合ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. 鉴定数据 .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
* 下一个头――紧接鉴定头的头认证类型。与IPv4协议域使用同样的值。（8位选择器）
* Auth数据类型――在8个8位字节的单元里的鉴定数据域的长度。（8位无符号的整数）
* 保留域――将传送、忽略和接收初始化为0。
* 安全的协会身份（Security Assoc ID）――IPv6源地址的组合，确认信息包属于起先建立安全联合的哪一个接收器。（32位单元域）
* 鉴定数据――指定的运算法则，要求用于鉴定信息包源和确保该信息包的完整。（可变长度单位域，一个8位字节倍数的整数。）
12.2.6隐秘头（Privacy Header）
隐秘头的作用是使待加密数据具有机密性和完整性，同时保护和发送隐秘头数据部分的加密数据。不但可在传送层（如UDP或TCP）体制上进行加密，而且一个完整的带自动寻址的IPv6也可被加密，这由用户的安全要求决定的。这种压缩的处理方式必须为整个初始的带自动寻址的信息包提供机密性。如果是在目前，该隐秘头就是一个信息包最后的单位元，它是没有被加密的。
隐秘头工作在主机之间、主机和安全网卡之间、或安全网卡之间。对安全网卡的支持允许可信赖的网络在没有安全的货币代价执行的情况下存在，同时对不可信赖的网络段的传送提供安全。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 安全联合身份(SAID) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. 初始化向量 .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 下一个头* | 长度 | 保留单元* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| 被保护的数据* +-+-+-+-+-+-+-+-+-+-+
| | 跟踪单元* |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
*被加密的
安全联合身份（SAID）――为这种自带寻址信息包提供的安全联合标志符。如果没有建立安全的联合，该单元的值就应当为0x0000。安全联合正常情况下是单信道的。正常情况下两个主机间的鉴别通信单元在使用中有两个SAID。（每个方向一个）接收信号的主机使用SAID的联合值和初始地址来区别当前的联合。（32位单元）
初始化向量――这个单元是可选的并且它的值依靠使用中SAID。例如，该单元可以容纳用加密算法加密的一块同步加密数据。也可以被用来容纳带有加密的一组初始化向量。通常，隐秘头的执行是对SAID值的使用，来确认是否该单元就是当前单元，和该单元的使用情况。（它的存在和长度依靠于SAID）
* 下一个头――被加密的――紧接隐秘头的之后的头类型标志符。于IPv4协议单元使用同样的值。（8位选择器）
* 保留单元――被加密的――在接收中被忽略。
* 长度――被加密的――在8个八位字节单元里隐秘头的长度。不包括起初的8位字节。（8位无符号的整数）
* 被保护的数据――被加密的-－该单元可以容纳一个完整的压缩型的IPv6自带寻址信息包，它包括IPv6头、0组或多组IPv6选项序列和一个传送层的有效负荷；或者它可以是紧接传送层有效负荷之后的一组0或多个IPv6选项的序列。（可变长度）
* 跟踪器――(依靠运算法则的跟踪器)――被加密的――目前支持一些加密算法的领域，这些加密算法需要被扩充。（例如，用块导向加密算法进行加密全部的块单元）或者具有很强的使用加密算法的认证数据能力，用来提供在没有认证的情况下信息包的机密性。（它的存在和长度依靠于SAID）
12.2.7端对端选项头
端对端选项头被用来提供一个可选择的信息，该信息只被信息包目的单元节点检查。端对端选项头被下一个头的值认证，该值属于直接前头的TBD的。它与HOP-BY-HOP选项头有同样的格式，但它不具备排除来自鉴定完整计算选项的能力。
13 IPng 工作组
我们推荐一个新的IPng工作组，它是IPv6协议规范的功能产品模式。该工作组将IPng领域主管的建议作为大纲，它是在该备忘录1994年7月由IETF提出的。我们建议该工作组应当将Xerox PARC中心的 Steve Deering和 Wellfleet中心的 Ross Callon.二位授予主席的位置。
该工作组的首要任务就是提出一套方案来定义这个基本功能、交互作用（interactions）、假设方案 （assumptions）和IPv6的信息包格式。我们推荐Sun Microsystems公司的Robert Hinden 作为这个文档主编。该文档列表于附录C中，将被该工作组使用用来构建最终文档设置的基础部分。
该工作组的工作如下：
完成IPv6的简介文档。
完成IPv6详细操作说明书。
完成IPv6的地址构建说明书。
完成IPv6封装各种媒体的说明书。
完成支持大于64KB信息包的说明书。
完成需要增加的支持IPv6的DNS说明书。
完成ICMP、IGMP和支持IPv6的路由器发明（discovery）的说明书。
完成为IPv6提供路径的MTU发明的说明书。
完成在IPv6通道里IPv6的说明书。
完成指派计划的暗示地址格式。
调整研究地址的自动构建功能的工作组。
调整NGTRANS和TACIT工作组。
完成支持头鉴定和加密功能的说明书。
工作组也应当考虑增加少量的可选择的功能，包括以下两个方面：
1）在本地IPv6的上下文关系中考虑IPv6头的压缩方法，多个IPv6信息包压缩在一个流程里，从而形成压缩的IPv6。
2）考虑支持指定的大量的最小化的MTU.
14 IPng评论家（Reviewer）
这就是当前IPng领域主管的任务，被提出的IPng工作组的主管和主席应当调整许多类似成就方面的积极性，从而直接面对当前IPng的不同方面。同时这也是有可能的，并且这是在当前看来它好像运行的很好而不能保持长时间工作的原因。在另外的一些原因中，IPng领域将最终被消解和解散它的主管。这也将变得在别的IETF领域的启动中，作为与IPng相关的行为有太大的不同之处。
我们建议IPng评论家被指定专门的责任来确保IPv6观点的一致性，从而继续和相关工作组保持一致。由于IPng努力部分之间交互作用的复杂本性和由于对许多IETF领域的IPng相关工作的指派，这个功能是必须的。我们建议MIT中心的Dave Clark负责这一部分。这将是一个有关On－going activities方面的长期任务。因为它是各个工作组、IAB和整个IETF的工作，因此IPng评论家就不仅仅是制定一个建筑上的决定。这个目标就是在它们到达功能和作用可能将面临危险的端之前找出不足和使人误解的地方。
15 地址的自动构建
当数据网络变得更复杂而至少需要避过一些复杂性和对“即插即用”功能的迫切需要时，用户就没有去理解网络体系结构细节或者知道网络软件在他们主机里如何工作的必要。在理想的情况下，一个用户应当可以打开一台新的计算机, 把它联入当地的网络，在没有特定信息的输入要求下“就”可以工作。由于安全的关系可能在一些环境里限制了提供透明的地址自动构建层的功能，但该机制必须能被代替支持在当地合适的情况下对自动机制的支持。
“即插即用”的基本的要求操作是：当第一次附属一个网络，或者因为主机移动或网络的标志符地改变，主机必须能动态地获得一个地址。这里也有其它地许多功能要求支持一个完整的“即插即用”环境。[ Berk94 ] 这些中的大多数必须在 IPv6 区域外编址，但是定义一个主机地址自动构建地焦点就是 IPv6 进程的一部分。
我们推荐一个新的地址自动构建工作组 ( addrconf ) ，大卫·卡茨作为Cisco 系统的副主席和Bellcore 的休·索姆森作为co-chairs形成改组。这个工作组的目的就是为动态分配给IPv6主机地址地设计协议。该地址配置协议必须适合大范围地网络布局,从而形成一个简单地单独网络不安全地全球网络联接。它应该也允许对管理控制层地改变，形成在非常小地疏忽情况下地完全自动操作。
这个工作组的范围是提出一个主机地址自动构建协议，该协议支持全范围内的布局和Pv6 使用管理环境。该意图是, 和IPv6 系统发展一起，地址地自动构建协议将提供最小的引导信息，必要时可以使主机获得进一步的配置信息 ( 例如在 IPv4里 由 DHCP 提供了 ) 。该范围不包括路由器配置或其它主机地配置功能。然而该工作组必须在这个范围里调查并且将这个工作和与之相关功能（包括系统发展）之间的关系写成文档， DNS自动登记，服务发展（discovery），和广域主机购置的功能，可以推动这些功能地统一。[ Katz94a ]
希望工作组能在 1994 年左右完成这个工作，同时在那时解散。该组的“IPv6 地址自动构建体系结构” [ Katz94b ]草稿文档作为这个工作地基础部分。
16 转换
因特网从IPv6到IPv4 转换面对两个单独地需要。短期的是需要定义一个专门地技术和方法来对IPv4网络进行转换，包括因特网，IPv6网络和IPv6 因特网。长期的是需要一个转换的长期的操作计划编制, 包括允许分散移动策略的发展方法,当两个协议都是基础结构的一部分时，应当给予理解这个长期的共存分枝，交互测试是被要求来保证将来英特网的可靠性和可管理性。
16.1 短期的转变
任何 IPng 转换计划必须要充分考虑供应商将提供哪一种设备类型和网络管理配置。 IPng 转换计划必须要定义一套程序，用来成功的执行供应商愿意包含他们机制的功能函数。即使这有好的观点建议使用这个特殊的功能。例如头转换，如果产品存在的话，有一个内在的操作比没有好。
我们建议一个新的NGTRANS工作组由Sun Microsystems公司的 Bob Gilligan和 xxx公司的yyy作为co-chairs来设计这个机制和程序，从而支持从IPv4到IPv6 的因特网转换，同时给于在首选的程序和技术上的建议。
这个组的工作将围绕下列 3 个方面：
* 定义一个从 IPv4 转换到 IPv6 的进程的英特网程序。作为这个成就的一部分，该组将提出一个关于解释通常因特网社区在转换中使用的机制文档，同时包含这个转换是如何工作的、在这些机构的操作中底层结构的展开状态，和应用软件开发者假想的协议混合转换功能函数的类型。
* 定义和指定供应商在主机，路由器，和别的为转换提供的英特网的组成的强制和可选机制。双栈，封装和头转换机制都必须被定义, 也可使用这些机制的不同联合主机之间的交互。这个指定的产品将被用户使用用来执行实现这些 IPv6 系统。
* 有关具体的操作计划为英特网执行从 IPv4 到 IPv6 的转换工作。这个工作的结果将是为网络操作员和因特网订户提供执行的一个转换计划。
工作组在1994年末完成任务并在那时解散。在工作开始的时候工作组使用“简单的SIPP传输协议（SST）”【Gilig94a】浏览文档。
16.2 传输－长期
相当数量的传输相关的课题额外的增加了IPv4到IPv6机制和它们的扩展，操作和相互作用的定义规范。迁移到一个新技术或已存在科技的新版本的分支和过程必须充分理解。
我们建议传输和共存包括测试工作组（TACIT），在几个月之前开始，浏览一些基本的发行相关联的对业已存在的因特网的新科技的扩展。TACIT工作组将注意力放在一般的发行传输上并且对于即将到来的IPv6传输不加限制。因为，扩展到IPv6（IPv6ng）需要时间。在那一点上，他们需要展开到现在已经存在的因特网上。相对于NGTRANS工作组，TACIT工作组将更具可操作性，且继续进入到实现IPv6传输。
探测的主要目的是：
* 使当前传输的扩展协议扩展到一个新的协议上去，当调节均匀性和分散性管理层。
* 由于它不可能也很难代替所有的现存的系统或软件，因此了解性能和新协议和已存在的协议长期共存的操作是很重要的。
* 因特网必须考虑一个实用程序。当一种新科技能够扩展时我们要看它是否可用于大规模的情况。严格的结构和相互的测试必须是预先扩展阶段的一部分。测试增加的性能和稳定性将提供特别的挑战。WG将决定是否从OSPF，BGP4和CIDR扩展中学到一棵，AppleTalk 1 到2 传输，Decnet 的段位4到5计划和传输，在其中。
TACIT工作组将研究新科技扩展的每一种情况并且开发大量的文档以帮助使用者和受了影响的数据网络和IETF管理人员：
* 在转换和共存中的细节描述问题区域，都是预期的建立在课程学习和观察作为IPv6处理的过程。
* 推荐特殊的测试过程。
* 推荐共存操作过程。
* 推荐平稳的转换计划。
[Huston94]
17.其他的地址系列
当有一个或多个网络协议已经扩展时或者有效计划承担建立一个综合网络地址计划时有很多种环境。在这种情况下可以试验综合IPv6到环境中去，通过使用存在的地址计划定义所有的或部分的IPv6地址。这样做的好处是它允许在多重协议家族中统一管理地址空间。普通地址的使用可以帮助其他的协议到IPv6时简化传输。
如果存在的地址是世界上唯一的并且和网络拓扑学相一致这就是合理的建议。IETF必须和其他的组织合作发展算法可以用于地图地址在IPv6和其他环境中。全球与之相类似的地图必须提供一个无歧义的1到1地图在专用地址间。
建议为Novell IPX地址，一些OSI NSAPs类型，E164地址和SNA地址开发新的算法。每一种可能性都必须小心检查以确保算法解决更多的问题。在一些情况中最好推荐使用本地的IPng地址计划开发代替，或者一个IPv6地址使用非IP环境。【Carpen94b】
我们推荐，连接其他的组织推荐关于使用非IPv6地址在IPv6环境中并且IPv6地址在非IPv6环境中的开发。
18.对其他IETF标准的影响
许多当前的IETF标准受到了来自IPv6的影响。至少在目前51种因特网标准中的27种必须重新为IPv6修订，至少20种汇票标准中的6种和130种申请协议中的25种必须修订。【Poste194】
在一些订正中只要对原文进行简单的修订，例如，在许多RFCs中的IP地址在过去作为“32位IP地址”甚至许多在协议中使用的协议没有被定义。所有的标准记录文档必须被检查看是否有相关的引用。
在剩余的许多协议订正中，包括包格式，这些都被要求。在许多情况下地址作为数据元素携带并且对地址的大范围的修订格式在函数模式中没有效果。
在剩余的一些协议中，协议的一些操作将作为IPv6的结果改变。例如，安全和源路径机制将在根本上从IPv4变为IPv6。依靠IPv4的协议和申请将重新设计为IPv6下的等价函数。
在一些情况下将决定是否一些RFCs将变为历史，例如EGP【Mills84】和IP上的ARCNET【Provan91】
IPng 工作组的基础将对此中的一些进行编码，存在的IETF工作组能够工作在其他上，当新的工作组来处理它们时。IPng 工作组将对定义新的ICMP，APP/RARP，和UDP负责。它将同样审查RFC1639，“FTP通过大地址操作（FOOBAR）”【Piscit94】和RFC1191“MTU目录的路径”【Mogu190】
存在的工作组必须检查订正一些路径协议：RIPv2，IS－IS，IDRP和SDRP。一个新的工作组可能需要OSPF。
存在的DHCP工作组修订DHCP并且检查BOOTP。
一个TCPng工作组即将成立，新的工作组将用来处理例如SNMP，DNS，NTP，NETbios,TCP 上的OSI，主机请求，和像通过多种媒体定义的IP习惯的像 Kerberos那样的RFCs。
额外的标准记录RFCs移动有许多信息和试验性的RFCs，这些RFCs将影响很多因特网标准的制订（这些标准记录RFCs正是我们所需要的）。
我们推荐IESG 委托审阅所有的标准记录RFCs以确保所有的有影响力的文档的编译。我们推荐IESG通过在他们建议上的IPv6进一步理解改变当前的IETF工作组，为了支持IPv6适当的修订文档。
我们推荐IESG特许新的工作组，这些工作组需要修订其他的RFCs标准。
19.非IETF标准和产品的影响
许多产品和使用者的依赖大小或IPv4结构地址的申请需要修改为工作在IPv6的格式下面。当IETF能够促进在非IEFT标准和产品上的IPv6的影响的调查时，对其他标准体和机关负责。
非IETF标准而被IPv6影响的例子包括POSIX标准，开放软件基础的DCE和DME，X－Open，Sun ONC，Andrew文件系统和MIT's Kerberos。许多产品提供指定的网络安全包括防火墙类型设备及与之相关的将扩展以支持IPv6。
20.APIs
传统的描述是IETF没有“做”APIs。有许多的理由，一个最为普通的理由是TCP/IP的应用环境很多，有很多操作系统，程序语言和平台。面对这种复杂情况IETF无法定义一种独立于语言和操作系统的接口。
我们感觉历史上IETF避免处理APIs的趋势在IPv6中可能改变。我们感觉在一些规范情况中流行的独立的APIs类型是修改形式的普通解答。
需要IPv6的文件证明。
对一些新情况，我们推荐RFCs的相关信息必须被征求或开发。个别情况，Berkeley－style socket接口，UNIX TLI和XTI接口，和WINSOCK接口必须指定目标。一个已经存在的文档必须开发socket 的API描述。【Gillig94b】
21.IPng区域和工作组的未来
在Houston IETF会议的提示中，我们指出现存的IPng建议性的工作组必须紧紧的面对已制作的标准。每一个工作在技术上的工作组必须对他们的IPng区域进行额外的申请并且技术不能丢失。
因为多伦多IETF会议使现存的IPng工作组恢复到因特网区域。工作组成员决定结束他们的工作或继续一些他们的效果。如果他们选择继续，工作组的特性必须改变，因为他们不再存在一个IPng候选。
在多伦多SIPP工作组的主席要求SIPP工作组必须结束。TUBA工作组的主席要求TUBA工作组必须理解这些间隙直到大量的处理文档完成，在每一次他们请求工作组必须包括。
我们推荐IPng区域和它的董事会一直持续到基本文档在1994年晚些时候或1995年初变为标准并且在这段时间之后区域必须解散并且这些IPng区域工作组将移到IETF区域。
22.安全考虑
因特网的安全不再被询问。它是有效区域的主题，许多会议和工作组。几乎所有的注意力都忽略了，指出许多地方的可能的安全级别已经超出了当前或未来因特网的要求。大量的RFC 1550白皮书规范指出发展有效安全的要求【Adam94，Bell94b，Brit94，Green94，ecchi94，Flei94】“认识到未来的信息要求”。【Nat94】
在1994年2月，IAB召集了一个在因特网构架安全上的研究组。研究组的报告【IAB94】包括一个安全问题区域的考察和制作许多推荐标准来发展因特网提供给它的使用者的安全级别。
我们感觉一个在因特网上的一个基本安全级别的发展是重要的对它的持续成功。使用者必须能够承担来自贿赂，转换的风险。希望使用因特网去办理商务的组织希望对他们的代理银行有高级别的担保，并且他们的通讯也必须安全。这个目标是提供强有力的保护作为课程的内容通过因特网。
IAB报告指出，许多必须的工具并不是协议工作层的函数。这些高级别的工具必须在他们出现时在因特网工作层保持高度的安全。当我们希望许多高度安全的包裹对特殊的因特网使用者时，对于基本的包级别鉴定必须提供足够的需要，普遍的，通过因特网的安全基础设施。
最好对加密的鉴定分开支持。一个能够使用两个独立的函数。有许多信任鉴定是充分的并且其他的数据交换必须保证私人隐私。
我们推荐IPv6作为基础和需要的函数支持包鉴定。依靠支持这种申请的应用必须能够在每一个IPv6上实现。支持规范鉴定算法是必须的，而支持额外的算法是可选的。
我们推荐支持的鉴定标题技术必须在所有的IPv6平台上实现。
我们推荐需要支持规范鉴定算法。规范算法必须被提出作为IPv6文档所提供的推荐标准。
我们推荐在IPv6中实现保密标题。
我们推荐需要对保密鉴定算法提供支持。规范算法必须及时决定，IPv6文档必须提供推荐标准。
非常清楚的是，一个密钥管理基础构架为了使用鉴定和加密标题是必须的。即使如此，定义一个这样的基础构架超出了IPv6的影响范围。我们在这一区域on－goingIETF是能动性的。对这些能动性IPv6 传输工作组必须协调好。
鉴定的使用和加密可能会增加开销并且影响系统性能但是对于安全的多的基础构件这是值得的。这将减少软件和硬件的关联。
在因特网上防火墙的使用越来越普级。我们希望鉴定的出现和IPv6的保密功能将减少防火墙的需求，但在我们可以预见的未来防火墙将继续被使用。我们感觉到防火墙的开发者将以最好的方式设计并配置它们，当它们工作在IPv6的环境下时。
我们推荐一个“IPv6防火墙的机构”必须发展。这种机构开发方式使鉴定标题能够增强防火墙技术并且IPv6包的细节必须被防火墙分析。
一些安全特征需要额外的研究。例如，在【Vecchi94】中指出的那样，即使在非军事环境下，仍需要程序去阻挠传输分析。这将由加密封装的使用来决定，但是这和其他相近的要求必须通过IETF安全区域编制一个on－going基础。IPv6的设计必须灵活以支持以后的安全功能。
我们相信IPv6和它的固定安全功能必须提供基础在因特网上能够连续的扩展它的基础和使用者基础。
23.作者通讯地址
Scott Bradner
Harvard University
10 Ware St.
Cambridge, MA 02138
电话: +1 617 495 3864
EMail: sob@harvard.edu
Allison Mankin
USC/Information Sciences Institute
4350 North Fairfax Drive, Suite 400
Arlington, VA 22303
电话: +1 703-807-0132
EMail: mankin@isi.edu
附录A－推荐标准摘要
5.3 地址转换策略标准
改变地址转换策略的改变当前并不是推荐的影响，对于因特网有效份额现在并没有推荐。推荐使用未分配的A类地址来转换CIDR－类型的地址。
11.IPng推荐标准
推荐“简单因特网协议Plus（SIPP）Spec。（128位标准）”【Deering94b】作为IPng的基础。
推荐在附录C中的文档记录作为IPng的基础
13.IPng工作组
推荐Steve Deering和Ross Callon的IPng工作组组成和管理
推荐Robert Hinden为IPng效果的文档编辑。。
14.IPng审阅
推荐一个IPng审阅者为Dave Clark
15.地址自动配置
推荐一个地址自动配置工作组的组成和管理由Dave Katz和Sue Thomson负责.
16.1 转换－短期
推荐IPng传输工作组的组成和管理由Bob Gilligan和TBA负责
16.2 转换－长期
推荐特许传输和并存包括测试工作组。
17.其他的地址系列
推荐关于IPv6环境中使用非IPv6和在非IPv6环境中使用IPv6地址的推荐标准的开发。
18.在其他IETF标准中的影响
推荐IESG委托使用所有的标准记录RFCs的标准。
推荐IESG管理当前的IETF工作组并在他们建议的基础上理解IPng的影响，并且适当的修订文档以支持IPng
推荐IESG特许新的工作组需要修订其他的RFCs标准
19.APIs
推荐RFCs信息的开发和征求新的通用APIs。
21.IPng区域和工作组的未来
推荐IPng区域和区域董事会一直保持到1994年末主要的文档已作为协议标准建立起来为止。
22.安全因素
推荐对鉴定标题的支持。
推荐对规范鉴定算法的支持
推荐对保密标题的支持。
推荐对规范保密算法的支持
推荐对一个“防火墙的IPng结构”的开发。
附录B－IPng区域董事会
J. Allard - Microsoft <jallard@microsoft.com>
Steve Bellovin - AT&T <smb@research.att.com>
Jim Bound - Digital <bound@zk3.dec.com>
Ross Callon - Wellfleet <rcallon@wellfleet.com>
Brian Carpenter - CERN <brian.carpenter@cern.ch>
Dave Clark - MIT <ddc@lcs.mit.edu >
John Curran - NEARNET <curran@nic.near.net>
Steve Deering - Xerox <deering@parc.xerox.com>
Dino Farinacci - Cisco <dino@cisco.com>
Paul Francis - NTT <francis@slab.ntt.jp>
Eric Fleischmann - Boeing <ericf@atc.boeing.com>
Mark Knopper - Ameritech <mak@aads.com>
Greg Minshall - Novell <minshall@wc.novell.com>
Rob Ullmann - Lotus <ariel@world.std.com>
Lixia Zhang - Xerox <lixia@parc.xerox.com>
RIPE 的Daniel Karrenberg参加了董事会当它成立时，但是收回到期要求。
在多伦多的IETF会议上，Paul Francis 因为其他方面的兴趣从董事会中退出。而Sun 微系统的Robert Hinden和IBM的Yakov Rekhter加入了。
附录C－涉及IPng工作组的文档
【Deering94b】 Deering，S.，“简单的因特网协议Plus（SIPP）Spec。（128位ver）”，
工作在进行中。
【Francis94】 Francis，P.，“SIPP地址构架”，工作在进行中。
【Rekhter94】 Rekhter，Y.，和T.Li，“IPv6 Unicast联合地址分配的构架”，工作在进
行中。
【Gillig94a】 Gilligan，R.，“简单的SIPP传输（SST）综述”，工作在进行中。
【Gillig94b】 Gilligan，R.，“SIPP鉴定标题”，工作在进行中。
【Ford94b】 Hinden，R.，“下一代IP综述”，工作在进行中。
附录D－IPng 建议综述
【Ford94a】 Ford，P.，和M.Knopper，“作为IPng的TUBA：白皮书”，工作在进行中。
【Hinden94a】 Hinden，R.，“简单的因特网协议Plus白皮书”，
RFC 1710，Sun微系统，10.1994。
【McGovern94】 McGovern,M.，和R.Ullmann，“CATNIP：因特网的通用构架”，
RFC1707，Sunspot 图形学，莲花发展公司.，10.1994。
附录 E－RFC 1550 白皮书
【Adam94】 Adamson，B.，“战术无线电频率通讯对IPng的要求”，RFC 1677，NRL，
8.1994。
【Bello94a】 Bellovin，S.，“每一个主机的多个地址”，RFC 1681，
AT&T 贝尔实验室，8.1994。
【Bello94b】 Bellovin，S.，“IPng的安全要素”，RFC 1675，AT&T
AT&T 贝尔实验室，8.1994。
【Bound94】 Bound，J.，“IPng BSD主机实现分析”，RFC 1682，数字设备公司，8.1994。
【Brazd94】 Brazdziunas，C.，“IPng对ATM服务的支持”，RFC 1680，Bellcore，8.1994。
【Britt94】 Britton，E.，和J.Tavs，“IPng对大型公司网络的支持”，RFC 1678，IBM，
8.1994
【Brown194】 Brownlee，J.，“IPng的结算张目请求”，RFC 1672，Auckland 大学，
8.1994。
【Carpen94a】 Carpenter，B.，“IPng白皮书的传输和其他要素”，RFC1671，CERN，
8.1994。
【Chiappa94】 Chiappa，N.，“IPng技术对Nimrod路由和地址构架的要求”，
RFC 1753，11.1994。
【Clark94】 Clark，R.，Ammar，M.，和K.Calvert，“IPng中多路协议的互用性”，
RFC 1683，佐治亚研究会，8.1994。
【Curran94】 Curran，J.，“IPng条件的市场准入”，RFC 1669，BBN，8.1994。
【Estrin94a】 Estrin，D.，Li，T.，和Y.Rekhter，“IPng 的统一路径”，RFC 1668，USC，
Cisco系统，IBM，8.1994。
【Fleisch94】 Fleischman，E.，“大公司用户对IPng的观点”，
RFC 1687，波音电脑服务，8.1994。
【Green94】 Green，D.，Irey，P.，Marlow，D.，和K.O'Donoghue，“HPN工作组投
入到IPng需求中”，RFC 1679，NSWC－DD，8.1994。
【Ghisel94】 Ghiselli，A.，Salomoni，D.，和C.Vistoli，“对IPng的INFN需求”，
RFC 1676，INFN/CNAF，8.1994。
【Heager94】 Heagerty，D.，“进入IPng 的工程要素”，RFC 1670，CERN，8.1994。
【Simpson94】 Simpson，W。“IPng移动要素”，RFC 1688，Daydreamer，8.1994。
【Skelton94】 Skelton，R.，“电力研究学会对IPng的说明”，RFC 1673，EPRI，8.1994。
【Syming94】 Symington，S.，Wood，D.，和J。Pullen，“IPng的模型和模拟”，
RFC 1667，MITRE，佐治亚麻省理工学院，8.1994。
【Taylor94】 Taylor，M.，“IPng的网络产业观点”，RFC 1674，CDPD 国际银行，8.1994。
【Vecchi94】 Vecchi，M.，“IPng需求：电缆电视产业观点”，
RFC 1684，Time Warner 电缆，8.1994
附录 F－辅助参考
【Almqu92】 Almquist，P.，“BOF选择条件的记录”，华盛顿特区IETF，12.1992，
（ietf/nov92/select-minutes-92nov.txt）。
【Berkow94】 Berkowitz，H.，“IPng和最新的即插即用问题和请求“，工作在进行中，
9.1994。
【Bos94】 Bos，E.J.，“BOF预期地址寿命的记录（ALE）”，Seattle IETF，3.1994，
（ietf/ale/ale-minutes-94mar.txt）。
【Big】 大型互联网邮件记录档案，在munnari.oz.au中的big-internet/list-archives
上。
【Bradner93】 Bradner，S.，和A.Mankin,“IP：下一代（IPng）白皮书”，
RFC 1550，哈佛大学，NRL，12.1993。
【Callon87】 Callon，R.，“下一代因特网协议的建议”，对X3S3的建议，12.1987。
【Callon92a】 Callon，R.，“CNAT”，工作在进行中。
【Callon92b】 Callon，R.，“简单的CLNP”，工作在进行中。
【Callon92c】 Callon，R.，“TCP和UDP的大地址（TUBA），因特网地址和路径的简
单协议”，RFC 1347，DEC，6.1992。
【Carpen93】 Carpenter，B.和T.Dixon，“关于IPng决策处理BOF（IPDECIDE）的记
录”，/ietf/93jil/ipdecide-minutes-93jul.txt，8.1993。
【Chiappa91】 Chiappa，J.，“一个新的IP路径和地址构架”，工作在进行中。
【Clark91】 Clark，D.，Chapin，，L.，Cerf，V.，Braden，R.，和R.Hobby，“面向未
来的因特网构架”，RFC 1287，MIT，BBN，CNRI，ISI，UC Davis，
12.1991。
【Deering92】 Deering，S.，“简单的因特网协议”，大型因特网邮件记录，22.9.1992。
【Deering94a】 Deering，S.，和P.Francis，信息对邮件记录的访问，31.5.1994。
【Estrin94b】 Estrin，D.，Zappala，D.，Li，T.，Rekhter，Y.，和K.Varadhan，
“对路径的基本要求：包的格式和发运规范（第一版）”工作在进行中。
【Fuller93】 Fuller，V.，Li，T.，Yu，J.，和K.Varadhan，“无差别的域间路径（CIDR）：
一个地址分配和集结法策略”，RFC 1519，BARRNet，Cisco 系统，MERIT，
OARnet，9.1993。
【Gillig94c】 Gilligan，B.，“IPng传输（ngtrans）”，工作在进行中。
【Gross92】 Gross，P.，和P.Almquist，“IESG对路径和地址的审议”，RFC 1380，ANS，
斯坦福大学，11.1992。
【Gross94】 Gross，P.“IPng的方向”，RFC 1719，MCI，9.1994。
【Hinden92a】 Hinden，R.，“因特网路径和地址的新的方案（ENCAPS）”，工作在进
行中。
【Hinden94b】 Hinden，R.，Deering，S.，和P.Francis，“简单因特网协议的增强”，工
作组特许，4.1994。
【Hinden92b】 Hinden，R.，和D.Crocker，“IP地址封装的协议（IPAE）：与大型地址
相兼容的IP版本“，工作在进行中。
【Huston94】 Huston，G.，和A.Bansal，为传输和并存包括测试（TACIT）工作组制
定的许可，6.1994。
【Huitema93】 Huitema，C.，“对发行规模处理的IAB对中间策略的推荐标准”，RFC
1715，INRIA，10.1994。
【IAB92】 因特网构架底板，“IP第七版”，工作在进行中。
【IAB94】 Braden，R.，Clark，D.，Crocker，S.，和C.Huitema，“IAB工作室对因特
网构架安全的报告－2 8－10，1994”，RFC 1636，USC/信息科学研究所，
MIT计算机科学实验室，委托信息系统，有限公司.，INRIA，IAB 主席，
6.1994。
【Kasten92】 Kastenholz，F，和C.Partridge，“Ipv7 技术准则”，工作在进行中。
【Kasten94】 Partridge，C.，和F.Kastenholz，“选择IP的技术准则，FTP软件，12.1994。
【Knopper94a】 Knopper，M.，和P.Ford，“TCP/UDP 通过CLNP寻址的网络（TUBA）”，
工作组许可，1.1994。
【Knopper94b】 Knopper，M.，和D.Piscitello，“BigTen IPng 收容记录”，19&20.5.1994。
【Leiner93】 Leiner，B.，和Y.Rekhter，“多路因特网协议”，
RFC 1560，USRA,IBM,12.1993.
【Mankin94】 Mankin，A.，和S.Bradner，对大型互联网信息的tuba，sipp，catnip和ietf
邮件记录，7.7.1994。
【Mills84】 Mills，D。“外部网关协议格式说明规范”，RFC 904，UDEL，4.1984。
【Mogul90】 Mogul，J.，和S.Deering，“MTU 路径的发现”，
RFC 1191，DECWRL，斯坦福大学，11.1990。
【Nat94】 国家研究理事会，“认识信息的未来：因特网和未来”，国家学术出版社，1994。
【Piscit94】 Piscitello，D.，“通过大型地址记录的FTP操作（FOOBAR）”，RFC 1639，
核心权限，6.1994。
【Provan91】 Provan，D.，“通过ARCNET网络的IP传输”，RFC 1051，Novell，2.1991。
【Poste194】 Postel，J.Editor，“因特网正式协议标准”，RFC 1720，USC/信息科学研
究，11.1994。
【Solens93a】 Solensky，F.，和T.Li，“对地址生存期预期工作组的特许”，
FTP软件，Cisco系统，11.1993。
【Solens93b】 Solensky，F.，“地址生存期预期BOF的记录（ALE）”，Houston IETF，
11.1993，（ietf/ale//ale-minutes-93nov.txt）。
【Solens94】 Solensky,F., “地址生存期预期BOF的记录（ALE）”，多伦多 IETF，7.1994，
（ietf/ale/ale-minutes-94jul.txt）
【Sukonnik94】 Sukonnik，V.，“下一代IP（catnip）的通用构架”，工作组许可，4.1994。
【Tsuchiya92】 Tsuchiya，P.，“‘P’因特网协议”，工作在进行中。
【Ullmann93】 Ullmann，R.，“TP/IX：下一代因特网”，RFC 1475，Process Software 公
司，6.1993。
附录 G－答谢
达到制成标准的阶段毫无疑问是许多认的努力换来的。特别是IPng理事会（在附录B中列出），Frank Kastenholz和Craig Partridge（Criteria 文档的作者）及Jon Crowcroft （领导ngreq BOF）的工作。领导，成员及三个IPng推荐工作组的文档作者的工作和合作，ALE
工作组和TACIT工作组领导了基础工作和推荐标准。
我们同样答谢许多致力于RFC1550的人和提供数据网络许多要求的广泛理解，使任何IPng的建议必须编码。
IESG的成员，IAB总是邮件记录的积极参与者提供我们许多我们所面对的观点。
在这期间，许多其他的独立机构和个人给了我们许多要旨及有用的建议。他们包括（没有特别的顺序）Radia Perlman, Noel Chiappa, Peter Ford, Dave Crocker, Tony Li, Dave Piscitello, Vint Cerf 和Dan Lynch。
感谢David Williams 和Cheryl Chapman从事一些困难的工作。
对所有上面我们所提及的人和一些我们所忽略的人，感谢你们使任务顺利完成！
RFC 1752 Recommendation for IPng IPng的推荐标准
第 1 页