Capabilities Advertisement with BGP-4
RFC 3392

Document Type RFC - Draft Standard (November 2002; No errata)
Obsoleted by RFC 5492
Obsoletes RFC 2842
Authors John Scudder  , Ravi Chandra 
Last updated 2015-10-14
Stream Internent Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3392 (Draft Standard)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Bill Fenner
IESG note Published as RFC 3392
Send notices to <>
Network Working Group                                         R. Chandra
Request for Comments: 3392                              Redback Networks
Obsoletes: 2842                                               J. Scudder
Category: Standards Track                                  Cisco Systems
                                                           November 2002

                 Capabilities Advertisement with BGP-4

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


   This document defines a new Optional Parameter, called Capabilities,
   that is expected to facilitate the introduction of new capabilities
   in the Border Gateway Protocol (BGP) by providing graceful capability
   advertisement without requiring that BGP peering be terminated.

   This document obsoletes RFC 2842.

1. Introduction

   Currently BGP-4 requires that when a BGP speaker receives an OPEN
   message with one or more unrecognized Optional Parameters, the
   speaker must terminate BGP peering.  This complicates introduction of
   new capabilities in BGP.

2. Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Chandra, et. al.            Standards Track                     [Page 1]
RFC 3392         Capabilities Advertisement with BGP-4     November 2002

3. Overview of Operations

   When a BGP speaker [BGP-4] that supports capabilities advertisement
   sends an OPEN message to its BGP peer, the message MAY include an
   Optional Parameter, called Capabilities.  The parameter lists the
   capabilities supported by the speaker.

   A BGP speaker determines the capabilities supported by its peer by
   examining the list of capabilities present in the Capabilities
   Optional Parameter carried by the OPEN message that the speaker
   receives from the peer.

   A BGP speaker that supports a particular capability may use this
   capability with its peer after the speaker determines (as described
   above) that the peer supports this capability.

   A BGP speaker determines that its peer doesn't support capabilities
   advertisement, if in response to an OPEN message that carries the
   Capabilities Optional Parameter, the speaker receives a NOTIFICATION
   message with the Error Subcode set to Unsupported Optional Parameter.
   In this case the speaker SHOULD attempt to re-establish a BGP
   connection with the peer without sending to the peer the Capabilities
   Optional Parameter.

   If a BGP speaker that supports a certain capability determines that
   its peer doesn't support this capability, the speaker MAY send a
   NOTIFICATION message to the peer, and terminate peering (see Section
   "Extensions to Error Handling" for more details).  The Error Subcode
   in the message is set to Unsupported Capability.  The message SHOULD
   contain the capability (capabilities) that causes the speaker to send
   the message.  The decision to send the message and terminate peering
   is local to the speaker.  If terminated, such peering SHOULD NOT be
   re-established automatically.

Chandra, et. al.            Standards Track                     [Page 2]
RFC 3392         Capabilities Advertisement with BGP-4     November 2002

4. Capabilities Optional Parameter (Parameter Type 2):

   This is an Optional Parameter that is used by a BGP speaker to convey
   to its BGP peer the list of capabilities supported by the speaker.

   The parameter contains one or more triples <Capability Code,
   Capability Length, Capability Value>, where each triple is encoded as
   shown below:

       | Capability Code (1 octet)    |
       | Capability Length (1 octet)  |
       | Capability Value (variable)  |

   The use and meaning of these fields are as follows:

      Capability Code:

         Capability Code is a one octet field that unambiguously
         identifies individual capabilities.

      Capability Length:

         Capability Length is a one octet field that contains the length
         of the Capability Value field in octets.

      Capability Value:

         Capability Value is a variable length field that is interpreted
         according to the value of the Capability Code field.

   BGP speakers SHOULD NOT include more than one instance of a
Show full document text