RFC 827
Exterior Gateway Protocol (EGP)
1 INTRODUCTION 🎀
Okay bestie, so the DARPA Catenet is expected to keep growing 📈✨ with more and more hosts on more and more networks joining in. That means we need more and more gateways 🌸. In the past, the expansion was pretty chaotic. New gateways, often running software totally different from the existing ones, would just get plugged in and immediately start joining the common routing algorithm through the GGP protocol 🙈. But as the internet gets bigger and bigger, this "just add it" method stops being feasible, and it's giving problems. There are a few reasons for that:
- the overhead of the routing algorithm gets excessively large 💀;
- the spread of radically different gateways all joining one common routing algorithm makes maintenance and fault isolation nearly impossible, because the internet stops being something you can treat as one integrated communications system 😭;
- the gateway software and algorithms, especially the routing algorithm, get too rigid and inflexible, since any proposed change has to be made in too many different places by too many different people 🙄.
In the future, the internet is expected to turn into a set of separate domains, or "autonomous systems" 👑. Each one is made up of one or more relatively homogeneous gateways. The protocols, and especially the routing algorithm these gateways use among themselves, will be a private matter, and they never need to be implemented in gateways outside that particular domain or system 🔒.
In the simplest case, an autonomous system is just a single gateway connecting, for example, a local network to the ARPANET 🧚. A gateway like that 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 that local network nor is headed to it. In the near-term future, we'll start thinking of the internet as a bunch 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 former system the "core" system, and it'll be used as a transport, or "long-haul", system for the latter ones 💅.
Ultimately, though, the internet might be a bunch of co-equal autonomous systems, any of which can be used as a transport medium for traffic starting in any system and heading to any system (with certain restrictions we'll get to later) ✨. When this more complex setup happens, it won't make sense to call any one autonomous system the "core" 🙃. Still, for the sake of concreteness, and because the first Exterior Gateway Protocol implementations are expected to focus on connecting "stub gateways" to the DARPA gateways on ARPANET and SATNET, we'll often use the term "core" gateways in our examples and discussion 🍓.
The whole point of the Exterior Gateway Protocol (EGP) 💜 is to let one or more autonomous systems act as transport media for traffic that starts in some other autonomous system and is headed for yet another one. Meanwhile, the end-user gets to see all the autonomous systems together as a single internet with a flat, uniform address space 🦋. The route a datagram takes through the internet, and how many autonomous systems it crosses, are supposed to be transparent to the end-user. The exception is if the end-user deliberately uses the IP "source route" option 🫶.
We've intentionally left a lot of latitude to the designers and implementers of particular autonomous systems, especially when it comes to timer values 🕰️. We did this because different gateway implementations and different internet environments may just have different requirements and goals, so no single strict implementation spec could apply to all of them. But here's the thing, and it's a BIG thing 🚨: this does NOT mean that ANY implementation that conforms to the spec will work well, or that the areas where we left latitude aren't crucial to performance. For example, the fact that some time-out value isn't specified here does NOT mean everything will work no matter what value gets assigned. Not me thinking that's fine 😤.
Autonomous systems get assigned 16-bit identification numbers (kind of the same way network and protocol numbers are assigned now) 🔢, and every EGP message header has one word for this number. Zero will never be assigned to an autonomous system. Instead, a zero in this field just means no number is present 0️⃣.
We also need to introduce the idea of one gateway being a NEIGHBOR of another 🤝. In the simplest and most common case, two gateways are "neighbors" if there's a network that each of them has an interface on. But we need a slightly more general notion of "neighbor" to cover these two cases:
- a) Two gateways may be regarded as neighbors if they're directly connected, not by a network (in the usual sense of the term), but by a simple wire, an HDLC line, or some similar means of "direct connection".
- b) Two gateways may be regarded as neighbors if they're connected by an "internet" that's transparent to them. In other words, we'd like to be able to say two gateways are neighbors even if they're connected by an internet, as long as the gateways don't use any knowledge of that internet's internal structure in their own packet-forwarding algorithms 🧠.
To handle all these cases at once, we'll say two gateways are NEIGHBORS if they're connected by some communications medium whose internal structure is transparent to them. (See IEN 184 for a more general discussion of this notion of neighbor 📖.)
If two neighbors are part of the same autonomous system, we call them INTERIOR NEIGHBORS. If two neighbors are not part of the same autonomous system, we call them EXTERIOR NEIGHBORS 🏠➡️🌍. For one system to use another as a transport medium, gateways that are exterior neighbors of each other need to be able to find out which networks can be reached through the other one. The Exterior Gateway Protocol is what lets this information get passed between exterior neighbors 📬. Since it's a polling protocol, it also lets each gateway control the rate at which it sends and receives network reachability information, so each system can control its own overhead 🎛️. It also lets each system have an independent routing algorithm that can't be disrupted by failures in other systems 🛡️.
It must be clearly understood that any autonomous system where routing needs to happen among the gateways inside that system must implement its own routing algorithm 🗺️. (A routing algorithm isn't generally necessary for a simple autonomous system made of just a single stub gateway.) The Exterior Gateway Protocol is NOT a routing algorithm 🚫. It helps exterior neighbors exchange information that's likely to be needed by any routing algorithm, but it does NOT specify what the gateways are supposed to do with that information. The "routing updates" of some autonomous system's interior routing algorithm may or may not look similar to the messages of the exterior gateway protocol. The gateways in the DARPA "core" system will initially use the GGP protocol (the old Gateway-Gateway protocol) as their routing algorithm, but that's subject to change 🔄. Gateways in other autonomous systems may use their own Interior Gateway Protocols (IGPs), which may or may not be similar to the IGP of any other autonomous system. They may, of course, use GGP, but they won't be permitted to exchange GGP messages with gateways in other autonomous systems 🙅♀️.
It must also be clearly understood that the Exterior Gateway Protocol is NOT meant to provide information that could be used as input to a completely general area or hierarchical routing algorithm 🙅. It's intended for a set of autonomous systems connected in a tree, with no cycles 🌳. It doesn't pass enough information to prevent routing loops if cycles in the topology do exist. Yikes 😬.
The Exterior Gateway Protocol has three parts: (a) the Neighbor Acquisition Protocol, (b) the Neighbor Reachability Protocol, and (c) Network Reachability determination 🧩. Note that all messages defined by EGP are meant to travel only a single "hop". That means they originate at one gateway and get sent to a neighboring gateway without any intervening gateway getting involved 🏃♀️. So the time-to-live field should be set to a very small value ⏳. Gateways that run into EGP messages in their message streams that aren't addressed to them may discard them 🗑️.
2 NEIGHBOR ACQUISITION 🦋
Before you can even grab routing info from an
Okay so, if you want to talk to an exterior gateway 🌸, you have to acquire that gateway as a direct neighbor. (The difference between direct and indirect neighbors gets explained in a later section 🦋.) For two gateways to become direct neighbors, they first have to be neighbors in the sense defined above, and then they have to run the Neighbor Acquisition Protocol, which is basically a standard three-way handshake 🤝✨.
A gateway that wants to start neighbor acquisition with another one sends it a Neighbor Acquisition Request. It should keep re-sending that message at a reasonable rate, maybe once every 30 seconds or so 🕰️, until a Neighbor Acquisition Reply shows up. The Request carries an identification number, which gets copied into the Reply so the two can be matched up 🧩💕.
When a gateway gets a Neighbor Acquisition Request, it has to decide whether it actually wants to become a direct neighbor of whoever sent it. If the answer is no, it may (its call, totally optional 💅) respond with a Neighbor Acquisition Refusal, and it can optionally say why. Otherwise, it should send a Neighbor Acquisition Reply. It must also send a Neighbor Acquisition Request too, unless it already did that 🙌.
Two gateways become direct neighbors once each one has sent a Neighbor Acquisition Message to the other and received the matching Neighbor Acquisition Reply back 👯♀️💖.
Unmatched Replies or Refusals should get thrown out after a reasonable amount of time. Still, info about those unmatched messages might be super useful for diagnostics 🔍🧁.
A Neighbor Acquisition Message from a gateway that's already a direct neighbor should be answered with a Reply and a Neighbor Acquisition Message 🔁.
If a Neighbor Acquisition Reply comes in from a prospective neighbor, but then time passes and no Neighbor Acquisition Message ever arrives from that same prospective neighbor, the neighbor acquisition protocol shall be considered incomplete 🚫. At that point, a Neighbor Cease message (more on that below) should get sent. If one gateway still wants to acquire the other as a neighbor, the whole protocol must be started over from the very beginning 🔄.
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 reply with a Neighbor Cease Acknowledgment, and it should stop treating the sender as a neighbor in any way 🚪. Direct neighbors run a lot of protocol between each other (see below), so if a gateway doesn't need to be a direct neighbor anymore, it's "polite" to say so with a Neighbor Cease Message 💅🫶. The Neighbor Cease Message should keep getting re-sent (up to some number of times) until an acknowledgment comes back 📬.
Once a Neighbor Cease message has been received, the Neighbor Reachability Protocol (below) should stop running 🛑.
NOTE THAT WE HAVE NOT SPECIFIED THE WAY IN WHICH ONE GATEWAY INITIALLY DECIDES THAT IT WANTS TO BECOME A NEIGHBOR OF ANOTHER. (Okay, this is lowkey a tricky problem, but it's just not part of the External Gateway Protocol 🤷♀️.)
3. Neighbor Reachability Protocol 🌈
It's really important for a gateway to keep real-time info about whether its neighbors are reachable 👀. If a gateway decides a particular neighbor can't be reached, it should stop 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 sent back to that neighbor "immediately" ⚡. The delay between receiving a "Hello" and sending back an "I Heard You" should never be more than a few seconds ⏱️.
Right now, the reachability determination algorithm is left up to whoever designs a particular gateway 🛠️. We've got algorithms like this in mind:
A reachable neighbor shall be declared unreachable if, during the time in which we sent our last n "Hello"s, we received fewer than k "I Heard You"s in return. An unreachable neighbor shall be declared reachable if, during the time in which we sent our last m "Hello"s, we received at least j "I Heard You"s in return 📊.
However, the frequency of "Hello"s and the values of the parameters k, n, j, and m can't be specified here 🙃. For the best results, they depend on the characteristics of the neighbor and of the network 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 😬.
The "Hello" and "I Heard You" messages have a status field, which the sending gateway uses to say whether it thinks the receiving gateway is reachable or not 🚦. That info is useful for diagnostics 🩺. It also lets one gateway make its reachability determination parasitic on the other 🦠: only one gateway actually needs to send "Hello" messages, and the other can declare it up or down based on the status field in the "Hello" 🤯. So the "passive" gateway (which only sends "I Heard You"s) declares the "active" one (which only sends "Hello"s) to be reachable when the "Hello"s from the active one indicate that it has declared the passive one to be reachable 🔁✨. Of course, this only works if there's prior agreement about which neighbor is the active one. (Ways of reaching that "prior agreement" aren't part of the Exterior Gateway Protocol 🤐.)
A direct neighbor should also be declared unreachable if the network connecting it supplies lower-level protocol info from which that can be deduced 🕵️♀️. For example, if a gateway gets an 1822 Destination Dead message from the ARPANET saying that a direct neighbor is dead 💀, it should declare that neighbor unreachable. The neighbor shouldn't be declared reachable again until the required number of Hello/I-Heard-You packets have been exchanged 📦.
A direct neighbor that's become unreachable does not stop being a direct neighbor just because of that 🙅♀️. It can be declared reachable again without going through the neighbor acquisition protocol all over again 🎉. However, if the neighbor stays unreachable for an extremely long time, such as an hour ⌛, the gateway should stop treating it as a neighbor, meaning it should stop sending Hello messages to it. The neighbor acquisition protocol would then have to be repeated before it could become a direct neighbor again 🔁🥲.
"Hello" and "I Heard You" messages from gateway G to gateway G' also carry the identification number of the NR poll message (see below) which G has most recently received from G' 🪪.
"Hello" and "I Heard You" messages from gateway G to gateway G' also carry the minimum interval in minutes at which G is willing to be polled by G' for NR messages (see below) ⏲️.
"Hello" messages from sources other than direct neighbors should simply be ignored 🙈. Logging them might still give useful diagnostic info 📝.
A gateway that's going down, or whose interface to the network connecting it to a particular neighbor is going down, should send a Gateway Going Down message to all the direct neighbors that won't be able to reach it anymore 📢. It should re-send that message (up to some number of times) until it gets a Gateway Going Down Acknowledgment 🔁. This gives neighbors an advance warning of an outage, so they can prepare in a way that minimizes disruption to existing traffic 🛟💅.
4. Network Reachability (NR) Message 🗺️
Terminology: 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.
Short version: G is an appropriate first hop for network M relative to network N just in case there's no better gateway on network N to route traffic destined for network M through 🏆. For optimal routing, traffic on network N that's destined for network M ought to always be forwarded to a gateway that's an appropriate first hop 🎯.
So, for exterior neighbors G and G' (which are neighbors over network N) to use each other as packet switches for forwarding traffic to remote networks, each one 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 passing this info along 📨.
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 get this info from exterior neighbor G, then it knows that no traffic destined for networks that are not in that list should be forwarded to G 🙅♀️. It can't just conclude, though, that all traffic for any networks in that list ought to go via G, since G' may have other neighbors that 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 one could be an appropriate first hop 👯.
For each network in the list, the NR message also contains a byte which 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. 💖 This information might (or might not!) be useful in the interior routing algorithm of gateway G', or for diagnostic purposes. 🔍
The max distance value, 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 doesn't mention some network N that was in the previous NR message from G, it SHALL be assumed that N is still reachable from G. 🌸 HOWEVER, IF N is not MENTIONED IN TWO SUCCESSIVE NR MESSAGES FROM G, THAT SHALL BE TAKEN TO MEAN THAT N IS NO LONGER REACHABLE FROM G. This is the timeout trick ⏰: networks that can't be reached anymore but never get explicitly declared unreachable still get timed out and removed from the list of reachable networks. Lowkey genius.
It may often be the case that where G and G' are exterior neighbors on network N, G knows about a bunch more gateway neighbors on network N, and knows which networks those other neighbors are the right first hop for. Since G' may not know about all of these other neighbors, it's convenient and often more efficient for it to get this info from G. So the EGP NR message also has fields that let G 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. Gateways SHOULD be included in this list only if G is actively running its neighbor reachability protocol with them.
- 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.
So the NR message basically lets a gateway "discover" new neighbors 🕵️♀️ by checking whether a neighbor it already knows has any extra neighbors on the same network. This also makes the INDIRECT NEIGHBOR strategy (defined below) possible. Iconic. 👑
A more precise description of the NR message goes like this.
The data portion of the message is mostly blocks of data 🧱. Each block is headed by a gateway address, which is the address of either the gateway sending the message or 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, plus the distance from that gateway to each network.
Before the list of data blocks, you get:
- a) The address of the network 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.
- b) 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.
- c) The count (one byte) of the number of exterior neighbors of G for which this message contains data blocks.
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 every gateway mentioned is on the same network (whose address was already given), the gateway addresses are written with the network address part (one, two, or three bytes) left out, to save space 🎀.
Each block has a one-byte count of the number of networks for which that gateway is the appropriate first hop. In the list of networks, each network address is one, two, or three bytes, depending on whether it's a class A, class B, or class C network. No trailing bytes are used. 💅
Sometimes the NR message needs to be fragmented 🧩. The NR message has a byte for the number of this fragment (fragments are numbered from zero), and a byte for the number of the last fragment (not the number of fragments). If fragmentation isn't used, these bytes MUST both be zero.
EACH FRAGMENT MUST BE A FULLY SELF-CONTAINED NR MESSAGE. Each fragment starts with a count of interior and exterior neighbors, and has some whole number of gateway data blocks. The number of data blocks in each fragment MUST correspond to the neighbor counts at the start of that fragment. However, only the first fragment SHOULD begin with a data block describing the sending gateway.
This setup means each fragment can be processed on its own, with no complicated reassembly needed 🙌. It also means you can process a message even when not all of its fragments have arrived. If, after some time and some retransmissions of a poll, not all fragments have been received, the fragments that ARE present SHALL be processed as if they were the complete NR message. (So networks mentioned only in the missing fragment keep the "distance" values they had in the previous NR message from that gateway. However, if no new value for a particular network arrives in the next NR message from that gateway, the network will be declared unreachable.) 🥲
5. 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 MUST NOT poll another for an NR message more often than once per minute. A gateway that gets more than one poll per minute MAY simply ignore the excess polls, or MAY return an error message. The Hello and I Heard You messages that gateway G sends to gateway G' show the minimum interval G will accept as the polling interval from G'. In other words, G' won't guarantee to respond to polls from G that arrive less than that interval apart. ⏳
Polls MUST only be sent to direct neighbors that are declared reachable by the neighbor reachability protocol. 🫶
An NR Poll message contains an identification number chosen by the polling gateway. The polled gateway returns this number in the NR message it sends back, so the polling gateway can match received NR messages up with polls. It's the polling gateway's job to pick an identification number that's "unique" enough to detect out-of-date NR messages still floating around the network 🛸. Since polls are pretty infrequent, this usually isn't much of a problem. To help pick a number, the Hello and I Heard You messages carry the identification number of the last NR poll received from the neighbor they're being sent to.
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 best parameters for the polling and retransmission algorithm depend on the characteristics of the two neighbors and of the network connecting them.
If only some fragments of an NR message arrive after the maximum number of retransmissions, the fragments that are present SHALL be treated as the whole NR message. 🧩
Received NR messages whose identification numbers don't match the identification number of the most recently sent poll SHALL be ignored. There's no provision for multiple outstanding polls to the same neighbor. 🚫
6. SENDING NR MESSAGES 🦋
In general, NR messages are only sent 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 a limited way to quickly announce reachability changes that may have happened 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 receiving a poll. Failing to respond in a timely manner to an NR poll may result in the polling gateway deciding that the polled gateway is not an appropriate first hop to any network. 🙈
NR messages sent in response to polls carry the identification number of the poll message in their "identification 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.) 🍓
To make sending unsolicited NR messages easier, the NR poll message has a byte indicating the polling interval in minutes. ⏱️
Polls from non-neighbors, from neighbors that aren't 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' doesn't have an interface to network N), then the source network field is considered "bad". 🚨
Okay bestie, the duplicate poll rule is SO important 🚨 If you get the same poll twice, you send back the exact same NR message, and if it's fragmented you send the same fragments in the same way every time 🧩 There's no support for handling several outstanding polls from one neighbor, so don't go there 🙅♀️ And lowkey I need you to hear this: if you DON'T resend the same fragments, reassembly is going to break, like, almost for sure 💀 BUT if you aren't fragmenting, a duplicate poll getting a newer NR message back is totally fine ✨
7. INDIRECT NEIGHBORS 🦋
Okay so becoming a "direct neighbor" of an exterior gateway takes three steps 🪜 First you do neighbor acquisition, then you run a neighbor reachability protocol, and then you poll that neighbor for NR messages on a regular schedule. But here's the twist 👀 Say gateway G gets an NR message from G', and G' says it has other neighbors G1, ..., Gn. Each of those is a good first hop for some networks that G' itself can't be a good first hop for. Then G should be allowed to send traffic for those networks straight to the right one of G1, ..., Gn, without bouncing it through G' first 🏃♀️💨
In this situation G counts as an INDIRECT NEIGHBOR of G1, ..., Gn, because it's a neighbor of them for forwarding purposes only. It doesn't do neighbor acquisition, neighbor reachability, or swap NR messages with them 🙅♀️ All of its info about those neighbors and networks comes indirectly through G', which is literally why it's called "indirect neighbor" 🫶 So we say G is an indirect neighbor of G1, ..., Gn VIA G'. Iconic naming, no notes 💅
Now the plot twist: if G is an indirect neighbor of G' via G'', and then G gets an NR message from G'' that doesn't mention G' at all, G should treat G' as unreachable 😭
8. HOW TO BE A STUB GATEWAY 🧚
Okay so the biggest use case for EGP is probably letting a stub gateway talk to one of the DARPA core gateways 🌈 That's how data can flow between networks that are only reachable through the stub and networks that are only reachable through the core system ✨ A stub is basically a one-gateway internet system with no interior neighbors. It's usually there to hook a local network (or networks) up to a long-range transport network, like ARPANET or SATNET, where a core gateway lives 🛰️ So the stub really doesn't want the core gateways sending it anything except traffic for the networks that can only be reached through the stub 🙅♀️ Generally speaking, the stub shouldn't do ANY services for the internet transport system unless it actually needs them to get traffic to and from those networks that can't be reached otherwise 💖
The stub should have its tables set up with the addresses of a small number of core gateways (no more than two or three) that it shares a common network with 🎀 The stub is the one responsible for starting neighbor acquisition with those gateways. Once a stub and a core gateway become direct neighbors, the core gateway starts sending Hello messages 📣
When the stub declares its direct-neighbor core gateways reachable, it should poll them for NR messages at a rate of no more than once per minute (or whatever the core gateways specify in their Hello messages) ⏰ The core gateways will also poll the stub for NR messages, so it's a two-way vibe 🤝
The NR message the stub sends should be the simplest one allowed. Basically it should have only one data block, headed by its own address (on the network it shares with the neighboring core gateway), and it should list only the networks it's an appropriate first hop for. In general, those are just the networks that can't be reached any other way 🍓
The core gateways will send complete NR messages with info about every other gateway on the common networks 💜 That includes core gateways (which shall be listed as interior neighbors) and other gateways (which shall be listed as exterior neighbors, and which may include the stub itself). This is the part that lets the stub become an indirect neighbor of all those other gateways. So the stub shall forward traffic directly to them as appropriate, but shall not become a direct neighbor with them 🦋
The core gateways will report a distance less than 128 if the network can be reached without leaving the core system (meaning, without going through any gateway that isn't a core gateway), and a distance greater than or equal to 128 otherwise 📏
Now the big rule 🚫 The stub should NEVER forward traffic to any neighboring core gateway (direct or indirect) when that gateway isn't an appropriate first hop according to an NR message. This doesn't apply to datagrams using the source route option, though. Those should always be forwarded as the source route option field says, even if that means sending them to a gateway that isn't an appropriate first hop 🗺️
If all of a stub's direct neighbors fail, it's the stub's job to get at least one new direct neighbor 💪 It can do this by picking one of the core gateways it used to have as an indirect neighbor and running the neighbor acquisition protocol with it. (It's possible that no more than one core gateway will ever agree to be a direct neighbor with a given stub at any one time 🤷♀️)
If the stub doesn't respond to Hello messages from the core gateway in a timely way, it may be declared unreachable 😬 And if it doesn't answer NR poll messages in a timely way, its networks may be declared unreachable. In either case, the core gateways may throw away traffic bound for those networks and send back ICMP "destination network unreachable" to the source hosts 🙈
The stub gateway is expected to fully implement ICMP as well as EGP 🫶 Specifically, it must respond to ICMP echo requests, and it must send ICMP destination dead messages when appropriate. It's also required to send ICMP Redirect messages when appropriate 💅
9. LIMITATIONS 💀
It has to be super clear that the Exterior Gateway Protocol is NOT a network routing algorithm by itself 🙅♀️ It also doesn't give you all the info you'd need to build a general area routing algorithm. And if the set of autonomous systems isn't tree-structured (so, if it has cycles), EGP doesn't give enough topology info to prevent loops 🔁 Not me being dramatic, this is serious 😭
If any gateway sends an NR message with false info, like claiming to be an appropriate first hop to a network it can't even reach, traffic for that network may never get delivered 💔 Implementers must keep this in mind, periodt 🫵
NEIGHBOR ACQUISITION 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 ! Info !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Checksum ! Autonomous System # !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Identification # !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Okay so the Neighbor Acquisition messages are how interior and exterior gateways become neighbors of each other 🤝
EGP Version # is just 1 💖
Type is 3 ✨
Code tells you what kind of acquisition message it is:
Code = 0 Neighbor Acquisition Request
Code = 1 Neighbor Acquisition Reply
Code = 2 Neighbor Acquisition Refusal (see Info field)
Code = 3 Neighbor Cease Message (see Info field)
Code = 4 Neighbor Cease AcknowledgmentChecksum 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 first 🧠
Autonomous System # is a 16-bit number that identifies the autonomous system containing the gateway that sent this message 🌸
Info depends on the code. For a Refusal, it gives the reason for refusing:
0 Unspecified
1 Out of table space
2 Administrative prohibitionFor a Cease message, it gives the reason for ceasing to be a neighbor:
0 Unspecified
1 Going down
2 No longer neededOtherwise, this field MUST be zero 🙅♀️ No exceptions, bestie 🔥
Identification Number is an identification number that helps match requests with replies 🎀
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 # !Min Poll Intvl ! Zero !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Last Poll Id # !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Okay so exterior neighbors use EGP Neighbor Hello and I Heard You messages to check that they're still connected 💜 When a gateway gets an EGP Neighbor Hello message from a neighbor, it should reply with an EGP I Heard You message 📣
EGP Version # is 1 🦋
Type is 5 🌈
Code is:
Code = 0 for Hello
Code = 1 for I Heard youChecksum works the same way as before: it's the 16-bit one's complement of the one's complement sum of the EGP message, starting from the EGP version number field 🧮 For computing it, the checksum field should be zero 🎀
Autonomous System #
This 16-bit number tells everyone which autonomous system the gateway that sent this message is chilling in 🌸
Here are the status codes, bestie 💅
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 interfaceLast Poll Id Number 🦋
This is the identification number of the most recently received NR poll message from the neighbor that this message is being sent to. It's giving "I'm keeping track of who asked me what" 🧚
Minimum Polling Interval ⏱️
Okay, so this gateway should not be polled for NR messages more often than once in this number of minutes. Please respect the boundaries, babe 🙈
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 # !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IP Source Network ! Interval !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Identification # !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+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 is in the IP source network field.
EGP Version # 🌈
The value here is 1.
Type 🎀
The value here is 2.
Code 🫶
The value here is 0.
Checksum 🔐
The EGP checksum is the 16-bit one's complement of the one's complement sum of the EGP message, starting with the EGP version number field. When you're computing it, the checksum field should be zero. Double-check that, friend 💅
Autonomous System # 🌸
This 16-bit number identifies the autonomous system containing the gateway that is the source of this message. Same energy as before, just the poll version ✨
Identification Number 🦋
An identification number that helps match requests and replies. It's the glue between the question and the answer 💜
IP Source Network 🌐
Each gateway mentioned in the NR message will have an interface on the network that is in the IP source network field. The IP source network is coded as one byte of network number followed by two bytes of zero for class A networks, two bytes of network number followed by one byte of zero for class B networks, and three bytes of network number for class C networks. The formatting is very particular, so don't freestyle it 🙈
Interval ⏳
The polling interval, in minutes.
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 # !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Fragment # !# of last frg. ! Identification # !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! IP Source Network !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! # of Int Gwys ! # of Ext Gwys !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! # of Nets ! ; # of nets for
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Gateway 1
! Gateway 1 IP address (without network #) ! ; 1, 2 or 3 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! net 1,1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! distance !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! net 1,2 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! distance !
+-+-+-+-+-+-+-+-+
.
.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! net 1,m !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; m nets reachable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; via Gateway 1
.
.
+-+-+-+-+-+-+-+-+
! # of nets ! ;number of nets for Gateway n
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Gateway n IP address (without network #) !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! net n,1 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! distance !
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! net n,2 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes
+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! distance ! .
+-+-+-+-+-+-+-+-+ .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! net n,m !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; m nets reachable
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; via Gateway n
! distance !
+-+-+-+-+-+-+-+-+Description 💫
The Network Reachability message (NR) is used to discover which networks may be reached through Exterior Gateways. The NR message is sent in response to an NR Poll message. It's basically the answer to the poll, and it's giving main character energy 👑
EGP Version # 🌈
The value here is 1.
Type 🎀
The value here is 1.
Code 🫶
The value here is 0.
Checksum 🔐
The EGP checksum is the 16-bit one's complement of the one's complement sum of the EGP message, starting with the EGP version number field. When you're computing it, the checksum field should be zero.
Autonomous System # 🌸
This 16-bit number identifies the autonomous system containing the gateway that is the source of this message.
U (Unsolicited) bit 💌
This bit is set if the NR message is being sent unsolicited. So if nobody asked, this is the one that's giving "surprise, I'm here" 🙈
Identification Number 🦋
The identification number of the last NR poll message received from the neighbor to whom this NR message is being sent. This number helps match polls and replies, so it's the bestie bracelet that connects them 💜
Fragment Number 🧩
Which Fragment this is in the NR Message. It's zero if fragmentation is not used.
Number of Last Fragment 🧩
The number of the last fragment in the NR Message. It's zero if fragmentation is not used.
IP Source Network 🌐
Each gateway mentioned in the NR message will have an interface on the network that is in the IP source network field.
# of Interior Gateways 🏠
The number of interior gateways that are mentioned in this message.
# of Exterior Gateways 🌍
The number of exterior gateways that are mentioned in this message.
# of Networks 🕸️
The number of networks for which the gateway whose IP address immediately follows is the appropriate first hop.
Gateway IP address 📍
1, 2 or 3 bytes of Gateway IP address (without network #).
Network address 🗺️
1, 2, or 3 bytes of network address of a network that can be reached via the preceding gateway.
Distance 📏
1 byte of distance, measured in number of hops.
EGP ERROR 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 # !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Error Type ! Error Code ! Id. # of Erroneous Msg. !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
! Sequence # !
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Description 🚨
An EGP Error Message is sent in response to an EGP Message that has a bad checksum or has an incorrect value in one of its fields. Someone messed up, and this is how we tell them 🙈
EGP Version # 🌈
The value here is 1.
Type 🎀
The value here is 8.
Code 🫶
The value here is 0.
Checksum 🔐
The EGP checksum is the 16-bit one's complement of the one's complement sum of the EGP message, starting with the EGP version number field. When you're computing it, the checksum field should be zero.
Autonomous System # 🌸
This 16-bit number identifies the autonomous system containing the gateway that is the source of this message.
Sequence Number 🔢
A sequence number assigned by the gateway that sends the error message.
Error Type 🧾
The Type of the EGP message that was in error.
Error Code 🧾
The Code of the EGP message that was in error.
Identification number of erroneous message 🆔
The Sequence number of the EGP message that was in error.
Reason 🧠
The reason that the EGP message was in error. The following reasons are defined:
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
9 - Not all fragments of NR message received📦 where this page comes from
- ietf: rfc827 1982-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms