Wait, a Tier-1 network was stripping BGP's route-leak-blocking "OTC" attribute!

Hi, it's Shii! Today I want to share an interesting piece of research I found on Cloudflare's blog about BGP security. It sounds like a deep, unglamorous corner of networking, but it turns out there was a pretty surprising discovery hiding in there!

Cloudflare Blog blog.cloudflare.com

What was announced?

Cloudflare's blog published the results of its own investigation into how widely "BGP Role" and the "Only to Customer (OTC)" attribute — together known as RFC 9234 — have been adopted on the Internet. This is a mechanism designed to automatically prevent route leaks.

And along the way, Cloudflare found that two major Tier-1 networks were quietly stripping the OTC attribute from routes passing through them. Cloudflare reached out to both networks directly and has been pushing for improvements.

Why it matters

BGP routing is built on relationships between networks, like "provider and customer" or "peer and peer." Routes are generally free to flow downstream, from a provider to its customers, but if a route learned from a customer gets forwarded sideways to another provider, it can send a flood of traffic down a path nobody intended — that's a route leak. Leaks like this have caused Internet-wide outages in the past.

Until now, enforcing "only flow downstream" has been left entirely up to each network's own filtering configuration. That configuration is complex and error-prone, which is part of why route leaks keep happening.

RFC 9234 bakes that relationship directly into the BGP protocol itself. Once a network supports it, routers can automatically detect and reject leaks without an operator having to hand-write a policy. That's exactly why it matters to know how far this has actually spread in practice.

What changes

Cloudflare built a unique measurement method using its global peering network, directly observing which networks properly send the OTC attribute. In the process, it found that two Tier-1 networks, AS3257 (GTT) and AS1299 (Arelion), were stripping the OTC attribute from routes passing through them.

Because Tier-1 networks sit close to the core of the Internet, losing the attribute there means it never reaches RFC 9234-compliant networks further downstream, which weakens the whole route-leak-detection effort.

When Cloudflare shared its findings with both networks, each confirmed they had configured their routers to defensively drop optional attributes, a leftover practice from past BGP error-handling incidents. Arelion rolled out a configuration change shortly after talking with Cloudflare and has confirmed it now preserves the OTC attribute. GTT, as of this writing, is still stripping it.

Dive Deep

Let me walk through how BGP Role and the OTC attribute actually work, and how Cloudflare's measurement worked.

What is a BGP Role? It's a mechanism where both ends of a BGP session explicitly agree on their relationship. There are really only three valid combinations:

• Provider ⇔ Customer
• Peer ⇔ Peer
• Route Server (RS) ⇔ RS-Client

Both sides need to configure the correct one. If both sides send a Role and the pairing doesn't match one of these, the BGP session itself fails to establish with a "Role Mismatch" error. That's the key benefit: a mismatched relationship gets caught at session setup, before it can turn into an incident.

The role of the OTC attribute: OTC works like a tag attached to a route. The moment a route stops moving upward (from customer toward provider), the AS number that made that turn gets written into it. Once a route carries OTC, the rule is it can only continue flowing downstream from there — so a router just has to check for OTC to mechanically know "if I forward this to a provider or peer, that's a leak." And because OTC is an "optional transitive" attribute, even routers that don't understand it are supposed to pass it along unchanged rather than dropping it.

How did they measure adoption? First, Cloudflare analyzed public BGP collector data from RouteViews and RIPE RIS. Naively counting distinct OTC values turned up 361 candidate ASes — but that number is inflated, because receiving networks sometimes fill in a missing OTC value themselves. Narrowing down to ASes that could be confidently confirmed as setting OTC directly toward the collectors left just 9, and even after adding a path-tracing technique, only 36 ASes total could be confidently identified as RFC 9234-compliant.

So Cloudflare turned to its own large-scale peering network instead, matching the OTC value received directly via BMP (BGP Monitoring Protocol) feeds against the sending peer's AS number. Looking at the past three months of data, it found 67 ASes setting the OTC attribute. Route servers and individually-run networks made up a disproportionately large share of that group, likely because they tend to run open-source BGP implementations that adopt new features faster.

The experiment to find who strips OTC: Cloudflare set up one IPv4 and one IPv6 test prefix, attached OTC=13335 (Cloudflare's own AS number), and announced them via Anycast from locations worldwide. After confirming the announcement had propagated, it withdrew the prefixes to deliberately trigger "path hunting," which surfaces more path variety for the team to observe.

That revealed 6 ASes immediately adjacent to Cloudflare that were dropping OTC, two of which were the Tier-1s AS3257 (GTT) and AS1299 (Arelion). Repeating the path-tracing method further out found 9 more ASes dropping it.

Overall, 33.1% of IPv4 paths and 17% of IPv6 paths were missing the OTC attribute. Of those OTC-absent paths, 96.6% (IPv4) and 92.9% (IPv6) went through GTT, Arelion, or both. GTT dropped OTC consistently, while Arelion only dropped it on 71.4% of IPv4 paths and 40.7% of IPv6 paths, suggesting inconsistent configuration across its own network.

Vendor support as of August 2026:

• Junos OS / Junos OS Evolved: supported
• RouterOS: supported
• BIRD: supported
• OpenBGPD: supported
• FRR: supported
• Cisco IOS XR: coming in the 26.4.1 release
• Arista EOS / Nokia SR OS / Huawei / Extreme SLX-OS / ArcOS / GoBGP / ExaBGP: not supported

Even on supported vendors, changing the Role configuration requires resetting the BGP session, so it needs to happen during a maintenance window. Cloudflare itself has already started gradually rolling out RFC 9234 configuration across its own router fleet.

Wrap-up

• Cloudflare used its own peering-based measurement method to investigate the real-world adoption of RFC 9234 (BGP Role + the OTC attribute), a mechanism that automatically prevents BGP route leaks
• Along the way, it discovered that Tier-1 networks GTT (AS3257) and Arelion (AS1299) were stripping the OTC attribute from routes
• Over 96% of OTC-absent paths went through one or both of those two networks; Arelion has already fixed it, while GTT was still stripping it as of this writing
• By Cloudflare's own measurement, only 67 ASes were setting OTC over the past three months, so real-world adoption still has a long way to go
• If you operate BGP routers, it's worth checking whether your vendor supports RFC 9234 and considering enabling Roles