背景：BGP 路由泄漏的传统困境
在边界网关协议（BGP）网络中，自治系统（AS）之间依据客户关系（Customer-Provider）或对等关系（Peer-Peer）形成层级化的路由传播规则。正常情况下，路由应当保持“无谷”属性：从上游或对等方学到的路由只能向下宣告给客户，而不能反向传回。一旦某 AS 将从供应商或对等体收到的路由再次宣告给另一供应商或对等体，便形成路由泄漏，造成流量绕行、延迟增加甚至中断。
历史上，各网络需依靠手工配置前缀过滤和基于 IRR 的策略来约束路由传播，不仅繁琐且容易出错。Cloudflare 此前已推出 Radar 路由泄漏检测系统，但被动检测无法从根本上阻止泄漏。
RFC 9234 的核心机制
RFC 9234 试图将意图直接嵌入协议，引入两项关键扩展：BGP Role 与 Only to Customer（OTC）属性。
BGP Role 能力
该能力要求相邻 AS 在建立 eBGP 会话时协商彼此角色，可选值包括 Provider、Customer、Peer、RS（路由服务器）及 RS-Client。有效配对仅限五种（如 Customer-Provider、Peer-Peer 等）。若两端角色不匹配（例如一端配 Customer 另一端配 Peer），会话将被拒绝，从而提前暴露关系认知分歧。运营商可开启严格模式，要求邻居必须发送 Role 能力，否则断连；但在当前低采用率阶段，多数网络仅启用部分防护。
OTC 属性
OTC 是可选传递路径属性（类型码 35），记录首次将路由向侧向或向下发送的起源 AS 号。此后路由仅允许继续向下游客户传播，且属性值必须保持不变。支持 OTC 的路由器可自动丢弃违反规则的泄漏路由，无需人工策略。即便设备不支持 RFC 9234，因属性可传递，也应原样保留。
Cloudflare 的采用率观测与发现
Cloudflare 依托其全球对等网络，通过监测对等 AS 是否向自身发送 OTC 属性，构建了独特的采用率追踪方法。分析显示，RFC 9234 的部署仍在早期，且出现意外情况：两家大型一级运营商（Tier-1）在转发路由时剥离了 OTC 属性，破坏了端到端的泄漏防护链条。Cloudflare 已与这些运营商沟通，推动其允许 OTC 透传。
部署建议
- 在每一条 eBGP 会话上配置本地 BGP Role，与邻居协调一致；复杂多重关系需拆分为独立会话。
- 将 BGP Role 与 ASPA 验证结合，路由器可依据角色执行差异化路径校验。
- 早期采用者暂不宜依赖严格模式，以免割裂与未升级网络的连接。
- 持续监控 OTC 属性是否被中间 AS 篡改或丢弃。
对读者的意义与技术解读
对于运维与网络工程师，RFC 9234 代表了从“人工策略防泄漏”向“协议内原生防护”的演进。尽管当前整体采用率有限，且部分骨干网行为不合规，但主动在边界部署 Role 能显著降低因关系配置错误引发的事故。国内云厂商、IDC 及跨境链路运营方可以此为契机，梳理 EBGP 会话角色，减少手工过滤的运维负担。
需要注意的是，OTC 依赖全程透传，若上游 Tier-1 擅自剥离，本地防护将失效。因此读者在采纳新标准时，仍须保留传统前缀过滤作为兜底，并借助 Cloudflare Radar 等公开监测手段验证自身路由通告的合规性。随着支持度提升，BGP 路由安全生态有望逐步夯实。