Summary

  • Traceroute did not require a central topology database. It varied the IP Time to Live so that successive probes expired one hop farther away, then used ICMP error responses to assemble a local view of the forwarding path.
  • The useful mechanism was composed from behaviours that already existed, but the first release still depended on host-side control: Jacobson warned in 1988 that his 4BSD users might need to change raw-IP kernel output so a program could set TTL.
  • A trace is evidence from one vantage at one moment, not a title register for the Internet. Silence, route changes, asymmetric return paths, tunnels, address aliases and load balancing all limit what the output proves.

A question the routing table could not answer

On 20 December 1988, Van Jacobson sent a short announcement to the IETF and end-to-end-interest mailing lists. After what he called a frustrating week trying to determine where packets were going, he had assembled a 4BSD routing diagnostic. It sent a UDP packet with a Time to Live of one and waited for an ICMP Time Exceeded response. If one arrived, the program printed its source address, increased the TTL and tried again.

The surviving message matters because it preserves the scale of the invention. Jacobson did not announce a topology service, a new routing protocol or an institution authorised to publish the one true path. He offered source code by FTP. He credited the idea to Steve Deering at an end-to-end task-force meeting. He also said the software might require a kernel modification: the raw IP output routine had to let a user program set the TTL.

That final detail is easy to lose in a modern retelling. The routers already contained most of the necessary behaviour, but the sender still needed a usable control surface in its own machine. A protocol feature becomes an operator tool only when software can reach it.

The self-destruct field

Time to Live was not created to show a route. RFC 791 defined it as an upper bound on a datagram’s life. The sender supplied a value. Every point processing the IP header reduced it, by at least one even when the actual processing time was not known. If the value reached zero before the destination, the datagram was destroyed.

The original purpose was defensive. A routing error should not leave packets circulating forever, consuming capacity while no endpoint could repair them. RFC 1812 would later describe TTL’s hop-count role as critical to preventing routing problems from melting down a network through infinite loops.

Traceroute turned that destruction rule into a measuring edge. A probe with TTL one died at the first forwarding hop. A probe with TTL two could pass the first and die at the second. Repetition converted a limit into distance—not geographic distance and not link length, but the number of forwarding decrements survived by that particular probe.

This was a creative reuse, not evidence that the protocol designers secretly intended an atlas. The distinction is important. Minimal common mechanisms often become valuable precisely because later users can combine them without waiting for the original specification to predict every application.

When failure sent a return address

Destruction alone would produce only silence. ICMP supplied the report. RFC 792 described the Internet Control Message Protocol as a way for gateways or destination hosts to send feedback about problems in the communications environment. A gateway that found TTL at zero had to discard the datagram and could notify the source with a Time Exceeded message.

Classic traceroute used the address from that response as the next visible point. It then needed to know when the probe had reached the destination rather than another intermediate hop. The Unix method sent UDP datagrams to an invalid high-numbered port. Intermediate routers answered with Time Exceeded; the destination answered with ICMP Port Unreachable. That different failure meant the trace was complete.

By 1994, RFC 1739 could explain the sequence as an ordinary Internet tool: commonly three probes at each TTL, rising one step at a time, with round-trip response times displayed beside the responding addresses. The output felt like a path because the program transformed multiple failed deliveries into an ordered list.

But RFC 792 had already supplied the warning that must travel with every list. ICMP feedback did not make IP reliable. There was no guarantee that a control message would return. An asterisk therefore does not prove that no router exists at that hop. It can reflect filtering, suppression, rate limiting, congestion, loss or a device that forwarded the probe but declined to answer.

Why no router upgrade was the decisive advantage

RFC 1393, published in 1993, gives a revealing comparison. It described the familiar increasing-TTL method and proposed an explicit IP traceroute option plus a new ICMP message. The proposed design could use fewer packets and gather return-path information, but it required traceroute functionality to be added to routers.

The existing method’s advantage was blunt: routers already knew how to return TTL-exceeded errors. No traceroute-specific code had to be installed in every transit network before the first useful trace could run.

This is Running-Code Primacy in its least ceremonial form. A small application at one edge used a minimal behaviour implemented across many independent devices. It did not ask those devices to recognise a new institution, join a database or coordinate an upgrade date. The value appeared where the probes were launched and interpreted.

That does not prove that explicit mechanisms are always inferior. RFC 1393 addressed real costs: classic traceroute repeats probes through nearer hops, the path can change while the sequence is running, and the outbound result says nothing direct about the return path. The historical point is narrower. A deployment-light composition could become useful before a more purpose-built design acquired the required router support.

From repair tool to public window

