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
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.
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.
This document was originally published as RFC 1267 in October 1991,
jointly authored by Kirk Lougheed (cisco Systems) and Yakov Rekhter
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
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
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 , 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.
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  and EGP usage in the NSFNET Backbone as
described in RFC 1092  and RFC 1093 .
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
neighboring AS. On the other hand, BGP can support any policy
conforming to the "hop-by-hop" routing paradigm. Since the current
Internet uses only the "hop-by-hop" routing paradigm and since BGP
can support any policy that conforms to that paradigm, BGP is highly
applicable as an inter-AS routing protocol for the current Internet.
A more complete discussion of what policies can and cannot be
enforced with BGP is outside the scope of this document (but refer to
the companion document discussing BGP usage ).
BGP runs over a reliable transport protocol. This eliminates the
need to implement explicit update fragmentation, retransmission,
acknowledgement, and sequencing. Any authentication scheme used by
the transport protocol may be used in addition to BGP's own
authentication mechanisms. The error notification mechanism used in
BGP assumes that the transport protocol supports a "graceful" close,
i.e., that all outstanding data will be delivered before the
connection is closed.
BGP uses TCP  as its transport protocol. TCP meets BGP's
transport requirements and is present in virtually all commercial
routers and hosts. In the following descriptions the phrase
"transport protocol connection" can be understood to refer to a TCP
connection. BGP uses TCP port 179 for establishing its connections.
This document uses the term `Autonomous System' (AS) throughout. The
classic definition of an Autonomous System is a set of routers under
a single technical administration, using an interior gateway protocol
and common metrics to route packets within the AS, and using an
exterior gateway protocol to route packets to other ASs. Since this
classic definition was developed, it has become common for a single
AS to use several interior gateway protocols and sometimes several
sets of metrics within an AS. The use of the term Autonomous System
here stresses the fact that, even when multiple IGPs and metrics are
used, the administration of an AS appears to other ASs to have a
single coherent interior routing plan and presents a consistent
picture of what destinations are reachable through it.
The planned use of BGP in the Internet environment, including such
issues as topology, the interaction between BGP and IGPs, and the
enforcement of routing policy rules is presented in a companion
document . This document is the first of a series of documents
planned to explore various aspects of BGP application. Please send
comments to the BGP mailing list (email@example.com).
3. Summary of Operation
Two systems form a transport protocol connection between one another.
They exchange messages to open and confirm the connection parameters.
The initial data flow is the entire BGP routing table. Incremental
updates are sent as the routing tables change. BGP does not require
periodic refresh of the entire BGP routing table. Therefore, a BGP
speaker must retain the current version of the entire BGP routing
tables of all of its peers for the duration of the connection.
KeepAlive messages are sent periodically to ensure the liveness of
the connection. Notification messages are sent in response to errors
or special conditions. If a connection encounters an error
condition, a notification message is sent and the connection is
The hosts executing the Border Gateway Protocol need not be routers.
A non-routing host could exchange routing information with routers
via EGP or even an interior routing protocol. That non-routing host
could then use BGP to exchange routing information with a border
router in another Autonomous System. The implications and
applications of this architecture are for further study.
If a particular AS has multiple BGP speakers and is providing transit
service for other ASs, then care must be taken to ensure a consistent
view of routing within the AS. A consistent view of the interior
routes of the AS is provided by the interior routing protocol. A
consistent view of the routes exterior to the AS can be provided by
having all BGP speakers within the AS maintain direct BGP connections
with each other. Using a common set of policies, the BGP speakers
arrive at an agreement as to which border routers will serve as
exit/entry points for particular destinations outside the AS. This
information is communicated to the AS's internal routers, possibly
via the interior routing protocol. Care must be taken to ensure that
the interior routers have all been updated with transit information
before the BGP speakers announce to other ASs that transit service is
Connections between BGP speakers of different ASs are referred to as
"external" links. BGP connections between BGP speakers within the
same AS are referred to as "internal" links. Similarly, a peer in a
different AS is referred to as an external peer, while a peer in the
same AS may be described as an internal peer.
3.1 Routes: Advertisement and Storage
For purposes of this protocol a route is defined as a unit of
information that pairs a destination with the attributes of a path to
- Routes are advertised between a pair of BGP speakers in UPDATE
messages: the destination is the systems whose IP addresses are
reported in the Network Layer Reachability Information (NLRI)
field, and the the path is the information reported in the path
attributes fields of the same UPDATE message.
- Routes are stored in the Routing Information Bases (RIBs):
namely, the Adj-RIBs-In, the Loc-RIB, and the Adj-RIBs-Out. Routes
that will be advertised to other BGP speakers must be present in
the Adj-RIB-Out; routes that will be used by the local BGP speaker
must be present in the Loc-RIB, and the next hop for each of these
routes must be present in the local BGP speaker's forwarding
information base; and routes that are received from other BGP
speakers are present in the Adj-RIBs-In.
If a BGP speaker chooses to advertise the route, it may add to or
modify the path attributes of the route before advertising it to a
BGP provides mechanisms by which a BGP speaker can inform its peer
that a previously advertised route is no longer available for use.
There are three methods by which a given BGP speaker can indicate
that a route has been withdrawn from service:
a) the IP prefix that expresses destinations for a previously
advertised route can be advertised in the WITHDRAWN ROUTES field
in the UPDATE message, thus marking the associated route as being
no longer available for use
b) a replacement route with the same Network Layer Reachability
Information can be advertised, or
c) the BGP speaker - BGP speaker connection can be closed, which
implicitly removes from service all routes which the pair of
speakers had advertised to each other.
3.2 Routing Information Bases
The Routing Information Base (RIB) within a BGP speaker consists of
three distinct parts:
a) Adj-RIBs-In: The Adj-RIBs-In store routing information that has
been learned from inbound UPDATE messages. Their contents
represent routes that are available as an input to the Decision
b) Loc-RIB: The Loc-RIB contains the local routing information
that the BGP speaker has selected by applying its local policies
to the routing information contained in its Adj-RIBs-In.
c) Adj-RIBs-Out: The Adj-RIBs-Out store the information that the
local BGP speaker has selected for advertisement to its peers. The
routing information stored in the Adj-RIBs-Out will be carried in
the local BGP speaker's UPDATE messages and advertised to its
In summary, the Adj-RIBs-In contain unprocessed routing information
that has been advertised to the local BGP speaker by its peers; the
Loc-RIB contains the routes that have been selected by the local BGP
speaker's Decision Process; and the Adj-RIBs-Out organize the routes
for advertisement to specific peers by means of the local speaker's
Although the conceptual model distinguishes between Adj-RIBs-In,
Loc-RIB, and Adj-RIBs-Out, this neither implies nor requires that an
implementation must maintain three separate copies of the routing
information. The choice of implementation (for example, 3 copies of
the information vs 1 copy with pointers) is not constrained by the