rfc2460.txt

很多RFC的中文文档

标识 32 比特。 参见下面的详细说明。
要发送大于去往目的节点的路径 MTU 的包， 源节点可以将包分成若干分片， 每个分片
单独发送， 并且在接收者处进行重组。
源节点应为每个要分片的包规定一个标识值。 这个标识值必须不同于近期之内*同一对源节
点和目的节点之间其他的分片包的标识值。 如果存在路由首部， 那么目的节点是指最终目
的节点。
* "近期之内" 是指包可能的最大生存期。 其中包括从源节点到目的节点的传输时间， 以
及等待与同一包的其他分片重组所花费的时间。 尽管如此， 源节点并没有必要知道包的最
大生存期。 它只需将标识字段值作为一个简单的32 比特循环计数器， 每次将包分片时计
数器增加一个增量即可。 具体的实现可以自己选择是维护一个计数器还是多个计数器， 还
可以选择是为每个节点可能的源地址维护一个计数器， 还是为每个活动的 (源地址， 目的
地址) 对维护一个计数器。
最初的， 未分片的大数据包称为"原包"。 原包可以看作是由两部分组成的， 如下
所示:
原包:
+------------------+----------------------//-----------------------+
| 不可分片 | 可分片 |
| 部分 | 部分 |
+------------------+----------------------//-----------------------+
不可分片部分包括 IPv6 首部， 以及那些必须由路由中的节点处理的扩展首部。
也就是以下三种情况: 所有路由首部以前(含路由首部)的首部(如果存在的话)，或者是 
Hop-by-Hop 选项首部(如果存在的话)， 或者没有扩展首部。
包中其余的部分为可分片部分， 也就是只需由包的最终目的节点处理的扩展首部， 以及上
层协议首部和数据。
原包中可分片部分被划分成若干分片， 除去最后("最右")一个分片， 每个分片都为
8 个八位组的整数倍长。 这些分片由相互独立的"分片包"来传送， 如下例所示:
原包:
+------------------+--------------+--------------+--//--+----------+
| 不可分片 | 第一个 | 第二个 | | 最后一个 |
| 部分 | 分片 | 分片 | 。。。。 | 分片 |
+------------------+--------------+--------------+--//--+----------+

