rfc2460.txt

很多RFC的中文文档

o 与 IPv4 不同的是， 当 IPv6 节点生成 UDP 包时， UDP 校验和不是可选的。也就是
说， 只要生成 UDP 包， IPv6 节点必须计算数据包和伪首部的 UDP 校验和。 而且， 如
果计算结果为 0， 必须将其改为十六进制的 FFFF， 放入 UDP首部。 IPv6 接收节点必
须抛弃包含零校验和的 UDP 包， 并记录这一错误。IPv6 版本的 ICMP [ICMPv6] 在计算
校验和时包含上述的伪首部; 这是一个与 IPv4的版本不同的地方 -- IPv4 的版本在校验和
中不包含伪首部。 改变的原因是防止ICMP 发生不正确的传送， 以及 IPv6 首部中的这
些字段发生讹误 -- 它们没有受到网络层校验和的保护。 ICMP 的伪首部中"下一个首部"
字段的值为 58， 标识IPv6 版本的 ICMP。
8。2 包的最大生存期
与 IPv4 不同的是， IPv6 节点不必强制规定一个包的最大生存期。 这就是 IPv4 中的"生
存期"字段在 IPv6 中改名为"跳数限制"的原因。 在实际中， IPv4 实现很少强制要求限制
包的生存期， 所以这一点实际上并没有改变。 任何依赖网络层协议 (IPv4 或 IPv6) 来限
制包的生存期的上层协议必须进行升级， 自己提供检测和抛弃过期的数据包的机制。
8。3 上层协议的最大有效载荷尺寸
当计算可提供给上层协议数据的最大有效载荷尺寸的时候， 上层协议必须考虑到IPv6 首
部比 IPv4 首部大。 例如， 在 IPv4 里， TCP 的 MSS 选项是包的最大尺寸 (缺省值或
者由路径 MTU 发现技术提供的值) 减去 40 个八位组 (IPv4 首部的最小长度 20 和 
TCP 首部的最小长度 20)。 当通过 IPv6 使用 TCP 时， MSS 必须改为包的最大尺寸减
去 60 个八位组， 这是因为 IPv6 首部的最小长度 (也就是没有任何扩展首部的 IPv6 首
部) 比 IPv4 首部的最小长度长 20 个八位组。
8。4 对携带路由首部的包的响应
当上层协议发送一个或多个包， 作为包含路由首部的包的响应时， 响应包中不能包含由所
收到的路由首部"反向"而自动得到的路由首部。 除非收到的源地址和路由首部的完整性和
可靠性已得到验证 (比如通过使用收到的包中的认证首部)。 换句话说， 只有下面几类包
可以响应由路由首部定向的包:
o 不携带路由首部的响应包。
o 携带路由首部的响应包， 但其携带的路由首部不是由所收到的包中的路由首部反向得到
的 (例如， 由本地配置信息提供的路由首部)
o 携带路由首部的响应包， 其路由首部是由所收到的包中的路由首部反向而得到的。 但所
收到的包中的源地址和路由首部的完整性和可靠性必须经过响应者验证。

