摘要

  • RFC 1393 定义了 IPv4 选项 82 和配套 ICMP 消息，让单个数据包触发沿途路由器报告跳数、出口链路速率与 MTU。
  • 它减少发送端探测包的代价，是要求每一跳增加专门处理；该机制从未广泛部署，后来被列为 Historic，并被建议过滤。

不再逐门敲问

经典 traceroute 的聪明之处，在于借用了路由器本来就具备的 TTL 过期行为。发送端先把 TTL 设为 1，再设为 2、3，依次收集 ICMP Time Exceeded，直到抵达目的地。RFC 1393 认为，这大约需要 2n 个数据包，重复经过近端路径也耗时；多次探测之间路径还可能变化，而且回程路径没有被直接记录。

新方案不再逐级增加 TTL，而是在一个外发数据包中放入 Traceroute 选项。类型 82 由“不复制到分片”的复制位、调试与测量类别 2、选项号 18 组成。字段包括起点自选的标识符、去程跳数、回程跳数和起点 IPv4 地址。规范特别说明，这个标识符与 IPv4 首部的 Identification 字段无关。

起点把去程计数设为零，把回程计数设为 0xFFFF；这个特殊值表示数据包正处于去程。路由器转发时，应向选项中的起点地址发送 ICMP Traceroute 消息，再增加相应方向的计数。若能够确定，它还会报告出口链路速率和 MTU；不能确定则填零。原数据包仍应像没有该选项一样选择路径。

目的节点可以把选项带入应答，保留标识、起点地址与去程计数，并把回程计数重新设为零。这样，返程沿途的路由器也能回报。它许诺用 n+1 个包代替 2n，并让路径不对称第一次进入同一套测量结构。

但这里的跳数不是 TTL。只有实际发出 ICMP Traceroute 报告时，路由器才增加计数。因此少一封回信意味着证据出现空洞，而不是路径必然少了一跳；收到几条消息，不能单独证明路径长度。

节省没有消失，只是转移了

RFC 1393 把发送端的重复探测，换成了每台路由器的新功能。规范自己承认，路由器必须专门实现该 traceroute 机制；安全章节则没有讨论风险。RFC 7126 后来补上了这部分：路径上每台路由器都要做特殊处理并产生 ICMP，这种机制可能被利用来耗尽路由器的 CPU 资源。

RFC 6814 给出了生命周期结论。选项 82 一直是实验性协议，在公共互联网从未广泛部署；2012 年，RFC 1393 被正式废止并改列 Historic。RFC 7126 又说明，阻断它没有运营或互通影响，并建议路由器、安全网关与防火墙丢弃带有该选项的数据包。

失败的不是“看见路径”这个需求，而是实现依赖的位置。经典 traceroute 借用普遍存在的差错报告；选项 82 则要求整条路径新增测量服务。发送端少发几个包，无法抵消每一跳都必须配合的部署门槛。

来源