BGP Role model: tracking the adoption of RFC 9234

Route leaks send traffic down paths its originators never intended. For years, defenses have been manual: every AS had to encode its business relationships into hand-written routing policies. RFC 9234 offers an in-protocol alternative by letting BGP speakers declare their relationship and tag routes with the Only to Customer (OTC) attribute, so a router can reject a leaked route without a single line of operator policy.

How the protocol expresses intent

The relationship between two Autonomous Systems (ASes) determines how routes should propagate. Customers pay providers; peers exchange traffic under settlement-free arrangements. The result is a "valley-free" hierarchy: a route learned from a provider or peer should only be announced downward to customers. A route leak, per RFC 7908, is any propagation beyond that intended scope. A common example is the hairpin turn, where a customer announces a route received from one provider to another, effectively carrying transit between the two.

The rules are asymmetric. Routes flow freely downward: a provider can hand a customer anything in its table. But upward and sideways announcements are limited to locally-originated routes and those learned from customers. Violations are frequent and consequential — they cause misdirection, capacity strain, and outages across the Internet.

Roles at session time

RFC 9234 introduces a BGP Role capability exchanged when an eBGP session comes up. Five roles exist: Provider, Customer, Peer, RS, and RS-Client. The first three map to transit and lateral peering relationships; RS and RS-Client involve Internet Exchange route servers. Only five pairings are valid, and when both sides advertise a Role that doesn't match, the session is rejected with a Role Mismatch notification (code 2, subcode 11). That makes latent relationship disagreements surface as a failed handshake rather than as an operational incident later.

During partial deployment, one-side-only Role configuration is the norm. By default, if your neighbor sends no Role, the session still comes up and your configured Role still offers partial leak protection. "Strict mode" — rejecting sessions without a Role from the neighbor — is opt-in and not yet realistic for most networks. If an AS holds multiple relationships with the same neighbor over a single session (e.g., customer for some prefixes, peer for others), RFC 9234 forbids configuring a Role on that session entirely; operators must split the relationships into separate eBGP sessions.

Roles have a second purpose beyond session negotiation. When combined with ASPA validation, the Role tells the router which path algorithm to run: routes from a provider may contain full vertical motion in the path, while routes from non-providers must only descend through customers. RFC 9234 authors recommend configuring Roles and ASPA together on routers that support both.

The OTC attribute in action

OTC is an optional transitive path attribute (type code 35) that records the ASN of the first network to send the route sideways or downward. Once set, RFC 9234 requires it to be preserved unchanged. Because it's optional transitive, even routers without RFC 9234 support should pass it along.

The behavior depends on your Role on each session. OTC is attached at the point a route stops travelling strictly upward: when announcing to a customer, peer, or RS-client with no OTC present, you set it to your own ASN; when receiving from a provider, peer, or RS with no OTC present, you attach it carrying their ASN. Once carrying OTC, a route may only move downward: never announce it to a provider, peer, or RS. An OTC-carrying route arriving from a customer is a leak and should be rejected; so is one arriving from a peer unless it carries that peer's own ASN.

Consider a hairpin leak where AS64504 announces a route from one provider to another. The protection kicks in at two points: if AS64504 honors Role rules, it won't announce an OTC-tagged route to a provider at all. If it misbehaves anyway, the receiving provider sees an OTC attribute on a route from a customer and marks it ineligible. Either check alone is sufficient to stop the leak.

Measuring RFC 9234 deployment is not straightforward

RFC 9234 leaves room for ambiguity when it comes to identifying who actually sets the OTC value. The specification calls for OTC to be attached on both egress and ingress routes, which is useful for coverage but muddies attribution. Consider the path 64506 64507 with OTC=64507: we cannot tell whether AS64507 stamped the value on egress or AS64506 filled it in on ingress because the attribute was missing.

That ambiguity complicates any attempt to measure real-world adoption of RFC 9234. To get a handle on it, we turned to the public BGP data collected by RouteViews and RIPE RIS. A naive count of distinct OTC values in the RIB dumps yields 361 potential setter ASes, but that number is inflated by ASes that fill in missing values from peers, providers, and route servers. Filtering for cases where the OTC value equals the first AS of the AS_PATH narrows the field to nine setter ASes, as those paths reflect raw received BGP messages at the collectors.

To distinguish egress from ingress setting further out in the path, we used a more relaxed heuristic. We collected all AS_PATH edges (ASX ASZ) where OTC = ASZ, then built two mappings: downstream (ASN→next hops) and upstream (ASN→previous hops). We then removed ASes that appear with high confidence to be setting OTC on the other side—specifically those with at least 10 downstream or upstream neighbors—and kept ASes with at least three remaining next or previous hops. That process surfaced 18 ASes likely setting OTC and 20 ASes likely filling in missing values on ingress. Combined with the direct peer observation, we find only 36 ASes that are potentially RFC 9234-compliant, though the actual number will need deeper investigation.

This method has known blind spots. ASes with very few upstreams or downstreams may be missed entirely. We are already considering refinements, for instance using the absence of OTC as negative evidence that an AS is not setting it. That approach would require accurate AS relationship data to focus only on cases where OTC should be attached—such as CAIDA’s or BGPKIT’s AS Relationships datasets—but AS relationship inference has been a hard problem for more than two decades. Still, public data remains invaluable, even with its inherent limitations.

Testing adoption at the edge

