SRFC  IPv9报头  编号：000001

 

第二版　Ｖ２.3

十进制网络工作组：                          上海十进制网络信息科技有限公司

SRFC：00001                                                                 谢建平、林肇

撤消：                                                                                       

类别：信息类                                                                    

                                                                                                 

本备忘录的状态

这个文档是互联网领域的互联网标准跟踪改进协议，请求讨论和建议，以便进行完善。这个文档目前是保密性的。

版权申明

  本文的全部版权属于十进制网络工作组和上海通用化工技术研究所（2008）。

 

摘要

本文档是互联网协议的第九个版本（Ipv9）1999年的第三次改进版。

 

1．引言

    IP第9版（Ipv9）是互联网协议的一个新的版本，它是IP第4版(IPv4)[RFC-791]和IPv6[RFC-1883][RFC-2464]的后继版本。也是RFC1606、RFC1607对21世纪网络展望的实际论证和试验版本,从IPv4、IPv6到Ipv9的变化主要有以下方面：

扩展了地址容量  Ipv9将IP的地址长度从32位、128位增加到2048位，以支持更多的地址层次、更多的可寻址节点和更简单的自动地址配置。同时也增加了将ipv4的32位地址长度减少到16位，以解决移动通讯中蜂窝通信的快捷用途。但由于采用了不定长不定位的方法所以实际上减少网络的开销。通过为组播地址增加一个“范围”字段，提高了组播路由的可扩展性。它定义了一个新的地址类型“任意广播地址”，用于把数据报发送给一组节点中的任意一个。

简化了首标格式  一些IPv4的首标字段被取消或变为选项，用以降低数据包控制上的公共处理的开销，并限制Ipv9首标的带宽开销。

改进了对扩展特性和选项的支持  改变了首标选项的编码方式，以容许更有效的转发、减少对选项长度的限制，获得在未来引人新选项的更大灵活性。

给数据流做标签的能力  增加一个新的能力，它可以对属于某一个特定数据通信的数据流附加标签，发送者可要求对这些数据流进行特殊的处理，如非缺省的服务质量或实时服务,如采用虚电路来达到电路通讯的目的。。

IP地址加密、身份验证和保护隐私功能  在Ipv9中增加了对IP地址加密及身份验证的支持、数据完整性和（可选）数据保密等方面的扩张性。

和初步定义的Ipv9扩展首标和选项它还讨论了数据包的长度问题、流控制标签和类的语义以及Ipv9对于高层协议的影响。Ipv9的ICMP版本包含了实现Ipv9所要求的一切条件。

 

直接路由寻址功能

新版本增加了路由字符排列认证、识别及寻址功能。从而减少了路由开销及提高了效率。

Ipv9过渡期的报头

为了使ipv4能顺利过渡到Ipv9考虑到保护原来的IPV4投资和不改变用户使用习惯, 本文档定义了基本的Ipv9首标和过渡期的报头,他可以在Ipv9中用最后一段地址,但基本使用ipv4和ipv6的报头,但版本号改为9.所使用的各种连接协议均为ipv4和ipv6。

IPV9虚实电路的设计

为了使ipv9能流畅传输声音或图象等实际应用时，需要采用长流码和绝对值、返回码等技术,采用了三层与四层网络混合架构，在虚实电路中应实施三层与四层网络混合架构，以便实时传送图象和语音。

2．术语

节点——一个安装了Ipv9的设备或可以同时与IPv4、IPv6相容的Ipv9设备。

路由器——负责转发并不是明确发送给自己的Ipv9数据的设备。

主机——不属于路由器的任何节点。

上层协议——位于Ipv9上一层的协议。这类协议的例子如：传输层协议TCP、UDP，链路——一个通信设施或介质，节点可以在其上进行链路层通信，即紧靠在Ipv9下下面的那一层。链路的例子包括以太网（简单的或桥接的）、PPP链路、X.25，帧中继或ATM网络。

邻居——连接到同一链路的各个节点。

接口——节点到链路的连接。

地址——一个接口或一组接口的Ipv9层标识符。

数据包——一个Ipv9首标加上负载。

链路MUT——能够在一段链路上传送的最大发送单位，即以八位组为单位的最大数据包长度。

路径MUT——在源节点和目的节点之间的路径上的所有链路中最小的MUT。

注意 请注意对于一个具有多个接口的设备来说，可以将它配置为能转发来自它的某一组接口的非自我定向发送的数据包，并可丢来自它的其他接口的非自我定向发送的数据包。当这样的设备从前一种接口上接收数据或与邻居打交道的时候，必须遵循主机的协议要求。

3．Ipv9的首标格式

版本号

通讯流类型 

流标签 

地址长度

优先类通信量

地址认证

绝对通信量

有效负载长度 

下一个头  

跳极限 

源地址    （16-2048 bit)

目的地址 （16-2048 bit)

时间  

鉴别码 

 

   

 

 

 

 

 

 

 

 

 

 

 

 

 

版本：长度为4位，互联网协议版本号。对于Ipv9，该字段必须为9。

2）    类别：长度为8位。高3位用来指定地址长度，值为0～7，为2的次方值，地址长度为1BYTE～128BYTE；默认值为256位,其中0为16位、1为32位、3为64位、4为128位、5为1024位、6为2048位、7为保留位。后5位指定通信类别和用于源地址和目的地址的认证。0到15称为优先值，其中0到5用来指定通信量的优先类，6到7用来指定先认证后通信的通信方法，信息包发送地用此来进行通信量控制及是否需要对及是否需要对源地址和目的地址认证，8到14用来指定那些遇到拥塞时不会后退的绝对通信量，15用于虚拟电路。16、17分别赋予音频与视频，称为绝对值，确保音频与视频的不间断传输。其它值保留为今后使用。

3）    流标签：长度为20位，用于标识属于同一业务流的包。

4）    净荷长度：长度为16位，其中包括净荷的字节长度，即Ipv9头后的包中包含的字节数。

