summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc827.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc827.txt')
-rw-r--r--doc/rfc/rfc827.txt2668
1 files changed, 2668 insertions, 0 deletions
diff --git a/doc/rfc/rfc827.txt b/doc/rfc/rfc827.txt
new file mode 100644
index 0000000..063330e
--- /dev/null
+++ b/doc/rfc/rfc827.txt
@@ -0,0 +1,2668 @@
+ RFC 827
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ EXTERIOR GATEWAY PROTOCOL (EGP)
+
+
+ Eric C. Rosen
+
+
+ Bolt Beranek and Newman Inc.
+
+
+ October 1982
+
+
+
+
+
+
+
+
+
+
+
+
+It is proposed to establish a standard for Gateway to Gateway procedures
+that allow the Gateways to be mutually suspicious. This document is a
+DRAFT for that standard. Your comments are strongly encouraged.
+
+
+
+
+
+
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ Table of Contents
+
+
+
+
+ 1 INTRODUCTION.......................................... 1
+ 2 NEIGHBOR ACQUISITION.................................. 8
+ 3 NEIGHBOR REACHABILITY PROTOCOL....................... 11
+ 4 NETWORK REACHABILITY (NR) MESSAGE.................... 15
+ 5 POLLING FOR NR MESSAGES.............................. 22
+ 6 SENDING NR MESSAGES.................................. 25
+ 7 INDIRECT NEIGHBORS................................... 27
+ 8 HOW TO BE A STUB GATEWAY............................. 28
+ 9 LIMITATIONS.......................................... 32
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - i -
+
+
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 1 INTRODUCTION
+
+
+ The DARPA Catenet is expected to be a continuously expanding
+
+ system, with more and more hosts on more and more networks
+
+ participating in it. Of course, this will require more and more
+
+ gateways. In the past, such expansion has taken place in a
+
+ relatively unstructured manner. New gateways, often containing
+
+ radically different software than the existing gateways, would be
+
+ added and would immediately begin participating in the common
+
+ routing algorithm via the GGP protocol. However, as the internet
+
+ grows larger and larger, this simple method of expansion becomes
+
+ less and less feasible. There are a number of reasons for this:
+
+
+ - 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.
+
+
+
+ - 1 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ In the future, the internet is expected to evolve into a set
+
+ of separate domains or "autonomous systems", each of which
+
+ consists of a set of one or more relatively homogeneous gateways.
+
+ The protocols, and in particular the routing algorithm which
+
+ these gateways use among themselves, will be a private matter,
+
+ and need never be implemented in gateways outside the particular
+
+ domain or system.
+
+
+ In the simplest case, an autonomous system might consist of
+
+ just a single gateway connecting, for example, a local network to
+
+ the ARPANET. Such a gateway might be called a "stub gateway",
+
+ since its only purpose is to interface the local network to the
+
+ rest of the internet, and it is not intended to be used for
+
+ handling any traffic which neither originated in nor is destined
+
+ for that particular local network. In the near-term future, we
+
+ will begin to think of the internet as a set of autonomous
+
+ systems, one of which consists of the DARPA gateways on ARPANET
+
+ and SATNET, and the others of which are stub gateways to local
+
+ networks. The former system, which we shall call the "core"
+
+ system, will be used as a transport or "long-haul" system by the
+
+ latter systems.
+
+
+ Ultimately, however, the internet may consist of a number of
+
+ co-equal autonomous systems, any of which may be used (with
+
+ certain restrictions which will be discussed later) as a
+
+
+
+ - 2 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ transport medium for traffic originating in any system and
+
+ destined for any system. When this more complex configuration
+
+ comes into being, it will be inappropriate to regard any one
+
+ autonomous system as a "core" system. For the sake of
+
+ concreteness, however, and because the initial implementations of
+
+ the Exterior Gateway Protocol are expected to focus on the the
+
+ case of connecting "stub gateways" to the DARPA gateways on
+
+ ARPANET and SATNET, we will often use the term "core" gateways in
+
+ our examples and discussion.
+
+
+ The purpose of the Exterior Gateway Protocol (EGP) is to
+
+ enable one or more autonomous systems to be used as transport
+
+ media for traffic originating in some other autonomous system and
+
+ destined for yet another, while allowing the end-user to see the
+
+ composite of all the autonomous systems as a single internet,
+
+ with a flat, uniform address space. The route which a datagram
+
+ takes through the internet, and the number of autonomous systems
+
+ which it traverses, are to be transparent to the end-user
+
+ (unless, of course, the end-user makes use of the IP "source
+
+ route" option).
+
+
+ In describing the Exterior Gateway Protocol, we have
+
+ deliberately left a great deal of latitude to the designers and
+
+ implementers of particular autonomous systems, particularly with
+
+ regard to timer values. We have done this because we expect that
+
+
+
+ - 3 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ different gateway implementations and different internet
+
+ environments may just have different requirements and goals, so
+
+ that no single strict implementation specification could apply to
+
+ all. However, this does NOT mean that ANY implementation which
+
+ conforms to the specification will work well, or that the areas
+
+ in which we have left latitude are not crucial to performance.
+
+ The fact that some time-out value, for example, is not specified
+
+ here does not mean that everything will work no matter what value
+
+ is assigned.
+
+
+ Autonomous systems will be assigned 16-bit identification
+
+ numbers (in much the same ways as network and protocol numbers
+
+ are now assigned), and every EGP message header contains one word
+
+ for this number. Zero will not be assigned to any autonomous
+
+ system; rather, the presence of a zero in this field will
+
+ indicate that no number is present.
+
+
+ We need to introduce the concept of one gateway being a
+
+ NEIGHBOR of another. In the simplest and most common case, we
+
+ call two gateways "neighbors" if there is a network to which each
+
+ has an interface. However, we will need a somewhat more general
+
+ notion of "neighbor" to allow the following two cases:
+
+
+ a) Two gateways may be regarded as neighbors if they are
+
+ directly connected not by a network (in the usual sense
+
+
+
+
+ - 4 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ of the term), but by a simple wire, or HDLC line, or some
+
+ similar means of "direct connection".
+
+
+ b) Two gateways may be regarded as neighbors if they are
+
+ connected by an "internet" which is transparent to them.
+
+ That is, we would like to be able to say that two
+
+ gateways are neighbors even if they are connected by an
+
+ internet, as long as the gateways utilize no knowledge of
+
+ the internal structure of that internet in their own
+
+ packet-forwarding algorithms.
+
+
+ In order to handle all these cases, let us say that two gateways
+
+ are NEIGHBORS if they are 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. In
+
+ order for one system to use another as a transport medium,
+
+ gateways which are exterior neighbors of each other must be able
+
+ to find out which networks can be reached through the other. The
+
+ Exterior Gateway Protocol enables this information to be passed
+
+ between exterior neighbors. Since it is a polling protocol, it
+
+ also enables each gateway to control the rate at which it sends
+
+
+
+
+ - 5 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ and receives network reachability information, allowing each
+
+ system to control its own overhead. It also enables each system
+
+ to have an independent routing algorithm whose operation cannot
+
+ be disrupted by failures of other systems.
+
+
+ It must be clearly understood that any autonomous system in
+
+ which routing needs to be performed among gateways within that
+
+ system must implement its own routing algorithm. (A routing
+
+ algorithm is not generally necessary for a simple autonomous
+
+ system which consists of a single stub gateway.) The Exterior
+
+ Gateway Protocol is NOT a routing algorithm. It enables exterior
+
+ neighbors to exchange information which is likely to be needed by
+
+ any routing algorithm, but it does NOT specify what the gateways
+
+ are to do with this information. The "routing updates" of some
+
+ autonomous system's interior routing algorithm may or may not be
+
+ similar in format 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 this will be 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
+
+ will not be permitted to exchange GGP messages with gateways in
+
+ other autonomous systems.
+
+
+
+
+ - 6 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ It must also be clearly understood that the Exterior Gateway
+
+ Protocol is NOT intended to provide information which could be
+
+ used as input to a completely general area or hierarchical
+
+ routing algorithm. It is intended for a set of autonomous
+
+ systems which are connected in a tree, with no cycles. It does
+
+ not enable the passing of sufficient information to prevent
+
+ routing loops if cycles in the topology do exist.
+
+
+ The Exterior Gateway Protocol has three parts: (a) Neighbor
+
+ Acquisition Protocol, (b) Neighbor Reachability Protocol, and (c)
+
+ Network Reachability determination. Note that all messages
+
+ defined by EGP are intended to travel only a single "hop". That
+
+ is, they originate at one gateway and are sent to a neighboring
+
+ gateway without the mediation of any intervening gateway.
+
+ Therefore, the time-to-live field should be set to a very small
+
+ value. Gateways which encounter EGP messages in their message
+
+ streams which are not addressed to them may discard them.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - 7 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 2 NEIGHBOR ACQUISITION
+
+
+ Before it is possible to obtain routing information from an
+
+ exterior gateway, it is necessary to acquire that gateway as a
+
+ direct neighbor. (The distinction between direct and indirect
+
+ neighbors will be made in a later section.) In order for two
+
+ gateways to become direct neighbors, they must be neighbors, in
+
+ the sense defined above, and they must execute the NEIGHBOR
+
+ ACQUISITION PROTOCOL, which is simply a standard three-way
+
+ handshake.
+
+
+ A gateway that wishes to initiate neighbor acquisition with
+
+ another sends it a Neighbor Acquisition Request. This message
+
+ should be repeatedly transmitted (at a reasonable rate, perhaps
+
+ once every 30 seconds or so) until a Neighbor Acquisition Reply
+
+ is received. The Request will contain an identification number
+
+ which is copied into the reply so that request and reply can be
+
+ matched up.
+
+
+ A gateway receiving a Neighbor Acquisition Request must
+
+ determine whether it wishes to become a direct neighbor of the
+
+ source of the Request. If not, it may, at its option, respond
+
+ with a Neighbor Acquisition Refusal message, optionally
+
+ specifying the reason for refusal. Otherwise, it should send a
+
+ Neighbor Acquisition Reply message. It must also send a Neighbor
+
+
+
+
+ - 8 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ Acquisition Request message, unless it has done so already.
+
+
+ Two gateways become direct neighbors when each has sent a
+
+ Neighbor Acquisition Message to, and received the corresponding
+
+ Neighbor Acquisition Reply from, the other.
+
+
+ Unmatched Replies or Refusals should be discarded after a
+
+ reasonable period of time. However, information about any such
+
+ unmatched messages may be useful for diagnostic purposes.
+
+
+ A Neighbor Acquisition Message from a gateway which is
+
+ already a direct neighbor should be responded to with a Reply and
+
+ a Neighbor Acquisition Message.
+
+
+ If a Neighbor Acquisition Reply is received from a
+
+ prospective neighbor, but a period of time passes during which no
+
+ Neighbor Acquisition Message is received from that prospective
+
+ neighbor, the neighbor acquisition protocol shall be deemed
+
+ incomplete. A Neighbor Cease message (see below) should then be
+
+ sent. If one gateway still desires to acquire the other as a
+
+ neighbor, the protocol must be repeated from the beginning.
+
+
+ If a gateway wishes to cease being a neighbor of a
+
+ particular exterior gateway, it sends a Neighbor Cease message.
+
+ A gateway receiving a Neighbor Cease message should always
+
+ respond with a Neighbor Cease Acknowledgment. It should cease to
+
+
+
+
+ - 9 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ treat the sender of the message as a neighbor in any way. Since
+
+ there is a significant amount of protocol run between direct
+
+ neighbors (see below), if some gateway no longer needs to be a
+
+ direct neighbor of some other, it is "polite" to indicate this
+
+ fact with a Neighbor Cease Message. The Neighbor Cease Message
+
+ should be retransmitted (up to some number of times) until an
+
+ acknowledgment for it is received.
+
+
+ Once a Neighbor Cease message has been received, the
+
+ Neighbor Reachability Protocol (below) should cease to be
+
+ executed.
+
+
+ NOTE THAT WE HAVE NOT SPECIFIED THE WAY IN WHICH ONE GATEWAY
+
+ INITIALLY DECIDES THAT IT WANTS TO BECOME A NEIGHBOR OF ANOTHER.
+
+ While this is hardly a trivial problem, it is not part of the
+
+ External Gateway Protocol.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - 10 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 3 NEIGHBOR REACHABILITY PROTOCOL
+
+
+ It is important for a gateway to keep real-time information
+
+ as to the reachability of its neighbors. If a gateway concludes
+
+ that a particular neighbor cannot be reached, it should cease
+
+ forwarding traffic to that gateway. To make that determination,
+
+ a NEIGHBOR REACHABILITY protocol is needed. The EGP protocol
+
+ provides two messages types for this purpose -- a "Hello" message
+
+ and an "I Heard You" message.
+
+
+ When a "Hello" message is received from a direct neighbor,
+
+ an "I Heard You" must be returned to that neighbor "immediately".
+
+ The delay between receiving a "Hello" and returning an "I Heard
+
+ You" should never be more than a few seconds.
+
+
+ At the current time, the reachability determination
+
+ algorithm is left to the designers of a particular gateway. We
+
+ have in mind algorithms like the following:
+
+
+ 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.
+
+
+
+
+
+ - 11 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ However, 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.
+
+
+ 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 one gateway to
+
+ 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". That is, the "passive" gateway (which sends only "I
+
+ Heard You"s) declares the "active" one (which sends only
+
+ "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 can only work if there is prior agreement as to
+
+ which neighbor is to be the active one. (Ways of coming to this
+
+
+
+
+ - 12 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ "prior agreement" are not part of the Exterior Gateway Protocol.)
+
+
+ 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. The neighbor 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" 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'.
+
+
+
+
+
+
+ - 13 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ "Hello" and "I Heard You" messages from gateway G to gateway
+
+ G' also carry the minimum interval in minutes with 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. 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 Gateway Going Down message to all direct neighbors
+
+ which will no longer be able to reach it. It should retransmit
+
+ that message (up to some number of times) until it receives a
+
+ Gateway Going Down Acknowledgment. This provides the neighbors
+
+ with an advance warning of an outage, and enables them to prepare
+
+ for it in a way which will minimize disruption to existing
+
+ traffic.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - 14 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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.
+
+
+ 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.
+
+
+
+ - 15 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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 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 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.
+
+
+
+ - 16 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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 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 procedure is necessary to ensure that networks which can no
+
+ longer be reached, but which are never explicitly declared
+
+ unreachable, are timed out and removed from the list of reachable
+
+ networks.
+
+
+ It may often be the case that where G and G' are exterior
+
+ neighbors on network N, G knows of many more gateway neighbors on
+
+ network N, and knows for which networks those other neighbors are
+
+ the appropriate first hop. Since 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 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. Gateways should be included in this list only
+
+ if G is actively running its neighbor reachability
+
+ protocol with them.
+
+
+
+
+
+ - 17 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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.
+
+
+ Thus the NR message provides a means of allowing a gateway
+
+ to "discover" new neighbors by seeing whether a neighbor that it
+
+ already knows of has any additional neighbors on the same
+
+ network. This information also makes possible the implementation
+
+ of the INDIRECT NEIGHBOR strategy defined below.
+
+
+ A more precise description of the NR message is the
+
+ following.
+
+
+ The data portion of the message will consist largely of
+
+ blocks of data. Each block will be headed by a gateway address,
+
+ which will be the address either of the gateway sending the
+
+ message or of one of that gateway's neighbors. Each gateway
+
+ address will be followed by a list of the networks for which that
+
+ gateway is an appropriate first hop, and the distance from that
+
+ gateway to each network.
+
+
+ Preceding the list of data blocks is:
+
+ a) The address of the network which this message is about.
+
+
+
+
+ - 18 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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 will include 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 follow 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.
+
+
+ Each block includes 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 either one, two, or
+
+ three bytes, depending on whether it is a class A, class B, or
+
+
+
+ - 19 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ class C network. No trailing bytes are used.
+
+
+ It may sometimes be necessary to fragment the NR message.
+
+ The NR message contains a byte indicating the number of this
+
+ fragment (fragments will be numbered from zero), and a byte
+
+ containing the number of the last fragment (NOT the number of
+
+ fragments). If fragmentation is not used, these bytes must both
+
+ be zero. EACH FRAGMENT MUST BE A FULLY SELF-CONTAINED NR
+
+ MESSAGE. That is, each fragment will begin with a count of
+
+ interior and exterior neighbors, and will have some integral
+
+ number of gateway data blocks. The number of data blocks in each
+
+ fragment must correspond to the neighbor counts at the beginning
+
+ of that fragment. However, only the first fragment should begin
+
+ with a data block describing the sending gateway.
+
+
+ This scheme enables each fragment to be processed
+
+ independently, and requires no complex reassembly mechanisms. It
+
+ also enables processing of a message all of whose fragments have
+
+ not been received. If, after some amount of time and some number
+
+ of retransmissions of a poll, not all fragments have been
+
+ received, the fragments which are present shall be processed as
+
+ if they constituted the complete NR message. (This means that
+
+ networks mentioned only in the missing fragment will retain the
+
+ "distance" values they had in the previous NR message from that
+
+ gateway. However, if no new value for a particular network is
+
+
+
+ - 20 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ received in the next NR message from that gateway, the network
+
+ will be declared unreachable.)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - 21 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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 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 Hello and I Heard You messages which gateway G
+
+ sends to gateway G' indicate the minimum interval which G will
+
+ accept as the polling interval from G'. That is, G' will not
+
+ guarantee to respond to polls from G that arrive less than that
+
+ interval apart.
+
+
+ Polls must only be sent to direct neighbors which are
+
+ declared reachable by the neighbor reachability protocol.
+
+
+ An NR Poll message contains an identification number chosen
+
+ by the polling gateway. The polled gateway will return this
+
+ number in the NR message it sends in response to the poll, to
+
+ enable the polling gateway to match up received NR messages with
+
+
+
+ - 22 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ polls. It will be the responsibility of the polling gateway to
+
+ choose an identification number which is sufficiently "unique" to
+
+ allow detection of out-of-date NR messages which may still be
+
+ floating around the network. Since polls are relatively
+
+ infrequent, this is not expected to be much of a problem.
+
+ However, to aid in choosing an identification number, the Hello
+
+ and I Heard You messages carry the identification number of the
+
+ last NR poll received from the neighbor to which they are being
+
+ sent.
+
+
+ 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 be dependent on the
+
+ characteristics of the two neighbors and of the network
+
+ connecting them.
+
+
+ If only some fragments of an NR message are received after
+
+ the maximum number of retransmissions, the fragments that are
+
+ present shall be treated as constituting the whole of the NR
+
+ message.
+
+
+
+
+
+ - 23 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - 24 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 6 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
+
+ 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 facilitate the sending of unsolicited NR messages, the NR
+
+ poll message has a byte indicating the polling interval in
+
+ minutes.
+
+
+
+
+
+ - 25 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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".
+
+
+ Duplicated polls (successive polls with the same
+
+ identification number) should be responded to with duplicates of
+
+ the same NR message. If that message is fragmented, the same
+
+ fragments shall be sent each time. Note that there is no
+
+ provision for handling multiple outstanding polls from a single
+
+ neighbor. NOTE THAT IF THE SAME FRAGMENTS ARE NOT SENT IN
+
+ RESPONSE TO DUPLICATED POLLS, INCORRECT REASSEMBLY WILL BE THE
+
+ PROBABLE RESULT. If fragmentation is not being used, however,
+
+ then no harm should result from responding to a duplicate poll
+
+ with a different (presumably more recent) NR message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - 26 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 7 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. Suppose, however, that gateway G receives an NR
+
+ message from G', in which G' indicates the presence of other
+
+ neighbors G1, ..., Gn, each of which 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, since it is a neighbor of
+
+ these other gateways for the purpose of forwarding traffic, but
+
+ does not perform neighbor acquisition, neighbor reachability, or
+
+ exchange of NR messages with them. Neighbor and network
+
+ reachability information is obtained indirectly via G', hence the
+
+ designation "indirect neighbor". 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', G
+
+ should treat G' as having become unreachable.
+
+
+
+
+
+
+
+ - 27 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 8 HOW TO BE A STUB GATEWAY
+
+
+ The most common application of EGP will probably be its use
+
+ to enable a stub gateway to communicate with one of the DARPA
+
+ core gateways, so as to enable data flow between networks
+
+ accessible only via the stub and networks accessible only via the
+
+ system of core gateways. As discussed previously, a stub gateway
+
+ can be considered to be a one-gateway internet system with no
+
+ interior neighbors. It is probably used to interface a local
+
+ network or networks to a long range transport network (such as
+
+ ARPANET or SATNET) on which there is a core gateway. In this
+
+ case, the stub will not want the core gateways to forward it any
+
+ traffic other than traffic which is destined for the network or
+
+ networks which can be reached only via the stub. In general, the
+
+ stub will not want to perform any services for the internet
+
+ transport system which are not needed in order to be able to pass
+
+ traffic to and from the networks that cannot be otherwise
+
+ reached.
+
+
+ The stub should have tables configured in with the addresses
+
+ of a small number of the core gateways (no more than two or
+
+ three) with which it has a common network. It will be the
+
+ responsibility of the stub to initiate neighbor acquisition with
+
+ these gateways. When a stub and a core gateway become direct
+
+ neighbors, the core gateway will begin sending Hello messages.
+
+
+
+ - 28 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ When the stub declares the core gateways which are direct
+
+ neighbors to be reachable, it should poll those gateways for NR
+
+ messages at a rate not to exceed once per minute (or as specified
+
+ in the Hello messages from the core gateways). The core gateways
+
+ will also poll the stub for NR messages.
+
+
+ The NR message sent by the stub should be the simplest
+
+ allowable. That is, 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. These will be just the networks
+
+ that can be reached no other way, in general.
+
+
+ The core gateways will send complete NR messages, containing
+
+ information about all other gateways on the common networks, 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 of all these other gateways.
+
+ That is, the stub shall forward traffic directly to these other
+
+ gateways as appropriate, but shall not become direct neighbors
+
+ with them.
+
+
+ The core gateways will report distances less than 128 if the
+
+ network can be reached without leaving the core system (i.e.,
+
+
+
+
+ - 29 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ without traversing any gateway other than a core gateway), and
+
+ greater than or equal to 128 otherwise.
+
+
+ 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.
+
+
+ If the direct neighbors of a stub should all fail, it will
+
+ be the responsibility of the stub to acquire at least one new
+
+ direct neighbor. It can do so by choosing one of the core
+
+ gateways which it has had as an indirect neighbor, and executing
+
+ the neighbor acquisition protocol with it. (It is possible that
+
+ no more than one core gateway will ever agree to become a direct
+
+ neighbor with any given stub gateway at any one time.)
+
+
+ If the stub gateway does not respond in a timely manner to
+
+ Hello messages from the core gateway, it may be declared
+
+ unreachable. If it does not respond to NR poll messages in a
+
+ timely manner, its networks may be declared unreachable. In both
+
+ these cases, the core gateways may discard traffic destined for
+
+
+
+
+ - 30 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ those networks, returning ICMP "destination network unreachable"
+
+ to the source hosts.
+
+
+ The stub gateway is expected to fully execute the ICMP
+
+ protocol, 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - 31 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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 of the set of autonomous systems is not tree-structured
+
+ (i.e., if it has cycles), 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - 32 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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 # !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Description:
+
+ The Neighbor Acquisition messages are used by interior and
+ exterior gateways to become neighbors of each other.
+
+ EGP Version #
+
+ 1
+
+ Type
+
+ 3
+
+ Code
+
+ 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 Acknowledgment
+
+ 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. For computing the checksum, the
+ checksum field should be zero.
+
+ Autonomous System #
+
+ This 16-bit number identifies the autonomous system
+ containing the gateway which is the source of this message.
+
+
+
+ - 33 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ Info
+
+ For Refusal message, gives reason for refusal:
+
+ 0 Unspecified
+ 1 Out of table space
+ 2 Administrative prohibition
+
+ For Cease message, gives reason for ceasing to be neighbor:
+
+ 0 Unspecified
+ 1 Going down
+ 2 No longer needed
+
+ Otherwise, this field MUST be zero.
+
+ Identification Number
+
+ An identification number to aid in matching requests and
+ replies.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - 34 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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 # !
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Description:
+
+ Exterior neighbors use EGP Neighbor Hello and I Heard You
+ Messages to determine neighbor connectivity. When a gateway
+ receives an EGP Neighbor Hello message from a neighbor it
+ should respond with an EGP I Heard You message.
+
+ EGP Version #
+
+ 1
+
+ Type
+
+ 5
+
+ Code
+
+ Code = 0 for Hello
+ Code = 1 for I Heard you
+
+ 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. For computing the checksum, the
+ checksum field should be zero.
+
+ Autonomous System #
+
+ This 16-bit number identifies the autonomous system
+ containing the gateway which is the source of this message.
+
+
+
+
+ - 35 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ Sequence Number
+
+ A sequence number to aid in matching requests and replies.
+
+ Status
+
+ 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
+
+ Last Poll Id Number
+
+ The identification number of the most recently received
+ NR poll message from the neighbor to which this message
+ is being sent.
+
+ Minimum Polling Interval
+
+ This gateway should not be polled for NR messages more
+ often than once in this number of minutes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - 36 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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 will send 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 #
+
+ 1
+
+ Type
+
+ 2
+
+ Code
+
+ 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. For computing the checksum, the
+ checksum field should be zero.
+
+ Autonomous System #
+
+ This 16-bit number identifies the autonomous system
+ containing the gateway which is the source of this message.
+
+
+
+
+ - 37 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ Identification Number
+
+ An identification number to aid in matching requests and
+ replies.
+
+ 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.
+
+ Interval
+
+ The polling interval in minutes.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - 38 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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 !
+ +-+-+-+-+-+-+-+-+
+
+
+
+
+
+ - 39 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! net n,2 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes
+ +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! distance ! .
+ +-+-+-+-+-+-+-+-+ .
+
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ ! net n,m !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; m nets reachable
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ; via Gateway n
+ ! distance !
+ +-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - 40 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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.
+
+ EGP Version #
+
+ 1
+
+ Type
+
+ 1
+
+ Code
+
+ 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. For computing the checksum, the
+ checksum field should be zero.
+
+ Autonomous System #
+
+ This 16-bit number identifies the autonomous system
+ containing the gateway which is the source of this message.
+
+ U (Unsolicited) bit
+
+ This bit is set if the NR message is being sent unsolicited.
+
+
+ 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 is used to aid in matching polls and
+ replies.
+
+ Fragment Number
+
+ Which Fragment this is in the NR Message. Zero, if
+ fragmentation is not used.
+
+
+
+
+ - 41 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ Number of Last Fragment
+
+ Number of the last fragment in the NR Message. 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 network which can be
+ reached via the preceding gateway.
+
+ Distance
+
+ 1 byte of distance in # of hops.
+
+
+
+
+
+
+
+
+
+
+
+
+ - 42 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ 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.
+
+ EGP Version #
+
+ 1
+
+ Type
+
+ 8
+
+ Code
+
+ 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. For computing the checksum, the
+ checksum field should be zero.
+
+ Autonomous System #
+
+ This 16-bit number identifies the autonomous system
+ containing the gateway which is the source of this message.
+
+
+
+
+
+
+
+ - 43 -
+
+
+ RFC 827 Bolt Beranek and Newman Inc.
+ Eric C. Rosen
+
+
+
+ Sequence Number
+
+ A sequence number assigned by the gateway sending 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+ - 44 -
+
+