RFC 888

"STUB" Exterior Gateway Protocol

📅 published January 1984, from ietf

RFC 888 ✨ "STUB" EXTERIOR GATEWAY PROTOCOL 🦋

Okay bestie, this is the RFC that defines how a stub gateway plugs into the core Autonomous System. It's giving foundational vibes. 💅

Authors: Linda J. Seamonson and Eric C. Rosen, from BBN Communications. 🎀

Date: January 1984 🌸

Category: This is an ARPA official protocol spec. The note says it "specifies the working protocol" and that all implementers of Gateways should carefully review it. 🫶

Obsoletes and Updates: The title block doesn't list anything here, so there's nothing to obsolete or update. 🌈

The abstract is basically the whole pitch: this note describes the Exterior Gateway Protocol used to connect Stub Gateways to an Autonomous System of core Gateways, and implementers should really read it closely. 🔥

Table of Contents 📋

Here's the map. Each section and appendix lives at the page number listed.

     1   INTRODUCTION.......................................... 1

     2   DEFINITIONS AND OVERVIEW.............................. 4

     3   NEIGHBOR ACQUISITION.................................. 7

     4   NEIGHBOR REACHABILITY PROTOCOL....................... 10

     5   NETWORK REACHABILITY (NR) MESSAGE.................... 15

     6   POLLING FOR NR MESSAGES.............................. 22

     7   SENDING NR MESSAGES.................................. 24

     8   INDIRECT NEIGHBORS................................... 26

     9   LIMITATIONS.......................................... 27

     A   APPENDIX A - EGP MESSAGE FORMATS..................... 28
     A.1   NEIGHBOR ACQUISITION MESSAGE....................... 28
     A.2   NEIGHBOR HELLO/I HEARD YOU MESSAGE................. 30
     A.3   NR POLL MESSAGE.................................... 32
     A.4   NETWORK REACHABILITY MESSAGE....................... 34
     A.5   EGP ERROR MESSAGE.................................. 37

1. INTRODUCTION 🌟

Okay so the DARPA Catenet is expected to keep growing, with more and more hosts on more and more networks joining in. That means more and more gateways. 🌸

Up until now, expansion was pretty chaotic. New gateways, often running totally different software from the existing ones, would get added and immediately start joining the common routing algorithm through the GGP protocol. 🙈 But as the internet gets bigger, this simple approach stops working, and it's not me saying it, it's the reasons below:

the overhead of the routing algorithm becomes excessively large;
the proliferation of radically different gateways participating in a single common routing algorithm makes maintenance and fault isolation nearly impossible, since it becomes impossible to regard the internet as an integrated communications system;
the gateway software and algorithms, especially the routing algorithm, become too rigid and inflexible, since any proposed change must be made in too many different places and by too many different people. 💀

In the future, the internet is expected to split into separate sections, or "autonomous systems." Each one is made of one or more relatively homogeneous gateways. The protocols those gateways use among themselves, especially the routing algorithm, will be a private matter and need never be implemented in gateways outside that section. 🔒✨

In the simplest case, an autonomous system could be just a single gateway connecting, for example, a local network to the ARPANET. That gateway might be called a "stub gateway," since its only job is to interface the local network with the rest of the internet. It's not meant to handle any traffic that neither started in nor is headed for that local network. 🧚

Near-term, we'll start thinking of the internet as a set of autonomous systems. One of them is the DARPA gateways on ARPANET and SATNET, and the others are stub gateways to local networks. We'll call the first one the "core" system, and it'll act as a transport, or "long-haul," system for the rest. 🚀

Ultimately, the internet might have a bunch of co-equal autonomous systems, and any of them could be used as a transport medium for traffic from any system going to any system. That's the more general case, and it's still being researched. 🔬

This note only covers how stub gateways connect to the core system using the Exterior Gateway Protocol (EGP). 🦋

2. DEFINITIONS AND OVERVIEW 📚

For the purposes of this note, a "stub gateway" is defined as follows:

it is not a core gateway
it shares a network with at least one core gateway (has an interface on the same network as some core gateway)
it has interfaces to one or more networks which have no core gateways
all other nets which are reachable from the core system via the stub have no other path to the core system except via the stub

