RFC 4893

BGP Support for Four-octet AS Number Space

📅 published May 2007, from ietf

Network Working Group RFC 4893 🦋

Okay bestie, let's get into RFC 4893 ✨ Quick title-block tea first: it's from the Network Working Group, the title is BGP Support for Four-octet AS Number Space, and it was written by Q. Vohra of Juniper Networks and E. Chen of Cisco Systems. It's a Standards Track doc, dated May 2007. The header has no Obsoletes or Updates line, so it isn't replacing or changing any other RFC 💅

Status of This Memo 📜

So this doc is an Internet standards track protocol spec for the whole Internet community 🌐 It's literally asking for your discussion and suggestions to make it better 🫶 If you want to know where this protocol sits in the standardization ladder, check the current edition of "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited, so share away 💖

Copyright (C) The IETF Trust (2007).

Abstract 🌸

Right now the Autonomous System (AS) number is a two-octet thing in BGP. This doc describes BGP extensions so the AS number can be carried as a four-octet thing instead ✨

1. Introduction 🧚

Okay so right now the Autonomous System number is a two-octet entity in BGP [BGP]. Two-octet AS numbers are expected to run out, so this document adds extensions to BGP that let the AS number ride along as a four-octet entity 😭

More specifically, this doc defines a brand-new BGP capability called Four-octet AS Number Capability. A BGP speaker can use it to say it supports four-octet AS numbers 🙌 Two new attributes, AS4_PATH and AS4_AGGREGATOR, are introduced too. They let four-octet AS path info get passed across BGP speakers that don't support four-octet AS numbers. The doc also explains how to build the AS path info from the AS_PATH attribute and the AS4_PATH attribute together 🧠

These extensions allow a gradual transition from 2-octet AS numbers to 4-octet AS numbers ⭐

2. Specification of Requirements 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Those are the exact words that carry the rules, so read them carefully 🔥

3. Protocol Extensions 🎀

Quick naming check: a BGP speaker that doesn't do the new 4-octet AS number extensions is an OLD BGP speaker. A BGP speaker that does support them is a NEW BGP speaker 🫶

The AS number shows up in a few places. It's in the "My Autonomous System" field of the OPEN message, in the AS_PATH attribute of the UPDATE message, and in the AGGREGATOR attribute of the UPDATE message. It also rides along in the BGP Communities attribute 💅

A NEW BGP speaker uses BGP Capability Advertisements [RFC2842] to tell its neighbors, whether internal or external, that it supports the 4-octet AS number extensions in this doc 🦋

That capability, which a speaker uses to tell its peer it can handle 4-octet AS numbers, also carries the speaker's own 4-octet AS number in the Capability Value field of the Capability Optional Parameter. The Capability Length field of the Capability gets set to 4 🔥

NEW BGP speakers carry AS path information with 4-octet Autonomous System numbers by using the existing AS_PATH attribute. The only difference is that each AS number in it is encoded as a 4-octet entity instead of a 2-octet one. The AGGREGATOR attribute works the same way. NEW BGP speakers use that same attribute, but the AS in it is encoded as a 4-octet entity 🌈

To keep AS path info with 4-octet AS numbers intact across OLD BGP speakers, this doc defines a new AS path attribute called AS4_PATH. It's an optional transitive attribute that holds the AS path encoded with 4-octet AS numbers. It has the same semantics as the AS_PATH attribute, except that it's optional transitive and carries 4-octet AS numbers 🧚

To stop confederation path segments from leaking outside a confederation, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH attribute. Nope, not allowed 🙅‍♀️

Similarly, this doc defines a new aggregator attribute called AS4_AGGREGATOR, which is optional transitive. It has the same semantics as the AGGREGATOR attribute, except that it carries a 4-octet AS number 💖

Currently assigned 2-octet Autonomous System numbers get converted into 4-octet ones by setting the two high-order octets of the 4-octet field to zero. A 4-octet AS number made that way is said to be mappable to a 2-octet AS number 🍓

To represent 4-octet AS numbers that aren't mapped from 2-octets as 2-octet AS numbers in AS path info encoded with 2-octet AS numbers, this doc reserves a 2-octet AS number. It's called AS_TRANS for ease of description through the rest of the spec 🦋 This AS number also goes in the "My Autonomous System" field of the OPEN message sent by a NEW BGP speaker, if that speaker doesn't have a (globally unique) 2-octet AS number 👑

4. Operations ⚙️

4.1. Interaction Between NEW BGP Speakers 🫶

A BGP speaker that supports 4-octet Autonomous System numbers SHOULD advertise this to its peers using the BGP Capability Advertisements. A BGP speaker that advertises this capability to a particular peer, and receives that peer's advertisement of the same capability, MUST encode Autonomous System numbers as 4-octet entities in both the AS_PATH and the AGGREGATOR attributes in the updates it sends to that peer. It MUST also assume that these attributes in updates received from that peer encode Autonomous System numbers as 4-octet entities 💅

The new attributes, AS4_PATH and AS4_AGGREGATOR, SHOULD NOT be carried in the UPDATE messages between NEW BGP peers 🙈 A NEW BGP speaker that receives the AS4_PATH and AS4_AGGREGATOR path attributes in an UPDATE message from a NEW BGP speaker SHOULD discard these path attributes and keep processing the UPDATE message 🧹

