Resumo

  • Um equipamento que troca o TTL da sonda por um valor estático alto — 255 na maior parte dos casos do novo estudo — consegue ocultar o restante do caminho. O destino passa a parecer vizinho do último roteador ou AS visível, embora outras redes tenham transportado o pacote entre eles.
  • Os pesquisadores encontraram traceroutes afetados provenientes de 950 sondas do RIPE Atlas em 471 ASes e apontaram pelo menos 47 ASes como locais prováveis de reescrita. São medições delimitadas, não uma taxa para toda a Internet; os números de IPv4 e IPv6 se sobrepõem.
  • Capturar a sonda no destino e ler o TTL original citado em um erro ICMP pode provar o aumento. Comprimento aparente, loop de um salto e conhecimento de topologia apenas sinalizam. No RIPE Atlas, o TTL interno aparece no campo opcional ittl; se ele não existe, a evidência está indisponível — não há prova de que a reescrita não ocorreu.

O pacote continuou; o caminho visível parou

Traceroute constrói o caminho provocando uma sequência de expirações. A sonda sai com TTL limitado e cada roteador reduz o valor. Quando ele chega a zero, o equipamento descarta o pacote e pode devolver ICMP Time Exceeded. A próxima sonda ganha um TTL inicial maior e, em condições normais, revela o salto seguinte.

Um dispositivo que substitui o valor restante por 255 rompe essa sequência. O próximo roteador recebe 254; os posteriores veem 253, 252 e 251. Nenhum deles encontra zero, portanto nenhum precisa emitir a mensagem que o traceroute espera. Se o destino responder, ele pode surgir na linha imediatamente posterior ao último equipamento visto antes da reescrita.

Os roteadores ocultos fizeram o trabalho. Foi o registro que os apagou.

Quando esse registro alimenta uma topologia, a lacuna vira uma relação falsa. Respostas consecutivas costumam ser tratadas como roteadores adjacentes. Em seguida, endereços são associados a sistemas autônomos, e dois rótulos AS consecutivos passam a representar uma interconexão inferida. Uma reescrita estática pode fabricar um enlace entre roteadores e outro entre ASes sem criar nenhuma adjacência direta na rede que encaminhou o pacote.

O mecanismo é diferente do conhecido problema de ECMP. Sondas tradicionais podem seguir rotas de custo igual distintas e compor uma sequência pela qual nenhum pacote passou. Paris traceroute reduz esse erro mantendo estáveis os campos usados na escolha de fluxo. Ainda assim, ele depende da redução do TTL. Coerência de fluxo não corrige um campo aumentado em trânsito.

Novecentas e cinquenta sondas provam existência, não prevalência mundial

Sebastian Kappes, Anja Feldmann, Tobias Fiebig e Johannes Zirngibl realizaram medições de sondas do RIPE Atlas até destinos onde podiam capturar os pacotes na chegada. O relato do RIPE Labs registra traceroutes afetados provenientes de 950 sondas instaladas em 471 ASes.

Os recortes por família de endereços não são grupos exclusivos: são 800 sondas IPv4 e 538 IPv6; 446 ASes em IPv4 e 263 em IPv6. Somar cada par contaria novamente sondas e redes presentes nas duas famílias.

O artigo científico identifica pelo menos 47 ASes provavelmente ligados a equipamentos que prejudicam o caminho visível. Em 43, o valor mais comum foi 255; em quatro, 64. Há exemplos no AS de origem e em trânsito. O RIPE Labs cita 14 sondas afetadas na Orange AS5511 e 65 na AT&T AS7018 enquanto o último salto visível ainda estava dentro do AS de origem. Também há traceroutes de outras redes que parecem sofrer a mudança depois de atravessar a Arelion AS1299.

Esses nomes localizam indícios; não encerram a atribuição. Depois da reescrita, o restante do caminho fica desconhecido. O AS do último endereço visível é o local mais provável, mas o endereço pode pertencer a um roteador de borda. O estudo também encontrou muitos caminhos que atravessavam um AS implicado sem alterar o TTL. A classificação pertence ao caminho, não à organização inteira.

As plataformas têm distribuições próprias de sondas e destinos. Muitas medições do Atlas são criadas por usuários e mudam ao longo do tempo. Os testes controlados usaram um conjunto restrito de destinos. O resultado demonstra uma interferência real em escala operacional; não estima a parcela de todos os caminhos da Internet que passa por ela.

As 49,6 mil ocorrências têm data e denominador

A análise histórica usou o TTL da sonda original preservado em alguns erros ICMP. No retrato do RIPE Atlas de 10 de novembro de 2025, havia 204,8 milhões de traceroutes. Desses, 2,65 milhões receberam um erro ICMP pertinente. Apenas 139,6 mil traziam um TTL citado que permitia a comparação. O método classificou 49,6 mil reescritas, ou 35,5% desse último subconjunto.