Jacobson described a program born from one routing problem. RFC 1739 later called traceroute a common tool for network and system managers and observed that end users could learn something about the structure of the Internet. RFC 1470 placed it in a catalog of tools for monitoring and debugging interconnected TCP/IP networks.

That movement changed who could make a claim about a path. An operator no longer needed privileged access to every intermediate routing table to see that packets appeared to cross Berkeley, a regional network and the NSFNET before reaching a remote host. A user could preserve the command, the time and the responses, and ask a provider why the observed route had changed.

The tool therefore distributed observability more than authority. Transit networks continued to choose routes. Routers continued to decide which interface address to place in a response and whether to respond at all. Traceroute gave the endpoint a test, not a lever over those decisions.

This distinction matters for accountability. A central map can be stale, selective or institutionally interested. A local probe can challenge it with running evidence. Yet the probe is also partial. The right institutional settlement is not to replace one unquestionable map with one unquestionable command output. It is to make claims contestable by preserving method, vantage and uncertainty.

The path that changes while it is being drawn

A classic trace is not one packet carrying a notebook through every router. It is a sequence of different packets. RFC 1393 noted the consequence: the route may change during the process. It also stated plainly that the method does not trace the return path, which may be different from the outbound path.

Load balancing adds a subtler error. Classic implementations change header fields while moving through probes and destination ports. Routers that divide traffic by a flow hash can send those probes along different equal-cost paths. The resulting output may assemble interfaces that no single packet visited in that order.

The 2006 Paris traceroute research made this visible. Its authors showed that ordinary traces could produce apparent loops, cycles and diamonds because probe headers interacted with load-balancing decisions. By controlling the fields used to identify a flow, Paris traceroute removed many of those artifacts and produced a more faithful view of one path class.

That correction did not make topology final. Tunnels may hide internal hops. Several interface addresses may belong to one router. A DNS name may be stale or misleading. An ICMP response travels back on a path that can differ from the forward probe. Reverse-traceroute research later quantified how poor a simple symmetry assumption could be and built additional mechanisms to infer the other direction.

Every improvement preserved the original lesson: observation is an experiment. Better control of the experiment improves the evidence; it does not turn the result into ownership.

What an address does not authorise

The address printed on a traceroute line is the source address selected for an ICMP response. It may be an interface, a loopback or an address whose naming and organisational data were maintained elsewhere. It does not by itself prove which company owns the chassis, which carrier supplied the underlying circuit, which autonomous system set every relevant policy or which jurisdiction could order a repair.

Nor does a round-trip figure beside that address measure the one-way delay of the preceding link. It includes the probe’s outward travel, the router’s treatment of the packet and the response path back. Queueing can move. Replies can receive different priority from forwarded data. Three numbers are evidence of three experiments, not an invoice assigning delay to one institution.

This is the line between a diagnostic ledger and mandate laundering. The running network can contradict a claim: a trace may show that traffic reached an unexpected interface or stopped before the advertised destination. But the observer must add routing data, operator statements, configuration evidence and repeated measurements before assigning cause and responsibility.

Traceroute’s great contribution was not that it made the Internet transparent. It made one kind of opacity testable from the edge.

A thin mechanism with a durable afterlife

The tool’s history joins three layers that are often confused. The protocol layer bounded packet lifetime and described error feedback. The host-software layer exposed those fields and interpreted responses. The operator layer decided what the observations meant and what action to take.

No layer acquired the rights of the others. RFC 791 did not create an Internet map. Jacobson’s code did not command routers. An ICMP response did not certify an owner. The strength of the arrangement came from keeping the common behaviour small enough to implement while leaving future decisions local.

That is why a map made from expired packets remains useful. It is cheap to challenge, easy to repeat and explicit about where the observation began. Its blanks are visible. Its errors can be studied. Competing implementations can improve the probe without asking one global gatekeeper to redraw the network.

The Internet did not become accountable because every path was published. It became more inspectable because an endpoint could ask the forwarding system a sequence of bounded questions—and because the honest answer was always a trace, never the map.

Sources and evidence limits

The TTL mechanism and its original lifetime purpose come from RFC 791. ICMP’s role and its lack of delivery guarantees come from RFC 792. Jacobson’s implementation description, credit to Steve Deering and kernel warning are preserved in the 20 December 1988 announcement.

The contemporary tool record is RFC 1470 and RFC 1739. The comparison with an explicit router-supported design and the early statement of changing and asymmetric paths come from RFC 1393. Later router requirements are in RFC 1812.

Load-balancing artifacts are documented in the Paris traceroute paper; the reverse-path limitation is developed in Reverse traceroute. These later works show why the method must be interpreted carefully. They do not erase the operational value of the original tool.