Summary

  • RFC 1393 defined IPv4 option 82 and a matching ICMP message so one packet could cause each participating router to report its hop, output-link speed and MTU.
  • The experiment saved repeated probes only by requiring new per-packet behavior at every hop; it was never widely deployed, became Historic, and is now recommended for filtering.

A trace written by the path

The familiar traceroute algorithm succeeds because routers already know how to report an expired Time to Live. A sender transmits a packet with TTL 1, then 2, then 3, collecting ICMP Time Exceeded messages until the destination is reached. RFC 1393 counted roughly two packets per hop and noted two limitations: successive probes may encounter a changing path, and the method does not instrument the return path.

Its proposed alternative placed a Traceroute option in an outbound packet. Option type 82 encoded copy bit zero, debugging-and-measurement class 2, and option number 18. The option carried an identifier chosen by the originator, an outbound hop count, a return hop count and the originator’s IPv4 address. The identifier was explicitly unrelated to the IPv4 header Identification field.

The sender set the outbound count to zero and the return count to 0xFFFF, a sentinel meaning outbound. Each forwarding router was expected to send a new ICMP Traceroute message to the recorded originator, increment the applicable counter, and report the outgoing link’s speed and MTU, using zero when either was unknown. The marked packet itself was to follow the same route it would have taken without the option.

At the destination, a reply such as an ICMP Echo Reply could preserve the option, copy its identifier, originator and outbound count, and start the return count at zero. Routers on the way back could then report that direction too. The claimed economy was n+1 packets rather than 2n, plus a view of asymmetry that ordinary probing could not directly supply.

But the counters were not TTL. They increased only when a router actually sent a Traceroute report. A missing report therefore created a hole rather than a reliable shorter path, and merely counting received messages could not establish path length.

The deployment bargain that did not clear

The design’s economy at the endpoint depended on new work inside routers. RFC 1393 acknowledged that every participating router needed the traceroute function. It left security issues undiscussed. Those two facts later met: RFC 7126 observed that forcing each router to do special processing and generate ICMP could be used to exhaust CPU resources.

RFC 6814 supplied the historical verdict. The option remained Experimental, was never widely deployed on the public Internet, and RFC 1393 was formally made Historic in 2012. RFC 7126 then recorded no operational or interoperability impact from blocking type 82 and recommended that routers, security gateways and firewalls drop packets containing it.

This is not a story in which diagnostics ceased to matter. It is a story about where diagnostic work is placed. Conventional traceroute built on a behavior routers already needed for forwarding correctness. Option 82 asked the whole path to implement a new reporting service. Fewer sender probes could not compensate for a deployment dependency that had to succeed hop by hop.

Sources