Cloudflare measures RFC 9234 adoption and finds BGP route-leak defense still uneven
On August 18, 2026, Cloudflare published its measurement of RFC 9234 adoption, the BGP Role and OTC mechanism that catches route leaks at the source. The finding is blunt: support varies widely by vendor, and the OTC attribute only stops a leak if the whole path preserves it.
August 18, 2026. RFC 9234. OTC. On August 18, 2026, Cloudflare published its tracking of RFC 9234 adoption, the IETF standard that encodes the relationship between two networks directly into BGP to detect and prevent route leaks. Three researchers — Bryton Herdes, Iliana Xygkou, and Mingwei Zhang — measure who has actually deployed it, and the finding is blunt: defense is uneven across vendors, and a path attribute is useless if half the path ignores it.
What a route leak is, and why it costs
A route leak pushes traffic down paths it was never meant to take. BGP runs on the relationships between autonomous systems (ASes): a customer pays its provider for access to the rest of the Internet, while two peers exchange traffic with no money changing hands. Those relationships form a “valley-free” hierarchy: a route learned from a provider or a peer should only be announced downward, to customers, never back up to another provider or peer.
A leak happens when that intent is violated. Historically, every network had to implement the intent itself, with complex, error-prone routing policies. That is where RFC 9234 (“Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages”) steps in: it expresses the intent inside the protocol.
The standard introduces two pieces. First, a “BGP Role” capability: two BGP neighbors must agree on their relationship — provider, customer, peer — when the session comes up. Second, an “Only to Customer” (OTC) path attribute that marks routes which must stay with customers. A router that understands OTC can then reject a leaked route on its own, with no operator-written policy at all.
The measurement: not everyone is ready
Cloudflare’s work does more than explain the standard: it measures adoption on the public network. The most striking result concerns Arelion (AS1299), a large tier-1. The researchers found its paths were dropping the OTC attribute in transit — in other words, the network was stripping the very mark meant to protect the route. After an exchange with the team, Arelion rolled out a configuration that preserves OTC, and the researchers verified it on their experiment prefixes using monocle, their route-analysis tool.
That is the most useful demonstration in the post: route-leak prevention via OTC is fragile end to end. The attribute must survive every hop for a downstream router to make the call. A single intermediate AS that strips it — deliberately or by default — and the protection evaporates.
The support table, current as of August 2026, tells the same story on the vendor side:
| BGP implementation | RFC 9234 support |
|---|---|
| Junos OS / Junos Evolved | Yes |
| RouterOS (MikroTik) | Yes |
| BIRD | Yes |
| OpenBGPD | Yes |
| FRR | Yes |
| Cisco IOS XR | Coming in 26.4.1 |
| Arista EOS | No |
| Nokia SR OS | No |
| Huawei | No |
| Extreme SLX-OS | No |
| ArcOS | No |
| GoBGP | No |
| ExaBGP | No |
The reading is immediate: the open routing stacks (BIRD, OpenBGPD, FRR, RouterOS) are ahead, Juniper has shipped, while most major proprietary vendors — Arista, Nokia, Huawei, Extreme — still lack support, and Cisco will only have it with IOS XR 26.4.1.
What to configure, and in which order
Cloudflare has begun its gradual rollout of RFC 9234 across its global fleet, and urges operators whose vendor is ready to configure roles now. One operational detail matters: applying roles resets BGP sessions. The rollout therefore belongs in a maintenance window, link by link, with a documented fallback.
The hierarchy of defenses is worth spelling out. RPKI and origin validation (ROV) — which we detailed in our RPKI/ROV guide — answer a different question: “is this AS legitimate for this prefix?”. RFC 9234 answers: “does this route have the right to come up to me?”. These are two complementary layers, not competitors. Eventually, ASPA will add a third lock, on the provider side, to reject announcements from a customer that is not the real path.
How OTC propagates, and where it gets lost
The mechanism is worth understanding in detail, because it explains the fragility being measured. OTC is a transitive path attribute: a router that emits it stamps the route, and every hop is expected to preserve it before making a decision. A router that receives an OTC-marked route from a peer or provider knows the route has no business reaching it — it is flowing up instead of down — and can reject it.
The problem is that preservation is not guaranteed. An intermediate AS whose implementation does not know the attribute, or whose policy strips it, breaks the chain. That is exactly what Cloudflare observed at Arelion: the attribute vanished in transit, neutralizing the protection for every downstream network.
The most cited precedent remains the June 24, 2019 leak. That day, Verizon (AS701) accepted and then propagated thousands of routes from DQE Communications (AS396531), a small Pennsylvania ISP, because of a misconfigured BGP optimizer. Traffic from Cloudflare, Amazon, and Facebook flowed through a network that was never meant to carry it, causing congestion and outages for nearly two hours. RFC 9234 was designed precisely to prevent that scenario: a downstream router that understands OTC would have rejected those routes.
One asymmetry operators must accept: configuring roles on your side protects your own sessions, but end-to-end protection also depends on what upstream ASes do with the attribute. A network that preserves OTC correctly still inherits the failure of a neighbor that strips it. That is the point of initiatives such as MANRS (Mutually Agreed Norms for Routing Security), which push networks to adopt ROV, anti-spoofing, and leak prevention together — RFC 9234 sits squarely inside its fourth action.
Operationally, the rollout is incremental. Cloudflare recommends starting on a few sessions, confirming with a route collector that OTC survives the path, then widening the scope link by link. The reset of each session is the only disruptive step, which is why the deployment belongs in a maintenance window — and why a lab with a route collector (such as monocle, or any public BGP feed viewer) pays for itself before the first production session is touched.
Verdict
If your router supports RFC 9234 — Junos, RouterOS, BIRD, OpenBGPD, or FRR — configure roles at the next maintenance. The payoff is automatic: once roles are set, OTC protection no longer depends on policies someone still has to write and re-read.
If your vendor does not support it yet, the lever is not technical but commercial: ask for a date. As long as Arista, Nokia, Huawei, or Cisco (pre-26.4.1) have not shipped, your network remains a link that can leak — yours or your neighbor’s.
The conclusion fits in one sentence: the route leak is an end-to-end problem, and RFC 9234 is the first mechanism to treat it as one. Its real value depends on how much of the path understands it — and today, that share is still too uneven to lean on alone.