rfc2460.txt

很多RFC的中文文档

个首部来寻找某个特定类型的选项， 并且在处理所有前面的选项之前处理它。
选项类型标识符以如下规则编码: 其最高两比特指定了当 IPv6 节点无法识别这一选项类
型时所必须的反应:
00 - 跳过这一选项， 继续处理首部。
01 - 抛弃这个包
10 - 抛弃这个包， 并且不管包的目的地址是不是组播地址， 都给包的源地址发送一个 
ICMP "参数存在问题"， 编码 2 的报文， 指针指向无法识别的选项类型。
11 - 抛弃这个包， 并且只有当包的目的地址不是组播地址时， 才给包的源地址发送一个 
ICMP "参数存在问题"， 编码 2 的报文， 指针指向无法识别的选项类型。
选项类型标识符的第三位指明了选项数据是否可以改变到最终目的地址的选路。若存在认证
首部， 在包计算或校验认证值时， 可改变选路的选项的整个数据字段都必须当作全零的八
位组来处理。
0 - 选项数据不会改变选路
1 - 选项数据可能改变选路
上述的前三位应作为选项类型的一部分， 而不能独立于选项类型之外。 这就是说，某一特
定的选项是由全部 8 比特的选项类型标识符标识的， 而并不只是选项类型中的后面 5 位。
Hop-by-Hop 选项首部和目的地址选项首部使用相同的选项类型编码空间。 尽管如此， 某
一特定类型的选项的规范可以限制其只用于两者之一。
有些选项可能具有明确的对齐要求， 以保证选项数据字段中的多八位组值能够落在其自然
边界上。 选项的对齐要求用符号 xn+y 来说明， 表示选项类型必须出现在从首部开始位
置处 x 个八位组的整数倍加上 y 个八位组的位置上。 例如:
2n 表示从首部开始处 2 个八位组的整数倍的偏移量。
8n+2 表示从首部开始处 8 个八位组的整数倍加上 2 个八位组的偏移量。
有两种填充选项， 用来在需要时对齐后续的选项， 以及把整个首部填充成 8 个八位组的
整数倍长。 所有的 IPv6 实现都必须能够识别这些填充选项。
填充1 选项 (对齐要求: 无)
+-+-+-+-+-+-+-+-+
| 0 |
+-+-+-+-+-+-+-+-+
注意! 填充1 选项是一种特殊情况 -- 它没有长度字段和数值字段。
填充1 选项用于在首部的选项区填充一个八位组。 如果需要填充多于一个的八位组， 那
么就应该使用下面要介绍的填充N 选项， 而不是多个填充1 选项。
填充N 选项 (对齐要求: 无)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
| 1 | 选项数据长度 | 选项数据
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - -
填充N 选项用于在首部的选项区填充两个或两个以上的八位组。 对于 N 个八位组的填
充， 选项数据长度字段应包含值 N-2， 选项数据由 N-2 个零值八位组组成。
附录 B 包含了设计新的选项格式的指导方针。
4。3 Hop-by-Hop 选项首部
Hop-by-Hop 选项首部用于传送必须由包的传送路径中的每个节点检测的可选信息。
Hop-by-Hop 选项首部由 IPv6 首部中"下一个首部"字段值为 0 来标识， 并且具有如下的
格式:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 下一个首部 | 首部扩展长度 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |

 选 项 。

| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
下一个首部 8 比特选择器。 标识紧跟在 Hop-by-Hop 选项首部后面的首部的类型。 使用
与 IPv4 协议字段 [RFC-1700 及后续协议] 相同的数值。
首部扩展长度 8 比特无符号整数。 以 8 个八位组为单位的 Hop-by-Hop选项首部的长度， 
不包括开始的 8 个八位组。
选项 可变长度字段， 其长度须使整个 Hop-by-Hop 选项首部的长度为 8 个八位组的整数
倍。 包含一个或多个 TLV 编码的选项， 如第 4。2 章中所述。
在本文中定义的仅有的 Hop-by-Hop 选项是填充1 及填充N 选项， 如第 4。2 章中
所述。
4。4 路由首部
路由首部用于 IPv6 源节点列出到包的目的节点的路径中所应"访问"的一个或多个中间节
点。 这一功能十分类似于 IPv4 的松散源地址和路由记录选项。 前面的首部中"下一个首
部"字段中的值为 43 表示下一个首部为路由首部。 路由首部具有如下的格式:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 下一个首部 | 首部扩展长度 | 路由类型 | 分段剩余 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |

 特定 类型数据

| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
下一个首部 8 比特选择器。 标识紧跟在路由首部后面的首部的类型。
使用与 IPv4 协议字段 [RFC-1700 及后续协议] 相同的数值。
首部扩展长度 8 比特无符号整数。 以 8 个八位组为单位的路由首部的长度， 不包括开始
的 8 个八位组。
路由类型 8 比特的某种特定路由首部变量的标识符。
分段剩余 8 比特无符号整数。 剩余的路由分段的数量。 也就是在到达最终的目的节点之
前仍然应当访问的， 明确列出的中间节点的数量。
特定类型的数据 可变长度字段。 其格式由路由类型决定， 其长度须使整个路由首部的长
度为 8 个八位组的整数倍。
如果节点在处理收到的包的过程中遇到了含有无法识别的路由类型值的路由首部，节点应根
据分段剩余字段中的值进行处理， 如下所述:
如果分段剩余值是零， 节点必须忽略路由首部， 继续处理包中的下一个首部， 其类型由
路由首部中的"下一个首部"字段中的值来标识。
如果分段剩余值非零， 节点必须抛弃这个包， 并且给包的源地址发送一个 ICMP"参数存
在问题"， 编码 0 的报文， 指针指向无法识别的路由类型。
如果中间节点在处理路由首部之后， 确定应将包传送到一个链路 MTU 小于此包的尺寸的
链路中去， 那么中间节点必须抛弃此包， 并且给包的源地址发送一个 ICMP"包太大"的报
文。
类型 0 的路由首部具有如下格式:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 下一个首部 | 首部扩展长度 | 路由类型 = 0 | 分段剩余 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 保 留 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 地 址 [1] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 地 址 [2] +

+ +
| |
+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 地 址 [n] +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
下一个首部 8 比特选择器。 标识紧跟在路由首部后面的首部的类型。
使用与 IPv4 协议字段 [RFC-1700 及后续协议] 相同的数值。
首部扩展长度 8 比特无符号整数。 以 8 个八位组为单位的路由首部的长度， 不包括开始
的 8 个八位组。 对于类型 0 的路由首部， 首部扩展长度等于首部中地址数量的两倍。
路由类型 0。
分段剩余 8 比特无符号整数。 剩余的路由分段的数量。 也就是在到达最终的目的节点之
前仍然应当访问的， 明确列出的中间节点的数量。
保留 32 比特保留字段。 传输时初始化为零; 接收时忽略。
地址[1。。n] 128 比特地址向量， 从 1 到 n 编号。
不允许组播地址出现在类型 0 的路由首部中， 也不允许出现在携带类型 0 路由首
部的包中的 IPv6 目的地址字段中。直到包到达 IPv6 首部中的目的地址字段所标识的那个
节点才对路由首部进行检测和处理。 在这个节点调用路由首部处理模块， 并且对于路由类
型 0， 执行下面的算法:
if 分段剩余 = 0 {
继续处理包中的下一个首部， 其类型由路由首部中"下一个首部"字段所标识}
else if 首部扩展长度为奇数 {
给源地址发 鸵桓?ICMP "参数存在问题"， 编码 0 的报文， 指针指向首部扩展长度字段， 
并且抛弃此包
}
else {
计算出n， 也就是路由首部中的地址数量。 方法是首部扩展长度除以 2
if 分段剩余比 n 大 {
给源地址发送一个 ICMP "参数存在问题"， 编码 0 的报文， 指针指向分段剩余字段， 并
且抛弃此包
}
else {
分段剩余减一;
计算 i， 也就是地址向量(地址列表)中要"访问"的下一个地址， 方法是 n 减分段剩余
if 地址[i] 或者 IPv6 目的地址是组播地址 {
抛弃此包
}
else {
交换 IPv6 目的地址和地址[i]
if IPv6 跳数限制小于等于 1 {
给源地址发送一个 ICMP "超时 – 传输超过跳数限制" 的报文， 并且
抛弃此包
}
else {
跳数限制减一;
向 IPv6 模块重新提交此包， 传给新的目的节点
}
}
}
}

作为上述算法的一个例子， 考虑这样一种情况: 源节点 S 给目的节点 D 发送一个包， 用
路由首部来使这个包经过中间节点 I1， I2 和 I3。 在传送路径的每段中， IPv6 首部中的
相关字段值以及路由首部字段值应为如下所述:
当包从 S 传到 I1:
源地址 = S 首部扩展长度 = 6
目的地址 = I1 分段剩余 = 3
地址[1] = I2
地址[2] = I3
地址[3] = D
当包从 I1 传到 I2:
源地址 = S 首部扩展长度 = 6
目的地址 = I2 分段剩余 = 2
地址[1] = I1
地址[2] = I3
地址[3] = D
当包从 I2 传到 I3:
源地址 = S 首部扩展长度 = 6
目的地址 = I3 分段剩余 = 1
地址[1] = I1
地址[2] = I2
地址[3] = D
当包从 I3 传到 D:
源地址 = S 首部扩展长度 = 6
目的地址 = D 分段剩余 = 0
地址[1] = I1
地址[2] = I2
地址[3] = I3
4。5 分片首部
IPv6 源节点使用分片首部来发送大于去往目的节点的路径 MTU 的包。 (注意: 不同于 
IPv4 的是， 在 IPv6 里， 只有包的源节点才能进行分片， 传输路径中的路由器不能进行
分片 – 参见第 5 章) 前面的首部中"下一个首部"字段中的值为 44 表示下一个首部为分
片首部。 分片首部具有如下格式:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 下一个首部 | 保 留 | 分片偏移量 |Res|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 标 识 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
下一个首部 8 比特选择器。 标识原包(后面有定义)中可分片部分的初始首部的类型。 使
用与 IPv4 协议字段 [RFC-1700 及后续协议] 相同的数值。
保留 8 比特保留字段。 传输时初始化为零; 接收时忽略。
分片偏移量 13 比特无符号整数。 以 8 个八位组为单位的， 首部后面的数据相对于原包
中可分片部分的开始位置处的偏移量。
Res (保留) 2 比特保留字段。 传输时初始化为零; 接收时忽略。
M 标志位 1 = 还有分片; 0 = 最后一个分片。