| Internet-Draft | Strict OTC Verification on RS Sessions | September 2026 |
| Herdes, et al. | Expires 21 March 2027 | [Page] |
RFC 9234 specifies how an AS receiving a route from a lateral Peer can check if a route was leaked, but doesn't specify any checks for routes received from a Route Server (RS). This makes the quality of filtering dependent on whether the RS implements RFC 9234.¶
This document updates RFC 9234 by adding a complementary ingress check by an RS-Client.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC9234] specifies OTC attribute and Peering Roles: Customer, Provider, Peer, RS, and RS-Client. Section 5 of [RFC9234] specifies ingress filtering based on the OTC value for routes received from a Peer. It says:¶
If a route with the OTC Attribute is received from a Peer (i.e., remote AS with a Peer Role) and the Attribute has a value that is not equal to the remote (i.e., Peer's) AS number, then it is a route leak and MUST be considered ineligible.¶— RFC 9234
For the routes received from an RS, [RFC9234] doesn't specify any checks, though an RS basically provides service for indirect peering, thus the same procedure to a Peer should be applied.¶
Section 3 extends the OTC check on RS-Clients to verify that if OTC is present, its value matches the RS's AS number.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Terminology follows [RFC9234]: the BGP Roles Provider, Customer, RS, RS-Client, and Peer are as defined in its Sections 3.1 and 4, and "local AS" and "remote AS" are the two ends of an eBGP session. "Route is ineligible" is as in [RFC4271]. A transparent RS does not insert its own AS number into the AS_PATH of routes it redistributes [RFC7947]; most production route servers are transparent. Example AS numbers are from the documentation range [RFC5398].¶
An RS exists to redistribute routes between RS-Clients that peer laterally through it. [RFC9234] states that if a route received by an RS has the OTC attribute, it is a route leak. But if the RS is non-compliant, it will accept the route without checking the OTC value and redistribute it to its RS-Clients.¶
If the RS is implementing [RFC9234], it will reject received routes if OTC is present and will add the OTC attribute with the value equal to its own AS (the RS's AS number) when advertising routes to its RS-Clients.¶
From the point of the RS-Client, a correct route received from an RS must carry either no OTC Attribute or one equal to the RS's AS number. Otherwise, it's a route leak.¶
That is true of transparent and non-transparent route servers alike, since transparency affects only whether the RS appears in the AS_PATH.¶
This section updates Section 5 of [RFC9234] by adding a new rule for RS-Client.¶
If a route with the OTC Attribute is received from an RS (i.e., remote AS with an RS Role) and the Attribute has a value that is not equal to the remote (i.e., RS's) AS number, then it is a route leak and MUST be considered ineligible.¶
The above update in OTC processing is fully backwards compatible with [RFC9234]. It doesn't require a new version or BGP capability negotiations between implementations.¶
There are IXPs that may provide additional L3 connectivity services. For example, they may provide connectivity for remote IXP using a dedicated L3 gateway. If other IXP members send prefixes through this L3 gateway, it becomes their Provider in terms of peering relationships. To solve this ambiguity, the document suggests the following routing policy:¶
This document has no IANA actions.¶