A Border Gateway Protocol 4 (BGP-4)
obsoletes
- rfc-1771 — A Border Gateway Protocol 4 (BGP-4)
updated by
- rfc-4724 — Graceful Restart Mechanism for BGP
- rfc-6286 — Autonomous-System-Wide Unique BGP Identifier for BGP-4
- rfc-6608 — Subcodes for BGP Finite State Machine Error
- rfc-6793 — BGP Support for Four-Octet Autonomous System (AS) Number Space
- rfc-7606 — Revised Error Handling for BGP UPDATE Messages
- rfc-7607 — Codification of AS 0 Processing
- rfc-7705 — Autonomous System Migration Mechanisms and Their Effects on the BGP AS_PATH Attribute
- rfc-8212 — Default External BGP (EBGP) Route Propagation Behavior without Policies
- rfc-8654 — Extended Message Support for BGP
- rfc-9072 — Extended Optional Parameters Length for BGP OPEN Message
- rfc-9687 — Border Gateway Protocol 4 (BGP-4) Send Hold Timer
- rfc-9774 — Deprecation of AS_SET and AS_CONFED_SET in BGP
Extracted elements (31)
BGP uses TCP as its transport rather than implementing its own reliability layer, eliminating the need for explicit update fragmentation, retransmission, acknowledgement, and sequencing. This simplifies the protocol but couples BGP session lifetime to TCP connection state.
MULTI_EXIT_DISC is intentionally scoped to a single AS boundary (must not be propagated to other neighboring ASes) to prevent unintended influence on distant routing decisions and to preserve each AS's autonomy over its own exit-point selection.
The BGP Identifier collision resolution rule (retain the connection from the higher BGP Identifier) provides a deterministic, configuration-free convention when two peers simultaneously initiate connections to each other, avoiding the need for an external tie-breaker.
An UPDATE message SHOULD NOT include the same address prefix in both WITHDRAWN ROUTES and NLRI fields simultaneously, but a BGP speaker MUST be able to process such messages and SHOULD treat the prefix as not withdrawn.
BGP version negotiation is accomplished by retrying connection attempts starting with the highest supported version. If a peer returns NOTIFICATION with error OPEN Message Error / Unsupported Version Number, the Data field carries the largest locally-supported version less than the peer's bid, enabling rapid convergence on the highest common version.
A BGP speaker SHOULD retain the current version of routes advertised by all peers for the duration of the connection, or make use of the Route Refresh extension (RFC 2918), to allow local policy changes without resetting connections.
A route received with the ATOMIC_AGGREGATE attribute MUST NOT have its NLRI made more specific when advertised to other speakers, and the attribute SHOULD NOT be removed during propagation.
KEEPALIVE messages MUST NOT be sent more frequently than one per second. If the negotiated Hold Time is zero, periodic KEEPALIVE messages MUST NOT be sent.
LOCAL_PREF SHALL be included in all UPDATE messages sent to internal peers. A BGP speaker MUST NOT include LOCAL_PREF in UPDATE messages sent to external peers (except in BGP Confederations); if received from an external peer it MUST be ignored.
ORIGIN, AS_PATH, and NEXT_HOP are well-known mandatory attributes and MUST be present in every UPDATE message that contains NLRI. All implementations MUST recognize all well-known attributes.
The Hold Time MUST be either zero or at least three seconds. Upon receipt of an OPEN message, the BGP speaker MUST calculate the Hold Time as the smaller of its configured value and the received value. An implementation MUST reject Hold Time values of one or two seconds.
The Marker field in every message header MUST be set to all ones. If the received Marker is not all ones, the Error Subcode MUST be set to Connection Not Synchronized and a NOTIFICATION sent.
The MULTI_EXIT_DISC attribute received from a neighboring AS MUST NOT be propagated to other neighboring ASes. A BGP speaker MUST implement a mechanism to remove MED from a route before the Decision Process phases 1 and 2.
The NEXT_HOP attribute MUST NOT be set to the IP address of the receiving speaker, and a BGP speaker SHALL NOT install a route with itself as the next hop. The NEXT_HOP MUST be resolvable via the local Routing Table.
Unrecognized transitive optional attributes SHOULD be accepted; when passed to other peers they MUST be forwarded with the Partial bit set to 1. Once the Partial bit is set to 1 by a previous AS, it MUST NOT be reset to 0. Unrecognized non-transitive optional attributes MUST be quietly ignored.
When advertising a route to an external peer, the BGP speaker MUST prepend its own AS number to the AS_PATH attribute. When advertising to an internal peer, the speaker SHALL NOT modify the AS_PATH.
When connection collision occurs, one connection MUST be closed. The connection initiated by the BGP speaker with the higher-valued BGP Identifier (treated as a 4-octet unsigned integer in host byte order) is retained.
BGP uses TCP (port 179) as its transport, relying on TCP for fragmentation, retransmission, acknowledgement, and sequencing. BGP assumes TCP supports graceful close so all outstanding data is delivered before the connection closes.
Path attributes fall into four categories: (1) well-known mandatory — must be in every NLRI-bearing UPDATE; (2) well-known discretionary — may or may not be sent; (3) optional transitive — forwarded to other ASes with Partial bit logic; (4) optional non-transitive — not forwarded beyond the receiving AS.
The BGP Decision Process operates in three phases: Phase 1 calculates degree of preference for each route in Adj-RIBs-In, Phase 2 selects the best route to each destination for the Loc-RIB (with tie-breaking rules), and Phase 3 disseminates selected routes to peers via Adj-RIBs-Out.
The BGP Routing Information Base (RIB) consists of three logical parts: Adj-RIBs-In (unprocessed inbound routes from peers), Loc-RIB (routes selected by the local Decision Process), and Adj-RIBs-Out (routes selected for advertisement to specific peers). Implementations are not required to maintain three physical copies.
IANA maintains registries for BGP message types (1=OPEN, 2=UPDATE, 3=NOTIFICATION, 4=KEEPALIVE), NOTIFICATION error codes (1–6), and their associated error subcodes as defined in Sections 4.5 and 6. New values require IANA action.
BGP-4 itself does not provide authentication of routing information. An attacker who can inject or alter BGP messages can cause incorrect routing, including traffic attraction, black-holing, or routing loops. The document notes that TCP MD5 authentication (RFC 2385) should be used to protect BGP sessions against spoofed RST segments and injected data.
BGP speakers should apply input filtering (policy) to routes received from peers to prevent acceptance of bogus routes such as prefixes not owned by the peer's AS. Absence of such filtering enables route hijacking and mis-origination attacks.
The BGP FSM defines six states: Idle, Connect, Active, OpenSent, OpenConfirm, and Established. Mandatory session attributes include State, ConnectRetryCounter, ConnectRetryTimer/Time, HoldTimer/Time, and KeepaliveTimer/Time. Transitions are driven by administrative events, timer events, TCP connection events, and BGP message events.
Each path attribute is encoded as: Attribute Flags (1 octet), Attribute Type Code (1 octet), Length (1 octet, or 2 octets when the Extended Length bit is set), and Value. Bits 0–3 of the Flags octet carry Optional, Transitive, Partial, and Extended-Length flags; bits 4–7 MUST be zero on send and ignored on receive.
Every BGP message begins with a fixed 19-octet header: a 16-octet Marker (all ones), a 2-octet unsigned Length (19–4096), and a 1-octet Type code (1=OPEN, 2=UPDATE, 3=NOTIFICATION, 4=KEEPALIVE). All multi-octet fields are in network byte order.
IP address prefixes in NLRI and Withdrawn Routes are encoded as <Length (1 octet, in bits), Prefix (variable, padded with trailing bits to an octet boundary)>. A Length of zero matches all addresses and carries zero prefix octets.
The NOTIFICATION message appends Error Code (1 octet) and Error Subcode (1 octet) plus a variable Data field to the standard header; minimum length is 21 octets. Data length equals message length minus 21.
The OPEN message carries: Version (1 octet, must be 4), My Autonomous System (2 octets), Hold Time (2 octets), BGP Identifier (4 octets), Optional Parameters Length (1 octet), and variable-length Optional Parameters encoded as Type-Length-Value triplets. Minimum length is 29 octets.
The UPDATE message contains: Withdrawn Routes Length (2 octets), Withdrawn Routes (variable, <length,prefix> tuples), Total Path Attribute Length (2 octets), Path Attributes (variable), and NLRI (variable). NLRI length is derived as: message length − 23 − path attr length − withdrawn routes length. Minimum size is 23 octets.