Cloudflare 2026 年 IPv6 路由泄漏：当出口策略失去最后一道约束

摘要

Cloudflare 表示，2026 年 1 月 22 日的一次清理删除了已经废弃的 Bogotá 前缀列表引用，却留下包含 route-type internal 和 accept 的生成式 IPv6 出口策略项。
最后一个狭窄匹配条件被删除后，该策略项没有随之消失或转为拒绝；其有效匹配范围反而扩大，而渲染后的配置在语法上仍可被路由器接受。
自动化于 20:25 UTC 在一台 Miami 路由器上运行，影响随即开始；20:50，操作人员手动恢复路由策略并暂停自动化。Cloudflare 将公开影响界定为 25 分钟，且仅涉及 IPv6。
Cloudflare 报告 Miami 至 Atlanta 方向出现拥塞，部分客户流量经历更高时延和更高丢包；路由器过滤器丢弃了不属于下游方向的流量，峰值约为 12 Gbps。这些均为 Cloudflare 披露的测量结果。
Cloudflare 描述了从对等网络 Meta AS32934 学到的路由，经 AS13335 向转接提供商 AS3356 错误导出的情形，并将事件归为 RFC 7908 Type 3 与 Type 4 路由泄漏的混合。
对前缀 2a03:2880:f077::/48 的限定 RIPEstat 查询返回 1,548 个事件，其中 1,440 个事件的路径同时包含 AS13335 与 AS32934。这只能佐证异常路径在公共观测系统中可见。
RPKI 源验证能够检查前缀的起源 AS 是否获得授权，却不能单独阻止起源仍然正确、邻居关系却不允许的路径泄漏。
有效的单路由器试运行必须在发出更新前比较路由集合与逐邻居 Adj-RIB-Out 的变化，并在发现对等、提供商、客户或运营方来源关系违规时自动停止。
回滚不能只修复当前路由器；它还必须修复生成配置的源头、暂停自动化、验证外部撤回结果，并由具名责任人决定何时恢复。

一次有限事件为何暴露出更大的控制问题

这起事件的技术边界很窄：一台 Miami 边缘路由器、一个 IPv6 出口策略错误、25 分钟公开影响。然而，它揭示的控制问题并不局限于某台设备或某条前缀。真正需要回答的是：当自动化系统删除一个已经过时的狭窄约束时，运营方如何证明生成后的策略并未因此获得更大的出口权限？

这里的关键并非配置是否能够解析。路由器可以接受一段语法正确但语义过宽的策略。持续集成系统也可能确认模板渲染成功、字段类型正确、候选配置能够加载，却没有回答这段配置究竟会匹配哪些路由、会向哪些邻居开放，以及这些邻居关系是否允许相应传播。

Cloudflare 对事件的解释表明，原始变更意图是清理 Bogotá 基础设施升级后已不再需要的站点本地前缀列表引用。问题在于，删除这些引用之后，生成策略中的相应项仍保留 route-type internal 匹配和 accept 动作。原本帮助限制匹配范围的最后一个狭窄条件消失了，剩余条件却仍能匹配非外部路由，包括通过 iBGP 学到的路由。

这不是“空配置”意义上的完全无条件匹配，而是语义上的约束不足：策略项仍有谓词，但这个谓词比原设计允许的范围宽得多。对审批者而言，源代码差异可能表现为删除废弃引用；对运行路由器而言，有效结果却是一个更宽的接受集合。两者之间的差异，正是本次事件的问责核心。

完整时间线与事实边界

以下时间均为 2026 年 1 月 22 日 UTC，且依据 Cloudflare 的事件说明：

时间	已披露事件	证据属性
19:52	删除废弃 Bogotá 前缀列表引用的仓库变更被合并	Cloudflare 对变更历史的说明
20:25	自动化在一台 Miami 路由器上运行，影响开始	Cloudflare 对内部运行与影响起点的说明
20:40	调查开始	Cloudflare 披露的响应时间线
20:44	事件被正式提出	Cloudflare 披露的响应时间线
20:50	操作人员手动恢复路由器策略，并暂停自动化	Cloudflare 披露的控制面处置
21:47	仓库中的源变更被回退	Cloudflare 披露的源状态修复
22:07	自动化被判断为恢复健康	Cloudflare 披露的恢复判断
22:40	自动化解除暂停	Cloudflare 披露的恢复时间线

Cloudflare 将公开影响窗口界定为从 20:25 到 20:50，共 25 分钟，并表示事件只影响 IPv6。这里必须区分“影响停止”和“所有恢复工作完成”：20:50 的人工路由策略回退结束了公开影响窗口，但仓库源变更直到 21:47 才被回退，自动化直到 22:07 才被判断为健康，并在 22:40 才恢复运行。

