Summary

  • 9 月 11 日的 draft-ietf-nvo3-rfc7348bis-08 拟将 15 个标志位、16 位 Field-2 和 8 位 Field-3 标成 Unassigned；新值须通过 IETF Review。
  • 第 5 节仍把后两个字段称为 Reserved，并要求发送方写零、接收方忽略。按照 RFC 8126，Reserved 与 Unassigned 并不是同一种注册状态。
  • 草案仍在区域主管跟进阶段，三项 DISCUSS 尚存，IANA 也在等待复审新版本。Daniel Kade 建议发布前制作逐字段处置账本；这不是 IETF 已宣布的控制措施。

数一遍坐标，矛盾就显出来

第 08 版草案的日期是 9 月 11 日。它要取代 2014 年的 RFC 7348，并把 VXLAN 从独立提交流带入 IETF 文档流，使需要占用头部位置的扩展可以在 IANA 登记。这不是简单换一份封面，而是在一项大规模部署的封装格式上建立未来修改入口。

入口尚未完成审批。Datatracker 当前记录把文件列为 Informational Internet-Draft，状态为 IESG Evaluation::AD Followup。页面显示仍有三项 DISCUSS，也说明这些讨论解决后票数足以通过。版本历史记下 9、10、11 日连续出现第 06、07、08 版；IANA 状态仍是 Version Changed - Review Needed。这些都是进行中的程序事实，不等于 RFC 已获批准。

RFC 7348原来描述一个 8 位 Flags 字段：除 I 位之外有 7 个保留位；随后是 24 个保留位、24 位 VNI，再跟 8 个保留位。未用位置都必须在发送时写零、接收时忽略。

第 08 版不移动任何物理坐标，却重新划分了语义。第 5 节把 Flags 扩成 16 位：第 4 位是 I 位，其余 15 位称为 Unassigned，同样要求写零并忽略。接下来的 16 位和末尾 8 位仍被称为 Reserved，处理规则也仍是写零、忽略。

第 8.2 节给出了另一张表。它要求 IANA 建立 VXLAN Fields 注册表组，覆盖 16 位 Flag field、2 字节 Field-2 和 1 字节 Field-3。除 I 位之外的 15 个标志位是 Unassigned，Field-2 的 16 位是 Unassigned，Field-3 的 8 位也是 Unassigned，总计 39 位。未来分配要依据 RFC 8126走 IETF Review。

可分配不等于可以先占

注册术语决定权限。Unassigned 表示该位置尚未分配，但仍可按既定政策申请；Reserved 表示通常不开放分配。两者都不等于厂商或运营者可以自行定义。这里承诺的门槛是 IETF Review，而不是“旧设备反正会忽略，所以先用起来”。

IESG 表决记录保存了这次修订为何发生。第 05 版一面把未使用标志位写成 Reserved，一面又规定“新值”经 IETF Review 分配。IANA 的审查指出，计划开放的位置应标为 Unassigned。IESG 的 DISCUSS 也要求把可分配与永久保留明确分开，并说明从 RFC 7348 的 24 位保留区中抽出前 8 位、并入 16 位 Flags，是有意的语义重组。

文档负责人说明确认未来分配政策是 IETF Review，不需要指定专家；不过说明书仍反映较早的 reserved 表述。第 08 版已经让 15 个标志位的两处名称一致，却没有让 Field-2、Field-3 在第 5 节和第 8.2 节完全对齐。

眼下的数据包行为并不含糊：这 24 位必须为零，接收方忽略。问题出现在未来转换上。如果注册表批准 Field-2 的某种含义，基础正文中的 Reserved 何时改成 Assigned？旧接收方继续忽略是否属于该扩展的兼容设计？哪份引用让实现者知道转换已经生效？

这不是漏洞或事故报告。冻结来源没有显示现网正在使用非零值，也没有显示任何厂商实现出错。头部长短和位坐标也没有改变。这里报道的是规范治理的接缝：注册表提供未来权利，报文正文规定当前行为，两者必须指向同一个状态转换。

给每一段位域一行处置记录

Daniel Kade 建议在草案推进前制作一份字段处置账本。每一行对应标志位 0–3、I 位、标志位 5–15、Field-2 或 Field-3，并同时写明报文坐标、当前注册状态、发送规则、接收规则、分配政策、变更控制者、规范引用与兼容条件。

账本还要规定触发事件。未用字段处在“Unassigned、发送为零、接收忽略”的状态；一项经批准的扩展只改变自己获配的范围，给出新语义和新的收发要求。旧实现能否安全忽略，必须由扩展的兼容设计说明，不能从“过去一直忽略”自动推出。

这张表不会替 IETF 分配编号，也不会预先批准扩展。它只把一次决定所需的证据放在同一处。IANA 的 4789 端口记录说明引用维护同样重要：第 08 版另行要求把 VXLAN 端口的规范引用更新到新文档。注册表保存的不只是数字，还有谁在什么文本下拥有修改权。

IESG 关于 DISCUSS 的说明把 DISCUSS 定义为解决重大问题的讨论请求，而不是否决或拒绝证明。连续三次修订显示修复正在发生。可验证的完成标准不是“又出了一个版本”，而是每个字段在注册表和报文正文里拥有同一处置与同一转换规则。

Heng Lu 的《政策之镜》提醒人们不要把机制事实升级为权力主张：“旧接收方会忽略”只是处理行为，不是分配许可。《最小初始规范》主张用小而清楚的共同边界保留本地创新空间。《BTW Media 为何存在》则限定了报道措辞：第 08 版证明一处正在审查的文本不一致，不证明生产 VXLAN 已经失效。

Sources

  1. VXLAN bis，第 08 版
  2. VXLAN bis，第 07 版
  3. VXLAN bis Datatracker 当前记录
  4. VXLAN bis 版本历史
  5. VXLAN bis IESG 表决
  6. VXLAN bis 文档负责人说明
  7. RFC 7348 — VXLAN
  8. RFC 8126 — IANA 注意事项指南
  9. IANA 服务名称与传输协议端口注册表，4789
  10. IESG 关于处理表决立场的说明
  11. Heng Lu — 《政策之镜》
  12. Heng Lu — 《最小初始规范》
  13. Heng Lu — 《BTW Media 为何存在》