Summary

  • RFC 3609 treated a top-level IP hop and the lower-level hops contained by a tunnel as different evidence objects; a clean outer trace could therefore be accurate and incomplete at the same time.
  • Tunnel detail depended on per-hop probes, response conditions, packet equivalence, protocol support and authorization. It did not prove production forwarding, ownership, service execution or user outcome.

One hop with a room inside it

Imagine an operations screen with five green nodes between a source and a destination. The third node is labelled by an address, answers on time and appears to connect cleanly to the fourth. The picture feels finished. Yet the third apparent “hop” may be the entrance to a GRE tunnel, an MPLS label-switched path, an IPsec construction or several heterogeneous tunnels nested inside one another. The outer trace can be truthful about the IP abstraction while saying almost nothing about the forwarding work concealed beneath it.

That was the gap RFC 3609 documented in September 2003. The Informational RFC did not standardise a finished tracing protocol. It specified requirements for an application and a protocol that could go beyond conventional traceroute, verify the IP forwarding plane and reveal tunnel detail when policy allowed. Its status matters. This is an architectural statement of need, not evidence that a generic mechanism was universally implemented or deployed.

The document's central distinction is easy to lose in a polished diagram. A response may represent a top-level IP hop or a lower-level hop contained by a tunnel. Those are not two labels for the same fact. The first says how the IP path appears at one layer. The second attempts to decompose the machinery supporting that appearance. A tunnel ingress and egress can be visible without the interior being known. Conversely, an authorized control-plane description of the interior does not itself prove that a particular production packet crossed every reported component.

Expansion is a governed act

RFC 3609 allowed a tunnel to be shown as a single hop or expanded in detail. The user could request the view, but permission still governed whether it was returned. A security token represented the tracer's privileges, and network elements were expected to use it when deciding whether to reveal information. The security section added identification, authorization and resource-control requirements.

That design makes visibility a relationship, not a universal entitlement. The same infrastructure may legitimately produce a collapsed view for one observer and a detailed view for another. A public trace, an operator trace and a vendor diagnostic can therefore disagree in granularity without one of them necessarily being false. Evidence records need to preserve who asked, under which authority, what was requested and what disclosure policy applied. Stripping those conditions from the output turns a scoped response into a false claim of neutral topology.

A detailed view could include tunnel type, name or identifier, endpoint addresses, components and component round-trip delay. Each field still has a boundary. A name does not prove ownership. An identifier does not prove current configuration. A round-trip value does not isolate one direction. A list of components does not prove that a later flow took the same interior path. The report is useful precisely because it is specific; it becomes dangerous when specificity is mistaken for omniscience.

A trace needs receipts that survive failure

The requirements demanded partial results through broken paths and broken tunnels. That led to a consequential protocol choice: separate probes and separate responses, with each response representing one hop. A single packet accumulating the whole path would make later evidence depend on every earlier participant and on the packet surviving to the end. Per-hop exchanges allow an operator to retain the last bounded observation even when the next segment is the failure under investigation.

They also make absence more complicated. No response can mean forwarding failure, filtering, rate limiting, missing protocol support, an unavailable return route, denied disclosure or an implementation fault. RFC 3609 explicitly required useful partial traces when a device did not support the proposed protocol; the application should identify the unsupported boundary and try to continue downstream. “Unknown”, “unsupported”, “withheld” and “failed” therefore need separate states. Rendering all four as a red hop fabricates a diagnosis the measurement did not make.

Returnability is part of the experiment. The tracing host needed routes to the traced ingress and to the ingress of each tunnel for which it requested detail. Interior devices needed routes back to the tunnel ingress, not necessarily to the original tracing host. A response chain can fail because its designed return condition is absent even while the forward path continues to carry production traffic. That is an observability failure, not automatically a forwarding failure.

The diagnostic packet must not choose another road

RFC 3609 rejected a proposed shortcut built around one probe carrying the IP Router Alert option. The reason was operational rather than aesthetic: many networks forward packets with IP options differently from packets without them. Adding an option could cause the tracing application to measure a path other than the one its user intended to investigate.

This is the document's sharpest lesson for modern evidence systems. A diagnostic is not representative merely because it reaches the same destination. Packet size, address family, flow key, options, DSCP, encapsulation and timing can change classification and path selection. The closer the probe is to a special control packet, the more carefully an operator must demonstrate equivalence with ordinary traffic. A beautifully detailed answer about the wrong packet class is not a better answer.

The RFC preferred a stateless, UDP-carried probe/response model, partly for scale and denial-of-service resistance. Statelessness constrains what nodes must remember between messages. It does not authenticate topology, guarantee that a reply describes the data plane, or eliminate replay and authorization questions. Transport design and evidentiary authority remain separate receipts.

Control plane and forwarding plane are two witnesses

RFC 3609 asked the application to trace the control plane, the forwarding plane or both. For a control-plane trace, the hop ingress would report the hop. For a forwarding-plane trace, the hop egress would report when the tunnel offered a TTL-decrement-like mechanism. The origin of the account changes with the plane.

That distinction prevents a familiar operational mistake. A control plane can contain a plausible next-hop story while programmed forwarding is stale, partial or broken. A forwarding response can show what one probe encountered without explaining the policy that selected it. Agreement strengthens confidence, but neither witness absorbs the other's role. A credible incident record keeps desired topology, programmed state, observed forwarding and application outcome in separate columns.

TTL behavior creates another boundary. RFC 3609 wanted forwarding-plane tracing whether or not the inner TTL was copied to the outer header, provided the tunnel had a decrement or similar mechanism. TTL propagation and the existence of an observable decrement are different properties. A trace that exposes or hides an interior hop is not, by that fact alone, proof of a configuration error.

Later RFCs developed more concrete mechanisms around this terrain. GRE and MPLS specifications explain the encapsulation and label-switched abstractions. MPLS TTL processing shows how visibility depends on propagation models. MPLS LSP ping and traceroute, eventually specified in RFC 8029 after earlier RFC 4379 work, add their own validation and reply semantics. ICMP extensions in RFC 4884 and the MPLS object in RFC 4950 can carry more detail. These advances add receipts; they do not retroactively prove deployment of RFC 3609's generic proposal or convert a reported label stack into end-to-end outcome evidence.

Build an evidence ladder, not a heroic map

For an operator, the smallest defensible record begins with the traffic specimen: source and destination, flow fields, size, options, service marking and time. It then records the outer trace with the vantage and method. If a tunnel is inferred or disclosed, the record adds ingress and egress, the authority under which details were released and whether the information came from control or forwarding plane. Interior hops require their own probe and response pairs, negative-result classes and return-route assumptions. Finally, packet delivery and service outcome need independent evidence.

This ladder preserves the logic of the minimum interoperable layer. A shared protocol can define what a request and response mean without forcing every network to expose every local detail. Operators can add richer evidence within their own authority. Running systems remain the source of operational truth, while a diagram remains a projection assembled from bounded observations.

The result is less cinematic than a complete map, but more useful. A path can be complete at the IP layer and unresolved inside a tunnel. A disclosure can be authentic and still limited to the control plane. A missing response can be classified without being overdiagnosed. And a successful trace can stop before claiming that an application worked. RFC 3609's enduring contribution was to make those limits part of the design.

Sources