RFC 6793

BGP Support for Four-Octet Autonomous System (AS) Number Space

📅 published December 2012, from ietf

RFC 6793: BGP Support for Four-Octet Autonomous System (AS) Number Space 🎀 (part 1 of 3)

Okay bestie, this one is from the IETF (Internet Engineering Task Force) 🌈 and it's a Standards Track doc, dated December 2012. The authors are Q. Vohra (Juniper Networks) and E. Chen (Cisco Systems), and the ISSN is 2070-1721. It obsoletes RFC 4893 and updates RFC 4271, so it replaces one doc and tweaks another. 💅

Abstract 🦋

The Autonomous System number is encoded as a two-octet entity in the base BGP spec. This doc describes extensions to BGP so the Autonomous System numbers can be carried as four-octet entities instead. It obsoletes RFC 4893 and updates RFC 4271. ✨

Status of This Memo 📜

This is an Internet Standards Track document. 💖

It's a product of the IETF and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741. 🫶

For the current status, any errata, and how to send feedback, check http://www.rfc-editor.org/info/rfc6793. 🧚

Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) as they stood on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Any Code Components pulled out of this document have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License. 📝

1. Introduction ✨

Okay so in the base BGP spec [RFC4271], the Autonomous System (AS) number is only two octets. The two-octet AS numbers are expected to run out eventually, so this doc extends BGP to carry AS numbers as four-octet entities to get ready for that. 🌈

More specifically, it defines a BGP capability code called "support for four-octet AS number capability". A BGP speaker uses it to say it supports four-octet AS numbers. 💅 It also introduces two attributes, AS4_PATH and AS4_AGGREGATOR. These let four-octet AS path info get passed along between BGP speakers that don't support four-octet AS numbers. The doc also explains how to rebuild the AS path info from the AS_PATH attribute together with the AS4_PATH attribute. 🧠

The extensions here allow a gradual switch from two-octet AS numbers to four-octet AS numbers. No big bang, just a slow glow-up. 🦋

This doc obsoletes RFC 4893 and updates RFC 4271. It has a bunch of clarifications and editorial tweaks, and it also spells out the error handling for the new attributes. 🎀

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]. 🔥

3. Protocol Extensions 🌸

For this doc, a BGP speaker that does not support the new four-octet AS number extensions is an OLD BGP speaker, and a BGP speaker that does support them is a NEW BGP speaker. 💜

BGP carries AS numbers 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. BGP also carries AS numbers in the BGP Communities attribute. 🍓

A NEW BGP speaker uses BGP Capabilities Advertisements [RFC5492] to tell its neighbors (internal or external) that it supports the four-octet AS number extensions in this doc. 📣

The capability a BGP speaker uses to tell its BGP peer about the four-octet Autonomous System number capability also carries the speaker's AS number, encoded as a four-octet entity, in the Capability Value field. The Capability Length field of that capability is set to 4. 🧮

The AS path info exchanged between NEW BGP speakers rides in the existing AS_PATH attribute. The only difference is that every AS number in it is a four-octet entity instead of a two-octet one. The AGGREGATOR attribute works the same way between NEW BGP speakers, except the AS number inside it is four-octet too. 💖

The AS_PATH attribute and the AGGREGATOR attribute that go between a NEW BGP speaker and an OLD BGP speaker keep using two-octet AS numbers. Old school, but it works. 🕰️

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

To stop Confederation-related path segments from leaking outside of a Confederation, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC5065] are declared invalid for the AS4_PATH attribute. They MUST NOT be included in the AS4_PATH attribute of an UPDATE message. 🚫

Confed segments are a hard no in AS4_PATH. An UPDATE message MUST NOT include them there. 🙅‍♀️

Same energy for AS4_AGGREGATOR: it's another new optional transitive attribute. It has the same semantics and encoding as the AGGREGATOR attribute, except it carries a four-octet AS number. 🦋

Two-octet AS numbers that are currently assigned get turned into four-octet AS numbers by setting the two high-order octets of the four-octet field to zero. A four-octet AS number like that is said to be mappable to a two-octet AS number. 🧚

This doc reserves a two-octet AS number called AS_TRANS. AS_TRANS can stand in for non-mappable four-octet AS numbers as two-octet AS numbers, in AS path info that's encoded with two-octet AS numbers. (In this context, four-octet AS numbers that didn't come from mapping a two-octet AS number are called "non-mappable".) We call this special AS number AS_TRANS for the rest of the spec. 🎀

AS_TRANS also goes in the "My Autonomous System" field of the OPEN message from a NEW BGP speaker, but only if and only if that speaker does not have a (globally unique) two-octet AS number. 🌈

4. Operations 🔥

4.1. Interaction between NEW BGP Speakers 🫶

