Zusammenfassung

  • Die IESG billigte am 27. Oktober die VXLAN-Revision zur Veröffentlichung als informativen RFC. Am 2. November wartete sie noch beim RFC Editor auf Rückmeldung der Autoren; IANA-Maßnahmen liefen ebenfalls.
  • Der Entwurf ändert weder Headerlänge noch Bitpositionen. Er würde bislang reservierte Stellen als registrierbare Flags behandeln, deren neue Belegung eine IETF-Prüfung verlangt.

Ein VXLAN-Paket kommt durch die Leitung, ohne sich für diese Revision umzuziehen. Der nächste Anbieter, der einer freien Null im Header eine eigene Bedeutung geben will, steht vor einer anderen Frage: Gilt diese Bedeutung auch für alle anderen? Der Entwurf in Fassung 12 antwortet mit einem Register und einer Prüfung. Die technische Kontinuität bleibt; die öffentliche Änderungsbefugnis bekommt eine Adresse.

Die IESG-Entscheidungsliste nennt den 27. Oktober 2026 als Datum der Billigung für einen Informational RFC. Der Datatracker bezeichnet Fassung 12 weiter als Internet-Draft. Beim RFC Editor steht sie wegen erforderlicher Autorenauskunft; die IANA-Aktionen sind in Bearbeitung. Der Beschluss ist also vorhanden, die Veröffentlichung und das beantragte Register noch nicht. Wer beides gleichsetzt, macht aus einem Arbeitsauftrag eine erledigte Institution.

RFC 7348 erschien 2014 als unabhängige Einreichung und hielt ein bereits eingesetztes VXLAN fest. Sein IANA-Abschnitt vermerkte den UDP-Port 4789. Ein Register für künftige Bedeutungen einzelner Flag-Bits schuf er nicht. Die neue Schrift würde die VXLAN-Spezifikation in den IETF-Dokumentenstrom überführen und die Zuordnung von Header-Erweiterungen öffentlich nachvollziehbar machen.

Der Eingriff in die Bits ist genau abgegrenzt. Von einem bisher 24 Bit breiten Reserved-Feld werden die ersten acht als zusätzliche Flag-Positionen neu eingeordnet. Damit entstehen ein 16-Bit-Feld „VXLAN Flags“ und danach 16 Bit „Reserved-1“. Kein Bit wandert, der VXLAN-Header wird nicht länger. Bit 4 bleibt das I-Flag für eine vorhandene VNI; ein VTEP muss Pakete mit I=0 verwerfen. Die übrigen 15 Stellen beginnen ohne Zuteilung. Sender setzen sie auf null, Empfänger ignorieren sie. Alte Geräte lesen damit dieselbe Folge wie zuvor.

Im IANA-Abschnitt verlangt der Entwurf eine VXLAN-Registergruppe und ein Verzeichnis der Flags mit Bitnummer, Beschreibung und definierender Schrift. Neue Einträge sollen nach IETF Review vergeben werden. RFC 8126 legt fest, was das kostet: ein RFC aus dem IETF-Strom, durch das IESG-Verfahren geführt. Auch ein informativer IETF-RFC kann genügen. Eine Herstellerbroschüre kann keine öffentliche Flag-Belegung beanspruchen. Zusätzlich sollen beim Port 4789 der IETF Chair als Kontakt und die IESG als Inhaber eingetragen werden.

Ein solches Register schützt vor einer einfachen Kollision. Zwei Erweiterungen können dieselbe knappe Bitposition nicht verschieden deuten und gleichzeitig Interoperabilität versprechen. Die Zuordnung dokumentiert, welcher Entwurf welches Recht beansprucht. Aber der Prüfweg dauert; er wird Teil jedes Produktzeitplans, der eine öffentliche Erweiterung braucht. Ein privat ausprobiertes Bit ist schneller gesetzt als ein gemeinsam nutzbares Bit.

Die Zuteilung selbst installiert noch keine Funktion. Betreiber wählen weiterhin, welche Erweiterung sie fahren, und müssen alte mit neuen VTEPs testen. Für noch ungeschriebene Flag-Erweiterungen bietet der Entwurf keine Messung. Eine konkrete Entscheidung würde ein bestimmter Erweiterungs-RFC mit Paketspuren aus gemischten Versionen und dokumentiertem Fehlerverhalten verändern.

Die 2014er Schrift beschrieb den laufenden Betrieb. Die 2026er Schrift will die nächste öffentliche Änderung in ein Verfahren legen. Gerade weil der alte Header erhalten bleibt, lässt sich sehen, wo die Machtverschiebung liegt: nicht im heutigen Paket, sondern im Schlüssel für die künftigen Nullen.

Entwurfsstatus · Fassung 12 · IESG-Beschluss · RFC 7348 · RFC 8126