摘要

  • RFC 5492 让 BGP 路由器在 OPEN 中列出可选能力。只有双方都公告的能力才能用于该会话；收到不认识的能力必须忽略，而本地业务必需的能力未被对端公告时，才可以用具名错误停止会话。
  • John Scudder 的公开署名记录还包括 RFC 8810 对能力代码私用区的整理，以及他与 Enke Chen 合著的 RFC 9072 对 OPEN 可选参数 255 字节上限的扩展。三份文档共同说明：扩展性依赖双边证据、薄而明确的登记册和一个不伪装兼容的失败边界。

第一次 OPEN 失败，不一定是网络断了

值班界面很容易把 BGP 故障压成两种颜色：会话 Established，或者会话 Down。能力协商揭示了第三种更重要的状态。物理链路、IP 可达性和 TCP 都可能正常，两台路由器却无法完成预定的 BGP 工作，因为它们没有对同一项扩展留下共同声明。

RFC 5492 回顾的基础行为是：OPEN 带有接收方不认识的 Optional Parameter 时，接收方会终止 peering。这个规则清楚，却让协议扩展付出很大代价。一项新功能如果需要新的参数，旧设备可能连原有的普通路由交换也一起失去。

Capability Advertisement 的选择更窄。发送方仍在 OPEN 中表达自己支持什么，但把各种能力放进一个共同认识的 Capabilities Optional Parameter。接收方可以解析容器，同时对其中尚不认识的能力保持无知。未知内容不会因此取得效力，也不必摧毁整个会话。

RFC 5492 的作者是 John Scudder 与 Ravi Chandra。Scudder 后来单独署名 RFC 8810，调整 BGP Capability Code 的登记规则；他又与 Enke Chen 合著 RFC 9072，扩展 OPEN 可选参数的长度表示。IETF Datatracker 档案 将这些文档连接到其公开的路由标准工作记录，并提供本人的公开肖像。

署名能够证明参与，不能制造个人主权。RFC 是共同审阅的 IETF 标准文本，机制还要经过实现者、设备厂商、IANA、运营者和真实网络。本文把 Scudder 作为公开记录的连接点，不把 BGP、共识、实现或运行结果归为一人的作品。

三个字段只承担最小共同职责

一项 capability 由三个部分组成：一字节 Capability Code、一字节 Capability Length，以及按该 code 对应规范解释的可变长 Capability Value。Code 解决“这是什么”，Length 解决“这个值到哪里结束”，Value 才携带能力特有的信息。

这个容器刻意不替所有扩展规定业务语义。共同层只提供可解析、可分隔、可登记的骨架。某项能力若允许相同 code 携带多个不同 value，引入该能力的 RFC 必须说明如何理解。协议因而可以增长，而不必让一个总规范预先占有未来的每个决定。

字段正确也有证据上限。已登记的 code 只指向共同语义，不证明对端实现没有 bug；合理的 length 只避免解析越界，不认证消息来源；value 可被成功读取，也不等于本地配置允许使用。

RFC 5492 建议在 OPEN 中只放一个 Capabilities Optional Parameter，并把多项 capability TLV 收在其中。不过为兼容早期实现，接收方必须接受多个同类参数，并把合并后的能力集合按相同方式处理。完全重复的实例不增加含义，但也不能让解析器崩溃。标准约束的是可观察语义，不是某个厂商恰好生成的唯一字节布局。

双方都说“支持”，功能才有资格出现

RFC 5492 最重要的句子不是某个 code 的分配，而是双边规则：只有一项能力被两个 peer 都公告后，才可在这条 peering 上使用。任何一方没有公告，就不能使用。

这避免把“软件可能支持”偷换成“本次会话已经同意”。同一版本可以因配置、地址族、邻居类型或许可条件不同而公告不同能力。设备数据表、版本说明和配置模板都是旁证；OPEN 才是两台运行中路由器在这个时刻对彼此留下的声明。

双向公告也不是中央许可。IANA 分配 code，不能替运营者开启功能；RFC 定义行为，不能替设备生成配置；一端宣布支持，也不能把扩展强加给另一端。共同登记保证双方读到同一个名字，实际采用仍由两个承担后果的节点分别表达。

监控若只显示一个合并后的 supported=true，就把这项设计重新弄丢。应保存 local OPEN、remote OPEN、各自 value、方向、地址族和能力专属语义。双方都公告是必要条件，不必然表示功能在两个方向做相同的事。

“我不认识你”与“我不能没有你”必须分开

收到本地不支持或不认识的 capability 时，RFC 5492 要求忽略。不得仅因它未知就发送 Unsupported Capability，更不得因此终止会话。这条规定为渐进升级留下空间：旧节点不假装理解，新节点也不能凭一个可选公告让所有旧邻居掉线。

真正可以停止的是另一种情况。本地可能把某项能力定义为建立这条会话的必要条件，例如预定要交换某个地址族，而对端没有公告相应能力。此时本地可以发送 Unsupported Capability NOTIFICATION 并终止；通知的数据必须列出造成决定的能力。

