]> CZ.NIC

Milesovska 1136/5 Praha 13000 Czechia maria.matejka@nic.cz mq@jmq.cz

Routing Inter-Domain Routing EGP attribute manipulation The BGP Origin attribute in its original meaning has been out of use for years. Yet, the BGP Origin attribute has high priority in the best route selection algorithm, right after the AS Path length, and it's being used inconsistently over the Internet to manipulate the route preference. This document updates RFC 4271 and RFC 7606 by making the BGP Origin attribute half-optional and explicitly allowing its scrubbing to zero (IGP). About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Inter-Domain Routing Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Origins of the BGP Origin attribute stem from times when BGP was not the only full internet routing protocol, and was slowly replacing EGP (). First seen in the first published BGP draft as the Direction field in the UPDATE message (see ), later refined into the Origin attribute (see ) with just three values: IGP, EGP and Incomplete. While the attribute itself has been long established, even in 1995 in , it is not being formally specified to be used for best route selection. Instead, using the origin attribute was suggested in to be used as an indicator of better route, together with AS Path Length and more criteria. It's hard to dig through the archives to find out what happened when and why, but it's safe to assume that most of the BGP implementations of that time simply used a very similar tie breaking algorithm without formal specification, as documented e.g. in . With that, the tie breaking in its current form, specified in , was most probably simply copied from the existing stuff out there. In the year 2006, there might still have been some remnants of EGP infrastructure, and deprecating the BGP Origin attribute altogether wasn't probably a good idea then. In September 2025, a short look into the global IPv4 routing table shows that about 9% of the DFZ routing table bears BGP Origin value INCOMPLETE and under 1% there are still some routes with BGP Origin value EGP. With these routes, several transit providers rewrite the BGP Origin value to IGP to raise their priority in the best route selection. Rather curiously, there are even several IPv6 routes with BGP Origin value EGP. Therefore, this document makes the first needed steps to deprecate the BGP Origin attribute in the future by updating the rules for its origination, relaxing its handling and deprecating all other its values than zero.

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here.

Tolerance of missing or malformed BGP Origin attribute The ORIGIN attribute is considered malformed if its length is not 1 as specified by , or its value is not one of these specified by . It is considered absent if it's not included in the UPDATE message at all. Unless explicitly configured by a network operator to do otherwise, if the ORIGIN attribute is malformed or absent, BGP speakers SHOULD accept such UPDATE message. In such case, before the path attributes are processed any further:

• If the ORIGIN attribute is absent, the BGP speaker MUST add a new ORIGIN attribute with the value of 0 (IGP).
• If the ORIGIN attribute length is not 1, the BGP speaker MUST replace that attribute with a new ORIGIN attribute with the value of 0 (IGP).
• If the ORIGIN attribute value is not 0 (IGP), the BGP speaker SHOULD rewrite that value to 0 (IGP).

The BGP speaker SHOULD allow logging the original ORIGIN attribute value. Per the above specification, this document updates by accepting routes with a malformed or absent ORIGIN attribute.

Update to the BGP Origin attribute values The values of the BGP Origin attribute are specified in , the Path attribute part, a) ORIGIN (Type Code 1). Unless explicitly configured by a network operator to do otherwise, BGP speakers MUST NOT advertise BGP UPDATE messages with the ORIGIN attribute containing any other value than 0 (IGP), including manually configured static routes. Additionally, BGP speakers SHOULD rewrite any ORIGIN attribute value to 0 (IGP) if it contains any other value, even a valid one, before processing the path attributes any further. If explicitly configured by a network operator to do so, BGP speakers MAY also advertise BGP UPDATE messages without including the ORIGIN attribute at all. Per the above specification, this document updates by deprecating ORIGIN attribute values 1 (EGP) and 2 (INCOMPLETE), and by effectively making the attribute optional.

Additional Notes The ORIGIN scrubbing is designed to happen on the receiving side, so that the best route selection algorithm is entered with it being always zero, effectively rendering the step b) of void. Yet, if somebody wants to per-use the attribute locally for any custom purpose, the algorithms are still there. For the purposes of route aggregation as of , with the scrubbed ORIGINs on input, all the ORIGINs on the output are also going to be 0 (IGP).

Operational Considerations All the results achievable by manipulating this attribute may be instead achieved by other techniques, most notably by AS Path Stuffing, LOCAL_PREF, and MED . The implementations may offer a configuration option to not send the ORIGIN attribute at all. The network operator must be sure, though, that the other side actually employs the algorithms specified in this document, otherwise all their routes would be treated as withdraw.

Security Considerations Originating a route with a non-zero value of the ORIGIN attribute makes the route prone to unwanted prioritization by the intermediate AS's. Scrubbing the attribute removes this possible traffic redirection problem. Most notably, stuffing the AS Path by own AS Number is directly supported by the Secure Path attribute as of , being more secure and with higher priority than the ORIGIN attribute.

IANA Considerations This document has no IANA actions.

References Normative References This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol. The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced. BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths. This document obsoletes RFC 1771. [STANDARDS-TRACK] According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable because a session reset would impact not only routes with the offending attribute but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for a number of existing attributes. This document updates error handling for RFCs 1997, 4271, 4360, 4456, 4760, 5543, 5701, and 6368. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References RFC-904 is the specification of the Exterior Gateway Protocol (EGP). This memo updates portions of RFC-888 and RFC-827. This RFC specifies an official protocol of the DARPA community for use between gateways of different autonomous systems in the ARPA-Internet. This RFC outlines a specific approach for the exchange of network reachability information between Autonomous Systems. Updated by RFCs 1163 and 1164. [STANDARDS-TRACK] This RFC, together with its companion RFC-1164, "Application of the Border Gateway Protocol in the Internet", specify an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] This document, together with its companion document, "Application of the Border Gateway Protocol in the Internet", define an inter-autonomous system routing protocol for the Internet. [STANDARDS-TRACK] This document, together with its companion document, "A Border Gateway Protocol 4 (BGP-4)", define an inter-autonomous system routing protocol for the Internet. This document describes the usage of the BGP in the Internet. [STANDARDS-TRACK] This document describes BGPsec, an extension to the Border Gateway Protocol (BGP) that provides security for the path of Autonomous Systems (ASes) through which a BGP UPDATE message passes. BGPsec is implemented via an optional non-transitive BGP path attribute that carries digital signatures produced by each AS that propagates the UPDATE message. The digital signatures provide confidence that every AS on the path of ASes listed in the UPDATE message has explicitly authorized the advertisement of the route. Inter.link Futurewei Kentik Nvidia NTT Network Innovations HPE Cisco Verizon Inc. Autonomous System (AS) path prepending is a tool to manipulate the BGP AS_PATH attribute through prepending one or more Autonomous System Numbers (ASNs). AS path prepending is used to deprioritize a route in the presence of a route with a shorter AS_PATH. By prepending a local ASN multiple times, ASes can make advertised AS paths appear artificially longer. However, excessive AS path prepending has caused routing issues in the Internet. This document provides guidance for the use of AS path prepending, including alternative solutions, in order to avoid negatively affecting the Internet.

Acknowledgments The authors wish to thank James Bensley, Gert Doering, Wolfgang Tremmel, Ondřej Zajíček, and Alexander Zubkov for valuable comments, suggestions and discussions on the topic and text of the document.