Summary

  • draft-ietf-nvo3-rfc7348bis-08, dated 11 September, proposes 15 unassigned flag bits plus unassigned 16-bit and eight-bit fields. Future values would require IETF Review.
  • Section 5 still calls the latter two fields Reserved and tells senders to zero them and receivers to ignore them. “Reserved” and “Unassigned” are different registry states under RFC 8126.
  • The draft remains in Area Director follow-up with three DISCUSS positions and a fresh IANA review pending. Daniel Kade proposes one field-disposition ledger before publication; this is editorial analysis, not an announced IETF control.

One header now carries two descriptions of its future

The 11 September revision of the VXLAN bis work does more than refresh a widely deployed encapsulation. Its introduction says the document would move VXLAN into the IETF stream and make extensions that add to the VXLAN header registerable with IANA. That creates a public route for changing a header whose original description was published in 2014.

The route is not yet complete. The current Datatracker record lists an Informational Internet-Draft in IESG Evaluation::AD Followup. It reports three DISCUSS positions and enough ballot positions to pass once those discussions are resolved. The history records revisions 06, 07 and 08 on three consecutive days, and the IANA state remains Version Changed - Review Needed. None of that is an RFC approval.

The useful governance issue is visible by counting coordinates. RFC 7348 described eight flag bits, including the I bit, followed by 24 reserved bits, a 24-bit VNI and another eight reserved bits. All unused positions were transmitted as zero and ignored on receipt.

Revision 08 reorganises the same eight-octet header without moving a bit. Section 5 now describes a 16-bit Flags field: bit 4 is the I bit, while the other 15 are Unassigned, zero on transmission and ignored on receipt. The next 16 bits and the final eight bits are still named Reserved and receive the same zero-and-ignore rule.

Section 8.2 presents a broader future. It asks IANA for a VXLAN Fields registry group containing the 16-bit flag field, a two-octet Field-2 and a one-octet Field-3. Fifteen flag positions are Unassigned. Field-2's 16 bits are Unassigned. Field-3's eight bits are Unassigned. The total is 39, and new values would be assigned through IETF Review under RFC 8126.

“Unassigned” does not mean “use it”

This vocabulary is part of the control system. An Unassigned value remains available for assignment under the registry's policy. A Reserved value is not available for ordinary assignment. Neither label authorises an implementer to select a private meaning. Here, future allocation requires an IETF-stream document satisfying IETF Review.

The distinction entered the ballot record for a practical reason. The IESG ballot preserves a DISCUSS explaining that revision 05 labelled the unused flag positions Reserved while also offering an assignment policy for new values. IANA's review made the same point: positions intended for allocation should be Unassigned, not Reserved. The shepherd write-up documents the intended IETF Review policy but still reflects the earlier reserved-bit description.

Revision 08 resolves the contradiction for the 15 flag bits. It does not yet resolve the naming of Field-2 and Field-3 between Sections 5 and 8. The registry says those 24 bits are available for a future assignment. The packet text says they are Reserved. Present behavior is not ambiguous—send zero, ignore on receipt—but the transition triggered by a later assignment is.

This is not evidence of an exploit, an outage or a broken deployment. No source in the frozen record shows current non-zero use. It is also not a claim that packet length or coordinates changed. The proposal deliberately reclassifies the first eight bits of RFC 7348's 24-bit reserved field as new flag space while keeping the physical layout stable.

Give every coordinate one disposition

Daniel Kade proposes a field-disposition ledger before the document advances. One row would cover each range: flag bits 0–3, the I bit, flag bits 5–15, Field-2 and Field-3. Each row would name the packet coordinates, current registry state, sender behavior, receiver behavior, assignment policy, change controller, reference and compatibility rule.

The ledger would also state the transition event. An unused range starts as Unassigned, transmitted as zero and ignored. An approved extension changes a defined range to Assigned, supplies its semantics and updates sender and receiver behavior. Older receivers can continue ignoring a newly meaningful position only if the extension's compatibility design permits that outcome. The registry entry and base specification should point to the same event.

This record would not allocate a value, choose an extension or replace IETF consensus. It would make the decision inspectable. The IANA port record illustrates why maintenance fields matter: revision 08 separately asks IANA to update the VXLAN port 4789 reference to the new document. A registry is not merely a number list; references and change custody tell operators which text governs.

The IESG statement on DISCUSS positions treats a DISCUSS as a request to resolve a serious issue, not as a veto or proof of rejection. That is the right frame here. Three rapid revisions show an active repair process. The remaining question is whether every representation of the field state will converge before publication.

Heng Lu's Policy Mirror warns against turning a mechanism into an authority claim. “Ignored by old receivers” describes processing; it does not grant permission to assign. The Minimum Initial Specification favours a narrow common boundary that leaves future change possible without hiding who may authorise it. Why BTW Media Exists supplies the reporting limit: revision 08 is evidence of a live specification mismatch under review, not evidence that production VXLAN is failing.

Sources

  1. VXLAN bis, Working Group revision 08
  2. VXLAN bis, previous revision 07
  3. Current VXLAN bis Datatracker record
  4. VXLAN bis document history
  5. VXLAN bis IESG ballot
  6. VXLAN bis shepherd write-up
  7. RFC 7348 — VXLAN
  8. RFC 8126 — IANA Considerations guidance
  9. IANA Service Name and Transport Protocol Port Number Registry, port 4789
  10. IESG statement on handling ballot positions
  11. Heng Lu — The Policy Mirror
  12. Heng Lu — Minimum Initial Specification
  13. Heng Lu — Why BTW Media Exists