Resumo

  • Data Offset define o limite físico do cabeçalho; EOL encerra a lista significativa antes dele.
  • NOP pode ajustar o início da opção seguinte, mas o receptor deve aceitar opções desalinhadas.

Um percurso pelo cabeçalho

O receptor avança octeto por octeto. Kind 1, NOP, consome um octeto. Uma opção comum fornece tipo, tamanho e dados; o tamanho inclui os dois primeiros campos e permite saltar a opção inteira, mesmo quando seu significado é desconhecido. Kind 0, EOL, encerra a interpretação das opções. O espaço restante até Data Offset é preenchimento zero, não carga útil.

RFC 793 já descrevia esses dois formatos em 1981. RFC 9293 mantém a regra de que toda opção diferente de EOL e NOP, inclusive uma futura, precisa ter tamanho. O receptor não precisa conhecer todos os significados para continuar sincronizado; precisa apenas conseguir avançar dentro do limite declarado e tratar tamanhos inválidos com segurança.

Alinhamento não é uma exigência

O emissor pode inserir NOP para colocar a opção seguinte em um limite de palavra. Isso é conveniência de layout, não uma condição para interoperabilidade. RFC 793 exigia tolerância a opções iniciadas em qualquer octeto, e RFC 9293 preserva essa obrigação. Tampouco há garantia de que NOP seja mais rápido em toda arquitetura.

EOL não substitui Data Offset, não reduz o cabeçalho e não faz a carga útil começar imediatamente. Ele termina a lista lógica. Quando aparece antes do limite, os bytes restantes devem ser zero; quando as opções já alcançam o limite, EOL é desnecessário.

Extensibilidade com limites

A continuidade entre RFC 793 e RFC 9293 está na disciplina de leitura: tamanhos tornam extensões desconhecidas atravessáveis; tamanhos zero ou incoerentes são ilegais e exigem tratamento defensivo.

Sources