IPv6协议规范

Internet Protocol, Version 6 (IPv6) Specification

梗概

本文档规定了 Internet 协议的第 6 版(IPv6)，它废弃了 RFC 2460。

本备忘录的状态

这是一个 Internet 标准跟踪文档。

本文档是 Internet 工程任务组 (IETF) 的产品。它代表了 IETF 社区的共识。它已接受公众审查，并已被互联网工程指导组 (IESG) 批准出版。有关 Internet 标准的更多信息，请参见 RFC 7841 的第 2 节。

有关本文档的当前状态、任何勘误以及如何提供反馈的信息，请访问 http://www.rfc-editor.org/info/rfc8200。

版权声明

版权所有 (c) 2017 IETF Trust 和确定为文档作者的人员。版权所有。

本文档受 BCP 78 和 IETF 信托与 IETF 文档相关的法律规定 (http://trustee.ietf.org/license-info) 的约束，该规定在本文档发布之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含 Trust Legal Provisions 第 4.e 节中所述的简化 BSD 许可文本，并且不提供如简化 BSD 许可中所述的保证。

本文档可能包含来自于 2008 年 11 月 10 日之前发布或公开提供的 IETF 文档或 IETF 贡献的材料。控制本材料某些版权的人可能未授予 IETF 信托允许修改此类材料的权利在 IETF 标准流程之外。如果没有从控制此类材料版权的人那里获得足够的许可，则不得在 IETF 标准流程之外修改本文档，并且不得在 IETF 标准流程之外创建其衍生作品，除非将其格式化为作为 RFC 发布或将其翻译成英语以外的语言。

1、简介

IP 版本 6 (IPv6) 是互联网协议 (Internet Protocol，IP) 的新版本，设计为 IP 版本 4 (IPv4) [RFC791] 的后继版本。从 IPv4 到 IPv6 的变化主要分为以下几类：

** 扩展寻址能力

IPv6 将 IP 地址大小从 32 位增加到 128 位，以支持更多级别的寻址层次结构、更多数量的可寻址节点以及更简单的地址自动配置。通过向多播地址添加“范围”字段来提高多播路由的可扩展性。并且定义了一种称为“任播地址”的新型地址；它用于向一组节点中的任何一个发送数据包。

** 报文头格式简化

一些 IPv4 报文头字段已被删除或成为可选字段，以降低数据包处理的常见情况处理成本并限制 IPv6 报文头的带宽成本。

** 改进了对扩展和选项的支持

IP 报文头选项编码方式的变化允许更高效的转发、对选项长度的更宽松的限制，以及在未来引入新选项的更大灵活性。

** 流标签能力

添加了一项新功能，可以对发送方请求在网络中作为单个流处理的数据包序列进行标记。

** 身份验证和隐私功能

为 IPv6 指定了支持身份验证、数据完整性和（可选）数据机密性的扩展。

本文档规定了基本 IPv6 报文头和最初定义的 IPv6 扩展头和选项。它还讨论了数据包大小问题、流标签和流量类别的语义以及 IPv6 对上层协议的影响。IPv6 地址的格式和语义在 [RFC4291] 中单独指定。[RFC4443] 中规定了所有 IPv6 实现都需要包含的 ICMP 的 IPv6 版本。

IPv6 的数据传输顺序与 [RFC791] 的附录 B 中定义的 IPv4 相同。

注意：由于本文档已废弃 [RFC2460]，因此本文档中引用的任何包含指向 RFC 2460 的指针的文档都应被解释为引用本文档。

2. 术语

node：节点，实现 IPv6 的设备。

router：路由器，转发非自身为目的址的 IPv6 数据包的节点。（请参阅下面的注释。）

host：主机，任何不是路由器的节点。（请参阅下面的注释。）

upper layer：上层，在 IPv6 网络层之上的协议层。比如传输协议（例如 TCP 和 UDP）、控制协议（例如 ICMP）、路由协议（例如 OSPF）以及通过 IPv6 “隧道化”（即封装在）IPv6 中的 Internet 层或较低层协议，例如 Internetwork Packet Exchange (IPX) )、AppleTalk 或 IPv6 本身。

link：链路，节点可以在链路层（即 IPv6 正下方的层）进行通信的通信设施或介质。例如以太网（简单或桥接）；PPP 链接；X.25、帧中继或 ATM 网络；和互联网层或更高层的“隧道”，例如通过 IPv4 或 IPv6 本身的隧道。

neighbors：邻居，连接到同一链路的节点。

interface：接口，节点和链路的连接点。

address：地址，一个接口或一组接口的 IPv6 层标识符。

packet：包/报文，一个 IPv6 报文头和有效载荷。

link MTU：链路MTU，可以通过链路传送的最大传输单元，即以八位字节为单位的最大数据包大小。

path MTU：路径MTU，源节点和目的节点之间路径中所有链路的最小链路 MTU。

注意：具有多个接口的设备可以配置为转发来自其某些接口集（少于全部）的非自身目标数据包，并丢弃来自其他接口的非自身目标数据包。当从前一个（转发）接口接收来自邻居的数据包并与邻居交互时，此类设备必须遵守路由器的协议要求。当从后者（非转发）接口接收数据包并与邻居交互时，它必须遵守主机的协议要求。

3、 IPv6 头格式

Version：版本， 4 位 Internet 协议版本号 = 6。

Traffic Class：流量类别， 8 位流量类别字段。见第 7 节。

Flow Label：流标签， 20 位流标签。见第 6 节。

Payload Length：有效载荷长度， 16 位无符号整数。IPv6 有效负载的长度，即此 IPv6 报文头后面的数据包的其余部分，以八位字节为单位。（请注意，存在的任何扩展报文头（请参阅第 4 节）都被视为有效载荷的一部分，即包含在长度计数中。）

Next Header：下一个报文头， 8 位选择器。标识紧跟在 IPv6 报文头之后的报文头类型。使用与 IPv4 协议字段 [IANA-PN] 相同的值。

Hop Limit：跳数限制， 8 位无符号整数。每个转发数据包的节点减 1。转发时，如果接收时 Hop Limit 为零或递减为零，则丢弃该数据包。作为数据包目的的节点不应丢弃 Hop Limit 为零的数据包；它应该正常处理数据包。

Source Address：源地址，数据包始发者的 128 位地址。参见 [RFC4291]。

