rfc985.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,312 行 · 第 1/4 页

   2.2.  Internet Control Message Protocol (ICMP)

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

      The distinction between subnets of a subnetted network, which
      depends on an arbitrary mask as described in RFC-950 [21], is in
      general not visible outside that network.  This distinction is
      important in the case of certain ICMP messages, including the ICMP


NTAG                                                            [Page 6]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


      Destination Unreachable and ICMP Redirect messages.  The ICMP
      Destination Unreachable message is sent by a gateway in response
      to a datagram which cannot be forwarded because the destination is
      unreachable or down.  A choice of several types of these messages
      is available, including one designating the destination network
      and another the destination host. However, the span of addresses
      implied by the former is ill-defined unless the subnet mask is
      known to the sender, which is in general not the case.  It is
      recommended that use of the ICMP Destination Network Unreachable
      messages be avoided.  Instead, an ICMP Destination Host
      Unreachable message should be sent for each distinct unreachable
      IP address.

      The ICMP Redirect message is sent by a gateway to a host in order
      to change the address used by the host for a designated host or
      net.  A choice of four types of messages is available, depending
      on whether it applies to a particular host, network or service.
      As in the previous case, these distinctions may depend upon the
      subnet mask.  As in the above case, it is recommended that the use
      of ICMP messages implying a span of addresses (e.g.  net
      unreachable, net redirect) be avoided in favor of those implying
      specific addresses (e.g.  host unreachable, host redirect).

      The ICMP Source Quench message has been the subject of much
      controversy.  It is not considered realistic at this time to
      specify in detail the conditions under which this message is to be
      generated or interpreted by a host or gateway.

      New host and gateway implementations are expected to support the
      ICMP Address Mask messages described in RFC-950.  It is highly
      desirable, although not required, to provide correct data for ICMP
      Timestamp messages, which have been found useful in network
      debugging and maintenance.

   2.3.  Exterior Gateway Protocol (EGP)

      This is the basic protocol used to exchange information between
      gateway systems of the Internet and is described in RFC-904 [11].
      However, EGP as presently specified is an asymmetric protocol with
      only the "non-core" procedures defined in RFC-904.  There are at
      present no "core" procedures specified, which would be necessary
      for a stand-alone Internet.  RFC-975 [27] suggests certain
      modifications leading to a symmetric model;  however, this is not
      an official specification.

      In principle, a stand-alone Internet can be built with non-core
      EGP gateways using the EGP distance field to convey some metric


NTAG                                                            [Page 7]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


      such as hop count.  However, the use of EGP in this way as a
      routing algorithm is discouraged, since typical implementations
      adapt very slowly to changing topology and have no loop-protection
      features.

      The EGP model requires each gateway belong to an autonomous system
      of gateways.  If a routing algorithm is operated in one or more
      gateways of an autonomous system, its data base must be coupled to
      the EGP implementation in such a way that, when a net is declared
      down by the routing algorithm, the net is also declared down via
      EGP to other autonomous systems.  This requirement is designed to
      minimize spurious traffic to "black holes" and insure fair
      utilization of the resources on other systems.

      There are no peer-discovery or authentication procedures defined
      in the present EGP specification and no defined interpretation of
      the distance fields in the update messages, although such
      procedures may be defined in future (see RFC-975).  There is
      currently no guidance on the selection of polling parameters and
      no specific recovery procedures in case of certain error messages
      (e.g.  "administratively prohibited").  It is recommended that EGP
      implementations include provisions to initialize these parameters
      as part of the monitoring and control procedures and that changing
      these procedures not require recompilation or rebooting the
      gateway.

   2.4.  Address Resolution Protocol (ARP)

      This is an auxiliary protocol used to manage the
      address-translation function between hardware addresses in a
      local-net environment and Internet addresses and described in
      RFC-826 [4].  However, there are a number of unresolved issues
      having to do with subnets and response to addresses not in the
      same subnet or net.  These issues, which are intertwined with ICMP
      and various gateway models, are discussed in Appendix A.

3.  Subnets

   The concept of subnets was introduced in order to allow arbitrary
   complexity of interconnected LAN structures within an organization,
   while insulating the Internet system against explosive growth in
   network numbers and routing complexity.  The subnet architecture,
   described in RFC-950 [21], is intended to specify a standard approach
   that does not require reconfiguration for host implementations,
   regardless of subnetting scheme.  The document also specifies a new




NTAG                                                            [Page 8]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


   ICMP Address Mask message, which a gateway can use to specify certain
   details of the subnetting scheme to hosts and is required in new host
   and gateway implementations.

   The current subnet specification RFC-950 does not describe the
   specific procedures to be used by the gateway, except by implication.
   It is recommended that a (sub)net address and address mask be
   provided for each network interface and that these values be
   established as part of the gateway configuration procedure.  It is
   not usually necessary to change these values during operation of any
   particular gateway; however, it should be possible to add new
   gateways and/or (sub)nets and make other configuration changes to a
   gateway without taking the entire network down.

