Resumo

  • A opção IPv4 de tipo 68 criava um registro finito dentro do pacote para timestamps isolados ou pares de endereço e timestamp.
  • A cooperação permaneceu nas normas de hosts e roteadores, mas relógios dessincronizados, registros não autenticados, exposição de informações e filtragem reduziram sua utilidade.

Um espaço que acabava à vista de todos

O Internet Timestamp de RFC 791 não era um horário preenchido apenas na origem. O remetente reservava uma área mutável e sistemas ao longo do caminho podiam acrescentar observações. O tipo era 68. Como o copy bit valia zero, a opção ficava somente no primeiro fragmento; também não podia aparecer mais de uma vez no mesmo datagrama.

O formato deixava a escassez explícita. O comprimento total tinha limite de 40 octetos. Um ponteiro, com valor mínimo válido igual a 5, indicava a próxima posição. Quatro bits mantinham um contador de overflow, enquanto outros quatro escolhiam o modo. Sem espaço, o participante incrementava o contador em vez de escrever além da opção. Comprimento ou ponteiro inválido, ou overflow do próprio contador, tornava o datagrama errado: ele era descartado e podia provocar um ICMP Parameter Problem.

No modo 0, eram inseridos timestamps consecutivos de 32 bits. No modo 1, cada equipamento registrava primeiro seu endereço Internet e depois a hora. No modo 3, endereços já vinham indicados, e o equipamento escrevia somente quando o próximo endereço correspondia a ele. A referência preferida era o número de milissegundos desde a meia-noite em tempo universal. Quem não dispusesse desse relógio podia usar outra referência, desde que marcasse o bit mais alto para declarar o valor não padrão.

O registro era, portanto, um testemunho limitado de participação. Não autenticava quem escreveu, não obrigava todos os saltos a colaborar e não acrescentava uma data. Em modos com endereço, os 40 octetos se esgotavam ainda mais depressa. Mesmo entradas honestas não permitiam comparar relógios que não estivessem sincronizados.

Hosts podiam escolher; roteadores deviam compreender

RFC 1122 tornou opcionais para hosts tanto a criação quanto o processamento da opção. Se implementada, porém, a origem tinha de inserir sua própria hora quando o modo permitisse; o destino devia, se possível, acrescentar a hora corrente antes de entregar a opção à camada superior. Permanecia a preferência por milissegundos desde a meia-noite UT e a obrigação de marcar valores não padrão.

RFC 1812 exigiu que roteadores suportassem o Timestamp em pacotes encaminhados. No modo 3, o próximo endereço predefinido podia corresponder a qualquer endereço do roteador, e não necessariamente à interface de entrada ou saída. Era permitido oferecer uma chave para deixar inalterados os modos 0 e 1, mas ela deveria vir desligada. O texto também reconhecia que anotar perto da chegada aumentava a utilidade e que relógios sem sincronização a limitavam.

A informação de diagnóstico mudou de destinatário

RFC 7126 observou que tempos de processamento e endereços ajudam a investigar falhas, mas também expõem topologia, hora dos sistemas e características de implementação. Desvios de relógio poderiam até contribuir para identificar dispositivos físicos. O pacote que pedia transparência ao caminho não controlava quem aprenderia com a resposta.

Na prática, qualquer limite que descartasse opções IPv4 quebrava a técnica. O ping comum continuava sem elas. Diante de uma filtragem já disseminada, RFC 7126 considerou esses usos do Timestamp praticamente inviáveis e recomendou que roteadores, gateways de segurança e firewalls descartassem os pacotes que o contivessem.

Fontes