Destination Address：目标地址，数据包预期接收者的 128 位地址（如果存在路由报文头，则可能不是最终接收者）。参见 [RFC4291] 和第 4.4 节。

4、 IPv6 扩展头

在 IPv6 中，可选的互联网层信息被编码在单独的报文头中，这些报文头可以放置在数据包中的 IPv6 报文头和上层报文头之间。有少量这样的扩展报文头，每个报文头由不同的下一个报文头值标识。

扩展报文头从 IANA IP 协议编号 [IANA-PN] 编号，与 IPv4 和 IPv6 使用的值相同。当处理数据包中的 Next Header 值序列时，第一个不是扩展头 [IANA-EH] 表示数据包中的下一项是相应的上层头。如果没有上层报文头，则使用特殊的“无下一个报文头”值。

如这些示例中所示，IPv6 数据包可以携带零个、一个或多个扩展报文头，每个扩展报文头由前一个报文头的下一个报文头字段标识：

扩展报文头（Hop-by-Hop Options 报文头除外）不会被任何沿着数据包传递路径的节点处理、插入或删除，直到数据包到达该节点（或节点集的每个节点，在多播情况下）在 IPv6 报文头的目标地址字段中标识。

Hop-by-Hop Options 报文头不会被插入或删除，但可以被沿数据包传递路径的任何节点检查或处理，直到数据包到达节点（或节点组中的每个节点，在多播的情况下）在 IPv6 报文头的目标地址字段中标识。Hop-by-Hop Options 报文头（如果存在）必须紧跟在 IPv6 报文头之后。它的存在由 IPv6 报文头的下一个报文头字段中的值零指示。

注意：虽然 [RFC2460] 要求所有节点都必须检查和处理 Hop-by-Hop Options 报文头，但现在预计，如果明确配置为这样做，沿数据包传送路径的节点仅检查和处理 Hop-by-Hop Options 报文头。

在目的节点，对 IPv6 报文头的 Next Header 字段的正常解复用调用模块来处理第一个扩展报文头，如果没有扩展报文头，则调用上层报文头。每个扩展头的内容和语义决定是否继续下一个头。因此，扩展头必须严格按照它们在数据包中出现的顺序进行处理；例如，接收方不得扫描数据包以寻找特定类型的扩展报文头并在处理所有前面的报文头之前处理该报文头。

如果作为处理报文头的结果，目标节点需要继续处理下一个报文头，但节点无法识别当前报文头中的 Next Header 值，则它应该丢弃该数据包并向目标节点发送 ICMP 参数问题消息。数据包的来源，ICMP 代码值为 1（“遇到无法识别的下一个报文头类型”），ICMP 指针字段包含原始数据包中无法识别的值的偏移量。如果节点在除 IPv6 报文头之外的任何报文头中遇到 Next Header 值为零，则应采取相同的操作。

每个扩展报文头是 8 个八位字节长的整数倍，以便为后续报文头保留 8 个八位字节对齐。每个扩展报文头内的多八位字节字段在它们的自然边界上对齐，即宽度为 n 个八位字节的字段放置在从报文头开始的 n 个八位字节的整数倍处，对于 n = 1、2、4 或 8。

IPv6 的完整实现包括以下扩展头的实现：

Hop-by-Hop Options，逐跳选项

Fragment，分段

Destination Options，目的选项

Routing，路由

Authentication，验证

Encapsulating Security Payload，封装安全载荷

本文件规定了前四种；最后两个分别在 [RFC4302] 和 [RFC4303] 中指定。可以在 [IANA-EH] 找到当前的 IPv6 扩展头列表。

4.1、 扩展头顺序

当在同一个数据包中使用多个扩展头时，建议这些头按以下顺序出现：

IPv6 header，IPv6 报文头

Hop-by-Hop Options header，逐跳选项报文头

Destination Options header，目标选项报文头（注 1）

Routing header，路由头

Fragment header，片段头

Authentication header，验证报文头（注 2）

Encapsulating Security Payload header，封装安全载荷头（注 2）

Destination Options header，目的选项报文头（注 3）

Upper-Layer header，上层报文头

注 1：用于由出现在 IPv6 目标地址字段中的第一个目标以及路由报文头中列出的后续目标处理的选项。

注 2：[RFC4303] 中给出了关于认证和封装安全有效载荷头的相对顺序的附加建议。

注 3：对于仅由数据包的最终目的处理的选项。

每个扩展报文头最多应该出现一次，除了 Destination Options 报文头，它最多应该出现两次（一次在路由报文头之前，一次在上层报文头之前）。

如果上层报文头是另一个 IPv6 报文头（在 IPv6 被隧道传输或封装在 IPv6 中的情况下），它可能跟随着它自己的扩展报文头，它们分别受相同的排序建议的约束。

如果定义了其他扩展报文头，则必须指定它们相对于上面列出的报文头的排序约束。

IPv6 节点必须接受并尝试以任何顺序处理扩展报文头，并且在同一个数据包中出现任意次数，但 Hop-by-Hop Options 报文头除外，它被限制为仅出现在 IPv6 报文头之后。尽管如此，强烈建议 IPv6 数据包的来源遵循上述推荐顺序，直到并且除非后续规范修改该推荐。

4.2、 选项

本文档中指定的两个当前定义的扩展报文头——Hop-by-Hop Options 报文头和 Destination Options 报文头——携带可变数量的“选项”，这些“选项”是以下编码的类型-长度-值 (TLV)格式：

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

Opt Data Len 8 位无符号整数。此选项的选项数据字段的长度，以八位字节为单位。

选项数据可变长度字段。特定于选项类型的数据。

报文头中的选项序列必须严格按照它们在报文头中出现的顺序进行处理；例如，接收方不得扫描报文头以寻找特定类型的选项并在处理所有前面的选项之前处理该选项。

选项类型标识符在内部进行编码，以便它们的最高 2 位指定在处理 IPv6 节点不识别选项类型时必须采取的操作：

00 - 跳过此选项并继续处理报文头。

01 - 丢弃数据包。

10 - 丢弃数据包，无论数据包的目标地址是否是多播地址，都向数据包的源地址发送 ICMP 参数问题，代码 2，消息，指向无法识别的选项类型。

11 - 丢弃数据包，并且仅当数据包的目标地址不是多播地址时，才向数据包的源地址发送 ICMP 参数问题，代码 2，消息，指向无法识别的选项类型。

