Resumo

  • Em 27 de outubro, a IESG aprovou a revisão do VXLAN para publicação informativa. Em 2 de novembro, o texto ainda estava na fila do RFC Editor, aguardando os autores, com ações da IANA em andamento.
  • O projeto não amplia o cabeçalho nem desloca bits. Ele propõe um registro de flags cujas futuras atribuições exigirão IETF Review.

O pacote VXLAN que passa pelo centro de dados pode continuar exatamente como está. A mudança aparece quando alguém quiser transformar um zero reservado em função pública. A versão 12 do projeto coloca uma porta nessa decisão: um RFC examinado pela IETF e uma atribuição registrada pela IANA. A compatibilidade de hoje acompanha uma disputa sobre quem escreve a semântica de amanhã.

A lista de decisões da IESG registra a aprovação em 27 de outubro de 2026, com status Informational pretendido. O Datatracker ainda mostra um Internet-Draft. O RFC Editor aguarda retorno dos autores e as ações da IANA seguem em andamento. A aprovação é concreta; um novo RFC publicado e o registro pedido ainda não são fatos consumados.

O RFC 7348, de 2014, foi uma submissão independente que documentou o VXLAN já instalado. Sua seção IANA tratava da porta UDP 4789. Não havia uma tabela pública para os significados futuros das flags do cabeçalho. A revisão transfere a especificação para o fluxo documental da IETF, onde extensões poderão receber definição e número comuns.

A operação nos bits é exata. O texto antigo chamava Reserved a um campo de 24 bits. O projeto reclassifica os oito primeiros como posições adicionais de flag, resultando em 16 bits de «VXLAN Flags» e 16 bits de «Reserved-1». Nenhuma posição muda; o cabeçalho não cresce. O bit 4 continua a ser a flag I, que indica a presença do VNI, e um VTEP deve descartar um pacote com I=0. As outras quinze posições começam sem atribuição. O emissor envia zero, o receptor ignora. Equipamentos antigos continuam vendo os mesmos zeros.

Na seção IANA está o novo mecanismo de controle. O projeto pede um grupo de registros VXLAN e um registro de flags que identifique posição, descrição e documento definidor. Novos valores seguiriam IETF Review. Segundo o RFC 8126, isso exige um RFC do fluxo IETF conduzido pela IESG. Um RFC informativo pode servir; uma ficha de produto não ocupa um bit público sozinha. O texto ainda pede que a ficha da porta 4789 passe a indicar o presidente da IETF como contato e a IESG como responsável pela atribuição.

Existe um motivo prático para desacelerar. Duas extensões que atribuem funções diferentes ao mesmo bit não se tornam interoperáveis só porque o cabeçalho é igual. O registro torna a colisão visível e aponta para uma definição verificável. O preço é tempo no planejamento dos produtos. Um experimento privado pode sair rápido; uma semântica compartilhada depende da revisão.

Receber um número tampouco instala a função. Operadores decidem o que ativar e precisam testar VTEPs antigos e novos juntos. O projeto não contém medições de compatibilidade para flags futuras ainda indefinidas. O dado capaz de mudar uma decisão é uma extensão concreta com RFC, traços de pacotes em versões misturadas e resultados de falhas.

O documento de 2014 registrou um protocolo que já rodava. O projeto de 2026 manteria os bytes e levaria a próxima mudança pública para a fila da IETF. O pacote fica; a chave do futuro muda de mãos.

Estado do projeto · Versão 12 · Decisão IESG · RFC 7348 · RFC 8126