Border Gateway Protocol (BGP) keeps the global internet connected, but it was never designed with strong built-in safeguards against route leaks. RFC 9234 introduces “BGP Roles” and the “Only to Customer” (OTC) path attribute to help routers automatically detect and reject many route leaks without manual filters or complex policies.
This article explains what RFC 9234 does, how BGP Roles and OTC work in practice, how far adoption has progressed so far, and why some early deployment choices (including a few Tier 1 networks stripping OTC) matter for operators and service providers. If you run or depend on multi-homed connectivity, peering, or transit, understanding these changes will help you build a more resilient network.
Key Takeaways
- RFC 9234 introduces BGP Roles and the Only to Customer (OTC) attribute so routers can automatically detect and drop many route leaks.
- BGP Roles codify the business relationship between peers (customer, provider, peer, route server, etc.) directly in the BGP session.
- OTC is a simple BGP attribute that marks routes as “customer-only,” helping enforce correct propagation paths.
- Adoption is growing, but uneven: some networks are deploying RFC 9234 correctly, while others—surprisingly including two Tier 1s—are stripping OTC.
- OTC stripping undermines the standard and can break route-leak protections, especially for downstream networks relying on RFC 9234 behavior.
- Small providers and content networks can already start using BGP Roles and OTC to improve routing hygiene, as long as they monitor how upstreams handle the attribute.
What RFC 9234 Tries to Fix
BGP connects tens of thousands of autonomous systems (ASes). Each AS advertises which IP prefixes it knows how to reach, and those routes propagate through providers, customers, and peers. Because BGP does not strongly validate how routes move across business relationships, a misconfiguration or policy mistake can create a route leak:
- A customer accidentally redistributes full routes to a peer or another provider.
- A peer exports routes learned from one provider to another provider.
- Transit-free core networks end up forwarding traffic in ways that violate the intended economic or security model.
Historically, operators tried to reduce leaks using:
- Manual filters (prefix lists, AS-path filters, communities).
- IRR and RPKI-based validation (which help, but do not fully express relationship-based policies).
- Heuristics and monitoring tools to detect anomalies after they occur.
RFC 9234 takes a different approach: it encodes the type of relationship between neighbors in the BGP session itself (BGP Roles), and uses a simple path attribute (OTC) so routers can tell when a route has gone somewhere it should not go. The goal is to let routers automatically reject obvious leaks without relying solely on operator-maintained filters.
How BGP Roles Work
A BGP Role is an explicit statement about how two BGP neighbors relate to each other. Valid roles include:
- Provider – You are providing transit to the neighbor (they are your customer).
- Customer – The neighbor is providing transit to you (you are their customer).
- Peer – You exchange traffic on a settlement-free basis, usually just for your own and your customers’ prefixes.
- RS / RS-Client – Route server and route server client roles at IXPs.
- Internal roles – Between routers in the same AS, for consistency and policy enforcement.
The key is that roles are negotiated symmetrically when a BGP session is established. For example:
- If one side configures the session as “Provider”, the other must configure “Customer”.
- If one side configures “Peer”, the other must also configure “Peer”.
- RS–RS-Client relationships must match accordingly.
This negotiation means an operator cannot unilaterally claim “I am your provider” if the other side disagrees. Both endpoints must align, which helps detect configuration mistakes early and gives routers a trusted description of the relationship to use in policy decisions.
Only To Customer (OTC): The Enforcement Piece
The Only to Customer (OTC) attribute is the operational workhorse of RFC 9234. It is a transitive BGP path attribute that routers can attach to a route when exporting it to a customer. The semantics are:
- When an AS sends a route to a customer, it marks the route with an OTC attribute set to its own AS number.
- Downstream routers see OTC and know that the route has been exported by a provider (or peer/RS in some models) only for further export to customers.
- If a router sees an OTC-marked route and a policy would export it toward a provider or equal peer, that export should be rejected as a potential route leak.
In simple terms: OTC says “this route is now in a customer-only lane; do not send it uphill or sideways.”
Because OTC is a standard attribute, any RFC 9234-capable router can automatically:
- Add OTC when sending routes to customers (based on the BGP Role).
- Check OTC on received routes and enforce leak-prevention rules.
This reduces reliance on hand-built policies that are easy to misapply or forget during network changes.
Measuring RFC 9234 and OTC in the Wild
To understand how widely RFC 9234 and OTC are being used, researchers and operators look for evidence in:
- Public BGP collectors (e.g., RIPE RIS, RouteViews) to see which ASes advertise routes with OTC.
- Looking glass servers to test how particular networks treat OTC on ingress and egress.
- Controlled experiments (for operators that can manipulate test prefixes and observe behavior across multiple upstreams).
From this type of measurement, several patterns emerge:
- Incremental deployment – Some networks use BGP Roles and OTC on certain edges (e.g., at IXPs or a subset of customer links) while leaving legacy policy elsewhere.
- Partial attribute handling – A router may propagate OTC but not yet enforce leak prevention based on it, especially if the operator has updated software but not production policies.
- Attribute stripping – A few networks are removing OTC from BGP paths before exporting them, intentionally or unintentionally.
It is this third behavior—attribute stripping—that undermines the value of RFC 9234 and has raised particular concern.
Tier 1 Networks Stripping OTC: Why It Matters
Measurements have identified at least two Tier 1 networks that are stripping the OTC attribute from routes somewhere in their internal or external routing policy. Because Tier 1s sit at the core of the global internet, what they do with OTC has an outsized impact:
- If a Tier 1 removes OTC on ingress or before re-exporting routes to customers, downstream networks never see the OTC attribute and cannot leverage RFC 9234 protections.
- Networks that rely on OTC for leak detection might misclassify clean routes as “unmarked” and treat them differently than intended.
- Inconsistent behavior among large transit providers makes coordinated leak prevention more difficult for smaller ASes that connect to multiple upstreams.
There are several possible reasons for OTC stripping:
- Legacy route-map templates that drop unknown or “nonstandard” attributes.
- Conservative policies aimed at reducing attribute bloat without recognizing the new standard.
- Partial or misaligned upgrades, where some routers understand OTC and others do not.
Regardless of intent, stripping OTC counters the standard’s goals. Even networks that are not ready to enforce new policies should generally preserve OTC on transit paths so others can benefit from it.
Implications for Small Networks and Service Providers
For small ISPs, hosting providers, and content networks, RFC 9234 offers a path to better routing hygiene with less manual configuration, but early adoption comes with some nuances.
Benefits of Deploying BGP Roles and OTC
- Reduced risk of accidentally leaking routes to peers or upstreams if you misconfigure route maps.
- Stronger default behavior for new links: once roles are configured correctly, the router enforces business-relationship boundaries automatically.
- More predictable interactions with other RFC 9234-compliant networks, especially IXPs and security-conscious providers.
Practical Deployment Steps
If you are considering RFC 9234 in your own network:
- Check your platform support. Confirm your routers’ software versions implement BGP Roles and OTC, and review vendor documentation for any caveats.
- Start with clear relationships. Apply roles first on straightforward links (pure customer, simple peer) before touching complex or legacy setups.
- Enable OTC marking and enforcement incrementally. Begin by adding OTC on customer exports, then gradually enable enforcement on a subset of sessions.
- Monitor route behavior. Use BGP monitoring tools or looking glass tests to see how upstreams handle OTC. Note any networks that strip attributes.
- Align with existing policies. RFC 9234 is not a replacement for good IRR/RPKI-based filtering and prefix management; it complements them.
If a major upstream strips OTC, consider:
- Documenting that behavior so your team does not rely on OTC for paths transiting that provider.
- Discussing attribute handling with your account team or NOC to confirm whether stripping is intentional and whether it may change.
- Using communities and traditional policies as a fallback until they support RFC 9234 more fully.
What to Watch Next in RFC 9234 Adoption
As more vendors and networks implement BGP Roles, we can expect:
- Cleaner baseline policies for new BGP sessions, reducing human error.
- More accurate leak detection in monitoring systems that understand OTC.
- Community pressure on large providers to stop stripping OTC and align with the standard.
For operators, ongoing tasks include:
- Following vendor release notes and configuration guidance for updated support.
- Tracking measurements and public reports on RFC 9234 deployment trends.
- Reviewing your own internal templates so you do not inadvertently drop OTC or other emerging security-related attributes.
Conclusion: Moving Toward Safer, More Predictable BGP
RFC 9234 does not eliminate all BGP risks, but it is a meaningful step toward automating route-leak prevention based on the real-world relationships between networks. BGP Roles give routers the context they have always lacked, and the OTC attribute turns that context into enforceable policy.
Early measurements show a mixed landscape: some networks are deploying RFC 9234 as intended, while others—surprisingly including two Tier 1s—are stripping OTC and weakening its benefits for everyone downstream. As a small provider or network operator, you can still gain from adopting BGP Roles and OTC, provided you introduce them carefully, monitor behavior, and stay aware of how your upstreams treat these attributes.
The more consistently the ecosystem respects OTC, the closer we get to a global routing system that fails safer rather than failing loudly and unpredictably.
If you are planning a broader performance or reliability upgrade for your infrastructure—including BGP policy cleanup, observability improvements, or application-level hardening—and you need support with planning, implementation, or custom tooling, explore our service offerings at
https://izendestudioweb.com/services/.