5）    下一个头：长度为8位，这个字段指出了Ipv9头后所跟的头字段中的协议类型。

6）    跳极限：长度为8位，每当一个节点对包进行一次转发之后，这个字段就会被减一。

7）    源地址：长度为8位bit～2048位bit，指出了Ipv9包的发送方地址，采用不定长不定位的方法。

8）    目的地址：长度为8位bit～2048位bit，指出了Ipv9包的目的地址，采用不定长不定位的方法。

9）    时间   ：用于控制报头中地址的生存时间。

10）鉴别码 : 用于标识报头中地址的真实性。

4．Ipv9的扩展首标

在Ipv9中，可选的互联网其他层信息放在另一些专门的首标中，它们可以放在数据包Ipv9首标和高层协议首标之间。这种扩展首标的数量不多，每一个都由不同的下一个首标植来标识。正如例子中所解释的，一个Ipv9数据包可以带有零个、一个或更多个扩展首标，这些扩展首标中的每一个都在前面的首标中下一个首标s字段定义：

Ipv9首标

下一个首标=TCP

 TCP首标+数据

Ipv9首标

下一个首标=路由

 路由首标
下一个首标=TCP		 TCP首标+数据

Ipv9首标

下一个首标=路由

 路由首标
下一个首标=
      数据段		 数据段首标
下一个首标=TCP		 TCP数据段
首标+数据

 

有一个例外，在数据包的传递路径上，任何一个节点都不检查或处理扩展首标，直到数据包到达Ipv9的首标中“目的地址”字段指定的那个节点（如果是组播地址，则是一组节点）为止。在那里，对于Ipv9首标的下一个首标字段的正常多路分解要调用处理模块来处理第一个扩展首标；如果不存在扩展首标的话，则要处理高层首标。因此，扩展首标的处理必须严格按照它们在数据包中出现的顺序来进行，接收者不能够扫描数据包来查找某一个特定的扩展首标，并在处理其他位于前面的首标之前来处理它。

上一段所述情况的一个例外是“逐个网段选项”首标，这部分首标中包含的信息必须由数据包传递路径上所经过的每一个节点来检查和处理，包括源节点和目的节点。一旦出现“逐个网段选项”首标，它必须紧跟在Ipv9首标后。Ipv9首标中“下一个首标”字段的值为零表明“逐个网段选项”首标的存在。

如果一个节点在处理了首标之后，要处理下一个首标，但是它不能识别“下一个首标”的值，它将丢失这个数据包，并且给数据包的发送源发送一个“ICMP存在参数问题”的消息，该消息的ICMP代码的值为2（遇到不能识别的“下一个首标”的类型），“ICMP指示符”字段中包含无法识别的“下一个首标值”在原数据包中的偏移量位置。如果一个节点在任何非Ipv9首标中发现了“下一个首标”字段为0，也会执行上面同样的操作。

每一个扩展首标的长度都是8位组的整数倍，以便使后面的首标能够按8位组边界对齐。在扩展首标中，由多个8位组构成的字段在其内部按照它们内部的自然边界对齐，也就是说，宽度为n个8位组的字段被放在从首标开始的，一个整数乘以n个8位组的位置，其中n=1,2,4或8。

完整安装的Ipv9包括下面的扩展首标：

1）Hop-by-Hop Option(逐个网段选项)。

2）Routing（路由）（类型0）

3）Fragment（数据段）。

4）目的地选项（目的地选项）。

5）Authentication（身份验证）。

6）Encapsulating Security Payload（封装安全负载）。

本文档定义了前四个扩展首标，后面的两个另外定义。

1．扩展首标的顺序

当在同一个数据包中使用了多个扩展首标的时候，建议这些首标以下面的顺序出现：

1）Ipv9首标。

2）逐个网段选项首标。

3）目的地选项首标（注1）。

4）路由首标。

5）数据段首标。

6）身份验证首标。

7）封装安全负载首标。

8）目的地选项首标（注2）。

9）上层首标。

注1：用于要由Ipv9目的地址字段中出现的第一个目的节点，以及路由首标中列出的后续目的节点来处理的选项。

注2：用于仅由数据包的最终目的节点来处理的选项。

每一种扩展首标最多只能出现一次，但是目的地选项首标最多可以出现两次（一次在路由首标之前，一次在高层首标之前）。

如果高层首标是另一个Ipv9首标（当Ipv9被封装在另一个Ipv9隧道中的时候）它的后面可以跟随着它自己的扩展首标，这些首标作为一个整体，遵循同样的顺序。

当定义其他扩展首标的时候，必须指定它们与上面列出的首标之间的顺序关系。

Ipv9节点必须能够接受和处理以任意顺序排列的扩展首标，并且在同一个数据包中扩展首标可以出现任意次，只有Hop-by-Hop Option首标除外，它只能紧跟在Ipv9首标的后面。但是，除非以后制定的规范修改了上面的建议，否则Ipv9数据包源应该尽可能遵守上面建议顺序。

2．选项

当前定义的扩展首标中的逐个网段选项和目的地选项首标带有数量不等的以类型长值（TLV）形式编码的选项，它采用下面的格式：

选项类型

选项数据长度

选项数据

类型选项的8位标识符。

选项数据长度8位无符号整数。它是这个选项的选项数据字段的长度，以8位组为单位。

选项数据可变长度字段，与选项类型相关的数据。

对首标中的选项顺序的处理必须严格地按照它们在首标中出现的顺序进行；接收者不能通过扫描首标来查找某一个特定类型的选项，并且不能在处理所有前面的选项之前处理它。

选项类型标识符是内部定义的，所以它的最高两位用于规定了如果处理Ipv9的节点不能识别这个选项类型时必须执行的操作：

00——跳过这个选项并继续处理首标。

01——丢弃这个数据包。

10——丢弃这个数据包，并且无论这个数据包的目的地址是否是组播地址，都给这个数据包的源地址发送一个“ICMP参数存在问题，代码2，”的消息，指出不能识别的选项类型。

