Résumé

  • En remplaçant le TTL d'une sonde par une valeur statique élevée, le plus souvent 255 dans l'étude, un équipement peut masquer toute la fin du trajet. La destination semble alors voisine du dernier routeur ou AS visible, alors que d'autres réseaux ont transporté le paquet entre les deux.
  • Les chercheurs ont observé des traces touchées depuis 950 sondes RIPE Atlas réparties dans 471 AS et ont identifié au moins 47 AS probablement associés aux réécritures. Ces nombres portent sur un dispositif de mesure délimité; les sous-totaux IPv4 et IPv6 se recouvrent.
  • Une capture à la destination ou le TTL original cité dans une erreur ICMP peut prouver une hausse. La longueur apparente du trajet, une boucle d'un saut ou des connaissances topologiques ne sont que des indices. Dans RIPE Atlas, ittl est facultatif: son absence signifie preuve indisponible, et non absence de réécriture.

Les routeurs n'ont pas disparu, leur expiration oui

Traceroute dépend d'une suite de petites expirations. Une sonde part avec un TTL limité. Chaque routeur le réduit. Celui qui atteint zéro détruit le paquet et peut renvoyer ICMP Time Exceeded. La sonde suivante reçoit un TTL initial plus grand et révèle normalement le saut d'après.

Un équipement qui remplace le TTL restant par 255 rompt cette progression. Le routeur suivant voit 254, puis les suivants 253, 252 et 251. Aucun n'est obligé de produire le message d'expiration attendu. Si la destination répond, elle apparaît immédiatement après le dernier saut observé avant la réécriture.

Le paquet, lui, a toujours traversé le segment caché. C'est la liste qui l'a effacé.

Cette nuance devient une erreur structurelle lorsqu'un traitement transforme la trace en topologie. Deux réponses consécutives sont souvent interprétées comme deux routeurs adjacents. Leurs adresses sont rattachées à des systèmes autonomes; deux étiquettes AS consécutives deviennent alors une interconnexion supposée. La réécriture peut donc fabriquer une liaison entre routeurs, puis entre AS, sans que le réseau de transmission contienne cette liaison directe.

Le phénomène ne se réduit pas au multipath ECMP. Des sondes classiques peuvent suivre des chemins différents et composer un ordre qu'aucun paquet n'a emprunté. Paris traceroute corrige une partie de ce biais en stabilisant les champs utilisés pour choisir le chemin. Mais il repose toujours sur la diminution du TTL. Maintenir le même flux ne sert à rien face à un équipement qui relève ce champ.

950 sondes constituent une alerte, pas une mesure de l'Internet entier

Sebastian Kappes, Anja Feldmann, Tobias Fiebig et Johannes Zirngibl ont lancé des mesures depuis RIPE Atlas vers des destinations où ils pouvaient capturer les sondes à l'arrivée. Le compte rendu de RIPE Labs fait état de traces affectées depuis 950 sondes situées dans 471 AS.

Les détails par famille d'adresses ne forment pas deux populations disjointes: 800 sondes IPv4 et 538 sondes IPv6; 446 AS en IPv4 et 263 en IPv6. Additionner ces valeurs compterait certains éléments deux fois.

L'article scientifique retient au moins 47 AS dans lesquels se trouvent vraisemblablement des équipements responsables de réécritures perturbant le trajet. Pour 43, la valeur la plus courante est 255; pour quatre, 64. Les exemples comprennent des situations proches de la source et d'autres en transit. RIPE Labs mentionne 14 sondes affectées chez Orange AS5511 et 65 chez AT&T AS7018 alors que le dernier saut visible reste dans l'AS source. Pour Arelion AS1299, les traces viennent de plusieurs autres réseaux et semblent subir la réécriture en transit.

Ces attributions restent prudentes. Une fois le trajet masqué, l'AS de la dernière adresse visible n'est que le lieu le plus probable. L'adresse peut appartenir à un routeur frontalier. Surtout, l'étude trouve aussi des trajets non réécrits qui passent par des AS impliqués. La propriété appartient à un trajet observé, pas à une organisation pour toujours.

La distribution des sondes et des cibles limite également la portée. Les mesures RIPE Atlas initiées par les utilisateurs varient dans le temps. CAIDA Ark a une autre couverture. Les balayages contrôlés n'ont utilisé qu'un ensemble limité de destinations. Le travail établit l'existence opérationnelle du mécanisme; il ne calcule pas la part de tous les chemins Internet concernés.

Les 49 600 traces d'une journée ne représentent pas 35,5 % d'Atlas

L'analyse historique utilise le TTL de la sonde originale cité dans certaines erreurs ICMP. Pour la photographie RIPE Atlas du 10 novembre 2025, le point de départ est de 204,8 millions de traces. Parmi elles, 2,65 millions ont reçu une erreur ICMP pertinente. Seulement 139 600 contenaient un TTL cité exploitable. Le test a détecté 49 600 réécritures dans ce dernier sous-ensemble, soit 35,5 %.

Le dénominateur protège l'interprétation. Il serait faux d'écrire que 35,5 % de toutes les traces Atlas ont été réécrites. Ce taux concerne les traces dotées d'un TTL cité dans un instantané daté. Le passage de 204,8 millions à 139 600 décrit précisément la disponibilité de la preuve décisive.

Les archives font apparaître des indices dès février 2018 et une visibilité croissante par la suite. Mais le nombre et la nature des mesures changent, le champ d'erreur est facultatif et la méthode repère mieux les augmentations que les diminutions de TTL. La série fournit une borne basse sur les chemins contrôlables, pas un inventaire de déploiement.

Un cas CAIDA Ark illustre l'effet possible sur un point d'observation. Depuis le nœud IPv6 igx2-us situé dans AT&T AS7018, 93,4 % des traceroutes achevés en octobre 2025 avaient une longueur de quatre sauts. Dans un autre dénominateur, 95,9 % des boucles identifiées se terminaient par trois sauts identiques. Ces taux ne décrivent ni le trafic d'AT&T ni tous ses chemins.

Deux preuves et trois signaux

L'étude réunit cinq indicateurs dont la force n'est pas la même.

Indicateur Portée probante
Paquet capturé à la destination avec un TTL supérieur à toutes les valeurs émises Preuve décisive d'une hausse sur ce trajet
Sonde originale citée dans une erreur ICMP avec un TTL supérieur à toutes les valeurs émises Preuve décisive d'une hausse sur ce trajet
Trajet aller apparemment beaucoup plus court que le retour estimé Signal à corroborer par le paquet
Même adresse répondant à deux TTL voisins, sous forme de boucle d'un saut Signal à corroborer par le paquet
Liaison apparente contraire à des données topologiques indépendantes Signal à corroborer et à soumettre à une attribution AS prudente

Les trois derniers critères ne sont ni nécessaires ni suffisants. Un trajet court peut être réel. Une boucle peut avoir une autre origine. Les données publiques de routage et de peering sont incomplètes. Employer ces indices comme verdict ne ferait que déplacer l'invention topologique.

Les deux preuves fermes ont un prix de couverture. Il faut contrôler la destination pour capturer l'arrivée. La méthode ICMP exige que la destination ou le dernier nœud accessible envoie une erreur contenant la sonde originale. Plus on demande une preuve robuste, plus le nombre de chemins exploitables diminue.

ittl facultatif: une limite, pas un zéro

La documentation de RIPE Atlas définit ittl comme le TTL du paquet ayant déclenché l'erreur ICMP. Le champ est facultatif. RIPE Labs précise qu'Atlas ne conserve ce TTL interne que dans certains résultats. Présent et supérieur à toutes les valeurs émises, il peut confirmer la réécriture. Absent, il prive le traitement de cette comparaison.

Il faut donc conserver une catégorie d'indisponibilité. Encoder l'absence par false confondrait deux propositions: «la preuve décisive ne montre pas de hausse» et «la preuve décisive n'existe pas dans ce résultat».

Un enregistrement léger par trajet peut distinguer:

  • confirmed_target_capture, lorsque la capture d'arrivée prouve la hausse;
  • confirmed_quoted_ttl, lorsque la citation ICMP la prouve;
  • indicator_only, lorsqu'une forme suspecte existe sans preuve de paquet;
  • evidence_unavailable, lorsque les deux méthodes décisives sont impossibles.

Les noms peuvent changer, pas la séparation. Il faut garder l'identifiant de mesure et de sonde, la source, la cible, la famille d'adresses, le protocole, l'horodatage, le TTL maximal émis, ittl s'il existe, la méthode de décision, la version du classificateur et le sort réservé à la liaison dérivée. Une preuve ultérieure peut ainsi corriger la conclusion sans effacer son histoire.

La cause ne figure pas dans le verdict

Les auteurs n'ont trouvé aucune source publiable établissant la cause et n'ont pas réussi à reproduire le phénomène en laboratoire. Deux opérateurs ont fourni des explications anonymes. La première concerne un double étiquetage MPLS et la recopie du TTL de l'étiquette interne vers le paquet IP. La seconde concerne un système d'exploitation réseau et le mappage d'une fonction de passerelle d'accès dans le SDK d'un ASIC.

Ces récits rendent une erreur d'implémentation plausible. Ils ne désignent pas un fournisseur commun à tous les cas. Une hypothèse de dissimulation des relations commerciales est aussi rapportée, puis jugée peu probable, puisque la réécriture dégrade les propres outils de diagnostic de l'opérateur. Un saut caché n'est pas une intention cachée.

Sources

La présentation publique est l'article de RIPE Labs When Traceroutes Lie. Les méthodes, dénominateurs, limites et l'étude de cas AT&T viennent de l'article IMC 2026 de Kappes, Feldmann, Fiebig et Zirngibl, TTL Jumps: Unexpected TTL Rewrites Impacting Inferences from Traceroutes, DOI 10.1145/3777912.3809149.

Le champ facultatif figure dans le format des résultats RIPE Atlas, version 5000. Le papier renvoie aux captures et traces ouvertes par le DOI 10.17617/3.D5GQFG. Ces sources ne donnent ni prévalence mondiale ni attribution certaine à un équipement.