4.  Local Network Interface

   The packet format used for transmission of datagrams on the various
   subnetworks is described in a number of documents summarized below.

   4.1.  Public data networks via X.25

      The formats specified for public data networks via X.25 access are
      described in RFC-877 [8].  Datagrams are transmitted over standard
      level-3 virtual circuits as complete packet sequences.  Virtual
      circuits are usually established dynamically as required and time
      out after a period of no traffic.  Retransmission, resequencing
      and flow control are performed by the network for each virtual
      circuit and by the LAPB link-level protocol.  Multiple parallel
      virtual circuits are often used in order to improve the
      utilization of the subscriber access line, which can result in
      random resequencing.  The correspondence between Internet and
      X.121 addresses is usually established by table-lookup.  It is
      expected that this will be replaced by some sort of directory
      procedure in future.

   4.2.  ARPANET via 1822 Local Host, Distant Host or HDLC Distant Host

      The formats specified for ARPANET networks via 1822 access are
      described in BBN Report 1822 [3], which includes the procedures
      for several subscriber access methods.  The Local Host (LH) and
      Very Distant Host (VDH) methods are not recommended for new
      implementations.  The Distant Host (DH) method is used when the
      host and IMP are separated by not more than about 2000 feet of
      cable, while the HDLC Distant Host is used for greater distances
      where a modem is required.  Retransmission, resequencing and flow
      control are performed by the network and by the HDLC link-level
      protocol, when used.  While the ARPANET 1822 protocols are widely


NTAG                                                            [Page 9]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


      used at present, they are expected to be eventually overtaken by
      the DDN Standard X.25 protocol (see below) and the new PSN
      End-to-End Protocol described in RFC-979 [29].

      While the cited report gives details of the various ARPANET
      subscriber access methods, it specifies neither the IP packet
      encapsulation format nor address mappings.  While these are
      generally straightforward and easy to implement, the details
      involve considerations beyond the scope of readily accessable
      documentation. Potential vendors are encouraged to contact one of
      the individuals listed at the beginning of this document for
      further information.

      Gateways connected to ARPANET/MILNET IMPs must incorporate
      features to avoid host-port blocking (RFNM counting) and to detect
      and report (as ICMP Unreachable messages) the failure of
      destination hosts or gateways.

   4.3.  ARPANET via DDN Standard X.25

      The formats specified for ARPANET networks via X.25 are described
      in the Defense Data Network X.25 Host Interface Specification [6].
      This document describes two sets of procedures, the DDN Basic X.25
      and the DDN Standard X.25, but only the latter is suitable for use
      in the Internet system.  The DDN Standard X.25 procedures are
      similar to the public data subnetwork X.25 procedures, except in
      the address mappings. Retransmission, resequencing and flow
      control are performed by the network and by the LAPB link-level
      protocol.

   4.4.  Ethernets

      The formats specified for Ethernet networks are described in
      RFC-894 [10].  Datagrams are encapsulated as Ethernet packets with
      48-bit source and destination address fields and a 16-bit type
      field. Address translation between Ethernet addresses and Internet
      addresses is managed by the Address Resolution Protocol, which is
      required in all Ethernet implementations.  There is no explicit
      retransmission, resequencing or flow control.  although most
      hardware interfaces will retransmit automatically in case of
      collisions on the cable.

      It is expected that amendments will be made to this specification
      as the result of IEEE 802.3 evolution.  See RFC-948 [20] for
      further discussion and recommendations in this area.  Note also
      that the IP broadcast address, which has primary application to
      Ethernets and similar technologies that support an inherent


NTAG                                                           [Page 10]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


      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 presently not in conformance with the
      definitive specification RFC-950 [21].

      See Appendix A for further considerations.

   4.5.  Serial-Line Protocols

      Gateways may be used as packet switches in order to build
      networks. In some configurations gateways may be interconnected
      with each other and some hosts by means of serial asynchronous or
      synchronous lines, with or without modems.  When justified by the
      expected error rate and other factors, a link-level protocol may
      be required on the serial line. While there is no requirement that
      a particular standard protocol be used for this, it is recommended
      that standard hardware and protocols be used, unless a convincing
      reason to the contrary exists.  In order to support the greatest
      variety of configurations, it is recommended that some variation
      on full X.25 (i.e.  "symmetric mode") be used where resources
      permit;  however, X.25 LAPB would also be acceptable where
      requirements permit.  In the case of asynchronous lines no clear
      choice is apparent.

5.  Interoperability

   In order to assure interoperability between gateways procured from
   different vendors, it is necessary to specify points of protocol
   demarcation.  With respect to interoperability of the routing
   function, this is specified as EGP.  All gateway systems must include
   one or more gateways which support EGP with a core gateway, as
   described in RFC-904 [11].  It is desirable that these gateways be
   able to operate in a mode that does not require a core gateway or
   system.  Additional discussion on these issues can be found in
   RFC-975 [27].

   With respect to the interoperability at the network layer and below,
   two points of protocol demarcation are specified, one for Ethernets
   and the other for serial lines.  In the case of Ethernets the
   protocols are as specified in Section 4.4 and Appendix A of this
   document.  For serial lines between gateways of different vendors,
   the protocols are specified in Section 4.5 of this document.
   Exceptions to these requirements may be appropriate in some cases.






NTAG                                                           [Page 11]



RFC 985                                                         May 1986
Requirements for Internet Gateways -- DRAFT


6.  Subnetwork Architecture

   It is recognized that gateways may also function as general packet
   switches to build networks of modest size.  This requires additional
   functionality in order to manage network routing, control and
   configuration.  While it is beyond the scope of this document to
   specify the details of the mechanisms used in any particular, perhaps
   proprietary, architecture, there are a number of basic requirements
   which must be provided by any acceptable architecture.

   6.1.  Reachability Procedures

      The architecture must provide a robust mechanism to establish the
      operational status of each link and node in the network, including
      the gateways, the links connecting them and, where appropriate,
      the hosts as well.  Ordinarily, this requires at least a
      link-level reachability protocol involving a periodic exchange of
      hello messages across each link.  This function might be intrinsic
      to the link-level protocols used (e.g.  LAPB, DDCMP).  However, it
      is in general ill-advised to assume a host or gateway is operating
      correctly if its link-level reachability protocol is operating
      correctly.  Additional confirmation is required in the form of an
      operating routing algorithm or peer-level reachability protocol,