GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc827
                                                             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
  1. 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:
  1. the overhead of the routing algorithm becomes excessively
          large;
  1. 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;
  1. 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. 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
  1. 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
  1. 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
  1. 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
  1. 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.
  1. 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.
  1. 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
  1. 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
  1. 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.
  1. 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.
  1. 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
  1. 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'.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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
  1. 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
  1. 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.)
  1. 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
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.,
  1. 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
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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.
  1. 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
   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.
  1. 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.
  1. 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      !
   +-+-+-+-+-+-+-+-+
  1. 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      !
   +-+-+-+-+-+-+-+-+
  1. 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
   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.
  1. 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.
  1. 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
   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.
  1. 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
  1. 44 -
/data/webs/external/dokuwiki/data/pages/rfc/rfc827.txt · Last modified: 1991/10/17 17:49 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki