摘要

  • RFC 8654 将 OPEN 和 KEEPALIVE 之外的 BGP 报文上限从 4,096 字节提高到 65,535 字节，但只能向已通告能力码 6 的对等体发送扩展报文。
  • 该能力是单条会话上的接收承诺，并非全网授权；混合支持可能迫使边界路由器丢弃合格属性、扣留 UPDATE，甚至撤回既有路由。

更大的报文空间始于双边承诺

RFC 4271 给出了明确基线：BGP 报文必须完整接收后才能处理，最大长度为 4,096 字节。随着地址族和功能增加，RFC 8654 对 OPEN 与 KEEPALIVE 之外的报文把上限提高到 65,535 字节。

真正控制行为的不是数字，而是能力协商。能够接收扩展报文的设备 SHOULD 通过 RFC 5492 机制通告 BGP Extended Message Capability。IANA 将其登记为能力码 6。发送方只有在从该会话的对等体收到这项能力后，才 MAY 发送扩展报文。

通告意味着真实义务：实现 MUST 能接收不超过 65,535 字节的报文。反过来，即使软件能够处理扩展报文，只要配置没有通告能力，就 MUST NOT 接受它。实现能力不能越过已配置的会话边界。

RFC 8654 还规定了一条独立的发送边界：发给未通告该能力的对等体的 NOTIFICATION 报文不得超过 4,096 字节（MUST NOT）。

一条链路的容量不会自动传给下一条

超过 4,096 字节的 UPDATE 可能从支持扩展报文的对等体进入，又需要向未通告能力的邻居传播。第一条会话只授权接收，没有替第二条会话作出决定。

RFC 8654 规定，中间设备 SHOULD 尝试移除符合 RFC 7606 “attribute discard”条件的属性来缩小报文。这一手段受到严格限制：可丢弃属性不得影响路由选择或安装。如果 UPDATE 仍然过大，RFC 8654 禁止将其发给该邻居（MUST NOT）；若 NLRI 此前已向该邻居通告，则必须从服务中撤回。

受益者可能是需要承载更多属性或 NLRI 的应用。成本则可能落到下游邻居和依赖该路由的用户身上，因为通告无法跨过 4,096 字节边界。于是，表示容量会变成传播乃至可达性决定。

内部一致性是管理层的部署问题

在同一自治系统中，RFC 8654 指出，只有全部 iBGP 路由器都通告该能力，才能保证一致视图。否则，运营者应考虑是否应该向外部对等体通告扩展报文能力。

稳健顺序是：先逐会话盘点能力，测试最大报文的接收与解析，测量缓冲区余量，识别全部内外边界，并在渐进部署中观察被删除的路由和被丢弃的属性。之后才能决定哪些外部会话可以看见能力码 6。

RFC 8654 并没有解决 BGP 原有安全问题。更大的缓冲区会增加故意或意外资源耗尽的暴露面，重排报文和丢弃属性也会消耗处理资源。收到能力既不证明路由合法，也不证明载荷安全，只证明对等体声明了接收容量。

证据与边界

RFC 8654 定义扩展尺寸、例外、协商和混合边界；RFC 4271 提供原始上限；RFC 5492 定义能力通告；RFC 7606 约束属性丢弃；IANA 注册表确认当前能力码 6。

来源没有说明哪些网络正在启用该能力，没有给出通用内存成本，也没有保证属性丢弃总能让 UPDATE 变小。权力、授权、受益者、成本与反事实属于基于标准的分析推论。

来源