4. IPv6 Extension Headers (IPv6 扩展报头)
在 IPv6 中, 可选的互联网层信息被编码在单独的报头中, 这些报头可以放置在 IPv6 报头和上层报头之间.存在少量这样的扩展报头, 每个扩展报头由不同的 Next Header 值标识.如以下示例所示, IPv6 分组可以携带零个、一个或多个扩展报头, 每个扩展报头由前一报头的 Next Header 字段标识:
+---------------+------------------------
| IPv6 header | TCP header + data
| |
| Next Header = |
| TCP |
+---------------+------------------------
+---------------+----------------+------------------------
| IPv6 header | Routing header | TCP header + data
| | |
| Next Header = | Next Header = |
| Routing | TCP |
+---------------+----------------+------------------------
+---------------+----------------+-----------------+-----------------
| IPv6 header | Routing header | Fragment header | fragment of TCP
| | | | header + data
| Next Header = | Next Header = | Next Header = |
| Routing | Fragment | TCP |
+---------------+----------------+-----------------+-----------------
除一个例外, 扩展报头不会被分组传递路径上的任何节点检查或处理, 直到分组到达 IPv6 报头的 Destination Address 字段中标识的节点 (或者在组播情况下, 节点集合中的每个节点).在那里, 对 IPv6 报头的 Next Header 字段进行正常解复用会调用模块来处理第一个扩展报头, 或者如果不存在扩展报头则处理上层报头.每个扩展报头的内容和语义决定是否继续处理下一个报头.因此, 扩展报头必须严格按照它们在分组中出现的顺序进行处理; 例如, 接收方不得扫描分组以查找特定类型的扩展报头并在处理所有前面的报头之前处理该报头.
上一段中提到的例外是 Hop-by-Hop Options header (逐跳选项报头), 它携带的信息必须由分组传递路径上的每个节点 (包括源节点和目的节点) 检查和处理.当存在 Hop-by-Hop Options header 时, 它必须紧跟 IPv6 报头.其存在由 IPv6 报头的 Next Header 字段中的值零指示.
如果作为处理报头的结果, 节点需要继续处理下一个报头, 但当前报头中的 Next Header 值不被节点识别, 则它应该丢弃该分组并向分组的源地址发送 ICMP Parameter Problem 消息, ICMP Code 值为 1 ("unrecognized Next Header type encountered (遇到无法识别的下一报头类型)"), ICMP Pointer 字段包含原始分组中无法识别值的偏移量.如果节点在除 IPv6 报头之外的任何报头中遇到 Next Header 值为零, 也应采取相同的行动.
每个扩展报头的长度是 8 个八位字节的整数倍, 以便为后续报头保持 8 个八位字节对齐.每个扩展报头中的多八位字节字段在其自然边界上对齐, 即宽度为 n 个八位字节的字段放置在距报头起始位置 n 个八位字节的整数倍处, 其中 n = 1、2、4 或 8.
IPv6 的完整实现包括以下扩展报头的实现:
Hop-by-Hop Options
Routing (Type 0)
Fragment
Destination Options
Authentication
Encapsulating Security Payload
前四个在本文档中规定; 后两个分别在 [RFC-2402] 和 [RFC-2406] 中规定.