A BGP speaker that supports four-octet AS numbers SHALL advertise this to its peers using BGP Capabilities Advertisements. 📣 The AS number of the BGP speaker MUST be carried in the Capability Value field of the "support for four-octet AS number capability". 💅

When a NEW BGP speaker processes an OPEN message from another NEW BGP speaker, it MUST use the AS number encoded in the Capability Value field of the "support for four-octet AS number capability" instead of the "My Autonomous System" field of the OPEN message. 🙌

A BGP speaker that advertises that capability to a particular peer, and also gets that same advertisement back from that peer, MUST encode AS numbers as four-octet entities in both the AS_PATH attribute and the AGGREGATOR attribute in the updates it sends to that peer. It MUST also assume that these attributes in updates received from that peer encode AS numbers as four-octet entities. 🧠

The new attributes, AS4_PATH and AS4_AGGREGATOR, MUST NOT be carried in an UPDATE message between NEW BGP speakers. If a NEW BGP speaker gets the AS4_PATH attribute or the AS4_AGGREGATOR attribute in an UPDATE message from another NEW BGP speaker, it MUST discard that path attribute 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 BGP speaker is only possible if the NEW BGP speaker has a two-octet AS number. 🧩 That said, this doc doesn't assume that an Autonomous System with NEW BGP speakers has to have a globally unique two-octet AS number. AS_TRANS MUST be used when the NEW BGP speaker doesn't have a two-octet AS number, even if multiple Autonomous Systems end up using it. 🎀

4.2.2. Generating Updates 💖

When talking to an OLD BGP speaker, a NEW BGP speaker MUST send the AS path info in the AS_PATH attribute encoded with two-octet AS numbers. It MUST also send the AS path info in the AS4_PATH attribute (encoded with four-octet AS numbers), except when all of the AS path info is made up of mappable four-octet AS numbers only. In that case, the NEW BGP speaker MUST NOT send the AS4_PATH attribute. 🫶

In the AS_PATH attribute encoded with two-octet AS numbers, non-mappable four-octet AS numbers are represented by the well-known two-octet AS number, AS_TRANS. This keeps the path length property of the AS path info intact, and it also helps when a NEW BGP speaker updates the AS path info it got from an OLD BGP speaker, as explained in the next section. 🧚

The NEW BGP speaker builds the AS4_PATH attribute from the AS path info. Whenever the AS path info contains an AS_CONFED_SEQUENCE or AS_CONFED_SET path segment, the NEW BGP speaker MUST exclude those segments from the AS4_PATH attribute it's building. 🙅‍♀️

Because AS4_PATH is optional transitive, it gets carried across a series of OLD BGP speakers without any changes, and that's how it helps preserve the non-mappable four-octet AS numbers in the AS path info. 🌈

Same deal with AGGREGATOR. If a NEW BGP speaker has to send the AGGREGATOR attribute, and the aggregating Autonomous System's AS number is a non-mappable four-octet AS number, then the speaker MUST use the AS4_AGGREGATOR attribute and set the AS number field in the existing AGGREGATOR attribute to the reserved AS number, AS_TRANS. Also, if the AS number is mappable, the AS4_AGGREGATOR attribute MUST NOT be sent. 🦋💅

4.2.3. Processing Received Updates ✨

Okay so when a NEW BGP speaker gets an update from an OLD BGP speaker, it MUST be prepared to receive the AS4_PATH attribute alongside the regular AS_PATH attribute 🎀. If AS4_PATH shows up too, both attributes get used together to build the exact AS path info, which means the info in both of them gets checked for AS path loop detection 🔥.

Now, this part is lowkey important 👀. A route might have hopped through a bunch of Autonomous Systems that only use two-octet AS numbers and OLD BGP speakers. In that case, if the route carries AS4_PATH, that attribute would have stayed unmodified since the route left the last NEW BGP speaker. The trailing AS path info (the bit representing two-octet AS numbers and OLD BGP speakers only) lives only in the current AS_PATH attribute, in its leading part 💅.

