分包

IPv6 路由器在向目的地转发报文时，不会替它进行分片。如果报文大于下一条链路所能承载的大小，路由器通常丢弃它，并发送 ICMPv6 Packet Too Big 反馈。源端随后可以调整报文大小，或在适当情况下通过 IPv6 分片扩展头发送分片；这些分片在目的端重组。明确各阶段由谁负责，是判断超大报文故障的基础。 坏掉的样子 假定路由器会自动拆开过大的 IPv6 包，会掩盖与大小相关的故障。相同地址与路由上，小 echo 可以成功，大 echo 却失败。端点本地接口可能支持原始大小，中间链路却不支持。应检查整条路径约束，不能仅因接口配置了 MTU 1500，就推断该大小能够端到端通过，也不能用一次小探测成功替代完整大小检查。 Packet Too Big 反馈缺失，会使经典发现更难学到这个限制。分片被过滤，或者其中一片丢失，也可能阻止正确重组。能够生成分片扩展头，不证明沿途策略都允许相应报文。不能把源端分片当作正确路径大小与必要控制流量的万能替代，它有自己的交付条件，需要通过对应流量验证，而不是只检查发送选项已经开启。 反方向也有自己的路径估计。请求发送端学到 MTU，不会自动教会响应端怎样发送较大回复。因此双向 echo 测试需要分别了解两个方向。TCP 分段还不同于 IP 分片：TCP 发送端学到限制后，可以构造更小的段，而不必把每个 IP 包再分片。应先确定观察的是哪一层的切分，避免看到多个包就统称为分片。 快速验证 将脚本保存为 check-ipv6-fragmentation.py，准备 Docker 后运行 python3 check-ipv6-fragmentation.py。一次性环境使用 Python 3.11.16、iproute2 6.1.0、iputils ping 和 tcpdump 4.99.3，在 Linux 6.12.76 上验证。NET_ADMIN 与 SYS_ADMIN 支持四个嵌套命名空间。两台路由器和两个端点使用新建 veth，不修改宿主接口或路由： ...