摘要

  • IESG 于 10 月 27 日批准 VXLAN 修订草案按信息类文件出版。截至 11 月 2 日，它仍是 Internet-Draft，RFC Editor 等待作者回复，IANA 动作尚在进行。
  • 草案不增加头部长度或改变位位置，却要把空闲标志位纳入 IANA 名册；未来公开分配须走 IETF Review。

数据中心明天发出的 VXLAN 包仍是今天那个包。有人想让其中一个目前写零的位代表新功能，麻烦才开始：第 12 版草案给这个新含义安排了一道审查门。它保住现有报文，同时重新分配决定下一次扩展的权力。

IESG 决定记录显示，修订稿已在 2026 年 10 月 27 日获准按 Informational 类别出版。Datatracker却仍把第 12 版列为 Internet-Draft：RFC Editor 因等待作者输入而暂停，IANA 动作进行中。批准与出版是两件事；草案里要求的登记簿也还不能当成已经完成的设施。

2014 年的 RFC 7348是独立投稿，记下已经部署的 VXLAN。它的 IANA 章节只谈 UDP 目的端口 4789，没有建立逐位管理未来标志含义的名册。新草案要把规范移到 IETF 文件流，让后续头部扩展有公开定义和正式编号。

位级改动很克制。旧文件把 24 位称作 Reserved；新草案把它们的前 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 年的 RFC 把已经运行的协议写下来；2026 年的草案保留这些字节，把下一次公共改动交给 IETF 审查。报文纹丝不动，未来那把钥匙却换了保管处。

草案状态 · 第 12 版 · IESG 决定 · RFC 7348 · RFC 8126