Scrubbing BGP ORIGIN Attribute

Status of This Memo

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 7 May 2026.¶

Copyright Notice

Copyright (c) 2025 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.¶

Table of Contents

1. 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 ([RFC904]). First seen in the first published BGP draft as the Direction field in the UPDATE message (see Section 3.4 of [RFC1105]), later refined into the Origin attribute (see Section 5 of [RFC1163]) with just three values: IGP, EGP and Incomplete.¶

While the attribute itself has been long established, even in 1995 in [RFC1771], it is not being formally specified to be used for best route selection. Instead, using the origin attribute was suggested in [RFC1772] 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 [bird-bgp-commit]. With that, the tie breaking in its current form, specified in Section 9.1.2.2 of [RFC4271], 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 [rewriting-bgp-origin] 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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Tolerance of missing or malformed BGP Origin attribute

The ORIGIN attribute is considered malformed if its length is not 1 as specified by Section 4.3 of [RFC4271], or its value is not one of these specified by [RFC4271]. 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 Section 7.1 of [RFC7606] by accepting routes with a malformed or absent ORIGIN attribute.¶

4. Update to the BGP Origin attribute values

The values of the BGP Origin attribute are specified in Section 4.3 of [RFC4271], 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 Section 4.3 of [RFC4271] by deprecating ORIGIN attribute values 1 (EGP) and 2 (INCOMPLETE), and Section 5.1.1 of [RFC4271] by effectively making the attribute optional.¶

5. 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 Section 9.1.2.2 of [RFC4271] 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 Section 9.2.2.2 of [RFC4271], with the scrubbed ORIGINs on input, all the ORIGINs on the output are also going to be 0 (IGP).¶

6. 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 [I-D.ietf-grow-as-path-prepending].¶

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.¶

7. 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 Section 3.1 of [RFC8205], being more secure and with higher priority than the ORIGIN attribute.¶

8. IANA Considerations

This document has no IANA actions.¶

9. References

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.¶

Author's Address