选项类型的第三高位指定该选项的选项数据是否可以在到达数据包最终目的的途中改变。当数据包中存在身份验证报文头时，对于其数据可能在途中更改的任何选项，在计算或验证数据包的身份验证值时，其整个选项数据字段必须被视为零值八位字节。

0 - 选项数据在途中不会改变

1 - 选项数据可能会在途中发生变化

上述三个高阶位将被视为选项类型的一部分，而不是独立于选项类型。也就是说，特定选项由完整的 8 位选项类型标识，而不仅仅是选项类型的低 5 位。

相同的选项类型编号空间用于 Hop-by-Hop Options 报文头和 Destination Options 报文头。但是，特定选项的规范可能会将其使用限制为仅这两个报文头之一。

个别选项可能有特定的对齐要求，以确保选项数据字段内的多字节值落在自然边界上。选项的对齐要求使用符号 xn+y 指定，这意味着选项类型必须出现在从头开始的 x 个八位字节加上 y 个八位字节的整数倍处。例如：

2n 表示从头开始的任何 2 个八位字节的偏移量。

8n+2 表示从头开始的任何 8 个八位字节的偏移量，加上 2 个八位字节。

有两个填充选项在必要时用于对齐后续选项并将包含的报文头填充到长度为 8 个八位字节的倍数。所有 IPv6 实现都必须识别这些填充选项：

Pad1 选项（对齐要求：无）

注意！Pad1 选项的格式是一种特殊情况——它没有长度和值字段。

Pad1 选项用于将 1 个八位字节的填充插入报文头的选项区域。如果需要多个八位字节的填充，则应使用接下来描述的 PadN 选项，而不是多个 Pad1 选项。

PadN 选项（对齐要求：无）

PadN 选项用于将两个或多个八位字节的填充插入到报文头的选项区域中。对于填充的 N 个八位字节，Opt Data Len 字段包含值 N-2，而 Option Data 由 N-2 个零值八位字节组成。

附录 A 包含设计新选项的格式指南。

4.3、 逐跳选项报文头

Hop-by-Hop Options 报文头用于携带可选信息，这些信息可以由沿数据包传递路径的每个节点进行检查和处理。Hop-by-Hop Options 报文头由 IPv6 报文头中的 Next Header 值 0 标识，并具有以下格式：

下一个报文头：8 位选择器。标识紧跟在 Hop-by-Hop Options 报文头之后的报文头类型。使用与 IPv4 协议字段 [IANA-PN] 相同的值。

HDR Ext Len：8 位无符号整数。Hop-by-Hop Options 报文头的长度，以 8 个八位字节为单位，不包括前 8 个八位字节。

选项：可变长度字段，其长度使得完整的逐跳选项报文头是 8 个八位字节长的整数倍。包含一个或多个 TLV 编码选项，如第 4.2 节所述。

本文档中定义的唯一逐跳选项是第 4.2 节中指定的 Pad1 和 PadN 选项。

4.4、 路由头

路由报文头被 IPv6 源用来列出一个或多个在到达数据包目的的途中要“访问”的中间节点。此功能与 IPv4 的松散源和记录路由选项非常相似。Routing 报文头由紧接在前一个报文头中的 Next Header 值 43 标识，并具有以下格式：

下一个报文头：8 位选择器。标识紧跟在 Routing 报文头之后的报文头类型。使用与 IPv4 协议字段 [IANA-PN] 相同的值。

HDR Ext Len：8 位无符号整数。路由报文头的长度，以 8 个八位字节为单位，不包括前 8 个八位字节。

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

Segments Left：8 位无符号整数。剩余路由分段的数量，即在到达最终目的之前仍要访问的明确列出的中间节点的数量。

type-specific data：可变长度字段，格式由路由类型确定，长度使得完整的路由报文头是 8 个八位字节长的整数倍。

如果在处理接收到的数据包时，节点遇到具有无法识别的路由类型值的路由报文头，则节点所需的行为取决于 Segments Left 字段的值，如下所示：

如果 Segments Left 为零，则节点必须忽略路由头并继续处理数据包中的下一个头，其类型由路由头中的下一个头字段标识。

如果 Segments Left 不为零，则节点必须丢弃数据包并向数据包的源地址发送 ICMP 参数问题代码 0 消息，指向无法识别的路由类型。

如果中间节点在处理接收到的数据包的路由头后，确定将数据包转发到链路 MTU 小于数据包大小的链路上，则该节点必须丢弃该数据包并发送 ICMP 数据包大消息到数据包的源地址。

当前定义的 IPv6 路由头及其状态可以在 [IANA-RH] 中找到。IPv6 路由头的分配指南可以在 [RFC5871] 中找到。

4.5、 片段头

IPv6 源使用 Fragment 报文头发送大于到达其目的的路径 MTU 的数据包。（注意：与 IPv4 不同，IPv6 中的分段仅由源节点执行，而不是由沿数据包传送路径的路由器执行——参见第 5 节。）片段头由紧接在前一个头中的 Next Header 值 44 标识，并且具有以下格式：

下一个报文头：8 位选择器。标识原始数据包的 Fragmentable Part 的初始头类型（定义如下）。使用与 IPv4 协议字段 [IANA-PN] 相同的值。

Reserved：8 位保留字段。传输初始化为零；接收时被忽略。

片段偏移量：13 位无符号整数。此报文头后面的数据相对于原始数据包的可分段部分的开头的偏移量（以 8 个八位字节为单位）。

Res：2 位保留字段。传输初始化为零；接待时被忽略。

M： 1 = 更多片段；0 = 最后一个片段。

Identification:32 位。请参阅下面的说明。

为了发送一个太大而无法容纳到其目的的路径的 MTU 的数据包，源节点可以将数据包分成多个片段并将每个片段作为单独的数据包发送，以便在接收器处重新组装。

对于每个要分段的数据包，源节点都会生成一个标识值。标识必须不同于最近发送的任何其他具有相同源地址和目标地址的分段数据包*。如果存在路由报文头，则关注的目标地址是最终目标的地址。

*“最近”是指在数据包的最大可能生命周期内，包括从源到目的的传输时间以及等待与同一数据包的其他片段重新组装所花费的时间。然而，不要求源节点知道最大数据包寿命。相反，假设可以通过实施导致低标识重用频率的算法来满足要求。[RFC7739] 中描述了可以满足此要求的算法示例。

