Network Working Group Y. Rekhter
Request for Comments: 1771 T.J. Watson Research Center, IBM Corp.
Obsoletes: 1654 T. Li
Category: Standards Track cisco Systems
Editors
March 1995
A Border Gateway Protocol 4 (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.
Abstract
This document, together with its companion document, "Application of
the Border Gateway Protocol in the Internet", define an inter-
autonomous system routing protocol for the Internet.
1. Acknowledgements
This document was originally published as RFC 1267 in October 1991,
jointly authored by Kirk Lougheed (cisco Systems) and Yakov Rekhter
(IBM).
We would like to express our thanks to Guy Almes (ANS), Len Bosack
(cisco Systems), and Jeffrey C. Honig (Cornell University) for their
contributions to the earlier version of this document.
We like to explicitly thank Bob Braden (ISI) for the review of the
earlier version of this document as well as his constructive and
valuable comments.
We would also like to thank Bob Hinden, Director for Routing of the
Internet Engineering Steering Group, and the team of reviewers he
assembled to review the previous version (BGP-2) of this document.
This team, consisting of Deborah Estrin, Milo Medin, John Moy, Radia
Perlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted
with a strong combination of toughness, professionalism, and
courtesy.
Rekhter & Li [Page 1]
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
datatracker.ietf.org