rfc1009.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

         There is some argument that the Source Quench should be sent
         before the gateway is forced to drop datagrams [62].  For
         example, a parameter X could be established and set to have
         Source Quench sent when only X buffers remain.  Or, a parameter
         Y could be established and set to have Source Quench sent when
         only Y per cent of the buffers remain.

         Two problems for a gateway sending Source Quench are: (1) the
         consumption of bandwidth on the reverse path, and (2) the use
         of gateway CPU time.  To ameliorate these problems, a gateway
         must be prepared to limit the frequency with which it sends
         Source Quench messages.  This may be on the basis of a count
         (e.g., only send a Source Quench for every N dropped datagrams
         overall or per given source host), or on the basis of a time
         (e.g., send a Source Quench to a given source host or overall
         at most once per T millseconds).  The parameters (e.g., N or T)
         must be settable as part of the configuration of the gateway;
         furthermore, there should be some configuration setting which
         disables sending Source Quenches.  These configuration
         parameters, including disabling, should ideally be specifiable
         separately for each network interface.

         Note that a gateway itself may receive a Source Quench as the
         result of sending a datagram targeted to another gateway.  Such
         datagrams might be an EGP update, for example.

      2.2.4.  Time Exceeded

         The ICMP Time Exceeded message may be sent when a gateway
         discards a datagram due to the TTL being reduced to zero.  It



Braden & Postel                                                [Page 17]



RFC 1009 - Requirements for Internet Gateways                  June 1987


         may also be sent by a gateway if the fragments of a datagram
         addressed to the gateway itself cannot be reassembled before
         the time limit.

      2.2.5.  Parameter Problem

         The ICMP Parameter Problem message may be sent to the source
         host for any problem not specifically covered by another ICMP
         message.

      2.2.6.  Address Mask

         Host and gateway implementations are expected to support the
         ICMP Address Mask messages described in RFC-950 [21].

      2.2.7.  Timestamp

         The ICMP Timestamp message has proven to be useful for
         diagnosing Internet problems.  The preferred form for a
         timestamp value, the "standard value", is in milliseconds since
         midnight GMT.  However, it may be difficult to provide this
         value with millisecond resolution.  For example, many systems
         use clocks which update only at line frequency, 50 or 60 times
         per second.  Therefore, some latitude is allowed in a
         "standard" value:

            *  The value must be updated at a frequency of at least 30
               times per second (i.e., at most five low-order bits of
               the value may be undefined).

            *  The origin of the value must be within a few minutes of
               midnight, i.e., the accuracy with which operators
               customarily set CPU clocks.

         To meet the second condition for a stand-alone gateway, it will
         be necessary to query some time server host when the gateway is
         booted or restarted.  It is recommended that the UDP Time
         Server Protocol [44] be used for this purpose.  A more advanced
         implementation would use NTP (Network Time Protocol) [45] to
         achieve nearly millisecond clock synchronization; however, this
         is not required.

         Even if a gateway is unable to establish its time origin, it
         ought to provide a "non-standard" timestamp value (i.e., with
         the non-standard bit set), as a time in milliseconds from
         system startup.




Braden & Postel                                                [Page 18]



RFC 1009 - Requirements for Internet Gateways                  June 1987


         New gateways, especially those expecting to operate at T1 or
         higher speeds, are expected to have at least millisecond
         clocks.

      2.2.8.  Information Request/Reply

         The Information Request/Reply pair was intended to support
         self-configuring systems such as diskless workstations, to
         allow them to discover their IP network numbers at boot time.
         However, the Reverse ARP (RARP) protocol [15] provides a better
         mechanism for a host to use to discover its own IP address, and
         RARP is recommended for this purpose.  Information
         Request/Reply need not be implemented in a gateway.

      2.2.9.  Echo Request/Reply

         A gateway must implement ICMP Echo, since it has proven to be
         an extremely useful diagnostic tool.  A gateway must be
         prepared to receive, reassemble, and echo an ICMP Echo Request
         datagram at least as large as the maximum of 576 and the MTU's
         of all of the connected networks.  See the discussion of IP
         reassembly in gateways, Section 2.1.

         The following rules resolve the question of the use of IP
         source routes in Echo Request and Reply datagrams.  Suppose a
         gateway D receives an ICMP Echo Request addressed to itself
         from host S.

            1.  If the Echo Request contained no source route, D should
                send an Echo Reply back to S using its normal routing
                rules.  As a result, the Echo Reply may take a different
                path than the Request; however, in any case, the pair
                will sample the complete round-trip path which any other
                higher-level protocol (e.g., TCP) would use for its data
                and ACK segments between S and D.

            2.  If the Echo Request did contain a source route, D should
                send an Echo Reply back to S using as a source route the
                return route built up in the source-routing option of
                the Echo Request.










Braden & Postel                                                [Page 19]



