Zusammenfassung

  • Setzt ein Gerät die TTL eines Traceroute-Pakets auf einen hohen festen Wert, in der neuen Studie meist auf 255, kann der restliche Vorwärtspfad unsichtbar werden. Das Ziel erscheint neben dem letzten sichtbaren Router oder AS, obwohl weitere Netze das Paket dazwischen getragen haben.
  • Die Forschenden fanden betroffene Traces von 950 RIPE-Atlas-Probes in 471 ASes und identifizierten mindestens 47 ASes als wahrscheinliche Orte solcher Umschreibungen. Das ist ein begrenzter Messbefund, keine Quote für das gesamte Internet; die IPv4- und IPv6-Teilzahlen überschneiden sich.
  • Ein Paketmitschnitt am Ziel und die in einem ICMP-Fehler zitierte ursprüngliche TTL können eine Erhöhung beweisen. Pfadlänge, scheinbare Ein-Hop-Schleifen und externe Topologiekenntnis sind nur Warnzeichen. RIPE Atlas speichert die innere TTL im optionalen Feld ittl: Fehlt es, fehlt der Beleg — die Umschreibung ist damit nicht widerlegt.

Der Pfad blieb, nur die Ablaufmeldungen verschwanden

Traceroute baut seine Ansicht aus absichtlich herbeigeführten Ablaufereignissen. Ein Messpaket startet mit begrenzter TTL, jeder Router verringert sie. Bei null verwirft das Gerät das Paket und kann ICMP Time Exceeded zurücksenden. Das nächste Paket erhält eine größere Ausgangs-TTL und legt normalerweise einen weiteren Hop frei.

Ein Gerät, das den Restwert auf 255 setzt, unterbricht diese Folge. Der nächste Router sieht 254, die späteren sehen 253, 252 und 251. Keiner erreicht null, keiner muss die von Traceroute erwartete Ablaufmeldung erzeugen. Antwortet das Ziel, kann es direkt nach dem letzten vor der Umschreibung sichtbaren Gerät erscheinen.

Die verborgenen Router haben weitergeleitet. Der Messdatensatz hat sie ausgelassen.

Wird der Datensatz in eine Topologie übersetzt, wird die Lücke zur falschen Beziehung. Aufeinanderfolgende Antworten gelten häufig als benachbarte Router. Ihre Adressen werden autonomen Systemen zugeordnet, und zwei aufeinanderfolgende AS-Kennungen werden als Interkonnektion interpretiert. Eine feste TTL-Umschreibung kann daher eine Router- und eine AS-Verbindung erzeugen, ohne dass diese direkte Nachbarschaft im Weiterleitungsnetz existiert.

Das ist nicht dasselbe wie das bekannte ECMP-Problem. Klassische Probes können verschiedene gleichwertige Pfade nehmen und Antworten zu einer Reihenfolge zusammensetzen, die kein einzelnes Paket erlebt hat. Paris Traceroute vermindert diesen Fehler durch stabile Flow-Felder. Es bleibt jedoch darauf angewiesen, dass Geräte die TTL verkleinern. Flow-Konsistenz repariert kein unterwegs erhöhtes Feld.

950 Probes belegen das Phänomen, nicht seine weltweite Häufigkeit

Sebastian Kappes, Anja Feldmann, Tobias Fiebig und Johannes Zirngibl ließen RIPE-Atlas-Probes Ziele messen, an denen sie die ankommenden Pakete mitschneiden konnten. RIPE Labs berichtet von betroffenen Traces aus 950 Probes in 471 ASes.

Die Adressfamilien bilden keine getrennten Gruppen: 800 IPv4-Probes und 538 IPv6-Probes; 446 ASes für IPv4 und 263 für IPv6. Eine Addition würde Probes und Netze doppelt zählen, die in beiden Familien vorkommen.

Die wissenschaftliche Arbeit nennt mindestens 47 ASes, in denen sich wahrscheinlich Geräte mit pfadbeeinträchtigender TTL-Umschreibung befinden. Bei 43 war 255 der häufigste Zielwert, bei vier 64. Die Beispiele umfassen Quellnetze und Transit. RIPE Labs führt 14 betroffene Probes bei Orange AS5511 und 65 bei AT&T AS7018 an, bei denen der letzte sichtbare Hop noch im Quell-AS lag. Bei Arelion AS1299 stammen die Probes dagegen aus anderen Netzen; die Veränderung scheint beim Transit aufzutreten.

