BGP Role model: tracking the adoption of RFC 9234

Cloudflare evaluated the deployment and effectiveness of Border Gateway Protocol (BGP) Role configurations on the global Internet by monitoring Autonomous Systems (ASes) that send the Only to Customer (OTC) attribute to its network, according to a Cloudflare Blog's report. During the analysis, Cloudflare discovered that two large Tier-1 networks were unexpectedly stripping the OTC attribute from routes they forwarded, prompting direct engagement with those Tier-1 providers to allow OTC attribute propagation.

This article covers how RFC 9234 implements BGP Roles and the OTC attribute to eliminate route leaks automatically without manual prefix filtering. It examines the mechanics of BGP session negotiation, why attribute stripping by upstream providers undermines leak prevention, which network operators are affected, and what steps network administrators should take to implement BGP Role configurations across their sessions.

BGP Role model: what actually changed

RFC 9234 shifts the burden of preventing BGP route leaks from error-prone, operator-written prefix filters to the BGP protocol itself. Route leaks occur when routing announcements propagate beyond their intended scope, violating valley-free hierarchy rules by propagating a route learned from a provider or peer to another provider or peer. Historically, each AS had to manually enforce routing intent across sessions using static policies and Internet Routing Registry (IRR) data. Under RFC 9234, routers negotiate their explicit neighbor relationship in-band and use protocol-level mechanisms to identify and block invalid paths dynamically.

The RFC introduces a BGP Role capability for UPDATE and OPEN messages alongside the Only to Customer (OTC) path attribute. By embedding relationship definitions directly into session handshakes, BGP can automatically validate whether route announcements align with agreed provider-to-customer or peer-to-peer structures. When a route strays from its permitted path, a router supporting RFC 9234 can reject the leak independently without relying on external, hand-crafted filtering rules.

BGP Role model: how it works

BGP Roles require two neighboring routers on an External BGP (eBGP) session to declare their relationship during session establishment. The specification defines five roles: Provider, Customer, Peer, Route Server (RS), and RS-Client. Only five specific pairings are valid between neighbors: Provider with Customer, Customer with Provider, RS with RS-Client, RS-Client with RS, and Peer with Peer. If both sides announce conflicting roles during negotiation, such as Customer and Peer, the session handshake fails immediately with a Role Mismatch notification code 2, subcode 11, preventing misconfigured relationships from establishing.

Complementing role negotiation is the OTC path attribute, an optional transitive attribute (type code 35) that carries the Autonomous System Number (ASN) of the network where a route first transitioned downward or sideways. Once attached, the OTC attribute must remain unchanged as the route propagates. If a router receives an OTC-marked route from a customer or RS-client, or if an OTC-marked route arrives from a peer with an ASN other than that peer's own, the receiving router identifies the path as a route leak and rejects it automatically.

BGP Role model: why it matters now

Route leaks create unauthorized traffic paths across the Internet, leading to hairpin turns where customer networks absorb unwanted traffic between upstream providers, causing severe latency and packet drops. Cloudflare tracks these routing anomalies using the Cloudflare Radar route leak detection system, highlighting the persistent frequency and operational impact of unauthorized route propagation. Implementing RFC 9234 provides an immediate, standardized protocol defense that reduces reliance on complex IRR-derived policies.

Furthermore, BGP Roles directly support Autonomous System Provider Authorization (ASPA) validation mechanisms. ASPA algorithms require routers to apply distinct validation logic depending on whether a path originates from a provider, peer, customer, or route server. BGP Roles inform the router which algorithmic path verification to execute, making the concurrent configuration of BGP Roles and ASPA essential for modern routing security architecture.

BGP Role model: who is affected

Network operators, Internet Exchange (IX) members, and transit providers implementing RFC 9234 are directly affected by how neighboring ASes handle path attributes. Because OTC is designated as an optional transitive attribute, legacy routers that do not support RFC 9234 are required by standard BGP specifications to pass the attribute along to downstream neighbors without modifying or discarding it. This allows early adopters to gain partial route leak protection even across networks with mixed vendor support.

However, Cloudflare's measurement of peer ASes discovered that two major Tier-1 networks actively strip the OTC attribute from routes they forward. This unexpected stripping breaks the transitive chain required for route leak detection, depriving downstream early adopters of the protection RFC 9234 provides. Cloudflare is actively engaging with these two Tier-1 networks to restore OTC propagation across their backbones.

BGP Role model: what to watch

Network administrators planning deployment must evaluate whether to use default compatibility or enable strict mode. By default, if a router configured with a BGP Role connects to a neighbor that does not send the Role capability, the session still establishes while applying local role rules. Strict mode forces the router to reject any session where the neighbor fails to declare a Role capability, though widespread adoption is not yet high enough for strict mode to be practical on most transit sessions.

Operators must also audit complex neighbor relationships where multiple relationship types exist over a single eBGP session. RFC 9234 prohibits configuring BGP Roles on multi-relationship sessions; operators must instead split complex arrangements into separate eBGP sessions for each relationship type and configure the appropriate Role on each session. Monitoring Tier-1 attribute propagation and configuring eBGP sessions with explicit roles remain critical milestones for broader Internet route safety.