RFC 1009 - Requirements for Internet Gateways                  June 1987


   2.3.  Exterior Gateway Protocol (EGP)

      EGP is the protocol used to exchange reachability information
      between Autonomous Systems of gateways, and is defined in
      RFC-904 [11].  See also RFC-827 [51], RFC-888 [46], and
      RFC-975 [27] for background information.  The most widely used EGP
      implementation is described in RFC-911 [13].

      When a dynamic routing algorithm is operated in the gateways of an
      Autonomous System (AS), the routing data-base must be coupled to
      the EGP implementation.  This coupling should ensure that, when a
      net is determined to be unreachable by the routing algorithm, the
      net will not be declared reachable to other ASs via EGP.  This
      requirement is designed to minimize spurious traffic to "black
      holes" and to ensure fair utilization of the resources on other
      systems.

      The present EGP specification defines a model with serious
      limitations, most importantly a restriction against propagating
      "third party" EGP information in order to prevent long-lived
      routing loops [27].  This effectively limits EGP to a two-level
      hierarchy; the top level is formed by the "core" AS, while the
      lower level is composed of those ASs which are direct neighbor
      gateways to the core AS.  In practice, in the current Internet,
      nearly all of the "core gateways" are connected to the ARPANET,
      while the lower level is composed of those ASs which are directly
      gatewayed to the ARPANET or MILNET.

      RFC-975 [27] suggested one way to generalize EGP to lessen these
      topology restrictions;  it has not been adopted as an official
      specification, although its ideas are finding their way into the
      new EGP developments.  There are efforts underway in the research
      community to develop an EGP generalization which will remove these
      restrictions.

      In EGP, there is no standard interpretation (i.e., metric) for the
      distance fields in the update messages, so distances are
      comparable only among gateways of the same AS.  In using EGP data,
      a gateway should compare the distances among gateways of the same
      AS and prefer a route to that gateway which has the smallest
      distance value.

      The values to be announced in the distance fields for particular
      networks within the local AS should be a gateway configuration
      parameter; by suitable choice of these values, it will be possible
      to arrange primary and backup paths from other AS's.  There are
      other EGP parameters, such as polling intervals, which also need
      to be set in the gateway configuration.


Braden & Postel                                                [Page 20]



RFC 1009 - Requirements for Internet Gateways                  June 1987


      When routing updates become large they must be transmitted in
      parts.  One strategy is to use IP fragmentation, another is to
      explicitly send the routing information in sections.  The Internet
      Engineering Task Force is currently preparing a recommendation on
      this and other EGP engineering issues.

   2.4.  Address Resolution Protocol (ARP)

      ARP is an auxiliary protocol used to perform dynamic address
      translation between LAN hardware addresses and Internet addresses,
      and is described in RFC-826 [4].

      ARP depends upon local network broadcast.  In normal ARP usage,
      the initiating host broadcasts an ARP Request carrying a target IP
      address; the corresponding target host, recognizing its own IP
      address, sends back an ARP Reply containing its own hardware
      interface address.

      A variation on this procedure, called "proxy ARP", has been used
      by gateways attached to broadcast LANs [14].  The gateway sends an
      ARP Reply specifying its interface address in response to an ARP
      Request for a target IP address which is not on the
      directly-connected network but for which the gateway offers an
      appropriate route.  By observing ARP and proxy ARP traffic, a
      gateway may accumulate a routing data-base [14].

      Proxy ARP (also known in some quarters as "promiscuous ARP" or
      "the ARP hack") is useful for routing datagrams from hosts which
      do not implement the standard Internet routing rules fully -- for
      example, host implementations which predate the introduction of
      subnetting.  Proxy ARP for subnetting is discussed in detail in
      RFC-925 [14].

      Reverse ARP (RARP) allows a host to map an Ethernet interface
      address into an IP address [15].  RARP is intended to allow a
      self-configuring host to learn its own IP address from a server at
      boot time.

   2.5.  Constituent Network Access Protocols

      See Section 3.









Braden & Postel                                                [Page 21]



RFC 1009 - Requirements for Internet Gateways                  June 1987


   2.6.  Interior Gateway Protocols

      Distributed routing algorithms continue to be the subject of
      research and engineering, and it is likely that advances will be
      made over the next several years.  A good algorithm needs to
      respond rapidly to real changes in Internet connectivity, yet be
      stable and insensitive to transients.  It needs to synchronize the
      distributed data-base across gateways of its Autonomous System
      rapidly (to avoid routing loops), while consuming only a small
      fraction of the available bandwidth.

      Distributed routing algorithms are commonly broken down into the
      following three components:

         A.  An algorithm to assign a "length" to each Internet path.

            The "length" may be a simple count of hops (1, or infinity
            if the path is broken), or an administratively-assigned
            cost, or some dynamically-measured cost (usually an average
            delay).

            In order to determine a path length, each gateway must at
            least test whether each of its neighbors is reachable; for
            this purpose, there must be a "reachability" or "neighbor
            up/down" protocol.

         B.  An algorithm to compute the shortest path(s) to a given
             destination.

         C.  A gateway-gateway protocol used to exchange path length and
             routing information among gateways.

      The most commonly-used IGPs in Internet gateways are as follows.

      2.6.1.  Gateway-to-Gateway Protocol (GGP)

         GGP was designed and implemented by BBN for the first
         experimental Internet gateways [41].  It is still in use in the
         BBN LSI/11 gateways, but is regarded as having serious
         drawbacks [58].  GGP is based upon an algorithm used in the
         early ARPANET IMPs and later replaced by SPF (see below).