摘要

  • RFC 9072 用可选参数类型 255 和两个八位位组的扩展长度，使 BGP OPEN 的可选参数区可以超过 255 个八位位组。
  • 更大的信封并不授予一揽子能力。不理解扩展格式的对等方预期会拒绝它，因此跨越旧上限必须建立在已验证的互操作性之上。

原有上限由所有能力共同占用

BGP OPEN 报文规定两个 BGP 发言者尝试建立会话时采用的条件。能力通过可选参数承载，但 RFC 4271 给整个可选参数区只分配了一个八位位组的长度字段。无论网络准备通告多少项能力，它们合计编码后都必须装进 255 个八位位组。

这个限制可能多年不显现。每项新增能力体量很小，每次本地变更看起来也彼此独立。然而，一组单独看都完全有效的功能，可能因为总长度而无法在基础格式中表达，并非其中任何一项有错。

RFC 9072 改变了这个信封。它保留可选参数类型 255，用来表明 OPEN 采用扩展格式。在旧格式长度与类型字段的位置之后，出现两个八位位组的扩展可选参数总长度；区内每个可选参数也改用两个八位位组表示自身长度。编码容量扩大了，但任何能力的语义并未改变。

报文有更多空间，不等于发送方获得对邻居更大的权力。发送方可以提出更大的能力集合，接收方仍然决定自己理解什么语法、支持哪些能力。会话实际建立，才是双方至少成功解析了此次协商的可观察证据。

类型 255 打开信封，也暴露边界

扩展格式有明确约束。RFC 9072 规定，旧的一字节可选参数长度应为 255，且绝不能为零；紧随其后、原本放置普通参数类型的八位位组必须也是 255。这个值指示兼容实现继续读取两字节扩展长度和后续参数序列。

当可选参数区不超过 255 个八位位组时，应继续使用基础格式。配置可以为测试强制采用扩展格式；即使内容本可装进基础格式，合规实现也必须接受扩展格式。一旦总量超过 255，扩展编码就是强制要求。

后一个转换才是真正的控制点。在上限以内，运营者可以一边保留基础表示，一边主动测试新解析器。超过上限后，同一能力集合不再存在兼容旧格式的表达方式：对等方接受扩展格式，发送方删减能力，或者会话无法建立。

标准采用的是显式失败的向后兼容策略。不实现 RFC 9072 的对等方预期会把类型 255 当作无法识别的可选参数，并以 Unsupported Optional Parameters 错误关闭连接。类型 255 若出现在扩展指示符之外，也必须按未知参数处理。协商不兼容因而会被暴露，而不是被悄然误解。

能力增长成为共同的兼容性预算

受益者是合法能力集合已无法装进原始信封的网络。它们不必仅仅因为总长度字段太短而关闭必要功能，未来能力的组合也获得了空间。但成本转移到了协调环节。

在切换扩展格式之前，每项能力都在消耗一个共享的 OPEN 预算。启用新功能的团队，未必是负责最后几个字节所影响的外部对等关系团队。缺少共同清单时，一项日常变更就可能成为迫使报文跨界的最后增量，并在远端暴露旧实现。

因此，在未达到 255 之前强制测试扩展格式很有价值：它把解析器就绪度与容量压力分开。证据应记录 OPEN 的精确长度、所用编码、对等软件版本、失败时返回的错误，以及重试是否删改了能力集合。

这项扩展不认证邻居，不保护 OPEN 报文，不验证路由策略，也不保证后续 UPDATE 处理安全。RFC 9072 明确没有改变底层 BGP 的安全与保密问题。把更大的信封误当成整体就绪证明，是赋予标准并不存在的权力。

证据与边界

RFC 9072 支撑类型 255 指示符、两字节长度、格式选择规则和旧对等方预期行为。RFC 4271 提供原始 OPEN 与错误模型，RFC 5492 提供能力框架，IANA 记录参数分配，RFC 4272 描述底层安全背景。把总长度视为治理预算属于分析。

这些来源不能证明任何具名运营商或厂商已经部署，也未量化不兼容对等方的比例，或规定触顶前的统一能力数量。扩展 OPEN 成功只能证明协商已被解析到足以建立会话，不能证明策略、选路或后续 UPDATE 正确。

来源