The stub gateway is expected to fully execute the Internet Control Message Protocol (ICMP), as well as the EGP protocol. In particular, it MUST respond to ICMP echo requests, and MUST send ICMP destination dead messages as appropriate. It is also REQUIRED to send ICMP Redirect messages as appropriate. 🎀

Autonomous systems get assigned 16-bit identification numbers (kind of like how network and protocol numbers are assigned now), and every EGP message header has a field for this number. Zero will never be assigned to any autonomous system. Using zero as an autonomous system number is reserved for future use. 🔢

We call two gateways "neighbors" if there's a network that each one has an interface on. If two neighbors are in the same autonomous system, they're called INTERIOR NEIGHBORS. For example, any two core gateways on the same network are interior neighbors of each other. If two neighbors are NOT in the same autonomous system, they're called EXTERIOR NEIGHBORS. For example, a stub gateway and any core gateway that share a network are exterior neighbors. 👯

For one system to use another as a transport medium, gateways that are exterior neighbors MUST be able to find out which networks can be reached through the other. The Exterior Gateway Protocol is what lets that info get passed between exterior neighbors. Since it's a polling protocol, it also lets each gateway control how fast it sends and receives network reachability information, so each system controls its own overhead. And it means each system can have an independent routing algorithm that can't get disrupted by failures in other systems. 💅

The Exterior Gateway Protocol has three parts: (a) the Neighbor Acquisition Protocol, (b) the Neighbor Reachability Protocol, and (c) Network Reachability determination. 🌈

Heads up: all messages defined by EGP are meant to travel only a single "hop." They start at one gateway and go straight to a neighboring gateway, with no intervening gateway involved. So the time-to-live field SHOULD be set to a very small value. Gateways that come across EGP messages in their message streams that aren't addressed to them MAY discard them. ⚠️

Quick aside: the single-hop thing is the whole point of the time-to-live advice, so don't skip it! 🙈

Each EGP message contains a sequence number. The gateway SHOULD maintain one sequence number per neighbor. 🔁

3. NEIGHBOR ACQUISITION 🤝

Before you can get routing info from an exterior gateway, you have to acquire it as a direct neighbor first. (We'll cover the difference between direct and indirect neighbors later.) For two gateways to become direct neighbors, they MUST be neighbors in the sense we defined above, and they MUST run the NEIGHBOR ACQUISITION PROTOCOL. That protocol is basically a standard two-way handshake. 🫶

A gateway that wants to start neighbor acquisition with another one sends it a Neighbor Acquisition Request. This message SHOULD be sent again and again (at a reasonable rate, maybe once every 30 seconds or so) until it gets a Neighbor Acquisition Reply or a Neighbor Acquisition Refusal. The Request carries an identification number that gets copied into the reply, so the request and reply can be matched up. 🔍

When a gateway gets a Neighbor Acquisition Request, it has to decide whether it wants to become a direct neighbor of the Request's source. If not, it MAY, at its option, respond with a Neighbor Acquisition Refusal message, and it can optionally say why. Otherwise, it SHOULD send a Neighbor Acquisition Reply message. ✨

The gateway that sent the Request SHOULD consider the acquisition complete once it has received the neighbor's Reply. The gateway that sent the Reply SHOULD consider the acquisition complete once it has sent the Reply. 🎉

Unmatched Replies or Refusals SHOULD be discarded after a reasonable amount of time. However, info about any unmatched messages may be useful for diagnostics. 🕵️

A Neighbor Acquisition Request from a gateway that's already a direct neighbor SHOULD be answered with a Reply. 🔄

A Neighbor Acquisition Request or Reply going from gateway G to gateway G' carries two minimum intervals, in seconds. The first is the minimum interval at which G is willing to answer Neighbor Reachability Hello Messages from G'. The second is the minimum interval at which G is willing to be polled for NR messages (more on that below). ⏱️

If a gateway wants to stop being a neighbor of a particular exterior gateway, it sends a Neighbor Cease message. A gateway that receives a Neighbor Cease message SHOULD always respond with a Neighbor Cease Acknowledgment. It SHOULD stop treating the sender as a neighbor in any way. 👋

Here's the polite part: since there's a significant amount of protocol running between direct neighbors, if a gateway no longer needs to be a direct neighbor of another, it's "polite" to say so with a Neighbor Cease Message. The Neighbor Cease Message SHOULD be retransmitted (up to some number of times) until an acknowledgment comes back. 💖

Part 1 of 5 done bestie, more parts are coming, so stay tuned! 🧚💜

...the Neighbor Reachability Protocol (below) SHOULD cease to be executed. 💅

4. NEIGHBOR REACHABILITY PROTOCOL 💖

Okay so it's so important for a gateway to keep real-time info on whether its neighbors are actually reachable 🧚 If a gateway decides a neighbor can't be reached, it SHOULD cease forwarding traffic to that gateway. To figure that out we need a NEIGHBOR REACHABILITY protocol, and the EGP protocol gives us two message types for it: a "Hello" message and an "I Heard You" message. 🫶

When a "Hello" comes in from a direct neighbor, an "I Heard You" MUST be returned to that neighbor "immediately" 🔥 The delay between getting a "Hello" and sending back an "I Heard You" SHOULD NEVER be more than a few seconds 💀

Core gateways will use the following algorithm for determining reachability of an exterior neighbor 👑

A reachable neighbor SHALL be declared unreachable if, during the time in which the core gateway sent its last n "Hello"s, it received fewer than k "I Heard You"s in return. An unreachable neighbor SHALL be declared reachable if, during the time in which the core gateway sent its last m "Hello"s, it received at least j "I Heard You"s in return. 🦋

Stub gateways MAY also send "Hello"s to their direct neighbors and receive "I Heard You"s in return. The algorithm for determining reachability MAY be similar to the algorithm described above. However, it is not necessary for stubs to send "Hello"s. The "Hello" and "I Heard You" messages have a status field which the sending gateway uses to indicate whether it thinks the receiving gateway is reachable or not. This information can be useful for diagnostic purposes. It also allows a stub gateway to make its reachability determination parasitic on its core neighbor (yes, that's the real term, I'm not making it up 😭). Only the core gateway actually needs to send "Hello" messages, and the stub can declare it up or down based on the status field in the "Hello". That is, the stub gateway (which sends only "I Heard You"s) declares the core gateway (which sends only "Hello"s) to be reachable when the "Hello"s from the core indicate that it has declared the stub to be reachable. 🌸

The frequency with which the "Hello"s are sent, and the values of the parameters k, n, j, and m cannot be specified here. For best results, this will depend on the characteristics of the neighbor and of the network which the neighbors have in common. THIS IMPLIES THAT THE PROPER PARAMETERS MAY NEED TO BE DETERMINED JOINTLY BY THE DESIGNERS AND IMPLEMENTERS OF THE TWO NEIGHBORING GATEWAYS; choosing algorithms and parameters in isolation, without considering the characteristics of the neighbor and the connecting network, would not be expected to result in optimum reachability determinations. 🙈

However, the Neighbor Acquisition Request and Reply messages give neighbors a way to tell each other the minimum frequency at which they are willing to answer Hellos. When gateway G sends a Neighbor Acquisition Request to gateway G', it states that it does not wish to answer Hellos from G' more frequently than once every X seconds. G' in its Neighbor Acquisition Reply states that it does not wish to answer Hellos from G more frequently than once every Y seconds. The two frequencies do not have to be the same, but each neighbor MUST conform to the interval requested by the other. A gateway MAY send Hellos less frequently than requested, but not more. ⭐

A direct neighbor gateway SHOULD also be declared unreachable if the network connecting it supplies lower level protocol information from which this can be deduced. Thus, for example, if a gateway receives an 1822 Destination Dead message from the ARPANET which indicates that a direct neighbor is dead, it SHOULD declare that neighbor unreachable. The neighbor SHOULD NOT be declared reachable again until the requisite number of Hello/I-Heard-You packets have been exchanged. 💀

A direct neighbor which has become unreachable does not thereby cease to be a direct neighbor. It can be declared reachable again without any need to go through the neighbor acquisition protocol again. However, if the neighbor remains unreachable for an extremely long period of time, such as an hour, the gateway SHOULD cease to treat it as a neighbor, i.e., SHOULD cease sending Hello messages to it. The neighbor acquisition protocol would then need to be repeated before it could become a direct neighbor again. 🍓

"Hello" messages from sources other than direct neighbors SHOULD simply be ignored. However, logging the presence of any such messages might provide useful diagnostic information. 🧚

A gateway which is going down, or whose interface to the network which connects it to a particular neighbor is going down, SHOULD send a Neighbor Cease message to all direct neighbors which will no longer be able to reach it. The Cease message SHOULD use the info field to specify the reason as "going down". It SHOULD retransmit that message (up to some number of times) until it receives a Neighbor Cease Acknowledgment. This gives the neighbors an advance warning of an outage, and lets them prepare for it in a way which will minimize disruption to existing traffic. 🫶

5. NETWORK REACHABILITY (NR) MESSAGE 🌈

Terminology time! Let gateway G have an interface to network N. We say that G is AN APPROPRIATE FIRST HOP to network M relative to network N (where M and N are distinct networks) if and only if the following condition holds:

Traffic which is destined for network M, and which arrives at gateway G over its network N interface, will be forwarded to M by G over a path which does not include any other gateway with an interface to network N. ✨

In short, G is an appropriate first hop for network M relative to network N just in case there is no better gateway on network N through which to route traffic which is destined for network M. For optimal routing, traffic in network N which is destined for network M ought always to be forwarded to a gateway which is an appropriate first hop. 💅

In order for exterior neighbors G and G' (which are neighbors over network N) to be able to use each other as packet switches for forwarding traffic to remote networks, each needs to know the list of networks for which the other is an appropriate first hop. The Exterior Gateway Protocol defines a message, called the Network Reachability Message (or NR message), for transferring this information. 🦋

Let G be a gateway on network N. Then the NR message which G sends about network N MUST contain the following information:

A list of all the networks for which G is an appropriate first hop relative to network N.

If G' can obtain this information from exterior neighbor G, then it knows that no traffic destined for networks which are NOT in that list SHOULD be forwarded to G. (It cannot simply conclude, however, that all traffic for any networks in that list ought to be forwarded via G, since G' may also have other neighbors which are also appropriate first hops to network N. For example, G and G'' might each be neighbors of G', but might be "equidistant" from some network M. Then each could be an appropriate first hop.) 🙈

For each network in the list, the NR message also specifies the "distance" (according to some metric whose definition is left to the designers of the autonomous system of which gateway G is a member) from G to that network. Core gateways will report distances less than 128 for networks that can be reached without leaving the core system, and greater than or equal to 128 otherwise. A stub gateway SHOULD report distances less than 128 for all networks listed in its NR messages. 👑

The maximum value of distance (255.) SHALL be taken to mean that the network is UNREACHABLE. ALL OTHER VALUES WILL BE TAKEN TO MEAN THAT THE NETWORK IS REACHABLE. 🔥

If an NR message from some gateway G fails to mention some network N which was mentioned in the previous NR message from G, it is possible that N has become unreachable from G. If several successive NR messages from G omit mention of N, it SHOULD be taken to mean that N is no longer reachable from G. This procedure is necessary to make sure that networks which can no longer be reached, but which are never explicitly declared unreachable, get timed out and removed from the list of reachable networks. 🍓

It will often be the case that where a core gateway G and a stub gateway G' are direct neighbors on network N, G knows of many more gateway neighbors on network N, and knows for which networks those gateway neighbors are the appropriate first hop. Since the stub G' may not know about all these other neighbors, it is convenient and often more efficient for it to be able to obtain this information from G. Therefore, the EGP NR message also contains fields which allow the core gateway G to specify the following information:

a) A list of all neighbors (both interior and exterior) of G (on network N) which G has reliably determined to be reachable. G MAY also include indirect neighbors in this list (see below.)
b) For each of those neighbors, the list of networks for which that neighbor is an appropriate first hop (relative to network N).

