A Border Gateway Protocol 4 (BGP-4)
obsoleted by
- rfc-4271 — A Border Gateway Protocol 4 (BGP-4)
obsoletes
- rfc-1654 — A Border Gateway Protocol 4 (BGP-4)
Extracted elements (31)
BGP-4 eliminates the concept of network 'class' from BGP, introduces IP prefix advertisement and classless interdomain routing (CIDR), and adds mechanisms for route aggregation including AS path aggregation, enabling the supernetting scheme described in the companion documents.
BGP enforces only hop-by-hop routing policies: a speaker advertises to neighboring ASes only routes it itself uses. Policies that require traffic to take a different path than what the neighboring AS would normally use (requiring source routing) cannot be supported by 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 is present in virtually all commercial routers and hosts, and any TCP authentication scheme is available in addition to BGP's own authentication.
BGP version negotiation uses repeated OPEN attempts starting at the highest supported version. If an OPEN fails with OPEN Message Error / Unsupported Version Number, the NOTIFICATION data contains a 2-octet unsigned integer indicating the largest version the remote peer supports that is less than the version attempted, allowing rapid convergence to a common version. Future BGP versions must retain the OPEN and NOTIFICATION message formats to support this mechanism.
A BGP speaker must retain the current version of the entire BGP routing tables of all its peers for the duration of the connection, because BGP does not require periodic full-table refresh.
All BGP messages must be no larger than 4096 octets and no smaller than 19 octets. All implementations are required to support the maximum message size of 4096 octets.
An UPDATE message may advertise at most one feasible route (described by one set of path attributes and one NLRI field) but may simultaneously withdraw multiple unfeasible routes. The same attribute type code must not appear more than once in a single UPDATE.
Connection collision resolution: when two simultaneous TCP connections form between the same BGP speaker pair, the connection initiated by the speaker with the higher-valued BGP Identifier is retained; the other is closed with a Cease NOTIFICATION. A collision with an Established connection unconditionally closes the newly created one.
For a peer previously transitioned to Idle due to an error, automatically generated Start events SHALL use exponential backoff: initial timer is 60 seconds, doubling on each consecutive retry, to prevent persistent connection flapping.
If NEXT_HOP is semantically incorrect on an external link (not on a common subnet with the local speaker, or equals the receiving speaker's own address), the error SHOULD be logged and the route silently ignored; no NOTIFICATION message should be sent.
If no KEEPALIVE, UPDATE, or NOTIFICATION is received within the Hold Time period, a NOTIFICATION with Error Code Hold Timer Expired must be sent and the BGP connection must be closed.
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 inter-KEEPALIVE interval is one-third of the Hold Time.
Phase 2 of the Decision Process MUST perform an IGP lookup to resolve the NEXT_HOP attribute address to an immediate next hop, and MUST install that immediate next hop in the Loc-RIB. If the IGP path to NEXT_HOP changes, route selection should be recalculated.
Unrecognized transitive optional attributes must be forwarded with the Partial bit set to 1. Unrecognized non-transitive optional attributes must be quietly ignored and not passed along to other BGP peers.
Upon receipt of an OPEN message a BGP speaker MUST set the Hold Timer to the smaller of its configured Hold Time and the Hold Time in the OPEN message. Hold Time MUST be either zero or at least three seconds; values of one or two seconds MUST be rejected with an Unacceptable Hold Time error.
AS_PATH (Type Code 2) is a well-known mandatory attribute identifying all ASes the route has traversed. When advertising externally, a speaker prepends its own AS number; when advertising internally, AS_PATH is not modified. An originator sends its own AS in the AS_PATH to external peers and an empty AS_PATH to internal peers.
ATOMIC_AGGREGATE (Type Code 6) is a well-known discretionary zero-length attribute signaling that a less-specific route was selected over a more-specific one. A receiver must not remove this attribute when forwarding and must not de-aggregate the NLRI.
LOCAL_PREF (Type Code 5) is a well-known discretionary 4-octet attribute conveying intra-AS route preference; higher value is preferred. It must be included in all internal UPDATE messages and must not be sent to external BGP peers; if received from an external peer it shall be ignored.
MULTI_EXIT_DISC (Type Code 4) is an optional non-transitive 4-octet unsigned metric for discriminating among multiple exit/entry points to the same neighboring AS. Lower metric is preferred. It may be propagated to internal BGP speakers within the same AS but is never propagated to neighboring ASes.
NEXT_HOP (Type Code 3) is a well-known mandatory attribute holding the IP address of the border router to use as next hop. A speaker must never advertise a peer's own address as NEXT_HOP for an originated route, and must never install a route with itself as next hop.
ORIGIN attribute (Type Code 1) is a well-known mandatory 1-octet attribute: 0=IGP (interior to originating AS), 1=EGP (learned via EGP), 2=INCOMPLETE (learned by other means). Generated by the originating AS and included in all UPDATE messages that propagate the route.
The Routing Information Base has three logical parts: Adj-RIBs-In (unprocessed routes received from peers), Loc-RIB (routes selected by the local Decision Process), and Adj-RIBs-Out (routes selected for advertisement to specific peers). Implementations may use any equivalent internal representation.
BGP provides an Authentication Information optional parameter (Type 1) in the OPEN message, carrying a 1-octet Authentication Code and variable Authentication Data. The authentication specification must define the Authentication Code value, the form of Authentication Data, and the algorithm for computing Marker field values. Transport-level authentication may be used independently.
BGP FSM has six states: Idle (no resources, refuses connections; Start event triggers transition to Connect), Connect (awaiting TCP completion), Active (initiating TCP connection), OpenSent (awaiting OPEN message), OpenConfirm (awaiting KEEPALIVE), Established (full UPDATE/KEEPALIVE/NOTIFICATION exchange). Any unexpected event in most states sends a Finite State Machine Error NOTIFICATION and transitions to Idle.
AGGREGATOR attribute (Type Code 7) is 6 octets: 2-octet last AS that formed the aggregate, followed by 4-octet IP address of the BGP speaker that formed the aggregate.
AS_PATH segments are encoded as <1-octet segment type, 1-octet segment length (count of ASes), variable segment value>. AS_SET=1 (unordered), AS_SEQUENCE=2 (ordered). Each AS number is 2 octets.
BGP message header is 19 octets: a 16-octet Marker (all ones for OPEN or when no authentication is used; otherwise computed per authentication mechanism), a 2-octet unsigned Length (19–4096), and a 1-octet Type (1=OPEN, 2=UPDATE, 3=NOTIFICATION, 4=KEEPALIVE).
NOTIFICATION message fields: 1-octet Error Code, 1-octet Error Subcode, variable Data. Minimum length 21 octets. Data length = MessageLength − 21. Six error codes are defined: Message Header Error (1), OPEN Message Error (2), UPDATE Message Error (3), Hold Timer Expired (4), Finite State Machine Error (5), Cease (6).
OPEN message fields beyond the header: 1-octet Version, 2-octet My Autonomous System, 2-octet Hold Time, 4-octet BGP Identifier, 1-octet Optional Parameters Length, variable Optional Parameters encoded as <Type, Length, Value> triplets. Minimum length 29 octets.
Path Attribute Flags octet (first octet of Attribute Type): bit 0=Optional, bit 1=Transitive, bit 2=Partial (incomplete transitive attribute), bit 3=Extended Length (attribute length field is 2 octets rather than 1). Lower 4 bits unused, must be zero on send and ignored on receipt.
UPDATE message contains: 2-octet Unfeasible Routes Length, variable Withdrawn Routes (each <1-octet prefix-length, variable prefix>), 2-octet Total Path Attribute Length, variable Path Attributes, and variable NLRI (also <length, prefix> tuples). Minimum length 23 octets. NLRI length is derived: UpdateLen − 23 − TotalPathAttrLen − UnfeasibleRoutesLen.