Resumo

  • A opção Tipo 68 da RFC 791 permitia que módulos IP acrescentassem um horário, com registro opcional de endereços; o contador de overflow de quatro bits contava os módulos sem espaço para escrever.
  • Como os relógios podiam não estar sincronizados e o registro era limitado, a opção reunia observações parciais de processamento, não uma medição confiável de atraso ponta a ponta.

Um horário dentro do datagrama

A RFC 791 definiu a opção Internet Timestamp, Tipo 68. O emissor reservava espaço no cabeçalho IP; cada módulo IP participante podia registrar um horário ao processar o datagrama. O valor de 32 bits contava milissegundos desde a meia-noite UT. Se UT ou um relógio baseado em UT não estivesse disponível, o bit mais significativo marcava o valor como não padronizado.

As flags determinavam o conteúdo de cada posição. A flag 0 guardava somente o horário. A flag 1 associava um endereço a cada horário. A flag 3 trazia endereços predefinidos, e o módulo só acrescentava um horário quando seu endereço correspondia ao próximo da lista. O ponteiro indicava a próxima posição. O comprimento máximo era de 40 octetos; por isso, o emissor precisava decidir quanto espaço do cabeçalho dedicaria ao registro.

Esse limite define o significado específico do campo de overflow. Seus quatro bits contavam os módulos IP que encontravam a opção cheia e não podiam adicionar um horário. Sem espaço, o módulo encaminhava o pacote e incrementava o contador. Mas, se ainda houvesse espaço insuficiente para um registro completo, ou se o próprio contador ultrapassasse seu limite, a RFC 791 considerava o datagrama errôneo e permitia uma mensagem ICMP Parameter Problem. O campo não identificava qual roteador faltou nem por quê.

A especificação também restringia o transporte: a opção não era copiada para os fragmentos e podia aparecer apenas uma vez. Portanto, não se podia presumir que cada fragmento carregasse um histórico completo da rota.

Observações, não tempo decorrido

Uma sequência de horários pode parecer uma trilha de latência. A RFC 791 não garantia relógios sincronizados ou precisos, participação de todos os roteadores, nem uma lista completa dos saltos. Cada valor refletia o relógio do módulo que o registrou. Subtrair dois valores pode misturar diferenças entre relógios e o tempo real de trânsito. A leitura defensável é mais estreita: o pacote podia carregar um conjunto limitado de observações de endereço e horário, além de um contador de overflow.

Os requisitos posteriores para hosts confirmaram o caráter opcional. A RFC 1122 tornou opcionais tanto a geração quanto o processamento da opção Timestamp. A especificação definia um formato e um comportamento, mas não comprovava que hosts ou roteadores o adotaram.

Em 2014, a RFC 7126 descreveu riscos como revelar os relógios dos equipamentos, permitir inferências de topologia e ajudar na identificação de dispositivos. Ela afirmou que o descarte disseminado tornava essas técnicas quase impossíveis, em sua avaliação, e recomendou que roteadores, gateways de segurança e firewalls DEVERIAM descartar pacotes que contivessem a opção. Isso é a caracterização e a recomendação da RFC, não uma medição atual de todas as redes.

A opção revela um limite da observabilidade: um registro dentro do pacote pode oferecer pistas úteis e ainda ser incompleto, depender de relógios e consumir espaço escasso do cabeçalho. O formato mostra o que um módulo participante podia gravar; a ausência de um registro não prova que nenhum salto ocorreu.

Fontes