rfc1009.txt

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

Braden & Postel                                                [Page 11]



RFC 1009 - Requirements for Internet Gateways                  June 1987


      a gateway must be highly robust and able to operate, possibly in a
      degraded state, under conditions of extreme congestion or failure
      of network resources.

      Even though the Internet system is not fully-interconnected, many
      parts of the system do need to have redundant connectivity.  A
      rich connectivity allows reliable service despite failures of
      communication lines and gateways, and it can also improve service
      by shortening Internet paths and by providing additional capacity.
      The engineering tradeoff between cost and reliability must be made
      for each component of the Internet system.







































Braden & Postel                                                [Page 12]



RFC 1009 - Requirements for Internet Gateways                  June 1987


2.  Protocols Required in Gateways

   The Internet architecture uses datagram gateways to interconnect
   constituent networks.  This section describes the various protocols
   which a gateway needs to implement.

   2.1.  Internet Protocol (IP)

      IP is the basic datagram protocol used in the Internet system [19,
      31].  It is described in RFC-791 [1] and also in MIL-STD-1777 [5]
      as clarified by RFC-963 [36] ([1] and [5] are intended to describe
      the same standard, but in quite different words).  The subnet
      extension is described in RFC-950 [21].

      With respect to current gateway requirements the following IP
      features can be ignored, although they may be required in the
      future:  Type of Service field, Security option, and Stream ID
      option.  However, if recognized, the interpretation of these
      quantities must conform to the standard specification.

      It is important for gateways to implement both the Loose and
      Strict Source Route options.  The Record Route and Timestamp
      options are useful diagnostic tools and must be supported in all
      gateways.

      The Internet model requires that a gateway be able to fragment
      datagrams as necessary to match the MTU of the network to which
      they are being forwarded, but reassembly of fragmented datagrams
      is generally left to the destination hosts.  Therefore, a gateway
      will not perform reassembly on datagrams it forwards.

      However, a gateway will generally receive some IP datagrams
      addressed to itself; for example, these may be ICMP Request/Reply
      messages, routing update messages (see Sections 2.3 and 2.6), or
      for monitoring and control (see Section 5).  For these datagrams,
      the gateway will be functioning as a destination host, so it must
      implement IP reassembly in case the datagrams have been fragmented
      by some transit gateway.  The destination gateway must have a
      reassembly buffer which is at least as large as the maximum of the
      MTU values for its network interfaces and 576.  Note also that it
      is possible for a particular protocol implemented by a host or
      gateway to require a lower bound on reassembly buffer size which
      is larger than 576.  Finally, a datagram which is addressed to a
      gateway may use any of that gateway's IP addresses as destination
      address, regardless of which interface the datagram enters.

      There are five classes of IP addresses:  Class A through
      Class E [23].  Of these, Class D and Class E addresses are


Braden & Postel                                                [Page 13]



RFC 1009 - Requirements for Internet Gateways                  June 1987


      reserved for experimental use.  A gateway which is not
      participating in these experiments must ignore all datagrams with
      a Class D or Class E destination IP address.  ICMP Destination
      Unreachable or ICMP Redirect messages must not result from
      receiving such datagrams.

      There are certain special cases for IP addresses, defined in the
      latest Assigned Numbers document [23].  These special cases can be
      concisely summarized using the earlier notation for an IP address:

         IP-address ::=  { <Network-number>, <Host-number> }

            or

         IP-address ::=  { <Network-number>, <Subnet-number>,
                                                         <Host-number> }

      if we also use the notation "-1" to mean the field contains all 1
      bits.  Some common special cases are as follows:

         (a)   {0, 0}

            This host on this network.  Can only be used as a source
            address (see note later).

         (b)   {0, <Host-number>}

            Specified host on this network.  Can only be used as a
            source address.

         (c)   { -1, -1}

            Limited broadcast.  Can only be used as a destination
            address, and a datagram with this address must never be
            forwarded outside the (sub-)net of the source.

         (d)   {<Network-number>, -1}

            Directed broadcast to specified network.  Can only be used
            as a destination address.

         (e)   {<Network-number>, <Subnet-number>, -1}

            Directed broadcast to specified subnet.  Can only be used as
            a destination address.

         (f)   {<Network-number>, -1, -1}