Diese Namen verorten Indizien, nicht abschließende Verantwortung. Nach der Umschreibung bleibt der weitere Pfad unbekannt. Das AS der letzten sichtbaren Adresse ist nur der wahrscheinlichste Ort; die Adresse könnte zu einem Grenzrouter gehören. Zudem fanden die Forschenden viele Pfade durch ein genanntes AS, auf denen die TTL unverändert blieb. Die Klassifikation gehört zu einem Pfad, nicht dauerhaft zu einem Unternehmen.

Auch die Messabdeckung setzt Grenzen. RIPE Atlas und CAIDA Ark verteilen Probes und Ziele nicht gleichmäßig über das Internet. Viele Atlas-Messungen werden von Nutzern angelegt und ändern sich mit der Zeit. Die kontrollierten Versuche nutzten nur eine begrenzte Zielmenge. Die Arbeit zeigt, dass der Mechanismus im Betrieb vorkommt; sie schätzt nicht den Anteil aller Internetpfade.

Die 49.600 Traces haben Datum und Nenner

Die historische Analyse verwendete die ursprüngliche TTL, die in manchen ICMP-Fehlern zitiert wird. Der RIPE-Atlas-Schnappschuss vom 10. November 2025 enthielt 204,8 Millionen Traces. Davon erhielten 2,65 Millionen einen einschlägigen ICMP-Fehler. Nur 139.600 enthielten eine zitierte TTL, die sich für den Vergleich eignete. 49.600 davon, also 35,5 Prozent dieses letzten Teilbestands, wurden als Umschreibung klassifiziert.

Nicht 35,5 Prozent aller Atlas-Traces waren betroffen. Die Quote gilt für den Teilbestand mit zitierter TTL an einem bestimmten Tag. Der Weg von 204,8 Millionen zu 139.600 beschreibt, wo entscheidender Beleg überhaupt verfügbar war.

Historische Hinweise reichen bis Februar 2018 zurück und wurden danach sichtbarer. Zugleich verändert sich die Zusammensetzung nutzergesteuerter Messungen, das ICMP-Feld ist optional und das Verfahren erkennt Erhöhungen besser als Verringerungen der TTL. Die Zeitreihe ist eine konservative Untergrenze für prüfbare Pfade, keine Bestandsaufnahme eingesetzter Geräte.

Ein CAIDA-Ark-Fall zeigt die mögliche Verzerrung eines einzelnen Standpunkts. Beim IPv6-Knoten igx2-us innerhalb von AT&T AS7018 hatten im Oktober 2025 93,4 Prozent der abgeschlossenen Traceroutes eine Länge von vier Hops. Unter einem anderen Nenner endeten 95,9 Prozent der erkannten Schleifen mit drei identischen Hops. Beide Werte gehören zu dieser Fallstudie; sie messen weder den gesamten AT&T-Verkehr noch alle Pfade des Netzes.

Zwei Beweise und drei Warnzeichen

Die fünf Indikatoren der Studie tragen nicht dieselbe Aussage.

Indikator Zulässige Aussage
Am Ziel mitgeschnittenes Paket mit höherer TTL als sämtliche gesendeten Werte Entscheidender Beleg für eine Erhöhung auf diesem Pfad
In ICMP-Fehler zitierte Ursprungssonde mit höherer TTL als sämtliche gesendeten Werte Entscheidender Beleg für eine Erhöhung auf diesem Pfad
Scheinbarer Hinweg deutlich kürzer als der geschätzte Rückweg Warnzeichen, das Paketbeleg benötigt
Gleiche Adresse antwortet auf benachbarte TTLs als scheinbare Ein-Hop-Schleife Warnzeichen, das Paketbeleg benötigt
Scheinbare Verbindung widerspricht unabhängigen Topologiedaten Warnzeichen, das Paketbeleg und vorsichtige AS-Zuordnung benötigt

Die letzten drei Kriterien sind weder notwendig noch hinreichend. Ein kurzer Pfad kann echt sein. Eine Schleife kann andere Ursachen haben. Öffentliche Routing- und Peeringdaten sind unvollständig. Aus einem Warnzeichen ein Urteil zu machen, würde den Topologiefehler auf einer anderen Ebene wiederholen.

Die beiden starken Nachweise kosten Reichweite. Für den Mitschnitt muss das Ziel kontrollierbar sein. Das ICMP-Verfahren benötigt einen brauchbaren Fehler vom Ziel oder letzten erreichbaren Gerät, der das Ursprungspaket enthält. Je höher der Beweisstandard, desto weniger Pfade lassen sich einordnen.

Ein fehlendes ittl ist kein negatives Ergebnis

Die RIPE-Atlas-Dokumentation definiert ittl als TTL des Pakets, das den ICMP-Fehler ausgelöst hat. Das Feld ist optional. RIPE Labs erläutert, dass Atlas diese innere TTL nur gelegentlich speichert. Ist sie vorhanden und höher als alle gesendeten Werte, kann sie die Umschreibung bestätigen. Fehlt sie, besitzt die nachgelagerte Auswertung diesen Vergleich nicht.

Die Abwesenheit braucht einen eigenen Zustand. ttl_rewrite=false würde zwei Aussagen vermischen: „Der verfügbare entscheidende Beleg zeigte keine Erhöhung“ und „Für dieses Ergebnis lag kein entscheidender Beleg vor“.

Ein kleiner Datensatz pro Pfad könnte unterscheiden:

  • confirmed_target_capture, wenn der Zielmitschnitt die Erhöhung beweist;
  • confirmed_quoted_ttl, wenn das ICMP-Zitat sie beweist;
  • indicator_only, wenn Form oder externe Topologie Verdacht wecken, aber nichts beweisen;
  • evidence_unavailable, wenn keine der beiden entscheidenden Methoden anwendbar ist.

Die Namen sind austauschbar, die Bedeutungen nicht. Gespeichert werden sollten Messungs- und Probe-ID, Quelle, Ziel, Adressfamilie, Protokoll, Zeitpunkt, höchste gesendete TTL, vorhandenes ittl, Entscheidungsmethode, Klassifikatorversion sowie die abgeleitete Verbindung, die beibehalten oder zurückgestellt wurde. Ein späterer Paketmitschnitt kann das Ergebnis korrigieren, ohne den früheren Beleggang zu löschen.

Die Ursache bleibt unbewiesen

Die Forschenden fanden keine zitierfähige Quelle für die Ursache und konnten das Verhalten im Labor nicht nachstellen. Zwei Betreiber gaben anonyme Erklärungen. Eine betraf doppelte MPLS-Labels und eine Implementierung, die beim Austritt die TTL des inneren Labels in das IP-Paket zurückkopierte. Die andere betraf ein Netzwerkbetriebssystem und die Abbildung einer Breitband-Gateway-Funktion im SDK eines ASIC-Herstellers.

Damit sind Implementierungsfehler plausibel, aber nicht für alle Fälle einem Hersteller oder Produkt zugeschrieben. Die Arbeit erwähnt auch die Vermutung, eine feste TTL solle Geschäftsbeziehungen verbergen, hält sie jedoch für unwahrscheinlich: Das Verhalten beeinträchtigt zugleich die Diagnose des Betreibers. Ein unsichtbares Pfadstück beweist keine verborgene Absicht.

Quellen

Die öffentliche Darstellung steht bei RIPE Labs unter When Traceroutes Lie. Methoden, Nenner, Grenzen und die AT&T-Fallstudie stammen aus der für IMC 2026 angenommenen Arbeit von Kappes, Feldmann, Fiebig und Zirngibl, TTL Jumps: Unexpected TTL Rewrites Impacting Inferences from Traceroutes, DOI 10.1145/3777912.3809149.

Das optionale Feld ist im RIPE-Atlas-Ergebnisformat, Version 5000 dokumentiert. Die Arbeit verweist für Paketmitschnitte und Traces auf DOI 10.17617/3.D5GQFG. Die Quellen liefern weder eine weltweite Häufigkeit noch eine sichere Gerätezuordnung.