Under certain conditions, it may not be possible to rebuild all of the AS path info from the AS_PATH and AS4_PATH attributes of a route 😭. For example, this happens when two or more routes carrying AS4_PATH get aggregated by an OLD BGP speaker, and the AS4_PATH of at least one of those routes has at least one four-octet AS number (not a two-octet AS number that's just encoded in 4 octets, okay, different thing!). Depending on the implementation, either AS4_PATH gets lost during route aggregation, or both AS_PATH and AS4_PATH hold valid partial info that can't be stitched together seamlessly, which leaves the AS path info incomplete in these cases. Messy, but that's the vibe 🫠.

A NEW BGP speaker MUST also be prepared to receive the AS4_AGGREGATOR attribute along with the AGGREGATOR attribute from an OLD BGP speaker 🦋. When both show up, 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 construct the AS path info, you first have to count the AS numbers in AS_PATH and AS4_PATH using the method in Section 9.1.2.2 of [RFC4271] and in [RFC5065] for route selection 🧮. Counting first, slaying later ✨.

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

If AS_PATH has more AS numbers than AS4_PATH, or the exact same amount, then the AS path info SHALL be built by grabbing as many AS numbers and path segments as needed from the leading part of AS_PATH, then prepending them onto AS4_PATH, so the AS path info ends up with the same number of AS numbers as AS_PATH 🌈. Also, 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 path segment that's getting prepended. Very precise, very iconic 💖.

5. Handling BGP Communities 🎀

As [RFC1997] spells out, when the high-order two octets of the community attribute are neither 0x0000 nor 0xffff, those two octets encode the AS number. Quite clearly, this would not work for a NEW BGP speaker with a non-mappable four-octet AS number 🙃. Such BGP speakers should use four-octet AS specific extended communities [RFC5668] instead 🌸.

6. Error Handling 🚨

This section gives an update to RFC 4271 [RFC4271] about the error conditions noted here and how to handle them 📝.

Since two-octet AS numbers dominate during the transition and get carried in AS_PATH by an OLD BGP speaker, this document goes with the "attribute discard" approach for handling a malformed AS4_PATH attribute 🗑️✨.

Similarly, because AS4_AGGREGATOR is just informational, the "attribute discard" approach is also picked for a malformed AS4_AGGREGATOR attribute 💅.

The AS4_PATH and AS4_AGGREGATOR attributes MUST NOT be carried in an UPDATE message between NEW BGP speakers 🚫. A NEW BGP speaker that receives AS4_PATH or AS4_AGGREGATOR in an UPDATE message from another NEW BGP speaker MUST discard that path attribute and keep processing the UPDATE message. This case SHOULD be logged locally for analysis 📓.

Also, the path segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH attribute of an UPDATE message 🙅. A NEW BGP speaker that receives these path segment types in the AS4_PATH attribute of an UPDATE message from an OLD BGP speaker MUST discard those path segments, adjust the relevant attribute fields accordingly, and keep processing the UPDATE message. This case SHOULD be logged locally for analysis 🔍.

The AS4_PATH attribute in an UPDATE message SHALL be considered malformed under the following conditions 💀:

  • the attribute length is not a multiple of two or is too small (i.e., less than 6) for the attribute to carry at least one AS number, or
  • the path segment length in the attribute is either zero or is inconsistent with the attribute length, or
  • the path segment type in the attribute is not one of the types defined: AS_SEQUENCE, AS_SET, AS_CONFED_SEQUENCE, and AS_CONFED_SET.

A NEW BGP speaker that receives a malformed AS4_PATH attribute in an UPDATE message from an OLD BGP speaker MUST discard the attribute and keep processing the UPDATE message. The error SHOULD be logged locally for analysis 📝💜.

The AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered malformed if the attribute length is not 8 🔢.

A NEW BGP speaker that receives a malformed AS4_AGGREGATOR attribute in an UPDATE message from an OLD BGP speaker MUST discard the attribute and keep processing the UPDATE message. The error SHOULD be logged locally for analysis 🧾.

7. Transition 🦋

When an Autonomous System is using a two-octet AS number, the BGP speakers inside that Autonomous System MAY be upgraded to support the four-octet AS number extensions on a piecemeal basis 🧩. There is no requirement for a coordinated upgrade of the four-octet AS number capability in this case. However, if an Autonomous System wants to use a four-octet AS number as its own AS number, this document assumes that it can only do that after all the BGP speakers inside that Autonomous System have been upgraded to support four-octet AS numbers 👑.

A non-mappable four-octet AS number cannot be used as a "Member AS Number" of a BGP Confederation until all the BGP speakers within the Confederation have transitioned to support four-octet AS numbers 🚧.

Here's a spicy 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 mappable AS number), the Autonomous System with the OLD BGP speakers using the MULTI_EXIT_DISC attribute [RFC4271] may end up with MULTI_EXIT_DISC influencing route selection among the routes received from different neighboring Autonomous Systems 😬.

Under certain conditions, it may not be possible to rebuild all of the AS path info from the AS_PATH and AS4_PATH attributes of a route 😵‍💫. This happens when two or more routes carrying AS4_PATH are aggregated by an OLD BGP speaker, and the AS4_PATH of at least one of those routes carries at least one four-octet AS number (not a two-octet AS number encoded in 4 octets). When that aggregation creates a route that is less specific than any of the component routes (routes whose Network Layer Reachability Information (NLRI) covers the NLRI of all the component routes), losing the AS path info does not create the risk of a routing loop. In all other cases, losing the AS path info does create the risk of a routing loop 🔁⚠️.

8. Manageability Considerations 📊

If the BGP4-MIB [RFC4273] is supported, there are no additional manageability concerns from using four-octet AS numbers, since the InetAutonomousSystemNumber textual convention [RFC4001] is defined as Unsigned32 🙌.

When IP Flow Information Export (IPFIX) [RFC5101] is supported, there are no additional manageability concerns from using four-octet AS numbers either 🌷. The bgpSourceAsNumber and bgpDestinationAsNumber information elements [IANA-IPFIX] can keep being used, with a new template record that specifies the new length of 4 bytes 🧚.

9. IANA Considerations 🏛️

This document expands the pool for AS numbers from 0-65535 to 0-4294967295 🌍. The AS numbers are managed by the IANA "Autonomous System Numbers" registry. Other than expanding the AS number pool, this document doesn't propose any changes to the existing policies and procedures for allocating AS numbers, so no drama there 🙂.

This document uses a BGP capability code to show that a BGP speaker supports four-octet AS numbers. Capability Code 65 has been assigned by IANA per [RFC5492] 🎫.

This document also introduces two BGP optional transitive attributes, and IANA has assigned their type codes. The first is the AS4_PATH attribute, value 17, which preserves the AS path info with four-octet AS numbers across old BGP speakers 🛣️. The second is the AS4_AGGREGATOR attribute, value 18, which is similar in use to the current AGGREGATOR attribute, but carries a four-octet AS number 💎.

Finally, IANA replaced a reference to RFC 4893 with a reference to this document for the reserved two-octet AS number AS_TRANS (23456) 🔄. IANA also replaced a reference to RFC 4893 with a reference to this document for the "32-bit Autonomous System Numbers" registry 📚.

10. Security Considerations 🔐

This extension to BGP does not change the underlying security issues inherent in the existing BGP, except for the following:

The inconsistency between the AS_PATH attribute and the AS4_PATH attribute can cause loss of AS path info, and potential routing loops in certain cases, as discussed in this document. This could be exploited by an attacker 🚨😱. Not a vibe.

It is a misconfiguration to assign a non-mappable four-octet AS number as the "Member AS Number" in a BGP Confederation before all the BGP speakers within the Confederation have transitioned to support four-octet AS numbers. Such a misconfiguration would weaken AS path loop detection within a Confederation 🙅‍♀️💀.

11. Acknowledgments 🫶

The authors would like to thank Yakov Rekhter, Chaitanya Kodeboyina, and Jeffrey Haas for the countless discussions that went into making this document 💜.

The authors would also like to thank members of the IDR Working Group for their review and comments 🌟.

12. References 📚

12.1. Normative References

okay so these are the ones you actually have to read before anything else 📚 they're the foundation the whole spec leans on, no cap 💅

   [RFC1997]    Chandra, R., Traina, P., and T. Li, "BGP Communities
                Attribute", RFC 1997, August 1996.

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4271]    Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
                Border Gateway Protocol 4 (BGP-4)", RFC 4271,
                January 2006.

   [RFC5065]    Traina, P., McPherson, D., and J. Scudder, "Autonomous
                System Confederations for BGP", RFC 5065, August 2007.

   [RFC5492]    Scudder, J. and R. Chandra, "Capabilities Advertisement
                with BGP-4", RFC 5492, February 2009.

   [RFC5668]    Rekhter, Y., Sangli, S., and D. Tappan, "4-Octet AS
                Specific BGP Extended Community", RFC 5668,
                October 2009.

12.2. Informative References

these ones are more like bonus reading 🌸 helpful for context, but the spec itself doesn't depend on them the same way ✨

   [IANA-IPFIX] IANA, "IP Flow Information Export (IPFIX) Entities",
                <http://www.iana.org/assignments/ipfix>.

   [RFC4001]    Daniele, M., Haberman, B., Routhier, S., and J.
                Schoenwaelder, "Textual Conventions for Internet Network
                Addresses", RFC 4001, February 2005.

   [RFC4273]    Haas, J., Ed., and S. Hares, Ed., "Definitions of
                Managed Objects for BGP-4", RFC 4273, January 2006.

   [RFC5101]    Claise, B., Ed., "Specification of the IP Flow
                Information Export (IPFIX) Protocol for the Exchange of
                IP Traffic Flow Information", RFC 5101, January 2008.

Authors' Addresses 🦋

and that's the whole crew who wrote this 🫶 here's where you can find them if you ever want to slide into their inbox to say thank you 💜

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

   EMail: quaizar.vohra@gmail.com


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

   EMail: enkechen@cisco.com
📦 where this page comes from