Summary

  • Datée du 11 septembre, la révision 08 prévoit 15 bits de drapeau non attribués, un Field-2 de 16 bits et un Field-3 de huit bits. Toute nouvelle valeur passerait par « IETF Review ».
  • La section 5 qualifie toujours les deux derniers champs de Reserved et impose leur émission à zéro ainsi que leur ignorance à la réception. RFC 8126 distingue pourtant Reserved d’Unassigned.
  • Le projet reste en suivi du directeur de zone, avec trois DISCUSS et une nouvelle revue IANA attendue. Le registre de disposition proposé par Daniel Kade est une recommandation éditoriale, pas une règle annoncée par l’IETF.

Le désaccord tient dans la légende

Le texte du 11 septembre veut faire entrer la spécification de base de VXLAN dans la filière IETF. Son objectif déclaré est de permettre des extensions qui ajoutent des significations à l’en-tête et les enregistrent auprès de l’IANA. Pour un protocole déjà largement déployé, la question n’est donc pas seulement de décrire l’existant : il faut instituer la garde du changement futur.

Le dossier n’est pas clos. La fiche Datatracker parle d’un Internet-Draft informatif en IESG Evaluation::AD Followup. Trois positions DISCUSS subsistent. L’historique montre trois versions successives les 9, 10 et 11 septembre ; l’état IANA est encore Version Changed - Review Needed. Une cadence rapide témoigne d’un travail de correction, non d’une approbation.

Le comptage part du RFC 7348. Son en-tête comporte huit bits de drapeau, dont le bit I et sept bits réservés, puis 24 bits réservés, un VNI de 24 bits et huit derniers bits réservés. Les positions inutilisées sont émises à zéro et ignorées à la réception.

La révision 08 conserve les coordonnées et la taille de huit octets, mais redécoupe le sens. La section 5 élargit les drapeaux à 16 bits : le bit 4 est I et les 15 autres sont Unassigned. Viennent ensuite un champ de 16 bits et un champ final de huit bits que cette même section appelle encore Reserved. Pour tous, le comportement actuel reste zéro à l’émission et ignorance à la réception.

La section 8.2 propose à l’IANA un groupe VXLAN Fields. Elle y classe comme Unassigned les 15 positions de drapeau disponibles, Field-2 dans son entier et Field-3 dans son entier : 39 bits. Les attributions futures exigeraient un examen IETF selon le RFC 8126.

Une case disponible n’est pas une case libre

La nuance ne relève pas de la typographie. Un champ Unassigned demeure disponible dans le cadre de la politique indiquée. Un champ Reserved n’est pas normalement attribuable. Aucun des deux statuts ne confère un droit d’usage privé. Ici, l’entrée légitime suppose un document de la filière IETF et son examen collectif.

Le bulletin de vote IESG conserve la trace du problème. La révision 05 parlait de bits Reserved tout en prévoyant de nouvelles valeurs par IETF Review. L’IANA a demandé que les positions destinées à l’attribution soient nommées Unassigned. Une position DISCUSS a aussi exigé que la réorganisation des huit premiers bits de l’ancien champ réservé de 24 bits soit rendue explicite.

La révision 08 a aligné le vocabulaire des 15 bits de drapeau. Elle n’a pas encore aligné Field-2 et Field-3 entre le format et le registre. Le rapport du responsable du document confirme bien une politique IETF Review sans expert désigné, mais conserve encore l’ancien récit des bits réservés.

Il n’y a pas de panne actuelle à déduire. Les sources ne montrent ni trafic non nul dans ces champs, ni faille, ni implémentation fautive. Le problème se déclenche lors d’une attribution : quel événement transforme une obligation d’ignorer en sémantique reconnue ? Quel texte gouverne le déploiement ? Et selon quelle règle un ancien récepteur peut-il continuer d’ignorer le nouveau sens ?

Une ligne par plage, une transition par décision

Daniel Kade propose un registre de disposition des champs annexé au travail avant publication. Une ligne couvrirait chacune des plages : bits 0–3, bit I, bits 5–15, Field-2 et Field-3. Elle réunirait coordonnées, état IANA, comportement d’émission, comportement de réception, politique d’attribution, contrôleur du changement, référence et règle de compatibilité.

L’état initial serait explicite : Unassigned, zéro, ignorance. Une extension approuvée ferait passer sa seule plage à Assigned, définirait le nouveau traitement et préciserait le sort des récepteurs anciens. Ce passage devrait apparaître simultanément dans la référence normative et dans le registre, sans obliger l’opérateur à reconstruire une intention dispersée.

Cette pièce ne distribue aucun bit. Elle rend la décision vérifiable. Le registre IANA du port 4789 rappelle qu’une référence fait partie de la garde : la révision 08 demande aussi que le futur document remplace RFC 7348 comme référence du port VXLAN.

La déclaration de l’IESG sur DISCUSS présente cette position comme une demande de résoudre un problème sérieux, non comme un veto. La bonne preuve de résolution sera donc une concordance lisible entre les deux sections, pas seulement un nouveau numéro de version.

Le Miroir de la politique de Heng Lu aide à séparer mécanisme et autorité : le fait qu’un récepteur ignore un bit ne donne pas le pouvoir de l’attribuer. La Spécification initiale minimale invite à fixer une frontière commune étroite tout en laissant l’innovation locale respirer. Pourquoi BTW Media existe impose enfin la retenue : le document révèle une couture normative en cours de traitement, pas une défaillance de VXLAN en production.

Sources

  1. VXLAN bis, révision 08
  2. VXLAN bis, révision 07
  3. Fiche Datatracker actuelle
  4. Historique du document
  5. Bulletin IESG
  6. Rapport du responsable du document
  7. RFC 7348 — VXLAN
  8. RFC 8126 — règles des registres IANA
  9. Registre IANA des ports, entrée 4789
  10. Déclaration IESG sur les positions de vote
  11. Heng Lu — Le Miroir de la politique
  12. Heng Lu — Spécification initiale minimale
  13. Heng Lu — Pourquoi BTW Media existe