11——丢弃这个数据包，只有当这个数据包的目的地址不是组播地址的时候，才给这个数据包的源地址发送一个“ICMP参数存在问题，代码2”的消息，指出它不能识别的选项类型。

选项类型的高位第三位指定这个选项的选项数据在到达数据包最终目的的途中是否可以变化。当数据包中出现了身份验证首标，在计算数据包的认证值时，任何数据在途中可以变化的选项所在字段的整体都被作为全0的8位组对待。

0——选项数据在传输途中不能改变。

1——选项数据在传输途中可以改变。

每一个选项可以有自己的对齐要求，以保证选项数据字段中多个8位组的值落到自然边界上。选项的对齐要求用Xn+y的形式来表示的，它的意思是：选项类型必须出现在离首标开始出x个8位组的整数倍再加上y个8位组的位置上。例如：

2n意味着偏移量为离首标开始处2个8位组的任意倍数。

8n+2意味着偏移量为离首标开始处8个8位组的任意倍数加上2个8位组。

当需要对齐后面的选项或将所在首标长度填充至8位组倍数时，有两种填充选项可供使用。这些填充选项必须为所有Ipv9所识别。

Pad1选项（对齐要求：无）

0

注意  Pad1选项的格式是一种特殊的情况——它没有长度字段和值字段。

Pad1选项用于在首标的选项字段中插入一个8位组的填充位。如果需要填充多个8位组，请使用下面介绍的PadN选项，而不是使用多个Pad1选项。

PadN选项（对齐要求：无）

1

选项数据长度

选项数据

PadN选项用于向首标的选项字段插入两个或多个8位组填充位。要填充N个8位组，选项数据长度字段的值应为N-2，选项数据字段包含N-2个全0的8位组。

附录A包含了指导设计新选项的格式方面的内容。

3．逐个网段选项首标

逐个网段选项首标用来携带必须由数据包所经过路径上所有节点检查和处理的选项信息。在Ipv9中，逐个网段选项首标用下一个首标的值为0来表示，因而具有下面的格式：

下一个首标

首标扩展长度

 

  

选项

下一个首标8位选择器。用于标识紧跟在逐个网段选项首标后面的首标的类型。使用与IPv4的协议字段相同的值[Rfc-1700]。

首标扩展长度8位无符号整数。逐个网段选项首标的长度，以8位组为单位，不包含第一个8位组。

选项可变长度字段，它的长度使逐个网段首标的长度成为8位组整数倍。包含一个或多个TLV编码的选项。

除了上面指定的Pad1和PadN选项之外，定义了下面的逐个网段选项：

大负载选项（对齐要求：4n+2）

  194 选项数据长度
大负载长度

 

大负载选项用于发送负载长度超过65535个8位组的Ipv9数据包。大负载长度是数据包的长度，以8位组为单位，不包括Ipv9首标，但包括逐个网段选项首标；它必须大于65535。如果接收到带有大负载选项的数据包，并且大负载长度小于或等于65535，则要给发送数据包的源节点发送一个“ICMP参数存在问题，代码0”的消息，指向无效的大负载长度字段的高位。

如果数据包带有大负载选项，在Ipv9首标中的负载长度必须设置为0。如果接收到一个既包含有效大负载长度选项，同时Ipv9负载长度字段为非0的数据包，则要给发送数据包的源节点发送一个“ICMP参数存在问题，代码0”的消息，指向大负载选项类型字段。

在带有数据段首标的数据包中不得使用大负载选项。如果在包含大负载选项的数据包中遇到数据段首标，则将要给发送数据包的源节点发送一个“ICMP参数存在问题，代码0”的消息，指向数据段首标的第一个8位组。

如果安装的Ipv9不支持大负载选项，它就不拥有与MTU大于65535的链路之间的接口（72个8位组的Ipv9首标，加上4G个8位组的负载）。

 

4．路由首标

Ipv9源使用路由首标列出一个或多个中间节点，它们是在数据包到达目的节点的路径上需要访问的节点。这个功能与IPv4的源路由选项非常相似。路由首标由它的前一个首标中值为43的下一个首标字段标识，它具有下面的格式：

下一个首标

首标扩展长度

路由类型

剩余数据段

与类型有关的数据

下一个首标8位选择器。标识紧跟在路由首标后面的首标类型。使用与IPv4协议字段相同的值[RFC-1700]。

首标扩展长度。8位无符号整数。路由首标的长度，以8位组为单位，不包含第一个8位组。

路由类型0。路由首标变量的8位标识符。

剩余数据段8位无符号整数。剩余路由数据段的数量，即显式列出的中间节点的数量，它们是在到达最终目标节点之前还要访问的节点。

与类型有关的数据。变长字段，它的格式由路由类型确定，它的长度使整个路由首标的长度成为8位组的整数倍。

如果正当处理接收到的数据包时，一个节点遇到了不能识别的路由类型值，这个节点将要采取的动作取决于剩余数据段字段的值：

如果剩余数据段字段的值为0，这个节点必须忽略路由首标并接下去处理数据包的下一个首标，该首标的类型在路由首标的下一个首标字段中给出。

如果剩余数据段字段的值非0，这个节点必须丢弃这个数据包，并且给数据包的源地址发送一个ICMP参数存在问题，代码0，消息，指向不能识别的路由类型。

类型0路由首标的格式为：

下一个首标

首标扩展长度

路由类型=0

剩余数据段

保留

严格/宽松位影射

地址[1]

地址[2]

 

地址[n]

下一个首标8位选择器。标识紧跟在路由首标之后的首标的类型。使用与IPv4协议字段相同的值[RFC-1700et Seq]。

首标扩展长度8位无符号整数。路由首标的长度，以8位组为单位，不包含第一个8位组。对于类型0的路由首标，首标扩展长度等于首标中地址数量的两倍，并且是小于或等于46的偶数。

路由类型0。

剩余数据段8位无符号整数。剩余的路由数据段的数量，即显式列出的中间节点的数量，它们是在到达最终目标节点之前还要访问的节点。最大的有效值为23。