附录 A。 数据流标签字段的语义和用法
数据流是指从某特定的源节点向某特定的 (单播或组播) 目的节点发送的数据包的序列。 
当源节点希望中间的路由器对数据包进行一些特殊处理时， 可以使用数据流。 这一特殊处
理的种类可以由某一控制协议， 如资源预约协议， 或者由数据流中的包自身中的信息， 如
在 hop-by-hop 选项首部里的选项， 传达给路由器。 关于这样的控制协议或者选项的详细
资料已经超出了本文的范围。
从源节点到目的节点之间可能有数条活动的数据流， 还可能有同任何数据流都无关的业务
量。 一个数据流由一个源地址和一个非零的数据流标签唯一地标识。 不属于任何一个数据
流的包具有零值的数据流标签。
由数据流的源节点为数据流分配数据流标签。 新的数 萘鞅昵┍匦氪?1 到 FFFF (十六进制) 
之间伪随机地选出来。 随机分配数据流标签的目的是使得路由器能够使用数据流标签字段
中的任意一组位作为哈希关键字， 用来查询与数据流相关的状态。
属于同一数据流的包必须具有相同的源地址， 目的地址和数据流标签。 如果其中的一些包
包含 Hop-by-Hop 选项首部， 那么它们都必须具有相同内容的 Hop-by-Hop选项首部 (除
了 Hop-by-Hop 选项首部中的"下一个首部"字段)。 如果其中的一些包包含路由首部， 那
么它们在路由首部之前 (含路由首部) 的所有扩展首部的内容都必须相同 (除了路由首部中
的"下一个首部"字段)。 允许但不要求路由器或目的节点检验上述条件是否满足。 如果检
测到违反上述条件， 应向源节点发送 ICMP"参数存在问题"， 编码 0 的报文， 指针指向
数据流标签字段的高位 (也就是， 在IPv6 包中偏移量为 1)。
在数据流的路径中建立的数据流处理状态的最大生存期必须作为描述状态建立机制的一部
分加以规范。 比如资源预约协议， 或者"数据流建立" hop-by-hop 选项。
使用一个数据流标签以后， 不允许源节点在这个已建立的数据流处理状态的最大生存期内
重新使用这个数据流标签。
当节点停机和重新启动(比如系统崩溃)时， 它必须小心， 不要使用先前用过的可能尚未过
期的数据流的数据流标签。 有多种解决方法: 可以在稳定可靠的存储器中记录数据流标签
的使用情况， 这样节点就能在系统崩溃前后记住它。 或者在所有先前建立的数据流过期以
前， 避免使用任何数据流。 如果知道系统重新启动的最短时间， 这一时间可从开始分配
数据流标签之前的等待时间中扣除。
不要求全部的包， 甚或大多数的包处于数据流中 (也就是， 携带非零的数据流标签)。
这一观察报告放在这里， 提醒协议的设计者和实现者不要对此做出任何假定。 例如， 设
计一个这样的路由器是不明智的， 其性能只有在大多数包处于数据流中的时候才差强人意。 
再如， 设计一个只用于数据流中的包的首部压缩方案也是欠考虑的。

附录 B。 选项字段格式的指导方针
本附录对设计用于 Hop-by-Hop 选项首部和目的地址选项首部 (见第 4。2 章) 的新选项时
如何安排字段提出了一些建议。 这些原则以如下假设为基础:
o 选项的数据区中任意多八位组字段应放在其自然边界上。 也就是说， 长度为n 个八位
组的字段应放在距 Hop-by-Hop 选项首部和目的地址选项首部的开始位置处 n 个八位组
的整数倍的位置上， 其中 n = 1， 2， 4， 或 8。
o Hop-by-Hop 选项首部和目的地址选项首部应使用尽量少的空间。 但必须满足， 整个首
部的长度应为 8 个八位组的整数倍。
o 不妨假定携带选项的首部即使存在， 也只携带非常少的选项， 通常只有一个。由这些假
设可以设计出如下安排选项中字段，以由小到大的顺序排列字段，其间没有内部填充， 然
后由最大字段的对齐要求得到整个选项的对齐要求 (最大到8 个八位组的对齐)。 下面的例
子说明了这一方法:
例 1
如果选项 X 需要两个数据字段， 一个为 8 个八位组， 一个为 4 个八位组， 这些字段
应如下排列:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 选项类型 = X |选项数据长度=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 八位组字段 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 8 八位组字段 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
这一选项的对齐要求为 8n+2， 保证 8 八位组字段从距所在的首部开始位置处 8 个八位
组的整数倍处开始。 包含此选项的完整的 Hop-by-Hop 选项首部或目的地址选项首部看上
去应是下面的样子:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 下一个首部 |首部扩展长度=1 | 选项类型 = X |选项数据长度=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 八位组字段 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 8 八位组字段 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
例 2
如果选项 Y 需要三个数据字段， 一个为 4 个八位组， 一个为 2 个八位组， 一个
为 1 个八位组， 这些字段应如下排列:
+-+-+-+-+-+-+-+-+
| 选项类型 = Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|选项数据长度=7 | 1 八位组字段 | 2 八位组字段 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 八位组字段 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
这一选项的对齐要求为 4n+3， 保证 4 八位组字段从距所在的首部开始位置处 4 个八位
组的整数倍处开始。 包含此选项的完整的 Hop-by-Hop 选项首部或目的地址选项首部看上
去应是下面的样子:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 下一个首部 |首部扩展长度=1 | 填充1 选项=0 | 选项类型 = Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|选项数据长度=7 | 1 八位组字段 | 2 八位组字段 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 八位组字段 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 填充N 选项=1 |选项数据长度=2 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

