TTL do pacote IP, como funciona e por que traceroute usa

TTL (Time to Live), o campo de 8 bits que conta saltos, valores padrão por SO (64 Linux, 128 Windows) e como o traceroute usa o TTL para mapear rotas.

TTL (Time to Live) é o campo de 8 bits no cabeçalho IPv4 que determina quantos roteadores um pacote pode atravessar antes de ser descartado. Peterson & Davie explicam por que o nome "Time to Live" é enganoso: na prática, não conta tempo, conta saltos (hops). Esse detalhe é a base de como o traceroute funciona. Este artigo explica o TTL campo por campo, os valores padrão por sistema operacional, por que pacotes em loop seriam problematicos, e como o traceroute explora o TTL para mapear cada roteador no caminho.

O que é o TTL do pacote IP: campo e função

O cabeçalho IPv4 tem 14 campos em 20 bytes. Um deles, no offset 8, é o campo TTL de 8 bits. Valores possíveis: 0 a 255. A função original, descrita na RFC 791 de Jon Postel (setembro 1981), era limitar o tempo de vida do pacote em segundos: cada roteador devia decrementar o TTL pela quantidade de tempo que o pacote ficou na fila.

Na prática, isso nunca funcionou como especificado. A maioria dos roteadores processava pacotes em microssegundos, muito menos que 1 segundo. O TTL virou, na prática, um contador de saltos.

"Como era raro que um pacote ficasse por 1 segundo em um roteador, e nem todos os roteadores tinham acesso a um relógio em comum, a maioria dos roteadores simplesmente decrementava o TTL em 1 quando encaminhava o pacote. Assim, ele tornou-se mais um contador de hops do que um temporizador."

Larry L. Peterson, Bruce S. Davie, Redes de computadores: uma abordagem de sistemas, 5a edição, p. 128 (Elsevier, 2013)

O IPv6 renomeou o campo. No cabeçalho IPv6 (RFC 8200), o campo equivalente chama-se "Hop Limit" (Limite de Saltos) e é explicitamente definido como contador de hops, eliminando a ambiguidade.

Valores de TTL por sistema operacional

O TTL inicial de um pacote é escolhido pelo sistema operacional do remetente. Esse valor padrão é útil para estimar quantos hops um pacote percorreu: se você recebe um pacote com TTL 119, o remetente provavelmente usou TTL inicial 128 (Windows), e o pacote passou por 9 roteadores.

Como o TTL decrementa a cada roteador

Cada roteador que encaminha um pacote IP executa três ações obrigatórias: ler o TTL do cabeçalho, decrementar em 1, e verificar se o resultado é zero. Se zero: descartar o pacote e enviar ICMP Time Exceeded de volta ao remetente. Se maior que zero: atualizar o Header Checksum (porque o TTL mudou) e encaminhar ao próximo salto.

"A mensagem TIME EXCEEDED é enviada quando um pacote é descartado porque seu contador chegou a zero. Esse evento é um sintoma de que os pacotes estão entrando em loop, de que há um enorme congestionamento ou de que estão sendo definidos valores muito baixos para o timer."

Andrew S. Tanenbaum, Redes de computadores, 4a edição, p. 346 (Campus, 2004)

ICMP Time Exceeded: o que acontece quando TTL chega a zero

Quando um roteador recebe um pacote com TTL=1 e precisa encaminhar (o que decrementaria para 0), ele descarta o pacote e envia um ICMP Type 11 (Time Exceeded) de volta ao endereço IP de origem do pacote descartado. O ICMP Time Exceeded inclui no payload os primeiros 28 bytes do pacote original (header IP + 8 bytes do payload), o que permite ao traceroute identificar a qual probe cada resposta pertence.

Como o traceroute usa o TTL para mapear a rota

O traceroute (tracert no Windows) é um dos diagnósticos de rede mais úteis. Seu funcionamento é engenhoso: em vez de usar um TTL normal, ele envia pacotes com TTL=1, TTL=2, TTL=3... e coleta os ICMP Time Exceeded de cada roteador no caminho. Teste direto no navegador com a ferramenta Traceroute deste site, sem precisar abrir terminal.

1. Traceroute envia 3 pacotes com TTL=1. O primeiro roteador os descarta e responde com ICMP Time Exceeded. O traceroute registra o IP e o tempo de resposta desse roteador (hop 1).
2. Traceroute envia 3 pacotes com TTL=2. O primeiro roteador decrementa para 1 e encaminha. O segundo roteador decrementa para 0, descarta e responde. Hop 2 mapeado.
3. O processo continua incrementando o TTL até o pacote chegar ao destino final. O destino responde com ICMP Echo Reply (Unix/Linux por padrão usa UDP com porta alta; Windows usa ICMP Echo; ambos funcionam).
4. O traceroute monta a lista de hops com IP, hostname (via DNS reverso) e RTT de cada salto.

