Summary

  • A device that rewrites a traceroute probe's TTL to a high static value, commonly 255 in the new study, can hide the rest of the forward path. The destination may then appear next to the last visible router or AS even though other networks carried the packet between them.
  • The researchers found affected traces from 950 RIPE Atlas probes in 471 ASes and identified at least 47 ASes most likely associated with rewrites. Those totals describe selected measurements, not the share of the Internet affected, and the IPv4 and IPv6 subtotals overlap.
  • A packet captured at the target and the original probe quoted inside an ICMP error can prove an upward rewrite. Path length, apparent one-hop loops and topology knowledge can only warn. RIPE Atlas records the quoted inner TTL as optional ittl, so a missing value means evidence unavailable, not rewrite absent.

The packet arrived; the intermediate path disappeared

Consider a trace in which the third visible router receives a probe whose TTL is about to expire. Under the ordinary mechanism, that router or the next one reduces the value to zero, discards the packet and returns ICMP Time Exceeded. A later probe starts with a larger TTL and exposes the following hop.

Now put a device on the path that replaces the probe's remaining TTL with 255. The next router sees 254, not zero. Later routers see 253, 252 and 251. None of them needs to produce the expiry message on which traceroute depends. If the destination answers, it can become the next visible line after the last router seen before the rewrite.

The packet did not jump across the hidden routers. The representation did.

That difference matters when a trace is converted into topology. Consecutive responses are often treated as evidence of consecutive routers. Their addresses are then mapped to autonomous systems, and consecutive AS labels can become an inferred interconnection. A static TTL rewrite can therefore manufacture a router link and an AS link without creating either in the forwarding network.

This is not the familiar equal-cost multipath problem. Classic probes can take different paths and assemble replies that no single packet saw in that order. Paris traceroute reduces that error by holding the flow identifiers steady. It still needs each device to decrement the probe's TTL. Flow consistency cannot repair a field that an on-path device raises.

The controlled result is large enough to matter and too bounded to universalise

Sebastian Kappes, Anja Feldmann, Tobias Fiebig and Johannes Zirngibl tested the mechanism with RIPE Atlas probes and destinations where arriving packets could be captured. RIPE Labs reports affected traces from 950 probes in 471 ASes. The address-family figures are overlapping views of those totals: 800 IPv4 probes and 538 IPv6 probes; 446 IPv4 ASes and 263 IPv6 ASes. Adding either pair would count some probes or networks twice.

The paper identifies at least 47 ASes most likely associated with path-impairing rewrites. Forty-three most commonly rewrote to 255; four to 64. The measurements include apparent source-network and transit cases. RIPE Labs cites 14 affected probes in Orange AS5511 and 65 in AT&T AS7018 where the last visible hop remained inside the source AS. It also describes probes in other source networks whose traces were affected after traversing Arelion AS1299.

Those names locate evidence; they do not settle responsibility. Once the remainder of a path has been hidden, the AS of the last visible address is only the most likely site of the rewrite. That address might belong to a border router. The paper also found many traces that passed through an implicated AS without a rewrite. A network cannot be classified once for every path it may carry.

The limits are as important as the lower bound. RIPE Atlas and CAIDA Ark have their own distributions of probes and targets. Many Atlas measurements are created by users and change over time. The controlled scans used a limited set of destinations. The result proves that the mechanism exists at operational scale. It does not estimate the fraction of all Internet paths affected.

One day's 49,600 traces have a precise denominator

The historical analysis used quoted TTL values preserved inside ICMP errors. For the RIPE Atlas snapshot of 10 November 2025, the researchers began with 204.8 million traces. Of those, 2.65 million received a relevant ICMP error. Only 139,600 included a quoted TTL that could be used for this test. The classifier found rewrites in 49,600 of that final subset, or 35.5%.

The honest headline is not that 35.5% of Atlas traces were rewritten. It is that 35.5% of the quoted-TTL subset in one stated snapshot met the test. The reduction from 204.8 million to 139,600 is part of the result, because it describes where decisive evidence was available.

The historical series found signs of the behaviour from February 2018 onward. Its visibility increased over time. That trend combines the running network with a changing measurement population, optional error fields and a test that detects increases better than decreases. It is a conservative lower bound for the checked paths, not a census of device deployment.

One CAIDA Ark case shows how strongly a particular vantage can be distorted. For the igx2-us IPv6 node inside AT&T AS7018, 93.4% of completed traceroutes in October 2025 had length four. Separately, 95.9% of identified loops ended with three identical hops. These are two denominators inside one case study. They are not percentages of AT&T traffic, customers or all network paths.

Two proofs and three warnings

The paper offers five indicators. Their names can sit in one list; their authority cannot.

Indicator What it can establish
Packet captured at the target with a TTL above every value sent Decisive evidence of an upward rewrite on that path
Original probe quoted in an ICMP error with a TTL above every value sent Decisive evidence of an upward rewrite on that path
Apparent forward path much shorter than the estimated reverse path A warning that needs packet evidence
The same address answers adjacent TTLs as an apparent one-hop loop A warning that needs packet evidence
An apparent link conflicts with independent topology information A warning that needs packet evidence and careful AS mapping

The last three are neither necessary nor sufficient. A short path can be real. A loop can have another cause. Public routing and peering data are incomplete, and a router's response address does not always reveal the boundary a researcher wants. Turning a warning into a verdict would repeat the topology error at a different layer.

The two decisive methods also have an availability cost. A researcher can capture arrivals only at a destination under suitable control. The ICMP method works only when a target or last reachable node sends a usable error containing the original probe. Coverage narrows as evidentiary confidence rises.

Optional ittl is a state boundary

RIPE Atlas documents ittl as the TTL in the packet that triggered an ICMP error. The field is optional. RIPE Labs says Atlas saves this inner TTL only occasionally. When it is present and greater than every TTL sent during the trace, it can carry decisive evidence. When it is absent, a downstream topology process has no equivalent quoted value to test.

That absence deserves its own state. It must not be normalised to zero, false or clean. A Boolean such as ttl_rewrite=false would silently join two different claims: “decisive evidence found no upward rewrite” and “the decisive evidence did not exist.”

A compact per-path record could instead preserve four outcomes:

  • confirmed_target_capture when the arriving packet proves the increase;
  • confirmed_quoted_ttl when an ICMP quotation proves it;
  • indicator_only when shape or outside topology raises suspicion without proof;
  • evidence_unavailable when neither decisive method can be applied.

The labels are not important. The separation is. The record should retain the measurement and probe IDs, source and target, address family, protocol, timestamp, largest TTL sent, observed ittl when available, decision method, classifier version and the derived edge that was withheld or retained. A later packet capture or corrected classifier can then change the conclusion without erasing the earlier receipt.

The cause remains outside the proof

The researchers could not find a citable root cause and could not reproduce the behaviour in their lab. Two operators offered anonymous explanations. One involved double MPLS labels and an implementation that copied the inner label's TTL back into the IP payload. Another involved a network operating system and the mapping of a broadband-gateway function into an ASIC vendor's SDK.

These accounts make implementation defects plausible. They do not assign a common vendor or fault to every observed path. The paper also reports a conjecture that TTL pinning could hide business relationships, then judges it unlikely because the same behaviour damages the operator's own diagnostics. Evidence of a hidden hop is not evidence of a hidden motive.

Sources

The current public explanation is RIPE Labs' When Traceroutes Lie. Methods, denominators, limitations and the AT&T case come from Kappes, Feldmann, Fiebig and Zirngibl's accepted IMC 2026 paper, TTL Jumps: Unexpected TTL Rewrites Impacting Inferences from Traceroutes, DOI 10.1145/3777912.3809149.

The optional result field is defined in the RIPE Atlas measurement result format, version 5000. The paper identifies its packet captures and trace data at DOI 10.17617/3.D5GQFG. The evidence establishes the observed mechanism and bounded datasets; it does not provide an Internet-wide prevalence rate or definitive device attribution.