Resumo

  • O diagrama da RFC 8928 colocou C no bit 3 do EARO sem registrar a posição na IANA; depois, a RFC 9685 registrou o campo P de dois bits nas posições 2 e 3.
  • A RFC 9927 transfere C para o bit 1 e declara a mudança incompatível com versões anteriores. Não há plano de transição porque os autores não conheciam implementação nem implantação da RFC 8928.
  • A RFC corrigida e o registro atual definem a convenção compartilhada. Não atualizam firmware, não identificam todos os parsers antigos e não comprovam como um pacote ou serviço se comportou.

Uma lacuna entre o desenho e o livro de alocações

A RFC 8928 definiu o Address-Protected Neighbor Discovery. No Extended Address Registration Option, o sinalizador C informa que o Registration Ownership Verifier contém um Crypto-ID e que o 6LoWPAN Node pode ser desafiado a provar a propriedade do endereço registrado. A figura posicionava C no bit 3.

Isso bastava para orientar um implementador, mas a posição não foi incluída no registro de Address Registration Option Flags da IANA. Um campo compacto é um espaço compartilhado. Quem programa a partir do diagrama pode considerar o bit ocupado; quem prepara uma extensão posterior consulta o registro para encontrar uma posição livre. Sem a ligação entre as duas fontes, os dois podem seguir instruções razoáveis e criar gramáticas incompatíveis para o mesmo octeto.

A RFC 9685 veio depois com o Registered Address Type Indicator. Seu campo P, com dois bits, ocupa as posições 2 e 3 e recebeu os registros correspondentes. O bit 3 passou a admitir duas leituras. Não era apenas uma sigla repetida ou um problema visual: um receptor poderia tratar a posição como C ou como parte de P.

Nenhuma fonte relata falha, ataque ou incompatibilidade observada. O que o registro probatório sustenta é que os documentos permitiam parsers divergentes.

Mover C recompõe uma gramática única

A RFC 9927 substitui as figuras do EARO em Neighbor Solicitation e Neighbor Advertisement. C passa ao bit 1; P permanece nos bits 2 e 3. O texto também corrige “Enhanced Address Registration Option” para “Extended Address Registration Option”.

O registro vigente da IANA agora mostra: bit 0 não atribuído; bit 1 C; bits 2–3 P; bits 4–5 I; bit 6 R; bit 7 T. Essa lista é a superfície comum de coordenação, não um apêndice decorativo. Ela permite que o próximo autor ou programador conheça a ocupação sem reconstruir a história de todas as figuras.

A RFC 8126 oferece o contexto processual. Registrar valores escassos de protocolo é uma ação de governança. Ainda assim, a autoridade do registro tem escopo definido: ele comprova a alocação reconhecida pelo processo de padronização, mas não a versão de um executável, uma atualização distribuída ou a interpretação de um pacote recebido.

“Nenhuma implementação conhecida” preserva a incerteza

A RFC 9927 afirma que a alteração não é retrocompatível. Um emissor criado segundo a figura antiga e um receptor criado segundo o mapa novo podem discordar sobre o bit 3. Mesmo assim, o documento dispensa um plano de transição porque não havia implementação ou implantação conhecida da RFC 8928.

“Conhecida” delimita a afirmação. É o estado de informação usado pelos autores, não o resultado de um censo mundial. As fontes não descrevem uma busca universal nem excluem protótipos privados. Reescrever a frase como “não existia código algum” acrescentaria uma certeza sem prova.

Uma organização sem vestígio da RFC 8928 pode adotar a RFC 9927 como gramática inicial. Se um parser antigo aparecer, a resposta muda: identificar fontes e binários, preservar a procedência das compilações, testar codificadores e decodificadores com vetores controlados, observar pares, implantar em etapas e manter retorno. A ausência de transição normativa não cancela uma transição local sustentada por evidência.

Coordenação não é telemetria

O conceito de Minimum Initial Specification de Heng Lu serve como lente, não como regra da IETF: uma convenção estreita coordena o ponto comum e deixa a adoção nas mãos dos participantes. Running-Code Primacy marca o limite inverso, pois um documento corrigido não substitui a prova do sistema em operação. Reality Layers impede que autoridade normativa seja apresentada como fato operacional.

A RFC 8928 prova o que a figura mostrava. A RFC 9685 e a ação da IANA provam a alocação de P. A RFC 9927 prova a correção e o juízo declarado sobre transição. O registro atual prova o mapa compartilhado de hoje. Nenhuma dessas camadas, isoladamente, mostra como um binário não identificado interpreta o campo.

Uma alegação de runtime exige versão de código ou binário, comportamento de codificação e decodificação, configuração, testes ou capturas controladas, versão do par e interpretação observada. Para alegar efeito no serviço, falta ainda medir o serviço. “O registro foi corrigido” não significa “a rede foi corrigida”.

Fronteiras da evidência

O material não identifica produto, nó implantado, pacote capturado, exploração, indisponibilidade, taxa de adoção ou impacto comercial. O sinalizador C também não prova titularidade pública de endereço, autorização global de rota ou aceitação por serviço. Seu papel está restrito à verificação de propriedade no EARO.

A conclusão tem duas metades. Um diagrama capaz de gerar código precisa estar unido ao registro que coordena o campo. Um registro corrigido precisa continuar separado da evidência que descreve o código em execução. A RFC 9927 conserta a primeira união; cada operador ainda precisa demonstrar a segunda.

Fontes