初始的、大的、未分段的数据包被称为“原始数据包”，它被认为由三部分组成，如图所示：

原始数据包：

Per-Fragment 报文头必须包含 IPv6 报文头加上必须由到达目的的节点处理的任何扩展报文头，即所有报文头直到并包括路由报文头（如果存在），否则为 Hop-by-Hop Options报文头（如果存在），否则没有扩展报文头。

扩展报文头是未包含在数据包的 Per-Fragment 报文报文头分中的所有其他扩展报文头。为此，封装安全有效载荷 (ESP) 不被视为扩展报文头。Upper-Layer 头是第一个不是 IPv6 扩展头的上层头。上层报文头的示例包括 TCP、UDP、IPv4、IPv6、ICMPv6 和 ESP。

Fragmentable Part 由上层报文头之后或任何包含 Next Header 值为 No Next Header 的报文头（即初始 IPv6 报文头或扩展报文头）之后的数据包的其余部分组成。

原始数据包的 Fragmentable 部分被分成多个片段。必须选择片段的长度，使得生成的片段数据包适合到数据包目的的路径的 MTU。每个完整的片段，可能除了最后一个（“最右边的”）片段，都是 8 个八位字节长的整数倍。

片段在单独的“片段数据包”中传输，如图所示：

原始数据包：

分段数据包：

第一个分段包由以下部分组成：

(1) 原始报文的 Per-Fragment 头，原始 IPv6 报文头的 Payload Length 更改为仅包含该分段报文的长度（不包括 IPv6 报文头本身的长度），以及该报文的 Next Header 字段Per-Fragment 报文头的最后一个报文头更改为 44。

(2) 一个片段头，包含：

Next Header 值，用于标识原始数据包的 Per-Fragment 报文头之后的第一个报文头。

包含片段偏移量的片段偏移量，以 8 个八位字节为单位，相对于原始数据包的可分段部分的开头。第一个（“最左边”）片段的片段偏移量为 0。

M 标志值为 1，因为这是第一个片段。

标识值由原始数据包生成。

(3) 扩展报文头，如果有的话，和上层报文头。这些报文头必须在第一个片段中。注意：这将通过上层报文头的报文头大小限制为到数据包目的的路径的 MTU。

(4) 第一个片段。

随后的分段数据包由以下部分组成：

(1) 原始报文的 Per-Fragment 头，原始 IPv6 报文头的 Payload Length 更改为仅包含该分段报文的长度（不包括 IPv6 报文头本身的长度），以及该报文的 Next Header 字段Per-Fragment 报文头的最后一个报文头更改为 44。

(2) 一个片段头，包含：

Next Header 值，用于标识原始数据包的 Per-Fragment 报文头之后的第一个报文头。

包含片段偏移量的片段偏移量，以 8 个八位字节为单位，相对于原始数据包的可分段部分的开头。

如果片段是最后一个（“最右边”），则 M 标志值为 0，否则 M 标志值为 1。

标识值由原始数据包生成。

(3) 片段本身。

不得创建与从原始数据包创建的任何其他片段重叠的片段。

在目的，分段数据包被重新组合成其原始的、未分段的形式，如图所示：

重新组装的原始数据包：

以下规则管理重组：

原始数据包仅由具有相同源地址、目标地址和片段标识的片段数据包重组而成。

重组后的数据包的 Per-Fragment 报文头由所有报文头组成，但不包括第一个片段数据包（即 Fragment Offset 为零的数据包）的 Fragment 报文头，有以下两个变化：

Per-Fragment 头的最后一个头的 Next Header 字段是从第一个片段的 Fragment 头的 Next Header 字段中获取的。

重组数据包的有效载荷长度是根据 Per-Fragment 头的长度和最后一个片段的长度和偏移量计算的。例如，计算重组原始数据包的有效载荷长度的公式为：

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

公式中：

PL.orig = 重组数据包的有效载荷长度字段。

PL.first = 第一个片段数据包的有效载荷长度字段。

FL.first = 第一个片段数据包的片段头之后的片段长度。

FO.last = 最后一个分段包的分段头的分段偏移字段。

FL.last = 最后一个片段包的片段头之后的片段长度。

重组包的可分段部分由每个分段包中的分段头后面的分段构成。每个片段的长度是通过从数据包的 Payload Length 中减去 IPv6 报文头和片段本身之间的报文头长度来计算的；它在 Fragmentable Part 中的相对位置是根据它的 Fragment Offset 值计算的。

Fragment 报文头不存在于最终重组的数据包中。

如果分段是一个完整的数据报（即，Fragment Offset 字段和 M 标志都为零），那么它不需要任何进一步的重组，应该作为一个完全重组的数据包来处理（即更新 Next Header，调整 Payload长度、删除 Fragment 报文头等）。与此数据包匹配的任何其他片段（即，相同的 IPv6 源地址、IPv6 目标地址和片段标识）应独立处理。

重组分段数据包时可能会出现以下错误情况：

** 如果在接收到该数据包的第一个到达片段后 60 秒内收到的片段不足以完成数据包的重组，则必须放弃该数据包的重组，并且必须丢弃该数据包已接收的所有片段.如果接收到第一个片段（即片段偏移为零的片段），则应向该片段的源发送 ICMP Time Exceeded -- Fragment Reassembly Time Exceeded 消息。

** 如果从片段数据包的 Payload Length 字段导出的片段长度不是 8 个八位字节的倍数，并且该片段的 M 标志为 1，则必须丢弃该片段，并且 ICMP 参数问题，代码 0 , 消息应该发送到分段的源，指向分段数据包的 Payload Length 字段。

** 如果片段的长度和偏移量使得从该片段重组的数据包的有效载荷长度将超过 65,535 个八位字节，则必须丢弃该片段，并且应将 ICMP 参数问题，代码 0，消息发送到源分段的，指向分段包的Fragment Offset字段。

** 如果第一个片段不包括通过上层报文头的所有报文头，则应丢弃该片段，并将 ICMP 参数问题，代码 3，消息发送到片段的源，并将指针字段设置为零。

** 如果正在重组的任何片段与为同一数据包重组的任何其他片段重叠，则必须放弃该数据包的重组，并且必须丢弃该数据包已收到的所有片段，并且不应有 ICMP 错误消息发送。

