RFC 6286

RFC 6286: Autonomous-System-Wide Unique BGP Identifier for BGP-4 💖

Authors: Enke Chen and Jenny Yuan, both at Cisco Systems 🎀 Category: Standards Track ✨ Date: June 2011 ISSN: 2070-1721 Updates: RFC 4271 (it updates the BGP-4 base spec) 🔥 Obsoletes: nothing

Abstract 🦋

okay so some networks don't meet the current rules for the BGP Identifier, so this doc loosens them up 💅 The BGP Identifier becomes a 4-octet, unsigned, non-zero integer, and the "uniqueness" rule gets relaxed so it only has to be unique within an Autonomous System (AS-wide). These changes to the base BGP spec don't cause any backward compatibility issues, no cap 🫶 This document updates RFC 4271.

Status of This Memo 📜

This is an Internet Standards Track document. 🌈

It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication. 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/rfc6286. 🧚

Copyright Notice ©

Copyright (c) 2011 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 publication date. Please read those carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License describes. 🙈

1. Introduction ✨

So right now, a BGP speaker's BGP Identifier has to be a valid IPv4 host address assigned to that speaker [RFC4271]. On top of that, the BGP code that's actually deployed needs two BGP speakers to have distinct BGP Identifiers before they can set up a BGP connection 🙄

That's a problem for networks where those rules don't work, like an IPv6-only network. So this document loosens things: the BGP Identifier becomes a 4-octet, unsigned, non-zero integer, and the uniqueness requirement only has to hold AS-wide. These changes to the base BGP spec don't cause backward compatibility issues. 👑

2. Protocol Revisions 🎀

The changes to the base BGP spec [RFC4271] cover how the BGP Identifier is defined and what a BGP speaker that supports the AS-wide Unique BGP Identifier has to do.

2.1. Definition of the BGP Identifier 🌸

For a BGP speaker that supports the AS-wide Unique BGP Identifier, the BGP Identifier is defined like this:

The BGP Identifier is a 4-octet, unsigned, non-zero integer that
should be unique within an AS.  The value of the BGP Identifier
for a BGP speaker is determined on startup and is the same for
every local interface and every BGP peer.

2.2. Open Message Error Handling 🍓

For a BGP speaker that supports the AS-wide Unique BGP Identifier, the OPEN message error handling tied to the BGP Identifier gets tweaked like this:

If the BGP Identifier field of the OPEN message is zero, or if it
is the same as the BGP Identifier of the local BGP speaker and the
message is from an internal peer, then the Error Subcode is set to
"Bad BGP Identifier".

2.3. Connection Collision Resolution 💅

For a BGP speaker that supports the AS-wide Unique BGP Identifier, the connection collision resolution procedures get extended to handle the case where two BGP speakers share the same BGP Identifier. That only applies to an external peer, since it's the one case that matters here 😭

If the BGP Identifiers of the peers involved in the connection
collision are identical, then the connection initiated by the BGP
speaker with the larger AS number is preserved.

This extension also covers cases where 4-octet AS numbers are involved [RFC4893]. 🦋

3. Remarks 🧚

A BGP Identifier that was allocated based on [RFC4271] already fits the revised definition. Iconic, honestly 👑

In a BGP Confederation, the whole confederation counts as one AS for the purpose of the AS-wide Unique BGP Identifier. 🌈

A BGP speaker that supports the AS-wide Unique BGP Identifier cannot share a BGP Identifier with its external neighbor until that remote BGP speaker has been upgraded with software that supports these revisions. Not me being patient about this 🙈

Besides the OPEN message, the BGP Identifier is also used in these places right now:

• In the AGGREAGTOR attribute of a route, where a BGP Identifier and an AS number together uniquely identify the BGP speaker that does the route aggregation. 💜
• In Route Reflection within an AS, where only the BGP Identifier of an internal neighbor may be passed along in the route reflection related attributes. 🫶
• In route selection, where the BGP Identifier isn't used when comparing a route from an internal neighbor with a route from an external neighbor. Routes from BGP speakers with identical BGP Identifiers are also handled (for example, parallel BGP sessions between two BGP speakers). ✨

So the conclusion is that the revisions in this document don't cause any backward compatibility issues with how the BGP Identifier is currently used. Literally the best news 🎀

4. Security Considerations 💀

This extension to BGP does not introduce new security considerations. BGP security considerations are discussed in [RFC4271]. 🙈

Okay, to be clear: this extension doesn't add new security considerations, but BGP's security stuff is still a whole thing, and it's all covered in [RFC4271]. Don't skip it 🔥

5. Acknowledgments 🫶

The authors want to thank the members of the IDR Working Group for their discussions about the "IPv6-only Network" issues that inspired this document. The group is iconic 🌸

6. Normative References 📚

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

[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
          Number Space", RFC 4893, May 2007.

Authors' Addresses 🧚

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

EMail: enkechen@cisco.com

Jenny Yuan Cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134

EMail: jenny@cisco.com