Braden & Postel                                                [Page 14]



RFC 1009 - Requirements for Internet Gateways                  June 1987


            Directed broadcast to all subnets of specified subnetted
            network.  Can only be used as a destination address.

         (g)   {127, <any>}

            Internal host loopback address.  Should never appear outside
            a host.

      The following two are conventional notation for network numbers,
      and do not really represent IP addresses.  They can never be used
      in an IP datagram header as an IP source or destination address.

         (h)   {<Network-number>, 0}

            Specified network (no host).

         (i)   {<Network-number>, <Subnet-number>, 0}

            Specified subnet (no host).

      Note also that the IP broadcast address, which has primary
      application to Ethernets and similar technologies that support an
      inherent broadcast function, has an all-ones value in the host
      field of the IP address.  Some early implementations chose the
      all-zeros value for this purpose, which is not in conformance with
      the specification [23, 49, 50].

   2.2.  Internet Control Message Protocol (ICMP)

      ICMP is an auxiliary protocol used to convey advice and error
      messages and is described in RFC-792 [2].

      We will discuss issues arising from gateway handling of particular
      ICMP messages.  The ICMP messages are grouped into two classes:
      error messages and information messages.  ICMP error messages are
      never sent about ICMP error messages, nor about broadcast or
      multicast datagrams.

         The ICMP error messages are: Destination Unreachable, Redirect,
         Source Quench, Time Exceeded, and Parameter Problem.

         The ICMP information messages are: Echo, Information,
         Timestamp, and Address Mask.







Braden & Postel                                                [Page 15]



RFC 1009 - Requirements for Internet Gateways                  June 1987


      2.2.1.  Destination Unreachable

         The distinction between subnets of a subnetted network, which
         depends on the address mask described in RFC-950 [21], must not
         be visible outside that network.  This distinction is important
         in the case of the ICMP Destination Unreachable message.

         The ICMP Destination Unreachable message is sent by a gateway
         in response to a datagram which it cannot forward because the
         destination is unreachable or down.  The gateway chooses one of
         the following two types of Destination Unreachable messages to
         send:

            *  Net Unreachable

            *  Host Unreachable

         Net unreachable implies that an intermediate gateway was unable
         to forward a datagram, as its routing data-base gave no next
         hop for the datagram, or all paths were down.  Host Unreachable
         implies that the destination network was reachable, but that a
         gateway on that network was unable to reach the destination
         host.  This might occur if the particular destination network
         was able to determine that the desired host was unreachable or
         down.  It might also occur when the destination host was on a
         subnetted network and no path was available through the subnets
         of this network to the destination.  Gateways should send Host
         Unreachable messages whenever other hosts on the same
         destination network might be reachable; otherwise, the source
         host may erroneously conclude that ALL hosts on the network are
         unreachable, and that may not be the case.

      2.2.2.  Redirect

         The ICMP Redirect message is sent by a gateway to a host on the
         same network, in order to change the gateway used by the host
         for routing certain datagrams.  A choice of four types of
         Redirect messages is available to specify datagrams destined
         for a particular host or network, and possibly with a
         particular type-of-service.

         If the directly-connected network is not subnetted, a gateway
         can normally send a network Redirect which applies to all hosts
         on a specified remote network.  Using a network rather than a
         host Redirect may economize slightly on network traffic and on
         host routing table storage.  However, the saving is not
         significant, and subnets create an ambiguity about the subnet



Braden & Postel                                                [Page 16]



RFC 1009 - Requirements for Internet Gateways                  June 1987


         mask to be used to interpret a network Redirect.  In a general
         subnet environment, it is difficult to specify precisely the
         cases in which network Redirects can be used.

         Therefore, it is recommended that a gateway send only host (or
         host and type-of-service) Redirects.

      2.2.3.  Source Quench

         All gateways must contain code for sending ICMP Source Quench
         messages when they are forced to drop IP datagrams due to
         congestion.  Although the Source Quench mechanism is known to
         be an imperfect means for Internet congestion control, and
         research towards more effective means is in progress, Source
         Quench is considered to be too valuable to omit from production
         gateways.