需要注意的是，片段在网络中可能会被复制。代替将这些完全重复的片段视为重叠片段，实现可以选择检测这种情况并丢弃完全重复的片段，同时保留属于同一数据包的其他片段。

以下情况预计不会频繁发生，但如果发生，则不会被视为错误：

同一个原始数据包的不同分段的Fragment 头之前的头的数量和内容可能不同。在每个片段包中的片段包头之前，无论出现什么包头，都会在包到达时进行处理，然后再将片段排队以进行重组。只有 Offset zero fragment 数据包中的那些头被保留在重新组装的数据包中。

同一原始报文的不同分段的分段头中的下一个头值可能不同。只有来自 Offset zero fragment 数据包的值用于重组。

IPv6 报文头中的其他字段也可能因重新组装的片段而异。如果使用来自偏移零片段的值的基本机制不够充分，则使用这些字段的规范可能会提供附加说明。例如，[RFC3168] 的第 5.3 节描述了如何组合来自不同片段的显式拥塞通知 (Explicit Congestion Notification，ECN) 位以导出重组数据包的 ECN 位。

4.6、 目的选项报文头

Destination Options 报文头用于携带仅需要由数据包的目标节点检查的可选信息。Destination Options 报文头由紧接在前一个报文头中的 Next Header 值 60 标识，并具有以下格式：

下一个报文头：8 位选择器。标识紧跟在 Destination Options 报文头之后的报文头类型。使用与 IPv4 协议字段 [IANA-PN] 相同的值。

HDR Ext Len：8 位无符号整数。Destination Options 报文头的长度，以 8 个八位字节为单位，不包括前 8 个八位字节。

选项：可变长度字段，其长度使得完整的目标选项报文头是 8 个八位字节长的整数倍。包含一个或多个 TLV 编码选项，如第 4.2 节所述。

本文档中定义的唯一目标选项是第 4.2 节中指定的 Pad1 和 PadN 选项。

请注意，有两种可能的方式在 IPv6 数据包中对可选目标信息进行编码：作为目标选项报文头中的选项或作为单独的扩展报文头。Fragment 报文头和 Authentication 报文头是后一种方法的示例。可以使用哪种方法取决于不理解可选信息的目标节点需要什么操作：

** 如果目标节点想要丢弃数据包，并且仅当数据包的目标地址不是多播地址时，才向数据包的源地址发送 ICMP Unrecognized Type 消息，则该信息可以编码为单独的报文头或作为 Destination Options 报文头中的一个选项，其 Option Type 的最高 2 位值为 11。选择可能取决于以下因素：哪个占用更少的八位字节，或者哪个产生更好的对齐或更有效的解析。

** 如果需要任何其他操作，则必须将信息编码为 Destination Options 报文头中的选项，其选项类型的最高 2 位值为 00、01 或 10，指定所需的操作（参见第 4.2 节） ）。

4.7、 没有下一个报文头

IPv6 报文头或任何扩展报文头的 Next Header 字段中的值 59 表示该报文头后面没有任何内容。如果 IPv6 报文头的 Payload Length 字段指示在其 Next Header 字段包含 59 的报文头末尾之后存在八位字节，则如果转发数据包，则必须忽略这些八位字节并保持不变地传递。

4.8、 定义新的扩展头和选项

不建议定义新的 IPv6 扩展报文头，除非没有现有的 IPv6 扩展报文头可通过为该 IPv6 扩展报文头指定新选项来使用。指定新 IPv6 扩展头的提案必须包括详细的技术解释，说明为什么现有 IPv6 扩展头不能用于所需的新功能。有关其他背景信息，请参阅 [RFC6564]。

注意：不能定义需要逐跳行为的新扩展报文头，因为如本文档第 4 节中所指定，具有逐跳行为的唯一扩展报文头是逐跳选项报文头。

不推荐使用新的逐跳选项，因为节点可能被配置为忽略逐跳选项报文头，丢弃包含逐跳选项报文头的数据包，或分配包含逐跳选项报文头的数据包到缓慢的处理路径。考虑定义新的逐跳选项的设计人员需要了解这种可能的行为。为什么在标准化之前需要任何新的逐跳选项，必须有一个非常明确的理由。

建议使用 Destination Options 头代替定义新的扩展头来携带只能由数据包的目的节点检查的可选信息，因为它们提供更好的处理和向后兼容性。

如果定义了新的扩展头，它们需要使用以下格式：

下一个报文头：8 位选择器。标识紧跟在扩展报文头之后的报文头类型。使用与 IPv4 协议字段 [IANA-PN] 相同的值。

HDR Ext Len：8 位无符号整数。Destination Options 报文头的长度，以 8 个八位字节为单位，不包括前 8 个八位字节。

报文头特定数据：可变长度字段。特定于扩展报文头的字段。

5、 数据包大小问题

IPv6 要求 Internet 中的每个链接的 MTU 为 1280 八位字节或更大。这称为 IPv6 最小链路 MTU。在任何不能一次性传送 1280 个八位字节数据包的链路上，必须在 IPv6 之下的一层提供特定于链路的分段和重组。

具有可配置 MTU 的链路（例如，PPP 链路 [RFC1661]）必须配置为具有至少 1280 个八位字节的 MTU；建议将它们配置为 1500 个八位字节或更大的 MTU，以适应可能的封装（即隧道）而不会导致 IPv6 层分段。

从节点直接连接到的每条链路，该节点必须能够接受与该链路的 MTU 一样大的数据包。

强烈建议 IPv6 节点实现路径 MTU 发现 [RFC8201]，以便发现和利用大于 1280 八位字节的路径 MTU。然而，最小的 IPv6 实现（例如，在引导 ROM 中）可能会简单地将自身限制为发送不超过 1280 个八位字节的数据包，并省略路径 MTU 发现的实现。

为了发送大于路径 MTU 的数据包，节点可以使用 IPv6 Fragment 报文头在源处对数据包进行分段，并在目的重新组装。但是，在任何能够调整其数据包以适应测量的路径 MTU（即低至 1280 个八位字节）的应用程序中，不鼓励使用此类分段。

一个节点必须能够接受一个分段的数据包，在重组后，该数据包大到 1500 个八位字节。一个节点被允许接受重组为超过 1500 个八位字节的分段数据包。依赖 IPv6 分段发送大于路径 MTU 的数据包的上层协议或应用程序不应发送大于 1500 个八位字节的数据包，除非它保证目的能够重新组装更大尺寸的数据包。

6、 流标签

源使用 IPv6 报文头中的 20 位流标签字段来标记要在网络中作为单个流处理的数据包序列。

IPv6 流标签的当前定义可以在 [RFC6437] 中找到。

7、 流量类别

IPv6 报文头中的 8 位流量类别字段被网络用于流量管理。接收到的数据包或片段中的流量类别位的值可能与数据包源发送的值不同。

[RFC2474] 和 [RFC3168] 中规定了当前使用的流量类别字段用于区分服务和显式拥塞通知。

8、 上层协议问题

8.1、 上层校验和

任何在其校验和计算中包含来自 IP 报文头的地址的传输或其他上层协议都必须修改以在 IPv6 上使用，以包含 128 位 IPv6 地址而不是 32 位 IPv4 地址。特别是，下图显示了 IPv6 的 TCP 和 UDP“伪报文头”：

** 如果 IPv6 数据包包含路由报文头，则伪报文头中使用的目标地址是最终目的的目标地址。在始发节点，该地址将位于路由报文头的最后一个元素中；在接收方，该地址将位于 IPv6 报文头的目标地址字段中。

** 伪报文头中的下一个报文头值标识

上层协议（例如，TCP 为 6，UDP 为 17）。如果 IPv6 头和上层头之间存在扩展头，它将与 IPv6 头中的 Next Header 值不同。

** 伪头中的 Upper-Layer Packet Length 是上层头和数据（例如 TCP 头加 TCP 数据）的长度。一些上层协议携带自己的长度信息（例如UDP头中的长度字段）；对于此类协议，这是伪报文头中使用的长度。其他协议（如 TCP）不携带自己的长度信息，在这种情况下，伪头中使用的长度是来自 IPv6 头的有效载荷长度减去 IPv6 头和上层之间存在的任何扩展头的长度-层报文头。

** 与 IPv4 不同，当 UDP 数据包由 IPv6 节点发起时，默认行为是 UDP 校验和不是可选的。也就是说，无论何时发起 UDP 数据包，IPv6 节点都必须对数据包和伪报文头计算 UDP 校验和，如果计算结果为零，则必须将其更改为十六进制 FFFF 以放置在 UDP 报文头中. IPv6 接收器必须丢弃包含零校验和的 UDP 数据包，并应记录错误。

** 作为默认行为的一个例外，使用 UDP 作为隧道封装的协议可能会为发送和/或接收的特定端口（或端口集）启用零校验和模式。任何实现零校验和模式的节点都必须遵循“使用具有零校验和的 IPv6 UDP 数据报的适用性声明”[RFC6936] 中指定的要求。

ICMP [RFC4443] 的 IPv6 版本在其校验和计算中包含上述伪头；这是对 ICMP 的 IPv4 版本的更改，它的校验和中不包含伪报文头。更改的原因是为了保护 ICMP 免受其所依赖的 IPv6 报文头的那些字段的错误传递或损坏，与 IPv4 不同，这些字段未包含在 Internet 层校验和中。ICMP 伪头中的 Next Header 字段包含值 58，它标识 ICMP 的 IPv6 版本。

8.2、 最大数据包生命周期

与 IPv4 不同，IPv6 节点不需要强制执行最大数据包生命周期。这就是 IPv4 的“生存时间”字段在 IPv6 中更名为“跳数限制”的原因。实际上，很少有（如果有的话）IPv4 实现符合限制数据包生命周期的要求，因此这在实践中并没有改变。任何依赖互联网层（无论是 IPv4 还是 IPv6）来限制数据包生命周期的上层协议都应该升级以提供自己的机制来检测和丢弃过时的数据包。

8.3、 最大上层有效载荷大小

在计算可用于上层数据的最大有效载荷大小时，上层协议必须考虑 IPv6 报文头相对于 IPv4 报文头的更大尺寸。例如，在 IPv4 中，TCP 的最大分段大小 (MSS) 选项计算为最大数据包大小（默认值或通过路径 MTU 发现学习的值）减去 40 个八位字节（20 个八位字节用于最小长度的 IPv4 报文头和 20 个八位字节）对于最小长度的 TCP 报文头）。在 IPv6 上使用 TCP 时，MSS 必须计算为最大数据包大小减去 60 个八位字节，因为最小长度的 IPv6 报文头（即没有扩展报文头的 IPv6 报文头）比最小长度的 IPv4 报文头长 20 个八位字节。

8.4、 响应携带路由头的数据包

当上层协议发送一个或多个数据包以响应包含路由报文头的接收数据包时，响应数据包不得包含通过“反转”接收到的路由报文头而自动导出的路由报文头，除非完整性已验证接收的源地址和路由报文头的真实性（例如，通过在接收的数据包中使用身份验证报文头）。换句话说，仅允许以下类型的数据包响应接收到的带有路由头的数据包：

** 不携带路由头的响应数据包。

** 带有路由报文头的响应数据包，不是通过反转接收到的数据包的路由报文头（例如，由本地配置提供的路由报文头）导出的。

** 带有路由头的响应包是通过反转接收到的包的路由头导出的，当且仅当来自接收包的源地址和路由头的完整性和真实性已经被响应者验证。

9、 IANA 考虑

许多 IANA 注册机构都引用了 RFC 2460。这些包括：

** Internet 协议版本 6 (IPv6) 参数 [IANA-6P]

** 分配的互联网协议编号 [IANA-PN]

** ONC RPC 网络标识符 (netids) [IANA-NI]

** 网络层协议标识符 (NLPID) [IANA-NL]

** 协议注册机构 [IANA-PR]

IANA 已更新这些引用以指向本文档。

10、 安全考虑

从数据包的基本格式和传输的角度来看，IPv6 具有类似于 IPv4 的安全特性。这些安全问题包括：

** 窃听，其中路径上的元素可以观察每个 IPv6 数据报的整个数据包（包括内容和元数据）。

** 重放，攻击者从线路上记录一系列数据包，并将它们回放给最初接收它们的一方。

** 数据包插入，攻击者伪造具有某些选定属性集的数据包并将其注入网络。

** 数据包删除，攻击者从网络中删除数据包。

** 数据包修改，攻击者从线路中移除数据包，对其进行修改，然后将其重新注入网络。

** 中间人 (Man-in-the-middle，MITM) 攻击，攻击者破坏通信流，以伪装成发送者到接收者和接收者到发送者。

