summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6286.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6286.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6286.txt')
-rw-r--r--doc/rfc/rfc6286.txt227
1 files changed, 227 insertions, 0 deletions
diff --git a/doc/rfc/rfc6286.txt b/doc/rfc/rfc6286.txt
new file mode 100644
index 0000000..2fed690
--- /dev/null
+++ b/doc/rfc/rfc6286.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) E. Chen
+Request for Comments: 6286 J. Yuan
+Updates: 4271 Cisco Systems
+Category: Standards Track June 2011
+ISSN: 2070-1721
+
+
+ Autonomous-System-Wide Unique BGP Identifier for BGP-4
+
+Abstract
+
+ To accommodate situations where the current requirements for the BGP
+ Identifier are not met, this document relaxes the definition of the
+ BGP Identifier to be a 4-octet, unsigned, non-zero integer and
+ relaxes the "uniqueness" requirement so that only Autonomous-System-
+ wide (AS-wide) uniqueness of the BGP Identifiers is required. These
+ revisions to the base BGP specification do not introduce any backward
+ compatibility issues. This document updates RFC 4271.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ 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) 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 Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+Chen & Yuan Standards Track [Page 1]
+
+RFC 6286 AS-Wide Unique BGP ID for BGP-4 June 2011
+
+
+1. Introduction
+
+ Currently, the BGP Identifier of a BGP speaker is specified as a
+ valid IPv4 host address assigned to the BGP speaker [RFC4271]. In
+ addition, the deployed BGP code requires that two BGP speakers be of
+ distinct BGP Identifiers in order to establish a BGP connection.
+
+ To accommodate situations where the current requirements for the BGP
+ Identifier are not met (such as in the case of an IPv6-only network),
+ this document relaxes the definition of the BGP Identifier to be a
+ 4-octet, unsigned, non-zero integer and relaxes the "uniqueness"
+ requirement so that only AS-wide uniqueness of the BGP Identifiers is
+ required. These revisions to the base BGP specification do not
+ introduce any backward compatibility issues.
+
+2. Protocol Revisions
+
+ The revisions to the base BGP specification [RFC4271] include the
+ definition of the BGP Identifier and procedures for a BGP speaker
+ that supports the AS-wide Unique BGP Identifier.
+
+2.1. Definition of the BGP Identifier
+
+ For a BGP speaker that supports the AS-wide Unique BGP Identifier,
+ the BGP Identifier is specified as the following:
+
+ 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 related to the BGP Identifier is
+ modified as follows:
+
+ 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".
+
+
+
+
+
+
+
+
+
+
+Chen & Yuan Standards Track [Page 2]
+
+RFC 6286 AS-Wide Unique BGP ID for BGP-4 June 2011
+
+
+2.3. Connection Collision Resolution
+
+ For a BGP speaker that supports the AS-wide Unique BGP Identifier,
+ the procedures for connection collision resolution are extended as
+ follows to deal with the case in which the two BGP speakers share the
+ same BGP Identifier (thus, it is only applicable to an external
+ peer):
+
+ 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 covers cases in which the 4-octet AS numbers are
+ involved [RFC4893].
+
+3. Remarks
+
+ It is noted that a BGP Identifier allocated based on [RFC4271] fits
+ the revised definition.
+
+ In case of BGP Confederation, the whole confederation is considered
+ as one AS for the purpose of supporting 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 the remote
+ BGP speaker is upgraded with software that supports the specified
+ revisions.
+
+ In addition to the OPEN message, the BGP Identifier is currently also
+ used in the following areas:
+
+ o In the AGGREAGTOR attribute of a route where the combination of a
+ BGP Identifier and an AS number uniquely identifies the BGP speaker
+ that performs the route aggregation.
+
+ o In the Route Reflection within an AS, where only the BGP Identifier
+ of an internal neighbor may be propagated in the route reflection
+ related attributes.
+
+ o In the route selection, where the BGP Identifier is not used in
+ comparing a route from an internal neighbor and a route from an
+ external neighbor. In addition, routes from BGP speakers with
+ identical BGP Identifiers have been dealt with (e.g., parallel BGP
+ sessions between two BGP speakers).
+
+
+
+
+
+
+Chen & Yuan Standards Track [Page 3]
+
+RFC 6286 AS-Wide Unique BGP ID for BGP-4 June 2011
+
+
+ Therefore, it is concluded that the revisions specified in this
+ document do not introduce any backward compatibility issues with the
+ current usage of the BGP Identifier.
+
+4. Security Considerations
+
+ This extension to BGP does not introduce new security considerations.
+ BGP security considerations are discussed in [RFC4271].
+
+5. Acknowledgments
+
+ The authors would like to thank members of the IDR Working Group for
+ discussions on the "IPv6-only Network" related issues that inspired
+ this document.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+Chen & Yuan Standards Track [Page 4]
+