保留8位保留字段。发送方将它初始化为0，在接收方忽略这个字段。

严格/宽松位映射，从左至右为1到23。对于每一个路由数据段，指出下一个目的地址是否必须是上一个节点的邻居：1表示严格（必须是邻居），0表示宽松（不必是邻居）。

地址[1..n]256位地址向量，从1到n。

组播地址不能出现在类型0的路由首标数据包中，也不能出现在Ipv9的目的地址字段中带有类型0的路由首标的数据包中。

如果严格宽松位映射的第0个位的值是1，原始数据包的Ipv9首标中的目的地址字段必须指示源节点的一个邻居。如果第0个位为1，发送者可以使用任何合法的，非组播地址作为初始目的地址。

高于n的位，这里n是路由首标只能感的地址的数量，必须由发送者设置为0，并被接收者忽略。

直到数据包到达在它的Ipv9首标中目的地址字段指定的节点后，路由首标才被检查和处理。

5．数据段首标

Ipv9源主机利用数据段首标来发送长度大于数据包传递路径的MTU的数据包。（注意：与IPv4不同，在Ipv9中的仅由源主机来完成分段的工作，而不是由数据包所经过的路径上的路由器来完成）数据段首标是通过在它前面的首标中将下一个首标设置为44来标识的，它具有下面的格式：

下一个首标

保留

数据段偏移量

保留

M

标识符

 

下一个首标8位选择器。标识原始数据包的数据段部分的初始首标类型（在下面定义）。使用与IPv4协议字段相同的值[RFC-1700]。

保留8位字段。在发送方被初始化为0，在接收方被忽略。

M标志1表示还有更多的数据段，0表示最后一个数据段。

标识符32位。参见下面的描述。

为了发送长度大于传递路径的MTU的数据包，源节点可以将数据包拆分为一些数据段，并将每一个数据段作为一个独立的数据包发送，在接收方再进行数据包的重新组装。

对于每一个要分段的数据包，源节点都要为它生成一个标识符值。近期传递的任何具有相同源地址和目的地址的数据包中，任何数据分段都必须具有不同的标识符。如果出现了路由首标，所考虑的目的地址是最终的目的地址。

6．目的地选项首标

目的地选项首标用来携带只需要由数据包的最终节点检查的选项。目的地选项首标由它前面的，下一个首标字段值为60的首标标识，并有下面的格式：

下一个首标

首标扩展长度

 

  

选项

 

下一个首标位选择器。标识紧跟在目的地选项首标之后的首标的类型。使用与IPv4xx协议字段相同的值[RFC-1700]。

首标扩展长度8位无符号整数。目的地选项首标的长度，以8位组为单位，不包含第一个8位组。

选项可变长度字段，它的长度使目的地选项首标的长度成为8位组的整数倍。包含一个或多个TLV编码的选项。

在这个文档中唯一定义的目的地选项是Pad1和PadN选项。

注意，在Ipv9数据包中可选的目的信息有两种可能的编码方式：或者是在目的地选项首标中定义，或者是一个独立的扩展首标。数据段首标和身份验证首标是后一种情况的两个例子。用哪一种方式取决于目的节点不识别选项信息时需要采取的操作：

i      如果希望目的节点采取的操作是丢弃那个数据包，并且只有在数据包的目的节点地址不是组播地址的时候，给数据包的源地址发送一个ICMP Unrecognized Type（ICMP未识别类型）消息，然后这些消息可以封装为一个独立的首标，或目的地选项首标中的一个选项，并且选项类型的最高两位为11。这种选择取决于很多因素，如占用更少的字节，能够更好的对齐，或易于解析。

i      如果两种操作都需要，这些消息必须作为目的选项首标的一个选项来编码，它的Option类型的最高两位是00、01或10，分别指定希望采取的操作。

7．No下一个首标

Ipv9首标或任何扩展首标的下一个首标字段为59的时候，表示没有任何东西跟在首标的后面。如果Ipv9首标的负载长度字段指出在下一个首标字段为59的首标的后面还有一些8位组，这些8位组必须被忽略，当数据包必须转发的话，这些内容按原样传递。

5．数据包长度问题

Ipv9要求Internet上每一条链路的MTU至少为576。在任何链路上，如果它不能在一个数据包中传递576个8位组，那么与链路相关的数据段和重新组装必须由Ipv9以下的层次提供支持。

与节点直接连接的每一条链路，节点必须能够接受与链路是MTU等大的数据包。具有可配置的MTU的链路（如PPP链路[RFC-1661]）必须将MTU配置为至少576个8位组，建议配置为更大的MTU，以便容纳可能发生的封装（如隧道），而不必招致分段。

建议Ipv9节点实现Path MTU Discovery[RFC-1191]，以便发现和利用大于576的MTU链路的优势。然而，一个极小化的Ipv9实现（如在一个BootROM中）可以简单地限制它自己不发送大于576的数据包，并省略Path MTU Discovery的实现。

为了发送长度大于链路的MTU的数据包，节点可以利用Ipv9的数据段首标，在源节点对数据包进行分段，并在目的节点进行组装。然而在任何应用中都不提倡这种分段，如果它能够调整数据包的大小，以适合所测量到的链路的MTU的话（既减少576）。

一个节点必须保证能够接受分段的数据包，这个数据包在重新组装之后超过1500字节，包括Ipv9首标。但是一个节点必须保证不发送重新组装后大于1500字节的分段数据包，除非它被显式告知目的节点能够组装那样大的数据包。

将一个Ipv9数据包发送给一个IPv4节点的时候（即数据包要经历从Ipv9到IPv4的转换），Ipv9源发节点可能会收到一个ICMP Packet TOO Big（ICMP数据包太大）的消息，报告Next-Hop MTU必须小于576。在这种情况下，Ipv9不需要将后面的数据包的大小减小为小于576，但是必须在那些数据包中包含一个数据段首标，以便Ipv9-IPv4转换路由器能够获得一个适当的，用于所构造的IPv4数据段的标识符值。注意，这意味着负载可能被减小至496个8位组（576减Ipv9首标使用的72字节和数据段首标使用的8字节），如果使用了其他的扩展首标的话，还可能被减至更小。