** 拒绝服务 (Denial-of-service，DoS) 攻击，攻击者向目标发送大量合法流量以压制它。

通过使用“Internet 协议安全架构”[RFC4301]，可以保护 IPv6 数据包免受窃听、重放、数据包插入、数据包修改和 MITM 攻击。此外，还可以使用传输层安全 (TLS) 或安全外壳 (SSH) 等上层协议来保护运行在 IPv6 之上的应用层流量。

没有任何机制可以防止 DoS 攻击。防御这些类型的攻击超出了本规范的范围。

IPv6 地址明显大于 IPv4 地址，这使得在 Internet 上甚至在单个网络链接（例如局域网）上扫描地址空间变得更加困难。有关更多信息，请参阅 [RFC7707]。

由于减少了地址转换技术的使用，因此与 IPv4 相比，节点的 IPv6 地址有望在 Internet 上更加明显。这会产生一些额外的隐私问题，例如更容易区分端点。有关更多信息，请参阅 [RFC7721]。

IPv6 扩展头架构的设计，在增加了很多灵活性的同时，也带来了新的安全挑战。如下所述，与 Fragment 扩展报文头相关的问题已得到解决，但很明显，对于未来设计的任何新扩展报文头，都需要彻底检查安全隐患，这需要包括新扩展报文头如何与现有的扩展头。有关更多信息，请参阅 [RFC7045]。

此版本的 IPv6 规范解决了在 IPv6 规范的先前版本 [RFC2460] 中发现的许多安全问题。这些包括：

** 修改了文本以处理整个数据报的片段的情况（即片段偏移字段和 M 标志都为零）。如果收到，则应将它们作为重新组装的数据包进行处理。任何其他匹配的片段都应该独立处理。片段创建过程被修改为不创建整个数据报片段（片段偏移字段和 M 标志为零）。有关更多信息，请参阅 [RFC6946] 和 [RFC8021]。

** 删除了第 5 节中要求在报告下一跳 MTU 的 ICMP 数据包太大消息小于 1280 时在传出数据包中包含 Fragment 报文头的段落。有关更多信息，请参阅 [RFC6946]。

** 更改文本以要求 IPv6 节点不得创建重叠片段。此外，在重组 IPv6 数据报时，如果确定其组成片段中的一个或多个是重叠片段，则必须静默丢弃整个数据报（以及任何组成片段）。包括在收到重叠片段时不应发送 ICMP 错误消息的说明。有关更多信息，请参阅 [RFC5722]。

** 修改了正文，要求通过第一个上层报文头的所有报文头都在第一个片段中。有关更多信息，请参阅 [RFC7112]。

** 合并了 [RFC5095] 和 [RFC5871] 的更新，删除了路由头类型 0 (RH0) 的描述，路由头的分配指南在 RFC 5871 中指定，并从所需的扩展头列表中删除了 RH0 。

与 IPv6 其他部分相关的安全问题，包括寻址、ICMPv6、路径 MTU 发现等，在适当的规范中进行了讨论。

11、 参考文献

11.1、 规范参考

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981,.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998,.

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001,.

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006,.