c) For each such <neighbor, network> pair, the "distance" from that neighbor to that network.

Okay so this is the cool part 🫶 The NR message lets a gateway "discover" new neighbors just by checking whether a neighbor it already knows about has any extra neighbors on the same network. ✨ That info also makes the INDIRECT NEIGHBOR strategy possible, which we'll get to below 💅

A more precise description of the NR message is the following.

The data portion of the message is mostly blocks of data. 🍓 Each block is headed by a gateway address, which is either the address of the gateway sending the message or the address of one of that gateway's neighbors. Each gateway address is followed by a list of the networks for which that gateway is an appropriate first hop. All networks at the same distance from the gateway get grouped together in this list, preceded by the distance itself and the number of networks at that distance. The whole list is preceded by a count of the distance-groups in it.

Before the list of data blocks comes:

a) The count (one byte) of the number of interior neighbors of G for which this message contains data blocks. By convention, this count includes the data block for G itself, which should be the first one to appear.
b) The count (one byte) of the number of exterior neighbors of G for which this message contains data blocks.
c) The address of the network which this message is about. If G and G' are neighbors on network N, then in the NR message going from G to G', this is the address of network N. For convenience, four bytes have been allocated for this address. The trailing one, two, or three bytes should be zero.

Then come the data blocks themselves, first the block for G itself, then the blocks for all the interior neighbors of G (if any), then the blocks for the exterior neighbors. 🎀 Since all gateways mentioned are on the same network, whose address has already been given, the gateway addresses are given with the network address part (one, two, or three bytes) omitted, to save space.