为了发送传输声音或图象等实际应用时长度大于链路的MTU的数据包时，可以选用长流码和绝对绝返回码等技术，节点可以利用Ipv9的数据段首标，在源节点对数据包进行识别不分段，并在目的节点不进行组装。但在发送方和接受方接受到返回码断开的信令时则恢复为正常工作状况。

注意  必须进行Path MTU Discovery（查找路径MTU）的工作，即使主机认为目的                                                                     主机也连接在与自己相同的链路上。

注意  与IPv4不同，Ipv9不需要在数据包的首标中设置一个“Don't Fragment”（不分段）标志来进行Path MTU Discovery，这是Ipv9的一个隐式特性。而且RFC-1191中与使用MTU表有关的过程不适用于Ipv9，因为Ipv9版本的“Datagram Too Big”（数据报太大）的消息总是标识所使用的确切的MTU。

注意  与IPv4、IPV6不同，IPV9传输声音或图象等实际应用时，需要采用长流码和绝对绝返回码等技术(SRFC IPv9 实时支持和流),这样就形成了在预留的虚实电路中实际上已成为三层结构，所以不存在尽力传输的概念,而成为保证传选内容的通道可靠安全,保证传输内容不间段的概念。这样就形成了IPV9网络内三层与四层架构共同存在的状况。

6．流标签

源节点可以用Ipv9首标中24为的流标签字段来标记需要由Ipv9路由器特殊处理的数据包，如非缺省的质量服务要求，或实时服务。Ipv9的这个考虑，在编制它的时候尚属实验性的，并且在Internet中更加明确的流标签支持需求的影响下，会发生变化。不支持这些流控制标签字段的主机或路由器在发送数据包的时候，应该将这些字段置为0，在转发这些数据包的时候应保持这些字段的内容不变，在接收这些数据包的时候应该忽略这些字段。

数据流是从某一个源地址到某一个目的地址（点对点或组播）发送数据包的序列，源节点要求中间的路由器对这些数据包进行特殊的控制。这些特殊处理的性质可以通过控制协议转让给路由器，如资源预定协议，或者通过数据流中的数据包本身携带的信息传递给路由器，如资源预定协议，或者通过数据流中的数据包本身携带的信息传递给路由器，如逐个网段选项。

在一对源节点和目的节点之间可能有多个活动的流，以及与任何流无关的通信流量。一个流由一个源地址与非0的流标签的组合唯一标识。不属于任何流的数据包的流标签字段被设置为0。

流标签是由数据流的源节点赋予的。新的流标签必须随机选取（伪随机），范围是1到16777215（十进制）。随机分配的目的是使得流标签中的这些位适合于作为路由器中的哈希关键字使用，用于查找流的相关状态。

属于同一个流的所有数据包在发送时必须具有相同的源节点地址、目的节点地址、优先级和流标签。如果这些数据包中任何一个数据包包含了逐个网段选项首标，那么它们都必须拥有相同的逐个网段选项首标内容（除了逐个网段选项首标的下一个选项字段之外）。如果他们中的任何一个数据包包含了一个路由首标，他们的所有位于路由首标之前的扩展首标必须都拥有相同的内容，包括路由首标在内（除路由首标的下一个首标字段之外）。容许，但不要求，路由器和目的节点检查上面的要求是否被满足。如果检测到冲突，它应该通知源节点，通过一个ICMP参数存在问题，代码0的消息，指向流标签的高位（即在Ipv9数据包内偏移量为1）。

路由器可以根据“时机”自由的设置任何流的流控制状态，甚至在没有显式的通过流控制协议、逐个网段选项或其他方法向他们提供流创建信息的时候。例如，当从某个特定的源节点接收到一个带有未知的、非0的流标签的时候，路由器可以处理它的Ipv9首标和其他任何必要的扩展首标，就好象流控制标签为0一样。这些处理包括确定下一跳的接口，以及其他任何必要动作，如修改逐个网段选项、在路由首标中将指针向前跳越一步，或如何根据优先级字段决定数据包的排队方法。路由器可以选择记住这些处理步骤的结果并缓存这些信息，使用源地址和流标签作为哈希关键字。后续的具有同样源地址和流标签的数据包可以根据缓存的信息来处理，而不是检查所有的字段，这是根据前面谈到的要求，可以假定从接收到流的第一个包以后这些字段的内容没有变化。

上面所描述的流控制状态，在根据“时机”设置并缓存之后必须在6秒钟之内丢弃，无论是否继续有属于同一流的数据包到来。如果在缓存状态被丢弃之后，又有另一个具有相同源地址和流控制标签的数据包到来，那么这个数据包必须经历全部的正常处理（就好象流控制标签为0一样），这个过程可能会导致重新建立并缓存该流的流控制状态。

显式建立的流控制状态的生命期，如由控制协议或逐个网段选项所创建的流控制状态，必须作为显式的建立机制规范的一部分来指定，它可以超过6秒钟。

在任何早先为流控制状态而创建的流控制状态的生命期内，源节点不得将该控制标签用于新的流。由于任何视“时机”而创建的流控制状态具有6秒钟的生命期，一个流的最后一个数据包与新的流的第一个包之间，使用相同的流标签的最小时间间隔是6秒钟。用于显示创建的流标签具有更长的生命期，必须在那个更长的时间周期内不得重新用于新得流。

当一个节点停机并重新开机（比如由于系统崩溃造成的后果），它必须小心地避免使用它可能用于早先创建的流，且尚未过期的流标签。这可以通过在稳定的存储器内记录流标签的使用情况来实现，这样它就可以在系统崩溃之后回忆起以前使用过的流标签，或者直到先前创建的，可能存在的最大生命期超时之前不使用流标签（至少为6秒钟，如果使用了显式的流创建立机制，且指定了更长的生命期，时间还要更长）。如果一个节点的重新引导时间是已知的（通常要大于6秒钟），便可相应的扣除在开始分配流标签之前需要等待的时间。