Não se trata de 35,5% de todos os traceroutes do Atlas. O percentual vale para resultados com TTL citado em um retrato datado. A redução de 204,8 milhões para 139,6 mil é parte central da descoberta: ela mostra onde a evidência decisiva existia.

Os registros históricos revelam sinais desde fevereiro de 2018, com maior visibilidade depois. Mas a população de medições muda, o campo ICMP é opcional e o teste detecta melhor aumentos do que reduções do TTL. A série oferece um limite inferior para caminhos examináveis, não um censo de implantação de equipamentos.

Um caso da CAIDA Ark mostra o tamanho da distorção possível em um ponto de observação. No nó IPv6 igx2-us dentro da AT&T AS7018, 93,4% dos traceroutes concluídos em outubro de 2025 tinham quatro saltos. Em outro denominador, 95,9% dos loops identificados terminavam com três saltos idênticos. Os percentuais pertencem a um estudo de caso; não medem todo o tráfego ou todos os caminhos da AT&T.

Duas provas e três alertas

Os cinco indicadores do artigo não autorizam a mesma conclusão.

Indicador Conclusão permitida
Pacote capturado no destino com TTL maior que todos os valores enviados Prova decisiva de aumento naquele caminho
Sonda original citada em erro ICMP com TTL maior que todos os valores enviados Prova decisiva de aumento naquele caminho
Ida aparentemente muito menor que o caminho de volta estimado Alerta que requer evidência do pacote
Mesmo endereço responde a TTLs adjacentes como loop de um salto Alerta que requer evidência do pacote
Enlace aparente contradiz dados independentes de topologia Alerta que requer evidência do pacote e atribuição AS cautelosa

Os três últimos critérios não são necessários nem suficientes. Um caminho curto pode ser verdadeiro. Um loop pode ter outra causa. Informações públicas de roteamento e peering são incompletas. Transformar um alerta em sentença repetiria o erro topológico em outra camada.

As duas provas fortes diminuem o universo observável. Capturar a chegada exige controle do destino. O método ICMP depende de o destino ou o último nó alcançável devolver um erro aproveitável com a sonda original. Quanto maior a exigência, menor o número de caminhos classificáveis.

ittl opcional precisa de um estado próprio

A documentação do RIPE Atlas define ittl como o TTL do pacote que provocou o erro ICMP. O campo é opcional. O RIPE Labs explica que o Atlas guarda esse TTL interno apenas em parte dos resultados. Quando ele existe e supera todos os TTLs enviados, pode confirmar a reescrita. Quando não existe, o processo posterior perde a comparação decisiva.

Ausência não deve virar false. Isso juntaria duas afirmações diferentes: “a evidência decisiva disponível não mostrou aumento” e “não havia evidência decisiva nesse resultado”.

Um registro pequeno por caminho pode separar:

  • confirmed_target_capture, se a captura na chegada comprovar o aumento;
  • confirmed_quoted_ttl, se a citação ICMP comprovar;
  • indicator_only, se formato ou topologia externa levantarem suspeita sem prova;
  • evidence_unavailable, se nenhum dos métodos decisivos puder ser usado.

Os nomes podem variar; a separação semântica não. O registro deve guardar IDs de medição e sonda, origem, destino, família, protocolo, horário, maior TTL enviado, ittl observado quando houver, método, versão do classificador e o enlace derivado que foi mantido ou retirado. Uma captura posterior pode corrigir o resultado sem apagar o recibo anterior.

A causa continua fora da prova

Os autores não encontraram uma fonte citável para a causa e não conseguiram reproduzir o comportamento em laboratório. Dois operadores deram explicações anônimas. Uma envolve dupla rotulagem MPLS e uma implementação que copia o TTL do rótulo interno de volta ao pacote IP. A outra envolve um sistema operacional de rede e o mapeamento de uma função de gateway de banda larga no SDK do fabricante do ASIC.

Os relatos tornam defeitos de implementação plausíveis, mas não atribuem todos os casos a um fornecedor ou produto. O estudo também registra a hipótese de que fixar o TTL esconderia relações comerciais e a considera improvável, pois isso prejudicaria o diagnóstico do próprio operador. Um trecho invisível não prova uma intenção escondida.

Fontes

A apresentação pública está no RIPE Labs, When Traceroutes Lie. Métodos, denominadores, limitações e o caso AT&T vêm do artigo de Kappes, Feldmann, Fiebig e Zirngibl aceito para a IMC 2026, TTL Jumps: Unexpected TTL Rewrites Impacting Inferences from Traceroutes, DOI 10.1145/3777912.3809149.

O campo opcional está no formato de resultados do RIPE Atlas, versão 5000. O artigo aponta os pacotes capturados e traceroutes abertos no DOI 10.17617/3.D5GQFG. As fontes não oferecem prevalência mundial nem atribuição definitiva a equipamentos.