这一时间差证明，运行路由器状态、自动化源状态和自动化服务状态不是同一件事。运行设备可以先被人工修正，而配置生成源仍然保留错误；源代码可以随后回退，而自动化仍需保持暂停，等待健康判断。若把其中任何一个状态误称为“已经恢复”，都可能留下再次下发错误配置的窗口。

Cloudflare 报告，事件造成 Miami 至 Atlanta 方向拥塞，受影响链路时延升高，部分 Cloudflare 客户流量出现更高丢包；路由器防火墙过滤器丢弃了目的地并非下游网络的流量，丢弃流量峰值约为 12 Gbps。这些数字与影响描述来自 Cloudflare，公共路由收集器并不能独立测量相应内部链路、客户流量或丢弃量。

同样，IPv6-only 的影响范围是一项重要但有限的事实。它说明 Cloudflare 将这次公开影响限定在 IPv6，不足以单独证明 IPv4 与 IPv6 在模板、自动化权限、路由器进程、控制面组件或运营职责上具有怎样的隔离。没有公开证据时，不能从结果边界反推出未披露的私有架构。

出口策略为何会在“删除约束”后扩大权限

生成式路由策略通常有两个观察视角。开发者看到的是模板、数据模型、前缀集合及其差异；路由器执行的是模板渲染后形成的完整策略。删除源代码中的一行，不等于从有效策略中删除一个完整行为。

可以把本次机制抽象为一个接受条件：

原有效集合 = route-type internal ∩ Bogotá 指定前缀集合

当 Bogotá 前缀集合被删除，而生成器仍保留策略项时，结果可能变成：

新有效集合 = route-type internal

如果该策略项末尾仍然是 accept，那么变化不是“少匹配一些旧前缀”，而是“接受所有符合剩余宽泛条件的路由”。由于 route-type internal 可覆盖内部路由，包括经 iBGP 获得的路由，邻居学入但在自治系统内部传播的路由也可能进入出口候选集合。

语法检查通常发现不了这种问题。策略项仍然有合法名称、合法匹配表达式和合法动作。候选配置可以成功渲染，路由器也可以接受它。只有语义检查才能发现：某个接受项失去了最后一个前缀、社区或邻居关系约束，其匹配路由集合相对运行策略发生了非预期扩张。

因此，审批对象不能仅是源代码差异。最少需要同时检查：

变更意图描述了什么；
源模板及数据删除了什么；
渲染候选策略实际包含什么；
候选策略会匹配哪些路由；
运行策略此前匹配哪些路由；
每个邻居的拟议出口集合发生了什么变化；
变化是否符合该邻居的业务关系和传播权限。

当最后一个狭窄谓词被删除时，生成器应该采用明确的安全语义。例如，直接删除整个策略项、将其变为拒绝、阻止构建，或要求人工确认新的完整约束。最危险的行为是静默保留剩余宽泛谓词和接受动作，因为它把看似缩减配置的修改转化为权限扩大。

八个不能相互替代的证据层

路由事件分析经常把“配置”“路由”和“流量”混为一谈。实际上，至少要分开观察以下证据层：

1. 源意图

源意图解释变更为什么发生。本案中，Cloudflare 表示目的是删除基础设施升级后已经废弃的 Bogotá 前缀列表引用。意图能够解释操作目标，却不能证明生成结果安全。

2. 渲染后的候选策略

这是自动化系统准备交付给路由器的完整配置。它应当是语义评估的主要对象，因为源模板中的局部删除可能改变最终策略项的整体含义。

3. 有效运行策略

运行设备上实际生效的策略可能与候选策略不同，原因包括部分下发、人工覆盖、顺序差异、设备行为或先前状态。只有读取运行状态，才能确认候选配置是否真正成为执行规则。

4. Loc-RIB

Loc-RIB 表示本地 BGP 决策后保留的路由视图。某条路由存在于 Loc-RIB，并不等于它可以向任意外部邻居传播。它只是出口策略评估的输入之一。

5. 逐邻居 Adj-RIB-Out

Adj-RIB-Out 代表准备向特定邻居通告的路由集合。不同实现可能以不同方式呈现这一概念，但问责要求不变：验证必须逐邻居进行，不能只查看全局路由表或总路由数。

6. 已发出的 BGP 更新

候选出口集合仍不等于已经在网络上传播的更新。需要通过路由器更新日志、邻居状态或其他可审计数据确认哪些宣告和撤回真正离开了自治系统。

7. RIB、FIB 与流量证据

控制面选路、转发表安装和实际流量结果属于不同层次。某条路径出现在 BGP 视图中，不自动证明流量经过该路径；流量拥塞、丢包和过滤器丢弃则需要独立遥测支持。

8. 外部观测

RIPE RIS、BGPlay 等外部系统能够证明某些路径被公共观测点看到。它们有助于确认异常传播已经越过网络边界，却不能重建完整内部配置、所有邻居状态或所有未被观测点捕获的路由。

一条可信的事件证据链，应当把这些层次按照时间和对象关联起来，而不是让其中一个层次代替其他层次。源代码合并记录不能代替运行策略；运行策略不能代替实际更新；公共 AS 路径不能代替流量测量；RPKI 状态也不能代替邻居关系授权。

关系策略不能退化为“前缀和起源都有效”

BGP 的传播安全不仅取决于前缀是否存在、起源 AS 是否获得授权，还取决于一条路由是从谁那里学到、准备向谁发送。

一个简化的商业关系模型通常包含客户、提供商和对等方。客户路由通常可以向其他邻居传播，因为客户向运营方购买到达更广泛网络的连接；从提供商或对等方学到的路由，通常不应再向另一个提供商或对等方转送，否则运营方可能无意中提供了转接服务。真实网络政策会更复杂，但“来源关系”和“出口关系”仍必须独立进入策略判断。

Cloudflare 描述了从对等网络 Meta AS32934 学到的 IPv6 路由，经 Cloudflare AS13335 朝转接提供商 AS3356 导出的情形。公司公布的示例前缀是 2a03:2880:f077::/48，示例路径为：

64112 22850 174 3356 13335 32934

这个路径能够显示 AS13335 与 AS32934 同时出现在外部可见的传播链中，并与 Cloudflare 披露的泄漏方向相符。但 AS 路径本身不是完整商业合同记录。不能仅凭号码顺序推断所有相邻网络之间的具体合同条款，也不能将一个观测路径扩大为未披露的全部拓扑。

正确的策略模型应当为每条路由保存或可靠推导至少两类属性：

路由从哪一类邻居进入：客户、对等方、提供商，或运营方自身起源；
路由准备向哪一类邻居导出。

在此基础上，出口许可应表达为明确的关系矩阵，而非只依赖前缀或起源有效性。例如，从客户学到的路由、运营方自身起源的路由、从对等方学到的路由和从提供商学到的路由，需要分别进入不同的出口约束。即使前缀本身有效、起源 AS 正确，只要“学入关系—导出关系”组合不被允许，策略就必须拒绝传播。

可信社区可以帮助标记路由来源和允许的出口范围，但社区不是天然可信的。运营方需要控制哪些会话可以设置或保留这些标记，在网络边界清除未经授权的值，并验证内部重写不会丢失关系信息。否则，一条形式上存在的社区规则可能在最需要它时被错误值绕过。

Cloudflare 将事件描述为 RFC 7908 Type 3 与 Type 4 路由泄漏的混合。RFC 7908 提供了路由泄漏类型的分类语言，但分类并不自动证明本案每条路由的私有关系属性。最稳妥的表述是：Cloudflare 根据其内部关系和传播信息作出这一分类；公开路径能够支持异常传播的可见性，却不能独立还原全部商业关系。

单路由器试运行必须观察路由变化，而不只是配置成功

Cloudflare 表示自动化首先在一台 Miami 路由器上运行。这种有限部署能够约束初始范围，但“只改一台设备”本身并不等于有效的安全试运行。

如果试运行的成功标准只是配置加载成功、BGP 会话保持建立、CPU 没有异常、设备仍可响应，那么一段语义过宽的出口策略完全可能通过。真正的试运行必须围绕路由集合变化设定停止条件。

在实际向邻居发出更新之前，系统应通过候选策略评估或影子计算完成以下比较：

候选策略相对于运行策略增加和删除了哪些匹配路由；
每个邻居的拟议 Adj-RIB-Out 增加和删除了哪些前缀；
新增路径来自客户、对等方、提供商还是运营方自身；
新增路径是否包含不允许的“对等方至提供商”“提供商至对等方”或类似关系组合；
路由数量、地址空间、路径属性和社区是否超出批准范围；
IPv4 与 IPv6 的变化是否分别符合预期；
是否出现与变更目标无关的站点、区域或自治系统。

一旦发现关系违规，系统应在发出更新之前自动停止，而不是把告警交给人工判断后继续部署。对于不能完全预计算的设备或策略，也应采用不会向真实外部邻居传播的影子会话、路由反射测试环境或等效机制，尽量将语义检查提前。

