Summary

  • O draft-ietf-nvo3-rfc7348bis-08, de 11 de setembro, propõe 15 bits de flags, o Field-2 de 16 bits e o Field-3 de oito bits como Unassigned. Novas atribuições dependeriam de IETF Review.
  • A seção 5 ainda denomina os dois últimos campos Reserved e exige zero no envio e descarte sem interpretação na recepção. O RFC 8126 distingue Reserved de Unassigned.
  • A minuta permanece em acompanhamento do diretor de área, com três DISCUSS e nova revisão da IANA pendente. Daniel Kade recomenda um livro de disposição dos campos; não é um controle anunciado pela IETF.

A mudança está na autoridade, não no comprimento

A revisão 08 pretende substituir o RFC 7348 e levar a base do VXLAN ao fluxo da IETF. O objetivo inclui permitir extensões que deem novos significados ao cabeçalho e tenham registro na IANA. Isso transforma posições já presentes no fio em uma superfície pública de mudança.

O processo não terminou. O Datatracker mostra um Internet-Draft Informational em IESG Evaluation::AD Followup, ainda com três posições DISCUSS. O histórico registra as revisões 06, 07 e 08 em 9, 10 e 11 de setembro. A IANA marca Version Changed - Review Needed. Revisões rápidas são evidência de trabalho, não de publicação.

No RFC 7348, havia oito bits de flags — I e sete reservados —, um bloco reservado de 24 bits, o VNI de 24 bits e mais oito bits reservados. As posições sem função eram transmitidas como zero e ignoradas ao chegar.

A revisão 08 mantém os mesmos oito octetos e coordenadas. A seção 5 passa a ler os primeiros 16 bits como Flags: I ocupa o bit 4; os outros 15 são Unassigned. Depois aparecem 16 bits e oito bits ainda chamados Reserved. A regra operacional presente continua idêntica: escrever zero e ignorar.

Na seção 8.2, o futuro registro VXLAN Fields reúne o campo de flags, Field-2 e Field-3. Os 15 bits fora de I, os 16 de Field-2 e os oito de Field-3 aparecem como Unassigned, totalizando 39. Valores novos exigiriam IETF Review segundo o RFC 8126.

Disponível para atribuição não é livre para ocupação

Unassigned quer dizer que uma posição pode ser atribuída pela política declarada. Reserved quer dizer que ela não está disponível para atribuição comum. Nenhum termo autoriza significado privado. O fato de receptores antigos ignorarem um bit desconhecido é um comportamento de compatibilidade, não uma delegação.

A cédula da IESG registra a origem da correção. A revisão 05 chamava os bits de Reserved e simultaneamente oferecia IETF Review para valores novos. A IANA pediu Unassigned para posições destinadas a atribuição. Um DISCUSS também exigiu transparência sobre a incorporação de oito bits do antigo bloco reservado ao novo campo Flags, uma reorganização sem deslocar bits.

A revisão 08 harmonizou os 15 flags, mas não Field-2 e Field-3. Eles são Unassigned na tabela e Reserved no formato. O relatório do shepherd confirma a política IETF Review, sem especialista designado, mas ainda carrega a descrição anterior.

Nada disso prova vulnerabilidade, falha de fornecedor ou uso não zero em produção. A questão surge quando uma extensão futura recebe um campo. Qual evento muda a regra do emissor? Um receptor antigo pode ignorar com segurança o novo significado? Qual referência permite distinguir uma atribuição válida de bits acidentalmente acionados?

Registrar a passagem de zero para significado

Daniel Kade propõe um livro de disposição dos campos antes da publicação. Haveria uma linha para bits 0–3, I, bits 5–15, Field-2 e Field-3. Cada linha ligaria coordenadas, estado no registro, comportamento de envio e recepção, política, controlador de mudança, referência e condição de compatibilidade.

Uma faixa começaria Unassigned, zerada e ignorada. Uma extensão aprovada mudaria apenas sua faixa para Assigned, definiria semântica e processamento e explicaria a convivência com receptores antigos. A entrada na IANA e o texto normativo apontariam para o mesmo ato.

O livro não atribui valores nem substitui consenso. Ele conserva a prova. O registro do porto 4789 mostra outra manutenção solicitada: a revisão 08 pede que a futura referência substitua o RFC 7348. Um registro governa também qual documento controla o número.

A declaração da IESG sobre DISCUSS trata a posição como pedido de conversa sobre um problema sério, não como veto. Portanto, uma nova revisão não basta; a evidência será a convergência das duas descrições.

O Policy Mirror de Heng Lu impede transformar “o receptor ignora” em “alguém pode atribuir”. A Minimum Initial Specification recomenda uma base comum pequena que preserve decisões posteriores sem ocultar autoridade. Why BTW Media Exists fixa o limite factual: há uma costura textual sob revisão, não uma crise comprovada do VXLAN.

Sources

  1. VXLAN bis, revisão 08
  2. VXLAN bis, revisão 07
  3. Registro atual no Datatracker
  4. Histórico do documento
  5. Cédula da IESG
  6. Relatório do shepherd
  7. RFC 7348 — VXLAN
  8. RFC 8126 — orientação para registros IANA
  9. Registro IANA de portas, entrada 4789
  10. Declaração da IESG sobre posições
  11. Heng Lu — Policy Mirror
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — Why BTW Media Exists