Summary

  • La revisión 08 de draft-ietf-nvo3-rfc7348bis, fechada el 11 de septiembre, propone 15 bits de banderas, un Field-2 de 16 bits y un Field-3 de ocho bits como Unassigned. Toda asignación futura exigiría IETF Review.
  • La sección 5 aún denomina Reserved a Field-2 y Field-3 y manda transmitirlos a cero e ignorarlos al recibirlos. RFC 8126 separa expresamente Reserved de Unassigned.
  • El documento sigue en seguimiento del director de área, con tres DISCUSS y otra revisión de IANA pendiente. Daniel Kade propone un registro de disposición por campo antes de publicar; no es una medida anunciada por la IETF.

El mapa administrativo ya no coincide con la leyenda técnica

La revisión del 11 de septiembre pretende llevar la especificación básica de VXLAN al flujo documental de la IETF. El motivo declarado incluye crear un camino para extensiones que añadan significado al encabezado y necesiten inscripción en IANA. La operación convierte espacio de bits ya desplegado en un bien gobernado para cambios futuros.

Todavía no hay aprobación. El registro de Datatracker muestra un Internet-Draft informativo en IESG Evaluation::AD Followup, con tres posiciones DISCUSS. El historial registra las versiones 06, 07 y 08 los días 9, 10 y 11; IANA conserva el estado Version Changed - Review Needed. El expediente está reaccionando a la revisión, no ha terminado.

El punto de partida es RFC 7348. Dibujaba ocho bits de banderas —el bit I y siete reservados—, 24 bits reservados, el VNI de 24 bits y otros ocho bits reservados. Los campos sin uso viajaban a cero y se ignoraban en destino.

La versión 08 no cambia el tamaño ni desplaza coordenadas. Amplía la interpretación de Flags a 16 bits: I ocupa la posición 4 y los otros 15 se llaman Unassigned. A continuación, la sección 5 aún habla de un campo Reserved de 16 bits y otro de ocho. Todos se escriben a cero y se ignoran mientras carezcan de significado.

La sección 8.2 mira al futuro de otra manera. Solicita un grupo de registro VXLAN Fields con el campo de banderas, Field-2 y Field-3. Declara Unassigned los 15 bits distintos de I, los 16 de Field-2 y los ocho de Field-3: 39 en total. Las nuevas asignaciones quedarían bajo IETF Review conforme a RFC 8126.

Unassigned es una puerta con procedimiento

Unassigned no significa libre uso. Indica que el valor está disponible para ser asignado por la política publicada. Reserved indica que no está disponible para la asignación ordinaria. En este proyecto, la puerta es IETF Review; que los receptores antiguos ignoren un bit no entrega esa potestad a quien primero lo active.

La papeleta de la IESG explica la reparación. En la versión 05, las posiciones aparecían como Reserved y, al mismo tiempo, el texto ofrecía IETF Review para “nuevos valores”. IANA pidió llamarlas Unassigned si realmente podían adjudicarse. Un DISCUSS también señaló que incorporar ocho bits del antiguo bloque reservado al nuevo campo Flags era un cambio semántico deliberado, aunque la trama física siguiera intacta.

La versión 08 resolvió el nombre de las 15 banderas. Aún mantiene dos nombres para los 24 bits de Field-2 y Field-3: Unassigned en el registro, Reserved en el formato. El informe del responsable confirma IETF Review y la ausencia de expertos designados, pero conserva la descripción anterior.

No se deduce un fallo de implementación. Las fuentes no documentan tráfico con esos campos activos, un ataque, una caída ni una incompatibilidad presente. La duda aparece cuando una futura extensión obtenga un campo: ¿qué referencia cambia la regla del emisor?, ¿qué deben hacer los receptores que conocen la asignación?, ¿cuándo deja de ser correcto llamar reservado al mismo espacio?

Un libro mayor para la transición

Daniel Kade propone un registro de disposición de campos antes de que avance el documento. Tendría una fila para bits 0–3, I, bits 5–15, Field-2 y Field-3. Cada fila reuniría posición, estado registral, regla de emisión, regla de recepción, política de asignación, controlador del cambio, referencia y condición de compatibilidad.

La transición quedaría escrita como tal. Una fila comienza Unassigned, cero e ignorada. Una extensión aprobada cambia únicamente su intervalo a Assigned, define la nueva semántica y demuestra si un receptor antiguo puede seguir ignorándola. Registro y especificación deben apuntar al mismo acto de autoridad.

La tabla no reparte números ni sustituye consenso. Evita reconstruirlo después. El registro IANA del puerto 4789 ofrece otro ejemplo: la versión 08 pide actualizar la referencia del puerto al documento sucesor. La custodia reside también en la cita que dice qué texto manda.

La declaración de la IESG sobre DISCUSS describe estas posiciones como solicitudes de conversación sobre problemas serios, no como vetos. La prueba de cierre será que el formato y el registro expresen una sola disposición verificable.

El Policy Mirror de Heng Lu separa capacidad de autoridad: ignorar un campo desconocido es una conducta de protocolo, no un permiso de asignación. La Minimum Initial Specification defiende una frontera común mínima que preserve decisiones futuras. Why BTW Media Exists fija el límite periodístico: hay una incoherencia textual bajo revisión, no una crisis demostrada de VXLAN.

Sources

  1. VXLAN bis, revisión 08
  2. VXLAN bis, revisión 07
  3. Registro actual en Datatracker
  4. Historial del documento
  5. Papeleta IESG
  6. Informe del responsable del documento
  7. RFC 7348 — VXLAN
  8. RFC 8126 — guía para registros IANA
  9. Registro IANA de puertos, entrada 4789
  10. Declaración de IESG sobre posiciones de voto
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — Why BTW Media Exists