Summary

  • BGP Roles let adjacent networks compare provider, customer, peer and route-server expectations before route exchange; a confirmed mismatch can prevent the eBGP session from forming.
  • OTC carries a propagation boundary with the route, but it cannot authenticate the commercial relationship, replace explicit import and export policy, or describe a complex per-prefix arrangement.

Analysis

A route leak is not necessarily a false origin. RFC 7908 defines it as propagation beyond intended scope. A route may identify the correct destination and still move from one provider to another, or from a peer toward a provider, in a direction the surrounding relationships were not meant to permit. The failure sits in the chain of handoffs.

For decades, that chain depended mainly on local configuration. One operator labelled a neighbour as a customer, provider or peer, built route maps around that belief, and hoped the other side described the same relationship. The session itself did not have to compare the two stories. A typo, a missing filter or an automation error could turn a local mistake into someone else’s accepted route.

RFC 9234 inserts a small but consequential exchange before the routes. The BGP OPEN message can carry a Role Capability. The allowed roles are Provider, Customer, Route Server, Route Server Client and Peer. When both sides advertise roles, the pair must make sense: Provider faces Customer, Route Server faces Route Server Client, and Peer faces Peer. An incompatible pair is rejected with a Role Mismatch notification.

That is a protocol consistency check, not a commercial oracle. A router does not read a transit agreement, invoice or traffic commitment. Both operators can configure a matching but false role. They can also have a relationship that changes by prefix, service or geography. RFC 9234 calls such an arrangement complex and says Roles must not be configured on that session. If it can be split into separate normal relationships, separate sessions are preferred; otherwise per-prefix policy remains necessary.

The second mechanism operates after the session is up. Only to Customer, or OTC, is an optional transitive path attribute with type code 35. Its four-octet value carries an autonomous system number. Once a route has crossed toward a customer, peer or route-server client, OTC marks the path so that it should continue only toward customers.

The rules are deliberately directional. A route carrying OTC that arrives from a customer or route-server client is a leak and becomes ineligible. A peer route is also rejected when the OTC value conflicts with the peer’s ASN in the way specified by the RFC. On export, a route already carrying OTC must not be sent to providers, peers or route servers. The attribute can therefore stop a local leak and expose one several hops later.

Partial deployment still has value. When a route arrives from a provider, peer or route server without OTC, a compliant receiver can add it. The RFC describes this as a benefit for early adopters: protection does not require every earlier AS on the path to have implemented the mechanism. But the attribute is not cryptographically protected. An on-path AS can remove or alter it, and a wrong mark can suppress legitimate propagation.

Backward compatibility creates another choice. If one neighbour advertises a Role and the other does not, the default behaviour is to continue using the locally configured role. An operator may require strict mode and reject an unlabelled neighbour. RFC 9234 warns against making strict mode the default because a software update could leave a session unable to establish. The safety gain is real; so is the reachability cost.

RFC 8212 remains the foundation. Routes should not be imported or exported on eBGP without explicit policy. BGP Roles and OTC do not make a permissive policy safe, validate the origin, or replace prefix and path controls. They add shared relationship evidence to a system that still depends on local authorization.

The IANA registry confirms the wire assignments: OTC is Path Attribute 35 and Role Mismatch is OPEN Message Error subcode 11. It does not show who has deployed them. This article therefore makes no claim about a named network, vendor release or prevented incident.

Sources