BGP and the Routing Protocol That Holds the Internet Together
Kirk Lougheed and Yakov Rekhter's Border Gateway Protocol replaced EGP with a path-vector system for exchanging reachability between autonomous networks, becoming the Internet's interdomain routing foundation.
Internet growth broke the assumptions of the old exterior routing model
The early Internet relied on the Exterior Gateway Protocol to exchange reachability around a relatively centralized backbone architecture. As NSFNET, regional networks and commercial providers expanded, that model could not express the growing number of independent routing domains and policies.
RFC 1105, published in June 1989 by Kirk Lougheed of Cisco and Yakov Rekhter of IBM, introduced the Border Gateway Protocol as an inter-autonomous-system routing protocol.[1]
The Internet was becoming a network of networks in an organizational sense
Different operators needed to make their own decisions about which routes to accept, advertise and prefer. Routing therefore had to represent administrative boundaries, not only shortest paths.
BGP exchanged reachability together with an autonomous-system path
A BGP advertisement says not only that a destination can be reached but also which autonomous systems the route has traversed. This path information helps prevent routing loops and provides input to policy decisions.
The original specification explicitly framed BGP as a mechanism for exchanging network reachability among autonomous systems.[1]
Path vector differs from simple distance metrics
A route can be rejected because its AS path violates policy even if the path appears numerically short. BGP therefore treats routing as a combination of topology and administration.
The protocol was deployed while NSFNET was still rapidly expanding
NSFNET’s historical timeline records the first deployment of BGP for inter-network routing in August 1989, only months after RFC 1105.[2] The backbone was already connecting a growing hierarchy of regional networks and other federal and international systems.
BGP gave those independently managed networks a more scalable method for exchanging routes than the earlier core-gateway model.
Operational deployment drove protocol evolution
Internet routing is too interconnected to perfect entirely in a laboratory. Early BGP versions changed quickly as operators discovered scaling, policy and implementation requirements.
BGP-4 added classless routing and became the enduring version
Later revisions culminated in BGP-4, standardized in RFC 1771 and eventually replaced by the current core specification, RFC 4271. Classless Inter-Domain Routing allowed prefixes of arbitrary length rather than fixed network classes.
RFC 4271 describes BGP as an inter-autonomous-system routing protocol whose primary function is exchanging network reachability information together with AS path data.[3]
CIDR helped slow routing-table and address-space growth
Aggregating many networks into larger prefixes reduced the number of routes that had to be carried globally, though routing-table growth remained an ongoing operational challenge.
BGP is fundamentally a policy protocol
Operators use attributes, filters and local preferences to decide which routes to select and propagate. Business relationships such as customer, provider and peer arrangements can shape routing as strongly as geographic distance.
This policy freedom is one reason BGP scaled across organizations that do not share one central authority.
The same flexibility creates security and reliability risks
A mistaken or malicious route advertisement can attract traffic to the wrong network. Because classic BGP largely assumes that neighboring networks will announce legitimate reachability, route leaks and prefix hijacks have become recurring Internet incidents.
RFC 7454 documents operational security practices for BGP, including filtering and policies intended to reduce these risks.[4]
Internet routing security has been added incrementally rather than by replacing BGP
Resource Public Key Infrastructure and route-origin validation let operators verify whether an autonomous system is authorized to originate a prefix. Other proposals aim to protect the complete AS path.
The persistence of BGP demonstrates how difficult it is to replace a protocol embedded in thousands of independently managed networks.
Why BGP belongs in the core history of networking
BGP made global Internet routing compatible with decentralized administration. Its AS-path model, route advertisements and policy mechanisms let independent networks cooperate without surrendering control to a single central router.[1][5]
The protocol’s weaknesses are equally instructive. The Internet’s routing system works because organizations exchange enough trust and policy information to remain connected, and it fails conspicuously when that trust is misplaced. BGP is therefore both a technical protocol and an expression of the Internet’s decentralized governance.
BGP’s policy model also reflects the economics of the Internet. Two networks may exchange routes differently depending on whether one pays the other for transit or whether they peer as roughly equal partners. The protocol does not encode those business categories directly; instead, operators translate commercial relationships into import and export rules. This means the global route graph is partly an economic artifact. A route that is technically reachable may not be advertised because the relationship between networks makes carrying that traffic undesirable. Interdomain routing therefore cannot be understood through graph theory alone.
The protocol’s success is therefore inseparable from its conservatism. Changes that might improve elegance must be weighed against the risk of destabilizing global reachability, so the routing system evolves through incremental extensions and operational safeguards.
Operationally, BGP also forced network engineers to think in terms of failure containment. A bad route from one autonomous system can propagate to many others if filters and policies accept it unquestioningly. This is why route monitoring, prefix filters, maximum-prefix limits and origin validation became part of normal Internet operations. The protocol itself deliberately leaves much policy to operators, so safe deployment depends on institutional competence as much as correct software. That makes BGP unusual compared with protocols that can be understood mostly from packet formats. Its real behavior emerges from thousands of locally configured policies interacting globally. The resulting Internet is neither centrally planned nor purely automatic: it is a negotiated routing system in which technical mechanisms, business agreements and human operational practices jointly determine where traffic flows.
Works Cited
- 01RFC 1105 — A Border Gateway Protocol (BGP) rfc-editor.org
- 02
- 03RFC 4271 — A Border Gateway Protocol 4 (BGP-4) rfc-editor.org
- 04RFC 7454 — BGP Operations and Security rfc-editor.org
- 05Internet Society — Border Gateway Protocol and Internet Routing internetsociety.org
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.
Submit a research lead