6286
PROPOSED STANDARD

Autonomous-System-Wide Unique BGP Identifier for BGP-4

Authors: E. Chen, J. Yuan
Date: June 2011
Area: rtg
Working Group: idr
Stream: IETF
Updates: RFC 4271

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. [STANDARDS-TRACK]

RFC 6286: Autonomous-System-Wide Unique BGP Identifier for BGP-4 [RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Errata] [Info page]

PROPOSED STANDARD
Errata Exist
Internet Engineering Task Force (IETF)                           E. Chen
Request for Comments: 6286                                       J. Yuan
Updates: <a href="./rfc4271">4271</a>                                              Cisco Systems
Category: Standards Track                                      June 2011
ISSN: 2070-1721


         <span class="h1">Autonomous-System-Wide Unique BGP Identifier for BGP-4</span>

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 <a href="./rfc4271">RFC 4271</a>.

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 <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="https://www.rfc-editor.org/info/rfc6286">http://www.rfc-editor.org/info/rfc6286</a>.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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.




<span class="grey">Chen & Yuan                  Standards Track                    [Page 1]</span>

<span id="page-2" ></span>
<span class="grey"><a href="./rfc6286">RFC 6286</a>             AS-Wide Unique BGP ID for BGP-4           June 2011</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   Currently, the BGP Identifier of a BGP speaker is specified as a
   valid IPv4 host address assigned to the BGP speaker [<a href="./rfc4271" title=""A Border Gateway Protocol 4 (BGP-4)"">RFC4271</a>].  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.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Protocol Revisions</span>

   The revisions to the base BGP specification [<a href="./rfc4271" title=""A Border Gateway Protocol 4 (BGP-4)"">RFC4271</a>] include the
   definition of the BGP Identifier and procedures for a BGP speaker
   that supports the AS-wide Unique BGP Identifier.

<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>.  Definition of the BGP Identifier</span>

   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.

<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>.  Open Message Error Handling</span>

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










<span class="grey">Chen & Yuan                  Standards Track                    [Page 2]</span>

<span id="page-3" ></span>
<span class="grey"><a href="./rfc6286">RFC 6286</a>             AS-Wide Unique BGP ID for BGP-4           June 2011</span>


<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>.  Connection Collision Resolution</span>

   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 [<a href="./rfc4893" title=""BGP Support for Four-octet AS Number Space"">RFC4893</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Remarks</span>

   It is noted that a BGP Identifier allocated based on [<a href="./rfc4271" title=""A Border Gateway Protocol 4 (BGP-4)"">RFC4271</a>] 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).






<span class="grey">Chen & Yuan                  Standards Track                    [Page 3]</span>

<span id="page-4" ></span>
<span class="grey"><a href="./rfc6286">RFC 6286</a>             AS-Wide Unique BGP ID for BGP-4           June 2011</span>


   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.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Security Considerations</span>

   This extension to BGP does not introduce new security considerations.
   BGP security considerations are discussed in [<a href="./rfc4271" title=""A Border Gateway Protocol 4 (BGP-4)"">RFC4271</a>].

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Acknowledgments</span>

   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.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Normative References</span>

   [<a id="ref-RFC4271">RFC4271</a>] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border
             Gateway Protocol 4 (BGP-4)", <a href="./rfc4271">RFC 4271</a>, January 2006.

   [<a id="ref-RFC4893">RFC4893</a>] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
             Number Space", <a href="./rfc4893">RFC 4893</a>, May 2007.

Authors' Addresses

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

   EMail: [email protected]

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

   EMail: [email protected]













Chen & Yuan                  Standards Track                    [Page 4]

Additional Resources