Cloudflare's January 2026 IPv6 Route Leak Made Empty Export Policy an Accountability Test

Summary

Cloudflare says a repository change intended to remove obsolete Bogotá site-local prefix-list references was merged at 19:52 UTC on 22 January 2026. Automation applied the resulting policy to one Miami router at 20:25, when impact began. Investigation started at 20:40; the incident was raised at 20:44; an operator manually reverted the router configuration and paused automation at 20:50. The repository change was reverted at 21:47, automation was judged healthy at 22:07 and it was unpaused at 22:40 [1].
According to Cloudflare, deleting the final prefix-list condition did not remove the enclosing export term. The term retained the broader match route-type internal and an accept action. Because Cloudflare says that match included non-external routes such as routes learned through iBGP, the rendered policy could select internally redistributed third-party IPv6 routes and export them to Miami peers and transit providers. The configuration was therefore semantically broader even though it remained syntactically usable [1].
Cloudflare bounded the impact at 25 minutes and to IPv6. It reported congestion on its Miami-to-Atlanta backbone path, higher latency on affected links, elevated loss for some Cloudflare customer traffic and firewall discard of traffic addressed to non-downstream prefixes. The company estimated that discarded traffic reached about 12 Gbps at peak. Those measurements come from Cloudflare's account; the public record does not independently quantify affected customers, individual losses or the complete prefix set [1].
Cloudflare described learning Meta IPv6 routes from peer AS32934 and advertising them from Cloudflare AS13335 toward transit provider AS3356. For 2a03:2880:f077::/48, it published the path 64112 22850 174 3356 13335 32934. A bounded RIPEstat BGPlay query returned 1,548 update events, including 1,440 paths containing both AS13335 and AS32934. That independently corroborates public visibility of the anomalous path pattern, but not the internal policy cause, traffic volume or customer impact [1][6][7][8].
The central control failure was not merely deletion of text. It was expansion of the set of routes authorized for export. Source intent, rendered configuration, running configuration, Loc-RIB state, candidate Adj-RIB-Out and emitted BGP updates answer different questions. A safe change should have shown that removing Bogotá references produced only expected removals and zero newly eligible peer- or provider-learned routes on every affected IPv6 session [1][10].
Cloudflare classified the event as a mixture of RFC 7908 Type 3 and Type 4 leaks: provider-learned routes exported to peers, and peer-learned routes exported toward a transit provider. RFC 8212 default-reject behavior addresses the absence of explicit external policy, but it cannot by itself correct an explicit policy whose surviving accept term is too broad. RFC 9234 Roles and Only-to-Customer offer relationship-aware controls that are distinct from origin authorization [11][12][13].
RPKI origin validation would not necessarily reject the published path example. The route still ended in Meta AS32934, so origin authorization and intermediate-path authorization were different questions. ROAs, origin validation and router-to-cache distribution protect origin assertions; BGP Roles and OTC address relationship propagation, while ASPA proposes developing path-verification mechanisms. None of those documents proves what Cloudflare or its neighbors had deployed during the incident [12][15][16][17][18][20].
Applying the change to one router limited device scope but did not prevent that router from affecting external routing. A meaningful canary must compare rendered match sets and Adj-RIB-Out before emission, watch live exports by neighbor and address family, abort on relationship violations, correlate RIB/FIB and discard signals, and confirm withdrawals through external collectors. The public account leaves private topology, exact automation internals, decision ownership, hidden safeguards and the effectiveness of later remediation unknown [1][7][14][19].

The narrow finding supported by the public record

The event should be understood as an interdomain export-policy failure with a bounded internal and external evidence record. Cloudflare's incident post is the primary account of why the policy changed, what the generated configuration did, how operators responded and what effects the company measured. It is unusually useful because it identifies a site, address family, policy condition, neighbor relationships, sample prefix, AS path, operational chronology and recovery sequence. It is nevertheless Cloudflare's account of an event inside Cloudflare's network, not a complete neutral reconstruction [1].

The independent evidence has a narrower function. A RIPEstat BGPlay query for one disclosed Meta IPv6 prefix and a bounded event window shows that paths containing Cloudflare AS13335 and Meta AS32934 were visible through public routing collectors. It supports the conclusion that an anomalous path pattern escaped the private configuration context and appeared in the public control plane. It cannot identify the source-code condition, determine which router emitted every update, measure traffic, establish the number of affected customers or reveal Cloudflare's private topology [6][7][8].

Those two evidence classes should not be collapsed. Cloudflare's disclosure supports attributed statements about internal cause and impact. The public route observations support a bounded statement about external visibility. Agreement between them strengthens the overall account, but it does not turn either source into evidence for every layer of the event.

The strongest defensible finding is therefore precise: Cloudflare says one Miami router exported IPv6 routes learned from peers and providers after an automated cleanup removed the last prefix-list restriction from an accepting policy term. Public collectors observed at least one corresponding AS-path pattern. Cloudflare reversed the router policy after 25 minutes, paused automation, later reverted the repository change, assessed the automation as healthy and then resumed it [1][7].

Several broader claims are not supported. The evidence does not establish the complete set of leaked prefixes, all networks that selected the paths, the amount of traffic carried rather than discarded, the losses of individual customers, the exact device commands, every intermediate routing decision or the internal allocation of responsibility. It also does not demonstrate whether later safeguards were fully deployed or effective.

That boundary matters because routing incidents can invite exaggerated descriptions. Here, the mechanism disclosed was an operator-caused expansion of export eligibility. Meta remained the origin in the example path, and Cloudflare did not attribute malicious activity. The analytical task is to ask why an apparently narrow cleanup could widen interdomain authority and what evidence would have stopped or exposed that expansion sooner.

Eight disclosed timestamps and no invented chronology

Cloudflare's public sequence starts at 19:52 UTC, when the repository change was merged. The purpose, according to the company, was to remove references to obsolete Bogotá site-local prefix lists following infrastructure upgrades. That description establishes intent: retire no-longer-needed local configuration references. It does not establish the semantics of the final device configuration [1].

At 20:25, automation ran on one Miami router and impact began. This timestamp is important for two reasons. First, it ties activation to one device rather than a simultaneous fleet-wide change. Second, it marks the start of the 25-minute impact window disclosed by Cloudflare. The one-router boundary limited where the policy was activated, but it did not keep routes emitted by that router inside Cloudflare [1].

