Exterior Gateway Protocol
The Exterior Gateway Protocol (EGP) is a distance-vector routing protocol designed to exchange network reachability information between gateways in different autonomous systems (ASes) on the early Internet, enabling inter-AS routing through periodic polling mechanisms such as Hello/I-Heard-You and Poll/Update messages.[1] Developed in 1984 as part of the DARPA Internet program, EGP facilitated the connection of separate ASes by assuming a tree-structured topology and using hop counts to advertise reachable networks, but it was limited to reliable neighbor communications and did not support policy-based routing or loop detection beyond basic measures.[1] EGP was gradually superseded by the Border Gateway Protocol (BGP), introduced in 1989, due to the Internet's growth and the need for more scalable, policy-driven interdomain routing, with EGP continuing in use until the mid-1990s.[2] EGP's core procedures include neighbor acquisition via Request/Confirm handshakes to establish relationships, neighbor reachability monitoring through timed exchanges to detect failures, and network reachability updates that propagate lists of accessible networks with associated metrics.[1] It operates using IP protocol number 8 for message delivery and required gateways to poll core systems for external routing information in a hierarchical model.[1] Key assumptions, such as a fixed core AS and non-comparable hop metrics across systems, reflected the constrained ARPANET-era environment but proved inadequate for the decentralized, multi-homed topologies that emerged later.[1] Although EGP played a pivotal role in the transition from ARPANET to the modern Internet by introducing the AS concept for administrative domain separation, its rigid structure and lack of support for path attributes contributed to its deprecation in favor of BGP, which built directly on EGP's lessons to enable robust, scalable global routing.[2] Today, EGP is primarily of historical interest, with no active deployments in production networks, underscoring the evolution of Internet routing protocols toward greater flexibility and security.[2]Overview
Definition and Purpose
The Exterior Gateway Protocol (EGP) is the first standardized protocol designed for exchanging routing information between autonomous systems (ASes) on the Internet, where an AS represents a group of networks under a single administrative authority.[3] Developed to support inter-domain routing, EGP enables gateways to advertise network reachability to exterior neighbors, facilitating communication across distinct administrative boundaries without relying on a unified routing policy.[4] Unlike interior gateway protocols (IGPs), which handle routing within a single AS, EGP focuses exclusively on exterior interactions to maintain scalability in a multi-domain environment.[3] The primary purpose of EGP is to allow separate networks, such as those connected via ARPANET gateways, to route traffic efficiently without assuming a common administrative domain, thereby enabling the scalable interconnection of early Internet components in the 1980s.[5] By providing a mechanism for gateways to periodically poll each other for reachability updates, EGP ensures reliable propagation of routing data while controlling overhead through a controlled exchange process.[4] This addressed the limitations of prior ad-hoc routing methods, which lacked standardization and struggled with the growing complexity of inter-network connections.[4] EGP operates at the network layer (OSI layer 3) within the TCP/IP protocol suite, specifically tailored for gateway-to-gateway roles in a core-periphery topology, where core gateways form the backbone and peripheral stubs connect to it.[5] Introduced initially in 1982 via RFC 827 as a draft proposal, it was refined in the "STUB" version through RFC 888 in January 1984 to support stub-to-core connections, with a comprehensive formal specification provided in RFC 904 in April 1984 to standardize its use across Internet gateways.[3][5][4]Key Characteristics
The Exterior Gateway Protocol (EGP) employs a distance-vector routing approach, where gateways exchange vectors containing distance metrics—primarily hop counts—to destinations within their autonomous systems, enabling the receiving gateway to compute reachability based on these metrics.[6] Unlike pure distance-vector protocols, EGP incorporates limited path awareness through autonomous system (AS) identifiers but does not transmit full AS paths; instead, it prevents routing loops by assuming a tree-structured topology with no cycles among ASes.[7] This design choice prioritizes simplicity in exchanging inter-AS reachability information over comprehensive loop detection mechanisms found in later protocols.[6] EGP supports AS numbers by requiring each gateway to include a 16-bit AS identifier in message headers and update payloads, allowing boundary gateways to apply policy-based filtering and decisions based on the originating AS.[8] For instance, a gateway advertises routes tagged with its own AS number, facilitating controlled propagation across AS boundaries without revealing internal topologies.[6] This feature was essential for the early Internet's administrative segmentation into ASes, though it lacked the advanced path attributes of subsequent protocols. Reliability in EGP is achieved without a transport-layer protocol like TCP; instead, it operates directly over IP using protocol number 8, with built-in checksums for message integrity and a time-to-live value typically set to 1 for single-hop communication between neighbors.[9] Liveness detection relies on periodic Hello messages exchanged during neighbor acquisition and maintenance, supplemented by I-Heard-You (I-H-U) acknowledgments to confirm bidirectional reachability.[6] Update solicitations use Poll messages with configurable intervals and retransmission attempts (up to a maximum before declaring failure), ensuring reliable delivery in the absence of connection-oriented transport.[6] EGP's design assumes a hierarchical topology, such as the NSFNET backbone as the central core with peripheral ASes connecting in a non-cyclic, tree-like fashion, which limits its scalability to sparse peering arrangements rather than dense, full-mesh interconnections.[7] Updates follow a polling-based model, where a gateway explicitly requests route information via Poll commands rather than broadcasting unsolicited floods, thereby minimizing bandwidth overhead in these constrained, hierarchical environments.[6] Message types like Hello for neighbor establishment and Update for conveying route vectors exemplify this controlled exchange.[6] Due to these topology-specific limitations, EGP was eventually superseded by path-vector protocols such as BGP, which better accommodate arbitrary inter-AS connectivity.[9]History
Development and Standardization
The Exterior Gateway Protocol (EGP) originated in the early 1980s as part of efforts by the DARPA community to manage the expanding complexity of the internet, particularly during the transition from the Network Control Protocol (NCP) to TCP/IP on the ARPANET. Developed primarily by engineers at Bolt, Beranek and Newman (BBN), EGP was designed to replace informal and unstructured gateway procedures, such as those using the Gateway-to-Gateway Protocol (GGP), with a standardized mechanism for exchanging network reachability information between autonomous systems (ASes). The protocol's initial focus was on connecting stub gateways to core gateways in networks like ARPANET and SATNET, enabling the use of multiple ASes as transport media while preserving a uniform internet address space.[9] This development gained urgency following the administrative split of ARPANET into a civilian ARPANET and the military-focused MILNET on October 1, 1983, which created distinct ASes requiring interoperable routing amid growing multi-vendor network environments. The transition to TCP/IP on January 1, 1983 (known as Flag Day), further highlighted the need for a dedicated exterior protocol to handle inter-AS communication without assuming a single routing algorithm. Key contributors included Eric C. Rosen at BBN, who authored the initial proposal, along with collaborators like Linda J. Seamonson and D.L. Mills, who refined the specifications in response to these challenges.[10][9][11][1] The protocol's standardization progressed through several seminal RFCs published by the Network Working Group, precursors to the Internet Engineering Task Force (IETF). RFC 827 (October 1982) provided the first description of EGP, outlining basic procedures for gateway-to-gateway exchanges. This was extended in RFC 888 (January 1984), which specified the "STUB" variant for connecting peripheral gateways to a core AS. The formal specification arrived in RFC 904 (April 1984), authored by D.L. Mills, which defined a state-machine model (including Idle, Acquisition, Up, and Cease states), message types, and polling mechanisms, updating prior RFCs for official DARPA use. Further clarifications came in RFC 1092 (February 1989) by Yakov Rekhter, addressing policy-based routing applications.[9][11][1][12] EGP's standardization aligned closely with the deployment of the National Science Foundation Network (NSFNET) between 1985 and 1986, where it facilitated interoperability between civilian academic networks and the separated MILNET/ARPANET infrastructure by enabling controlled reachability announcements across AS boundaries. However, the initial versions of EGP lacked robust mechanisms for loop prevention, relying instead on an assumed hierarchical, spanning-tree topology among core gateways to avoid cycles; this limitation was partially mitigated in later implementations through fixed metrics and bilateral policies, as noted in NSFNET contexts, but inherent vulnerabilities to backdoor routes and false advertisements persisted. EGP functioned as a foundational exterior protocol for inter-AS connectivity but was ultimately superseded by the Border Gateway Protocol (BGP) in RFC 1105 (September 1989).[12][10]Adoption in Early Internet
The Exterior Gateway Protocol (EGP) was initially deployed in 1985 to facilitate interconnections for the National Science Foundation Network (NSFNET), marking its practical adoption in the burgeoning Internet infrastructure as specified in RFC 827 (1982).[9] This deployment supported the NSFNET's Phase I backbone, operating at 56 kbps speeds to link supercomputer centers and regional networks, thereby enabling coordinated routing across diverse autonomous systems.[13] By 1988, EGP had connected over 100 gateways, including key implementations from Bolt Beranek and Newman (BBN) and SRI International, which played pivotal roles in managing inter-domain traffic.[14] EGP was used for routing to maintain connectivity following the ARPANET-MILNET split in 1983-1984, exchanging reachability information between the research-oriented ARPANET and the military-focused MILNET, ensuring seamless separation while maintaining connectivity through core gateways.[15] In the NSFNET context, gateways like those operated by BBN handled exterior routing to integrate with legacy ARPANET components, fostering the Internet's expansion beyond U.S. Department of Defense networks.[16] At its peak around 1990, EGP supported routing for approximately 2,500 networks amid explosive growth, with the number of connected networks rising from about 650 in 1989 to over 2,000 by 1990, though this scale began straining the protocol's distance-vector mechanisms and topology restrictions.[17] EGP enabled early transatlantic Internet links, such as connections to European networks in 1988-1989, leveraging satellite and emerging fiber infrastructure like TAT-8 to extend reachability across continents.[10] The protocol's phase-out accelerated with the rollout of the Border Gateway Protocol (BGP) in 1994, which addressed EGP's limitations in handling policy-based routing and larger topologies; EGP's last major deployment ended with the NSFNET backbone shutdown on April 30, 1995.[13] This transition marked the end of EGP's dominance in inter-domain routing during the Internet's formative expansion.Protocol Operation
Neighbor Relationships
In the Exterior Gateway Protocol (EGP), neighbor relationships are established and maintained between gateways in adjacent autonomous systems (ASes) to enable the exchange of routing information across AS boundaries. The process initiates with neighbor acquisition, where a gateway sends an Acquisition Request message to propose adjacency with a potential neighbor, with its AS number specified in the message header. If accepted, the neighbor responds with a Confirm message, initializing parameters such as hello and poll intervals, thereby establishing the adjacency. This acquisition phase ensures that only gateways with valid AS identifiers can form relationships.[1] EGP neighbor relationships progress through distinct states: Idle (no resources allocated, awaiting initiation), Acquisition (requesting and confirming adjacency), Up (active exchange of messages), Down (reachability lost but reacquisition possible), and Cease (terminating the relationship). State transitions are event-driven; for instance, a Start event moves from Idle to Acquisition, triggering the Request message, while receipt of a Confirm advances to Down for reachability testing before entering Up. A Stop event or prolonged unreachability prompts a shift to Cease, followed by a Cease-ack to return to Idle, ensuring orderly lifecycle management.[1] Gateways operate in one of two modes to handle communication asymmetry: active or passive. In active mode, the initiating gateway periodically sends Hello and Poll messages to probe liveness and solicit updates, suitable for core gateways that drive interactions. Passive mode, used by peripheral gateways, involves responding to incoming messages without initiation, relying on the active peer's probes; mode selection is predefined based on network topology, with active gateways using stricter reachability thresholds (e.g., j=3 successive confirmations for up state). This division optimizes resource use in hierarchical Internet structures.[1] Neighbor liveness is monitored differently by mode. In active mode, it uses periodic Hello and I-Heard-You (I-H-U) exchanges, with a minimum Hello interval of 30 seconds to balance overhead and responsiveness. In passive mode, liveness is determined using the Status field in received Hello or Poll messages and in sent Update messages, without sending Hello or I-H-U. The protocol recommends a monitoring window (T3) of approximately four times the Hello interval, adjusting thresholds by mode (j=3 and k=1 for active, j=1 and k=4 for passive; where j is successive confirmations to enter Up state, k is consecutive misses to detect failure and trigger Down or Cease). If the number of consecutive missed confirmations exceeds the mode-specific threshold k (1 for active, 4 for passive), the gateway detects failure, sends a Cease message, and transitions accordingly, preventing stale routing data propagation.[1] EGP includes a sequence number in each message header for verifying order and a checksum for data integrity, but lacks any authentication or replay protection mechanisms. These elements provide basic checks during acquisition and ongoing communication, though they offer limited protection against attacks.[1]Message Types and Formats
The Exterior Gateway Protocol (EGP) employs a fixed 10-octet common header for all messages, consisting of the following fields: EGP Version Number (1 octet, value 2 for the current version), Type (1 octet, indicating the message category), Code (1 octet, specifying the subtype within the type), Status (1 octet, providing message-dependent status information such as up/down for reachability), Checksum (2 octets, a 16-bit one's complement of the entire message starting from the version field, computed with the checksum field zeroed), Autonomous System Number (2 octets, identifying the sender's AS), and Sequence Number (2 octets, used for ordering commands and responses).[18] EGP defines five primary message types, each with specific codes and variable additional fields following the header, to manage neighbor relationships, liveness detection, and route exchanges. These are transported directly over IP using protocol number 8, with all communications conducted via unicast datagrams and no support for multicast.[1]| Type | Message Type | Code | Purpose and Key Fields |
|---|---|---|---|
| 1 | Update | 0 | Conveys routing information; includes number of interior gateways, number of exterior gateways, IP source network (4 octets), lists of interior and exterior gateway IP addresses (4 octets each), corresponding distances (1 octet each, values 0-15 indicate hop counts with 0 for direct connections, 255 denotes unreachable), number of networks, and list of network addresses (4 octets each) with their distances. |
| 2 | Poll | 0 | Requests an Update from a neighbor; includes IP source network (4 octets). |
| 3 | Acquisition | 0 (Request) | Establishes adjacency; includes Hello interval (2 octets) and Poll interval (2 octets). |
| 3 | Acquisition | 1 (Confirmation) | Acknowledges adjacency establishment; includes Hello and Poll intervals. |
| 3 | Acquisition | 2 (Refusal) | Rejects adjacency; no additional fields. |
| 3 | Acquisition | 3 (Cease) | Terminates adjacency; no additional fields. |
| 3 | Acquisition | 4 (Cease Acknowledgment) | Acknowledges termination; no additional fields. |
| 5 | Hello | 0 | Indicates liveness (up status); no additional fields. |
| 5 | I-Heard-You (I-H-U) | 1 | Response to Hello, confirming liveness; no additional fields. |
| 8 | Error | 0 | Reports protocol errors; includes reason code (1 octet, e.g., 0 for unspecified) and the header of the erroneous message. |