Resumen

  • La IESG aprobó el 27 de octubre una revisión de VXLAN para publicación informativa. El 2 de noviembre seguía siendo un Internet-Draft en la cola del RFC Editor, pendiente de los autores y de acciones de IANA.
  • El tamaño del encabezado y las posiciones de sus bits permanecen intactos. La novedad es un registro de banderas cuyas futuras asignaciones exigirían «IETF Review».

Una red puede seguir enviando el mismo paquete VXLAN. Quien quiera que uno de sus ceros tenga una función pública nueva tendrá que esperar su turno. Esa es la jugada de la versión 12 del proyecto: conservar los bytes actuales y cambiar el procedimiento para escribir el siguiente significado de sus bits libres.

La lista de decisiones de la IESG fecha la aprobación el 27 de octubre de 2026, con estatus Informational previsto. El Datatracker todavía muestra un Internet-Draft. El RFC Editor necesita respuesta de los autores y las acciones de IANA están en curso. Se ha aprobado el camino editorial; aún no hay un RFC de reemplazo publicado ni debe darse por hecho el registro pedido.

El RFC 7348 apareció en 2014 como publicación independiente para describir un VXLAN que ya funcionaba. Su apartado IANA registraba el puerto UDP 4789. No repartía los bits sobrantes del encabezado entre futuras extensiones. La revisión lleva la especificación al flujo de documentos de la IETF para que las nuevas funciones de encabezado puedan definirse y anotarse públicamente.

El cambio físico es mínimo. El documento antiguo llamaba Reserved a un campo de 24 bits. El proyecto reclasifica sus primeros ocho bits como posiciones adicionales de bandera, de modo que describe 16 bits «VXLAN Flags» seguidos de 16 bits «Reserved-1». No se mueve ninguna posición ni crece el encabezado. El bit 4 sigue siendo la bandera I, que señala la presencia del VNI; un VTEP debe desechar un paquete si I vale cero. Las otras quince posiciones empiezan sin asignación. El emisor las pone a cero y el receptor las ignora. Los equipos antiguos ven los mismos ceros.

La sección de IANA pide un grupo de registros VXLAN y una lista de banderas con número de bit, descripción y documento que define cada uso. Para un valor nuevo se aplicaría IETF Review. El RFC 8126 exige para ello un RFC del flujo IETF tramitado por la IESG. Puede ser informativo; una ficha de producto no basta para ocupar un bit público. El proyecto también pide cambiar el contacto y el titular de la inscripción del puerto 4789 al presidente de la IETF y la IESG.

La escasez justifica el trámite. Dos fabricantes que asignen funciones diferentes al mismo bit dejan a los receptores un problema que el paquete no puede resolver por sí solo. El registro hace visible la colisión y ofrece un documento común. El coste es tiempo: una extensión pública debe incorporar la revisión a su calendario. Un experimento privado puede avanzar más deprisa, pero no impone significado a las redes ajenas.

Una asignación tampoco instala la función. Los operadores deciden qué ejecutar y deben probar VTEP de distintas generaciones juntos. El proyecto no contiene pruebas de interoperabilidad de banderas futuras aún no definidas. Cambiaría la decisión una extensión concreta con RFC, trazas de paquetes mixtos y resultados ante fallos, no una casilla recién creada en el registro.

El texto de 2014 dejó constancia de un protocolo en uso. El proyecto de 2026 conservaría sus bytes y daría a la IETF la llave de la siguiente modificación pública. El paquete se queda; el control del futuro cambia de mesa.

Estado del proyecto · Versión 12 · Decisión IESG · RFC 7348 · RFC 8126