分包

IPv6 路由器在向目的地转发报文时，不会替它进行分片。如果报文大于下一条链路所能承载的大小，路由器通常丢弃它，并发送 ICMPv6 Packet Too Big 反馈。源端随后可以调整报文大小，或在适当情况下通过 IPv6 分片扩展头发送分片；这些分片在目的端重组。明确各阶段由谁负责，是判断超大报文故障的基础。 坏掉的样子 假定路由器会自动拆开过大的 IPv6 包，会掩盖与大小相关的故障。相同地址与路由上，小 echo 可以成功，大 echo 却失败。端点本地接口可能支持原始大小，中间链路却不支持。应检查整条路径约束，不能仅因接口配置了 MTU 1500，就推断该大小能够端到端通过，也不能用一次小探测成功替代完整大小检查。 Packet Too Big 反馈缺失，会使经典发现更难学到这个限制。分片被过滤，或者其中一片丢失，也可能阻止正确重组。能够生成分片扩展头，不证明沿途策略都允许相应报文。不能把源端分片当作正确路径大小与必要控制流量的万能替代，它有自己的交付条件，需要通过对应流量验证，而不是只检查发送选项已经开启。 反方向也有自己的路径估计。请求发送端学到 MTU，不会自动教会响应端怎样发送较大回复。因此双向 echo 测试需要分别了解两个方向。TCP 分段还不同于 IP 分片：TCP 发送端学到限制后，可以构造更小的段，而不必把每个 IP 包再分片。应先确定观察的是哪一层的切分，避免看到多个包就统称为分片。 路由器不会对转发的 IPv6 流量分片。源端分片、目的端重组与学习路径上限属于不同阶段。报文和开口形状为示意，未按字节比例绘制。网络示例执行仍受阻，本次未重跑。 快速验证 历史报告使用 Linux 6.12.76、Python 3.11.16、iproute2 6.1.0 与 tcpdump 4.99.3；本轮没有重跑。脚本名为 check-ipv6-fragmentation.py，只应留给另外获得授权的可丢弃 Linux 虚拟机实验。容器共享该虚拟机的内核，NET_ADMIN、SYS_ADMIN 与 proc 挂载需要比生产容器更明确的隔离边界。之后运行时的 --network none 不会阻止镜像构建下载软件包。保持断言开启，不要为通过设置而放宽宿主安全策略。新建 veth、地址与路由仅应存在于实验内部： ...