Lendo a saída do traceroute no Brasil

Uma saída típica de traceroute de um usuário em São Paulo para um servidor nos EUA mostra hops locais (192.168.x.x, 100.64.x.x), hops do provedor (geralmente com nome como gru-b13-link.telia.com indicando GRU = Guarulhos), e hops internacionais cruzando o Atlântico ou o Pacific.

Hops com * * * não significam necessariamente falha na rota. Muitos roteadores de provedores configuram rate limiting em respostas ICMP ou bloqueiam ICMP para reduzir carga. O pacote ainda passa por eles, mas a resposta não volta. Se o traceroute termina normalmente no destino, hops intermediários com * são geralmente inofensivos.

Impacto operacional do TTL em redes corporativas

Em ambientes corporativos, o TTL tem implicações operacionais concretas além do diagnóstico com traceroute. Alguns cenários relevantes:

TTL em redes SD-WAN: Soluções SD-WAN (Software-Defined Wide Area Network) como Cisco Viptela, VMware SDWAN (Velocloud) e Fortinet SD-WAN populares em empresas brasileiras criam túneis VPN sobrepostos sobre links de internet. Nesses ambientes, o TTL real que o pacote enfrenta pode ser diferente do esperado: o túnel encapsula o pacote original, e o TTL do túnel é decrementado, não o TTL do pacote interno. O traceroute pelo túnel SD-WAN muitas vezes mostra apenas os endpoints do túnel, não os hops intermediários do ISP.

TTL e Load Balancing: Roteadores com ECMP (Equal-Cost Multi-Path) distribuem pacotes por múltiplos caminhos. Um traceroute de uma fonte para um destino pode mostrar caminhos diferentes a cada execução, porque os três probes de cada TTL podem ser distribuídos por caminhos distintos. O MTR resolve parcialmente esse problema enviando probes repetidos para o mesmo hop.

TTL em aplicações de latência crítica: Em redes financeiras de alta frequência (como as que conectam algoritmos de trading ao B3 - Bolsa de Valores de São Paulo), cada microsegundo de latência importa. Engenheiros dessas redes usam traceroutes para verificar que o caminho entre o data center do cliente e a B3 usa a rota de menor latência, sem desvios desnecessários. O TTL é a ferramenta para mapear esses caminhos e garantir que o network path é o esperado.

TTL no header IPv4: posição e relação com outros campos

O campo TTL ocupa o byte 9 (offset 8) do header IPv4, que tem 20 bytes no formato mínimo. O layout completo do header ajuda a entender como o TTL interage com outros campos de controle do IP:

Um detalhe importante: quando o roteador decrementa o TTL, ele precisa recalcular o Header Checksum. O checksum do header IP cobre todos os campos do header, incluindo o TTL. Isso adiciona processamento em cada salto, o que foi identificado como overhead desnecessário no IPv6: o IPv6 eliminou o checksum do header completamente, delegando a verificação de integridade ao TCP/UDP/ICMPv6. No IPv6, o campo equivalente ao TTL chama-se "Hop Limit" e tem a mesma função mecânica.

Como interpretar a saída do traceroute

Um traceroute do Brasil para um servidor nos EUA tipicamente mostra entre 10 e 20 hops. Aprender a ler a saída é uma habilidade prática que economiza horas de diagnóstico.

Cada linha do traceroute representa um roteador no caminho. Os três tempos (em ms) são as latências de três probes distintos enviados com o mesmo TTL. Variações entre eles indicam jitter (variação de latência). Um aumento repentino de latência em um hop específico indica que o gargalo está naquele roteador ou no link que o precede.

Traceroute de rotas típicas no Brasil

Um traceroute de São Paulo para o PTT-SP (ix.br) ou para servidores nos EUA mostra a infraestrutura de internet brasileira em ação. Analisar rotas reais é mais instrutivo que exemplos artificiais.

Rota típica de um usuário residencial Claro (AS28573) para o Google (AS15169) via PTT-SP:

A latência total de ~12ms do Brasil para o 8.8.8.8 é possível porque o Google tem servidores no PTT-SP de São Paulo, tornando o tráfego puramente nacional. Sem o IX.br e o peering Google-Claro, esse tráfego teria que ir para os EUA (latência de 150-200ms). Esse é o valor prático dos pontos de troca de tráfego como o IX.br: mantém latências baixas para serviços populares.

TTL e segurança: fingerprinting e ataques

