跳到主要内容

8. 上层协议问题

8.1. 上层校验和​

任何在校验和计算中包含 IP 头部地址的传输协议或其他上层协议, 都必须修改为可在 IPv6 上使用, 即包含 128 位 IPv6 地址而不是 32 位 IPv4 地址. 特别是, 下图展示了 IPv6 的 TCP 和 UDP "pseudo-header":

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                         Source Address                        +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                      Destination Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                   Upper-Layer Packet Length                   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      zero                     |  Next Header  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • 如果 IPv6 数据包包含 Routing header, pseudo-header 中使用的 Destination Address 是最终目的地地址. 在发起节点处, 该地址位于 Routing header 的最后一个元素中. 在接收方处, 该地址位于 IPv6 头部的 Destination Address 字段中.

  • pseudo-header 中的 Next Header 值标识上层协议, 例如 TCP 为 6, UDP 为 17. 如果 IPv6 头部和上层头部之间存在扩展头部, 它将不同于 IPv6 头部中的 Next Header 值.

  • pseudo-header 中的 Upper-Layer Packet Length 是上层头部和数据的长度, 例如 TCP 头部加 TCP 数据. 某些上层协议携带自己的长度信息, 例如 UDP 头部中的 Length 字段. 对这类协议, 这就是 pseudo-header 中使用的长度. 其他协议 (如 TCP) 不携带自己的长度信息, 在这种情况下, pseudo-header 中使用的长度是 IPv6 头部中的 Payload Length 减去 IPv6 头部与上层头部之间任何扩展头部的长度.

  • 与 IPv4 不同, IPv6 节点发起 UDP 数据包时的默认行为是 UDP 校验和不是可选的. 也就是说, 每当发起 UDP 数据包时, IPv6 节点都必须对该数据包和 pseudo-header 计算 UDP 校验和. 如果该计算结果为零, 则必须改为十六进制 FFFF 以放入 UDP 头部. IPv6 接收者必须丢弃包含零校验和的 UDP 数据包, 并应记录该错误.

  • 作为默认行为的例外, 使用 UDP 作为隧道封装的协议可以为特定端口 (或端口集合) 启用零校验和模式, 用于发送和/或接收. 任何实现零校验和模式的节点都必须遵循 "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums" [RFC6936] 中规定的要求.

IPv6 版本的 ICMP [RFC4443] 在其校验和计算中包含上述 pseudo-header. 这不同于 IPv4 版本的 ICMP, 后者在校验和中不包含 pseudo-header. 这种变化的原因是保护 ICMP 不受误递送或其依赖的 IPv6 头部字段损坏的影响, 因为这些字段不同于 IPv4, 不受互联网层校验和保护. ICMP pseudo-header 中的 Next Header 字段包含值 58, 标识 IPv6 版本的 ICMP.

8.2. 最大数据包生命周期​

与 IPv4 不同, IPv6 节点不要求强制执行最大数据包生命周期. 这就是 IPv4 "Time-to-Live" 字段在 IPv6 中改名为 "Hop Limit" 的原因. 实际上, 很少有 IPv4 实现 (如果有的话) 符合限制数据包生命周期的要求, 因此这在实践中并不是变化. 任何依赖互联网层 (无论 IPv4 还是 IPv6) 限制数据包生命周期的上层协议, 都应该升级为提供自己的机制来检测并丢弃过时数据包.

8.3. 最大上层 Payload 大小​

计算可用于上层数据的最大 payload 大小时, 上层协议必须考虑 IPv6 头部相对 IPv4 头部更大的大小. 例如, 在 IPv4 中, TCP 的 Maximum Segment Size (MSS) 选项计算为最大数据包大小 (默认值或通过 Path MTU Discovery 获知的值) 减去 40 个八位字节 (20 个八位字节用于最小长度 IPv4 头部, 20 个八位字节用于最小长度 TCP 头部). 使用 TCP over IPv6 时, MSS 必须计算为最大数据包大小减去 60 个八位字节, 因为最小长度 IPv6 头部 (即没有扩展头部的 IPv6 头部) 比最小长度 IPv4 头部长 20 个八位字节.

8.4. 响应携带 Routing Header 的数据包​

当上层协议响应收到的包含 Routing header 的数据包而发送一个或多个数据包时, 响应数据包不得包含通过 "反转" 收到的 Routing header 自动派生出的 Routing header, 除非已验证收到的 Source Address 和 Routing header 的完整性与真实性, 例如通过收到数据包中的 Authentication header. 换句话说, 对携带 Routing header 的收到数据包, 只允许以下类型的数据包作为响应:

  • 不携带 Routing header 的响应数据包.

  • 携带并非通过反转收到数据包的 Routing header 派生而来的 Routing header 的响应数据包, 例如由本地配置提供的 Routing header.

  • 携带通过反转收到数据包的 Routing header 派生而来的 Routing header 的响应数据包, 当且仅当 responder 已验证收到数据包中 Source Address 和 Routing header 的完整性与真实性.

最后于 更新