分片包:
+------------------+--------+--------------+
| 不可分片 | 分片 | 第一个 |
| 部分 | 首部 | 分片 |
+------------------+--------+--------------+
+------------------+--------+--------------+
| 不可分片 | 分片 | 第二个 |
| 部分 | 首部 | 分片 |
+------------------+--------+--------------+
o
o
o
+------------------+--------+--------------+
| 不可分片 | 分片 | 最后一个 |
| 部分 | 首部 | 分片 |
+------------------+--------+--------------+
每个分片包由下述几部分构成:
(1) 原包中的不可分片部分。 其中原来 IPv6 首部中有效载荷长度值只应包含本分片包的
长度 (不包含 IPv6 首部自身的长度)。 不可分片部分中最后一个首部的"下一个首部"字段
值改为 44。
(2) 分片首部。 其中包括:
其"下一个首部"值标识原包中可分片部分的第一个首部。其分片偏移量字段 包含以 8 个八
位组为单位的， 本分片相对于原包中可分片部分开始位置处的偏移量。 第一个("最左")分
片的分片偏移量为 0。
其 M 标志位为 0 表示这是最后("最右")一个分片， 否则 M 标志位为 1。其标识值依原
包产生。
(3) 分片自身
分片的长度应使分片包的尺寸适于去往目的节点的路径 MTU。
在目的节点， 分片包重组为原来未分片的形式， 如下例所示:
重组的原包:
+------------------+----------------------//------------------------+
| 不可分片 | 可分片 |
| 部分 | 部分 |
+------------------+----------------------//------------------------+
重组应遵循如下原则:
原包只能由具有相同源地址， 目的地址和分片标识的分片包重组。
重组后的包中的不可分片部分由第一个分片包(也就是分片偏移量为 0 的那个包)中分片首
部前面所有的首部(不含分片首部)组成， 并作如下两处修改:
从第一个分片的分片首部中的"下一个首部"字段得到不可分片部分最后一个首部中的"下一
个首部"字段值。
由不可分片部分的长度及最后一个分片的长度和偏移量计算出重组包的有效载荷长度。 计
算重组包的有效载荷长度的公式为:
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 "参数存在问题"， 
编码 0 的报文， 指针指向分片包的有效载荷
长度字段。
如果分片的长度和偏移量使得重组后的包的有效载荷长度超过了 65，535 个八位组， 那么
必须抛弃这个分片， 并且向分片的源节点发送一个 ICMP "参数存在问题"， 编码 0 的报
文， 指针指向分片包的分片偏移量字段。
不希望出现下述情形， 但不将它们视为错误:
同一个原包的不同分片中， 分片首部前面的首部在数量和内容上都可能不同。当每个分片
包到达时， 无论分片首部前面的首部是什么， 都应在进入分片重组队列之前进行处理。 只
有分片偏移量为零的那个包中的首部才保留在重组后的包中。
同一个原包的不同分片中， 分片首部中"下一个首部"值可能不同。 只有分片偏移量为零的
那个包中的值才可用于重组。
4。6 目的地址选项首部
目的地址选项首部用于携带只需由包的目的节点检测的可选信息。 前面的首部中"下一个首
部"字段中的值为 60 表示下一个首部为目的地址选项首部。 目的地址选项首部具有如下格
式:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 下一个首部 | 首部扩展长度 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
。 。
。 选 项 。
。 。
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
下一个首部 8 比特选择器。 标识紧跟在目的地址选项首部后面的首部的类型。 使用与 
IPv4 协议字段 [RFC-1700 及后续协议]相同的数值。
首部扩展长度 8 比特无符号整数。 以 8 个八位组为单位的目的地址选项首部的长度， 不
包括开始的 8 个八位组。
选项 可变长度字段， 其长度须使整个目的地址选项首部的长度为 8 个八位组的整数倍。 
包含一个或多个 TLV 编码的选项， 如第 4。2 章中所述。
在本文中定义的仅有的目的地址选项是填充1 及填充N 选项， 如第 4。2 章中所述。
需要注意的是， 有两种途径来编码目的地址的可选信息: 或者作为目的地址选项首部中的
一个选项， 或者作为一个独立的扩展首部。 分片首部和认证首部就是后者的典型例子。 使
用哪种方法取决于目的节点无法识别这一可选信息时， 希望采取的措施:
o 如果希望节点抛弃这个包， 并且当包的目的地址不是组播地址时， 给包的源地址发送一
个 ICMP "类型无法识别"报文， 可以将这一信息编码成独立的扩展首部或者目的地址选项
首部中的一个选项， 其选项类型的最高两位为 11。
最终的选择可以根据其他的因素而定， 比如哪一个可以使用更少的八位组，哪一个能生成
更好的对齐或者具有更高的处理效率。
o 如果希望采取其他的措施， 那么这一信息必须作为目的地址选项首部的一个选项进行编
码。 其选项类型的最高两位为 00， 01 或 10， 指定所需采取的措施 (参见第 4。2 章)。
4。7 "无下一个首部"
IPv6 首部或者扩展首部中"下一个首部"的值为 59 表示这个首部后面没有其他的首部了。 
如果 IPv6 首部中的有效载荷字段表明最后一个首部 ("下一个首部"字段为 59 的那个首部) 
后面还有其他的八位组， 那么这些八位组将被忽略， 并且在传输过程中保持不变。
5。 包的尺寸问题
IPv6 要求互联网上的每条链路具有 1280 或更多个八位组的 MTU。 无法在一片之内传送 
1280 个八位组的链路必须根据链路的情况在 IPv6 下层的协议中提供分片和重组机制。
具有可配置 MTU 的链路 (比如 PPP 链路 [RFC-1661]) 必须配置为具有至少 1280
个八位组的 MTU; 建议配置成具有 1500 或更多个八位组的 MTU， 这样可以容纳可能的
封装 (也就是"隧道") 而不至于在 IPv6 协议层分片。
与链路直接连接的节点必须能够接收链路 MTU 大小的包。
强烈建议 IPv6 节点使用 "路径 MTU 发现" 技术 [RFC-1981]， 以发现比 1280 个八位组
更大的路径 MTU， 并发挥其优点。 但是， 一个最小的 IPv6 实现 (比如， 在启动 ROM 
里) 可以简单的限制自己只发送小于 1280 个八位组的包， 从而忽略 "路径 MTU 发现" 
技术。
要发送大于路径 MTU 的包， 节点可以使用 IPv6 分片首部， 在源节点将包分片， 并在
目的节点将包重组。 但是， 如果应用程序能够调整包的大小来适合标准的路径MTU， 那
么最好不要使用分片。
节点必须能够接收重组后大小为 1500 个八位组的分片包。 同时， 允许节点接收重组后大
于 1500 个八位组的分片包。 基于 IPv6 分片来发送大于路径 MTU 的包的上层协议或应
用程序不应发送大于 1500 个八位组的包， 除非它确信目的节点能够重组这样大的包。
作为发往 IPv4 目的节点的 IPv6 包 (也就是从 IPv6 转换成 IPv4 的包) 的响应， IPv6 
的初始节点可能收到 ICMP "包太大"报文， 报告下一跳 MTU 小于 1280。 在这种情况下， 
IPv6 节点不必将后续的包的尺寸减小到 1280 以下， 但必须在这些包中包含一个分片首
部， 使得负责从 IPv6 到 IPv4 之间转换的路由器能够得到一个适当的标识值， 用来生成 
IPv4 分片。 需要注意的是， 这就意味着有效载荷将减小到 1232 霭宋蛔?( 1280 减去 IPv6 
首部的 40 和分片首部的 8)， 如果还有其他的扩展首部， 有效载荷将变得更小。
6。 数据流标签
IPv6 首部中 20 比特的数据流标签字段用于源节点标识那些需要 IPv6 路由器特殊处理的
包的序列， 比如非缺省质量的服务或者"实时"服务。 撰写这篇文章的时候， IPv6 在这方
面尚处于实验阶段， 并且随着因特网上支持数据流的要求变得越来越清楚， 它还可能有所
改变。 不支持数据流标签字段功能的主机和路由器应在初始化数据包的时候将此字段设为
零， 传输包的时候保持不变， 接收包的时候忽略。附录 A 描述了当前数据流标签字段已
经明确了的语义和用法。
7。 传输类别
IPv6 首部中 8 比特的传输类别字段可用于初始节点和/或转寄路由器标识和区分不同 
IPv6 包的类别或优先级。 撰写本规范的时候， 已经总结了在使用 IPv4 服务类型和/或优
先级位 (用来为 IP 包提供不同形式的"区别服务"， 不同于显式的建立数据流) 的过程中的
若干经验。 IPv6 首部中的传输类别字段在 IPv6 中提供了相似的功能。
希望这些经验能够使得人们在哪种传输分类对 IP 包最为有用的问题上达成一致意见。 对 
IPv6 传输类别中全部或部分数据位的结构和语义的详细定义， 或者是实验性的， 或者是
最终的标准， 都将在单独的文档中提供。
下面是传输类别字段所应满足的总的要求:
o 节点中 IPv6 服务的服务接口必须为上层协议规定一种给初始包提供传输类别数据位的
值的方法。
o 支持部分或全部传输类别数据位的某一特定 (实验性的或最终标准) 用法的节点可以根
据其用法修改它们所生成的， 传输的或者收到的包中的这些位的值。 如果节点不支持这一
用法， 应忽略这些位， 并保持其值不变。
o 上层协议不应假定所收到的包中传输类别数据位的值与源节点发送此包时的值相同。
8。 上层协议的问题
8。1 上层协议校验和
在计算校验和时包含 IP 首部中地址的传输层或其他上层协议必须为通过 IPv6 进
行传输加以相应的改进， 将 32 位的 IPv4 地址改为 128 位的 IPv6 地址。 特别
地， 下面的例子展示了 TCP 和 UDP 的 IPv6 "伪首部":
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 源 地 址 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 目 的 地 址 +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 零 | 下一个首部 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o 如果 IPv6 包包含路由首部， 伪首部使用的目的地址就是最终的目的地址。在初始节点， 
这一地址就是路由首部的最后一个元素; 在接收者一方， 这一地址在 IPv6 首部的目的地
址字段。
o 伪首部中"下一个首部"字段值标识了上层协议的类型 (比如 6 为 TCP， 17为 UDP)。 如
果 IPv6 首部和上层协议首部之间还存在扩展首部， 那么伪首部中"下一个首部"字段的值
可能与 IPv6 首部中的值有所不同。
o 伪首部中上层协议包的长度是指上层协议的首部和数据 (比如， TCP 首部加上 TCP 数
据)。 一些上层协议携带了自己的长度信息 (比如， UDP 首部中的长度字段); 对于这样的
协议， 这些信息就是伪首部使用的长度信息。 其他协议 (比如 TCP) 不携带自己的长度信
息， 在这种情况下， 伪首部使用的长度就是 IPv6 首部中的有效载荷长度字段值减去 IPv6 
首部与上层协议首部之间扩展首部的长度。