Cloudflare published an analysis of the prevalence of RFC 9234, which is used to limit routing leaks in the BGP protocol, based on data from exchange sessions with its networks and experiments in which it announced test routes across the Internet. The company found that 67 networks were adding the Only to Customer attribute, or OTC, to routes they sent directly. However, it also discovered that a number of networks remove this attribute while forwarding routes, weakening the ability of compliant networks to detect and reject leaks.
BGP leaks occur when a network announces a route learned from a provider or peer to another provider or peer, contrary to the commercial relationships and presumed hierarchical logic of Internet routes. This may cause data traffic to pass through a network that was not prepared to handle it or was not authorized to forward it in the first place, potentially resulting in increased latency, packet loss, or broader outages.
Moving Leak-Prevention Rules into the Protocol
Traditional protection mechanisms require every operator to configure manual policies, such as prefix filters and policies derived from IRR records, which requires precisely defining the relationship of each BGP session. RFC 9234 proposes shifting part of this burden into the protocol itself through two components: BGP Roles and the OTC attribute.
BGP Roles define the nature of the relationship between neighbors in an eBGP session, such as Provider, Customer, and Peer, in addition to RS and RS-Client, which are associated with route servers at Internet exchange points. When the two parties advertise incompatible roles, the session is rejected with a Role Mismatch notification instead of continuing until the error later appears as an actual leak. In cases of partial adoption, the session can operate if only one party sends a role, unless the operator enables strict mode, which rejects sessions in which the other party advertises no role.
The OTC attribute records the autonomous system number that first added it when a route stops moving upward through the hierarchy and begins moving toward customers. Once it exists, the route should not be sent to a provider, peer, or route server. A compliant router can also reject a route carrying OTC if it arrives through a relationship that does not permit it. This makes prevention automatic after roles are configured, rather than relying exclusively on a policy written by the operator for each session.
What Did Cloudflare Actually Measure?
Cloudflare used BMP data from its routers and monitored the OTC value received from direct neighbors over three months. It considered a network a compliance candidate when the attribute value matched the neighbor’s autonomous system number, a method that reduces ambiguity when analyzing routes that passed through several networks. These measurements showed 67 autonomous systems adding OTC, with the observation that route servers may adopt new features more quickly and that some privately operated networks appeared at a notable rate in the results.
Analysis of public RIB data from RouteViews and RIPE RIS produced more conservative results. After attempting to distinguish between networks that add OTC when sending and those that fill in a missing value upon receipt, Cloudflare identified 18 networks that were likely adding the attribute and 20 networks that were likely filling it in. Combining these results with those from direct neighbors produced 36 networks that were likely compatible with RFC 9234. The company emphasized that the methodology may miss networks with a limited number of routes or neighbors.
Networks That Removed OTC
Cloudflare tested OTC propagation by announcing an IPv4 prefix and an IPv6 prefix carrying the value 13335 from its exchange locations, then analyzed BGP messages during the announcement and withdrawal using RIPE RIS and RouteViews data, as well as local BMP data. In the first phase, it identified six autonomous systems that remove the attribute, including the two Tier 1 networks GTT, AS3257 and Arelion, AS1299. Continuing the analysis of longer paths led to the identification of nine additional networks that remove OTC.
The attribute was absent from 33.1% of IPv4 AS_PATHs and 17% of IPv6 paths in the experiment. GTT, Arelion, or both appeared in 96.6% of IPv4 paths that lost OTC and 92.9% of IPv6 paths, with Arelion accounting for most cases. When examining paths whose next hop was one of the two networks, Cloudflare found that GTT consistently removed the attribute, while Arelion removed it in 71.4% of IPv4 paths and 40.7% of IPv6 paths in the relevant sample.
Cloudflare said the two networks confirmed that OTC removal was part of defensive practices that arose after incidents related to the handling of BGP errors. According to the published results, GTT’s configurations continued to remove the attribute, while Arelion began preserving it after communicating with Cloudflare, which was verified through a later analysis of the test routes.
What Changes in Practice for Network Operators?
The results show that adoption of RFC 9234 depends not only on routers supporting the feature, but also on intermediate networks continuing to forward the optional transitive attribute. Removing OTC in a network with a central position may prevent a compliant network several hops downstream from detecting a leak that could have been prevented.
Cloudflare notes that Junos OS and Junos OS Evolved support RFC 9234, and that support for Cisco IOS XR was scheduled for release 26.4.1. Its table listed other implementations without specifying a complete support status, including Arista EOS, Nokia SR OS, Huawei, Extreme SLX-OS, RouterOS, BIRD, OpenBGPD, FRR, ArcOS, GoBGP, and ExaBGP. The company recommends that operators with the feature available configure BGP roles gradually during maintenance windows, because deploying it requires resetting BGP sessions. Cloudflare has also begun gradually deploying the configurations across its global fleet and plans to make adoption data available in the Routing section of Cloudflare Radar.