发生ICMP不可达差错的另一种情况是，当路由器收到一份需要分片的数据报，而在IP首部又设置了不分片（DF）的标志比特。如果某个程序需要判断到达目的端的路途中最小MTU是多少—称作路径MTU发现机制（2.9节），那么这个差错就可以被该程序使用。
    这种情况下的ICMP不可达差错报文格式如图11-9所示。这里的格式与图6-10不同，因为在第2个32 bit字中，16~31 bit可以提供下一站的MTU，而不再是0。

    如果路由器没有提供这种新的ICMP差错报文格式，那么下一站的MTU就设为0。
    新版的路由器需求RFC [Almquist 1993]声明，在发生这种ICMP不可达差错时，路由器必须生成这种新格式的报文。
例子
    关于分片作者曾经遇到过一个问题， ICMP差错试图判断从路由器netb到主机sun之间的拨号SLIP链路的MTU。我们知道从sun到netb的链路的MTU：当SLIP被安装到主机sun时，这是SLIP配置过程中的一部分，加上在3.9节中已经通过netstat命令观察过。现在，我们想从另一个方向来判断它的MTU（在第25章，将讨论如何用SNMP来判断）。在点到点的链路中，不要求两个方向的MTU为相同值。
    所采用的技术是在主机solaris上运行ping程序到主机bsdi，增加数据分组长度，直到看见进入的分组被分片为止。如图11-10所示。

    在主机sun上运行tcpdump，观察SLIP链路，看什么时候发生分片。开始没有观察到分片，一切都很正常直到ping分组的数据长度从500增加到600字节。可以看到接收到的回显请求（仍然没有分片），但不见回显应答。
    为了跟踪下去，也在主机bsdi上运行tcpdump，观察它接收和发送的报文。输出如图11-11所示。

    首先，每行中的标记（DF）说明在IP首部中设置了不分片比特。这意味着Solaris 2.2 一般把不分片比特置1，作为实现路径MTU发现机制的一部分。
    第1行显示的是回显请求通过路由器netb到达sun主机，没有进行分片，并设置了DF比特，因此我们知道还没有达到netb的SLIP MTU。
    接下来，在第2行注意到D F标志被复制到回显应答报文中。这就带来了问题。回显应答与回显请求报文长度相同（超过6 0 0字节），但是sun外出的SLIP接口MTU为552。因此回显应答需要进行分片，但是DF标志比特又被设置了。这样， sun就产生一个ICMP不可达差错报文返回给bsdi（报文在bsdi处被丢弃）。
    这就是我们在主机s o l a r i s上没有看到任何回显应答的原因。这些应答永远不能通过sun。分组的路径如图11 - 1 2所示。

    最后，在图11-11中的第3行和第6行中，mtu = 0表示主机s u n没有在ICMP不可达报文中返回出口MTU值，如图11-9所示（在25.9节中，将重新回到这个问题，用SNMP判断netb上的SLIP接口MTU值为1500）。