home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc888 < prev    next >
Text File  |  1991-04-21  |  53KB  |  2,359 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.                                   RFC 888
  18.  
  19.  
  20.                      "STUB" EXTERIOR GATEWAY PROTOCOL
  21.  
  22.  
  23.                             Linda J. Seamonson
  24.  
  25.                                Eric C. Rosen
  26.  
  27.  
  28.                             BBN Communications
  29.  
  30.  
  31.                                January 1984
  32.  
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42. This note describes the Exterior Gateway Protocol used to connect Stub
  43. Gateways to an Autonomous System of core Gateways.  This document specifies
  44. the working protocol, and defines an ARPA official protocol.  All
  45. implementers of Gateways should carefully review this document.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.  
  59.  
  60.  
  61.  
  62.      RFC 888                                              JANUARY 1984
  63.  
  64.  
  65.  
  66.                              Table of Contents
  67.  
  68.  
  69.  
  70.  
  71.  
  72.      1   INTRODUCTION.......................................... 1
  73.  
  74.      2   DEFINITIONS AND OVERVIEW.............................. 4
  75.  
  76.      3   NEIGHBOR ACQUISITION.................................. 7
  77.  
  78.      4   NEIGHBOR REACHABILITY PROTOCOL....................... 10
  79.  
  80.      5   NETWORK REACHABILITY (NR) MESSAGE.................... 15
  81.  
  82.      6   POLLING FOR NR MESSAGES.............................. 22
  83.  
  84.      7   SENDING NR MESSAGES.................................. 24
  85.  
  86.      8   INDIRECT NEIGHBORS................................... 26
  87.  
  88.      9   LIMITATIONS.......................................... 27
  89.  
  90.      A   APPENDIX A - EGP MESSAGE FORMATS..................... 28
  91.      A.1   NEIGHBOR ACQUISITION MESSAGE....................... 28
  92.      A.2   NEIGHBOR HELLO/I HEARD YOU MESSAGE................. 30
  93.      A.3   NR POLL MESSAGE.................................... 32
  94.      A.4   NETWORK REACHABILITY MESSAGE....................... 34
  95.      A.5   EGP ERROR MESSAGE.................................. 37
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.                                    - i -
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.      RFC 888                                              JANUARY 1984
  123.  
  124.  
  125.  
  126.      1  INTRODUCTION
  127.  
  128.  
  129.           The DARPA Catenet is expected to be a continuously expanding
  130.  
  131.      system,  with  more  and  more  hosts  on  more and more networks
  132.  
  133.      participating in it.  Of course, this will require more and  more
  134.  
  135.      gateways.   In  the  past,  such  expansion  has taken place in a
  136.  
  137.      relatively unstructured manner.  New gateways,  often  containing
  138.  
  139.      radically different software than the existing gateways, would be
  140.  
  141.      added and would immediately begin  participating  in  the  common
  142.  
  143.      routing algorithm via the GGP protocol.  However, as the internet
  144.  
  145.      grows larger and larger, this simple method of expansion  becomes
  146.  
  147.      less and less feasible.  There are a number of reasons for this:
  148.  
  149.  
  150.  
  151.           - the overhead of the routing algorithm becomes  excessively
  152.  
  153.             large;
  154.  
  155.  
  156.           - the  proliferation   of   radically   different   gateways
  157.  
  158.             participating  in  a single common routing algorithm makes
  159.  
  160.             maintenance and fault isolation nearly  impossible,  since
  161.  
  162.             it  becomes  impossible to regard       the internet as an
  163.  
  164.             integrated communications system;
  165.  
  166.  
  167.           - the  gateway  software  and  algorithms,  especially   the
  168.  
  169.             routing  algorithm, become too rigid and inflexible, since
  170.  
  171.  
  172.  
  173.                                    - 1 -
  174.  
  175.  
  176.  
  177.  
  178.  
  179.  
  180.  
  181.      RFC 888                                              JANUARY 1984
  182.  
  183.  
  184.  
  185.             any proposed change  must be made in  too  many  different
  186.  
  187.             places   and   by   too   many   different        people.
  188.  
  189.  
  190.  
  191.  
  192.           In the future, the internet is expected to evolve into a set
  193.  
  194.      of  separate  sections or  "autonomous  systems",  each  of which
  195.  
  196.      consists of a set of one or more relatively homogeneous gateways.
  197.  
  198.      The  protocols,  and  in  particular  the routing algorithm which
  199.  
  200.      these gateways use among themselves, will be  a  private  matter,
  201.  
  202.      and  need never be implemented in gateways outside the particular
  203.  
  204.      sections or system.
  205.  
  206.  
  207.           In the simplest case, an autonomous system might consist  of
  208.  
  209.      just a single gateway connecting, for example, a local network to
  210.  
  211.      the ARPANET.  Such a gateway might be called  a  "stub  gateway",
  212.  
  213.      since  its  only purpose is to interface the local network to the
  214.  
  215.      rest of the internet, and it is  not  intended  to  be  used  for
  216.  
  217.      handling  any traffic which neither originated in nor is destined
  218.  
  219.      for that particular local network.  In the near-term  future,  we
  220.  
  221.      will  begin  to  think  of  the  internet  as a set of autonomous
  222.  
  223.      systems, one of which consists of the DARPA gateways  on  ARPANET
  224.  
  225.      and  SATNET,  and  the others of which are stub gateways to local
  226.  
  227.      networks.   The former system, which we  shall  call  the  "core"
  228.  
  229.  
  230.  
  231.  
  232.                                    - 2 -
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.      RFC 888                                              JANUARY 1984
  241.  
  242.  
  243.  
  244.      system,  will be used as a transport or "long-haul" system by the
  245.  
  246.      latter systems.
  247.  
  248.  
  249.           Ultimately, the internet may consist of a number of co-equal
  250.  
  251.      autonomous  systems,  any  of  which  may  be used as a transport
  252.  
  253.      medium for traffic originating in any system and destined for any
  254.  
  255.      system.  This more general case is still the subject of research.
  256.  
  257.      This paper describes only how stub gateways connect to  the  core
  258.  
  259.      system using the Exterior Gateway Protocol (EGP).
  260.  
  261.  
  262.  
  263.  
  264.  
  265.  
  266.  
  267.  
  268.  
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282.  
  283.  
  284.  
  285.  
  286.  
  287.  
  288.  
  289.  
  290.  
  291.                                    - 3 -
  292.  
  293.  
  294.  
  295.  
  296.  
  297.  
  298.  
  299.      RFC 888                                              JANUARY 1984
  300.  
  301.  
  302.  
  303.      2  DEFINITIONS AND OVERVIEW
  304.  
  305.  
  306.           For the purposes of this paper, a "stub gateway" is  defined
  307.  
  308.      as follows:
  309.  
  310.  
  311.           - it is not a core gateway
  312.  
  313.           - it shares a network with at least one core gateway (has an
  314.  
  315.             interface on the same network as some core gateway)
  316.  
  317.           - it has interfaces to one or more networks  which  have  no
  318.  
  319.             core gateways
  320.  
  321.           - all other nets which are reachable from  the  core  system
  322.  
  323.             via  the stub have no other path to the core system except
  324.  
  325.             via the stub
  326.  
  327.  
  328.  
  329.           The stub gateway is expected to fully execute  the  Internet
  330.  
  331.      Control Message Protocol (ICMP), as well as the EGP protocol.  In
  332.  
  333.      particular, it must respond to ICMP echo requests, and must  send
  334.  
  335.      ICMP  destination  dead  messages  as  appropriate.   It  is also
  336.  
  337.      required to send ICMP Redirect messages as appropriate.
  338.  
  339.  
  340.  
  341.           Autonomous systems will be  assigned  16-bit  identification
  342.  
  343.      numbers  (in  much  the same ways as network and protocol numbers
  344.  
  345.      are now assigned), and every EGP message header contains a  field
  346.  
  347.  
  348.  
  349.  
  350.                                    - 4 -
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.      RFC 888                                              JANUARY 1984
  359.  
  360.  
  361.  
  362.      for  this  number.   Zero  will not be assigned to any autonomous
  363.  
  364.      system; the use  of  zero  as  an  autonomous  system  number  is
  365.  
  366.      reserved for future use.
  367.  
  368.  
  369.           We call two gateways "neighbors" if there is  a  network  to
  370.  
  371.      which  each  has  an interface.  If two neighbors are part of the
  372.  
  373.      same autonomous system, we  call  them  INTERIOR  NEIGHBORS;  for
  374.  
  375.      example,  any  two core gateways on the same network are interior
  376.  
  377.      neighbors of each other.  If two neighbors are not  part  of  the
  378.  
  379.      same  autonomous  system,  we  call  them EXTERIOR NEIGHBORS; for
  380.  
  381.      example, a stub gateway and any core gateway that share a network
  382.  
  383.      are exterior neighbors of each other.  In order for one system to
  384.  
  385.      use another as a transport medium, gateways  which  are  exterior
  386.  
  387.      neighbors  of  each other must be able to find out which networks
  388.  
  389.      can be reached through the other.  The Exterior Gateway  Protocol
  390.  
  391.      enables this information to be passed between exterior neighbors.
  392.  
  393.      Since it is a polling protocol, it also enables each  gateway  to
  394.  
  395.      control   the  rate  at  which  it  sends  and  receives  network
  396.  
  397.      reachability information, allowing each system to control its own
  398.  
  399.      overhead.   It  also  enables  each system to have an independent
  400.  
  401.      routing algorithm whose operation cannot be disrupted by failures
  402.  
  403.      of other systems.
  404.  
  405.  
  406.  
  407.  
  408.  
  409.                                    - 5 -
  410.  
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.      RFC 888                                              JANUARY 1984
  418.  
  419.  
  420.  
  421.           The Exterior Gateway Protocol has three parts: (a)  Neighbor
  422.  
  423.      Acquisition Protocol, (b) Neighbor Reachability Protocol, and (c)
  424.  
  425.      Network  Reachability  determination.   Note  that  all  messages
  426.  
  427.      defined  by EGP are intended to travel only a single "hop".  That
  428.  
  429.      is, they originate at one gateway and are sent to  a  neighboring
  430.  
  431.      gateway   without  the  mediation  of  any  intervening  gateway.
  432.  
  433.      Therefore, the time-to-live field should be set to a  very  small
  434.  
  435.      value.   Gateways  which  encounter EGP messages in their message
  436.  
  437.      streams which are not addressed to them may discard them.
  438.  
  439.  
  440.           Each EGP message contains a sequence  number.   The  gateway
  441.  
  442.      should maintain one sequence number per neighbor.
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.                                    - 6 -
  469.  
  470.  
  471.  
  472.  
  473.  
  474.  
  475.  
  476.      RFC 888                                              JANUARY 1984
  477.  
  478.  
  479.  
  480.      3  NEIGHBOR ACQUISITION
  481.  
  482.  
  483.           Before it is possible to obtain routing information from  an
  484.  
  485.      exterior  gateway,  it  is necessary to acquire that gateway as a
  486.  
  487.      direct neighbor.  (The distinction between  direct  and  indirect
  488.  
  489.      neighbors  will  be  made  in a later section.)  In order for two
  490.  
  491.      gateways to become direct neighbors, they must be  neighbors,  in
  492.  
  493.      the  sense  defined  above,  and  they  must execute the NEIGHBOR
  494.  
  495.      ACQUISITION  PROTOCOL,  which  is  simply  a   standard   two-way
  496.  
  497.      handshake.
  498.  
  499.  
  500.           A gateway that wishes to initiate neighbor acquisition  with
  501.  
  502.      another  sends  it  a Neighbor Acquisition Request.  This message
  503.  
  504.      should be repeatedly transmitted (at a reasonable  rate,  perhaps
  505.  
  506.      once  every  30 seconds or so) until a Neighbor Acquisition Reply
  507.  
  508.      or a Neighbor Acquisition Refusal is received.  The Request  will
  509.  
  510.      contain  an  identification number which is copied into the reply
  511.  
  512.      so that request and reply can be matched up.
  513.  
  514.  
  515.           A gateway receiving  a  Neighbor  Acquisition  Request  must
  516.  
  517.      determine  whether  it  wishes to become a direct neighbor of the
  518.  
  519.      source of the Request.  If not, it may, at  its  option,  respond
  520.  
  521.      with   a   Neighbor   Acquisition   Refusal  message,  optionally
  522.  
  523.      specifying the reason for refusal.  Otherwise, it should  send  a
  524.  
  525.  
  526.  
  527.                                    - 7 -
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.      RFC 888                                              JANUARY 1984
  536.  
  537.  
  538.  
  539.      Neighbor Acquisition Reply message.
  540.  
  541.  
  542.           The gateway  that  sent  the  Request  should  consider  the
  543.  
  544.      Neighbor Acquisition complete when it has received the neighbor's
  545.  
  546.      Reply.  The gateway that  sent  the  Reply  should  consider  the
  547.  
  548.      acquisition complete when it has sent the Reply.
  549.  
  550.  
  551.           Unmatched Replies or Refusals should be  discarded  after  a
  552.  
  553.      reasonable  period  of time.  However, information about any such
  554.  
  555.      unmatched messages may be useful for diagnostic purposes.
  556.  
  557.  
  558.           A Neighbor Acquisition  Request  from  a  gateway  which  is
  559.  
  560.      already a direct neighbor should be responded to with a Reply.
  561.  
  562.  
  563.           A Neighbor Acquisition Request or Reply from  gateway  G  to
  564.  
  565.      gateway  G'  carries the minimum interval in seconds with which G
  566.  
  567.      is willing to answer Neighbor Reachability Hello Messages from G'
  568.  
  569.      and the minimum interval in seconds with which G is willing to be
  570.  
  571.      polled for NR messages (see below).
  572.  
  573.  
  574.           If  a  gateway  wishes  to  cease  being  a  neighbor  of  a
  575.  
  576.      particular  exterior  gateway, it sends a Neighbor Cease message.
  577.  
  578.      A gateway  receiving  a  Neighbor  Cease  message  should  always
  579.  
  580.      respond with a Neighbor Cease Acknowledgment.  It should cease to
  581.  
  582.      treat the sender of the message as a neighbor in any way.   Since
  583.  
  584.  
  585.  
  586.                                    - 8 -
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.      RFC 888                                              JANUARY 1984
  595.  
  596.  
  597.  
  598.      there  is  a  significant  amount  of protocol run between direct
  599.  
  600.      neighbors (see below), if some gateway no longer needs  to  be  a
  601.  
  602.      direct  neighbor  of  some other, it is "polite" to indicate this
  603.  
  604.      fact with a Neighbor Cease Message.  The Neighbor  Cease  Message
  605.  
  606.      should  be  retransmitted  (up  to some number of times) until an
  607.  
  608.      acknowledgment for it is received.
  609.  
  610.  
  611.           Once  a  Neighbor  Cease  message  has  been  received,  the
  612.  
  613.      Neighbor   Reachability  Protocol  (below)  should  cease  to  be
  614.  
  615.      executed.
  616.  
  617.  
  618.           A stub should have tables configured in with  the  addresses
  619.  
  620.      of  a  small  number  of  the  core gateways (no more than two or
  621.  
  622.      three) with which it has  a  common  network.   It  will  be  the
  623.  
  624.      responsibility  of the stub to initiate neighbor acquisition with
  625.  
  626.      these gateways.  If the direct neighbors of  a  stub  should  all
  627.  
  628.      fail,  it  will  be  the responsibility of the stub to acquire at
  629.  
  630.      least one new direct neighbor.  It can do so by choosing  one  of
  631.  
  632.      the  core  gateways which it has had as an indirect neighbor (see
  633.  
  634.      below), and executing the neighbor acquisition protocol with  it.
  635.  
  636.      (It  is  possible  that  no  more than one core gateway will ever
  637.  
  638.      agree to become a direct neighbor with any given stub gateway  at
  639.  
  640.      any one time.)
  641.  
  642.  
  643.  
  644.  
  645.                                    - 9 -
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.      RFC 888                                              JANUARY 1984
  654.  
  655.  
  656.  
  657.      4  NEIGHBOR REACHABILITY PROTOCOL
  658.  
  659.  
  660.           It is important for a gateway to keep real-time  information
  661.  
  662.      as  to the reachability of its neighbors.  If a gateway concludes
  663.  
  664.      that a particular neighbor cannot be  reached,  it  should  cease
  665.  
  666.      forwarding  traffic to that gateway.  To make that determination,
  667.  
  668.      a NEIGHBOR REACHABILITY protocol is  needed.   The  EGP  protocol
  669.  
  670.      provides two messages types for this purpose -- a "Hello" message
  671.  
  672.      and an "I Heard You" message.
  673.  
  674.  
  675.           When a "Hello" message is received from a  direct  neighbor,
  676.  
  677.      an "I Heard You" must be returned to that neighbor "immediately".
  678.  
  679.      The delay between receiving a "Hello" and returning an  "I  Heard
  680.  
  681.      You" should never be more than a few seconds.
  682.  
  683.  
  684.           Core  gateways  will  use  the   following   algorithm   for
  685.  
  686.      determining reachablility of an exterior neighbor:
  687.  
  688.  
  689.           A reachable  neighbor  shall  be  declared  unreachable  if,
  690.  
  691.      during  the  time  in  which  the  core  gateway  sent its last n
  692.  
  693.      "Hello"s, it received fewer than k "I Heard You"s in return.   An
  694.  
  695.      unreachable  neighbor  shall be declared reachable if, during the
  696.  
  697.      time in which the core gateway  sent  its  last  m  "Hello"s,  it
  698.  
  699.      received at least j "I Heard You"s in return.
  700.  
  701.  
  702.  
  703.  
  704.                                   - 10 -
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.      RFC 888                                              JANUARY 1984
  713.  
  714.  
  715.  
  716.           Stub  gateways  may  also  send  "Hello"s  to  their  direct
  717.  
  718.      neighbors  and  receive  "I Heard You"s in return.  The algorithm
  719.  
  720.      for determining reachability may  be  similar  to  the  algorithm
  721.  
  722.      described  above.  However, it is not necessary for stubs to send
  723.  
  724.      "Hello"s.  The "Hello" and "I Heard You" messages have  a  status
  725.  
  726.      field  which  the  sending  gateway  uses  to indicate whether it
  727.  
  728.      thinks  the  receiving  gateway  is  reachable  or   not.    This
  729.  
  730.      information  can  be  useful  for  diagnostic  purposes.  It also
  731.  
  732.      allows a stub gateway  to  make  its  reachability  determination
  733.  
  734.      parasitic  on  its  core neighbor: only the core gateway actually
  735.  
  736.      needs to send "Hello" messages, and the stub can declare it up or
  737.  
  738.      down based on the status field in the "Hello".  That is, the stub
  739.  
  740.      gateway (which sends only  "I  Heard  You"s)  declares  the  core
  741.  
  742.      gateway  (which  sends  only  "Hello"s)  to be reachable when the
  743.  
  744.      "Hello"s from the core indicate that it has declared the stub  to
  745.  
  746.      be reachable.
  747.  
  748.  
  749.           The frequency with which the  "Hello"s  are  sent,  and  the
  750.  
  751.      values of the parameters k, n, j, and m cannot be specified here.
  752.  
  753.      For best results, this will depend on the characteristics of  the
  754.  
  755.      neighbor  and  of the network which the neighbors have in common.
  756.  
  757.      THIS IMPLIES THAT THE PROPER PARAMETERS MAY NEED TO BE DETERMINED
  758.  
  759.      JOINTLY  BY THE DESIGNERS AND IMPLEMENTERS OF THE TWO NEIGHBORING
  760.  
  761.  
  762.  
  763.                                   - 11 -
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.      RFC 888                                              JANUARY 1984
  772.  
  773.  
  774.  
  775.      GATEWAYS;  choosing  algorithms  and  parameters  in   isolation,
  776.  
  777.      without  considering  the characteristics of the neighbor and the
  778.  
  779.      connecting network, would not be expected to  result  in  optimum
  780.  
  781.      reachability determinations.
  782.  
  783.  
  784.           However, the Neighbor Acquisition Request and Reply messages
  785.  
  786.      provide  neighbors with a way to inform each other of the minimum
  787.  
  788.      frequency at which they  are  willing  to  answer  Hellos.   When
  789.  
  790.      gateway  G sends a Neighbor Acquisition Request to gateway G', it
  791.  
  792.      states that it does not  wish  to  answer  Hellos  from  G'  more
  793.  
  794.      frequently  than  once  every  X  seconds.   G'  in  its Neighbor
  795.  
  796.      Acquisition Reply states that it does not wish to  answer  Hellos
  797.  
  798.      from  G  more  frequently  than  once  every  Y seconds.  The two
  799.  
  800.      frequencies do not have to be the same, but  each  neighbor  must
  801.  
  802.      conform  to  the  interval requested by the other.  A gateway may
  803.  
  804.      send Hellos less frequently than requested, but not more.
  805.  
  806.  
  807.           A  direct  neighbor  gateway   should   also   be   declared
  808.  
  809.      unreachable  if  the  network  connecting it supplies lower level
  810.  
  811.      protocol information from which this can be deduced.   Thus,  for
  812.  
  813.      example,  if  a gateway receives an 1822 Destination Dead message
  814.  
  815.      from the ARPANET which indicates that a direct neighbor is  dead,
  816.  
  817.      it should declare that neighbor unreachable.  The neighbor should
  818.  
  819.  
  820.  
  821.  
  822.                                   - 12 -
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.      RFC 888                                              JANUARY 1984
  831.  
  832.  
  833.  
  834.      not be declared reachable again until  the  requisite  number  of
  835.  
  836.      Hello/I-Heard-You packets have been exchanged.
  837.  
  838.  
  839.           A direct neighbor which  has  become  unreachable  does  not
  840.  
  841.      thereby  cease  to  be  a  direct  neighbor.  The neighbor can be
  842.  
  843.      declared reachable again without  any  need  to  go  through  the
  844.  
  845.      neighbor  acquisition  protocol  again.  However, if the neighbor
  846.  
  847.      remains unreachable for an extremely long period of time, such as
  848.  
  849.      an  hour,  the  gateway  should  cease to treat it as a neighbor,
  850.  
  851.      i.e., should cease sending Hello messages to  it.   The  neighbor
  852.  
  853.      acquisition  protocol  would  then  need to be repeated before it
  854.  
  855.      could become a direct neighbor again.
  856.  
  857.  
  858.           "Hello" messages from sources other  than  direct  neighbors
  859.  
  860.      should  simply  be ignored.  However, logging the presence of any
  861.  
  862.      such messages might provide useful diagnostic information.
  863.  
  864.  
  865.           A gateway which is going down, or  whose  interface  to  the
  866.  
  867.      network which connects it to a particular neighbor is going down,
  868.  
  869.      should send a Neighbor Cease  message  to  all  direct  neighbors
  870.  
  871.      which  will  no  longer  be  able to reach it.  The Cease message
  872.  
  873.      should use the info field to specify the reason as "going  down".
  874.  
  875.      It  should  retransmit  that message (up to some number of times)
  876.  
  877.      until it receives a Neighbor Cease Acknowledgment.  This provides
  878.  
  879.  
  880.  
  881.                                   - 13 -
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.      RFC 888                                              JANUARY 1984
  890.  
  891.  
  892.  
  893.      the  neighbors  with an advance warning of an outage, and enables
  894.  
  895.      them to prepare for it in a way which will minimize disruption to
  896.  
  897.      existing traffic.
  898.  
  899.  
  900.  
  901.  
  902.  
  903.  
  904.  
  905.  
  906.  
  907.  
  908.  
  909.  
  910.  
  911.  
  912.  
  913.  
  914.  
  915.  
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.                                   - 14 -
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.      RFC 888                                              JANUARY 1984
  949.  
  950.  
  951.  
  952.      5  NETWORK REACHABILITY (NR) MESSAGE
  953.  
  954.  
  955.           Terminology: Let gateway G have an interface to  network  N.
  956.  
  957.      We  say  that G is AN APPROPRIATE FIRST HOP to network M relative
  958.  
  959.      to network N (where M and N are distinct networks) if and only if
  960.  
  961.      the following condition holds:
  962.  
  963.  
  964.           Traffic which is destined for network M, and  which  arrives
  965.  
  966.           at gateway G over its network N interface, will be forwarded
  967.  
  968.           to M by G over a path  which  does  not  include  any  other
  969.  
  970.           gateway with an interface to network N.
  971.  
  972.  
  973.           In short, G is  an  appropriate  first  hop  for  network  M
  974.  
  975.      relative  to network N just in case there is no better gateway on
  976.  
  977.      network N through which to route traffic which  is  destined  for
  978.  
  979.      network  M.   For  optimal routing, traffic in network N which is
  980.  
  981.      destined for network M ought always to be forwarded to a  gateway
  982.  
  983.      which is an appropriate first hop.
  984.  
  985.  
  986.           In  order  for  exterior  neighbors  G  and  G'  (which  are
  987.  
  988.      neighbors  over network N) to be able to use each other as packet
  989.  
  990.      switches for forwarding traffic to remote networks, each needs to
  991.  
  992.      know  the  list of networks for which the other is an appropriate
  993.  
  994.      first hop.  The Exterior  Gateway  Protocol  defines  a  message,
  995.  
  996.  
  997.  
  998.  
  999.                                   - 15 -
  1000.  
  1001.  
  1002.  
  1003.  
  1004.  
  1005.  
  1006.  
  1007.      RFC 888                                              JANUARY 1984
  1008.  
  1009.  
  1010.  
  1011.      called  the  Network  Reachability  Message  (or NR message), for
  1012.  
  1013.      transferring this information.
  1014.  
  1015.  
  1016.           Let G be a gateway on network N.  Then the NR message  which
  1017.  
  1018.      G sends about network N must contain the following information:
  1019.  
  1020.  
  1021.           A list of all the networks for which  G  is  an  appropriate
  1022.  
  1023.           first hop relative to network N.
  1024.  
  1025.  
  1026.      If G' can obtain this information from exterior neighbor G,  then
  1027.  
  1028.      it  knows  that no traffic destined for networks which are NOT in
  1029.  
  1030.      that list should be forwarded to G.  (It cannot simply  conclude,
  1031.  
  1032.      however,  that all traffic for any networks in that list ought to
  1033.  
  1034.      be forwarded via G, since G' may also have other neighbors  which
  1035.  
  1036.      are also appropriate first hops to network N.  For example, G and
  1037.  
  1038.      G'' might each be neighbors of G',  but  might  be  "equidistant"
  1039.  
  1040.      from  some  network  M.   Then each could be an appropriate first
  1041.  
  1042.      hop.)
  1043.  
  1044.  
  1045.           For each network in the list, the NR message also  specifies
  1046.  
  1047.      the "distance" (according to some metric whose definition is left
  1048.  
  1049.      to the designers of the autonomous system of which gateway G is a
  1050.  
  1051.      member)  from  G  to  that  network.   Core  gateways will report
  1052.  
  1053.      distances less than 128 for networks that can be reached  without
  1054.  
  1055.  
  1056.  
  1057.  
  1058.                                   - 16 -
  1059.  
  1060.  
  1061.  
  1062.  
  1063.  
  1064.  
  1065.  
  1066.      RFC 888                                              JANUARY 1984
  1067.  
  1068.  
  1069.  
  1070.      leaving  the  core  system,  and  greater  than  or  equal to 128
  1071.  
  1072.      otherwise.  A stub gateway should report distances less than  128
  1073.  
  1074.      for all networks listed in its NR messages.
  1075.  
  1076.  
  1077.           The maximum value of distance (255.) shall be taken to  mean
  1078.  
  1079.      that  the network is UNREACHABLE.  ALL OTHER VALUES WILL BE TAKEN
  1080.  
  1081.      TO MEAN THAT THE NETWORK IS REACHABLE.
  1082.  
  1083.  
  1084.           If an NR message from some gateway G fails to  mention  some
  1085.  
  1086.      network  N which was mentioned in the previous NR message from G,
  1087.  
  1088.      it is possible that N has become unreachable from G.  If  several
  1089.  
  1090.      successive  NR  messages  from  G omit mention of N, it should be
  1091.  
  1092.      taken to mean that  N  is  no  longer  reachable  from  G.   This
  1093.  
  1094.      procedure  is  necessary  to  ensure  that  networks which can no
  1095.  
  1096.      longer be  reached,  but  which  are  never  explicitly  declared
  1097.  
  1098.      unreachable, are timed out and removed from the list of reachable
  1099.  
  1100.      networks.
  1101.  
  1102.  
  1103.           It will often be the case that where a core gateway G and  a
  1104.  
  1105.      stub  gateway  G'  are  direct neighbors on network N, G knows of
  1106.  
  1107.      many more gateway neighbors on network N,  and  knows  for  which
  1108.  
  1109.      networks  those  gateway neighbors are the appropriate first hop.
  1110.  
  1111.      Since the stub G' may not know about all these  other  neighbors,
  1112.  
  1113.      it  is  convenient  and often more efficient for it to be able to
  1114.  
  1115.  
  1116.  
  1117.                                   - 17 -
  1118.  
  1119.  
  1120.  
  1121.  
  1122.  
  1123.  
  1124.  
  1125.      RFC 888                                              JANUARY 1984
  1126.  
  1127.  
  1128.  
  1129.      obtain this information from G.  Therefore, the  EGP  NR  message
  1130.  
  1131.      also  contains  fields  which allow the core gateway G to specify
  1132.  
  1133.      the following information:
  1134.  
  1135.  
  1136.           a) A list of all neighbors (both interior and exterior) of G
  1137.  
  1138.              (on  network  N)  which  G  has reliably determined to be
  1139.  
  1140.              reachable.  G may also include indirect neighbors in this
  1141.  
  1142.              list (see below.)
  1143.  
  1144.  
  1145.           b) For each of those neighbors, the  list  of  networks  for
  1146.  
  1147.              which that neighbor is an appropriate first hop (relative
  1148.  
  1149.              to network N).
  1150.  
  1151.  
  1152.           c) For each such <neighbor, network>  pair,  the  "distance"
  1153.  
  1154.              from that neighbor to that network.
  1155.  
  1156.  
  1157.           Thus the NR message provides a means of allowing  a  gateway
  1158.  
  1159.      to  "discover" new neighbors by seeing whether a neighbor that it
  1160.  
  1161.      already knows  of  has  any  additional  neighbors  on  the  same
  1162.  
  1163.      network.  This information also makes possible the implementation
  1164.  
  1165.      of the INDIRECT NEIGHBOR strategy defined below.
  1166.  
  1167.  
  1168.           A  more  precise  description  of  the  NR  message  is  the
  1169.  
  1170.      following.
  1171.  
  1172.  
  1173.  
  1174.  
  1175.  
  1176.                                   - 18 -
  1177.  
  1178.  
  1179.  
  1180.  
  1181.  
  1182.  
  1183.  
  1184.      RFC 888                                              JANUARY 1984
  1185.  
  1186.  
  1187.  
  1188.           The data portion of the  message  will  consist  largely  of
  1189.  
  1190.      blocks  of data.  Each block will be headed by a gateway address,
  1191.  
  1192.      which will be the address  either  of  the  gateway  sending  the
  1193.  
  1194.      message  or  of  one  of  that gateway's neighbors.  Each gateway
  1195.  
  1196.      address will be followed by a list of the networks for which that
  1197.  
  1198.      gateway  is  an  appropriate first hop.  All networks at the same
  1199.  
  1200.      distance from the gateway will be grouped together in this  list,
  1201.  
  1202.      preceded  by  the  distance  itself and the number of networks at
  1203.  
  1204.      that distance.  The whole list is preceded  by  a  count  of  the
  1205.  
  1206.      distance-groups in the list.
  1207.  
  1208.  
  1209.           Preceding the list of data blocks is:
  1210.  
  1211.           a) The count (one byte) of the number of interior  neighbors
  1212.  
  1213.              of  G  for  which  this message contains data blocks.  By
  1214.  
  1215.              convention, this count will include the data block for  G
  1216.  
  1217.              itself, which should be the first one to appear.
  1218.  
  1219.  
  1220.           b) The count (one byte) of the number of exterior  neighbors
  1221.  
  1222.                 of  G  for  which  this  message contains data blocks.
  1223.  
  1224.  
  1225.  
  1226.  
  1227.           c) The address of the network which this message  is  about.
  1228.  
  1229.              If  G  and  G' are neighbors on network N, then in the NR
  1230.  
  1231.              message going from G  to  G',  this  is  the  address  of
  1232.  
  1233.  
  1234.  
  1235.                                   - 19 -
  1236.  
  1237.  
  1238.  
  1239.  
  1240.  
  1241.  
  1242.  
  1243.      RFC 888                                              JANUARY 1984
  1244.  
  1245.  
  1246.  
  1247.              network   N.   For  convenience,  four  bytes  have  been
  1248.  
  1249.              allocated for this address -- the trailing one,  two,  or
  1250.  
  1251.              three bytes should be zero.
  1252.  
  1253.  
  1254.           Then follow the data blocks themselves, first the block  for
  1255.  
  1256.      G itself, then the blocks for all the interior neighbors of G (if
  1257.  
  1258.      any), then the blocks for  the  exterior  neighbors.   Since  all
  1259.  
  1260.      gateways  mentioned  are  on  the same network, whose address has
  1261.  
  1262.      already been given, the gateway  addresses  are  given  with  the
  1263.  
  1264.      network  address part (one, two, or three bytes) omitted, to save
  1265.  
  1266.      space.
  1267.  
  1268.  
  1269.           In the list of networks, each network address is either one,
  1270.  
  1271.      two,  or three bytes, depending on whether it is a class A, class
  1272.  
  1273.      B, or class C network.  No trailing bytes are used.
  1274.  
  1275.  
  1276.           The NR message  sent  by  a  stub  should  be  the  simplest
  1277.  
  1278.      allowable.   That  is,  it  should have only a single data block,
  1279.  
  1280.      headed by its own address (on the network it has in  common  with
  1281.  
  1282.      the neighboring core gateway), listing just the networks to which
  1283.  
  1284.      it is an appropriate first hop.  These will be just the  networks
  1285.  
  1286.      that can be reached no other way, in general.
  1287.  
  1288.  
  1289.  
  1290.  
  1291.  
  1292.  
  1293.  
  1294.                                   - 20 -
  1295.  
  1296.  
  1297.  
  1298.  
  1299.  
  1300.  
  1301.  
  1302.      RFC 888                                              JANUARY 1984
  1303.  
  1304.  
  1305.  
  1306.           The core gateways will send complete NR messages, containing
  1307.  
  1308.      information  about all other gateways on the common network, both
  1309.  
  1310.      core gateways (which shall be listed as interior  neighbors)  and
  1311.  
  1312.      other  gateways (which shall be listed as exterior neighbors, and
  1313.  
  1314.      may include the stub itself).  This information will  enable  the
  1315.  
  1316.      stub  to  become  an  indirect  neighbor (see below) of all these
  1317.  
  1318.      other gateways.  That is, the stub shall forward traffic directly
  1319.  
  1320.      to  these  other  gateways  as  appropriate, but shall not become
  1321.  
  1322.      direct neighbors with them.
  1323.  
  1324.  
  1325.           The  stub  should  NEVER  forward  to   any   (directly   or
  1326.  
  1327.      indirectly)  neighboring  core gateway any traffic for which that
  1328.  
  1329.      gateway is not an appropriate first hop, as indicated  in  an  NR
  1330.  
  1331.      message.   Of  course, this does not apply to datagrams which are
  1332.  
  1333.      using the source route option; any such datagrams  should  always
  1334.  
  1335.      be  forwarded as indicated in the source route option field, even
  1336.  
  1337.      if that  requires  forwarding  to  a  gateway  which  is  not  an
  1338.  
  1339.      appropriate first hop.
  1340.  
  1341.  
  1342.  
  1343.  
  1344.  
  1345.  
  1346.  
  1347.  
  1348.  
  1349.  
  1350.  
  1351.  
  1352.  
  1353.                                   - 21 -
  1354.  
  1355.  
  1356.  
  1357.  
  1358.  
  1359.  
  1360.  
  1361.      RFC 888                                              JANUARY 1984
  1362.  
  1363.  
  1364.  
  1365.      6  POLLING FOR NR MESSAGES
  1366.  
  1367.  
  1368.           No gateway is required to send  NR  messages  to  any  other
  1369.  
  1370.      gateway,  except  as  a  response  to  an  NR  Poll from a direct
  1371.  
  1372.      neighbor.  However, a gateway is required to  respond  to  an  NR
  1373.  
  1374.      Poll  from  a  direct neighbor within several seconds (subject to
  1375.  
  1376.      the qualification two paragraphs  hence),  even  if  the  gateway
  1377.  
  1378.      believes that neighbor to be down.
  1379.  
  1380.  
  1381.           The EGP NR Poll message is defined  for  this  purpose.   No
  1382.  
  1383.      gateway  may  poll another for an NR message more often than once
  1384.  
  1385.      per minute.  A gateway receiving more than one  poll  per  minute
  1386.  
  1387.      may  simply  ignore  the  excess  polls,  or  may return an error
  1388.  
  1389.      message.
  1390.  
  1391.  
  1392.           The minimum interval which gateway  G  will  accept  as  the
  1393.  
  1394.      polling  interval  from gateway G' and the minimum interval which
  1395.  
  1396.      G' will accept as the polling interval from G  are  specified  at
  1397.  
  1398.      the  time  that  G  and  G'  become  direct  neighbors.  Both the
  1399.  
  1400.      Neighbor Acquisition Request and the Neighbor  Acquisition  Reply
  1401.  
  1402.      allow  the  sender  to  specify,  in seconds, its desired minimum
  1403.  
  1404.      polling interval.  If G specifies to G' that its minimum  polling
  1405.  
  1406.      interval  is  X,  G'  should not poll G more frequently than once
  1407.  
  1408.      every X seconds.  G will not guarantee to  answer  more  frequent
  1409.  
  1410.  
  1411.  
  1412.                                   - 22 -
  1413.  
  1414.  
  1415.  
  1416.  
  1417.  
  1418.  
  1419.  
  1420.      RFC 888                                              JANUARY 1984
  1421.  
  1422.  
  1423.  
  1424.      polls.
  1425.  
  1426.  
  1427.           Polls must only  be  sent  to  direct  neighbors  which  are
  1428.  
  1429.      declared reachable by the neighbor reachability protocol.
  1430.  
  1431.  
  1432.           An NR Poll message contains a sequence number chosen by  the
  1433.  
  1434.      polling  gateway.   The polled gateway will return this number in
  1435.  
  1436.      the NR message it sends in response to the poll,  to  enable  the
  1437.  
  1438.      polling gateway to match up received NR messages with polls.
  1439.  
  1440.  
  1441.           In general, a poll should be retransmitted  some  number  of
  1442.  
  1443.      times  (with a reasonable interval between retransmissions) until
  1444.  
  1445.      an NR message is received.  IF NO NR MESSAGE  IS  RECEIVED  AFTER
  1446.  
  1447.      THE MAXIMUM NUMBER OF RETRANSMISSIONS, THE POLLING GATEWAY SHOULD
  1448.  
  1449.      ASSUME THAT THE POLLED GATEWAY IS NOT AN  APPROPRIATE  FIRST  HOP
  1450.  
  1451.      FOR  ANY  NETWORK  WHATSOEVER.   The  optimum  parameters for the
  1452.  
  1453.      polling/retransmission  algorithm  will  be  dependent   on   the
  1454.  
  1455.      characteristics   of   the  two  neighbors  and  of  the  network
  1456.  
  1457.      connecting them.
  1458.  
  1459.  
  1460.           Received NR messages whose  identification  numbers  do  not
  1461.  
  1462.      match  the  identification  number of the most recently sent poll
  1463.  
  1464.      shall be ignored.  There is no provision for multiple outstanding
  1465.  
  1466.      polls to the same neighbor.
  1467.  
  1468.  
  1469.  
  1470.  
  1471.                                   - 23 -
  1472.  
  1473.  
  1474.  
  1475.  
  1476.  
  1477.  
  1478.  
  1479.      RFC 888                                              JANUARY 1984
  1480.  
  1481.  
  1482.  
  1483.      7  SENDING NR MESSAGES
  1484.  
  1485.  
  1486.           In general, NR messages are to be sent only in response to a
  1487.  
  1488.      poll.   However,  between  two  successive polls from an exterior
  1489.  
  1490.      neighbor, a gateway may send one  and  only  one  unsolicited  NR
  1491.  
  1492.      message  to  that  neighbor.   This  gives  it limited ability to
  1493.  
  1494.      quickly announce  network  reachability  changes  that  may  have
  1495.  
  1496.      occurred in the interval since the last poll.  Excess unsolicited
  1497.  
  1498.      NR messages may be ignored, or an error message may be returned.
  1499.  
  1500.  
  1501.           An NR message should be sent within  several  seconds  after
  1502.  
  1503.      receipt  of  a poll.  Failure to respond in a timely manner to an
  1504.  
  1505.      NR poll may result in the polling  gateway's  deciding  that  the
  1506.  
  1507.      polled gateway is not an appropriate first hop to any network.
  1508.  
  1509.  
  1510.           NR messages sent in response to  polls  carry  the  sequence
  1511.  
  1512.      number  of  the  poll  message in their "sequence number" fields.
  1513.  
  1514.      Unsolicited NR messages carry the identification  number  of  the
  1515.  
  1516.      last  poll  received,  and have the "unsolicited" bit set.  (Note
  1517.  
  1518.      that this allows for only a single  unsolicited  NR  message  per
  1519.  
  1520.      polling period.)
  1521.  
  1522.  
  1523.           Polls from  non-neighbors,  from  neighbors  which  are  not
  1524.  
  1525.      declared  reachable, or with bad IP source network fields, should
  1526.  
  1527.  
  1528.  
  1529.  
  1530.                                   - 24 -
  1531.  
  1532.  
  1533.  
  1534.  
  1535.  
  1536.  
  1537.  
  1538.      RFC 888                                              JANUARY 1984
  1539.  
  1540.  
  1541.  
  1542.      be responded to with an EGP error message  with  the  appropriate
  1543.  
  1544.      "reason"  field.   If  G  sends  an  NR poll to G' with IP source
  1545.  
  1546.      network N, and G' is not a neighbor of  G  on  its  interface  to
  1547.  
  1548.      network  N  (or G' does not have an interface to network N), then
  1549.  
  1550.      the source network field is considered "bad".
  1551.  
  1552.  
  1553.           A gateway is normally not required to send more than one  NR
  1554.  
  1555.      message  within the minimum interval specified at the time of the
  1556.  
  1557.      neighbor acquisition.  An exception to  this  must  be  made  for
  1558.  
  1559.      duplicate polls (successive polls with the same sequence number),
  1560.  
  1561.      which occur when an NR message is lost  in  transit.   A  gateway
  1562.  
  1563.      should  send an NR message containing its most recent information
  1564.  
  1565.      in response to a duplicate poll.
  1566.  
  1567.  
  1568.  
  1569.  
  1570.  
  1571.  
  1572.  
  1573.  
  1574.  
  1575.  
  1576.  
  1577.  
  1578.  
  1579.  
  1580.  
  1581.  
  1582.  
  1583.  
  1584.  
  1585.  
  1586.  
  1587.  
  1588.  
  1589.                                   - 25 -
  1590.  
  1591.  
  1592.  
  1593.  
  1594.  
  1595.  
  1596.  
  1597.      RFC 888                                              JANUARY 1984
  1598.  
  1599.  
  1600.  
  1601.      8  INDIRECT NEIGHBORS
  1602.  
  1603.  
  1604.           Becoming a "direct neighbor" of an exterior gateway requires
  1605.  
  1606.      three  steps:  (a)  neighbor  acquisition, (b) running a neighbor
  1607.  
  1608.      reachability protocol, and (c) polling the neighbor  periodically
  1609.  
  1610.      for NR messages.  Suppose, however, that gateway G receives an NR
  1611.  
  1612.      message from G', in which G'  indicates  the  presence  of  other
  1613.  
  1614.      neighbors  G1, ..., Gn, each of which is an appropriate first hop
  1615.  
  1616.      for some set of networks to which G' itself is not an appropriate
  1617.  
  1618.      first hop.  Then G should be allowed to forward traffic for those
  1619.  
  1620.      networks directly to the appropriate one of G1, ..., Gn,  without
  1621.  
  1622.      having to send it to G' first.  In this case, G may be considered
  1623.  
  1624.      an INDIRECT NEIGHBOR of G1, ..., Gn, since it is  a  neighbor  of
  1625.  
  1626.      these  other  gateways for the purpose of forwarding traffic, but
  1627.  
  1628.      does not perform neighbor acquisition, neighbor reachability,  or
  1629.  
  1630.      exchange   of  NR  messages  with  them.   Neighbor  and  network
  1631.  
  1632.      reachability information is obtained indirectly via G', hence the
  1633.  
  1634.      designation  "indirect  neighbor".   We say that G is an indirect
  1635.  
  1636.      neighbor of G1, ..., Gn VIA G'.
  1637.  
  1638.  
  1639.           If G is an indirect neighbor of  G'  via  G'',  and  then  G
  1640.  
  1641.      receives  an  NR  message  from  G'' which does not mention G', G
  1642.  
  1643.      should treat G' as having become unreachable.
  1644.  
  1645.  
  1646.  
  1647.  
  1648.                                   - 26 -
  1649.  
  1650.  
  1651.  
  1652.  
  1653.  
  1654.  
  1655.  
  1656.      RFC 888                                              JANUARY 1984
  1657.  
  1658.  
  1659.  
  1660.      9  LIMITATIONS
  1661.  
  1662.  
  1663.           It must be clearly  understood  that  the  Exterior  Gateway
  1664.  
  1665.      Protocol   does  not  in  itself  constitute  a  network  routing
  1666.  
  1667.      algorithm.  In addition, it does not provide all the  information
  1668.  
  1669.      needed  to  implement  a  general area routing algorithm.  If the
  1670.  
  1671.      topology does not obey the  rules  given  for  stubs  above,  the
  1672.  
  1673.      Exterior  Gateway  Protocol  does  not provide enough topological
  1674.  
  1675.      information to prevent loops.
  1676.  
  1677.  
  1678.           If any gateway sends an NR message with  false  information,
  1679.  
  1680.      claiming  to be an appropriate first hop to a network which it in
  1681.  
  1682.      fact cannot even reach, traffic  destined  to  that  network  may
  1683.  
  1684.      never be delivered.  Implementers must bear this in mind.
  1685.  
  1686.  
  1687.  
  1688.  
  1689.  
  1690.  
  1691.  
  1692.  
  1693.  
  1694.  
  1695.  
  1696.  
  1697.  
  1698.  
  1699.  
  1700.  
  1701.  
  1702.  
  1703.  
  1704.  
  1705.  
  1706.  
  1707.                                   - 27 -
  1708.  
  1709.  
  1710.  
  1711.  
  1712.  
  1713.  
  1714.  
  1715.      RFC 888                                              JANUARY 1984
  1716.  
  1717.  
  1718.  
  1719.      A  APPENDIX A - EGP MESSAGE FORMATS
  1720.  
  1721.           The Exterior Gateway Protocol runs under Internet Protocol as
  1722.      protocol number 8 (decimal).
  1723.  
  1724.  
  1725.  
  1726.  
  1727.      A.1  NEIGHBOR ACQUISITION MESSAGE
  1728.  
  1729.       0                   1                   2                   3
  1730.       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
  1731.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1732.      ! EGP Version # !     Type      !     Code      !    Info       !
  1733.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1734.      !        Checksum               !       Autonomous System #     !
  1735.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1736.      !        Sequence #             !       NR Hello interval       !
  1737.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1738.      !        NR poll interval       !
  1739.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1740.  
  1741.      Description:
  1742.  
  1743.           The Neighbor Acquisition messages are used by interior and
  1744.           exterior gateways to become neighbors of each other.
  1745.  
  1746.      EGP Version #
  1747.  
  1748.          2
  1749.  
  1750.      Type
  1751.  
  1752.          3
  1753.  
  1754.      Code
  1755.  
  1756.           Code = 0      Neighbor Acquisition Request
  1757.           Code = 1      Neighbor Acquisition Reply
  1758.           Code = 2      Neighbor Acquisition Refusal (see Info field)
  1759.           Code = 3      Neighbor Cease Message (see Info field)
  1760.           Code = 4      Neighbor Cease Acknowledgment
  1761.  
  1762.      Checksum
  1763.  
  1764.  
  1765.  
  1766.                                   - 28 -
  1767.  
  1768.  
  1769.  
  1770.  
  1771.  
  1772.  
  1773.  
  1774.      RFC 888                                              JANUARY 1984
  1775.  
  1776.  
  1777.  
  1778.          The  EGP checksum is the 16-bit one's complement of the one's
  1779.          complement sum of the  EGP  message  starting  with  the  EGP
  1780.          version  number  field.   For  computing  the  checksum,  the
  1781.          checksum field should be zero.
  1782.  
  1783.      Autonomous System #
  1784.  
  1785.          This   16-bit   number   identifies   the  autonomous  system
  1786.          containing the gateway which is the source of this message.
  1787.  
  1788.      Info
  1789.  
  1790.          For Refusal message, gives reason for refusal:
  1791.  
  1792.              0  Unspecified
  1793.              1  Out of table space
  1794.              2  Administrative prohibition
  1795.  
  1796.          For Cease message, gives reason for ceasing to be neighbor:
  1797.  
  1798.              0 Unspecified
  1799.              1 Going down
  1800.              2 No longer needed
  1801.  
  1802.          Otherwise, this field MUST be zero.
  1803.  
  1804.      Sequence Number
  1805.  
  1806.          A sequence number to aid in matching requests and
  1807.          replies.
  1808.  
  1809.      NR Hello Interval
  1810.  
  1811.          Minimum Hello polling interval(seconds).
  1812.  
  1813.      NR Poll Interval
  1814.  
  1815.          Minumum NR polling interval(seconds).
  1816.  
  1817.  
  1818.  
  1819.  
  1820.  
  1821.  
  1822.  
  1823.  
  1824.  
  1825.                                   - 29 -
  1826.  
  1827.  
  1828.  
  1829.  
  1830.  
  1831.  
  1832.  
  1833.      RFC 888                                              JANUARY 1984
  1834.  
  1835.  
  1836.  
  1837.      A.2  NEIGHBOR HELLO/I HEARD YOU MESSAGE
  1838.  
  1839.       0                   1                   2                   3
  1840.       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
  1841.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1842.      ! EGP Version # !    Type       !     Code      !    Status     !
  1843.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1844.      !    Checksum                   !    Autonomous System #        !
  1845.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1846.      !      Sequence #               !
  1847.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1848.  
  1849.      Description:
  1850.  
  1851.          Exterior  neighbors  use  EGP  Neighbor Hello and I Heard You
  1852.          Messages to determine neighbor connectivity.  When a  gateway
  1853.          receives  an  EGP  Neighbor  Hello message from a neighbor it
  1854.          should respond with an EGP I Heard You message.
  1855.  
  1856.      EGP Version #
  1857.  
  1858.          2
  1859.  
  1860.      Type
  1861.  
  1862.          5
  1863.  
  1864.      Code
  1865.  
  1866.           Code = 0 for Hello
  1867.           Code = 1 for I Heard you
  1868.  
  1869.      Checksum
  1870.  
  1871.          The  EGP checksum is the 16-bit one's complement of the one's
  1872.          complement sum of the  EGP  message  starting  with  the  EGP
  1873.          version  number  field.   For  computing  the  checksum,  the
  1874.          checksum field should be zero.
  1875.  
  1876.      Autonomous System #
  1877.  
  1878.          This   16-bit   number   identifies   the  autonomous  system
  1879.          containing the gateway which is the source of this message.
  1880.  
  1881.  
  1882.  
  1883.  
  1884.                                   - 30 -
  1885.  
  1886.  
  1887.  
  1888.  
  1889.  
  1890.  
  1891.  
  1892.      RFC 888                                              JANUARY 1984
  1893.  
  1894.  
  1895.  
  1896.      Sequence Number
  1897.  
  1898.          A sequence number to aid in matching requests and replies.
  1899.  
  1900.      Status
  1901.  
  1902.              0  No status given
  1903.              1  You appear reachable to me
  1904.              2  You appear unreachable to me due to neighbor
  1905.                 reachability protocol
  1906.              3  You appear unreachable to me due to network
  1907.                 reachability information (such as 1822 "destination
  1908.                 dead" messages from ARPANET)
  1909.              4  You appear unreachable to me due to problems
  1910.                 with my network interface
  1911.  
  1912.  
  1913.  
  1914.  
  1915.  
  1916.  
  1917.  
  1918.  
  1919.  
  1920.  
  1921.  
  1922.  
  1923.  
  1924.  
  1925.  
  1926.  
  1927.  
  1928.  
  1929.  
  1930.  
  1931.  
  1932.  
  1933.  
  1934.  
  1935.  
  1936.  
  1937.  
  1938.  
  1939.  
  1940.  
  1941.  
  1942.  
  1943.                                   - 31 -
  1944.  
  1945.  
  1946.  
  1947.  
  1948.  
  1949.  
  1950.  
  1951.      RFC 888                                              JANUARY 1984
  1952.  
  1953.  
  1954.  
  1955.      A.3  NR POLL MESSAGE
  1956.  
  1957.       0                   1                   2                   3
  1958.       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
  1959.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1960.      ! EGP Version # !    Type       !     Code      !    Unused     !
  1961.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1962.      !         Checksum              !       Autonomous System #     !
  1963.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1964.      !         Sequence #            !       Unused                  !
  1965.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1966.      !             IP Source Network                                 !
  1967.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1968.  
  1969.  
  1970.      Description:
  1971.  
  1972.           A  gateway  that  wants  to  receive  an  NR message from an
  1973.           Exterior Gateway will send an NR Poll message.  Each gateway
  1974.           mentioned in the NR message will have an  interface  on  the
  1975.           network that is in the IP source network field.
  1976.  
  1977.      EGP Version #
  1978.  
  1979.          2
  1980.  
  1981.      Type
  1982.  
  1983.          2
  1984.  
  1985.      Code
  1986.  
  1987.          0
  1988.  
  1989.      Checksum
  1990.  
  1991.           The EGP checksum is the 16-bit one's complement of the one's
  1992.           complement  sum  of  the  EGP  message starting with the EGP
  1993.           version number  field.   For  computing  the  checksum,  the
  1994.           checksum field should be zero.
  1995.  
  1996.      Autonomous System #
  1997.  
  1998.          This   16-bit   number   identifies   the  autonomous  system
  1999.  
  2000.  
  2001.  
  2002.                                   - 32 -
  2003.  
  2004.  
  2005.  
  2006.  
  2007.  
  2008.  
  2009.  
  2010.      RFC 888                                              JANUARY 1984
  2011.  
  2012.  
  2013.  
  2014.          containing the gateway which is the source of this message.
  2015.  
  2016.      Sequence Number
  2017.  
  2018.           A sequence  number  to  aid in matching requests and
  2019.           replies.
  2020.  
  2021.      IP Source Network
  2022.  
  2023.           Each  gateway  mentioned  in  the  NR  message  will have an
  2024.           interface on the network that is in the  IP  source  network
  2025.           field.   The  IP  source  network  is  coded  as one byte of
  2026.           network number followed by two bytes of  zero  for  class  A
  2027.           networks,  two  bytes of network number followed by one byte
  2028.           of zero for class B networks, and  three  bytes  of  network
  2029.           number for class C networks.
  2030.  
  2031.  
  2032.  
  2033.  
  2034.  
  2035.  
  2036.  
  2037.  
  2038.  
  2039.  
  2040.  
  2041.  
  2042.  
  2043.  
  2044.  
  2045.  
  2046.  
  2047.  
  2048.  
  2049.  
  2050.  
  2051.  
  2052.  
  2053.  
  2054.  
  2055.  
  2056.  
  2057.  
  2058.  
  2059.  
  2060.  
  2061.                                   - 33 -
  2062.  
  2063.  
  2064.  
  2065.  
  2066.  
  2067.  
  2068.  
  2069.      RFC 888                                              JANUARY 1984
  2070.  
  2071.  
  2072.  
  2073.      A.4  NETWORK REACHABILITY MESSAGE
  2074.  
  2075.       0                   1                   2                   3
  2076.       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
  2077.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2078.      ! EGP Version # !     Type      !   Code        !U! Zeroes      !
  2079.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2080.      !    Checksum                   !       Autonomous System #     !
  2081.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2082.      !    Sequence #                 ! # of Int Gwys ! # of Ext Gwys !
  2083.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2084.      !                      IP Source Network                        !
  2085.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2086.      ! Gateway 1 IP address (without network #)      ! ; 1, 2 or 3 bytes
  2087.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2088.      !  # Distances  !
  2089.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2090.      !  Distance 1   !   # Nets      !
  2091.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2092.      !   net 1,1,1   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes
  2093.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2094.      !   net 1,1,2   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes
  2095.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2096.             ...
  2097.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2098.      !  Distance 2   !   # Nets      !
  2099.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2100.      !   net 1,2,1   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes
  2101.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2102.      !   net 1,2,2   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! ; 1, 2 or 3 bytes
  2103.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2104.             ...
  2105.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2106.      !             Gateway  n IP address (without network #)         !
  2107.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2108.      !  # Distances  !
  2109.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2110.      !  Distance 1   !  # Nets       !
  2111.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2112.      !   net n,1,1   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  ; 1, 2 or 3 bytes
  2113.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2114.      !   net n,1,2   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  ; 1, 2 or 3 bytes
  2115.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2116.      !  Distance 2   !  # Nets       !
  2117.  
  2118.  
  2119.  
  2120.                                   - 34 -
  2121.  
  2122.  
  2123.  
  2124.  
  2125.  
  2126.  
  2127.  
  2128.      RFC 888                                              JANUARY 1984
  2129.  
  2130.  
  2131.  
  2132.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2133.      !   net n,2,1   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  ; 1, 2 or 3 bytes
  2134.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2135.      !   net n,2,2   !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!  ; 1, 2 or 3 bytes
  2136.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2137.            ...
  2138.  
  2139.  
  2140.  
  2141.      Description:
  2142.  
  2143.           The  Network  Reachability  message (NR) is used to discover
  2144.      which networks may be reached through Exterior Gateways.  The  NR
  2145.      message is sent in response to an NR Poll message.
  2146.  
  2147.      EGP Version #
  2148.  
  2149.          2
  2150.  
  2151.      Type
  2152.  
  2153.          1
  2154.  
  2155.      Code
  2156.  
  2157.          0
  2158.  
  2159.      Checksum
  2160.  
  2161.          The  EGP checksum is the 16-bit one's complement of the one's
  2162.          complement sum of the  EGP  message  starting  with  the  EGP
  2163.          version  number  field.   For  computing  the  checksum,  the
  2164.          checksum field should be zero.
  2165.  
  2166.      Autonomous System #
  2167.  
  2168.          This   16-bit   number   identifies   the  autonomous  system
  2169.          containing the gateway which is the source of this message.
  2170.  
  2171.      U (Unsolicited) bit
  2172.  
  2173.          This bit is set if the NR message is being sent unsolicited.
  2174.  
  2175.  
  2176.  
  2177.  
  2178.  
  2179.                                   - 35 -
  2180.  
  2181.  
  2182.  
  2183.  
  2184.  
  2185.  
  2186.  
  2187.      RFC 888                                              JANUARY 1984
  2188.  
  2189.  
  2190.  
  2191.      Sequence Number
  2192.  
  2193.          The  sequence  number  of  the  last  NR  poll  message
  2194.          received from the neighbor to whom this NR message  is  being
  2195.          sent.   This  number  is  used  to  aid in matching polls and
  2196.          replies.
  2197.  
  2198.      IP Source Network
  2199.  
  2200.           Each  gateway  mentioned  in  the  NR  message  will have an
  2201.           interface on the network that is in the  IP  source  network
  2202.           field.
  2203.  
  2204.      # of Interior Gateways
  2205.  
  2206.           The  number  of interior gateways that are mentioned in this
  2207.           message.
  2208.  
  2209.      # of Exterior Gateways
  2210.  
  2211.           The  number  of exterior gateways that are mentioned in this
  2212.           message.
  2213.  
  2214.      Gateway IP address
  2215.  
  2216.           1, 2 or 3 bytes of Gateway IP address (without network #).
  2217.  
  2218.      # of Distances
  2219.  
  2220.           The number of distances in the gateway block.
  2221.  
  2222.      Distance
  2223.  
  2224.           The distance.
  2225.  
  2226.      # of Nets
  2227.  
  2228.           The number of nets at this distance.
  2229.  
  2230.      Network address
  2231.  
  2232.           1, 2,  or 3 bytes of network address of network which can be
  2233.           reached via the preceding gateway.
  2234.  
  2235.  
  2236.  
  2237.  
  2238.                                   - 36 -
  2239.  
  2240.  
  2241.  
  2242.  
  2243.  
  2244.  
  2245.  
  2246.      RFC 888                                              JANUARY 1984
  2247.  
  2248.  
  2249.  
  2250.      A.5  EGP ERROR MESSAGE
  2251.  
  2252.       0                   1                   2                   3
  2253.       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
  2254.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2255.      ! EGP Version # !    Type       !     Code      !    Unused     !
  2256.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2257.      !    Checksum                   !       Autonomous System #     !
  2258.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2259.      !       Sequence #              !          Reason               !
  2260.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2261.      !                                                               !
  2262.      !                     Error Message Header                      !
  2263.      !            (first three 32-bit words of EGP header)           !
  2264.      !                                                               !
  2265.      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2266.  
  2267.      Description:
  2268.  
  2269.          An  EGP  Error  Message is sent in response to an EGP Message
  2270.          that has a bad checksum or has an incorrect value in  one  of
  2271.          its fields.
  2272.  
  2273.      EGP Version #
  2274.  
  2275.          2
  2276.  
  2277.      Type
  2278.  
  2279.          8
  2280.  
  2281.      Code
  2282.  
  2283.          0
  2284.  
  2285.      Checksum
  2286.  
  2287.           The EGP checksum is the 16-bit one's complement of the one's
  2288.           complement  sum  of  the  EGP  message starting with the EGP
  2289.           version number  field.   For  computing  the  checksum,  the
  2290.           checksum field should be zero.
  2291.  
  2292.      Autonomous System #
  2293.  
  2294.  
  2295.  
  2296.  
  2297.                                   - 37 -
  2298.  
  2299.  
  2300.  
  2301.  
  2302.  
  2303.  
  2304.  
  2305.      RFC 888                                              JANUARY 1984
  2306.  
  2307.  
  2308.  
  2309.          This   16-bit   number   identifies   the  autonomous  system
  2310.          containing the gateway which is the source of this message.
  2311.  
  2312.      Sequence Number
  2313.  
  2314.           A  sequence number assigned by the gateway sending the error
  2315.           message.
  2316.  
  2317.      Reason
  2318.  
  2319.           The reason that the EGP message was in error.  The following
  2320.           reasons are defined:
  2321.  
  2322.           0  -  unspecified
  2323.           1  -  Bad EGP checksum
  2324.           2  -  Bad IP Source address in NR Poll or Response
  2325.           3  -  Undefined EGP Type or Code
  2326.           4  -  Received poll from non-neighbor
  2327.           5  -  Received excess unsolicted NR message
  2328.           6  -  Received excess poll
  2329.           7  -  Erroneous counts in received NR message
  2330.           8  -  No response received to NR poll
  2331.  
  2332.  
  2333.  
  2334.  
  2335.  
  2336.  
  2337.  
  2338.  
  2339.  
  2340.  
  2341.  
  2342.  
  2343.  
  2344.  
  2345.  
  2346.  
  2347.  
  2348.  
  2349.  
  2350.  
  2351.  
  2352.  
  2353.  
  2354.  
  2355.  
  2356.                                   - 38 -
  2357.  
  2358.  
  2359.