Résumé

  • Le 27 octobre, l’IESG a approuvé la révision de VXLAN en vue d’un RFC informatif. Le 2 novembre, elle attendait encore une réponse des auteurs dans la file du RFC Editor ; l’IANA travaillait aux actions demandées.
  • Le paquet garde ses dimensions et ses positions de bits. Le projet veut ouvrir un registre des drapeaux dont les nouveaux numéros seraient attribués par « IETF Review ».

Le paquet VXLAN peut continuer à traverser le centre de données avec les mêmes octets. C’est le prochain usage d’un zéro qui devra présenter ses papiers. Dans la version 12 du projet, la compatibilité du présent accompagne un changement de propriétaire pour les significations futures : une extension publique devra passer par un document examiné et un registre commun.

La liste des décisions de l’IESG porte l’approbation du 27 octobre 2026, avec le statut Informational prévu. La fiche Datatracker indique toujours Internet-Draft. Le RFC Editor attend les auteurs et les mesures de l’IANA sont en cours. L’approbation ne signifie pas que le RFC de remplacement ou le nouveau registre soient déjà publiés.

Le RFC 7348 de 2014 était une soumission indépendante décrivant un protocole déjà déployé. Sa section IANA mentionnait le port UDP 4789, sans établir un registre des bits de drapeau. Le nouveau projet déplace la spécification dans le flux documentaire de l’IETF pour que les ajouts futurs à l’en-tête puissent recevoir une définition et un numéro partagés.

Le geste technique est étroit. L’ancien champ Reserved comptait 24 bits. Le projet reclasse ses huit premiers bits comme positions de drapeau supplémentaires : on obtient 16 bits « VXLAN Flags », suivis de 16 bits « Reserved-1 ». Aucune position ne bouge et l’en-tête ne s’allonge pas. Le bit 4 reste le drapeau I, qui marque la présence du VNI ; un VTEP doit rejeter un paquet où I vaut zéro. Les quinze autres positions restent initialement sans attribution. L’émetteur y place des zéros, le récepteur les ignore. Les anciens équipements retrouvent les mêmes zéros aux mêmes places.

La section IANA demande un groupe de registres VXLAN et un registre « VXLAN Flags » avec le numéro, la description et le document de chaque attribution. Les nouveaux numéros suivraient la procédure IETF Review. Le RFC 8126 précise qu’elle exige un RFC du flux IETF conduit par l’IESG. Un RFC informatif convient ; une fiche commerciale ne réserve pas à elle seule un bit public. Le projet demande aussi de remplacer, dans l’inscription du port 4789, le contact par le président de l’IETF et le titulaire par l’IESG.

Pourquoi compliquer la vie des développeurs ? Parce qu’un même bit ne peut porter deux interprétations incompatibles sur un réseau partagé. Le registre signale une collision avant qu’elle ne devienne une panne et donne aux implémenteurs un texte à vérifier. Son prix est un délai de revue dans le calendrier d’un produit. Une expérience privée peut aller vite ; une extension commune réclame une attribution commune.

Le registre ne commande pas le déploiement. Les exploitants choisissent les extensions qu’ils activent et vérifient la coexistence des anciens et des nouveaux VTEP. Le projet ne fournit aucune mesure d’interopérabilité pour des drapeaux encore indéfinis. La preuve décisive serait un RFC d’extension déterminé, accompagné de traces de paquets entre versions et de résultats en cas d’échec.

Le texte de 2014 consignait un protocole en service. Celui de 2026 garde son format et place la prochaine modification publique sous la revue de l’IETF. La réforme ne prend pas un octet de plus ; elle change la serrure des bits disponibles.

État du projet · Version 12 · Décision IESG · RFC 7348 · RFC 8126