对于所有，或者说大多数，属于某一个流的数据包，也就是流标签非0的数据包来说，没有任何要求。之所以将这些讨论放在这里，是由于要提醒协议的设计者和实现者不要进行其他的假设。例如，设计一个性能的增强必须依赖于大多数的数据包都要属于某一个流的路由器，这将是不明智的。同样，设计一个首标压缩机制，而这个机制只能应用于某个流的数据包，也是不明智的。

7．类别（参考[RFC-2464]）

在Ipv9首标中的8位类别字段使得源节点能够标识它所期望的数据包传递确定级，当然是相对于从同一节点发送的其他数据包而言。类别的值分为二段定义：高3位用来指定地址长度，值为0～7，为2的次方值，地址长度为1BYTE～128BYTE；默认值为256位,其中0为16位、1为32位、3为64位、4为128位、5为1024位、6为2048位、7为保留位。后5位指定通信类别的二个范围，值0到7用于指定由源节点提供拥挤控制的信息优先级，即面临拥挤而滞后发送的信息，如TCP信息的优先级。值8到15用于指定面临拥挤而没有滞后发送的信息的确定级，即以固定速率传送的“实时”数据包的优先级。

对于受拥挤制约的信息来说，下列优先级值可用于特定的应用类别：

0——     非字符信息。

1——     “填充”信息（如netnews）。

2——     无人照管的信息（如Email）。

3——     保留。

4——     有人照管的大批量信息（如FTP、NFS）。

5——     保留。

6——     交互式信息（如Telnet、X）。

7——     互联网控制信息（如路由协议，SNMP）。

8——     为音频用。

9——     为视频用。

10—— 为视频或者音频压缩后不会由于排列差错而出现差错的。

11—— 广播用音频和视频用。

12—— 紧急用。

对于不受拥挤制约的信息来说，最低的确定级值8应该用于发送者在拥挤情况下最希望丢弃的数据包（如高保真视频信息），最高的确定级值15应该用于发送者最不希望丢弃的数据包（如低保真音频信息）。在不受拥挤制约的确定级与受拥挤制约的优先级之间并不存在对应的顺序关系。

8．上层协议问题

1．上层协议检验

如果任何传输协议或其他上层协议在计算它的检验和时将IP首标中的地址包含在内，那么为了能够在Ipv9之上运行，必须修改计算检验和的算法，以便包含长度为16位至-2048位的地址，而不是长度为32位的IPv4地址。下面给出了用于IPv9的TCP和UDP首标：

源地址

目的地址

时间  

鉴别码 

负载长度

0

下一个首标

n        如果数据包中包含路由首标，那么在伪首标中目的地址使用的是最终地址。在源发节点，这个地址是路由首标中的最后一个地址：在接收方，这个地址将在Ipv9首标的目的地址字段中。

n        伪首标中下一个首标的值标识上层协议（如：TCP为6、UDP为17）。如果在Ipv9首标与上层协议首标之间还有扩展首标，伪首标中下一个首标的值与Ipv9首标中下一个首标的值不同。

n        在伪首标中的负载长度字段的值是上层协议数据包的长度，包括上层协议首标。它要比Ipv9首标中Payload Length（或在大负载选项）小，如果在Ipv9首标与上层协议首标之间还有扩展首标的话。

n        与IPv4不同，当一个UDP数据包从一个Ipv9节点发出的时候，UDP检验和不是可任选的。也就是说，只要Ipv9节点发送UDP数据包，它就是必须计算UDP检验和。检验和由数据包和伪首标产生，如果计算结果是0，它必须被转换为十六进制FFFF，并放置在UDP首标中。Ipv9接收者必须丢弃包含检验和为0的UDP数据包，并记录这个错误。

Ipv9的ICMP版本在它的检验和计算中包含了上述的伪首标；这是对IPv4版本的ICMP的修改，IPv4的ICMP在它的检验和计算中没有包含伪首标。进行这项修改是为了保证ICMP不被错误的传递或毁坏它所依赖的Ipv9首标中的有关字段，与IPv4不同，这些字段并没有被互联网层的检验和所保护。ICMP的伪首标中的下一个首标字段包含值58，它标识Ipv9版本的ICMP。

2．最大数据包生命期

与IPv4不同，Ipv9节点和IPv6一样并不要求强制性的最大数据包生命期。这就是IPv4的“留存时间”字段被重命名为Ipv9的“网段数限制”的原因。在实践中，很少的（如果有的话）IPv4遵守要现在数据包生命期的要求，因此这并不是一个实践上的修改。任何上层协议，如果它依赖于互联网层（无论是Ipv9还是IPv4）来限制数据包生命期，它就应该升级为依靠自己的机制来检测和丢弃陈旧的数据包。

3．最大上层负载的大小

当计算可用于高层协议的最大负载时，上层协议必须考虑到Ipv9的首标要大于IPv4的首标。例如，在IPv4中，TCP的MSS选项的计算方法是，最大数据报长度（缺省值或通过Path MTU Discovery得到的值）减去40个8位组（20个8位组用于最小长度的IPv4首标，20个用于最小长度的TCP首标）。当在Ipv9上使用TCP的时候，MSS的计算方法必须是最大长度减去60个8位组，因为Ipv9的最小首标（即没有扩展首标的Ipv9首标）长度要比IPv4的最小首标长度大20个8位组。

9．选项的格式指南

当设计逐个网段选项首标或目的地选项首标的新选项时，需要先进行字段规划。这些都基于下面的一些假设：

i     一个希望的特性是：一个选项的选项数据中由多个8位组构成的任何字段都按照它们的自然边界对齐，即宽度为n个8位组的字段应该放在离逐个网段首标或目的地选项首标开始处的n个8位组的整数倍的地方，此处n=1，2，3，4或8

i     另一个希望的特性是：逐个网段首标或目的地选项首标尽可能少占用空间，必须符合首标的长度是8位组的整数倍的要求。