“必要”不是协议替全世界作出的判断，而是本地对这条关系用途的决定。若停止，RFC 建议不要自动重建。否则系统会不断建立 TCP、交换相同证据、发现相同缺口、再次关闭，把明确的不兼容变成没有进展的抖动。

所以同样带有 unsupported 字样的日志，可能代表相反方向。收到陌生新能力时，应继续基础互操作；需要的能力没有出现时，可以拒绝一个无法完成任务的关系。把两种情形压成“能力不匹配”，会让排障者误判应该升级谁、改什么，甚至触发错误的自动重试。

旧设备的降级连接不是完整成功

更老的 BGP speaker 可能连 Capabilities Optional Parameter 这个容器都不认识，并以 Unsupported Optional Parameter 拒绝 OPEN。RFC 5492 建议支持能力机制的一端重新连接，这一次不发送容器。

这是一条兼容桥，而非合格证明。若会话只需基础 IPv4 路由，降级后也许仍有价值；若合同目标是特定地址族或依赖能力的功能，一个 Established 的低配会话可能没有完成任何预定工作。

运维记录必须把第一次拒绝、第二次省略、随之丢失的能力和最终路由集合串起来。只看“会话后来起来了”，会把能力降级误报成修复。兼容性允许保留可共享的最小集合，不要求新业务永远屈从于最低共同功能。

私用编号一进入互联就不再私用

能力容器之所以能被独立实现共同解析，是因为同一个 code 必须指向同一含义。RFC 5492 最初把 128–255 设为 Private Use。RFC 8810 根据后来的实践直言，这个范围不仅无用，还会让实现者困惑。

原因不在实验室，而在产品相遇。厂商甲把 130 当作功能 A，厂商乙在自己的封闭环境把 130 当作功能 B；各自在内部都能运行。一旦互联，同一个字节同时承载两个语义，原本用于证明兼容的字段反而制造误认。

RFC 8810 重新划分：1–63 保持 IETF Review，64–238 采用 First Come First Served，239–254 用于 Experimental Use，255 Reserved。实验区明确不应长期使用，也不应用在出货产品里。公开登记用极薄的权力解决碰撞：保存唯一编号、说明与参考，而不是判断某网络必须采用该功能。

修复没有抹去历史不确定性。工作开始于对已知私用值的调查，并把若干 prestandard 使用写入记录；RFC 同时承认无法保证找到全部私用。仍存在的冲突要作为冲突处理，不能因为登记册更新就假装旧世界已经整齐。

协商新能力的信封也会装满

OPEN 的 Optional Parameters Length 原本只有一字节，因此所有可选参数合计不能超过 255 字节。单项 capability 很小，持续增加的 capability 却会让负责描述扩展的空间本身触顶。

RFC 9072 没有让所有 OPEN 一夜改格式。总长度不超过 255 时，通常仍应使用基础编码；需要更长时，Optional Parameter type 255 作为特殊标记，后接两字节总长度，各个 Optional Parameter 的 length 也扩为两字节。实现即使收到不超过 255 字节的 extended form，也必须能接受。

新旧节点的兼容边界写得很诚实。只要新节点的参数仍装得进旧信封，双方没有额外互操作问题。一旦实际需要超过 255 字节，新节点必须发 extended form；旧节点会把 255 看成不认识的 Optional Parameter，并预期以 Unsupported Optional Parameters 关闭连接。

这不是兼容失败的尴尬，而是防止假兼容的保护。旧解析器不能理解消息，明确停止比悄悄截断更安全。向后兼容保留共同子集，却不会凭标准愿望给旧实现增加不存在的容量。

更长的 OPEN 仍不带来身份认证或保密。RFC 9072 明确没有改变 BGP 原有的安全与机密性问题。能多写能力，不等于这些声明更可信。

最小共同规则最终要回到运行证据

卢恒的 Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption 为 Sofia Ren 提供一把分析尺。全球共同层只需要能解释的容器、唯一 code、双向使用条件、有限错误和可扩展长度；能力的具体设计、本地是否强制、何时升级，则留给接近后果的人。

这是一项 2026 年的编辑框架，不是对 Scudder、Chandra、Chen 或 IETF 私人动机的推断。三份 RFC 的依据始终是其公开文本。

Running-Code Primacy 给出下一步核验。OPEN 比产品宣传更接近事实，因为它记录两台运行中设备实际对彼此声明什么；但它仍只证明声明。能力是否真正生效、消息是否正确解析、路由是否按预期交换、NOTIFICATION 是否可归因、转发是否成功，都要继续观测。

Capability Advertisement 的价值不是让登记册或某位标准作者决定所有未来。它让两个独立系统用很小的共同语言说清楚：我能做什么、我不能假设什么、缺少什么会让我停止。扩展由此可以自愿进入会话，而兼容性的终点不会被一盏虚假的绿灯掩盖。

来源