A Border Gateway Protocol 4 (BGP-4)
obsoleted by
- rfc-1771 — A Border Gateway Protocol 4 (BGP-4)
Extracted elements (30)
BGP-4 eliminates the concept of network 'class' and supports advertising IP prefixes (CIDR), along with AS path aggregation, to address the Internet's scaling problems with classful routing and to support the proposed supernetting scheme.
BGP enforces the 'hop-by-hop' routing paradigm: a speaker advertises only routes it itself uses. This means policies requiring source routing (e.g., directing traffic through a specific third AS) cannot be expressed in BGP.
BGP runs over TCP (port 179) rather than implementing its own reliable transport, eliminating the need for explicit update fragmentation, retransmission, acknowledgement, and sequencing. TCP's graceful close guarantee is relied upon to deliver all outstanding data before connection teardown.
BGP speakers negotiate protocol version by attempting connections starting with the highest supported version. If the peer responds with NOTIFICATION Error Code OPEN Message Error / Unsupported Version Number, the data field contains the highest version the peer supports, enabling rapid convergence to the highest common version.
A BGP speaker must never advertise a peer's own address back to that peer as a NEXT_HOP for an originated route, and must never install a route with itself as the next hop.
A BGP speaker that receives a route with the ATOMIC_AGGREGATE attribute shall not remove it and shall not make any NLRI of that route more specific when advertising to other speakers.
All BGP implementations MUST support the maximum message size of 4096 octets. The Length field must always be at least 19 and no greater than 4096, with no padding after the message.
For a peer previously transitioned to Idle due to an error, automatic Start events shall use exponential backoff: initial interval 60 seconds, doubled for each consecutive retry, to prevent persistent route flapping.
If a BGP route's NEXT_HOP attribute depicts an address to which the local BGP speaker has no route in its Loc-RIB, the route SHOULD be excluded from the Phase 2 decision function.
If a system does not receive successive KEEPALIVE, UPDATE, or NOTIFICATION messages within the Hold Time period, it must send a NOTIFICATION with Error Code Hold Timer Expired and close the BGP connection.
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. A reasonable maximum interval between KEEPALIVEs is one-third of the Hold Time.
LOCAL_PREF shall be included in all UPDATE messages sent to internal BGP peers but shall not be included in UPDATE messages sent to external BGP speakers. If received from an external peer, LOCAL_PREF shall be ignored.
Unrecognized non-transitive optional attributes must be quietly ignored and not passed along. Unrecognized transitive optional attributes must be accepted and forwarded with the Partial bit set to 1.
Upon receipt of an OPEN message, a BGP speaker MUST calculate the Hold Timer value as the smaller of its configured Hold Time and the received Hold Time. The Hold Time MUST be either zero or at least three seconds; implementations MUST reject values of one or two seconds.
When advertising a route to an external BGP speaker, the advertising speaker shall prepend its own AS number to the AS_PATH: if the first segment is AS_SEQUENCE it prepends to that segment; if AS_SET, it prepends a new AS_SEQUENCE segment containing its own AS.
When connection collision occurs (two simultaneous TCP connections between peers), the connection initiated by the peer with the higher-valued BGP Identifier is retained; the other is closed with a NOTIFICATION Cease. A collision with an Established connection unconditionally closes the new connection.
AGGREGATOR (Type Code 7) is an optional transitive 6-octet attribute containing the last AS that formed the aggregate (2 octets) and its IP address (4 octets). It is attached by a BGP speaker performing route aggregation.
AS_PATH (Type Code 2) is a well-known mandatory attribute consisting of AS path segments, each a triple <segment type (1=AS_SET, 2=AS_SEQUENCE), segment length, segment value>. AS numbers are 2 octets each. It identifies all ASes a route has traversed.
MULTI_EXIT_DISC (Type Code 4) is an optional non-transitive 4-octet unsigned integer used to discriminate among multiple exit/entry points to the same neighboring AS. Lower metric is preferred. It may propagate over internal links but never to neighboring ASes.
ORIGIN (Type Code 1) is a well-known mandatory attribute encoding the origin of path information: 0=IGP, 1=EGP, 2=INCOMPLETE. It is generated by the originating AS and included in all UPDATE messages propagating that information.
Phase 2 tie-breaking first considers MULTI_EXIT_DISC (lowest wins, if configured), then lowest IGP interior distance to NEXT_HOP, then lowest BGP Identifier among advertising external peers, then lowest BGP Identifier overall.
The BGP Routing Information Base (RIB) comprises three parts: Adj-RIBs-In (unprocessed routes from peers), Loc-RIB (routes selected by local Decision Process), and Adj-RIBs-Out (routes selected for advertisement to peers). Implementations are not required to maintain three separate copies.
The Decision Process runs in three sequential phases: Phase 1 calculates degree of preference for external routes and advertises best to internal peers; Phase 2 selects the best route per destination and installs it in the Loc-RIB; Phase 3 disseminates Loc-RIB routes to external peers with optional aggregation.
The 16-octet Marker field in every BGP message header can authenticate incoming messages: when Authentication Code is zero all bits must be one; with non-zero authentication codes, the Marker value is computed by the specified authentication algorithm to detect loss of synchronization and authenticate peers. A separate transport-level authentication mechanism may also be used.
The BGP FSM has six states: Idle (refuses all connections), Connect (waiting for TCP to complete), Active (trying to acquire peer), OpenSent (waiting for OPEN), OpenConfirm (waiting for KEEPALIVE), and Established (full operation). Transitions are triggered by TCP events, received messages, timers (ConnectRetry, Hold, KeepAlive), and operator Start/Stop events.
Every BGP message begins with a fixed 19-octet header: a 16-octet Marker (all-ones when no authentication or when type is OPEN), a 2-octet unsigned Length (19–4096), and a 1-octet Type (1=OPEN, 2=UPDATE, 3=NOTIFICATION, 4=KEEPALIVE).
Path attribute type is a 2-octet field: Attribute Flags octet (bit 0=Optional, bit 1=Transitive, bit 2=Partial, bit 3=Extended Length, bits 4–7 unused/zero) followed by Attribute Type Code octet. Extended Length flag selects 1- or 2-octet attribute length.
The NOTIFICATION message carries a 1-octet Error Code, 1-octet Error Subcode, and variable Data field. Minimum length is 21 octets including header. Six error codes are defined (Message Header, OPEN, UPDATE, Hold Timer Expired, FSM Error, Cease).
The OPEN message carries: 1-octet Version (currently 4), 2-octet My Autonomous System, 2-octet Hold Time, 4-octet BGP Identifier, 1-octet Authentication Code, and variable-length Authentication Data. Minimum length is 29 octets including header.
The UPDATE message contains: 2-octet Unfeasible Routes Length, variable Withdrawn Routes (list of <length, prefix> 2-tuples), 2-octet Total Path Attribute Length, variable Path Attributes, and variable NLRI. Minimum length is 23 octets.