Summary

  • On 27 October the IESG approved a VXLAN revision for Informational publication. On 2 November it remained an Internet-Draft in the RFC Editor queue, awaiting author input while IANA actions continued.
  • The draft preserves header length and bit positions, but would establish a VXLAN Flags registry: future public assignments would require IETF Review.

A data-centre operator can keep sending the same VXLAN packet. The approved draft does not add a byte. Yet the next builder who wants to give one of its zeroed bits a public meaning would face a new question: where is the RFC? That is the quiet fight inside version 12 of the VXLAN revision. The wire stays familiar while the right to define its future flags moves to a reviewed registry.

The IESG decision record dates approval to 27 October 2026, with Informational status intended. The Datatracker entry still calls the text an Internet-Draft. The RFC Editor queue is blocked for author input; IANA work is in progress. IESG approval is real, but the replacement RFC and proposed registry are not yet finished products.

RFC 7348 appeared in 2014 as an Independent Submission documenting deployed VXLAN. Its IANA section recorded UDP destination port 4789. It did not create a public allocation table for the header's spare flag positions. The revision moves the specification into the IETF document stream so future header extensions can be defined and registered there. The institutional move is written into the same document that promises compatibility with the original format and processing.

The bit operation is precise. The older text called 24 bits Reserved. The revision reclassifies the first eight of those bits as additional flags, yielding a 16-bit VXLAN Flags field followed by a 16-bit Reserved-1 field. No bit position changes; the header does not grow. Bit 4 stays the I flag, indicating that the VXLAN Network Identifier is present. A VTEP must discard a packet with I=0. The other fifteen flag positions start unassigned. Senders set them to zero and receivers ignore them. Existing devices continue to see the old zeroes in the old places.

The change comes when a zero becomes an assignment. Section 8 asks IANA to create a VXLAN registry group and a VXLAN Flags registry recording each bit, its description and its defining document. New assignments would require IETF Review. RFC 8126 defines that procedure: a new value needs an RFC in the IETF stream shepherded through the IESG. An Informational IETF RFC can qualify. A product announcement cannot reserve a public bit by itself. The draft also requests a new contact and assignee for port 4789: the IETF Chair and IESG respectively.

There is a reason to slow down. Two extensions cannot assign incompatible meanings to the same scarce bit and expect every receiver to guess correctly. A registry makes the collision visible and points implementers to a shared definition. The cost is product time. A company may experiment privately, but a public extension would need to wait for review and assignment. The old packet keeps working while the next common meaning enters a queue.

An assignment still does not deploy an extension. Operators decide what to enable and must test mixed generations of VTEPs. The draft offers no fleet-wide trial of flags that have not yet been defined. A concrete extension RFC, packet traces across old and new devices, and failure behaviour would change an operator's decision. A registry entry alone would prove coordination, not that those packets work in production.

The 2014 RFC wrote down a protocol already running. The 2026 draft keeps its bytes in place and proposes a gate for the next public change. The packet is stable; the key to tomorrow's bits is moving.

Draft status · Version 12 · IESG decision · RFC 7348 · RFC 8126