4.2. Interaction Between NEW and OLD BGP Speakers 🌸

4.2.1. BGP Peering 🦋

Peering between a NEW BGP speaker and an OLD one is only possible if the NEW BGP speaker has a 2-octet AS number. This doc doesn't assume that an Autonomous System with NEW speakers has to have a globally unique 2-octet AS number, though. AS_TRANS could be used instead, even if multiple Autonomous Systems would be using it 🌈

4.2.2. Generating Updates ✨

When talking to an OLD BGP speaker, a NEW speaker MUST send the AS path info in the AS_PATH attribute encoded with 2-octet AS numbers. The NEW speaker MUST also send the AS path info in the AS4_PATH attribute, encoded with 4-octet AS numbers. The one exception is when the entire AS path info is made up of 2-octet AS numbers only. In that case, the NEW speaker SHOULD NOT send the AS4_PATH attribute 🙌

In the AS_PATH attribute encoded with 2-octet AS numbers, non-mappable 4-octet AS numbers are shown as the well-known 2-octet AS number AS_TRANS. This keeps the path length property of the AS path info intact, and it also helps when updating the AS path info a NEW BGP speaker gets from an OLD speaker, as explained in the next section 🧠

The NEW speaker builds the AS4_PATH attribute from the info in the AS_PATH attribute. If the AS_PATH attribute contains AS_CONFED_SEQUENCE or AS_CONFED_SET path segments, the NEW speaker MUST exclude those segments when it builds the AS4_PATH attribute from the AS_PATH attribute. The AS4_PATH attribute gets carried across a series of OLD BGP speakers without any changes, and it helps preserve the truly 4-octet AS numbers in the AS path info 💖

The same idea applies to the AGGREGATOR attribute. If the NEW speaker has to send it, and the aggregating Autonomous System's AS number is truly 4-octets, the speaker builds the AS4_AGGREGATOR attribute. It copies the attribute length and attribute value from the AGGREGATOR attribute into the attribute length and attribute value of the AS4_AGGREGATOR attribute. Then it sets the AS number field in the existing AGGREGATOR attribute to the reserved AS number, AS_TRANS 🎀 Note that if the AS number is 2-octets only, the AS4_AGGREGATOR attribute SHOULD NOT be sent 🙈

4.2.3. Processing Received Updates ✨

okay so when a NEW BGP speaker gets an update from an OLD one, it should be ready to receive the AS4_PATH attribute along with the regular AS_PATH attribute 💅. If the AS4_PATH attribute shows up too, the two get used together to rebuild the exact AS path info, and the info in both of them counts for AS path loop detection 🔁.

Here's the tea 🫖: a route might have gone through a bunch of autonomous systems that only used 2-octet AS numbers and only OLD BGP speakers. In that case, if the route has the AS4_PATH attribute, that attribute must have stayed untouched since the route left the last NEW BGP speaker 🙈. The trailing AS path info (the autonomous systems that were 2-octet and OLD-only) lives only in the current AS_PATH attribute, in the leading part of it.

Sometimes it's just not possible to fully rebuild the AS path from AS_PATH and AS4_PATH 😭. This happens when two or more routes carrying the AS4_PATH attribute get aggregated by an OLD BGP speaker, and at least one of those routes has a 4-octet AS number in its AS4_PATH (as oppose to a 2-octet AS number that's just written out in 4 octets). Depending on the implementation, either the AS4_PATH attribute gets lost during aggregation, or both the AS_PATH and AS4_PATH attributes end up with valid partial info that can't be stitched together cleanly, so the AS path info comes out incomplete. Messy, but that's the reality 💀.

A NEW BGP speaker should also be ready to receive the AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an OLD BGP speaker. When both show up, here's how it goes:

  • If the AS number in the AGGREGATOR attribute is not AS_TRANS, then:
    • the AS4_AGGREGATOR attribute and the AS4_PATH attribute SHALL be ignored,
    • the AGGREGATOR attribute SHALL be taken as the information about the aggregating node, and
    • the AS_PATH attribute SHALL be taken as the AS path information.
  • Otherwise,
    • the AGGREGATOR attribute SHALL be ignored,
    • the AS4_AGGREGATOR attribute SHALL be taken as the information about the aggregating node, and
    • the AS path information would need to be constructed, as in all other cases.

To build the AS path info, you first have to count the AS numbers in the AS_PATH and AS4_PATH attributes 🔢. Use the method from Section 9.1.2.2 [BGP] and [RFC3065] for route selection, because that's the official way 🤓.

If the AS_PATH attribute has fewer AS numbers than the AS4_PATH attribute, the AS4_PATH attribute SHALL be ignored, and the AS_PATH attribute SHALL be taken as the AS path information 🙃.

