|
|
|
|
|
|
|
|
|
|
| Last Update: Jun 22, 2010
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC1745
12/1994
(19 p.)
pdf(2p)
|
K. Varadhan
S. Hares
Y. Rekhter |
|
BGP4/IDRP for IP - OSPF Interaction |
|
This memo defines the various criteria to be used when designing an
Autonomous System Border Router (ASBR) that will run either BGP4 or
IDRP for IP with other ASBRs external to the AS and OSPF as its IGP.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC1773
03/1995
(9 p.)
pdf(2p)
|
P. Traina |
|
Experience with the BGP-4 protocol |
|
The purpose of this memo is to document how the requirements for
advancing a routing protocol to Draft Standard have been satisfied by
Border Gateway Protocol version 4 (BGP-4). This report documents
experience with BGP. This is the second of two reports on the BGP
protocol. As required by the Internet Architecure Board (IAB) and
the Internet Engineering Steering Group (IESG), the first report will
present a performance analysis of the BGP protocol.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC1774
03/1995
(10 p.)
pdf(2p)
|
P. Traina |
|
BGP-4 Protocol Analysis |
|
The purpose of this report is to document how the requirements for
advancing a routing protocol to Draft Standard have been satisfied by
the Border Gateway Protocol version 4 (BGP-4). This report summarizes
the key features of BGP, and analyzes the protocol with respect to
scaling and performance. This is the first of two reports on the BGP
protocol.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC1930
03/1996
(10 p.)
pdf(2p)
|
J. Hawkinson
T. Bates |
|
Guidelines for creation, selection, and registration
of an Autonomous System (AS) |
|
This memo discusses when it is appropriate to register and utilize an
Autonomous System (AS), and lists criteria for such. ASes are the
unit of routing policy in the modern world of exterior routing, and
are specifically applicable to protocols like EGP (Exterior Gateway
Protocol, now at historical status; see [EGP]), BGP (Border Gateway
Protocol, the current de facto standard for inter-AS routing; see
[BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the
Internet is expected to adopt when BGP becomes obsolete; see [IDRP]).
It should be noted that the IDRP equivalent of an AS is the RDI, or
Routing Domain Identifier.
|
|
|
|
|
|
|
|
|
|
|
| | |
RFC1997
08/1996
(5 p.)
pdf(2p)
|
R. Chandra
P. Traina
T. Li |
|
BGP Communities Attribute |
|
Border Gateway Protocol is an inter-autonomous system routing
protocol designed for TCP/IP internets.
This document describes an extension to BGP which may be used to pass
additional information to both neighboring and remote BGP peers.
The intention of the proposed technique is to aid in policy
administration and reduce the management complexity of maintaining
the Internet.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC1998
08/1996
(9 p.)
pdf(2p)
|
E. Chen
T. Bates |
|
An Application of the BGP Community Attribute in Multi-home Routing |
|
This document presents an application of the BGP community attribute
in simplifying the implementation and configuration of routing
policies in the multi-provider Internet. It shows how the community
based configuration can be used to replace the AS-based customization
of the BGP "LOCAL_PREF" attribute, a common method used today. Not
only does the technique presented simplifies configuration and
management at the provider level, it also represents a paradigm shift
in that it gives the potential for the customer to control its own
routing policy with respect to its service provider, as well as
providing the ability for policy configuration to be done at a prefix
based granularity rather than the more common AS based granularity.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC2270
01/1998
(6 p.)
pdf(2p)
|
J. Stewart
T. Bates
R. Chandra
E. Chen |
|
Using a Dedicated AS for Sites Homed to a Single Provider |
|
With the increased growth of the Internet, the number of customers
using BGP4 has grown significantly. RFC1930 outlines a set of
guidelines for when one needs and should use an AS. However, the
customer and service provider (ISP) are left with a problem as a
result of this in that while there is no need for an allocated AS
under the guidelines, certain conditions make the use of BGP4 a very
pragmatic and perhaps only way to connect a customer homed to a
single ISP. This paper proposes a solution to this problem in line
with recommendations set forth in RFC1930.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC2439
11/1998
(37 p.)
pdf(2p)
|
C. Villamizar
R. Chandra
R. Govindan |
|
BGP Route Flap Damping |
A usage of the BGP routing protocol is described which is capable of
reducing the routing traffic passed on to routing peers and therefore
the load on these peers without adversely affecting route convergence
time for relatively stable routes. This technique has been
implemented in commercial products supporting BGP. The technique is
also applicable to IDRP.
The overall goals are:
|
| - |
to provide a mechanism capable of reducing router processing load
caused by instability
| |
| - |
in doing so prevent sustained routing oscillations
| |
| - |
to do so without sacrificing route convergence time for generally
well behaved routes.
|
This must be accomplished keeping other goals of BGP in mind:
|
| - |
pack changes into a small number of updates
| |
| - |
preserve consistent routing
| |
| - |
minimal addition space and computational overhead
|
An excessive rate of update to the advertised reachability of a
subset of Internet prefixes has been widespread in the Internet.
This observation was made in the early 1990s by many people involved
in Internet operations and remains the case. These excessive updates
are not necessarily periodic so route oscillation would be a
misleading term. The informal term used to describe this effect is
"route flap". The techniques described here are now widely deployed
and are commonly referred to as "route flap damping".
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC2519
02/1999
(13 p.)
pdf(2p)
|
E. Chen
J. Stewart |
|
A Framework for Inter-Domain Route Aggregation |
|
This document presents a framework for inter-domain route aggregation
and shows an example router configuration which 'implements' this
framework. This framework is flexible and scales well as it
emphasizes the philosophy of aggregation by the source, both within
routing domains as well as towards upstream providers, and it also
strongly encourages the use of the 'no-export' BGP community to
balance the provider-subscriber need for more granular routing
information with the Internet's need for scalable inter-domain
routing.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC2545
03/1999
(5 p.)
pdf(2p)
|
P. Marques
F. Dupont |
|
Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing |
|
BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP
attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to
announce and withdraw the announcement of reachability information.
This document defines how compliant systems should make use of those
attributes for the purpose of conveying IPv6 routing information.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC2918
09/2000
(4 p.)
pdf(2p)
|
E. Chen |
|
Route Refresh Capability for BGP-4 |
|
This document defines a new Border Gateway Protocol (BGP) capability
termed 'Route Refresh Capability', which would allow the dynamic
exchange of route refresh request between BGP speakers and subsequent
re-advertisement of the respective Adj-RIB-Out. One possible
application of this capability is to facilitate non-disruptive
routing policy changes.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC3345
08/2002
(19 p.)
pdf(2p)
|
D. McPherson
V. Gill
D. Walton
A. Retana |
|
Border Gateway Protocol (BGP) Persistent Route Oscillation Condition |
|
In particular configurations, the BGP scaling mechanisms defined in
"BGP Route Reflection - An Alternative to Full Mesh IBGP" and
"Autonomous System Confederations for BGP" will introduce persistent
BGP route oscillation. This document discusses the two types of
persistent route oscillation that have been identified, describes
when these conditions will occur, and provides some network design
guidelines to avoid introducing such occurrences.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC3562
07/2003
(7 p.)
pdf(2p)
|
M. Leech |
|
Key Management Considerations for the TCP MD5 Signature Option |
|
The TCP MD5 Signature Option (RFC 2385), used predominantly by BGP,
has seen significant deployment in critical areas of Internet
infrastructure. The security of this option relies heavily on the
quality of the keying material used to compute the MD5 signature.
This document addresses the security requirements of that keying
material.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4271
01/2006
(104 p.)
pdf(2p)
|
Y. Rekhter
T. Li
S. Hares |
|
A Border Gateway Protocol 4 (BGP-4) |
This document discusses the Border Gateway Protocol (BGP), which is
an inter-Autonomous System routing protocol.
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 (ASes) that reachability information traverses.
This information is sufficient for constructing a graph of AS
connectivity for this reachability from which routing loops may be
pruned, and, at the AS level, some policy decisions may be enforced.
BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain
Routing (CIDR). These mechanisms include support for
advertising a set of destinations as an IP prefix, and eliminating
the concept of network "class" within BGP. BGP-4 also introduces
mechanisms that allow aggregation of routes, including aggregation of
AS paths.
|
|
|
| |
| List |
Status: | Draft Standard |
|
|
|
|
|
|
|
|
| | |
RFC4272
01/2006
(22 p.)
pdf(2p)
|
S. Murphy |
|
BGP Security Vulnerabilities Analysis |
Border Gateway Protocol 4 (BGP-4), along with a host of other
infrastructure protocols designed before the Internet environment
became perilous, was originally designed with little consideration
for protection of the information it carries. There are no
mechanisms internal to BGP that protect against attacks that modify,
delete, forge, or replay data, any of which has the potential to
disrupt overall network routing behavior.
This document discusses some of the security issues with BGP routing
data dissemination. This document does not discuss security issues
with forwarding of packets.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4273
01/2006
(32 p.)
pdf(2p)
|
J. Haas
S. Hares |
|
Definitions of Managed Objects for BGP-4 |
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community
In particular, it describes managed objects used for managing the
Border Gateway Protocol Version 4 or lower.
The origin of this memo is from RFC 1269 "Definitions of Managed
Objects for the Border Gateway Protocol (Version 3)", which was
updated to support BGP-4 in RFC 1657. This memo fixes errors
introduced when the MIB module was converted to use the SMIv2
language. This memo also updates references to the current SNMP
framework documents.
This memo is intended to document deployed implementations of this
MIB module in a historical context, to provide clarifications of some
items, and to note errors where the MIB module fails to fully
represent the BGP protocol. Work is currently in progress to replace
this MIB module with a new one representing the current state of the
BGP protocol and its extensions.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC4274
01/2006
(16 p.)
pdf(2p)
|
D. Meyer
K. Patel |
|
BGP-4 Protocol Analysis |
The purpose of this report is to document how the requirements for
publication of a routing protocol as an Internet Draft Standard have
been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for "the second report", as
described in Section 6.0 of RFC 1264. In order to fulfill the
requirement, this report augments RFC 1774 and summarizes the key
features of BGP-4, as well as analyzes the protocol with respect to
scaling and performance.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4276
01/2006
(97 p.)
pdf(2p)
|
S. Hares
A. Retana |
|
BGP-4 Implementation Report |
This document reports the results of the BGP-4 implementation survey.
The survey had 259 questions about implementations' support of BGP-4
as specified in RFC 4271. After a brief summary of the results, each
response is listed. This document contains responses from the four
implementers that completed the survey (Alcatel, Cisco, Laurel, and
NextHop) and brief information from three that did not (Avici, Data
Connection Ltd., and Nokia).
The editors did not use exterior means to verify the accuracy of the
information submitted by the respondents. The respondents are
experts with the products they reported on.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4277
01/2006
(19 p.)
pdf(2p)
|
D. McPherson
K. Patel |
|
Experience with the BGP-4 Protocol |
The purpose of this memo is to document how the requirements for
publication of a routing protocol as an Internet Draft Standard have
been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for "the second report", as
described in Section 6.0 of RFC 1264. In order to fulfill the
requirement, this report augments RFC 1773 and describes additional
knowledge and understanding gained in the time between when the
protocol was made a Draft Standard and when it was submitted for
Standard.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC4360
02/2006
(12 p.)
pdf(2p)
|
S. Sangli
D. Tappan
Y. Rekhter |
|
BGP Extended Communities Attribute |
|
This document describes the "extended community" BGP-4 attribute.
This attribute provides a mechanism for labeling information carried
in BGP-4. These labels can be used to control the distribution of
this information, or for other applications.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC4456
04/2006
(12 p.)
pdf(2p)
|
T. Bates
E. Chen
R. Chandra |
|
BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP) |
The Border Gateway Protocol (BGP) is an inter-autonomous system
routing protocol designed for TCP/IP internets. Typically, all BGP
speakers within a single AS must be fully meshed so that any external
routing information must be re-distributed to all other routers
within that Autonomous System (AS). This represents a serious
scaling problem that has been well documented with several
alternatives proposed.
This document describes the use and design of a method known as
"route reflection" to alleviate the need for "full mesh" Internal BGP
(IBGP).
|
|
|
| |
| List |
Status: | Draft Standard |
|
|
|
|
|
|
|
|
| | |
RFC4486
04/2006
(6 p.)
pdf(2p)
|
E. Chen
V. Gillet |
|
Subcodes for BGP Cease Notification Message |
|
This document defines several subcodes for the BGP Cease NOTIFICATION
message that would provide more information to aid network operators
in correlating network events and diagnosing BGP peering issues.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC4724
01/2007
(15 p.)
pdf(2p)
|
S. Sangli
E. Chen
R. Fernando
J. Scudder
Y. Rekhter |
|
Graceful Restart Mechanism for BGP |
This document describes a mechanism for BGP that would help minimize
the negative effects on routing caused by BGP restart. An End-of-RIB
marker is specified and can be used to convey routing convergence
information. A new BGP capability, termed "Graceful Restart
Capability", is defined that would allow a BGP speaker to express its
ability to preserve forwarding state during BGP restart. Finally,
procedures are outlined for temporarily retaining routing information
across a TCP session termination/re-establishment.
The mechanisms described in this document are applicable to all
routers, both those with the ability to preserve forwarding state
during BGP restart and those without (although the latter need to
implement only a subset of the mechanisms described in this
document).
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC4760
01/2007
(12 p.)
pdf(2p)
|
T. Bates
R. Chandra
D. Katz
Y. Rekhter |
|
Multiprotocol Extensions for BGP-4 |
|
This document defines extensions to BGP-4 to enable it to carry
routing information for multiple Network Layer protocols (e.g., IPv6,
IPX, L3VPN, etc.). The extensions are backward compatible - a router
that supports the extensions can interoperate with a router that
doesn't support the extensions.
|
|
|
| |
| List |
Status: | Draft Standard |
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5004
09/2007
(6 p.)
pdf(2p)
|
E. Chen
S. Sangli |
|
Avoid BGP Best Path Transitions from One External to Another |
|
In this document, we propose an extension to the BGP route selection
rules that would avoid unnecessary best path transitions between
external paths under certain conditions. The proposed extension
would help the overall network stability, and more importantly, would
eliminate certain BGP route oscillations in which more than one
external path from one BGP speaker contributes to the churn.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5065
08/2007
(14 p.)
pdf(2p)
|
P. Traina
D. McPherson
J. Scudder |
|
Autonomous System Confederations for BGP |
The Border Gateway Protocol (BGP) is an inter-autonomous system
routing protocol designed for Transmission Control Protocol/Internet
Protocol (TCP/IP) networks. BGP requires that all BGP speakers
within a single autonomous system (AS) must be fully meshed. This
represents a serious scaling problem that has been well documented in
a number of proposals.
This document describes an extension to BGP that may be used to
create a confederation of autonomous systems that is represented as a
single autonomous system to BGP peers external to the confederation,
thereby removing the "full mesh" requirement. The intention of this
extension is to aid in policy administration and reduce the
management complexity of maintaining a large autonomous system.
|
|
|
| |
| List |
Status: | Draft Standard |
|
|
|
|
|
|
|
|
| | |
RFC5291
08/2008
(12 p.)
pdf(2p)
|
E. Chen
Y. Rekhter |
|
Outbound Route Filtering Capability for BGP-4 |
|
This document defines a BGP-based mechanism that allows a BGP speaker
to send to its BGP peer a set of Outbound Route Filters (ORFs) that
the peer would use to constrain/filter its outbound routing updates
to the speaker.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5292
08/2008
(6 p.)
pdf(2p)
|
E. Chen
S. Sangli |
|
Address-Prefix-Based Outbound Route Filter for BGP-4 |
|
This document defines a new Outbound Router Filter (ORF) type for
BGP, termed "Address Prefix Outbound Route Filter", that can be used
to perform address-prefix-based route filtering. This ORF-type
supports prefix-length- or range-based matching, wild-card-based
address prefix matching, as well as the exact address prefix matching
for address families.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
| | |
RFC5398
12/2008
(3 p.)
pdf(2p)
|
G. Huston |
|
Autonomous System (AS) Number Reservation for Documentation Use |
|
To reduce the likelihood of conflict and confusion when relating
documented examples to deployed systems, two blocks of Autonomous
System numbers (ASNs) are reserved for use in examples in RFCs,
books, documentation, and the like. This document describes the
reservation of two blocks of ASNs as reserved numbers for use in
documentation.
|
|
|
| |
| List |
Status: | Informational |
|
|
|
|
|
|
|
|
| | |
RFC5492
02/2009
(7 p.)
pdf(2p)
|
J. Scudder
R. Chandra |
|
Capabilities Advertisement with BGP-4 |
|
This document defines an 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.
|
|
|
| |
| List |
Status: | Draft Standard |
|
|
|
|
|
|
|
|
| | |
RFC5575
08/2009
(22 p.)
pdf(2p)
|
P. Marques
N. Sheth
R. Raszuk
B. Greene
J. Mauch
D. McPherson |
|
Dissemination of Flow Specification Rules |
This document defines a new Border Gateway Protocol Network Layer
Reachability Information (BGP NLRI) encoding format that can be used
to distribute traffic flow specifications. This allows the routing
system to propagate information regarding more specific components of
the traffic aggregate defined by an IP destination prefix.
Additionally, it defines two applications of that encoding format:
one that can be used to automate inter-domain coordination of traffic
filtering, such as what is required in order to mitigate
(distributed) denial-of-service attacks, and a second application to
provide traffic filtering in the context of a BGP/MPLS VPN service.
The information is carried via the BGP, thereby reusing protocol
algorithms, operational experience, and administrative processes such
as inter-provider peering agreements.
|
|
|
| |
| List |
Status: | Proposed Standard |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