Investigation began at 20:40. Cloudflare says the incident was raised at 20:44. These are separate operational milestones and should remain separate: investigation indicates that an anomaly was being examined; raising the incident indicates a formal escalation in the response. The public account does not provide enough detail to identify which alarm fired first, when a specific person first saw an unexpected AS path or whether internal and external signals arrived in a particular order.

At 20:50, an operator manually reverted the configuration on the Miami router and paused automation. That dual action matters. Reverting the device addressed the active routing state, while pausing automation prevented the source-to-device system from immediately restoring the bad state. A rollback that changed only the router could have remained vulnerable to reapplication if the generating source still encoded the same result [1].

The repository change was reverted at 21:47. Cloudflare judged the automation healthy at 22:07 and unpaused it at 22:40. These later times show that restoration involved more than withdrawing leaked routes. The source state had to be corrected, the automation had to be assessed and resumption had to be an explicit decision. The public account does not disclose the tests used to reach the 22:07 judgment or the criteria for unpausing at 22:40 [1].

The impact boundary disclosed by Cloudflare ends with the manual router-policy revert and automation pause at 20:50. The company reported that the event lasted 25 minutes and affected IPv6 only. It attributed Miami-to-Atlanta backbone congestion, higher latency on affected links and elevated packet loss for some Cloudflare customer traffic to the event. It also said firewall filters discarded traffic for prefixes that were not downstream of Cloudflare and estimated a peak discard rate of about 12 Gbps [1].

Those figures should not be expanded into totals that Cloudflare did not publish. Twelve gigabits per second of discarded traffic is not the same as total attracted traffic, total leaked-route traffic, total customer demand or economic loss. “Some customer traffic” does not identify a customer count or geographic distribution. Higher latency on affected links does not establish a universal latency increase across Cloudflare's network.

The chronology supports a clear operational distinction. The harmful routing state ended before the source change was reverted and well before automation was resumed. Device recovery, source correction and automation recovery were three different states. Treating all three as one rollback event would hide the continuity risk created when a controller and a router disagree.

How a deleted predicate widened export authority

The disclosed policy failure turns on the difference between syntactic validity and set semantics. A syntax failure is normally conspicuous: a parser rejects a statement, a commit fails or a device refuses a candidate configuration. Cloudflare described something more dangerous. The generated term remained acceptable to the configuration system but represented a much larger route set than intended [1].

Before the cleanup, the relevant term combined a broad route-type internal condition with a narrow prefix-list condition for the Bogotá site. In conceptual set notation, its eligible routes can be represented as:

Internal routes ∩ Routes in the Bogotá prefix list

The cleanup removed the final prefix-list predicate. According to Cloudflare, it did not remove the enclosing term or change its terminal action. The resulting eligibility became:

Internal routes

This notation is explanatory rather than literal vendor configuration. Its importance is the difference between the two sets. The second is not empty. It is broader. Every route that qualified as internal but was not in the former Bogotá list became newly eligible for the term's remaining actions.

The term still ended in accept. Cloudflare says route-type internal matched non-external routes, including routes learned through iBGP. An iBGP-learned route is not necessarily a prefix originated by Cloudflare or a route belonging to a Cloudflare customer. It can carry reachability learned elsewhere in the network from a peer or a transit provider. Internal distribution describes how the local router received or represented the route; it does not prove that the route is safe to announce externally.

This is why “empty policy” needs careful interpretation. The term was not empty of behavior. It had become empty of its final narrow prefix constraint while retaining a broad match and an accepting action. The danger came from surviving authority, not from absence of configuration.

A textual change can look subtractive while its routing meaning is expansive. Removing a list reference appears to delete obsolete scope. But if the list was the last conjunct restricting an accepting term, the deletion enlarges the match set. A line-count summary might report less configuration even as the router gains permission to export more routes.

The relevant question is therefore not merely, “Did the configuration parse?” It is, “Which routes can this rendered term now accept for each external neighbor?” That question requires evaluating the policy against route state. It cannot be answered from source intent alone.

A compiled-policy test for this event should have constructed representative routes in at least five classes: Cloudflare-originated routes, legitimate downstream routes, routes learned from a peer, routes learned from a provider and unrelated routes carried internally through iBGP. Removing Bogotá references should have caused only the expected Bogotá-specific changes. Any newly accepted peer- or provider-learned route should have stopped activation.

The same test should have been run separately for IPv4 and IPv6. Cloudflare says only IPv6 was affected, so address-family-specific evaluation was essential. A generic “policy compiled successfully” result would not establish that the IPv6 term had retained its intended relationship and prefix restrictions.

This semantic failure mode is especially relevant to generated configuration. Human-authored source, templates, inventory values and route state can combine into a rendered term that no individual source fragment displays in full. Accountability belongs at the point where those inputs become effective policy. The rendered output must be treated as a security-relevant routing artifact, not as a disposable implementation detail.

Source intent, rendered policy and running state are different evidence

A routing change crosses several realities before it affects the Internet. Each has its own evidentiary value, and success at one layer cannot substitute for success at the next.

Evidence layer	Question it answers	Event-specific warning
Change intent	What was the operator trying to remove?	Obsolete Bogotá references describe purpose, not final export scope.
Generating source	What logic and data changed?	A small deletion can remove the last narrow predicate.
Rendered candidate	What exact terms and actions will the router receive?	`route-type internal` plus `accept` can remain syntactically valid.
Match-set evaluation	Which current routes satisfy each term?	Peer- and provider-learned IPv6 routes can enter the newly expanded set.
Running configuration	What did the router activate?	Acceptance by the device does not mean relationship policy is correct.
RIB and Adj-RIB-Out state	What routes are selected and eligible for each neighbor?	Unexpected third-party routes can be prepared for external advertisement.
Emitted updates	What did the router actually send?	Public AS paths can reveal that the boundary was crossed.
Forwarding and traffic state	What traffic followed the new paths, and what happened to it?	Cloudflare reported congestion, latency, loss and discard of non-downstream traffic.

The source change is evidence of intent and authorship. The rendered candidate shows how automation interpreted that intent. The running configuration shows what the router accepted. None of those alone shows which routes were selected for export. That requires route-state evaluation.

