Route leak prevention moves into the protocol, and two Tier-1s are stripping the signal

Cloudflare has described a method for measuring RFC 9234 uptake by watching which of its peer autonomous systems attach the Only to Customer (OTC) path attribute to the routes they send it, using its global peering presence as the vantage point ^[1]. In the course of that work it found something it says it did not expect: two large Tier-1 networks strip the OTC attribute from routes they forward ^[2].

The mechanism being measured is worth stating precisely, because it is a change in who does the work. BGP routing is driven by relationships between ASes, customer-provider and peer-peer, where customers pay providers for access to the rest of the Internet and peers exchange traffic settlement-free ^[3]. Those relationships imply a valley-free hierarchy: a route learned from a provider or a peer should be announced only downward to customers, never back up to another provider or peer ^[4]. The rules are asymmetric, and an AS may send upward or sideways only the routes it originates and those learned from its own customers ^[5]. RFC 7908 defines a route leak as the propagation of routing announcements beyond their intended scope ^[6], and the common shape is the hairpin turn, a customer announcing a route between two of its providers ^[7]. That is bad economics and bad capacity planning at once: the customer is not paid to carry traffic between its upstreams and may not be able to absorb it, producing added latency or drops ^[8].

Until now the enforcement has been manual. Existing defenses depend on prefix filters and IRR-derived policies, which require every AS to express its own relationships correctly, by hand, on every session ^[9], and Cloudflare characterises that per-network implementation as complex and error-prone ^[10]. RFC 9234, titled Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages, moves the intent into the protocol ^[11]. It adds a BGP Role capability that requires two neighbours to agree on their relationship when the session comes up ^[12], and the OTC attribute, which marks routes that must not propagate beyond customers ^[13]. A router that understands OTC can reject a leaked route on its own, with no operator-written policy behind it ^[14]. Enforcement shifts from the correctness of the sender's configuration to a check at the receiver ^[15].

That shift only holds if the marking survives the middle of the path. An attribute that an intermediate network deletes stops protecting every AS beyond that network, which is why the Tier-1 behaviour matters more than a percentage figure would ^[16]. Cloudflare says it has been engaging with the two networks to allow OTC propagation, on the grounds that this is what makes leak prevention work for early adopters ^[17]. It also runs the Cloudflare Radar route leak detection system, which tracks routing anomalies continuously ^[18].

Read the adoption number, when you see it, as a floor rather than a census: the method counts peers that send OTC to Cloudflare, so sessions Cloudflare is not on are invisible to it ^[19]. Watch whether the two unnamed Tier-1s change their handling, and whether stripping turns out to be deliberate policy or a side effect of unknown-attribute treatment. Operators with Role support available should check both directions of their own sessions, since a correctly marked route is only useful if the neighbour agrees on the relationship it was marked under ^[12].