Resumen

  • Un equipo que sustituye el TTL de una sonda por un valor estático alto —255 en la mayoría de los casos del nuevo estudio— puede ocultar el resto de la ruta. El destino parece vecino del último router o AS visible aunque otras redes transportaron el paquete entre ambos.
  • Los investigadores hallaron trazas afectadas desde 950 sondas de RIPE Atlas en 471 AS e identificaron al menos 47 AS probablemente asociados a reescrituras. Son observaciones acotadas, no una tasa de prevalencia de Internet; los subtotales de IPv4 e IPv6 se solapan.
  • La captura del paquete en el destino y el TTL original citado por un error ICMP pueden demostrar un incremento. La longitud de la ruta, un bucle aparente de un salto y el conocimiento topológico solo alertan. RIPE Atlas guarda ese TTL interno como ittl opcional: si falta, falta la prueba; no queda demostrada la ausencia de reescritura.

El paquete siguió; la ruta visible se detuvo

Traceroute crea una sucesión de expiraciones. Cada sonda sale con un TTL limitado y cada router lo reduce. Cuando llega a cero, el equipo descarta el paquete y puede contestar con ICMP Time Exceeded. La sonda siguiente recibe un TTL inicial mayor y, en condiciones normales, revela un salto más.

Un dispositivo que reemplaza el valor restante por 255 rompe esa secuencia. El router siguiente recibe 254; los posteriores ven 253, 252 y 251. Ninguno tiene que producir el mensaje de expiración que traceroute esperaba. Si el destino responde, puede aparecer como la línea inmediatamente posterior al último equipo visto antes de la reescritura.

Los routers intermedios no dejaron de reenviar. Desaparecieron del registro.

El problema adquiere otra escala cuando ese registro se convierte en topología. Dos respuestas consecutivas suelen tomarse como routers consecutivos. Después se asigna cada dirección a un sistema autónomo y dos etiquetas AS consecutivas pasan a ser una interconexión inferida. Una reescritura estática puede fabricar así un enlace de routers y otro de AS sin que exista esa adyacencia directa en la red de reenvío.

No es la misma anomalía que el balanceo ECMP. Las sondas clásicas pueden elegir rutas distintas y mezclar interfaces que ningún paquete recorrió en ese orden. Paris traceroute reduce ese error estabilizando los campos del flujo. Aun así, depende de que los equipos reduzcan el TTL. La coherencia del flujo no corrige un campo elevado durante el trayecto.

950 sondas prueban el mecanismo, no su frecuencia mundial

Sebastian Kappes, Anja Feldmann, Tobias Fiebig y Johannes Zirngibl enviaron mediciones desde RIPE Atlas hacia destinos donde podían capturar las sondas recibidas. RIPE Labs informa de trazas afectadas desde 950 sondas ubicadas en 471 AS.

Los detalles por familia no son grupos separados: 800 sondas IPv4 y 538 IPv6; 446 AS en IPv4 y 263 en IPv6. La suma duplicaría sondas y redes que participaron con ambas familias.

El artículo académico identifica al menos 47 AS probablemente vinculados con equipos que alteran la ruta visible. En 43, el valor más común fue 255; en cuatro, 64. Hubo ejemplos cercanos a la fuente y en tránsito. RIPE Labs registra 14 sondas afectadas en Orange AS5511 y 65 en AT&T AS7018 con el último salto visible aún dentro del AS de origen. También describe trazas procedentes de otras redes que resultan alteradas después de atravesar Arelion AS1299.

Los nombres señalan dónde apareció la evidencia, no quién es culpable. Tras una reescritura se desconoce la continuación del camino. El AS de la última dirección visible es el lugar más probable, pero podría tratarse de un router fronterizo. El estudio, además, encontró muchas rutas que atravesaron un AS implicado sin cambiar el TTL. La clasificación corresponde a cada ruta, no a toda una red.

La cobertura tiene límites. Las sondas y los destinos de RIPE Atlas y CAIDA Ark no representan uniformemente Internet. Muchas mediciones de Atlas las crean usuarios y cambian con el tiempo. Los experimentos controlados usaron un conjunto limitado de destinos. El resultado demuestra una interferencia real a escala operativa; no calcula qué proporción de todas las rutas la sufre.

Las 49.600 trazas tienen fecha y denominador

El análisis histórico se apoyó en el TTL de la sonda original incluido en ciertos errores ICMP. En la instantánea de RIPE Atlas del 10 de noviembre de 2025 había 204,8 millones de trazas. De ellas, 2,65 millones recibieron un error ICMP relevante. Solo 139.600 contenían un TTL citado apto para la comparación. El método clasificó 49.600 como reescritas: el 35,5% de ese último subconjunto.

No fue el 35,5% de todas las trazas de Atlas. Fue el 35,5% de los resultados con TTL citado en una instantánea concreta. La reducción desde 204,8 millones hasta 139.600 no es un detalle estadístico: mide el espacio donde existía evidencia decisiva.

Las señales históricas llegan al menos hasta febrero de 2018 y aumentan con el tiempo. Pero también cambia la población de mediciones, el campo ICMP es opcional y la técnica detecta mejor aumentos que descensos del TTL. La serie es un límite inferior sobre rutas observables, no un censo de configuraciones.

Un caso de CAIDA Ark muestra la intensidad posible en un punto de observación. En octubre de 2025, desde el nodo IPv6 igx2-us dentro de AT&T AS7018, el 93,4% de las trazas completadas tenía cuatro saltos. Por separado, el 95,9% de los bucles identificados terminaba con tres saltos idénticos. Son denominadores distintos dentro de un caso; no describen todo el tráfico ni todos los caminos de AT&T.

Dos pruebas y tres avisos

Los cinco indicadores del estudio no tienen la misma autoridad.

Indicador Alcance de la conclusión
Paquete capturado en el destino con TTL superior a todo lo enviado Prueba decisiva de un incremento en esa ruta
Sonda original citada en un error ICMP con TTL superior a todo lo enviado Prueba decisiva de un incremento en esa ruta
Trayecto de ida mucho más corto que la estimación de vuelta Aviso que necesita evidencia del paquete
Misma dirección contestando a TTL adyacentes como bucle de un salto Aviso que necesita evidencia del paquete
Enlace aparente en conflicto con topología independiente Aviso que necesita evidencia del paquete y atribución AS prudente

Los tres últimos no son condiciones necesarias ni suficientes. Una ruta corta puede ser auténtica. Un bucle puede tener otra causa. Los datos de encaminamiento y peering están incompletos. Convertir una advertencia en veredicto repetiría el error de topología con otra herramienta.

Las dos pruebas firmes reducen cobertura. Para capturar llegadas hace falta controlar el destino. La vía ICMP requiere que el destino o el último nodo alcanzable envíe un error útil con la sonda original. Aumentar la exigencia probatoria disminuye el número de rutas clasificables.

ittl opcional no equivale a false

La documentación de RIPE Atlas define ittl como el TTL del paquete que provocó el error ICMP. Es un campo opcional. RIPE Labs explica que Atlas conserva ese TTL interno solo en algunos resultados. Si aparece y supera todos los TTL enviados, puede confirmar la reescritura. Si no aparece, el proceso posterior carece de ese dato decisivo.

La ausencia necesita un estado propio. Guardarla como false fusionaría dos afirmaciones: “la prueba disponible no mostró un incremento” y “no había prueba disponible para comprobarlo”.

Un registro mínimo por ruta podría separar:

  • confirmed_target_capture, si la captura de llegada demuestra el aumento;
  • confirmed_quoted_ttl, si lo demuestra la cita ICMP;
  • indicator_only, si la forma o la topología externa levantan una sospecha sin prueba;
  • evidence_unavailable, si no puede aplicarse ninguno de los dos métodos decisivos.

Las etiquetas son intercambiables; los significados no. Conviene conservar el identificador de medición y sonda, origen, destino, familia, protocolo, fecha, TTL máximo enviado, ittl observado, método de decisión, versión del clasificador y el enlace derivado que se aceptó o retiró. Una nueva captura puede corregir el resultado sin borrar el recibo anterior.

La causa no está demostrada

Los autores no encontraron una fuente citable que estableciera la causa y no consiguieron reproducirla en el laboratorio. Dos operadores dieron explicaciones anónimas. Una se refería a doble etiquetado MPLS y a copiar el TTL de la etiqueta interior al paquete IP. La otra, a un sistema operativo de red y al mapeo de una función de gateway de banda ancha en el SDK de un ASIC.

Son indicios compatibles con fallos de implementación, no una atribución común a todos los casos. El trabajo también recoge la conjetura de que fijar el TTL ocultaría relaciones comerciales, pero la considera improbable: la misma conducta perjudica las herramientas de diagnóstico del operador. Una parte invisible de la ruta no demuestra un motivo secreto.

Fuentes

La explicación pública está en RIPE Labs: When Traceroutes Lie. Los métodos, denominadores, límites y el caso AT&T proceden del artículo aceptado para IMC 2026 de Kappes, Feldmann, Fiebig y Zirngibl, TTL Jumps: Unexpected TTL Rewrites Impacting Inferences from Traceroutes, DOI 10.1145/3777912.3809149.

El campo opcional aparece en el formato de resultados de RIPE Atlas, versión 5000. El artículo identifica sus capturas y trazas abiertas mediante el DOI 10.17617/3.D5GQFG. Ninguna fuente ofrece una tasa mundial ni una atribución definitiva a equipos concretos.