摘要

  • RFC 9792 为 OSPFv2 和 OSPFv3 定义了可变长度的 Prefix Extended Flags 子 TLV，但它自己没有给任何一位赋予属性含义。
  • 目前 IANA 注册表已有 RFC 9929 定义的 U 与 UP 两位；这仍然不能单独证明实现、启用、发送、接收或转发生效。

RFC 9792 最有分量的一句话，是它没有宣布新的路由动作：本文档目前未定义任何位。2025 年 6 月发布时，标准给出了装载未来属性的格式，也给出了在容器缺席、缩短、未知、重复或畸形时的处理边界。它创建的是语法空间，不是已经成立的前缀事实。

容器不是属性

在 OSPFv2 中，该子 TLV 的类型为 11，置于 RFC 7684 的 Extended Prefix TLV 内；在 OSPFv3 中，类型为 37，可置于 RFC 8362 的三类前缀 TLV，或 RFC 9513 的 SRv6 Locator TLV 内。

其值按 32 位块排列，bit 0 是首块的最高有效位，bit 32 是第五个字节的最高有效位。长度必须是 4 的倍数；否则整个承载它的 LSA 都是畸形的，必须被忽略。发送端还必须在最后一个值为一的位所在块之后截断。接收报文没有覆盖到的已定义位，按零处理。

因此，“没有”只有否定含义。子 TLV 不存在、尾部块未发送或块内全为零，都不能构成积极属性。未分配位必须以零发送，接收时忽略。旧实现依据 RFC 3630 或 RFC 8362 的扩展规则忽略未知子 TLV。兼容性来自不做推断，而不是暗中设定一个默认属性。

重复实例也不会合并。同一父 TLV 内若出现多个实例，接收端只采用第一个，忽略其余，并应限速记录错误。所谓“出现了两次”不是两份证据，更不是按位或运算。

后来的注册并不改写历史

发布时没有定义位，与今天的注册表已有位，两者都是真的。实时 IANA OSPFv2 和 OSPFv3 注册表已经把 bit 0 和 bit 1 分别分配给 U、UP，依据是后来的 RFC 9929；bit 2–31 仍未分配。RFC 9792 先定义地址空间，RFC 9929 才定义第一批属性。

即使读到一位为一，证据也没有结束。RFC 9929 令 U 表示不可达前缀，UP 表示计划中的不可达；没有 U 时，UP 必须被忽略。对 OSPFv2，两位只有在度量为 LSInfinity 时有效。对 OSPFv3，还必须同时满足 LSInfinity 以及父 Prefix Options 中的 NU 位。属性是多个字段共同形成的条件，不是解码器里一盏孤立的灯。

旧的固定字段也继续承担控制作用。RFC 5340 的八位 OSPFv3 Prefix Options 对 NU、LA、P、DN 等给出了路由计算语义。RFC 7684 的 OSPFv2 父 TLV 自有固定标志字节；RFC 9792 还要求先用完其中未用的固定标志，再分配扩展位。

把观察写成证据链

严谨的运营结论应逐层书写：IETF 文档定义了容器；IANA 分配了位；某软件版本声明实现；本地配置启用；完整 LSA 中出现合法的首个实例；接收端保留并解释；路由计算改变；FIB 改变；流量结果改变。每一层都需要自己的来源，缺失的层不能用前一层代替。

RFC 8126 所说的 IETF Review 只是控制码点分配的治理程序，不是网络遥测。RFC 9792 表示没有引入超出底层 OSPF 的新安全问题，也不代表畸形输入可以轻视；RFC 8362 要求稳健拒绝，避免扩展触发协议失效。

RFC 9792 的真正价值，正是在第一位获得名字之前就已经出现：它既为将来的含义留下空间，也为证据不足时拒绝含义制定了边界。

资料来源