If the AS_PATH attribute has more AS numbers than, or the same number as, the AS4_PATH attribute, then the AS path information SHALL be constructed by grabbing as many AS numbers and path segments as needed from the leading part of the AS_PATH attribute, and prepending them to the AS4_PATH attribute. The goal is that the AS path info ends up with the same number of AS numbers as the AS_PATH attribute ✨. One more detail: a valid AS_CONFED_SEQUENCE or AS_CONFED_SET path segment SHALL be prepended if it's either the leading path segment or sitting right next to a segment that's getting prepended 🧩.

5. Handling BGP Communities 🎀

okay so [RFC1997] says that when the high-order two octets of the community attribute are neither 0x0000 nor 0xffff, those two octets encode the Autonomous System number 🔢. Obviously that won't work for BGP speakers using 4-octet AS numbers 😬. Those speakers should use the Four-octet AS Specific Extended Communities [AS-EXT-COM] instead 💜.

6. Transition 🦋

this whole scheme gives you a gradual glow-up from 2-octet AS numbers to 4-octet AS numbers 🌈. You can upgrade one Autonomous System or one BGP speaker at a time, no drama 🫶.

To keep things simple, this document assumes an Autonomous System only starts using a 4-octet AS number after every single BGP speaker inside it has been upgraded to support 4-octet AS numbers 🧚.

An OLD BGP speaker MUST NOT use AS_TRANS as its Autonomous System number 🚫. Not even a little bit 🙅.

A non-mappable 4-octet AS number can't be used as a "Member AS Number" of a BGP Confederation until every BGP speaker in that Confederation has transitioned to support 4-octet AS numbers 🏰.

Here's a sneaky one 👀: in an environment where an Autonomous System with OLD BGP speakers peers with two or more Autonomous Systems that have NEW BGP speakers and use AS_TRANS (instead of having a globally unique AS number), the Autonomous System with the OLD speakers might use Multi-Exit Discriminators in a way where the MED ends up influencing route selection among routes received from different neighboring Autonomous Systems. Plot twist 🎭.

Again, it may not be possible to fully rebuild the AS path info from the AS_PATH and AS4_PATH attributes of a route. This happens when two or more routes carrying the AS4_PATH attribute are aggregated by an OLD BGP speaker, and at least one of those routes has a 4-octet AS number in its AS4_PATH (as oppose to a 2-octet AS number that's just encoded in 4 octets). When that aggregation creates a route that's less specific than any of the component routes (a route whose Network Layer Reachability Information (NLRI) covers the NLRI of all the component routes), losing the AS path info doesn't create a risk of a routing loop 🙌. In all other cases, though, losing the AS path info does create a risk of a routing loop 🌀 so yeah, pay attention 🚨.

7. IANA Considerations 📋

this document expands the pool of AS numbers from 0 - 65535 to 0 - 4294967295 🎉. The AS numbers are still managed by the IANA "Autonomous System Numbers" registry. Apart from expanding the pool, this document doesn't change any existing policies or procedures for AS number allocation 💅.

This document uses a BGP Capability code to show that a BGP speaker supports 4-octet AS numbers. Capability Code 65 was assigned by IANA per RFC 2842 🏷️.

It also introduces two brand-new BGP optional transitive attributes, and IANA assigned their type codes. The first is the AS4_PATH attribute, value 17, which keeps the AS path info with 4-octet AS numbers intact across old BGP speakers 🧳. The second is the AS4_AGGREGATOR attribute, value 18, which is used a lot like the current AGGREGATOR attribute, except it carries a 4-octet AS number 🔥.

Last but not least, this document introduces a reserved 2-octet AS number called AS_TRANS. IANA assigned the AS number 23456 to AS_TRANS 👑.

8. Security Considerations 🚨

okay, serious moment 🫡. This extension to BGP does not change the underlying security issues already in existing BGP, except for the following:

The inconsistency between the AS_PATH attribute and the AS4_PATH attribute can cause loss of AS path information, and potential routing loops in certain cases, as discussed in the document. This could be exploited by an attacker. ☠️ Do not ignore this one.

9. Acknowledgments 🫶

the authors want to thank Yakov Rekhter, Chaitanya Kodeboyina, and Jeffrey Haas for the many discussions that went into making this document 💖.

10. Normative References 📚

  • [BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
  • [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, August 1996.
  • [RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
  • [RFC3065] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

11. Informative References 🔍

  • [AS-EXT-COM] Rekhter, Y., Ramachandra, S., and D. Tappan, "Four-octet AS Specific BGP Extended Community", Work in Progress, April 2007.

Authors' Addresses 🖊️

Quaizar Vohra
Juniper Networks
1194 N.Mathilda Ave
Sunnyvale, CA 94089

EMail: quaizar.vohra@gmail.com


Enke Chen
Cisco Systems, Inc.
170 W. Tasman Dr.
San Jose, CA 95134

EMail: enkechen@cisco.com

Copyright (C) The IETF Trust (2007) 🌸.

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property ⚖️

The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or on whether any license under such rights might or might not be available. It also doesn't claim to have made any independent effort to identify such rights. Info on how rights in RFC documents are handled can be found in BCP 78 and BCP 79 📖.

Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users of this specification to use such proprietary rights, can be obtained from the IETF's online IPR repository at http://www.ietf.org/ipr 🔗.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 📬.

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society 🌷.

📦 where this page comes from