To complement the global view, we ran controlled experiments from Cloudflare’s own network, which has thousands of peers under an open peering policy. Because Cloudflare connects directly to many ASes, we can observe their behavior without the noise introduced by intermediate hops. Using our BMP feeds, we monitored OTC values on routes received from peers over the past three months. The test is simple: if the OTC value equals the peer’s ASN, that peer is setting the attribute on egress.

That check identified 67 ASes that set the OTC attribute. Characterizing those ASes by their PeeringDB network type (with some manual corrections) reveals two notable patterns:

• Route servers lead the way. They are more likely to adopt new features quickly, partly because many run open-source BGP implementations. YYCIX was the first to deploy RFC 9234. Since route servers sit in the propagation path for many routes, their compliance helps protect a significant portion of the Internet.
• Individual operators are well represented. A likely explanation is their inclination toward open-source BGP stacks, which tend to adopt new standards faster than proprietary implementations.

We will continue tracking RFC 9234 adoption via OTC and plan to publish this data publicly in Cloudflare Radar’s Routing section. In the meantime, we are also investigating a related question: which networks might unexpectedly strip the OTC attribute from routes they forward.

Measuring OTC stripping across the Internet

RFC 9234 defines OTC as an optional transitive attribute, and Section 5 of RFC 4271 mandates that unrecognized transitive attributes MUST be passed to other BGP peers with the Partial bit set. Yet prior to RFC 7606, a malformed transitive attribute could trigger cascading session resets far from the origin AS. That vulnerability led some operators to defensively drop unrecognized transitive attributes entirely — even at the cost of breaking legitimate propagation.

That history matters because OTC propagation is essential for RFC 9234-compliant ASes multiple hops away to detect route leaks. In early partial deployment, top-tier ASes in particular must preserve OTC or risk undermining the whole scheme. A recent incident where a malformed OTC attribute caused session resets in some BGP implementations underscored how fragile this balance remains.

To find out which ASes strip OTC in practice, we announced one IPv4 and one IPv6 prefix with OTC = 13335 attached, from all Cloudflare peering locations using BGP Anycast. After global propagation was confirmed, we withdrew the prefixes to trigger path hunting and reveal additional routes — giving us more chances to observe paths where OTC went missing. We parsed UPDATE messages (rather than RIB snapshots) from MRT dumps at RIPE RIS and RouteViews collectors, plus local BMP data, using the BGPKIT toolkit. Update analysis retrieves more routes across both the announcement and withdrawal phases.

We first examined AS_PATHs of the form ASX AS13335. A path without OTC in that shape means ASX stripped the attribute. This revealed six ASes dropping OTC, including two Tier-1 networks: AS3257 (GTT) and AS1299 (Arelion). We then applied an iterative algorithm to longer paths:

1. Seed a trusted set T with AS13335 — ASes that propagate OTC.
2. For each AS_PATH, filter out all ASes in T.
3. If only one AS remains, attribute OTC presence or absence to that AS.
4. Add ASes that preserved OTC = 13335 to T.
5. Add ASes where OTC is absent to the droppers set D.
6. Repeat from step 2 until T no longer changes.

This method surfaced nine more ASes stripping OTC. Counting distinct AS_PATHs without OTC, we found 33.1% of IPv4 routes and 17% of IPv6 routes had the attribute removed.

Tier-1 impact and follow-up

Because of their central position, AS1299 and AS3257 account for the bulk of observed stripping. Together they appeared in 96.6% of IPv4 and 92.9% of IPv6 OTC-absent paths, with Arelion responsible for the vast majority. When we narrowed analysis to paths where the next hop after AS13335 was one of these two, we found GTT consistently removed OTC, while Arelion dropped it on 71.4% of IPv4 and 40.7% of IPv6 paths — an inconsistent pattern across their network.

Both GTT and Arelion confirmed that they had been stripping OTC as defensive practice after past BGP error-handling incidents. Current GTT configurations still remove OTC, which continues to limit RFC 9234's effectiveness for route leaks transiting AS3257. Arelion, however, rolled out configuration changes shortly after our conversation. Verification via BGKIT Monocle confirms OTC is no longer absent from paths through AS1299 for our experiment prefixes:

➜  ~ monocle search -D rib \
  --start-ts "2026-08-18T00:44:00Z" \
  --end-ts "2026-08-18T03:44:00Z" \
  -p 8.44.61.0/24 \
  -a '^1299 13335$' \
  --collector route-views4 \
  -f type,timestamp,peer_asn,prefix,as_path,only-to-customer \
  --json
{
  "as_path": "1299 13335",
  "only_to_customer": 13335,
  "peer_asn": 1299,
  "prefix": "8.44.61.0/24",
  "timestamp": 1787017771.0,
  "type": "ANNOUNCE"
}

The result is measurable: route leak prevention using OTC is already more effective because of the engagement.

Deploying BGP Roles in practice

BGP Roles and the OTC attribute are foundational for preventing route leaks from propagating. As of August 2026, the following implementations support RFC 9234 or have plans to:

Where RFC 9234 is supported, we recommend configuring Roles now. Note that sessions must be reset when applying Roles, so plan the rollout during maintenance windows. Cloudflare has already begun gradual deployment across its global router fleet. Once Roles are applied, route leak prevention via the Only to Customer attribute is automatic — no complex routing policy is required. If your vendor lacks support yet, ask them for it; early adoption is what stops leaks from spreading in the first place.