组织：中国互动出版网（http://www.china-pub.com/） RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm） E-mail：ouyang@china-pub.com 译者： 译文发布时间：2001-10-17 版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须 保留本文档的翻译及版权信息。 Network Working Group S. Deering Request for Comments: 2460 Cisco Obsoletes: 1883 R. Hinden Category: Standards Track Nokia December 1998 Internet 协议第六版 (IPv6) 规范 (RFC2460——Internet Protocol, Version 6 (IPv6) Specification) 关于本文的说明 本文详细说明了 Internet 团体的一个标准协议， 并且请求进一步改进的讨论和建议。 请 参考"Internet 正式协议标准" (标准 1) 的当前版本来得到本协议的标准化陈述。 本文的分 发不受限制。 版权声明 版权所有 (C) Internet 协会 (1998)。 保留所有权利。 摘要 本文详细说明了 Internet 协议第 6 版 (IPv6)。 它有时叫做下一代 IP 或者IPng。 目录 1。 绪论 2 2。 术语 3 3。 IPv6 首部格式 3 4。 IPv6 扩展首部 4 4。1 扩展首部的顺序 5 4。2 选项 6 4。3 Hop-by-Hop 选项首部 7 4。4 路由首部 7 4。5 分片首部 11 4。6 目的地址选项首部 13 4。7 "无下一个首部" 14 6。 数据流标签 15 7。 传输类别 15 8。 上层协议的问题 15 8。1 上层协议校验和 15 8。2 包的最大生存期 16 8。3 上层协议的最大有效载荷尺寸 17 8。4 对携带路由首部的包的响应 17 附录 A。 数据流标签字段的语义和用法 17 附录 B。 选项字段格式的指导方针 18 安全性的考虑 20 参考文献 21 自 RFC-1883 以来的变化 21 完整的版权声明 (原文) 22 1。 绪论 IP 第 6 版 (IPv6) 是继 IP 第 4 版 (IPv4) [RFC-791] 以后， Internet 协议一个新版本。 由 IPv4 到 IPv6 的改变主要集中在以下几个方面: *地址容量的扩展 IPv6 把 IP 地址的大小从 32 位增至 128 位， 可以支持更多的地址层次， 更大数量的节 点， 以及更简单的地址自动配置。 组播路由的可缩放性改进为 给组播地址增加一个"范围"字段。 又定义了一个叫做"anycast"的新的地址类型， 用于把包 发送给一组节点中的任意一个。 *首部格式的简化 一些 IPv4 首部字段被删除或者成为可选字段， 减少了一般情况下包的处理开销以及 IPv6 首部占用的带宽。 *支持扩展和选项的改进 IP 首部选项编码方式的修改导致更加高效的传输， 在选项长度方面更少的限制， 以及将 来引入新的选项时更强的适应性。 *数据流标签的能力 加入一个新的能力， 使得那些发送者要求特殊处理的属于特别的传输"流"的包能够贴上"标 签"， 比如非缺省质量的服务或者"实时"服务。 *认证和保密的能力 为支持认证， 数据完整性以及(可选的)数据保密的扩展都在 IPv6 中说明。 本文描述 IPv6 基本首部以及最初定义的 IPv6 扩展首部和选项。 还将讨论包的 尺寸问题， 数据流标签和传输类别的语法， 以及 IPv6 对上层协议的影响。 IPv6 地 址的格式和语法在 [ADDRARCH] 中单独说明。 IPv6 版的 ICMP 是所有 IPv6 应用 都需要包含的， 它在 [ICMPv6] 中说明。 2。 术语 节点 - 应用 IPv6 的一个设备。 路由器 - 传送不是发给自己的 IPv6 包的节点。 [参见下面的说明] 主机 - 任何非路由器节点。 [参见下面的说明] 上层 - 直接在 IPv6 上层的协议层。 典型的例子是传输协议如 TCP 和 UDP，控制协议 如 ICMP， 路由协议如 OSPF， 以及网络层或在 IPv6 里被开凿了隧道 (也就是封装在 IPv6 里) 的低层协议， 比如 IPX， AppleTalk， 或者 IPv6 自身。 链路 - 一个通讯设备或者媒体。 通过它节点可以与链路层， 也就是直接在 IPv6 下面的 那一层进行通讯。 典型的例子是以太网 (简单的或者网桥的); PPP 连接; X。25帧中继， 或 者 ATM 网络; 以及网络层(或更高层)的"隧道"。 比如说通过 IPv4 或者 IPv6 本身的隧 道。 邻居 - 连在同一个链路上的节点。 接口 - 节点与链路的连接。 地址 - IPv6 层中一个接口或者一组接口的标识符。 包 - IPv6 首部加上有效载荷。 链路 MTU - 最大传输单元。 也就是以八位组为单位的能在链路中传输的包的最大尺寸。 路径 MTU - 源节点到目的节点之间的路径中所有链路的最小链路 MTU。 注意: 尽管不常见， 但这是可能的: 就是一个设备具有多个接口， 用来传输从它的某些(不 是全部)接口传来的， 不以自身为目的节点的包， 并且抛弃那些从其他接口传来的， 不以 自身为目的节点的包。 当这样的设备通过前一种接口接收包或者与其邻居联系时， 它必须 遵循协议中有关路由器的要求。 当它通过后一种接口接收包或者与其邻居联系时， 它必须 遵循协议中有关宿主机的要求。 3。 IPv6 首部格式 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 版本 | 传输类别 | 数据流标签 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 有效载荷长度 | 下一个首部 | 跳数限制 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 源 地 址 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + 目 的 地 址 + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 版本 4 比特 Internet 协议版本号 = 6。 传输类别 8 比特传输类别字段。 参见第 7 章。 数据流标签 20 比特数据流标签。 参见第 6 章。 有效载荷长度 16 比特无符号整数。 IPv6 有效载荷长度。 也就是以八位组为单位， 在这 个包中 IPv6 首部后面的其余部分的长度。 (注意， 扩展首部 [第 4 章] 将被认为是有效 载荷的一部分， 计算在长度里。) 下一个首部 8 比特选择器。 标识紧接在 IPv6 首部后面的下一个首部的类型。 使用与 IPv4 协议字段 [RFC-1700 及后续协议相同的数值。 跳数限制 8 比特无符号整数。 在每个传输此包的节点处递减1。 如果跳数限制减为零， 就 抛弃此包。 源地址 128 比特包的制作者的地址。 参见 [ADDRARCH] 目的地址 128 比特包的预期接收者的地址 (如果存在路由首部的话，可能不是最终的接收 者)。 参见 [ADDRARCH] 和第 4。4 章。 4。 IPv6 扩展首部 在 IPv6 里， 可选的网络层信息在一个独立的首部编码， 放在包中 IPv6 首部与上层协议 首部之间。 有这样几个为数不多的扩展首部， 每个首部由不同的"下一个首部"的值来标识。 一个 IPv6 首部可以携带零个， 一个或者更多的扩展首部， 每个扩展首部由前一个首部中 的"下一个首部"字段标识。 如下例所示: +---------------+------------------------ | IPv6 首部 | TCP 首部 + 数据 | | | 下一个首部 = | | TCP | +---------------+------------------------ | IPv6 首部 | 路由首部 | TCP 首部 + 数据 | | | | 下一个首部 = | 下一个首部 = | | 路由首部 | TCP | +---------------+----------------+------------------------ +---------------+----------------+-----------------+----------------- | IPv6 首部 | 路由首部 | 分片首部 | TCP 首部 + 数据 | | | | 的分片 | 下一个首部 = | 下一个首部 = | 下一个首部 = | | 路由首部 | 分片首部 | TCP | +---------------+----------------+-----------------+----------------- 除了一个特例， 扩展首部不在包的传送路径中的任何节点检测和处理， 直到这个包到达目 的地址字段标识的那个节点 (或者在组播的情况下， 一组节点中的每一个)。在这里， 对 IPv6 首部的"下一个首部"字段的常规处理将是调用处理模块来处理第一个扩展首部， 或 者， 如果不存在扩展首部， 就处理上层首部。 每个扩展首部的内容和语义决定是否处理 下一个首部。 因此， 扩展首部必须严格按照它们在包中出现的次序来处理; 这样， 接收 者就不能搜索整个包来寻找某个特定类型的首部， 并且在处理所有前面的首部之前处理它。 上文所述的特例是指 Hop-by-Hop 选项首部。 它携带了包的传送路径中的每个节点都必须 检测和处理的信息， 包括源节点和目的节点。 Hop-by-Hop 选项首部如果存在， 就必须 紧跟在 IPv6 首部后面。 IPv6 首部中"下一个首部"字段的值为零表示存在这个首部。 如果一个首部的处理结果要求节点处理下一个首部， 但是节点无法识别这个首部的"下一个 首部"字段值， 那么节点就应该抛弃这个包， 并且给包的源节点发送一个ICMP "参数存在 问题"的报文， ICMP 编码值为 1 ("遇到无法识别的'下一个首部'类型")。 ICMP 指针字段 包含那个无法识别的值在原包中的偏移量。 如果节点遇到 IPv6 首部以外的其他首部中的" 下一个首部"字段的值为零的情况， 应做相同的处理。 为了后 娴氖撞勘３?8 个八位组对齐， 每个扩展首部都是 8 个八位组的整数倍长。每个扩 展首部的多八位组字段都以它们的自然边界对齐。 也就是说， 宽度为 n 个八位组的字段 放在距首部开始位置处 n 个八位组的整数倍的位置上， 其中 n = 1， 2， 4， 或者 8。 一个完整的 IPv6 实现应包含以下扩展首部的处理程序: Hop-by-Hop 选项首部 路由首部 (类型 0) 分片首部 目的地址首部 认证首部 封装安全有效载荷首部 (ESP 首部) 前四个将在本文中加以说明， 后两个在 [RFC-2402] 和 [RFC-2406] 中分别进行说明。 4。1 扩展首部的顺序 当在同一个包中使用多于一个扩展首部时， 建议以如下顺序排列这些首部: IPv6 首部 Hop-by-Hop 选项首部 目的地址选项首部 (注 1) 路由首部 分片首部 认证首部 (注 2) 封装安全有效载荷首部 (注 2) 目的地址选项首部 (注 3) 上层协议首部 注 1: 由 IPv6 目的地址字段及路由首部列出的后续地址中第一个出现的目的地址处理的 选项。 注 2: 关于认证首部和封装安全有效载荷首部的相关顺序的附加建议参见 [RFC-2406]。 注 3: 只由包的最终目的地址处理的选项。 除了目的地址选项首部最多出现两次 (一次在路由首部前， 一次在上层协议首部前)以外， 每个扩展首部应当只出现一次。 如果上层协议首部是另一个 IPv6 首部 (在使用隧道技术或封装在 IPv6 中的情况下)， 它 后面可以有自己的扩展首部。 这些扩展首部以同样的建议顺序独立排列。如果定义了其他 的扩展首部， 与上面列出的扩展首部相关的次序限制必须加以说明。除了 Hop-by-Hop 选 项首部必须紧跟在 IPv6 首部后面以外， IPv6 节点必须接受并且尽量处理任意顺序的， 以 及在同一个包内出现任意多次的扩展首部。 尽管如此， 强烈建议 IPv6 包的源节点遵守上 面的建议顺序， 除非后续的协议规范修改这一顺序。 4。2 选项 当前已定义的扩展首部中的两个 -- Hop-by-Hop 选项首部和目的地址选项首部 -- 携带不定数量的， 以类型-长度-值(TLV)格式进行编码的选项， 其格式如下 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - | 选项类型 | 选项数据长度 | 选项数据 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- - - - - - - - - 选项类型 8 比特标识符， 标识选项的类型。 选项数据长度 8 比特无符号整数。 以八位组为单位的选项数据字段的长度。 选项数据 可变长度字段。 依选项类型而不同的数据。 首部中的选项必须严格按照它们在首部中出现的次序来处理; 这样， 接收方就不能搜索整 个首部来寻找某个特定类型的选项， 并且在处理所有前面的选项之前处理它。 选项类型标识符以如下规则编码: 其最高两比特指定了当 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 = 最后一个分片。 标识 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 首部与上层协议首部之间扩展首部的长度。 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: +1 408 527 8213 Fax: +1 408 527 8254 EMail: deering@cisco。com Robert M。 Hinden Nokia 232 Java Drive Sunnyvale， CA 94089 USA Phone: +1 408 990-2004 Fax: +1 408 743-5677 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 的路由首部中 境搜细?宽松位图字段和严格的路由功能。 并且删除了类型 0 的路由首部携带的地址数量的限制。 (原来由于严格/宽松位图的尺寸而 限制为 23 个地址) 01) 在第 5 章， 将最小 IPv6 MTU 从 576 改为 1280 个八位组。 并且增加了一条建议， 建议可配置 MTU 的链路 (如 PPP 链路) 将 MTU 配置成至少 1500 个八位组。 01) 在第 5 章， 删除了不允许节点在不知道目的节点的重组缓冲区尺寸的情况下发送重组 后大于 1500 个八位组的分片包的要求。 并将其改为上层协议或应用程序不应当这样做的 建议。 01) 将参考文献 "IPv4 路径 MTU 发现技术规范 (RFC-1191)" 改为参考" IPv6 路径 MTU 发现技术规范 (RFC-1981)"， 并删除了第 5 章结尾处关于路径 MTU 发现技术的注解， 现 在这些细节在 RFC-1981 中进行描述。 01) 在第 6 章， 删除了建立"机会"数据流的规范， 并删除了所有涉及建立机会数据流状 态"6 秒最大生存期"的参考。 01) 在第七章， 删除了关于传输类别字段的内部结构和语义的临时性描述， 并规定这样的 描述将在其他独立的文档中提供。 00) 在第四章， 修改了在 ICMP "参数存在问题"报文中指出"遇到无法识别的下一个首部类 型"的编码值(从 2 改为 1)。 00) 在第 3 章关于有效载荷长度字段及第 4。3 章关于巨包的有效载荷长度字段的描述中， 强调了扩展首部的长度应记入有效载荷长度里。 00) 在第 4。1 章， 交换了认证首部和 ESP 首部的次序。 (注意: 这是一个错误， 已在 01 版本中加以纠正。) 00) 在第 4。2 章中， 强调了选项应由全部 8 比特的选项类型值来标识， 而不仅是选项 类型中的低 5 位。 同时规定 Hop-by-Hop 选项首部和目的地址选项首部使用相同的选项 类型编码空间。 00) 在第 4。4 章， 增加了一项要求， 要求处理路由首部的节点在遇到无法放入下一跳链 路的大数据包时， 必须发送一个 ICMP "包太大"报文。 (而不是进行分片) 00) 将 IPv6 优先权字段更名为 "类别"， 将原来第 7 章中关于优先权的描述改为关于类别 字段的描述。 并将此字段从第 6 章中描述的同一流中的所有包所必须相同的字段列表中删 除。 00) 在第 8。1 章中的伪首部里， 将"有效载荷长度"字段更名为"上层协议包长度"字段。 并 指出， 如果上层协议本身携带自己的长度信息 (如非巨型的 UDP)，那么伪首部就使用上 层协议提供的长度， 而不是 IP 层提供的长度。 00) 增加第 8。4 章， 描述当响应一个携带路由首部的包时，不允许上层协议在响 应包中包含由未经认证的路由首部反向而得到的路由首部。 00) 修改了一些打字错误和语法错误。 00) 更新了作者的联系信息。 完整的版权声明 (原文) Copyright (C) The Internet Society (1998)。 All Rights Reserved。 This document and translations of it may be copied and furnished to others， and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared， copied， published and distributed， in whole or in part， without restriction of any kind， provided that the above copyright notice and this paragraph are included on all such copies and derivative works。 However， this document itself may not be modified in any way， such as by removing the copyright notice or references to the Internet Society or other Internet organizations， except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed， or as required to translate it into languages other than English。 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns。 This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES， EXPRESS OR IMPLIED， INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE。 RFC2460——Internet Protocol, Version 6 (IPv6) Specification Internet 协议第六版 (IPv6) 规范 1 1 RFC文档中文翻译计划