若预发检查通过，单路由器阶段仍需设置严格观测窗口。需要比较实际运行策略、逐邻居出口状态和已发更新，并从外部收集器检查是否出现新的异常路径。试运行不能依赖“没有客户工单”或“设备没有报错”来判定成功，因为控制面泄漏可能先被外部网络看到，流量影响也可能滞后或仅发生在部分路径上。

自动停止规则应当优先于继续扩大发布。只要关系违规、路由集合增长异常、未知社区出现、外部路径偏离预期，或内部与外部证据不一致，自动化就应冻结后续设备，保留当前状态，并将控制权移交给具名操作人员。

RPKI 能证明什么，不能证明什么

RPKI 为互联网号码资源建立加密可验证的授权框架。ROA 可以表达某个前缀允许由哪个 AS 起源，以及允许的最大前缀长度。基于 RFC 6811、RFC 8210 和 RFC 7115 的起源验证机制，可以把接收到的路由状态判断为有效、无效或未找到，并据此实施本地策略。

但起源授权与传播路径授权是两个不同问题。本案所述泄漏路由仍以 Meta AS32934 为起源。即使相应起源授权有效，也只能说明该起源 AS 与前缀之间的授权关系没有因为这次传播而改变。它不能说明 Cloudflare 是否可以把从对等方学到的路由再通告给转接提供商。

因此，这起事件不应被称为起源误宣告，也不能把 RPKI 描述成单独足以阻止此类关系泄漏的机制。RPKI 起源验证仍然重要，因为它能限制另一类前缀起源错误；只是它的安全边界没有覆盖完整 AS 路径与邻居关系。

RFC 9234 的 BGP Roles 与 Only-to-Customer 属性面向不同层面。BGP Roles 让会话双方协商关系角色，OTC 则为传播路径提供一种可用于识别关系违规的属性。它们能够在本地出口生成器出错时提供独立控制方向，但不能在没有部署证据的情况下被描述为已经保护了本次事件中的私有会话。

可信社区又是另一层控制。它们可以编码“来自客户”“来自对等方”“不得向某类邻居导出”等语义，但有效性取决于社区的设置、清洗、保留和策略执行。外部过滤则可以在接收方阻止不合理前缀、异常路径或不符合关系预期的宣告。接收方过滤有助于缩小损害，却不能替代宣告方对自身出口权限的责任。

ASPA 相关工作试图为提供商授权关系提供可验证材料，并为路径验证建立更直接的基础。不过，相关 IETF 文档仍属于发展中的工作，不能把它写成已经普遍部署或已被证明能够阻止本次事件的成熟事实。

这些机制应被理解为相互独立的防线：

RPKI/ROA 关注前缀与起源 AS 的授权；
BGP Roles 与 OTC 关注会话角色和路径传播约束；
可信社区承载运营方内部或邻居间的策略语义；
外部过滤由接收网络对输入进行限制；
ASPA 面向可验证的提供商授权与路径分析；
生成策略的语义验证则负责在变更进入路由器前发现权限扩大。

任何一层都不应被宣传为万能替代品。更重要的是，不能因为某项标准存在，就推定某个私有网络已经部署、正确配置或验证了它。

公共收集器证据：能看到泄漏，不等于能解释泄漏

针对前缀 2a03:2880:f077::/48，在 20:24 至 20:52 UTC 的限定 RIPEstat BGPlay 查询中，接口返回状态 ok，共有 1,548 个事件，其中 1,440 个事件的路径同时包含 AS13335 与 AS32934。

这一结果为公开路径可见性提供了独立佐证。它表明在事件窗口内，公共路由观测系统确实记录到大量同时包含这两个 AS 的路径事件。它使分析不必完全依赖事件方对“路由是否离开网络”的单方面说明。

但这组数据的证明范围必须保持严格：

它不能读取 Cloudflare 的源代码或渲染策略；
它不能证明 Miami 路由器上具体执行了哪一条配置；
它不能测量 Miami 至 Atlanta 链路的拥塞；
它不能证明客户流量的丢包、时延或数量；
它不能确认约 12 Gbps 的过滤丢弃峰值；
它不能给出所有受影响前缀的完整集合；
它不能恢复所有私有邻居关系或商业合同；
它不能证明每一个事件都对应独立前缀或独立影响；
它也不能说明未被 RIPE RIS 观测点覆盖的网络看到了什么。

事件数是收集器在限定查询中的更新事件数量，不是受影响客户数、前缀总数或流量规模。1,440 个同时包含 AS13335 与 AS32934 的事件也不是 1,440 条独立泄漏前缀。公共观测数据适合回答“异常路径是否在外部可见”，不适合在缺少额外证据时回答“内部错误为什么发生”或“实际损害有多大”。