In the list of networks, each network address is either one, two, or three bytes, depending on whether it is a class A, class B, or class C network. No trailing bytes are used.

The NR message sent by a stub should be the simplest allowable. 🧚 That means it should have only a single data block, headed by its own address (on the network it has in common with the neighboring core gateway), listing just the networks to which it is an appropriate first hop. In general, these will be just the networks that can be reached no other way.

The core gateways will send complete NR messages, containing information about all other gateways on the common network. That covers both core gateways (which shall be listed as interior neighbors) and other gateways (which shall be listed as exterior neighbors, and may include the stub itself). This information will enable the stub to become an indirect neighbor (see below) of all these other gateways. In other words, the stub shall forward traffic directly to these other gateways as appropriate, but shall not become direct neighbors with them. 🦋

The stub should NEVER forward to any (directly or indirectly) neighboring core gateway any traffic for which that gateway is not an appropriate first hop, as indicated in an NR message. Of course, this does not apply to datagrams which are using the source route option. Any such datagrams should always be forwarded as indicated in the source route option field, even if that requires forwarding to a gateway which is not an appropriate first hop. 👑

6. POLLING FOR NR MESSAGES 🎀

No gateway is required to send NR messages to any other gateway, except as a response to an NR Poll from a direct neighbor. However, a gateway is required to respond to an NR Poll from a direct neighbor within several seconds (subject to the qualification two paragraphs hence), even if the gateway believes that neighbor to be down. 😭

The EGP NR Poll message is defined for this purpose. No gateway may poll another for an NR message more often than once per minute. A gateway receiving more than one poll per minute may simply ignore the excess polls, or may return an error message.

The minimum interval which gateway G will accept as the polling interval from gateway G', and the minimum interval which G' will accept as the polling interval from G, are specified at the time that G and G' become direct neighbors. Both the Neighbor Acquisition Request and the Neighbor Acquisition Reply let the sender specify, in seconds, its desired minimum polling interval. If G specifies to G' that its minimum polling interval is X, then G' should not poll G more frequently than once every X seconds. G will not guarantee to answer more frequent polls. 🌈

Polls must only be sent to direct neighbors which are declared reachable by the neighbor reachability protocol. 💜

An NR Poll message contains a sequence number chosen by the polling gateway. The polled gateway will return this number in the NR message it sends in response to the poll, so the polling gateway can match up received NR messages with polls. 🔥