例 3
同时包含选项 X 和选项 Y (见例 1 和例 2) 的 Hop-by-Hop 选项首部或目的地址选项首
部可以有如下两种格式:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 下一个首部 |首部扩展长度=3 | 选项类型 = X |选项数据长度=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 八位组字段 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 8 八位组字段 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 填充N 选项=1 |选项数据长度=1 | 0 | 选项类型 = Y |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|选项数据长度=7 | 1 八位组字段 | 2 八位组字段 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 八位组字段 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 填充N 选项=1 |选项数据长度=4 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 选项类型 = X |选项数据长度=12|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 八位组字段 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ 8 八位组字段 +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

安全性的考虑
IPv6 的安全特性由"Internet 协议的安全体系结构" [RFC-2401] 进行描述。
致谢
感谢 IPng 工作小组， 点到点协议研究小组以及整个 Internet 团体的成员提出的有益建议。
作者的地址
Stephen E。 Deering
Cisco Systems， Inc。
170 West Tasman Drive
San Jose， CA 95134-1706
USA
Phone: [phone]
Fax: [phone]
EMail: deering@cisco。com
Robert M。 Hinden
Nokia
232 Java Drive
Sunnyvale， CA 94089
USA
Phone: [phone]
Fax: [phone]
EMail: hinden@iprg。nokia。com

参考文献
[RFC-2401] Kent， S。 和 R。 Atkinson， "Security Architecture for the
Internet Protocol"， RFC 2401， 1998 年 11 月。
[RFC-2402] Kent， S。 和 R。 Atkinson， "IP Authentication Header"， RFC 240
2，
1998 年 11 月。
[RFC-2406] Kent， S。 和 R。 Atkinson， "IP Encapsulating Security Protocol

(ESP)"， RFC 2406， 1998 年 11 月。
[ICMPv6] Conta， A。 和 S。 Deering， "ICMP for the Internet Protocol Ver
sion
6 (IPv6)"， RFC 2463， 1998 年 12 月。

[ADDRARCH] Hinden， R。 和 S。 Deering， "IP Version 6 Addressing
Architecture"， RFC 2373， 1998 年 7 月。
[RFC-1981] McCann， J。， Mogul， J。 和 S。 Deering， "Path MTU Discovery for

IP version 6"， RFC 1981， 1996 年 8 月。
[RFC-791] Postel， J。， "Internet Protocol"， 标准 5， RFC 791， 1981 年 9
月。
[RFC-1700] Reynolds， J。 和 J。 Postel， "Assigned Numbers"， 标准 2， RFC 1
700，
1994 年 10 月。 请参阅:
http://www。iana。org/numbers。html
[RFC-1661] Simpson， W。， "The Point-to-Point Protocol (PPP)"， 标准 51， RFC
1661， 1994 年 8 月。
自 RFC-1883 以来的变化
本文自 RFC-1883 以来有以下变化。 数字表示变化所在的 Internet 草案版本号。
02) 删除所有关于巨数据包和巨数据包有效载荷选项的内容 (移到一个单独的文档中)。
02) 已将大部分数据流标签的细节从第 6 章移到新的附录 A 中。
02) 在附录 A 中关于数据流标签的细节中， 将最大数据流标签值从 FFFFF 改为FFFF (也
就是减少一个 "F")。 这是由于数据流标签字段的尺寸从 24 比特减为 20 比特。
02) 将原来的附录 A 更名为附录 B。
02) 修改了"安全性的考虑"一章的措辞， 以避免本规范与 IP 协议规范族形成依赖性循环。
02) 更新了 R。 Hinden 的电子邮件地址和所在的公司。
01) 在第三章， 将字段名 "类别" 改为 "传输类别"， 并将其尺寸从 4 字节增加到 8 字节。 
将数据流标签字段从 24 字节减到 20 字节， 以补偿传输类别字段所增加的字节。
01) 在第 4。1 章中， 恢复了认证首部和 ESP 首部的次序。 这一次序曾在 00 版本的草
案中错误地修改过。
01) 在第 4。4 章中， 从类型 0 的路由首部中 境