Resumo

  • Desde a RFC 1883, os dois bits mais altos do Option Type de um TLV IPv6 determinam o que um nó em processamento faz quando não reconhece o tipo: salta, descarta ou descarta e devolve um ICMPv6 que aponta para o octeto desconhecido.
  • Um terceiro bit declara se os dados podem mudar no caminho. Ele protege o cálculo de autenticação contra uma promessa falsa, mas não obriga todo roteador a processar o cabeçalho, todo middlebox a encaminhá-lo nem ninguém a confiar na opção.

O formato comum sobrevivia sem conhecer a função

Um destino reconhece o cabeçalho Destination Options e percorre seus TLVs. Em certo ponto, encontra um tipo que sua versão não implementa. Ele não sabe interpretar o Value, mas lê a extensão do campo e sabe onde começa a próxima opção.

A RFC 1883, primeira especificação publicada do IPv6 em dezembro de 1995, acrescentou outra informação ao mesmo octeto. Os dois primeiros bits definiam a reação à não identificação; o terceiro declarava se Option Data podia mudar antes do destino final. Os cinco restantes continuavam participando da identidade.

O autor da novidade não ganhava autoridade sobre o programa antigo. Ganhava uma maneira pública de declarar um resultado mínimo que o programa conseguia executar sem adivinhar a semântica privada.

Dois bits delimitavam quatro respostas

00 permite ignorar a opção e continuar o cabeçalho; Opt Data Len informa quantos octetos avançar. 01 manda descartar o pacote. 10 manda descartar e enviar ICMPv6 Parameter Problem, Code 2, ao endereço de origem, com o ponteiro na Option Type desconhecida. 11 também descarta e relata, mas suprime a mensagem quando o destino era multicast.

Esses padrões não classificam ameaça. Uma opção 00 pode ser indesejada por uma política local. Uma opção 11 pode ser legítima, porém depender de compreensão para preservar seu efeito. Os bits classificam a consequência da ignorância.

O ponteiro transforma um fracasso genérico em evidência de um byte preciso. Ainda assim, a resposta pode ser limitada, filtrada ou perdida. Sua chegada prova um evento local; sua ausência não informa se o pacote foi pulado, descartado em silêncio ou bloqueado antes.

Multicast tinha uma fronteira de relatório explícita

A única diferença entre 10 e 11 está no destino multicast. O primeiro exige o relatório mesmo nesse caso; o segundo evita a resposta.

Assim, o possível gasto de tráfego de erro fica visível no tipo. O operador pode comparar a regra declarada com os limites de ICMP e com os pacotes realmente transmitidos. O padrão não declara multicast perigoso, nem substitui a proteção local contra amplificação.

O terceiro bit impedia autenticar uma aparência

O bit seguinte não escolhe entre descartar e continuar. Zero significa que os dados não mudam no caminho; um significa que podem mudar. Quando existe um Authentication Header, os dados de uma opção mutável são tratados como octetos zero no cálculo e na verificação do valor de autenticação.

O protocolo não prometia invariância para uma área que poderia sofrer uma atualização legítima em trânsito. A exclusão, porém, não é uma licença de escrita. A especificação da opção ainda define qual agente pode alterar qual campo; o bit só impede que a autenticação cubra uma afirmação insustentável.

Os oito bits eram o tipo completo

A RFC 2460 esclareceu em 1998 que os três bits superiores não eram uma política solta aplicada a um identificador de cinco bits. O Option Type é o octeto inteiro. Valores com os mesmos cinco bits inferiores e prefixos distintos são tipos diferentes.

Hop-by-Hop Options e Destination Options compartilham esse espaço, embora cada definição possa restringir onde aparece. As opções também precisam ser processadas em ordem. Um receptor não pode procurar uma opção conhecida adiante, executá-la e só depois resolver a desconhecida que veio antes.

A ordem impede aceitação retrospectiva: se a opção inicial determina descarte, a familiaridade com uma opção posterior não apaga a decisão.

Opção desconhecida não era cabeçalho desconhecido

Os bits pertencem a um TLV dentro de Hop-by-Hop Options ou Destination Options já reconhecido. Eles não dão automaticamente tamanho ou ação a um valor Next Header que identifica um Extension Header desconhecido.

A RFC 6564 preferiu uma nova Destination Option quando o mecanismo fosse suficiente e exigiu justificativa para criar outro Extension Header. Para cabeçalhos futuros, adotou um formato comum com comprimento; formatos antigos não foram reescritos.

A RFC 7045 separou responsabilidades. O host de destino descarta um pacote com Extension Header que não reconhece. Um nó intermediário não deve, em geral, descartar só porque ainda não conhece um cabeçalho novo; se decidir inspecionar a cadeia, precisa acompanhar o registro. Isso difere de ler bits de ação de um TLV desconhecido dentro de um recipiente conhecido.

Middleboxes mostraram o que o byte não resolvia

Firewalls, balanceadores e roteadores rápidos procuram campos de transporte. Uma cadeia longa ou nova pode exigir recirculação, tirar o pacote do fast path ou impedir que a política encontre as portas necessárias.

A RFC 8200 preservou as quatro ações e o bit de mudança, mas vinculou o processamento Hop-by-Hop em trânsito à configuração explícita. A RFC 9098 descreveu as escolhas de um equipamento que não encontra a informação desejada: encaminhar sem a inspeção, descartar ou consumir uma via de processamento mais cara.

Autodescrição não cria capacidade de hardware. Ela só elimina a improvisação depois que um processador alcançou aquela opção.

O que nunca foi autorizado

00 não significa seguro nem concede passagem. 11 não prova hostilidade. O bit mutável não libera alterações arbitrárias. Registro não prova suporte no caminho, e ICMP não autentica identidade ou intenção.

O mecanismo coordena estranhos porque é limitado: regra comum, execução local e prova pelos pacotes que realmente atravessam a rede.

Fontes e limites da evidência

A origem está nas RFCs 1883 e 2460; a regra atual, na RFC 8200. A distinção de formatos e papéis vem das RFCs 6564 e 7045; os limites operacionais, da RFC 9098. Esses textos não medem o suporte ou a perda atual de todos os produtos e redes.