RFC 1771 (rfc1771) - Page 2 of 57

A Border Gateway Protocol 4 (BGP-4)

RFC 1771                         BGP-4                        March 1995


   This updated version of the document is the product of the IETF IDR
   Working Group with Yakov Rekhter and Tony Li as editors. Certain
   sections of the document borrowed heavily from IDRP [7], which is the
   OSI counterpart of BGP. For this credit should be given to the ANSI
   X3S3.3 group chaired by Lyman Chapin (BBN) and to Charles Kunzinger
   (IBM Corp.) who was the IDRP editor within that group.  We would also
   like to thank Mike Craren (Proteon, Inc.), Dimitry Haskin (Bay
   Networks, Inc.), John Krawczyk (Bay Networks, Inc.), and Paul Traina
   (cisco Systems) for their insightful comments.

   We would like to specially acknowledge numerous contributions by
   Dennis Ferguson (MCI).

   The work of Yakov Rekhter was supported in part by the National
   Science Foundation under Grant Number NCR-9219216.

2.  Introduction

   The Border Gateway Protocol (BGP) is an inter-Autonomous System
   routing protocol.  It is built on experience gained with EGP as
   defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
   described in RFC 1092 [2] and RFC 1093 [3].

   The primary function of a BGP speaking system is to exchange network
   reachability information with other BGP systems.  This network
   reachability information includes information on the list of
   Autonomous Systems (ASs) that reachability information traverses.
   This information is sufficient to construct a graph of AS
   connectivity from which routing loops may be pruned and some policy
   decisions at the AS level may be enforced.

   BGP-4 provides a new set of mechanisms for supporting classless
   interdomain routing.  These mechanisms include support for
   advertising an IP prefix and eliminates the concept of network
   "class" within BGP.  BGP-4 also introduces mechanisms which allow
   aggregation of routes, including aggregation of AS paths.  These
   changes provide support for the proposed supernetting scheme [8, 9].

   To characterize the set of policy decisions that can be enforced
   using BGP, one must focus on the rule that a BGP speaker advertise to
   its peers (other BGP speakers which it communicates with) in
   neighboring ASs only those routes that it itself uses.  This rule
   reflects the "hop-by-hop" routing paradigm generally used throughout
   the current Internet.  Note that some policies cannot be supported by
   the "hop-by-hop" routing paradigm and thus require techniques such as
   source routing to enforce.  For example, BGP does not enable one AS
   to send traffic to a neighboring AS intending that the traffic take a
   different route from that taken by traffic originating in the



Rekhter & Li