【RFC文档】RFC 1883 中文 – Internet协议,版本6(IPv6)说明书

RFC 1883

组织:中国互动出版网(http://www.china-pub.com/)
RFC文档中文翻译计划(http://www.china-pub.com/compters/emook/aboutemook.htm)
E-mail:ouyang@china-pub.com
译者:cata_xu(cata_xu   amethyst@theory.issp.ac.cn)
译文发布时间:2001-9-11
版权:本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载,但必须
保留本文档的翻译及版权信息。


Network Working Group                             S. Deering, Xerox PARC
Request for Comments: 1883                  R.  Hinden, Ipsilon Networks
Category: Standards Track                                  December 1995

Internet协议,版本6(IPv6)说明书
(RFC1883——Internet Protocol, Version 6 (IPv6) Specification)


本备忘录的状态

本文档讲述了一种Internet社区的Internet标准跟踪协议,它需要进一步进行讨论和建
议以得到改进。请参考最新版的“Internet正式协议标准” (STD1)来获得本协议的标准化
程度和状态。本备忘录的发布不受任何限制。

摘要

本文档详述Internet协议版本6(IPv6),有时也可以看作是下一代的IP或是IPng。
Table of Contents

目录
 
1.  介绍	2
2.  术语	3
3.  IPv6报头格式	3
4.  IPv6扩展报头	5
4.1  扩展报头顺序	6
4.2  选项	7
4.3  逐跳选项报头	8
4.4   路由报头	10
4.5  分片报头	14
4.6  目的地选项报头	18
4.7 无下一报头	19
5. 分组尺寸问题	19
6.  流标签	20
7.  优先权	21
8. 上层协议问题	22
8.1 上层校验和	22
8.2 最大分组生存周期	23
8.3 最大上层有效载荷尺寸	23
附录A 选项的格式化指导策略	24
实例 1	24
实例 2	25
实例 3	26
安全考虑	26
致谢	27
参考	27

           



1.  介绍

IP版本6(IPv6)是Internet协议的新版本,作为IP版本4(IPv4)[RFC-791]的后继而设
计。IPv4到IPv6之间的变化可以简单地归结到下列范围:

o  扩展地址特性
   IPv6把IP地址大小从32位扩大到128位来支持更多的地址等级,更多数目的地址节点
以
   及更简单的地址自动配置。广播路由的可测量性是通过增加一个用来广播地址的“范围”
   域来改进的。IPv6定义了一个称为“任意播地址”的新型地址,通常用来发一个分组到
   一组节点中的任意一个。

o  报头格式简化
   一些IPv6报头域已经被去掉或者做了任选以减少分组句柄通用事件(common-case)并且
进程开销已经限制IPv6报头的带宽开销。

o  改进对扩展和选项的支持

   在IP报头选项编码上的改变考虑了更多有效的转发,选项长度上的更少限制以及将来引
   入新选项时的更大灵活性。

o  流标签特性
   IPv6增加了一种新的特性,该特性能为要求特殊句柄发送者,诸如服务的非默认量或
   “实时”服务,贴上属于特定通信“流”的分组标签。

o  鉴定和私有化特性

   扩展以支持鉴定,数据完整,以及(优化的)数据机密性是IPv6特有的。

本文档详述了基本的IPv6报头和初始定义的IPv6扩展报头和选项,并且也讨论了分组尺寸
问题,流标签和优先权的语义以及IPv6在上层协议中的影响。IPv6地址的格式和语义分别
在[RFC-1884]中得以说明。ICMP的IPv6版本在[RFC-1885]里被说明,那里所有的IPv6实
现都被要求包括。

2.  术语

节点      - 实现IPv6的设备。

路由器    - 一个转发没有清晰指向自身IPv6分组的节点。[见下面的注意]

主机      - 任何不是路由器的节点。[见下面的注意]

上层       - 紧挨着IPv6的上一个协议层。例子是传输协议如TCP和UDP,控制协议如
             ICMP,路由协议如OSPF以及Internet或低层作为“隧穿”(即封装进)
             IPv6的协议如IPX,AppleTalk或是IPv6本身。

链路       - 在能在链路层(即IPv6下的一层)通信的节点之上的一种通信设施或媒质。
             例子是Ethernets(简易的或桥接的),PPP链路,X.25,帧中继,或者
             ATM网络,以及Internet(或更高)层“隧道”,如隧穿IPv4或IPv6自身。

邻居        - 连接在同一链路上的节点。

接口        - 到一个链路的节点连接设置。

地址        - 一个接口或一组接口的IPv6标识符。

分组        - 加上有效载荷的IPv6报头。

链路 MTU    - 在一个链路上能搬运的一片最大传输单元,即八位字节分组的最大尺寸。

路径 MTU    - 源节点和目的节点之间路径里所有链路的最小链路MTU。

注意:尽管有些不寻常,但对有多个接口的设备来说,把它配置成转发从其某些接口组
(少于全部)来的非自身预定的分组,并且抛弃从其别的接口抵达的非自身预定分组是
可能的。当收到从前一个(正在转发的)接口以及和邻居相互作用的分组时,这样的设
备必须遵循路由的协议要求。当收到从后一个(非正在转发的)接口以及和邻居相互作
用的分组时,这样的设备必须遵循主机的协议要求。

3.  IPv6报头格式

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 版本  | 优先权 |              流     标     签                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         有效载荷长度         |    下一报头   |     跳限制       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         源    地    址                        +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                        目   的   地   址                      +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

版本             4位Internet协议版本号=6

优先权           4位优先权值。见第7节。

流标签           24位流标签。见第6节。

有效载荷长度      16位无符号整数,有效载荷的长度,即IPv6报头之后分组部分是八
                  位字节形式。如果为零,则说明有效载荷长度携带在一个巨大有效
                  载荷逐跳选项里。

下一个报头        8位选择器。标识紧接着IPv6报头的报头种类。其和IPv4协议域使用
的
                  是同一个值[RFC-1700后面有述]。
]
下一跳限制        8位无符号整数,转发此分组的每个节点都减去一。如果下一跳限制
                  降为零则此分组被抛弃。

源地址            分组始发者的128位地址。见[RFC-1884]。

目的地址          分组指定接受者的128位地址(如果一个路由报头出现,则可能不
                  是最终接收者)。见[RFC-1884]以及4.4部分。

4.  IPv6扩展报头

在IPv6里,任选Internet层信息被编码在分隔的报头里,这个报头可能位于分组的IPv6
报头和上一层报头之间。有少量这样的扩展报头,每个都被一个明确的下一报头值所标识。
正如在这些例子中例证的一样,IPv6分组可以有零、一、或更多扩展报头,每个分组都被
前一个报头的下一报头域所标识:
   +---------------+------------------------
   |  IPv6  报头   | TCP 报头 + 数据
   |               |
   |  下一个报头 =  |
   |      TCP      |
   +---------------+------------------------

   +---------------+----------------+------------------------
   |  IPv6  报头   |  路 由 报 头    | TCP 报头 + 数据
   |               |                |
   |  下一个报头  = |  下一个报头  =  |
   |      路由     |      TCP       |
   +---------------+----------------+------------------------

   +---------------+----------------+-----------------+-----------------
   |  IPv6  报头   |   路 由 报 头   |   分 片 报 头    |  TCP 分 片 
   |               |                |                 | 报头 + 数据
   |  下一个报头 =  |   下一个报头 =  |   下一个报头 =   |
   |     路由      |      片 段      |       TCP       |
   +---------------+----------------+-----------------+-----------------

有一种例外,除非分组抵达一个标识在IPv6报头目的地址域里的节点(或一组节点中的
每一个,以多播的形式传递),否则扩展报头不会被沿着一分组传递路径上的任何节点
所检查或处理。这样,如果没有扩展报头出现,那么IPv6下一报头域上的正常多路分解
就会激发此模块去处理第一个扩展报头,或者是在扩展报头没有出现时去处理上层报头。
每个扩展报头的内容和语义决定是否去继续到下义报头。所以扩展报头必须严格按它们
在分组里出现的顺序来处理。例如,一个接收器就不能通过扫描一个分组来寻找一种特
别的扩展报头并优先于处理所有前面的分组来处理它。

前面段落里提到的例外就是逐跳选项报头,其携带的信息必须被沿着分组传递路径的每
个节点所处理,包括源和目的地址。逐跳选项报头出现时必须立即接着IPv6报头。它的
出现在IPv6下一报头域里用数值零来指出。

作为处理一个报头的结果,假如一个节点被继续传递到下一个报头但在当前报头里的下一
报头值不被节点承认的话,节点就会废弃分组并发送一ICMP参数问题信息,包括一ICMP编
码值2(意即“遭遇未被承认的下一报头类型”)和在原始分组里包含未承认值的补偿的
ICMP指针域到分组源发地。如果一个节点在非IPv6报头里遭遇为零的下一报头值,同样的
措施也会被采取。

每个扩展报头都是一个8个8位字节的整数倍,这是为了给后来的报头保留8个8位字节的
队
列。每个扩展报头里的多个8位字节域是排列在它们的本来边界上的,即对n=1,2,4,或
8来说,n个8位字节宽的域被放置在从报头开始的n个8位字节的整数倍位置上。

一个IPv6的完全实现包括下列扩展报头的实现:
        
        逐跳选项
        路由(型号 0)
        分片
        目的选项
        授权
        封装安全有效载荷
前面四项将在这篇文档里被详述,后两项将分别在[RFC-1826]和[RFC-1827]中得以描述。

4.1  扩展报头顺序

     当超过一种扩展报头被用在同一个分组里时,可推荐的是那些报头按下列顺序出现:

           IPv6报头
           逐跳选项报头
           目的选项报头(注1)
           路由报头
           分片报头
           授权报头(注2)
           封装安全有效载荷(注2)
           目的选项报头(注3)
           上层报头

      注 1:指那些将被第一个目的地址处理的选项,这个目的地址出现在IPv6目的地址
            域里的选项应加上随后列在路由报头里。
      注 2:考虑授权和封装安全有效载荷报头相关顺序的附加推荐在[RFC-1827]里给出。

      注 3:指那些将仅被分组最终目的地处理的选项。
      
除了那些目的选项报头将最多出现两次(一次在路由报头之前,另一次在上层报头之前),每
个扩展报头将最多出现一次。

如果上层报头是另一个IPv6报头(以IPv6的形式被隧穿或被封装在IPv6里)的话,那它可
能会被它自身的扩展报头紧接着,这两个报头属于同一级别的推荐。

如果并且当别的扩展报头被定义的话,那么它们相对于上面所列报头的顺序约束必须被描
述。

除了只被约束在立即出现在IPv6报头之后的逐跳选项报头之外,IPv6节点必须接受以及试
图处理同一分组里以任何顺序并发生在任何时间的扩展报头。但是,粘有上述推荐顺序
IPv6分组源是已经得以仔细考虑过的,直到并且除非以后的规定能修订那个推荐顺序。

4.2  选项

当前定义过的两个扩展报头--逐跳选项报头和目的选项报头--以下面的格式携有被编码
为“选项”的类型长度值(type-length-value(TLV))的变量

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
      |  选项类型   |  选项数据长度     |   选项数据
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

      选项类型             选项类型的8位标识符。

      选项数据长度         8位未标记整数。此选项的选项数据长度域以8位字节的形式。
      
      选项数据             可变长度域。选项类型精确数据。

在报头里的选项选项顺序必须严格按它们出现在报头里的顺序来处理;例如,一个接收者
不能搜索报头寻找一种特殊选项并在处理所有先于它的选项之前优先处理。

选项类型标识符是被内在编码的以便如果正在处理IPv6的节点没有承认选项类型的话,则
标识符最高两位字节能说明这个行为。

      00 - 跳过这个选项并继续处理报头。

      01 - 抛弃此分组
                   
      10 - 抛弃此分组并且无论此分组目的地址是不是一个广播地址都发送一ICMP参数
           问题(代码2)报文给分组的源地址以指出未被承认的选项类型。
 
      11 - 抛弃此分组并且仅假使分组目的地址不是广播地址时才发送ICMP参数问题
           (代码2)报文给分组的源地址以指出未被承认的选项类型。

选项类型的第三最高位字节表明那个选项的选项数据是否能改变中间选路至分组的最后
目的。当授权报头出现在分组里时,对于任何其数据可能改变中间选路的选项来说,在计
算或检验分组授权值时它的全部选项数据域必须被看作零值的字节。   

      0 - 选项数据不会改变中间选路

      1 - 选项数据必须改变中间选路

单个选项可能有特殊的队列要求来确保选项数据域里的多字节值指向本来边界。一个选项
的队列要求是使用符号xn+y来指定的,意味着选项类型出现必须出现在从报头开始的一个
x个字节相乘的整数再加上y个字节。例如:

       2n    意味着任何从报头开始的2个8位字节的偏移。

       8n+2  意味着任何从报头开始的8个8位字节的偏移再加上2个8位字节。

当必须要排列后来的选项并且衬垫所包含的报头在长度上达到8个8位字节的倍数时,则有
两个填料选项要使用。这些填料选项必须被所有IPv6实现所承认:

填料1 选项  (队列要求:无)

       +-+-+-+-+-+-+-+-+
       |       0       |
       +-+-+-+-+-+-+-+-+

       注意!填料1选项的格式是一种特殊形式--它没有长度和值域。

填料1选项是被用来把一个8位字节的填料插入报头的选项区域的。如果需要超过一个8位
字
节的填料的话,那么填料n选项,正如下面所述,应当被使用,而不是多个填料1选项相乘。

填料N选项  (队列要求:无)

       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
       |       1       |  选项数据长度  |  选项数据
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -

填料N选项是被用来把两个或更多8位字节的填料插入报头的选项区域的。对N个8位字节
的填料来说,选项数据长度域包含值为N-2,并且选项数据由N-2个零值的8位字节组成。

附录A包含设计新选项的格式化向导。

4.3  逐跳选项报头

逐跳选项报头用来携带必须被沿着分组传输路径的每个节点所检查的优化信息。逐跳选项
报头是用IPv6报头里为零值的下一报头来标识的,并且有下列格式:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  下 一 报 头   |  报头扩展长度  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   .                                                               .
   .                            选   项                            .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   下一报头             8位选择器。标识紧挨着逐跳选项报头的报头类型。使用
                        和IPv4协议域的相同值[如RFC-1700所述]。

   报头扩展长度         8位未标记整数。逐跳选项报头长度是以8字节为单元的,
                       不包括头8个字节。

   选项                 可变长度域,其长度可使逐跳选项报头完整为8字节的整数
                        倍。正如4.2节里形容的一样包含一个或多个TLV编码选项。

在第4.2节里有对填料1和填料N的附加说明,下面是逐跳选项的定义:

   巨有效载荷选项(队列要求:4n+2)

                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |      194      | 选项数据长度=4 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                      巨 有 效 载 荷 长 度                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

巨有效载荷选项用来把大于65,535字节的有效载荷和IPv6分组一起发送。巨有效载荷长度
就是以字节为单位的分组长度,除去IPv6报头但包括逐跳选项报头;其一定大于65,535个
字节。如果一个分组和包含少于或等于65,535字节巨有效载荷长度的巨有效载荷选项一起
被收到的话,那么一个代码为零并指向无效巨有效载荷长度域的高位字节的ICMP参数差错
报文应被发送到分组的源发地。

IPv6里的有效载荷长度域应在携带有巨有效载荷选项的每个分组里被设置为零。如果分组
和一当前的巨有效载荷选项以及一非零IPv6有效载荷长度域一起收到,则一个代码为零并
指向巨有效载荷选项的选项类型域的ICMP参数差错报文应被发送到分组的源发地。

巨有效载荷选项不能用在携带分片报头的分组里。如果在包含有效巨有效载荷选项的分组
里遇到分片报头,则一个代码为零并指向分片报头首字节的ICMP参数差错报文应被发送到
分组的源发地。

一个不支持巨有效载荷选项的实现有到链路的接口,其链路MTU大于65,575字节(40字节
的IPv6加上65,535字节的有效载荷)。

4.4   路由报头

IPv6源发地使用路由报头来列出到分组目的地址途中要“访问”的中间节点。这个功能与
IPv4的源路由选项是非常相似的。路由报头是由紧接着继续报头里值为43的下一报头来定
义的,格式如下:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   下一报头   |  报头扩展长度  |    路由类型   |   遗 留 部 分    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        特 殊 类 型 数 据                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

下一报头                8位选择器。标识紧随着路由报头的报头类型。和IPv4协议域里
                        使用的值一样[如RFC-1700里所述一样]

扩展报头长度            8位未标记整数。长度为8个字节的路由报头,不包括头8个字
节。

路由类型                特定路由报头变量的8位标识符。

遗留部分                8位未标记整数。剩下的路由部分数目,即被清楚列出在抵达最
                        终目的地之前仍然需要访问的中间路由的数目。

特殊类型数据            可变长度域,其格式由路由类型决定,并且其长度能使完整的
                       路由报头是8个字节长度的整数倍。

假如节点正在处理一收到的分组时遭遇带有未被承认路由类型值的路由报头,则此节点所
要求的行为依靠遗留部分域值,如下:

      如果遗留部分是零,则节点必须忽略路由报头并继续处理分组里的下一个报头,这个
      报头的类型是由路由报头里的下一报头域来标识的。

      如果遗留片段不是零,则节点必须抛弃此分组并发送代码为零且指向未承认路由类型
的ICMP参数差错代码报文到分组的源发地址。

零路由报头类型有下列格式:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   下一报头    |  报头扩展长度  | 路 由 类 型=0 |   遗 留 片 段   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    预   留    |                 严格/宽松位图                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                              地址[1]                          +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                              地址[2]                          +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                               .                               .
   .                               .                               .
   .                               .                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                              地址[n]                          +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

下一报头                8位选择器。标识紧随着路由报头的报头类型。和IPv4协议域
                       里使用的值一样[如RFC-1700里所述一样]

扩展报头长度            8位未标记整数。长度为8个字节的路由报头,不包括头8个字
                       节。对于零型路由报头,报头扩展长度等于报头里地址数的两
                       倍,且必须是一个小于等于46的偶数。

路由类型                0。

遗留部分                8位未标记整数。剩下的路由部分数目,即被清楚列出在抵达
                        最终目的地之前仍然需要访问的中间节点的数目。
                        最大合法值是23。

预留                    8位预留域。对于传输初始为零;接收时忽略。

严格/宽松的位图          24位的位图,值从0到23,并是从左到右。对于路由的每一片
                        来说,位图指明是否下一个目的地址必须是前一个地址的邻
                        居:1意味着严格(必须是邻居),0意味着宽松(不需要是邻
                        居)。

地址[1...n]             128位的地址矢量,数目从1到n。

多播地址不必在类型为零的路由报头里出现,或是在携带零路由报头类型分组的IPv6目的
地址域里出现。

如果严格/宽松位图的位数值为零,则源分组里IPv6报头的目的地址域必须标识源节点的
一个邻居。如果位数为零,则源发者必须使用任何合法的,非多播地址作为初始目的地址。

位数大于n的位必须被源发者设为零并被接收者忽略,这里n是在路由报头里的地址数。

路由报头不会被检查或处理除非它抵达在此IPv6报头目的地址域里被标识的节点。在那个
节点,在紧随着前一个报头的下一报头域上分派会导致路由报头模块将被调用,这样以类型
为零的路由形式来执行下列算法:

   if 遗留片段 = 0 {
      继续处理分组里的下一报头,它的类型是由路由报头里的下一报头域来标识的
   }
   else if 报头扩展长度是奇数或大于46{
       发送代码为零并指向报头扩展长度域,且抛弃此分组的ICMP参数差错报文到源地
       址。
   }
   else {
       用扩展报头长度除以2来计算n,n为路由报头里的地址数。
      if 遗留片段大于n {
       发送代码为零并指向遗留片段域,且抛弃此分组的ICMP参数差错报文到源地
       址。
      }
      else {
         遗留片段减一;
         通过把遗留片段减去n来计算i,i是地址矢量里将要被访问的下一地址的索引。

         if 地址 [i] 或IPv6目的地址是广播 {
            抛弃分组
         }
         else {
            交换IPv6目的地址和地址[i]

            if 严格/宽松位图的第i位值为1并且新的目的地址不是这个节点的邻居
            地址{
               发送ICMP目的地不可抵达报文--这不是一到源地址的邻居报文并抛
               弃此分组。
            }
            else if IPv6 跳限制小于或等于一 {

               发送ICMP时间超过--在到源地址的传输报文里跳限制超过并抛弃此
               分组
            }
            else {
               从跳限制里减掉1

               重新递交分组给到新目的地的传输IPv6模块
            }
         }
      }
   }

作为上述算法效用的一个例子,考虑一种从源节点S发送一分组到目的节点D,并使用导致
分组通过紧挨着的节点I1,I2,和I3被路由的路由报头。在传递路径每个片段上的相关
IPv6报头值和路由报头域的值如下:

当分组从S到I1:

        源地址 = S                  报头扩展长度= 6
        目的地址 = I1               遗留片段 = 3
                                    地址[1] = I2
        (如果位图的零位是 1,         地址[2] = I3
         则S和I1必须是邻居,         地址[3] = D
         这个将被S检查)


当分组从I1到I2:

        源地址 = S                  报头扩展长度= 6
        目的地址 = I2               遗留片段 = 2
                                    地址[1] = I2
        (如果位图的1位是 1,         地址[2] = I3
         则I1和I2必须是邻居,        地址[3] = D
         这个将被I1检查)

当分组从I2到I3:

        源地址 = S                  报头扩展长度= 6
        目的地址 = I3               遗留片段 = 1
                                    地址[1] = I1
        (如果位图的2位是 1,         地址[2] = I3
         则I2和I3必须是邻居,         地址[3] = D
         这个将被I2检查)

当分组从I3到D:

        源地址 = S                  报头扩展长度= 6
        目的地址 = D                遗留片段 = 0
                                    地址[1] = I1
        (如果位图的3位是 1,          地址[2] = I2
         则I3和D必须是邻居,         地址[3] = I3
         这个将被I3检查)

4.5  分片报头

IPv6源发地用分片报头来发送比能适合在路径MTU里还大的分组到它们的目的地。(注意:
不象IPv4,IPv6里的分片只通过源节点来实现,而不是由沿着分组传递路径的路由器来实
现的--见第5节。)分片报头是由在前一个报头里,值为44的下一报头值来实现的,并且有
下列格式:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  下一报头    |   预       留   |       分 片 补 偿       |预留|M|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         标          识                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

下一报头                8位选择器。标识初始分组(如下面所定义的)的分片部分的
                        初始报头。使用和IPv4协议域一样的值[如RFC-1700里所述]。

预留                    8位预留域。传输时初始为零,接收时忽略。

分片补偿                13位未标记整数。相对于初始分组的分片部分开始来说是随着此
报头并以8个字节为单元的数据补偿。

预留                    2位的预留域。传输时初始为零,接收时忽略。

标志M                   1=更多分片;0=最后的分片。

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

为了发送一个太大了以至于不适合路径MTU的分组到它的目的地,源节点可以把分组分成分
片并把每个分片作为一个独立分组来发送,这些分组到达接收者时再被重新集合。

对于每个将要被分片的分组来说,源节点产生标识值。这个标识必须和近来*同一个源发地
址和目的地址上的任何别的分片分组不同。如果路由报头出现,要考虑的目的地址就是最
后的目的地址。

     *“近来”意味着是要在分组的最大可能生存时间内,包括从源发地到目的地的传输
       时间和花在等待要重组的同一个分组的其余分片上的时间。然而这并不要求源节点
       知道分组的最大生存周期,而是假定维持作为一个简单的,32位的,“回环”计数
       器的,并且每次分组必须被分片时能增加的标识值能符合要求。这是是否维持一个
       简单的节点还是多个计数器的实现选择,例如,此节点的每个可能源地址用一个计
       数器,或者每个活动的(源地址,目的地址)连接一个计数器。

初始时大的未分片的分组被参考为“原始分组”,并被认为是由两部分组成的,如下:

   原始分组:

   +------------------+----------------------//----------------------+
   |     未 分 片     |                    分    片                   |
   |       部分       |                    部    分                   |
   +------------------+----------------------//-----------------------+

未分片的部分由IPv6报头和扩展报头组成,是必须由到目的地前中间选路上的节点处理的,
即直到包括路由报头(如果出现的话)的所有报头,另外也包括逐跳选项报头(如果出现
的话),但不包括扩展报头。

分片部分由此分组的其余部分组成,即任何仅需要由最终目的节点所处理的扩展报头以及上
层报头和数据。

初始分组的分片部分被分成分片,除了可能是最后“最右面”的那个分片,每个分片长度都
是8字节的整数倍。分片将按下面例证的独立“分片分组”来传输:

原始分组:

   +------------------+--------------+--------------+--//--+----------+
   |      未 分 片    |    第一个     |    第二个     |      |   最终   |
   |        部分      |     分片      |     分片      | .... |   分片   |
   +------------------+--------------+--------------+--//--+----------+

分片分组:

   +------------------+--------+--------------+
   |     未 分 片     |  分 片 |    第一个     |
   |       部分       |  报 头 |     分片      |
   +------------------+--------+--------------+

   +------------------+--------+--------------+
   |     未 分 片     |  分 片 |    第二个     |
   |       部分       |  报 头 |     分片      |
   +------------------+--------+--------------+
                         o
                         o
                         o
   +------------------+--------+--------------+
   |     未 分 片     |  分 片 |     最终      |
   |       部分       |  报 头 |     分片      |
   +------------------+--------+--------------+

每个分片分组的组成:

    (1) 初始分组的未分片部分和初始IPv6报头的有效载荷长度一起改变到仅包含此分
        片分组的长度(除去IPv6报头自身的长度),并且未分片部分的最后报头的下
        一报头域改变为44。

    (2) 一个分片报头包括:

         标识初始分组分片部分的第一个报头的下一报头值。

         包含相对于初始分组分片部分开始而言的分片补偿,并以8字节为单元的分片补
         偿。第一个分片(“最左边”)的分片补偿是零。

         一个标志M,当分片是最后(“最右边”)一个时值为零,否则标志M值为1。

      (3) 分片自身。.

分片的长度必须被选择能产生适合在到分组目的地路径的MTU里的分片分组。

在目的地,分片分组被重新组合为原始的,未分片的形式,如下:

   重组原始分组:

   +------------------+----------------------//------------------------+
   |    未  分  片     |                   分    片                     |
   |      部  分       |                     部分                       |
   +------------------+----------------------//------------------------+

下列规则支配重组:

原始分组只能从具有同一源地址,目的地址以及分片标识的分片分组来重组。

重组分组的未分片部分由直到但不包含第一个分片分组的分片报头的所有报头组成(就是
说,分组的分片补偿是零),有下面两个变化:

未分片部分最后一个报头的下一报头域是从分片报头的第一个分片的下一报头域里获得的。

重组分组的有效载荷长度是从未分片部分和最后一个分片的长度和补偿里计算得到的。例
如,一种计算重组初始分组的有效载荷长度的公式是:

           PL.orig = PL.first - FL.first - 8 + (8 * FO.last) + FL.last

           这里
           PL.orig  = 重组分组的有效载荷长度域。
           PL.first = 第一个分片分组的有效载荷长度域。
           FL.first = 随着第一个分片分组的分片报头的分片长度。
           FO.last  = 最后一个分片分组的分片报头的分片补偿域。
           FL.last  = 随着最后一个分片分组的分片报头的分片长度。

重组分组的分片部分是从接着每个分片分组的分片报头的分片来建立的。每个分片的长度
是通过从分组有效载荷长度里减去IPv6报头和分片本身之间的长度来计算的。它在分片部
分的相对位置是通过它分片补偿值来计算的。

分片报头没有出现在最后的重组分组里。

当重组被分片的分组时可能产生以下错误类型:

假如收到的分片数不足以使在那个分组第一个抵达分片接收60秒内完成重组的话,则分组
重组必须被终止而且所有已经被收到的分组分片必须被抛弃。如果第一个分片(即分片补
偿值为零的那个)已经被接收,ICMP时间超出--分片重组时间超出报文应该被发送到分片
的源发地。

如果作为从分片分组有效载荷长度域引出的分片长度不是8字节的倍数并且分片的标志M是
1,那么这个分片必须被抛弃并发送代码为零且指向分片分组有效载荷长度域的ICMP参数
差错代码报文到分组的源发地址。

如果分片的长度和补偿值致使从分片重组产生的分组有效载荷长度将超过65,535字节那么
这个分片必须被抛弃并发送代码为零且指向分片分组分片补偿域的ICMP参数差错代码报文
到分组的源发地址。

下列情况不期望发生,但如果出现了则不应被视为错误:

同一初始分组的不同分片的前面分片报头的报头数目和内容可能不同。不管报头怎样出现,
在排列用来重组的分片之前,前面每个分片分组分片报头在分组抵达时首先被处理。只有
那些补偿为零的分片分组里的那些报头保留在重组后的分组里。

同一原始分组的不同分片的分片报头的下一报头值可能不同。只有从补偿值为零的分片分
组里来的值才被用于重组。

4.6  目的地选项报头

目的地选项报头是用来携带仅需要被分组的目的节点检查的优化信息的。目的地选项报头
用紧前面一个报头里为60的下一报头值来标识,格式有如下:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    下一报头    |  扩展报头长度  |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   .                                                               .
   .                            选   项                            .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   下一报头             8位选择器。标识紧接着目的地选项报头的报头类型。使用和
                        IPv4协议域一样的值[如RFC-1700里所述]。

   扩展报头长度         8位未标记整数。目的地选项报头长度是以8字节为单元的,
                       不包括头8个字节。

   选项                 可变长度域,其长度可使目的地选项报头完整为8字节的整数
                        倍。正如4.2节里形容的一样包含一个或多个TLV编码选项。

本文档里定义的唯一目的地选项是在第4.2节里说明的填料1和填料N。

注意到有两种可能的方法可以编译IPv6分组里的优化目的地信息:要么作为目的地选项
报头的一个选项,要么做一个独立的扩展报头。分片报头和授权报头是后一种方法例子。
使用哪种方法取决于不能理解优化信息的目的节点所期望的是何种行为:

      o  如果目的节点期望行为是抛弃分组并且分组的目的地址不是一个多播地址的话,
         那么信息要么被编码成一个独立报头要么作为目的选项报头里的一个选项,此
         目的选项报头里的选项类型在其本身最高两位值为11。这个选择可能取决于怎
         样采用更少的字节,或怎样产生更好的队列,或更有效的语法等因素。

      o   如果期望的是任何别的行为,则信息必须被编码成目的选项报头里的一个选项,
         其在最高两位的选项类型值为00,01,或10,用来说明期望行为(见4.2节)。

4.7 无下一报头

IPv6报头的下一报头域里的值为59或者任何扩展报头指出这个报头后没有报头了。如果
IPv6的有效载荷长度指出字节晚于一个下一报头域里有59的报头末尾出现时,这些字节
将被抛弃,并且如果分组被转发则字节将不改变地传递。

5. 分组尺寸问题

IPv6要求在Internet网上的每个链路都有576或更多字节的MTU。在任何一个不能搬运576
个
字节或更多字节分组的链路上,链路特定分片或重组必须在IPv6下一层来提供。

从每个链路到它直接连着的节点,节点都必须能接收和链路MTU一样大的分组。有一个
可配置的MTU(如PPP链路[RFC-1661])的链路必须被配置为有至少576字节的MTU。推荐
配置一个更大的MTU以适应可能的不招致分片的封装。

为了发现并利用具有大于576字节MTU的路径,强烈推荐IPv6节点实现路径MTU发现
[RFC-1191]。然而最小化的IPv6实现(如在导入ROM里)可能简单地限制本身发送不超
过576个字节的分组,且忽略了路径MTU发现的实现。

为了发送一大于路径MTU的分组,节点可使用IPv6分片报头来在源发地分开分组并在目的
地重组分组。然而这样分片在任何能调节本身分组去适合标准路径MTU(即降到576字节)
的应用里是不成功的。

一个节点必须能接收在重组后有1500字节大的分片分组,分组包括IPv6报头。节点允许
接收重组后大于1500字节的分片分组。然而节点不能发送重组后尺寸大于1500字节的分
片除非其已清楚地得知目的地能重组这样大尺寸的分组。

作为IPv6分组被发送到IPv4目的地的响应(即,分组经历从IPv6到IPv4的转换),初始
IPv6节点可能收到一个报告下一跳MTU少于576的ICMP分组太大报文。这样IPv6节点就不
被要求去减少后续分组尺寸到少于576字节,但必须包括一个分片报头在分组里以使IPv6
到IPv4转换路由器能获得一个用在导致IPv4分片的有效标识值。注意到这意味着有效载荷
可能必须被减少到528字节(576减去IPv6报头的40和分片报头的8个字节),并且如果附
加扩展报头被使用的话还可以更小。

      注意:路径MTU发现必须被一致执行,这里主机“认为”目的地是连接到和本身一样
      的链路上。

      注意:不象IPv4,为了执行路径MTU发现,IPv6里不必要设置“不分片”标签在分
      组报头里。就是说这是每个IPv6分组里的隐含特征。而且RFC-1191程序中的那些
      包括MTU“台阶”表使用的部分不能应用于IPv6,这是因为“自带寻址信息分组太
      大”报文的IPv6版本已经标识了要被使用的准确MTU。

6.  流标签

IPv6报头里的24位流标签域可以被源发地用来标记那些要求IPv6路由器进行特殊控制(如
非默认QOS或“实时”服务)的分组。在写本文档的时候,IPv6的这个问题仍然是实验性
的并且归因于对Internet里的流标签要求变得更清晰的改变。不支持流标签域功能的主机
和路由器被要求在初始分组时域要设置为零,在转发分组时不改变的穿过这个域,并且在
收到分组时忽略这个域。

流是从特定源发地发送到特定目的地(单播或多播)的一个分组序列,对于流来说,源发
地要求介于期间的路由器能对其进行特殊控制。特殊控制的本性可以通过控制协议,诸如
资源预留协议,或者通过在流分组自身里的信息,如在逐跳选项里的信息来转运到路由器。
这样控制协议或选项的细节已经超出了本文档的范围。

和没有与任何流联合在一块的通信一样,从一个源发地到目的地可能有多个活动流。一个
流是由源发地和非零流标签联合在一起来唯一标识的。不属于一个流的分组携带的流标签
为零。

流的源节点将一个流标签分配给一个流。新的流标签必须(伪)随机选择并且范围一律是
从1到0xffffff。随机分配的目的是为了在适合被路由器用做哈希键值的流标签域里设置
任何一组位,用来查询和流联合的状态。

所有属于同一流的分组必须随着同一源地址,目的地地址,优先权以及流标签一起发送。
如果任何那些分组中任何一个包括逐跳选项报头,那么它们都必须用同样的逐跳选项报头
内容(不包括逐跳选项报头的下一报头域)来初始。如果任何分组包括一路由报头,那么
它们都必须用直到包括路由报头的所有扩展报头(不包括下一路由报头的下一报头域)里
的同样内容来初始。用路由器和目的地来检查这些条件是否被满足是允许的但不是要求的。
如果探测到阻碍的话,那么节点必须通过发送代码为零且指向流标签域高位字节(也就是
IPv6分组里补偿值1)的ICMP参数差错代码报文到分组的源发地址。

对任何流来说,路由器可以自由地“象机会主义者”一样设置流控制态,甚至是在没有通
过控制协议、逐跳选项或别的方法提供给路由器清晰的流建立信息。例如,一旦收到从一
特定源发地来的带有未知且非零的流标签的分组,路由器就可以处理分组的IPv6报头和任
何必须的扩展报头,就象此时流标签是零一样。这样的处理将包括决定下一跳接口以及可
能的其它行为,如更新逐跳选项、推前路由报头里的指针和地址、或者判定怎样基于优先
权域来排列分组。然后路由器可能选择“记住”那些处理步骤的结果并缓存这些信息,同
时使用源地址加上流标签作为缓存键值。接着随后带有同一源地址和流标签的分组就可以
参考缓存的信息来操控,而不是根据文章前面要求那样去检查所有那些能假设为流里所见到
的从第一个分组开始就未改变的域。

正如前面所述,不管同一流的其他分组是否继续抵达,随机设置的缓存流控制态在其被建
立后6秒之内必须被抛弃。如果在缓存态已经废弃后别的带同一源地址和流标签的分组抵
达的话,分组将经受完全、正常地处理(好象它的流标签是零一样),可能导致对这个流
重建缓存流态。

例如被控制协议和逐跳选项随机设置的缓存流控制态的生存周期必须作为清晰的设置机制
规范的一部分来说明。

源发地在任何可能已经为流标签预先使用而建立的流控制态的生存周期里不能再为新的流
使用流标签。这是因为在6秒生存期内流控制态可以随机为任何流建立,在使用同一流标
签的流的最后一个分组和一新流的第一个分组间间隔是6秒。有更长流态生存期的用作清
晰设置流的流标签在被重新为新流使用前必须保持不被用做那些更长生命周期。

当一个节点停止并重新开始(如作为“崩溃”的结果)时,它必须仔细地不要使用一个已
经被用作更早的、生存期可能还没有过期的流的流标签。这可能通过在稳定存储器上记录
流标签以使流标签在崩溃后能被记住,或者通过在直到任何先前可能建立流最大生存期到
期(至少6秒;如果带有更长生存期的清晰流设置机制已经使用则时间更长)之前避免使
用任何流标签来完成。如果重起节点的最小时间(经常是多于6秒)已知,那么在开始分
配流标签前这个最小时间能被从必须等待时期内扣除。

对于所有或甚至大多数属于流,也就是携带非零流标签的分组来说并没有特殊要求。这份
评估放在这儿让协议设计者和实现者不要去考虑别的方面。例如仅假定大多数分组属于流
就想要去设计一个性能完备的路由器或者去设计一个仅工作在属于流的分组之上的报头压
缩机制都是不明智的。

7.  优先权

IPv6里的4位优先权域可以使源发地能相对于从同一源发地来的别的分组用它期望的传输
优先权进行标识。优先权值被分成两个范围:0到7的值用来指定通信优先权给正在提供阻
塞协议的源发地,即作为对阻塞的响应“退回”的通信如TCP通信。8到15的值是用来给在
响应阻塞时不能退回的通信如以常速率发送的“实时”分组以优先权。

对于受约束的阻塞通信,推荐下列优先权值给特定应用范围:

         0 - 无特征通信
         1 - “填空”通信(如网络新闻)
         2 - 不被注意的数据传输(如email)
         3 - (预留)
         4 - 被留意的块传输(如FTP,NFS)
         5 - (预留)
         6 - 交互通信(如telnet,X)
         7 - Internet控制通信(如路由控制协议,SNMP)

对于不受约束的阻塞通信来说,在阻塞条件下最低优先权值(8)应该用做那些发送者最
希望抛弃的分组(如高保真视频通信),最高优先值(15)应该赋给那些发送者最不希
望抛弃的分组(如低保真的音频通信)。在受约束的阻塞优先权和不受约束的优先权之
间没有暗示的相对顺序。

8. 上层协议问题
8.1 上层校验和

任何包括从IP报头来的地址的传输层或别的上层协议在它的校验和计算里必须修改得可
以在IPv6上使用,即用128位IPv6地址来代替32位IPv4地址。特别的,下面的例证显示
了IPv6的TCP和UDP的“伪报头”。

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                         源  地  址                            +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   +                        目  的  地  址                         +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          有效载荷长度                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        零                     |    下一报头    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      o  如果分组包含有路由报头,用在伪报头里的哪个目的地址就是最终目的地。在
         源节点,这个地址将是路由报头的最后部分。在接收方这个地址将是在IPv6报
         头的目的地址域里。

      o  伪报头里的下一报头值标识了上层协议(如,TCP对应的是6,UDP是17)。如
         果在IPv6报头和上层报头之间有扩展报头的话,那么伪报头的下一报头值和
         IPv6报头里的下一报头值会不同。

      o  用在伪报头里的有效载荷长度是上层分组的长度,包括上层报头。如果在IPv6
         报头和上层报头之间有扩展报头的话,那么伪报头的有效载荷长度将小于IPv6
         报头里的有效载荷长度(或是在巨有效载荷选项里)。

      o  不象IPv4,当UDP分组被一个IPv6节点初始时,UDP的校验和没有被优化。就是
         说不管什么时候初始一个UDP分组时,IPv6节点都必须在分组和伪报头上计算UDP
校验和,并且如果计算产生的结果是零的话,UDP报头里的位置也必须被改变为0xffff。IPv6
接收者必须抛弃包含零校验和的UDP分组并记录错误。

ICMP [RFC-1885]的IPv6版本在其校验和计算里包括上述伪报头,而IPv4版本没有在校验
和里包括伪报头,这是一个从ICMP的IPv4版本来的改变。这个改变的理由是为了保护ICMP
在其依靠的IPv6报头域上不会中断或误传,而不象IPv4一样被网络层校验和掩盖。ICMP的
伪报头里的下一报头域包含的值是58,这样就标识了ICMP的IPv6版本。

8.2 最大分组生存周期

不象IPv4,IPv6节点不需要增强最大分组生存周期。这是因为IPv4“存活”域在IPv6里
重新命名为“跳限制”。实际上即便要的话,只有非常少的IPv4实现顺应于它们限制分组
生存周期的要求,以至于实践中并没有什么改变。任何依靠网络层协议去限制分组生存周
期的上层协议(不管是IPv4还是IPv6)都必须先升级才能提供给自身探测和抛弃废旧分组
的机制。

8.3 最大上层有效载荷尺寸

当计算最大有效载荷尺寸对上层数据来说是可行的时候,上层协议必须考虑相对IPv4报头
的IPv6报头的更大尺寸。例如,在IPv4里TCP的MSS是用最大分组尺寸(默认值或通过路
径
MTU发现学习得来的值)减去40字节(20字节是最小化IPv4报头长度和20字节的最小化
TCP
报头长度)来计算的。当在IPv6上使用TCP时,因为IPv6报头的最小化长度要(就是说,
IPv6报头没有扩展报头)比最小化的IPv4长度多20字节,MSS必须用最大分组尺寸减去60
字节来计算。

附录A 选项的格式化指导策略

本附录对如何在设计用在逐跳选项报头或者目的选项报头(正如4.2节里形容的一样)里
的新选项时放置域给出一些建议。这个指导策略是基于如下一些假设:

      o  一个期望的特征是在选项的选项数据区里任何被排列在它们本来边界上的多字节
         域,即宽度为n字节的域应该被放置在从逐跳或目的选项报头的开始的n字节的整
         数倍位置,这里n=1、2、4、或者8。

      o  由于报头是8字节长的整数倍的要求,所以另一个期望的特征是逐跳或目的选项
         报头要尽可能小空间地建立。

      o  当选项类报头中任一个出现时可以假定它们携带非常小的选项个数,通常只为1。

这些假定提出下列方法去放置选项的域:没有内部填充地从最小到最大将域排序,然后派
生基于最大域排列要求(直到8字节的最大队列)的整个选项排列要求。这个方法用下面
的方法来例证:

   实例 1

如果选项X要求两个数据域,8字节长的域和4个字节长的域,可以如下放置:
 
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |   选项类型 =X  | 选项数据长度=12|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            4-字节域                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                            8-字节域                           +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

为了确保8字节域是在从封装报头的开始的8字节的倍数补偿开始的,要求它的队列是8n+2。
一个完整的包括一个这样选项的逐跳或目的选项报头应该看起来如下:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   下一报头    | 扩展报头长度=1 |   选项类型=X  | 选项数据长度=12  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            4-字节域                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                            8-字节域                           +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   实例 2

如果选项Y要求三个数据域,8字节长的域、4个字节长的域已经一个1字节长的域,可以如
下放置:

                                                   +-+-+-+-+-+-+-+-+
                                                   |   选项类型=Y  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 选项数据长度=7 |    1-字节域   |            2-字节域            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             4-字节域                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

为了确保4字节域是在从封装报头的开始的4字节的倍数补偿开始的,要求它的队列是4n+3。
一个完整的包括一个这样选项的逐跳或目的选项报头应该看起来如下:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    下一报头   | 扩展报头长度=1 |  填料1 选项=0 |   选项类型=Y    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 选项数据长度=7 |   1-字节域    |            2-字节域            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            4-字节域                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 填料N 选项=1   | 选项数据长度=2 |       0       |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   实例 3

包含例1中的选项X和例2中的选项Y的逐跳和目的选项报头根据选项出现的前后将是下列
两种格式之一:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   下一报头    | 扩展报头长度=3 |  选项类型=X   | 选项数据长度=12  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            4-字节域                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                            8-字节域                           +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 填料N 选项=1  | 选项数据长度=1 |       0       |   选项类型=Y   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 选项数据长度=7 |   1-字节域    |            2-字节域            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            4-字节域                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 填料N 选项=1  | 选项数据长度=2 |       0       |       0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   下一报头    | 扩展报头长度=3 | 填料1 选项=0  |   选项类型=Y    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |选项数据长度=7  |   1-字节域    |           2-字节域             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                              4-字节域                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | 填料N 选项=1  | 选项数据长度=4 |       0       |       0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0       |       0       |   选项类型=X  | 选项数据长度=12 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            4-字节域                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                            8-字节域                           +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

安全考虑参考Internet协议[RFC-1825]里的安全架构,本文档说明了和IPv6一起使用
的IP授权报头[RFC-1826]和IP封装安全有效载荷[RFC-1827]。

致谢

作者对IPng工作组、端到端协议研究组、以及Internet社区成员的许多有益建议表示衷心
的感谢。

作者地址

   Stephen E. Deering                   Robert M. Hinden
   Xerox Palo Alto Research Center      Ipsilon Networks, Inc.
   3333 Coyote Hill Road                2191 E. Bayshore Road, Suite 100
   Palo Alto, CA 94304                  Palo Alto, CA 94303
   USA                                  USA

   Phone: +1 415 812 4839               Phone: +1 415 846 4604
   Fax:   +1 415 812 4471               Fax:   +1 415 855 1414
   EMail: deering@parc.xerox.com        EMail: hinden@ipsilon.com

参考

   [RFC-1825]   Atkinson, R., "Security Architecture for the Internet
                Protocol", RFC 1825, Naval Research Laboratory, August
                1995.

   [RFC-1826]   Atkinson, R., "IP Authentication Header", RFC 1826,
                Naval Research Laboratory, August 1995.

   [RFC-1827]   Atkinson, R., "IP Encapsulating Security Protocol
                (ESP)", RFC 1827, Naval Research Laboratory, August
                1995.

   [RFC-1885]   Conta, A., and S. Deering, "Internet Control Message
                Protocol (ICMPv6) for the Internet Protocol Version 6
                (IPv6) Specification", RFC 1885, Digital Equipment
                Corporation, Xerox PARC, December 1995.

   [RFC-1884]   Hinden, R., and S. Deering, Editors, "IP Version 6
                Addressing Architecture", RFC 1884, Ipsilon Networks,
                Xerox PARC, December 1995.

   [RFC-1191]   Mogul, J., and S. Deering, "Path MTU Discovery", RFC
                1191, DECWRL, Stanford University, November 1990.

   [RFC-791]    Postel, J., "Internet Protocol", STD 5, RFC 791,
                USC/Information Sciences Institute, September 1981.

   [RFC-1700]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
                RFC 1700, USC/Information Sciences Institute, October
                1994.

   [RFC-1661]   Simpson, W., Editor, "The Point-to-Point Protocol
                (PPP)", STD 51, RFC 1661, Daydreamer, July 1994.

rfc1883 - Internet Protocol, Version 6 (IPv6) Specification 
          Internet协议,版本6(IPv6)说明书


RFC1883——Internet Protocol, Version 6 (IPv6) Specification    
Internet协议,版本6(IPv6)说明书


2
RFC文档中文翻译计划
打赏 赞(0)
比特币钱包
以太坊钱包
比特币钱包二维码图片

比特币钱包扫描二维码打赏

以太坊钱包二维码图片

以太坊钱包扫描二维码打赏

Article Attachments

Was this article helpful?

Related Articles

Leave A Comment?

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据