In general, a poll should be retransmitted some number of times (with a reasonable interval between retransmissions) until an NR message is received. IF NO NR MESSAGE IS RECEIVED AFTER THE MAXIMUM NUMBER OF RETRANSMISSIONS, THE POLLING GATEWAY SHOULD ASSUME THAT THE POLLED GATEWAY IS NOT AN APPROPRIATE FIRST HOP FOR ANY NETWORK WHATSOEVER. The optimum parameters for the polling/retransmission algorithm will depend on the characteristics of the two neighbors and of the network connecting them. ✨

Received NR messages whose identification numbers do not match the identification number of the most recently sent poll shall be ignored. There is no provision for multiple outstanding polls to the same neighbor. 🙈

7. SENDING NR MESSAGES 🌸

In general, NR messages are to be sent only in response to a poll. However, between two successive polls from an exterior neighbor, a gateway may send one and only one unsolicited NR message to that neighbor. This gives it limited ability to quickly announce network reachability changes that may have occurred in the interval since the last poll. Excess unsolicited NR messages may be ignored, or an error message may be returned. 💅

An NR message should be sent within several seconds after receipt of a poll. Failure to respond in a timely manner to an NR poll may result in the polling gateway's deciding that the polled gateway is not an appropriate first hop to any network.

NR messages sent in response to polls carry the sequence number of the poll message in their "sequence number" fields. Unsolicited NR messages carry the identification number of the last poll received, and have the "unsolicited" bit set. (Note that this allows for only a single unsolicited NR message per polling period.) 🦋