RFC 4271 describes BGP as a policy-driven reachability protocol and defines the conceptual routing information bases used in selection and propagation. Adj-RIB-Out represents the routes a BGP speaker advertises, or is prepared to advertise, to a particular peer. Implementations may expose this state differently, but the accountability question remains: what changed in the export set for each neighbor and address family? [10]

For the Miami event, a safe comparison would have been per neighbor, not a single router-wide route count. A route valid for a customer session can be invalid for a peer or provider session. The comparison should identify prefix, origin, relevant AS-path properties, address family, communities, relationship provenance and the policy term that authorized the export.

The expected delta from a Bogotá cleanup should have been narrow and mostly subtractive. The system should have listed the routes removed, the routes added and the reason for every addition. If no new export was intended, the allowed addition count should have been zero. An unexpected increase toward a peer or transit provider would then have been a stop condition rather than a statistic inspected after activation.

Running-policy evidence is also stronger when it is reproducible. An operator should be able to take the same RIB snapshot, apply the old and new rendered policies and obtain two explicit route sets. The difference should be preserved with the change record. That would make the semantic expansion visible even if the source deletion looked routine.

The crucial standard is correspondence. Intended cleanup, rendered restriction, activated terms, selected routes and emitted updates should all tell the same story. In this event, Cloudflare's account indicates that intention and emitted behavior diverged. Public accountability requires explaining where that divergence became observable and which control should have stopped it.

What Adj-RIB-Out should have exposed before emission

Adj-RIB-Out is the most event-specific missing bridge between configuration and public routing. A policy term can look reasonable in isolation, and a route can look legitimate in the Loc-RIB, while the combination is inappropriate for a particular external neighbor. Evaluating outgoing route sets makes the combination explicit [10].

Consider the disclosed Meta route. Learning 2a03:2880:f077::/48 from peer AS32934 can be entirely normal within a peering relationship. Distributing that route internally through iBGP can also be normal. The accountability failure arises when the Miami router prepares the route for export toward a transit provider or another peer contrary to the relationship rule described by Cloudflare.

A per-neighbor Adj-RIB-Out comparison should answer at least these questions:

Did the candidate add any route whose provenance was peer-learned to an upstream-facing IPv6 session?
Did it add any provider-learned route to a peer-facing session?
Did it change the number of third-party origins advertised on the session?
Did it remove or alter relationship communities?
Did it change AS-path or next-hop handling in a way that affected export eligibility?
Did every newly eligible prefix appear in the approved change scope?

The first two questions map directly to the leak directions Cloudflare described. The third catches unexpected expansion even if provenance metadata is incomplete. The fourth tests whether a secondary control survived. The fifth checks emitted attributes rather than prefix membership alone. The sixth ties the result back to the Bogotá cleanup.

Counts are useful but insufficient. A delta of one unauthorized route is still a policy violation, while a large legitimate downstream update may be expected during maintenance. The comparison needs identity and provenance, not just cardinality.

A route-set diff should also distinguish routes that the candidate would withdraw from routes that it would newly announce. A cleanup commonly creates expected withdrawals. Newly announced third-party routes demand a different explanation. Combining additions and removals into one net count can conceal a large and dangerous exchange.

Community provenance deserves particular attention. Cloudflare said it planned additional BGP-community safeguards [1]. Such safeguards can encode whether a route entered from a customer, peer, provider or internal origin, but only if the marks are assigned at trusted boundaries and cannot be casually inherited or forged. External communities may need to be stripped, normalized or recorded separately before internal relationship labels are applied.

A community-based export condition should be independent of the prefix-list condition that failed. If both restrictions are generated from the same disappearing input, they can fail together. A stronger design requires agreement between route provenance and outbound-neighbor role. A peer-learned marker should make export to a provider impossible even if a prefix-list predicate vanishes.

The final comparison must use the candidate policy that will reach the router, not an abstract template. It should also use route data representative of the activation moment. A test with no peer routes present can give false reassurance if live iBGP state contains many of them.

An operator need not expose private Adj-RIB-Out contents publicly. It should, however, retain enough evidence to state that the candidate introduced zero unauthorized exports by relationship and address family, and to show later investigators how that conclusion was reached. Cloudflare's incident post does not publish such a pre-activation comparison.

Reading the disclosed AS path without inventing a contract

Cloudflare's example centers on Meta prefix 2a03:2880:f077::/48 and AS path:

64112 22850 174 3356 13335 32934

BGP AS paths are normally read from the observing side toward the origin, with the originating AS at the right. In this example, AS32934 appears as the origin, Cloudflare AS13335 appears immediately before it, and AS3356 appears before Cloudflare. Cloudflare identifies AS32934 as a peer and AS3356 as a transit provider [1].

That attribution supplies relationship context that the numbers alone do not contain. Combined with Cloudflare's account, the segment 3356 13335 32934 represents a Meta-originated route learned by Cloudflare from a peer and then advertised by Cloudflare toward its transit provider. This is the peer-to-provider direction central to the incident.

The path does not say that Cloudflare originated Meta's prefix. AS32934 remains at the right-hand origin position. Nor does it, by itself, prove that the route was selected by every AS shown, carried customer traffic or violated a written contract. It records control-plane propagation as seen from a particular observation path.

AS paths are not complete commercial contracts. They do not encode prices, settlement terms, exceptions, sibling relationships, partial-transit arrangements or every private topology detail. Relationship classifications often depend on outside information and can vary by interconnection. Here, the relevant peer and provider labels are supportable because Cloudflare supplied them for the incident. They should not be generalized to every session among the same organizations.

The left-hand portion—64112 22850 174—shows that the route was visible beyond the immediate Cloudflare-Lumen segment in the observed path. It does not establish how many networks installed the route or how long each retained it. A collector records updates available from its connected vantage points, not the full Internet's forwarding state.

The path is therefore powerful but bounded evidence. It shows that a route retaining Meta as origin appeared with Cloudflare and its upstream in the middle. That is consistent with Cloudflare's disclosed leak direction. It does not reveal the router policy text, the route's traffic volume or the internal reason the advertisement passed.

This distinction is essential for accountability. An operator's internal records explain why a route was eligible. External paths show that eligibility escaped. A credible incident account needs both. If only internal configuration is available, the public cannot know whether the route was observed elsewhere. If only the AS path is available, the public cannot know which internal condition authorized it.

Why RFC 7908 yields Type 3 and Type 4 classifications

RFC 7908 supplies a vocabulary for route leaks without turning every routing anomaly into an origin problem. Its categories focus on unintended propagation across relationships [11].

A Type 3 leak involves routes learned from a transit provider being advertised to a peer. That export can turn the leaking network into an unintended path between its peer and provider. A Type 4 leak involves routes learned from a peer being advertised to a transit provider. The disclosed Meta example is in the Type 4 direction: Cloudflare says it learned the route from peer AS32934 and advertised it toward provider AS3356 [1][11].

Cloudflare classified the broader event as a mixture of Types 3 and 4 because the expanded policy exported internally redistributed routes to both peers and providers. Provider-learned routes sent to peers fit the Type 3 pattern; peer-learned routes sent toward a provider fit Type 4 [1][11].

The distinction matters operationally. A prefix allowlist can limit which routes leave, but a relationship-aware export rule asks a different question: where was this route learned, and to which class of neighbor may it be announced? The same prefix can be legitimately advertised to one neighbor and illegitimately advertised to another.

A downstream customer normally receives broad reachability from its provider. A peer normally receives the announcing network's own and customer routes, not routes learned from another peer or upstream. A transit provider normally receives the customer's own and downstream routes, not routes the customer learned from a lateral peer. Real arrangements can have exceptions, so enforcement must use the actual relationship assigned to each session rather than a universal guess.

This is why the event cannot be reduced to “too many prefixes.” The leaked routes crossed relationship boundaries. Route count, prefix identity, origin authorization and relationship authorization were all relevant, but they were not interchangeable.

RFC 7908 classifies behavior; it does not enforce it. Preventing the behavior requires export policy, relationship metadata, receiving-side filtering and, where supported, protocol mechanisms that carry relationship constraints. The classification is useful because it translates the Miami policy expansion into two testable invariants: no provider-learned route to a peer, and no peer-learned route to a provider.

One router and one address family did not make the change safe

Cloudflare says automation applied the policy to one Miami router. That fact should not automatically be called a successful canary or even an intentional canary. The public account identifies deployment scope but does not disclose the activation strategy or the criteria attached to it [1].

One-router activation can reduce the number of devices exposed to a bad configuration. It cannot by itself limit the reach of BGP updates emitted from that router. A single externally connected router can announce a route to peers and providers, which can then propagate it according to their own policies. The small device count and the potentially large routing radius are different dimensions.

A canary is valuable only if it has an observation contract and a stopping action. For this event, the contract should have required zero newly exported peer-learned routes toward providers, zero newly exported provider-learned routes toward peers and no unexpected increase in IPv6 Adj-RIB-Out. The stopping action should have paused further automation and withdrawn or blocked the candidate before human investigation became the primary containment mechanism.

The safest first stage may not emit updates at all. The candidate policy can be rendered and evaluated against current route state, producing a projected Adj-RIB-Out diff. If the platform permits a shadow or held-update mode, operators can inspect the candidate export set before release. Device activation should follow only after the non-emitting comparison passes.

When live emission is necessary, canary scope should be bounded in several dimensions: router, neighbor, relationship, address family, prefix set and time. “One router” leaves the other five unspecified. In Miami, a canary attached simultaneously to peers and transit providers could exercise exactly the relationships where a broad term was dangerous.

IPv6-only impact offers some evidence of family-specific behavior. Cloudflare's report supports the conclusion that the disclosed route leak and impact were confined to IPv6. It does not prove that the entire IPv4 and IPv6 control systems were independent, that shared hardware was unaffected or that every dual-stack service escaped secondary effects [1].

The family boundary should have been visible before activation. A rendered-policy comparison could show that IPv4 export sets were unchanged and that IPv6 changes were limited to the intended Bogotá removals. Live checks should then compare IPv4 and IPv6 BGP updates, RIB/FIB state, traffic and reachability separately.

The event also illustrates why a canary needs automatic expiry. A candidate that introduces an unexpected route should not remain active merely because no person has yet classified the signal. The system should define conditions under which it returns to the previous policy and pauses further changes. Human judgment remains necessary for diagnosis and resumption, but it should not be the only barrier between an anomalous export and continued propagation.

The evidence stack needed for this exact failure mode

No single signal could fully describe the Miami event. A robust control design needs multiple observations aligned in time and attached to the same change.

Rendered-policy evidence

The first check is structural. Did an accepting term lose its last prefix-list, community or relationship constraint? A term can remain nonempty in syntax while becoming underconstrained in meaning. The system should flag any accepting term whose set of restrictive predicates shrinks, especially where only a broad route classification remains.

The check should understand term behavior, not merely count conditions. Removing a logging statement is not equivalent to removing a prefix filter. Removing one of several redundant relationship controls differs from removing the sole narrow selector. The resulting action and term order also matter because a broader term can shadow later rejections.

Route-set expansion

The rendered policy should be evaluated against a route snapshot. For every term, the operator should record the old and new matched sets. In the disclosed scenario, a large expansion from Bogotá-specific routes to internally represented routes would have been visible immediately.

The output should identify why each newly matched route qualifies. If an iBGP-learned Meta route appears only because the final prefix-list condition disappeared, the explanation is concrete enough to stop the change. A percentage change alone is less useful than a list of newly authorized route classes.

RIB and FIB state

The Loc-RIB shows selected routing information available to the router. The FIB shows what the forwarding plane can use. Neither alone proves what was advertised externally, but both matter when traffic begins arriving.

Cloudflare reported that traffic for non-downstream prefixes was discarded by firewall filters [1]. That means export and forwarding controls produced different outcomes: the control plane attracted traffic that the data-plane policy would not transit. An operator should detect that contradiction. Advertising a route while discarding traffic for it is a high-confidence signal that reachability claims and forwarding authority have diverged.

The check should correlate leaked prefixes with next hops, installed forwarding entries, firewall counters and interface traffic. It should not assume that a route present in the RIB is installed in hardware or that an emitted route corresponds to a usable forwarding path.

BGP updates and Adj-RIB-Out

Update telemetry records what the router sends. The system should attribute each update to the neighbor, address family, policy term and route provenance that authorized it. For the disclosed failure, an update for a peer-learned prefix toward AS3356 would be sufficient to stop the change.

A raw update-rate alarm is useful but may miss a small unauthorized set. Relationship violations should therefore be first-class events even when volume is low. Conversely, a high update count during a legitimate maintenance operation may require explanation without necessarily indicating a leak.

Traffic, latency and discard

Cloudflare reported congestion between Miami and Atlanta, higher latency on affected links, elevated loss for some customer traffic and about 12 Gbps of discarded non-downstream traffic at peak [1]. These signals describe consequences, not the initial authorization error.

They are still valuable for automatic containment. A sudden rise in discard for prefixes not classified as downstream, combined with unexpected third-party routes in Adj-RIB-Out, is stronger than either signal alone. Backbone congestion can show where attracted traffic is stressing internal capacity. Latency and loss can expose collateral effects on legitimate customer traffic.

Thresholds should be based on deviation from the expected change, not generic numbers copied across sites. The Bogotá cleanup did not intend to attract new third-party traffic. The acceptable new non-downstream discard attributable to the change was therefore zero.

External route visibility

RIPE RIS collectors receive BGP information from participating networks and preserve public routing observations. BGPlay turns available route events into a time-bounded view; MRT data offers another structured form for routing records [6][8][9]. These systems provide independent visibility but only from their connected vantage points.

Cloudflare also describes route-leak detection and BGP anomaly investigation through Radar and associated interfaces [2][3][4][5]. Those materials show available concepts and capabilities. They do not establish which detection path identified the Miami incident, when it did so or whether a specific alert caused the rollback.

An operator should compare internal emitted updates with external observations. If internal records show withdrawal but collectors continue to receive the path, recovery is incomplete or propagation remains in progress. If collectors show a route that internal records do not explain, the evidence chain has a gap.

Recovery state

Recovery evidence should include restored running policy, expected Adj-RIB-Out, emitted withdrawals, normalized discard and traffic signals, and disappearance of anomalous paths from public views. The automation source and device state should agree before changes resume.

Cloudflare's published sequence shows manual configuration rollback, automation pause, repository reversal, health assessment and later resumption [1]. It does not publish the detailed observations used to close each step. Those records are important because the same automation fault that created a route can also misreport recovery if health is judged only at the source layer.

What the RIPEstat query proves—and what it cannot

The bounded RIPEstat BGPlay query covers 2a03:2880:f077::/48 from 20:24 to 20:52 UTC. It returned status ok, 1,548 update events and 1,440 events with paths containing both Cloudflare AS13335 and Meta AS32934 [7].

That result is independent public-path evidence in a specific sense. The data was available through public route collectors rather than generated solely from Cloudflare's internal incident narrative. It corroborates that the disclosed AS combination appeared in observable route updates during the relevant window.

The query does not independently prove that deleting a prefix-list condition caused the updates. Public BGP data normally contains the resulting prefix, AS path, attributes, timestamps and collector context, not the source code or rendered router policy responsible for them. The internal cause remains attributable to Cloudflare's disclosure [1][7][8].

It does not measure traffic. BGP updates describe reachability announcements and withdrawals, not packet volume. The 12 Gbps peak discard estimate, congestion, latency and customer loss remain company-reported measurements [1].

It does not establish a complete affected-prefix inventory. The query is for one prefix disclosed in the incident account. Other affected routes may or may not appear from the same collectors, and the event counts for this prefix cannot be converted into a total prefix count.

It does not establish 1,548 unique networks or 1,440 unique paths. Update events can include repeated announcements, withdrawals, path changes and observations from multiple vantage points. They are events in the returned data, not a direct count of affected organizations.

It also does not show universal propagation. RIPE RIS collectors provide substantial but partial visibility [6]. A route unseen by a particular collector can still exist elsewhere, and a route seen by a collector may not be selected for forwarding throughout the Internet.

The right use of BGPlay here is corroboration and timing context. It shows that the route-policy outcome was externally legible. It can help compare the appearance and withdrawal of paths with internal response records. It cannot replace device configuration, Adj-RIB-Out, update logs, traffic telemetry or customer evidence.

That division of labor is valuable. Internal telemetry can be detailed but controlled by the affected operator. Public collectors are independent but incomplete. When both show compatible evidence, confidence rises within the overlap of their claims.

Five control families with different jobs

The standards and practices relevant to this event address different questions. Treating them as interchangeable would obscure the exact failure.

RFC 8212: reject when external policy is absent

RFC 8212 changes the expected behavior of external BGP sessions so that routes are not imported or exported without an explicitly configured policy [13]. Its accountability principle is important: external propagation should require deliberate authorization.

The Miami condition was different from a session with no export policy. Cloudflare describes an explicit term that retained route-type internal and accept. A router can satisfy the existence of configured policy while that policy authorizes too much. Default reject is a baseline, not a semantic proof that every explicit term is relationship-safe.

An implementation aligned with RFC 8212 should still reject if no policy is present for the relevant address family. On top of that, automation must detect policies that have become functionally broad after a constraint disappears.

RFC 7454 and MANRS: operational filtering discipline

RFC 7454 collects BGP operational and security guidance, including filtering and policy practices [14]. MANRS likewise describes route filtering as an operational responsibility [19]. These sources support the principle that both sending and receiving networks should restrict propagation according to known routing authority and relationships.

They do not prove what filters Cloudflare, AS3356, AS32934 or other networks had in place on 22 January. Nor do they establish that a particular receiving network was contractually required to reject the example route. Private agreements and prefix authorization data are not fully available.

Receiving-side filtering is nevertheless an important complementary control. A transit provider accepting routes from a customer can restrict them to the customer's authorized prefixes and downstream cone. A peer can reject routes outside the expected peer and customer set. Such filters reduce dependence on the exporting network's generator.

The exporter remains responsible for its own Adj-RIB-Out. Defensive filtering by neighbors should not be treated as permission to emit unauthorized routes.

RPKI origin validation: origin authority, not full path authority

The RPKI architecture provides a framework for verifiable assertions about Internet number resources [15]. Route Origin Authorizations allow a holder to authorize an origin AS for a prefix. RFC 6811 defines BGP origin validation, RFC 8210 defines communication of validated information to routers, and RFC 7115 discusses operational use of origin validation [16][17][18].

In the disclosed path, Meta AS32934 remained the origin. If a matching ROA authorized AS32934, the route could be origin-valid even though Cloudflare carried it through an unauthorized intermediate relationship. The incorrect fact was not necessarily “Who may originate this prefix?” It was “May this peer-learned route be exported toward this transit provider?”

Rejecting origin-invalid routes remains valuable. It addresses false or unauthorized origins and some accidental misoriginations. It should not be advertised as a complete answer to Type 3 or Type 4 leaks that preserve the legitimate origin.

RFC 8210's router-to-cache mechanism distributes validated origin information; it does not add commercial relationship semantics to the AS path. RFC 7115's operational recommendations likewise do not transform origin validation into path authorization.

RFC 9234: Roles and Only-to-Customer

RFC 9234 defines BGP Roles and the Only-to-Customer attribute to help networks express and enforce relationship constraints [12]. The design addresses the propagation direction at issue in route leaks: routes learned in contexts marked as only suitable for customer delivery should not be re-exported across disallowed peer or provider paths.

For the Miami event, relationship-aware protocol state could provide an independent check on the generated local policy. A route learned from a peer should not become eligible for export to a transit provider merely because a prefix-list predicate disappeared. A provider-learned route should likewise remain ineligible for export to a peer.

Cloudflare said it would validate vendor support for these mechanisms [1]. That is a stated direction, not evidence that Roles and OTC were deployed during the incident or later across every relevant session.

Deployment also requires accurate assignment and negotiation of roles. A mechanism cannot protect a session if the relationship metadata is missing, wrong or inconsistently enforced. Operators need evidence of configured roles, negotiated outcomes, OTC handling and rejection behavior for each address family.

ASPA: developing path verification

The ASPA work proposes a way for an AS to authorize its providers and for relying networks to evaluate provider relationships along AS paths [20]. This is more directly concerned with path structure than origin-only validation.

It remains developing work, not a deployed Internet standard established by the Miami record. Whether ASPA-based verification would classify a particular observed path depends on the available authorizations, the verification algorithm, adoption along the path and treatment of uncertain segments.

ASPA should therefore be discussed conditionally. It may improve detection or rejection of path-policy anomalies that origin validation cannot see. It does not retroactively prove that the Cloudflare path would have been rejected everywhere, and its document does not prove deployment by any AS in the example.

Together, these controls form layers rather than substitutes. RFC 8212 prevents unconfigured external propagation. Local export policy defines precise authorization. Communities and RFC 9234 can carry relationship constraints. RPKI origin validation checks origin authority. ASPA aims at provider-path authorization. Neighbor filtering contains errors that escape the source network. None removes the need to inspect rendered policy and Adj-RIB-Out.

Designing an automatic stop for the Miami failure mode

An effective safeguard must be tied to the intended change. The purpose was to remove obsolete Bogotá references, not to expand transit behavior. That gives the automation a narrow expected result against which to compare reality.

Before device activation, the system should render the complete old and new export policies for every affected IPv6 neighbor. It should identify all accepting terms whose restrictive conditions changed. If a term loses its final prefix, community or relationship predicate, activation should stop unless the change explicitly authorizes a broader route set.

Next, the system should evaluate both policies against representative and current routes. The result should be a per-neighbor route-set diff with separate additions and removals. For this cleanup, expected additions should have been zero. Newly eligible routes learned from AS32934 or any other peer should have been visible before the router emitted them.

The relationship matrix should be explicit:

Route provenance	Customer-facing export	Peer-facing export	Provider-facing export
Cloudflare-originated	Allowed when intended	Allowed when intended	Allowed when intended
Legitimate downstream customer	Allowed according to service	Allowed according to agreement	Allowed according to transit design
Peer-learned	May be delivered to downstream customers	Reject unless a specific exception exists	Reject
Provider-learned	May be delivered to downstream customers	Reject	Reject toward another provider unless explicitly designed
Unknown or untrusted provenance	Reject pending classification	Reject	Reject

This is a general relationship framework, not a statement of Cloudflare's unpublished contracts. The actual matrix must reflect each session's documented role. Its value is that an export term cannot silently acquire authority merely because its prefix selector vanishes.

Community provenance should be tested at the same time. The system should show where a relationship marker was attached, whether an external neighbor could supply the same value, whether it survived iBGP distribution and whether the outbound policy required it. A missing or contradictory marker should produce rejection.

The candidate Adj-RIB-Out should then be calculated or captured without releasing updates where the platform permits. The comparison should include prefix, origin, path, next hop, communities and authorizing term. It should be separately signed off for IPv6 because the disclosed impact was family-specific.

If the change reaches one live router, automatic abort conditions should remain active. Event-specific conditions include:

any peer-learned route newly advertised toward a provider;
any provider-learned route newly advertised toward a peer;
any prefix addition outside the approved Bogotá scope;
disappearance of a required relationship community;
an unexpected rise in third-party origins in IPv6 Adj-RIB-Out;
discard traffic for newly advertised non-downstream prefixes;
correlated congestion, latency or loss on the Miami-to-Atlanta path;
public observation of a prohibited AS-path segment attributable to the canary.

The first four conditions should stop the change before traffic evidence is needed. Discard, congestion and public collectors are later defenses. Waiting for 12 Gbps of discard would turn a preventive control into an impact alarm.

An abort should do more than reverse one device command. It should freeze further automation, restore the previous rendered policy, capture the candidate and running states, preserve BGP update evidence and begin external withdrawal verification. The system should not continue applying the same source state elsewhere.

Human operators still decide whether the signal reflects a real relationship exception, incorrect metadata or an unsafe policy. But the default while that question is unresolved should be the previous export state. The burden should fall on expansion, not on continued restriction.

RIB, FIB and firewall evidence must agree

The disclosed discard behavior adds a particularly important accountability question. Cloudflare says its firewall filters discarded traffic for prefixes that were not downstream, reaching about 12 Gbps at peak [1]. The filters therefore recognized a forwarding-authority boundary that the BGP export policy failed to preserve.

That divergence could be made into a preventive signal. If a router advertises a prefix but its forwarding or firewall policy classifies the destination as non-downstream, the network is making inconsistent claims: “send this traffic to me” in BGP, and “I will not carry this destination” in the data plane.

An operator should continuously compare these classifications. For every externally advertised route, there should be a documented forwarding disposition. That does not require public disclosure of private topology. It requires internal assurance that advertisements correspond to paths the network is authorized and prepared to carry.

RIB and FIB evidence answer different questions. The RIB can show the selected next hop and route provenance. The FIB can show whether forwarding state was installed. Firewall counters can show whether traffic is being rejected despite the advertisement. Interface and backbone telemetry can show where attracted traffic imposes load.

In Miami, the reported congestion between Miami and Atlanta suggests that the effects extended beyond the external session that emitted the updates. The public account does not reveal which prefixes used that path, how traffic was distributed or whether every discarded packet followed the example AS path. Those details remain unknown [1].

A strong automatic response would correlate a newly advertised third-party IPv6 prefix with rising discard and backbone load. The route export supplies the cause-oriented signal; the traffic observations supply consequence-oriented confirmation. Either can be noisy alone. Together, they can justify rapid withdrawal.

Recovery requires the same agreement in reverse. It is not enough for the candidate configuration to show the old policy. Adj-RIB-Out should return to its baseline, withdrawals should be emitted, external paths should converge away from the leak, discard should normalize and legitimate customer traffic should recover.

The public chronology states when Cloudflare reverted the router and later resumed automation. It does not publish RIB, FIB, firewall, link or collector evidence used to judge completion. That omission does not prove those checks were absent. It defines what outside readers cannot verify.

Rollback was a two-state continuity problem

The response sequence reveals a common danger in automated networking: the source of truth and the running router can remain inconsistent during recovery.

At 20:50, Cloudflare says an operator manually reverted the configuration and paused automation [1]. Both actions were necessary for a stable rollback. The router needed immediate correction, while the controller needed to stop enforcing the still-unreverted repository state.

At 21:47, the repository change was reverted. This brought the generating source back into alignment with the desired router state. At 22:07, operators judged automation healthy. At 22:40, they unpaused it [1].

This sequence provides a useful continuity pattern:

Contain the emitted routing state.
Prevent automated reapplication.
Correct the generating source.
verify rendered output and route effects.
Resume automation explicitly.

The sequence is public, but the verification detail is not. A durable record should show which rendered policy was expected after the repository revert, whether it matched the manual router state, whether every affected neighbor had withdrawn the unauthorized routes and whether external observations had normalized.

Rollback also needs idempotency across partial failure. If an operator changes one router while the controller is paused, the system should know that the device is intentionally out of sync. When automation resumes, it should calculate the prospective delta again rather than assuming the repository revert makes replay harmless.

The recovery control should survive the same failure domain as the change. If the automation system that generated the broad term is also the only system that declares the rollback healthy, its conclusion needs independent confirmation from router state and emitted routes.

Decision ownership should be explicit at each transition: who may pause automation, who confirms the repository correction, who accepts the rendered-policy comparison and who authorizes resumption. The public record does not name those owners, and no names should be inferred. Internally, roles and decisions should be preserved so that recovery does not depend on memory during a routing emergency.

The event also demonstrates why automation health cannot mean only “the system ran without error.” The bad policy was syntactically usable and reached a router. A healthy result must include semantic agreement: the generated policy restricts exports as intended, the resulting route sets remain within bounds and no external observation contradicts the expected state.

Incident communication as operational evidence

Cloudflare's post provides several details that make the event analyzable: the intended cleanup, surviving policy condition, accepting action, address family, router location, relationship directions, sample prefix, sample AS path, impact boundary, measured effects, response chronology and future control directions [1].

That specificity is valuable because it connects configuration semantics to routing consequences. A vague statement about a network issue would not permit analysis of why an internal route classification was unsafe for external export.

The disclosure also has limits. It does not include the complete before-and-after rendered policy, a full leaked-prefix inventory, per-neighbor Adj-RIB-Out changes, all public collector views, detailed RIB/FIB evidence, customer-specific effects, alert chronology, private topology or named decision ownership. It does not demonstrate subsequent control effectiveness.

Future commitments should remain clearly labeled as commitments. Cloudflare said it would evaluate empty or erroneous policy terms in its automated checks, add BGP-community safeguards, validate vendor support for BGP Roles and OTC, and improve early detection [1]. Those are appropriate directions for the disclosed failure mode. The incident post alone cannot establish their later coverage or performance.

Cloudflare's materials on Radar route-leak detection, anomaly investigation, leak interfaces and routing terminology provide context for public BGP observability [2][3][4][5]. They should not be used to claim that Radar automatically prevented, detected or closed this specific event unless event-linked evidence says so.

Useful follow-up disclosure would report outcomes rather than intentions: the number of accepting terms examined, whether rendered route-set expansion is now tested, which relationship controls are enforced, whether IPv6 Adj-RIB-Out canaries automatically abort and how later exercises demonstrated that rollback remains stable.

Accountability does not require exposing sensitive topology or customer data. Aggregated route counts, relationship-class results, test coverage and time-bounded collector confirmation can establish that a control works without publishing confidential details.

An event-specific accountability scorecard

Miami accountability question	Evidence available publicly	Supportable result	Evidence still needed
Did the Bogotá cleanup remain subtractive after rendering?	Cloudflare says the last prefix-list condition disappeared while `route-type internal` and `accept` remained [1].	No; the rendered meaning expanded beyond the stated cleanup intent.	Old and new rendered terms plus their evaluated match sets.
Could automation detect a newly underconstrained accepting term?	Cloudflare identified evaluation of empty or erroneous terms as future work [1].	Preventive detection was not demonstrated for this change.	A passing structural test on equivalent last-predicate removal cases.
Were peer and provider directions enforced independently of the prefix list?	Peer-learned and provider-learned routes were exported across prohibited directions; community and RFC 9234 work was described prospectively [1].	Independent relationship enforcement was not demonstrated.	Per-session roles, trusted provenance marks and rejection results.
Did one-router activation contain external reach?	One Miami router emitted routes that appeared in public path data [1][7].	Device scope was narrow; routing scope was not contained.	Pre-emission Adj-RIB-Out comparison and automatic abort evidence.
Was the IPv6 route-set delta bounded before release?	Cloudflare reports IPv6-only impact but publishes no candidate delta [1].	Address-family scope is known after the event; the pre-activation bound is unknown.	Per-neighbor IPv6 additions, removals and allowed envelope.
Did public routing evidence corroborate the disclosed path?	The bounded BGPlay query returned 1,548 events, 1,440 with AS13335 and AS32934 in the path [7].	Yes, for the queried prefix, time window and collector visibility.	Broader prefix and vantage-point reconciliation, if available.
Did forwarding controls limit the consequences of bad advertisements?	Cloudflare says firewall filters discarded non-downstream traffic, peaking near 12 Gbps, while congestion, latency and loss occurred [1].	Discard limited unauthorized transit but did not prevent attraction or collateral impact.	Prefix-level RIB/FIB, firewall and traffic correlation.
Could manual rollback remain stable while source state was still wrong?	Cloudflare reverted the router and paused automation at 20:50, then reverted the repository at 21:47 [1].	The response addressed both running and generating states in sequence.	Evidence that no router was reapplied and all exports withdrew.
Was resumption based on route behavior rather than controller execution alone?	Automation was judged healthy at 22:07 and resumed at 22:40 [1].	Recovery judgment and deliberate resumption are disclosed; criteria are not.	Rendered-policy, Adj-RIB-Out, RIB/FIB, traffic and external-path results.
Does the disclosure separate evidence from uncertainty?	It provides mechanism, chronology, impacts and a path example but not complete topology, customer losses or control evidence [1].	Strong event-specific disclosure with material unanswered questions.	Later evidence of remediation deployment and effectiveness.

