我看到属于“TELEFONICA MOVILES”的移动电话网路上的ICMP风暴。 我们会定期在几秒钟内获得500万个以上的数据，如下所示：
08:12:05.740781 IP（tos 0x0，ttl 112，id 40224，offset 0，flags [none]，proto ICMP（1），length 56）200.76.88.6> ABCD：ICMP 200.39.21.96 unreachable – 需要frag（mtu 250），长度36
（“ABCD”是我的IP）
250甚至可能是合法的？ 68？ 这些ICMP在我们的这个问题上与更大的问题有关，但是我不能确定它们是一种症状，原因还是偶然的巧合。
pathMTU发现algorithm在这种情况下做什么？ 服务器是FreeBSD 7。
根据RFC 791，68字节的MTU在IPv4中是有效的：
每个互联网模块必须能够转发一个68字节的数据报，而不会有进一步的碎片。 这是因为互联网标题可能高达60个八位字节，最小的片段是8个八位字节。
重新组装的尺寸要求得到支持的要求要大得多：
每个互联网目的地都必须能够接收一个576个八位字节的数据报，可以是一个片段，也可以是重新组合的片段。
在IPv6中，这些数字被增加到1280和1500字节，如RFC 2460中所提到的：
IPv6要求互联网中的每个链路的MTU都是1280个八位字节或更大。 在任何不能传送1280个八位字节数据包的链路中，必须在低于IPv6的层上提供特定于链路的分段和重组。
一个节点必须能够接受一个分片的数据包，在重组之后，它大到1500个八位字节。 允许节点接受重组到1500个以上八位位组的分段数据包。 依赖于IPv6分片来发送大于pathMTU的数据包的上层协议或应用程序不应该发送大于1500个八位字节的数据包，除非它能保证目的地能够重组那些更大的数据包。
如果有人关心，这是我发现的。
简单的回答是，不，这些小的MTU是不合法的，但FreeBSD 7＆8应该更好地处理这种情况，因为在8月底左右会发生一些代码更改。
这个问题报告有更多： http : //www.freebsd.org/cgi/query-pr.cgi?pr=146628
Path MTU discovery（pathMTU发现）没有清除“do not fragment”标志，这意味着另一端顽固的不良行为主机将继续发送无法访问的“frag required”消息。 现在在接收到第一个微小的MTU之后，DF被清除，这有效地将问题下游移动到最靠近罪犯的路由器。 （因为他们必须为罪犯制造荒唐的碎片。）