O valor inicial do TTL revela o sistema operacional do remetente, uma técnica chamada OS fingerprinting passivo. Ferramentas como p0f e Nmap analisam o TTL de pacotes capturados para identificar o SO sem enviar nenhum probe ativo. Isso é usado tanto por defensores (inventário de ativos) quanto por atacantes (reconnaissance).

TTL como vetor de ataque: O ataque de TTL expiration injection explora roteadores que implementam ICMP Time Exceeded de forma previsível. Em redes MPLS, o valor do TTL pode ser copiado do IP para o header MPLS (modo pipe) ou decrementado a cada hop MPLS (modo uniform), o que afeta como o traceroute vê os hops internos do ISP. Provedores brasileiros tipicamente usam o modo pipe, ocultando a topologia interna do traceroute externo. Uma técnica relacionada, o TTL manipulation, é uma forma de evasão de IDS/IPS: o atacante envia um pacote "real" com TTL suficiente para chegar ao destino e um pacote "ruído" calibrado para morrer exatamente no sensor de detecção, criando uma sequência de bytes que o IDS vê como inofensiva mas o destino reconstrói como maliciosa. O ataque foi documentado em 1998 por Ptacek e Newsham no paper "Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection".

TTL na era de CDNs e nuvem: Com o uso de CDNs (Content Delivery Networks) como Cloudflare, Fastly e AWS CloudFront, os traceroutes para grandes sites frequentemente terminam em pontos de presença (PoPs) geograficamente próximos ao usuário, não nos servidores de origem. Um traceroute do Brasil para cloudflare.com geralmente termina num PoP em São Paulo ou Rio de Janeiro, com latência abaixo de 5ms. O IP retornado é do PoP da CDN, não do servidor original.

TTL no DNS: um conceito diferente com o mesmo nome

O campo TTL aparece em dois contextos de rede completamente diferentes: no header IP (contador de saltos) e nos registros DNS (tempo de vida em cache). É importante não confundir os dois.

O TTL de DNS (definido no RFC 1035) é um valor em segundos que indica por quanto tempo um registro DNS pode ser armazenado em cache por resolvers recursivos e clientes. Um registro A com TTL=3600 pode ficar em cache por 1 hora; depois disso, o resolver deve consultar o servidor autoritativo novamente. TTL de DNS afeta a propagação de mudanças: se você muda o IP de um domínio, clientes com cache antigo continuarão usando o IP velho até o TTL expirar.

Valores típicos de TTL DNS no Brasil: grandes portais como Globo.com e UOL usam TTLs de 60-300 segundos para flexibilidade em mudanças. CDNs como Cloudflare recomendam TTL de 300 segundos (5 minutos) em operação normal. Durante manutenção planejada (ex: troca de provedor de hospedagem), a prática é reduzir o TTL para 60 segundos com 24-48 horas de antecedência, fazer a mudança, e depois restaurar o TTL alto.

Ferramentas avançadas de traceroute

Além do traceroute e tracert clássicos, diversas ferramentas expandem as capacidades de mapeamento de rotas:

O MTR (Matt's Traceroute) é a ferramenta preferida para diagnóstico de qualidade de link no Brasil. Ao contrário do traceroute que faz um único sweep, o MTR envia probes continuamente e exibe latência mínima, média e máxima mais perda de pacotes em cada hop, o que permite identificar instabilidade intermitente que um traceroute simples perderia.

"O campo TTL do IP foi renomeado de 'tempo de vida' para 'contador de saltos' no IPv6, refletindo com mais precisão sua função real. Ele não conta segundos, mas sim o número de roteadores pelos quais o pacote passou."

Larry L. Peterson e Bruce S. Davie, Redes de computadores: uma abordagem de sistemas, 5a edição, p. 128 (Elsevier, 2013)

Perguntas frequentes sobre TTL do pacote IP

Leituras Relacionadas

• TCP/IP vs OSI, a diferença entre os dois modelos de redes -- TCP/IP tem 4 camadas, OSI tem 7. Compare os modelos, veja o mapeamento de protocolos reais (IP, TCP, Ethernet, BGP) e por que o OSI não dominou na prática.
• ARP, como dispositivos descobrem MAC na rede local -- ARP (Address Resolution Protocol), request broadcast e reply unicast, cache ARP, gratuitous e proxy ARP, ARP spoofing e o comando arp -a no Windows e Linux.
• RFC, o que são os padrões que governam a internet -- RFC (Request for Comments), os documentos tecnicos do IETF, o RFC 1 de 1969, Jon Postel e Vint Cerf e os 10 RFCs que todo profissional de redes conhece.