i     可以假设，当出现任何带有选项的首标时，它们只带有数量很少的选项，通常只有一个。

  这些假设意味着要这样来规划一个选项的各个字段：把字段从小到大排列，中间没有填充，然后根据最大字段的对齐要求得出整个字段的对齐要求。下面这个例子说明了这种方法：

例1．如果选项X需要两个数据字段，一个长度是8个8位组，一个长度是4个8位组，它应按下图安排：

  选项 类型=X 选项数据长度=12
4个8位组字段
8个8位组字段

 

 

它的对齐要求是8n+2，以保证8个8位组字段从首标开始处的一个8倍的偏移量开始。包含上面选项的、完整的逐个网段首标或目的地选项首标应是下面这个样子：

下一个首标

首标扩展长度=1

选项 类型=X

选项数据长度=12

4个8位组字段

8个8位组字段

 

例2．如果选项Y需要3个字段，一个长度为4个8位组，一个长度为2个8位组，一个长度为1个8位组，它应具有下面的格式：

    选项类型=Y
选项数据长度=7 1个8位组字段 2个8位组字段
4个8位组字段

 

 

它的对齐要求是4n+3，以保证4个8位组长的字段从首标开始处的一个4倍的偏移量开始。包含上面选项的、完整的Hop-by-Hop或目的地选项首标应是下面这个样子：

下一个首标

首标扩展长度=1

Pad1选项=0

选项类型=Y

选项数据长度=7

1个8位组字段

2个8位组字段

4个8位组字段

PadN选项=1

选项数据长度=2

0

0

 

例3．同时包含例1和例2中的选项X和选项Y的逐个网段首标或目的地选项首标，应是下面两种格式之一，这取决与哪一个选项先出现：

下一个首标

首标扩展长度=3

选项类型=X

选项数据长度=12

4个8位组字段

8个8位组字段

PadN选项=1

选项数据长度=1

0

选项类型=Y

选项数据长度=7

1个8位组字段

2个8位组字段

4个8位组字段

PadN选项=1

选项数据长度=2

0

0

 

下一个首标

首标扩展长度=3

PadN选项=1

选项类型=Y

选项数据长度=7

1个8位组字段

2个8位组字段

4个8位组字段

PadN选项=1

选项数据长度=4

0

0

0

0

选项类型=X

选项数据长度=12

4个8位组字段

8个8位组字段

 

 

10、封装安全载荷报头

1．封装安全载荷报头的格式

封装安全载荷Encapsulating Security Payload (ESP)报头的设计目的是在IPv4中提供混合的安全业务。封装安全载荷机制可以与认证报头一起应用，或者单独在隧道模式下以嵌套的方式应用。这里所说的安全业务可以在一对通信的主机之间，或者一对通信的安全网关之间，或者在一个安全网关和一台主机之间提供。上一节已经说明认证报头和封装安全载荷机制提供的认证服务最主要的区别在于其服务的有效区域。封装安全载荷机制并不对任何IP报头字段提供保护，除非这些字段被封装安全载荷封装（例如在隧道模式下，被封装在下层的IP包头就属于这种情况）。

封装安全报头插入的位置在IP报头之后。当应用在传输模式下时，封装安全报头在高层协议报头前面。当应用在隧道模式下时，封装安全报头在封装的IP报头之前。封装安全载荷机制能提供机密性、数据起源认证、无连接的完整性、反重播业务（一种部分序列完整的形式），以及有限的通信流机密性等业务。该机制所提供的业务依赖于在安全关联确立时的选项和应用程序的位置。机密性可以独立于其他业务选择。但是，仅仅使用机密性而不用完整性认证可能导致通信流遭受某些能够破坏保密业务的攻击。数据起源认证和无连接的完整性是联合服务，这项业务可以与机密性服务一起作为一个可选项共同提供。反重播业务只有当选择了数据起源认证服务时才可以选择，这项服务的选择是完全由接收者决定的。

机密性业务要求在隧道模式下选择，而且这项业务应用在安全网关上时最为有效，因为在网关上通信流的聚类可能屏蔽真实的信源和信宿地址模式。注意，虽然机密性业务和认证业务都是可选的，但是二者之间至少应该选择其一。

在封装安全载荷报头之前的一个协议报头（IPv4报头，Ipv9基本报头或者扩展报头）将在其协议字段（如果是IPv4报头）或者在其next header字段（如果是Ipv9扩展报头）中取值为50。

封装安全载荷分组和报头的格式如图所示。

0                8                16                24                31

安全参数指标

Security Parameters Index（SPI）
序列号
Sequence Number
载荷数据
Payload Data（变长）
  填充字段（0~255B））
  填充长度
Pad Length		 下一个报头
Next Header
认证数据
Authentication Data（变长）


    

注：提供认证业务的范围是认证数据之前的部分（不包括认证数据）；

提供加密业务的范围是序列号之后，认证数据之前的部分（不包括序列号和认证数据）。

封装安全载荷分组的格式

以下将阐述报头格式中的字段。我们在这里所说的“可选”表示如果这个选项没有被选中，该字段是被忽略的，在计算整体校验值时不用到它。而相反，“必需”表示该字段一定会出现在封装安全载荷分组中。

安全参数指标是一个32bit的必需字段。该字段与信宿IP地址和安全协议共同唯一的标示数据报的安全关联。安全参数指标的值可以是任意值，但是目前从1到255都是被IANA保留的。SPI的0值保留为本地的特定的应用程序使用。

32bit字段序列号包含的是一个单调递增的计数器值（序列号）。这个字段是必须有的，即使当接收端没有为某一个特定的安全关联选择开启“反重播放”服务。对于这个序列号字段的处理完全是由接收端进行的，也就是说，发送者必须传送这个字段，而接收端可以完全遵照此字段也可以不遵照此字段执行。

当安全关联确立时，发送者和接收者的计数器都设置为0。如果反重播启动（默认是启动的），则传输的序列号不允许循环。因此，在一次安全关联分组后，发送者和接收者的计数器必须复位。