更完整的外部核验还应比较多个观测点、更新与撤回的时间分布、路径首次和最后可见时间，以及异常路径消失是否在不同网络中一致。即便如此，外部核验仍然只能补充内部证据，不能代替运行配置、出口策略日志和流量遥测。

恢复必须同时修复运行状态与生成源

20:50 的人工动作包含两个关键部分：手动恢复路由器策略，以及暂停自动化。这一组合很重要。如果只修改运行路由器而不暂停自动化，尚未修复的生成源可能再次覆盖人工变更。如果只暂停自动化而不恢复运行策略，已经发出的错误通告仍可能继续存在。

随后，仓库变更于 21:47 被回退，自动化在 22:07 被判断为健康，并于 22:40 解除暂停。这个顺序形成了一个更合理的恢复模型：

阻止错误继续扩大；
修复当前运行设备；
暂停可能重放错误的自动化；
修复生成配置的权威源；
检查自动化和候选结果；
确认外部路由撤回；
由具名责任人批准恢复自动化。

然而，公开时间线并不能证明每一个具体检查步骤都已按上述形式实施，也不能证明后续改进已经部署。Cloudflare 提出的方向——检查空或错误策略项、增强 BGP 社区保护、验证 BGP Roles/OTC 的设备支持、改善早期检测——应当作为整改承诺或计划看待，而不是后续有效性的既成证据。

恢复证据还应覆盖撤回过程。内部路由器显示错误路径不再存在，是必要条件；外部收集器不再观察到异常路径，是另一项独立条件。两者的时间可能不同，因为更新传播、路由选择和收集器覆盖存在延迟。只有同时记录内部撤回与外部消失，才能较有把握地说明错误传播已经停止。

自动化解除暂停也需要明确责任边界。应记录谁确认生成源已经修复、谁审查候选策略、谁确认逐邻居出口集合恢复正常、谁检查外部观测，以及谁批准恢复。具名责任并不等于把复杂系统错误归咎于单个人；它意味着在每个关键判断点，都存在可追溯的决策所有者。

一套面向路由自动化的问责标准

这起事件表明，“已经自动化”不是安全结论。自动化的价值取决于它能否证明自己的输出没有扩大权限。面向生成式出口策略，可以建立以下检查标准。

源与生成结果

每次变更应保存变更意图、源模板差异、输入数据差异、完整渲染候选策略及其哈希或等效不可变标识。若最后一个前缀、社区或关系条件被删除，构建系统应默认失败，除非策略项整体被删除或新的完整约束获得明确批准。

路由集合语义

验证器应枚举每个策略项在当前路由集合上会匹配的路由，并比较候选与运行策略的集合差异。它不仅要计算总数，还要按地址族、邻居、路由来源、起源 AS、前缀长度、路径属性和社区分类。

邻居关系矩阵

每个外部会话应有独立的关系标识和允许出口矩阵。对等方、提供商、客户和运营方自身起源的路由不能只依赖同一条宽泛接受规则。任何缺失或无法确认的关系属性都应触发拒绝，而不是默认接受。

预发 Adj-RIB-Out 差异

候选策略必须在更新发出前计算逐邻居的出口差异。新增路由应能追溯到被批准的前缀、起源与关系组合。无法解释的新增项、超出阈值的路由增长，或与变更目标无关的路径变化，都应自动阻止发布。

单设备试运行与自动停止

单设备试运行需要明确预算：允许变化的前缀数量、路径类型、邻居范围、地址族和观测时间。关系违规应该是绝对停止条件，不能被“变化数量仍在阈值内”所覆盖。

发出更新后的双重观察

内部需要核对运行策略、Loc-RIB、逐邻居出口状态、BGP 更新、RIB/FIB 和流量告警；外部则需要检查公共收集器是否出现未预期路径。两类观察不同步时，系统应保持暂停并调查差异。

独立安全层

起源验证、BGP Roles/OTC、可信社区、接收方过滤和未来的路径验证机制应被分别测试。只有在存在当前部署与有效性证据时，才能把它们记为已实施控制。标准文档或整改承诺本身不能代替运行证据。

回滚可逆性

回滚包应同时包含运行路由器修正与生成源修正。自动化必须能够暂停，并且不能在状态不一致时自行恢复。错误更新的撤回需要内部和外部证据，恢复则需要具名批准。

证据保存

每次高风险路由变更应保留源意图、渲染候选、运行配置、路由集合差异、邻居关系、预期 Adj-RIB-Out、实际更新、外部观测、流量告警、回滚状态和批准记录。没有这些材料，事后只能看到结果，无法判断控制为什么允许结果发生。