Skip to main content

8. Upper-Layer Protocol Issues (上层协议问题)

8.1. Upper-Layer Checksums (上层校验和)​

任何在其校验和计算中包含来自 IP 头部的地址的传输或其他上层协议都必须 (MUST) 修改以用于 IPv6, 以包含 128 位 IPv6 地址而不是 32 位 IPv4 地址. 特别是, 以下插图显示了 IPv6 的 TCP 和 UDP "伪头部":

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

  • 如果 IPv6 数据包包含路由头部, 则伪头部中使用的目标地址是最终目标的地址. 在发起节点, 该地址将在路由头部的最后一个元素中; 在接收方, 该地址将在 IPv6 头部的目标地址字段中.

  • 伪头部中的下一头部值标识上层协议 (例如, TCP 为 6, UDP 为 17). 如果 IPv6 头部和上层头部之间存在扩展头部, 它将与 IPv6 头部中的下一头部值不同.

  • 伪头部中的上层数据包长度是上层头部和数据的长度 (例如, TCP 头部加 TCP 数据). 一些上层协议携带自己的长度信息 (例如, UDP 头部中的长度字段); 对于此类协议, 这是伪头部中使用的长度. 其他协议 (如 TCP) 不携带自己的长度信息, 在这种情况下, 伪头部中使用的长度是 IPv6 头部的有效载荷长度, 减去 IPv6 头部和上层头部之间存在的任何扩展头部的长度.

  • 与 IPv4 不同, 当 IPv6 节点发起 UDP 数据包时, 默认行为是 UDP 校验和不是可选的. 也就是说, 每当发起 UDP 数据包时, IPv6 节点必须 (MUST) 计算数据包和伪头部的 UDP 校验和, 并且如果该计算产生零结果, 则必须 (MUST) 将其更改为十六进制 FFFF 以放置在 UDP 头部中. IPv6 接收方必须 (MUST) 丢弃包含零校验和的 UDP 数据包, 并应该 (SHOULD) 记录错误.

  • 作为默认行为的例外, 使用 UDP 作为隧道封装的协议可以为特定端口 (或一组端口) 的发送和/或接收启用零校验和模式. 任何实现零校验和模式的节点都必须 (MUST) 遵循"使用零校验和的 IPv6 UDP 数据报的适用性声明" [RFC6936] 中指定的要求.

IPv6 版本的 ICMP [RFC4443] 在其校验和计算中包含上述伪头部; 这是与 IPv4 版本的 ICMP 的变化, 后者在其校验和中不包含伪头部. 更改的原因是保护 ICMP 免受其所依赖的 IPv6 头部字段的错误传递或损坏, 这些字段与 IPv4 不同, 不受互联网层校验和的保护. ICMP 的伪头部中的下一头部字段包含值 58, 它标识 IPv6 版本的 ICMP.

8.2. Maximum Packet Lifetime (最大数据包生命周期)​

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

8.3. Maximum Upper-Layer Payload Size (最大上层有效载荷大小)​

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

8.4. Responding to Packets Carrying Routing Headers (响应携带路由头部的数据包)​

当上层协议发送一个或多个数据包以响应包含路由头部的接收数据包时, 响应数据包禁止 (MUST NOT) 包含通过"反转"接收到的路由头部自动派生的路由头部, 除非已验证接收到的源地址和路由头部的完整性和真实性 (例如, 通过在接收到的数据包中使用认证头部). 换句话说, 仅允许以下类型的数据包响应携带路由头部的接收数据包:

  • 不携带路由头部的响应数据包.

  • 携带路由头部的响应数据包, 这些路由头部不是通过反转接收数据包的路由头部派生的 (例如, 由本地配置提供的路由头部).

  • 携带路由头部的响应数据包, 这些路由头部是通过反转接收数据包的路由头部派生的, 当且仅当 (IF AND ONLY IF) 响应方已验证接收数据包的源地址和路由头部的完整性和真实性.

Last updated on