The scorecard does not assign legal responsibility or infer individual fault. It asks whether the public record demonstrates controls proportionate to the routing authority exercised by the Miami router.

Its most important result is the difference between response capability and preventive proof. Cloudflare disclosed a structured response: investigation, escalation, manual revert, automation pause, source revert, health judgment and resumption. The record is much weaker on evidence that the generated policy was semantically bounded before activation.

The public-path row is the clearest independently corroborated element. The BGPlay query supports external visibility for the example prefix. Most other rows depend on Cloudflare's internal account or remain undocumented externally.

The scorecard also shows that data-plane discard was a partial safeguard, not a routing solution. Refusing to forward non-downstream traffic limited Cloudflare's unintended transit role, but the preceding advertisement still attracted traffic and contributed to reported congestion, latency and loss.

Confirmed facts, bounded inferences, recommendations and unknowns

Confirmed within attributed public evidence

Cloudflare publicly states that the repository change was merged at 19:52 UTC; automation ran on one Miami router and impact began at 20:25; investigation started at 20:40; the incident was raised at 20:44; an operator manually reverted the configuration and paused automation at 20:50; the repository change was reverted at 21:47; automation was judged healthy at 22:07; and automation was unpaused at 22:40 [1].

Cloudflare states that the impact lasted 25 minutes, affected IPv6 only and involved Miami-to-Atlanta congestion, higher latency, elevated loss for some customer traffic and discard of non-downstream traffic at a peak it estimated near 12 Gbps [1].

Cloudflare states that deletion of the final prefix-list condition left route-type internal and accept, allowing internally redistributed routes to be exported to peers and transit providers. It identifies the Meta-peer and Lumen-provider direction and publishes the sample prefix and AS path [1].

Independently, the bounded RIPEstat query returned public update events containing the relevant AS combination during the event window [7]. What is independently confirmed is the visibility of that path pattern, not Cloudflare's private cause or impact measurements.

Bounded inferences

The disclosed policy description supports the inference that the accepted route set expanded when the final narrow predicate disappeared. This follows from the relationship between a conjunction of conditions and the broader surviving condition. The exact vendor configuration and full matched set remain unpublished.

The segment 3356 13335 32934, combined with Cloudflare's relationship labels, supports the peer-to-provider interpretation. The AS path alone does not establish the commercial relationships.

The one-router boundary supports the inference that limiting device count was insufficient to contain external routing impact. It does not establish whether Cloudflare intended the router as a canary or what canary controls existed.

The IPv6-only result supports family-specific failure scope. It does not prove complete operational independence between IPv4 and IPv6.

Recommendations derived from the event

Routing automation should reject newly underconstrained accepting terms, evaluate rendered policies against current routes, compare per-neighbor Adj-RIB-Out, encode relationship provenance independently, separate IPv4 and IPv6 checks, and abort on any unauthorized relationship crossing.

A live canary should have predeclared route-set, relationship, traffic and external-observation limits. Its automatic response should restore the previous policy and pause further activation.

RIB, FIB, firewall and traffic evidence should be reconciled so that the network cannot continue advertising destinations it classifies as non-downstream and discards.

Recovery should not close until device state, generating source, Adj-RIB-Out, emitted withdrawals, traffic signals and external paths agree. Resumption should have a named owner and preserved evidence.

RPKI origin validation should remain deployed where appropriate, but it should not be represented as a complete answer to relationship leaks. BGP Roles and OTC, trusted communities, receiving-side filters and developing path verification address different parts of the problem.

Unknowns that should remain unknown in this account

The public record does not reveal Cloudflare's complete private topology, exact automation internals, full affected-prefix set, all neighbor sessions involved, individual customer losses, total attracted traffic, every alert and threshold, decision ownership, hidden compensating controls or the detailed criteria used to judge automation healthy.

It also does not show whether the later community, policy-evaluation, detection or RFC 9234 work was deployed across the relevant network or whether it has successfully stopped an equivalent failure.

No conclusion about negligence, contract breach, regulatory liability or individual fault can be drawn from the frozen evidence. Those questions would require facts and standards outside the public routing record considered here.

The empty-export-policy accountability test

The central lesson from Miami is not that automation should be abandoned. Manually maintained routing policy can produce the same class of error and make consistency harder. The lesson is that automation must prove the semantics of what it generates.

A repository merge showed what Cloudflare intended to change. The rendered term determined what the router could accept. The route state determined which prefixes qualified. Adj-RIB-Out determined what each neighbor could receive. Public collectors showed what escaped. Traffic and discard measurements showed consequences. Rollback required both the running router and the generating source to return to a safe state.

Each layer carries a different kind of truth. Source intent cannot override a broad rendered term. A valid origin cannot authorize an intermediate relationship. A one-router activation cannot guarantee a small routing radius. A successful controller run cannot establish that emitted routes are safe. A restored configuration cannot by itself prove that external paths and traffic have recovered.

For this event, the decisive preventive question was simple enough to state: after the Bogotá prefix-list references were removed, did any peer- or provider-learned IPv6 route become newly eligible for export from Miami?

A reliable system should answer that question before sending the first update. It should preserve the answer by neighbor, relationship and address family; stop when the answer is nonzero; and verify the result against both router state and the public routing system.

Cloudflare's disclosure explains how an apparently subtractive cleanup became an expansive export policy. The enduring accountability standard is equally concrete: routing authority is defined by the rendered policy and the routes actually emitted, not by the narrowness of the edit that produced them.