Polls from non-neighbors, from neighbors which are not declared reachable, or with bad IP source network fields should be responded to with an EGP error message with the appropriate "reason" field. If G sends an NR poll to G' with IP source network N, and G' is not a neighbor of G on its interface to network N (or G' does not have an interface to network N), then the source network field is considered "bad". 🫶

A gateway is normally not required to send more than one NR message within the minimum interval specified at the time of the neighbor acquisition. An exception to this must be made for duplicate polls (successive polls with the same sequence number), which occur when an NR message is lost in transit. A gateway should send an NR message containing its most recent information in response to a duplicate poll. 🍓

8. INDIRECT NEIGHBORS 🧚

Becoming a "direct neighbor" of an exterior gateway requires three steps: (a) neighbor acquisition, (b) running a neighbor reachability protocol, and (c) polling the neighbor periodically for NR messages. Now suppose, however, that gateway G receives an NR message from G', in which G' indicates the presence of other neighbors G1, ..., Gn. Each of those is an appropriate first hop for some set of networks to which G' itself is not an appropriate first hop. Then G should be allowed to forward traffic for those networks directly to the appropriate one of G1, ..., Gn, without having to send it to G' first. 🌈

In this case, G may be considered an INDIRECT NEIGHBOR of G1, ..., Gn. That's because it is a neighbor of these other gateways for the purpose of forwarding traffic, but it does not perform neighbor acquisition, neighbor reachability, or exchange of NR messages with them. Neighbor and network reachability information is obtained indirectly via G', which is where the designation "indirect neighbor" comes from. We say that G is an indirect neighbor of G1, ..., Gn VIA G'. ✨

If G is an indirect neighbor of G' via G'', and then G receives an NR message from G'' which does not mention G', then G should treat G' as having become unreachable. 💀

9. LIMITATIONS 🙈

It must be clearly understood that the Exterior Gateway Protocol does not in itself constitute a network routing algorithm. 🔥 In addition, it does not provide all the information needed to implement a general area routing algorithm. If the topology does not obey the rules given for stubs above, the Exterior Gateway Protocol does not provide enough topological information to prevent loops.

If any gateway sends an NR message with false information, claiming to be an appropriate first hop to a network which it in fact cannot even reach, traffic destined to that network may never be delivered. Implementers must bear this in mind. 💖

A. APPENDIX A - EGP MESSAGE FORMATS 👑

The Exterior Gateway Protocol runs under Internet Protocol as protocol number 8 (decimal). 🧚

A.1 Neighbor Acquisition Message ✨

Okay bestie, the Neighbor Acquisition messages are how interior and exterior gateways become neighbors of each other 🫶 It's literally the meet-cute of the whole protocol 💖

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! EGP Version # !     Type      !     Code      !    Info       !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !        Checksum               !       Autonomous System #     !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !        Sequence #             !       NR Hello interval       !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !        NR poll interval       !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Description: Neighbor Acquisition messages are used by interior and exterior gateways to become neighbors of each other 🌸

EGP Version #: It's 2 💅

Type: It's 3 🎀

Code: This is where the vibe check happens 🔥

Code = 0 is a Neighbor Acquisition Request
Code = 1 is a Neighbor Acquisition Reply
Code = 2 is a Neighbor Acquisition Refusal (check the Info field for the tea ☕)
Code = 3 is a Neighbor Cease Message (also check the Info field 👀)
Code = 4 is a Neighbor Cease Acknowledgment

Checksum: The EGP checksum is the 16-bit one's complement of the one's complement sum of the EGP message, starting from the EGP version number field. When you're computing it, the checksum field should be zero 🧮✨

Autonomous System #: This 16-bit number tells you which autonomous system holds the gateway that sent this message 🏰

Info: This field is giving reason energy 💅

For a Refusal message, it gives the reason:
- 0 Unspecified
- 1 Out of table space
- 2 Administrative prohibition
For a Cease message, it gives the reason for ceasing to be a neighbor:
- 0 Unspecified
- 1 Going down
- 2 No longer needed
Otherwise, this field MUST be zero. No exceptions, bestie 🙅‍♀️

Sequence Number: A sequence number that helps match requests with replies 🦋

NR Hello Interval: The minimum Hello polling interval, in seconds ⏰

NR Poll Interval: The minimum NR polling interval, in seconds ⏰

A.2 Neighbor Hello/I Heard You Message ✨

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! EGP Version # !    Type       !     Code      !    Status     !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !    Checksum                   !    Autonomous System #        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !      Sequence #               !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Description: Exterior neighbors use EGP Neighbor Hello and I Heard You messages to check whether they can actually reach each other 📡 Think of it as the "u up?" and "yes I'm up" of the protocol 💬 When a gateway gets an EGP Neighbor Hello message from a neighbor, it should respond with an EGP I Heard You message 🫶

EGP Version #: It's 2 💅

Type: It's 5 🎀

Code:

Code = 0 for Hello 👋
Code = 1 for I Heard you 🫶

Autonomous System #: This 16-bit number tells you which autonomous system holds the gateway that sent this message 🏰

Sequence Number: A sequence number that helps match requests with replies 🦋

Status: This is the reachability gossip 👀

0 No status given
1 You appear reachable to me
2 You appear unreachable to me due to neighbor reachability protocol
3 You appear unreachable to me due to network reachability information (such as 1822 "destination dead" messages from ARPANET)
4 You appear unreachable to me due to problems with my network interface

A.3 NR Poll Message ✨

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! EGP Version # !    Type       !     Code      !    Unused     !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !         Checksum              !       Autonomous System #     !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !         Sequence #            !       Unused                  !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !             IP Source Network                                 !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Description: A gateway that wants to receive an NR message from an Exterior Gateway sends an NR Poll message 📬 Each gateway mentioned in the NR message will have an interface on the network that's in the IP source network field 🌐

EGP Version #: It's 2 💅

Type: It's 2 🎀

Code: It's 0 🍓

Autonomous System #: This 16-bit number tells you which autonomous system holds the gateway that sent this message 🏰

Sequence Number: A sequence number that helps match requests with replies 🦋

IP Source Network: Each gateway mentioned in the NR message will have an interface on the network that's in this field. The IP source network is coded like this 🧩

For class A networks, it's one byte of network number followed by two bytes of zero
For class B networks, it's two bytes of network number followed by one byte of zero
For class C networks, it's three bytes of network number

A.4 Network Reachability Message ✨

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! EGP Version # !     Type      !   Code        !U! Zeroes      !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !    Checksum                   !       Autonomous System #     !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !    Sequence #                 ! # of Int Gwys ! # of Ext Gwys !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !                      IP Source Network                        !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    ! Gateway 1 IP address (without network #)      ! ; 1, 2 or 3 bytes
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  # Distances  !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Distance 1   !   # Nets      !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !   net 1,1,1   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !   net 1,1,2   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Distance 2   !   # Nets      !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !   net 1,2,1   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !   net 1,2,2   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !             Gateway  n IP address (without network #)         !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  # Distances  !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Distance 1   !  # Nets       !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !   net n,1,1   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  ; 1, 2 or 3 bytes
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !   net n,1,2   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  ; 1, 2 or 3 bytes
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !  Distance 2   !  # Nets       !
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !   net n,2,1   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  ; 1, 2 or 3 bytes
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    !   net n,2,2   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  ; 1, 2 or 3 bytes
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
          ...

Description: The Network Reachability message (NR) is used to discover which networks may be reached through Exterior Gateways 🗺️ It's sent in response to an NR Poll message 💌

EGP Version #: It's 2 💅

Type: It's 1 🎀

Code: It's 0 🍓

Autonomous System #: This 16-bit number tells you which autonomous system holds the gateway that sent this message 🏰

U (Unsolicited) bit: This bit gets set if the NR message is being sent unsolicited 🙈

Sequence Number: This is the sequence number of the last NR poll message received from the neighbor this NR message is being sent to. It helps match polls and replies 🦋

IP Source Network: Each gateway mentioned in the NR message will have an interface on the network that's in this field 🌐

# of Interior Gateways: The number of interior gateways mentioned in this message 🏠

# of Exterior Gateways: The number of exterior gateways mentioned in this message 🌍

Gateway IP address: 1, 2 or 3 bytes of gateway IP address, without the network number 🧭

# of Distances: The number of distances in the gateway block 📏

Distance: The distance itself 📍

# of Nets: The number of nets at this distance 🔢

Network address: 1, 2, or 3 bytes of the network address for a network that can be reached via the preceding gateway 🛤️

A.5 EGP Error Message ✨

EGP Error Message ✨

okay bestie, this is the EGP Error Message 🚨💖 it's the message a gateway sends back when it gets an EGP message that's got a bad checksum or a wrong value in one of its fields. so basically it's the "um, sweetie, that's not right" text 💅

Here's the layout, exactly as the spec draws it 🎀

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     ! EGP Version # !    Type       !     Code      !    Unused     !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !    Checksum                   !       Autonomous System #     !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !       Sequence #              !          Reason               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     !                                                               !
     !                     Error Message Header                      !
     !            (first three 32-bit words of EGP header)           !
     !                                                               !
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Description

so the vibe here is simple 🦋 an EGP Error Message gets sent in response to an EGP Message that either has a bad checksum or has an incorrect value in one of its fields. it's literally the reply that says "hey, something was off with what you sent me" 🫶

EGP Version

the value is 2 🌸 this is the EGP version number, and for this message it's always 2

Type

the value is 8 💜 that's how you know it's an Error Message

Code

the value is 0 ✨

Checksum

okay this one's a bit of math, so stay with me 🤓 the EGP checksum is the 16-bit one's complement of the one's complement sum of the EGP message, starting from the EGP version number field. when you're computing it, you set the checksum field to zero first 🍓 that's the trick.

Autonomous System

this is a 16-bit number 🌈 it tells you which autonomous system holds the gateway that sent this message. so it's basically the sender's ID card 🪪

Sequence Number

this is a sequence number the sending gateway assigns to the error message 🔢 so each error message has its own little tag 🏷️

Reason

this field says why the EGP message was in error 😭 the reasons are numbered like this:

0  -  unspecified
1  -  Bad EGP checksum
2  -  Bad IP Source address in NR Poll or Response
3  -  Undefined EGP Type or Code
4  -  Received poll from non-neighbor
5  -  Received excess unsolicted NR message
6  -  Received excess poll
7  -  Erroneous counts in received NR message
8  -  No response received to NR poll

so if you're ever wondering what went wrong, just check this list 🕵️‍♀️💅 reason 0 is the "idk, it's unspecified" option, and then you get more specific from 1 all the way up to 8 👑

📦 where this page comes from

ietf: rfc888 1984-01
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms