要約

  • IESGは10月27日、VXLAN改訂案を情報提供用RFCとして出版することを承認した。11月2日時点ではRFC Editorが著者の返答を待ち、IANAの作業も進行中だ。
  • パケットの寸法とビット位置はそのまま、空きフラグの公的な割り当てにIETF Reviewを求めるのが主な変更だ。

データセンターのVXLANパケットは着替えない。しかし、次のメーカーが「このゼロのビットには自社の新機能という意味がある」と言い出すなら、話は別だ。改訂草案の第12版は、その主張を共通の仕様にするための入口を新たに置く。現在の形式を守りながら、将来の意味を決める手順を変える。

IESGの決定記録には、2026年10月27日にInformationalとして承認されたことが載る。一方、Datatrackerは第12版をまだInternet-Draftと表示する。RFC Editorは著者の回答待ちで、IANAの措置は進行中だ。承認済みという事実と、代替RFCや登録簿が完成したという主張は分けなければならない。

2014年のRFC 7348は独立投稿だった。稼働中のVXLANを記録し、IANAに関する節ではUDPポート4789の割り当てに触れた。ヘッダーの空きビットに将来どんな拡張を置くかを管理する登録簿はない。新草案は仕様をIETF文書の流れへ移し、ヘッダー拡張に公的な参照先と番号を用意する。

変更は一見すると小さい。従来Reservedとされた24ビットのうち、先頭8ビットを追加フラグとして再分類する。その結果、16ビットの「VXLAN Flags」の後に16ビットの「Reserved-1」が続く。各ビットの位置もヘッダー全体の長さも変わらない。第4ビットは引き続きVNIの存在を示すIフラグで、IがゼロのパケットはVTEPが破棄する。残る15のフラグ位置は当初未割り当て。送信側はゼロにし、受信側は無視する。旧機器が見るビット列は変わらない。

制度の変更はIANAへの要求にある。草案はVXLAN登録簿群と「VXLAN Flags」登録簿を求め、ビット番号、説明、定義文書を記録させる。新しい割り当てには IETF Review を使う。RFC 8126によれば、IESGの手続きを通ったIETF文書系列のRFCが必要だ。情報提供用RFCでもよいが、製品発表だけで公的な番号は取れない。ポート4789についても、登録上の連絡先をIETF Chair、割当先をIESGに変えるよう求める。

有限のビットを二つの拡張が別々の意味で使えば、受信側はパケットから正解を選べない。登録簿は衝突を表面化させ、実装者が定義をたどれるようにする。その代償は審査の時間だ。私的な実験はすぐにできても、共有の意味を得るにはRFCの工程を通る。

番号を得ても設備は自動更新されない。運用者は拡張を採用するか自分で決め、旧世代と新世代のVTEPを混在させて試す必要がある。草案にはまだ定義されていないフラグの運用測定はない。判断を変えるのは具体的な拡張RFC、混合環境のパケット記録と障害時の動作だ。

2014年の文書は既存の稼働を記した。2026年の草案は同じパケットを保ち、次の公的な変更の鍵をIETF審査に移す。動かないヘッダーにも、権限の引っ越しは起こる。

草案の状態 · 第12版 · IESG決定 · RFC 7348 · RFC 8126