[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006,.

[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011,.

11.2、 参考资料

[Err2541] RFC Errata, Erratum ID 2541, RFC 2460.

[Err4279] RFC Errata, Erratum ID 4279, RFC 2460.

[Err4657] RFC Errata, Erratum ID 4657, RFC 2460.

[Err4662] RFC Errata, Erratum ID 4662, RFC 2460.

[IANA-6P] IANA, "Internet Protocol Version 6 (IPv6) Parameters",.

[IANA-EH] IANA, "IPv6 Extension Header Types",.

[IANA-NI] IANA, "ONC RPC Network Identifiers (netids)",.

[IANA-NL] IANA, "Network Layer Protocol Identifiers (NLPIDs) of Interest",.

[IANA-PN] IANA, "Protocol Numbers",.

[IANA-PR] IANA, "Protocol Registries",.

[IANA-RH] IANA, "Routing Types",.

[RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994,.

[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998,.

[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005,.

[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005,.

[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005,.

[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation of Type 0 Routing Headers in IPv6", RFC 5095, DOI 10.17487/RFC5095, December 2007,.

[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, DOI 10.17487/RFC5722, December 2009,.

[RFC5871] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for the IPv6 Routing Header", RFC 5871, DOI 10.17487/RFC5871, May 2010,.

[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, DOI 10.17487/RFC6564, April 2012,.

[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, DOI 10.17487/RFC6936, April 2013,.

[RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 6946, DOI 10.17487/RFC6946, May 2013,.

[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing of IPv6 Extension Headers", RFC 7045, DOI 10.17487/RFC7045, December 2013,.

[RFC7112] Gont, F., Manral, V., and R. Bonica, "Implications of Oversized IPv6 Header Chains", RFC 7112, DOI 10.17487/RFC7112, January 2014,.

[RFC7707] Gont, F. and T. Chown, "Network Reconnaissance in IPv6 Networks", RFC 7707, DOI 10.17487/RFC7707, March 2016,.

[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016,.

[RFC7739] Gont, F., "Security Implications of Predictable Fragment Identification Values", RFC 7739, DOI 10.17487/RFC7739, February 2016,.

[RFC8021] Gont, F., Liu, W., and T. Anderson, "Generation of IPv6 Atomic Fragments Considered Harmful", RFC 8021, DOI 10.17487/RFC8021, January 2017,.

[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, "Path MTU Discovery for IP version 6", STD 87, RFC 8201, DOI 10.17487/RFC8201, July 2017,.

附录 A、 选项格式指南

本附录就如何在设计要在 Hop-by-Hop Options 报文头或 Destination Options 报文头中使用的新选项时如何布置字段提供一些建议，如第 4.2 节所述。这些准则基于以下假设：

** 一个理想的特性是选项的选项数据区域内的任何多八位字节字段都在它们的自然边界上对齐，即宽度为 n 个八位字节的字段应放置在从跃点开始的 n 个八位字节的整数倍处-by-Hop 或 Destination Options 报文头，对于 n = 1、2、4 或 8。

** 另一个可取的特性是 Hop-by-Hop 或 Destination Options 报文头占用尽可能少的空间，前提是报文头是 8 个八位字节长的整数倍。

** 可以假设，当任一带有选项的报文头存在时，它们携带的选项数量非常少，通常只有一个。

这些假设建议使用以下方法来布置选项的字段：将字段从最小到最大排序，没有内部填充，然后根据最大字段的对齐要求（最多8 个八位字节的最大对齐）。以下示例说明了此方法：

示例 1

如果选项 X 需要两个数据字段，其中一个长度为 8 个八位字节，一个长度为 4 个八位字节，则其布局如下：

它的对齐要求是 8n+2，以确保 8 个八位字节字段从封闭报文头开始处的 8 倍偏移处开始。包含此选项的完整 Hop-by-Hop 或 Destination Options 报文头如下所示：

示例 2

如果选项 Y 需要三个数据字段，其中一个长度为 4 个八位字节，一个长度为 2 个八位字节，一个长度为 1 个八位字节，则其布局如下：

它的对齐要求是 4n+3，以确保 4 个八位字节字段从封闭报文头的开始位置以 4 的倍数偏移开始。包含此选项的完整 Hop-by-Hop 或 Destination Options 报文头如下所示：

示例 3

包含示例 1 和示例 2 中的选项 X 和 Y 的逐跳或目标选项报文头将具有以下两种格式之一，具体取决于哪个选项首先出现：

附录 B、 和 RFC 2460 相比的更改

本备忘录对 RFC 2460 有以下更改。

** 从摘要中删除了下一代 IP。

** 在第 1 节中添加了数据传输顺序与 RFC 791 中定义的 IPv4 相同的文本。

** 澄清了第 3 节中关于递减跳跃限制的文本。

** 阐明扩展报文头（Hop-by-Hop Options 报文头除外）不会被沿数据包传送路径的任何节点处理、插入或删除。

** 将 Hop-by-Hop Options 报文头的要求更改为“可以”，并添加了一条注释以指示关于 Hop-by-Hop Options 报文头的预期内容。

** 在第 4 节中添加了一段以阐明扩展报文头如何编号以及哪些是上层报文头。

** 在第 4 节末尾添加了对“IPv6 扩展报文头类型”IANA 注册表的引用。

** 合并了来自 RFC 5095 和 5871 的更新，以删除 RH0 的描述，路由报文头的分配指南在 RFC 5871 中指定，并从所需的扩展报文头列表中删除了 RH0。

** 根据 RFC 5722、6946、7112 和 8021 的更新修订了关于 IPv6 分段的第 4.5 节。这包括：

- 修改了文本以处理整个数据报的片段的情况（即片段偏移字段和 M 标志都为零）。如果收到，则应将它们作为重新组装的数据包进行处理。任何其他匹配的片段都应该独立处理。修改后的片段创建过程被修改为不创建整个数据报片段（片段偏移字段和 M 标志为零）。

- 更改文本以要求 IPv6 节点不得创建重叠片段。此外，在重组 IPv6 数据报时，如果确定其组成片段的一个或多个是重叠片段，则必须静默丢弃整个数据报（以及任何组成片段）。包括在收到重叠片段时不应发送 ICMP 错误消息的说明。

- 修改了文本，要求通过第一个 Upper-Layer 报文头的所有报文头都在第一个片段中。这更改了描述数据包如何分段和重组的文本，并添加了一个新的错误案例。

- 在处理完全重复的片段的片段报文头过程中添加了文本。

- 更新了 Fragmentation 报文头文本以更正身份验证报文头 (AH) 的包含并注明无下一个报文头情况。

- 将 Fragment 报文报文头分中的术语从“Unfragmentable Headers”更改为“Per-Fragment headers”。

- 删除了第 5 节中的段落，如果 ICMP 数据包太大消息报告下一跳 MTU 小于 1280，则要求在传出数据包中包含片段报文头。

- 更改文本以阐明 MTU 限制和 8 字节限制，并在第一个片段中注明对报文头的限制。

** 在第 4.5 节中，添加了说明，指出 IPv6 报文头中的某些字段也可能因重新组装的片段而异，并且其他规范可能会提供有关如何重新组装它们的附加说明。例如，参见 [RFC3168] 的第 5.3 节。

** 合并了来自 RFC 6564 的更新以添加新的第 4.8 节，该节描述了定义新扩展报文头和选项的建议。

** 向第 5 节添加文本以定义“IPv6 最小链路 MTU”。

** 简化了第 6 节中关于流标签的文本并删除了附录 A（“流标签字段的语义和用法”）；相反，指向 [RFC6437] 中的 IPv6 流标签字段和 [RFC2474] 和 [RFC3168] 中的流量类别字段的当前规范。

** 在第 8 节中合并了 RFC 6935（“隧道数据包的 IPv6 和 UDP 校验和”）所做的更新。为处理具有隧道零校验和的 UDP 数据包的默认行为添加了一个例外。

** 在第 9 节“IANA 注意事项”中添加了说明，以将 RFC 2460 的引用更改为本文档。

** 修订并扩展了第 10 节“安全注意事项”。

** 在致谢部分添加了一个段落，感谢更新文档的作者。

** 更新了对当前版本的引用，并分配了对规范性和信息性的引用。

** 进行了更改以解决 RFC 2460 上的勘误表。这些是：

勘误 ID 2541 [Err2541]：此勘误指出，当流标签的长度从 RFC 1883 中的 24 位更改为 20 位时，RFC 2460 未更新 RFC 2205。此问题已在定义流标签的 RFC 6437 中解决.此规范现在引用 RFC 6437。无需更改。

勘误 ID 4279 [Err4279]：此勘误指出规范不处理转发节点接收具有零跳数限制的数据包的情况。这在本规范的第 3 节中得到了修复。

勘误 ID 4657 [Err4657]：此勘误建议文本，扩展报文头绝不能由除数据包源之外的任何节点插入。这已在第 4 节“IPv6 扩展报文头”中解决。

勘误表 ID 4662 [Err4662]：该勘误表建议的文本是，除了一个例外，扩展报文头不会被沿数据包传递路径的任何节点检查、处理、修改、插入或删除。这已在第 4 节“IPv6 扩展报文头”中解决。

勘误 ID 2843：此勘误标记为“已拒绝”。没有进行任何更改。

以上就是IPv6协议规范的介绍，Vecloud为客户提供丰富的IPV6网络专线解决方案，主要地区包含日本、韩国、伦敦、法兰克福、洛杉矶、圣何塞、华盛顿、印度、迪拜、南非等均可随时提供网络专线和IP传输服务。