载荷数据是一个变长的字段，包含由next header字段描述的数据。载荷字段是必需的，在长度上是整数倍字节。

填充字段的使用是为了加密的。在封装安全载荷报头中采用填充字段是出于以下的目的：

i     如果某种加密算法要求正文是某个字节数的整数倍，则填充字节就用于填充正文

（除了填充字段本身外，还包括载荷数据、填充长度和next header字段）来满足加密算法对数据长度的要求。

i     即使不考虑加密算法的要求，可能也需要填充字段来保证加密后的数据长度终止

于4B的边界。特别的，填充长度字段和next header字段的长度必须对齐于4B，来保证认证数据字段终止于4B的边界。

i     除了以上出于算法和对齐的要求之外，填充字段也可能被用于隐藏载荷的真实长

度，部分地对通信流提供加密。但是，这种额外的填充显然要占用宝贵的带宽资源，因此在使用时应该谨慎考虑。

发送者可以添加0到255B的填充字段。在一个封装安全载荷分组中是否填充是可选的，但是所有的应用程序都必须支持填充字段的产生和使用，以便能满足加密算法对加密数据长度的要求，同时保证认证数据对齐于4B的边界。

填充长度字段标明紧接着在它之前的填充字段的字节数。合法的填充长度值应该是从0到255，0值表示没有填充字节。填充长度字段是必需的。

Next header字段是一个8bit的字段，标明在载荷数据字段中的数据类型。该字段是必需的。

认证数据是变长的字段，包含有分组的整体检验值Integrity Check Value (ICV)，整体检验值是从封装安全载荷分组中除了认证数据之外的部分计算得到的。这个字段是可选的，只有当安全关联中包含了认证业务时才出现。认证算法必须说明整体检验值的长度和确认的相对规则和处理步骤。

2．封装安全载荷报头的处理

前文已经说明，和认证报头一样，封装安全载荷也可以以两种方式应用：传输模式或者隧道模式。

传输模式仅仅适用于主机应用程序。与认证报头不同，在这种模式下，封装安全载荷报头仅仅对高层协议提供保护，而对IP报头字段不提供保护。在传输模式下，封装安全载荷报头插入的位置在其他IP报头之后，在TCP、UDP和ICMP等高层协议之前。在Ipv9中，封装安全载荷报头被当作端到端的载荷，因此这个报头必须出现在跳到跳报头、路由报头和分段报头之后。信宿选项报头可以出现在封装安全载荷报头之前或者之后，取决于语义的要求。下面两图的数据报阐述了传输模式下一个典型的Ipv9分组中封装安全载荷报头的位置。

基本报头

扩展报头
（如果有的话）

TCP

数据
Data

应用封装安全载荷报头之前的数据报

基本
报头

跳到跳报头
信宿选项报头
路由报头
分段报头

封装安全载荷ESP

信宿选项报头

TCP

数据

封装安
全载荷
报尾
ESP
Trailer

封装
安全
载荷
认证
ESP
Auth

应用封装安全载荷报头之后的数据报

以上分组中，被加密的部分可以采用基本报头加密，也可以是信宿选项报头、TCP、数据和封装安全载荷报尾。而被认证的部分除了以上被加密的部分之外，还要加上封装安全载荷。

隧道模式下封装安全载荷报头可以应用于主机或者安全网关上。当封装安全载荷报头应用于安全网关上来保护用户的传输通信流时，必须使用隧道模式。在隧道模式下，“下层的”IP报头携带最终的信源和信宿地址，而“上层的”IP报头可以包含其他的地址，例如安全网关的地址。在隧道模式下，封装安全载荷报头相对于“上层的”IP报头的位置与在传输模式下一样。下图说明在隧道模式下典型的Ipv9分组中封装安全载荷报头的位置。

上层
基本
报头

上层扩展报头
（如果有的话）

封装安全载荷ESP

下层基本报头

下层扩展报头
（如果有的话）

TCP

数据

封装
安全
载荷
认证
ESP
Trailer

封装安
全载荷
认证
ESP
Auth

隧道模式下典型的IPv9分组中封装安全载荷报头的位置

 

以上分组中，被加密的部分可以采用上层基本报头加密，也可以是下层基本报头、下层扩展报头、TCP、数据和封装安全载荷报尾。而被认证的部分除了以上被加密的部分之外，还要加上封装安全载荷。

 

附录A 对RFC1606  RFC1607的述说

本文挡是对RFC1606  RFC1607对21世纪网络展望的具体实施方案, 42层路由地址空间是遵照RFC1606中的文挡描述的 :

2. 路由

IPv9的深达42层的路由层次是他得到广泛应用的关键特性。

但为了保护以以前的投资，所以留出了兼容IPV4和IPV6地址，其中1-41层是为了兼

容IPV4和IPV6而设计的,而第42层是遵照RFC1606中的文挡描述的 :

1.   分配:IPv9协议的大量的号码空间也使得分配地址可以用一种直接的方式而设计的。

目的主要用于全IP的移动手机、IPTV、IP电话、物联网等需要用阿拉伯数字表示及需采用字符不必再解析的网络应用，因此设计了字符路由器。

RFC1606在分析当时IPV9失败原因时,主要是地址长度不够，所以SRFC  IPV9地址长度是按RFC1607的文挡设想在21世纪网络地址长度是1024比特设计的,同时根据实际需求将地址空间长度设计成了2048比特，从而解决了地址空间容量问题。

为了达到RFC1606、RFC1607的技术场景设想,重新定义了路由层次、地址长度、地址工作模式、地址空间资源、地址文本表示方法、压缩定义、间隔符的定义。

 

十进制网络工作小组联系地址：上海市武夷路461弄1号楼403

联系人：谢建平

电  话：0086-21-52388911

F A X ：0086-21-62906873

电子邮件：[email protected]

1999年6月2日

最近修改日为：2008年6月28日

这次修改日为：2010年7月22目