doc: Add RFC documents

1 files changed, 1311 insertions, 0 deletions

diff --git a/doc/rfc/rfc985.txt b/doc/rfc/rfc985.txt
new file mode 100644
index 0000000..15499c6
--- /dev/null
+++ b/doc/rfc/rfc985.txt
@@ -0,0 +1,1311 @@
+
+
+Network Working Group                   Network Technical Advisory Group
+Request for Comments: 985                                            NSF
+                                                                May 1986
+
+              Requirements for Internet Gateways -- Draft
+
+
+Status of this Memo
+
+   This RFC summarizes the requirements for gateways to be used on
+   networks supporting the DARPA Internet protocols.  While it applies
+   specifically to National Science Foundation research programs, the
+   requirements are stated in a general context and are believed
+   applicable throughout the Internet community.  This document was
+   prepared by the Gateway Requirements Subcommittee of the NSF Network
+   Technical Advisory Group in cooperation with the Internet Activities
+   Board, Internet Architecture Task Force and Internet Engineering Task
+   Force.  It requests discussion and suggestions for improvements.
+   Distribution of this memo is unlimited.
+
+   The purpose of this document is to present guidance for vendors
+   offering products that might be used or adapted for use in an
+   Internet application.  It enumerates the protocols required and gives
+   references to RFCs and other documents describing the current
+   specifications.  In a number of cases the specifications are evolving
+   and may contain ambiguous or incomplete information.  In these cases
+   further discussion giving specific guidance is included in this
+   document.  Specific policy issues relevant to the NSF scientific
+   networking community are summarized in an Appendix.
+
+   *********************************************************************
+
+      This is a DRAFT edition of this statement of gateway requirements.
+      Comments are sought on this document for consideration and
+      possibly incorporated in the final edition.  Comments are
+      especially sought from those actually developing gateways,
+      particular vendors and potential vendors of gateways.  The period
+      for comments is 90 days ending 15-Aug-86, at which time revised
+      edition will be issued with a new RFC number.
+
+   *********************************************************************
+
+   Suggestions and comments on this document can be sent to the
+   subcommittee chairman Dave Mills (mills@usc-isid.arpa), or NTAG
+   committee chairman Dave Farber (farber@huey.udel.edu).  The
+   subcommittee members, present affiliations and Internet mailboxes are
+   as follows:
+
+      Hank Dardy, NRL                 dardy@nrl.arpa
+      Dave Farber, U Delaware         farber@huey.udel.edu
+      Dennis Jennings, JVNC         jennings%pucc.bitnet@wiscvm.wisc.edu
+
+
+NTAG                                                            [Page 1]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+      Larry Landweber, U Wisconsin    landweber@rsch.wisc.edu
+      Tony Lauck, DEC                 rhea!bergil!lauck@decwrl.arpa
+      Dave Mills (Chairman), Linkabit mills@usc-isid.arpa
+      Dennis Perry, DARPA/IPTO        perry@ipto.arpa
+
+   The subcommittee wishes to thank the following additional
+   contributors and invited referees:
+
+      Len Bosack, Stanford U/CISCO    bosack@su-score.arpa
+      Bob Braden, ISI                 braden@isi-braden.arpa
+      Hans-Werner Braun, U Michigan   hwb@gw.umich.edu
+      Noel Chiappa, MIT/Proteon       jnc@proteon.arpa
+      Doug Comer, Purdue U            dec@cs.purdue.edu
+      Ira Fuchs, Princeton U          fuchs%pucc.bitnet@wiscvm.wisc.edu
+      Ed Krol, U Illinois            krol%uiucvmd.bitnet@wiscvm.wisc.edu
+      Barry Leiner, RIACS             leiner@riacs.arpa
+      Mike Muuss, BRL                 mike@brl.arpa
+      Ron Natalie, BRL                ron@brl.arpa
+      Harvey Newman, CIT              newman@cit-hex.arpa
+      Jon Postel, ISI                 postel@usc-isib.arpa
+      Marshall Rose, NRTC             mrose@nrtc-gremlin.northrop.com
+      Jeff Schiller, MIT              jis@bitsy.mit.edu
+      Lixia Zhang, MIT                lixia@xx.lcs.mit.edu
+
+1.  Introduction
+
+   The following sections are intended as an introduction and background
+   for those unfamiliar with the DARPA Internet architecture and the
+   Internet gateway model.  General background and discussion on the
+   Internet architecture and supporting protocol suite can be found in
+   the DDN Protocol Handbook [25] and ARPANET Information Brochure [26],
+   both available from the Network Information Center, SRI
+   International, Menlo Park, CA 94025.  Readers familiar with these
+   concepts can proceed directly to Section 2.
+
+   1.1.  The DARPA Internet Architecture
+
+      The DARPA Internet system consists of a number of gateways and
+      networks that collectively provide packet transport for hosts
+      subscribing to the DARPA Internet protocol architecture.  These
+      protocols include the Internet Protocol (IP), Internet Control
+      Message Protocol (ICMP), Transmission Control Protocol (TCP) and
+      application protocols depending upon them.  All protocols use IP
+      as the basic packet-transport mechanism.  IP is a datagram, or
+      connectionless, service and includes provision for service
+      specification, fragmentation/reassembly and security information.
+      ICMP is considered an integral part of IP, although it is
+
+
+NTAG                                                            [Page 2]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+      architecturally layered upon it.  ICMP provides error reporting,
+      flow control and first-hop gateway redirection.  Reliable data
+      delivery is provided in the protocol suite by TCP, which provides
+      end-end retransmission, resequencing and connection control.
+      Connectionless service is provided by the User Datagram Protocol
+      (UDP).
+
+      The Internet community presently includes several thousand hosts
+      connected to over 400 networks with about 120 gateways.  There are
+      now well over 2400 hosts registered in the ARPA domain alone and
+      an unknown number registered in other domains, with the total
+      increasing at about ten percent each month.  Many of the hosts,
+      gateways and networks in the Internet community are administered
+      by civil organizations, including universities, research
+      laboratories and equipment manufacturers.  Most of the remainder
+      are administered by the US DoD and considered part of the DDN
+      Internet, which presently consists of three sets of networks: the
+      experimental segment, or ARPANET, the unclassified segment, or
+      MILNET, and the classified segment, which does not yet have a
+      collective name.
+
+      The Internet model includes constituent networks, called local
+      networks to distinguish them from the Internet system as a whole,
+      which are required only to provide datagram (connectionless)
+      transport.  This requires only best-effort delivery of individual
+      packets, or datagrams.  Each datagram carries 32-bit source and
+      destination addresses, which are encoded in three formats
+      providing a two-part address, one of which is the local-network
+      number and the other the host number on that local net.  According
+      to the Internet service specification, datagrams can be delivered
+      out of order, be lost or duplicated and/or contain errors.  In
+      those networks providing connection-oriented service the extra
+      reliability provided by virtual circuits enhances the end-end
+      robustness of the system, but is not strictly necessary.
+
+      Local networks are connected together in the Internet model by
+      means of Internet gateways.  These gateways provide datagram
+      transport only and normally seek to minimize the state information
+      necessary to sustain this service in the interest of routing
+      flexibility and robustness.  In the conventional model the gateway
+      has a physical interface and address on each of the local nets
+      between which it provides forwarding services.  The gateway also
+      participates in one or more distributed routing or reachability
+      algorithm such as the Gateway-Gateway Protocol (GGP) or Exterior
+      Gateway Protocol (EGP) in order to maintain its routing tables.
+
+
+
+
+NTAG                                                            [Page 3]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+   1.2.  The Internet Gateway Model
+
+      An Internet gateway is a self-contained, stand-alone packet switch
+      that performs the following functions:
+
+         1.  Interfaces to two or more packet-switching networks,
+             including encapsulation, address transformation and flow
+             control.
+
+         2.  Conforms to specific DARPA Internet protocols specified in
+             this document, including the Internet Protocol (IP),
+             Internet Control Message Protocol (ICMP), Exterior Gateway
+             Protocol (EGP) and others as necessary.
+
+         3.  Supports an interior gateway protocol (IGP) reachability or
+             routing algorithm in cases of multiple gateways operating
+             as a system.  Supports the EGP reachability algorithm to
+             exchange routes between systems, in particular the DARPA
+             "core" system operated by BBN.
+
+         4.  Receives and forwards Internet datagrams consistent with
+             good engineering practice in the management of resources,
+             congestion control and fairness.  Recognizes various error
+             conditions and generates ICMP error and information
+             messages as required.
+
+         5.  Provides system support facilities, including loading,
+             debugging, status reporting, exception reporting and
+             control.
+
+      In some configurations gateways may be connected to
+      packet-switching local nets that provide generic local-net
+      routing, error-control and resource-management functions.  In
+      others gateways may be directly connected via serial lines, so
+      that these functions must be provided by the gateways themselves.
+
+      There are three typical scenarios that should be addressed by
+      gateway vendors:
+
+         1.  National or regional network.  Gateways of this class
+             should be capable of switching multiple continuous flows in
+             the 1.5-Mbps range at rates to several thousand packets per
+             second.  They will be high-performance, possibly redundant,
+             multiple-processor devices, probably procured as a system
+             and operated remotely from a regional or national
+             monitoring center.  The design of these gateways should
+             emphasize high aggregate throughput, throughput-sensitive
+
+
+NTAG                                                            [Page 4]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+             resource management and very high reliability.  The typical
+             application would be an NSF backbone net or one of the
+             consortium or regional nets.
+
+         2.  Campus network.  Gateways of this class should be capable
+             of switching some burst flows at 10-Mbps (Ethernets, etc.),
+             together with some flows in the 64-Kbps range or lower, at
+             rates to perhaps several thousand packets per second.  They
+             will be medium-performance devices, probably competitively
+             procured from different vendors for each campus and
+             operated from a campus computing center.  The design of
+             these gateways should emphasize low average delay and good
+             burst performance, together with delay and type-of-service
+             sensitive resource management.  Their chief function might
+             be to interconnect various LANs and campus computing
+             resources, including a high-speed interconnect to a
+             national or regional net.  An important factor will be a
+             very flexible routing mechanism, since these gateways may
+             have to select among several backbone nets based on
+             cost/performance considerations.
+
+         3.  Department network.  Gateways of this class should be
+             capable of switching a small number of burst flows at
+             10-Mbps (Ethernets, etc.), together with a small number of
+             flows in the range 64-Kbps or lower, at rates of a few
+             hundred packets per second.  They will be
+             medium-performance devices procured from a variety of
+             vendors and used for protocol-matching, LAN repeaters and
+             as general utility packet switches.  They will probably be
+             locally maintained by the various users and not be used as
+             transit switches.
+
+      It is important to realize that Internet gateways normally operate
+      in an unattended mode, but that equipment and software faults can
+      affect the entire Internet.  While some of the above scenarios
+      involve positive control of some gateways from a monitoring
+      center, usually via a path involving other networks and Internet
+      gateways, others may involve much less formal control procedures.
+      Thus the gateways must be highly robust and be expected to
+      operate, possibly in a degraded state, under conditions of extreme
+      congestion or failure of network resources.
+
+
+
+
+
+
+
+
+NTAG                                                            [Page 5]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+2.  Protocols Required
+
+   The Internet architecture uses datagram gateways to interconnect
+   networks and subnetworks.  These gateways function as intermediate
+   systems (IS) with respect to the ISO connectionless network model and
+   incorporate defined packet formats, routing algorithms and related
+   procedures.  In the following it is assumed the protocol
+   implementation supports the full protocol, including all required
+   options, with exceptions only as noted.
+
+   2.1.  Internet Protocol (IP)
+
+      This is the basic datagram protocol used in the Internet system.
+      It is described in RFC-791 [1] and also MIL-STD-1777 [5], both of
+      which are intended to describe the same standard, but in quite
+      different words.
+
+      With respect to current gateway requirements the following can be
+      ignored, although they may be required in future:  Type of Service
+      field, Security option, Stream ID option and Timestamp option.
+      However, if recognized, the interpretation of these quantities
+      must conform to the standard specification.
+
+      Note that the Internet gateway model does not require that the
+      gateway reassemble IP datagrams with destination address other
+      than the gateway itself.  However, in the case of those protocols
+      in which the gateway directly participates as a peer, including
+      routing and monitor/control protocols, the gateway may have to
+      reassemble datagrams addressed to it.  This consideration is most
+      pertinent to EGP.
+
+      Note that, of the five classes of IP addresses.  Class-A through
+      Class-E, Class-D and Class-E addresses are reserved for
+      experimental use.  A gateway which is not participating in these
+      experiments should ignore all packets with a Class-D or Class-E
+      destination IP address.  No ICMP Destination Unreachable or ICMP
+      Redirect messages should result from receiving such packets.
+
+   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,
+      such as used in EGP.
+
+      Failure and restoration of a link and/or gateway are considered
+      network events and must be reported to the control center.  It is
+      desirable, although not required, that reporting paths not require
+      correct functioning of the routing algorithm itself.
+
+   6.2.  Routing Algorithm
+
+      It has been the repeated experience of the Internet community
+      participants that the routing mechanism, whether static or
+      dynamic, is the single most important engineering issue in network
+      design.  In all but trivial network topologies it is necessary
+      that some degree of routing dynamics is vital to successful
+      operation, whether it be affected by manual or automatic means or
+      some combination of both.  In particular, if routing changes are
+      made manually, the changes must be possible without taking down
+      the gateways for reconfiguration and, preferably, be possible from
+      a remote site such as a control center.
+
+      It is not likely that all nets can be maintained from a
+      full-service control center, so that automatic-fallback or
+      rerouting features may be required.  This must be considered the
+      normal case, so that systems of gateways operating as the only
+
+
+NTAG                                                           [Page 12]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+      packet switches in a network would normally be expected to have a
+      routing algorithm with the capability of reacting to link and
+      other gateway failures and changing the routing automatically.
+      Following is a list of features considered necessary:
+
+         1.  The algorithm must sense the failure or restoration of a
+             link or other gateway and switch to appropriate paths
+             within an interval less than the typical TCP user timeout
+             (one minute is a safe assumption).
+
+         2.  The algorithm must never form routing loops between
+             neighbor gateways and must contain provisions to avoid and
+             suppress routing loops that may form between non-neighbor
+             gateways.  In no case should a loop persist for longer than
+             an interval greater than the typical TCP user timeout.
+
+         3.  The control traffic necessary to operate the routing
+             algorithm must not significantly degrade or disrupt normal
+             network operation. Changes in state which might momentarily
+             disrupt normal operation in a local area must not cause
+             disruption in remote areas of the network.
+
+         4.  As the size of the network increases, the demand on
+             resources must be controlled in an efficient way.  Table
+             lookups should be hashed, for example, and data-base
+             updates handled piecemeal, with only the changes broadcast
+             over a wide area.  Reachability and delay metrics, if used,
+             must not depend on direct connectivity to all other
+             gateways or the use of network-specific broadcast
+             mechanisms. Polling procedures (e.g.  for consistency
+             checking) should be used only sparingly and in no case
+             introduce an overhead exceeding a constant independent of
+             network topology times the longest non-looping path.
+
+         5.  The use of a default gateway as a means to reduce the size
+             of the routing data base is strongly discouraged in view of
+             the many problems with multiple paths, loops and
+             mis-configuration vulnerabilities.  If used at all, it
+             should be limited to a discovery function, with operational
+             routes cached from external or internal data bases via
+             either the routing algorithm or EGP.
+
+         6.  This document places no restriction on the type of routing
+             algorithm, such as node-based, link-based or any other
+             algorithm, or metric, such as delay or hop-count.  However,
+             the size of the routing data base must not be allowed to
+             exceed a constant independent of network topology times the
+
+
+NTAG                                                           [Page 13]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+             number of nodes times the mean connectivity (average number
+             of incident links).  An advanced design would not require
+             that the entire routing data base be kept in any particular
+             gateway, so that discovery and caching techniques would be
+             necessary.
+
+7.  Operation and Maintenance
+
+   Gateways and packets switches are often operated as a system by some
+   organization who agrees to operate and maintain the gateways, as well
+   as to resolve link problems with the respective common carriers. It
+   is important to note that the network control site may not be
+   physically attached to the network being monitored.  In general, the
+   following requirements apply:
+
+      1.  Each gateway must operate as a stand-alone device for the
+          purposes of local hardware maintenance.  Means must be
+          available to run diagnostic programs at the gateway site using
+          only on-site tools, which might be only a diskette or tape and
+          local terminal.  It is desirable, although not required, to
+          run diagnostics via the network and to automatically reboot
+          and dump the gateway via the net in case of fault.  In
+          general, this requires special hardware.
+
+          The use of full-blown transport services such as TCP is in
+          general ill-advised if required just to reboot and dump the
+          gateway. Consideration should be given simple
+          retransmission-overlay protocols based on UDP or specific
+          monitoring protocols such as HMP described in RFC-869 [7].
+
+      2.  It must be possible to reboot and dump the gateway manually
+          from the control site.  Every gateway must include a watchdog
+          timer that either initiates a reboot or signals a remote
+          control site if not reset periodically by the software.  It is
+          desirable that the data involved reside at the control site
+          and be transmitted via the net; however, the use of local
+          devices at the gateway site is acceptable. Nevertheless, the
+          operation of initiating reboot or dump must be possible via
+          the net, assuming a path is available and the connecting links
+          are operating.
+
+      3.  A mechanism must be provided to accumulate traffic statistics
+          including, but not limited to, packet tallies, error-message
+          tallies and so forth.  The preferred method of retrieving
+          these data is by explicit, periodic request from the control
+          site using a standard datagram protocol based on UDP or HMP.
+
+
+
+NTAG                                                           [Page 14]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+          The use of full-blown transport services such as TCP is in
+          general ill-advised if required just to collect statistics
+          from the gateway. Consideration should be given simple
+          retransmission-overlay protocols based on UDP or HMP.
+
+      4.  Exception reports ("traps") occuring as the result of hardware
+          or software malfunctions should be transmitted immediately
+          (batched to reduce packet overheads when possible) to the
+          control site using a standard datagram protocol based on UDP
+          or HMP.
+
+      5.  A mechanism must be provided to display link and node status
+          on a continuous basis at the control site.  While it is
+          desirable that a complete map of all links and nodes be
+          available, it is acceptable that only those components in use
+          by the routing algorithm be displayed.  This information is
+          usually available locally at the control site, assuming that
+          site is a participant in the routing algorithm.
+
+   The above functions require in general the participation of a control
+   site or agent.  The preferred way to provide this is as a user
+   program suitable for operation in a standard software environment
+   such as Unix.  The program would use standard IP protocols such as
+   TCP, UDP, and HMP to control and monitor the gateways.  The use of
+   specialized host hardware and software requiring significant
+   additional investment is strongly discouraged;  nevertheless, some
+   vendors may elect to provide the control agent as an integrated part
+   of the network in which the gateways are a part.  If this is the
+   case, it is required that a means be available to operate the control
+   agent from a remote site using Internet protocols and paths and with
+   equivalent functionality with respect to a local agent terminal.
+
+   Remote control of a gateway via Internet paths can involve either a
+   direct approach, in which the gateway supports TCP and/or UDP
+   directly, or an indirect approach, in which the control agent
+   supports these protocols and controls the gateway itself using
+   proprietary protocols. The former approach is preferred, although
+   either approach is acceptable.
+
+
+
+
+
+
+
+
+
+
+
+NTAG                                                           [Page 15]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+8.  References and Bibliography
+
+   [1]  Defense Advanced Research Projects Agency, "Internet Protocol",
+        DARPA Network Working Group Report RFC-791, USC Information
+        Sciences Institute, September 1981.
+
+   [2]  Defense Advanced Research Projects Agency, "Internet Control
+        Message Protocol", DARPA Network Working Group Report RFC-792,
+        USC Information Sciences Institute, September 1981.
+
+   [3]  Advanced Research Projects Agency, "Interface Message Processor
+        - Specifications for the Interconnection of a Host and an IMP",
+        BBN Report 1822, Bolt Beranek and Newman, December 1981.
+
+   [4]  Plummer, D., "An Ethernet Address Resolution Protocol", DARPA
+        Network Working Group Report RFC-826, Symbolics, September 1982.
+
+   [5]  United States Department of Defense, "Military Standard Internet
+        Protocol", Military Standard MIL-STD-1777, August 1983.
+
+   [6]  Defense Communications Agency, "Defense Data Network X.25 Host
+        Interface Specification", BBN Communications, December 1983.
+
+   [7]  Hinden, R., "A Host Monitoring Protocol", DARPA Network Working
+        Group Report RFC-869, BBN Communications, December 1983.
+
+   [8]  Korb, J.T., "A Standard for the Transmission of IP Datagrams
+        over Public Data Networks", DARPA Network Working Group Report
+        RFC-877, Purdue University, September 1983.
+
+   [9]  Nagle, J., "Congestion Control in IP/TCP Internetworks", DARPA
+        Network Working Group Report RFC-896, Ford Aerospace,
+        January 1984.
+
+   [10] Hornig, C., "A Standard for the Transmission of IP Datagrams
+        over Ethernet Networks", DARPA Network Working Group Report
+        RFC-894, Symbolics, April 1984.
+
+   [11] Mills, D.L., "Exterior Gateway formal Specification", DARPA
+        Network Working Group Report RFC-904, M/A-COM Linkabit,
+        April 1984.
+
+   [12] Postel, J., and J. Reynolds., "ARPA-Internet Protocol Policy",
+        DARPA Network Working Group Report RFC-902, USC Information
+        Sciences Institute, July 1984.
+
+
+
+
+NTAG                                                           [Page 16]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+   [13] Kirton, P., "EGP Gateway under Berkeley UNIX 4.2", DARPA Network
+        Working Group Report RFC-911, USC Information Sciences
+        Institute, August 1984.
+
+   [14] Postel, J., "Multi-LAN Address Resolution", DARPA Network
+        Working Group Report RFC-925, USC Information Sciences
+        Institute, October 1984.
+
+   [15] International Standards Organization, "Protocol for Providing
+        the Connectionless-Mode Network Services", DARPA Network Working
+        Group Report RFC-926, International Standards Organization,
+        December 1984.
+
+   [16] National Research Council, "Transport Protocols for Department
+        of Defense Data Networks", DARPA Network Working Group Report
+        RFC-942, National Research Council, March 1985.
+
+   [17] Postel, J., "DOD Statement on NRC Report", DARPA Network Working
+        Group Report RFC-945, USC Information Sciences Institute,
+        April 1985.
+
+   [18] International Standards Organization, "Addendum to the Network
+        Service Definition Covering Network Layer Addressing", DARPA
+        Network Working Group Report RFC-941, International Standards
+        Organization, April 1985.
+
+   [19] Leiner, B., J. Postel, R. Cole and D. Mills, "The DARPA Internet
+        Protocol Suite", Proceedings INFOCOM 85, Washington DC,
+        March 1985]  Also in: IEEE Communications Magazine, March 1985.
+
+   [20] Winston, I., "Two Methods for the Transmission of IP Datagrams
+        over IEEE 802.3 Networks", DARPA Network Working Group Report
+        RFC-948, University of Pennsylvania, June 1985.
+
+   [21] Mogul, J., and J. Postel, "Internet Standard Subnetting
+        Procedure", DARPA Network Working Group Report RFC-950, Stanford
+        University, August 1985.
+
+   [22] Reynolds, J., and J. Postel, "Official ARPA-Internet Protocols",
+        DARPA Network Working Group Report RFC-961, USC Information
+        Sciences Institute, October 1985.
+
+   [23] Reynolds, J., and J. Postel, "Assigned Numbers", DARPA Network
+        Working Group Report RFC-960, USC Information Sciences
+        Institute, December 1985.
+
+
+
+
+NTAG                                                           [Page 17]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+   [24] Nagle, J., "On Packet Switches with Infinite Storage", DARPA
+        Network Working Group Report RFC-970, Ford Aerospace,
+        December 1985.
+
+   [25] Defense Communications Agency, "DDN Protocol Handbook",
+        NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI
+        International, December 1985.
+
+   [26] Defense Communications Agency, "ARPANET Information Brochure",
+        NIC-50003, SRI International, December 1985.
+
+   [27] Mills, D.L., "Autonomous Confederations", DARPA Network Working
+        Group Report RFC-975, M/A-COM Linkabit, February 1986.
+
+   [28] Jacobsen, O., and J. Postel, "Protocol Document Order
+        Information",  DARPA Network Working Group Report RFC-980, SRI
+        International, March 1986.
+
+   [29] Malis, A.G., "PSN End-to-End Functional Specification", DARPA
+        Network Working Group Report RFC-979, BBN Communications,
+        March 1986.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NTAG                                                           [Page 18]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+Appendix A.  Ethernet Management
+
+   Following is a summary of procedures specified for use by hosts and
+   gateways on an Ethernet.
+
+   A.1.  Hardware
+
+      A packet is accepted from the cable only if its destination
+      Ethernet address matches either the assigned interface address or
+      a broadcast/multicast address.  Presumably, this filtering is done
+      by the interface hardware;  however, the software driver is
+      expected to do this if the hardware does not.  Some hosts
+      incorporate an optional feature that associates an assigned
+      multicast address with a specific subnet in order to restrict
+      access for testing, etc.  When this feature is activated, the
+      assigned multicast address replaces the broadcast address.
+
+   A.2.  IP datagram
+
+      In case of broadcast/multicast (as determined from the destination
+      Ethernet address) an IP datagram is discarded if the source IP
+      address is not in the same subnet, as determined by the assigned
+      host IP address and subnet mask.  It is desirable that this test
+      be overridden by a configuration parameter, in order to support
+      the infrequent cases where more than one subnet may coexist on the
+      same cable.
+
+   A.3.  ARP datagram
+
+      An ARP reply is discarded if the destination IP address does not
+      match the local host address.  An ARP request is discarded if the
+      source IP address is not in the same subnet.  It is desirable that
+      this test be overridden by a configuration parameter, in order to
+      support the infrequent cases where more than one subnet may
+      coexist on the same cable (see RFC-925 for examples).  An ARP
+      reply is generated only if the destination protocol IP address is
+      reachable from the local host (as determined by the routing
+      algorithm) and the next hop is not via the same interface.  If the
+      local host functions as a gateway, this may result in ARP replies
+      for destinations not in the same subnet.
+
+   A.4.  ICMP redirect
+
+      An ICMP redirect is discarded if the destination IP address does
+      not match the local host address or the new target address is not
+      on the same subnet.  An accepted redirect updates the routing data
+      base for the old target address.  If there is no route or
+
+
+NTAG                                                           [Page 19]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+      associated with the old target address, the redirect is ignored.
+      If the old route is associated with a default gateway, a new route
+      associated with the new target address is inserted in the data
+      base.  Note that it is not possible to send a gratuitous redirect
+      unless the sender is possessed of considerable imagination.
+
+      When subnets are in use there is some ambiguity as to the scope of
+      a redirect, unless all hosts and gateways involved have prior
+      knowledge of the subnet masks.  It is recommended that the use of
+      ICMP network-redirect messages be avoided in favor of ICMP
+      host-redirect messages instead.  This requires the original sender
+      (i.e.  redirect recipient) to support a general IP
+      address-translation cache, rather than the usual network table.
+      However, this is normally done anyway in the case of ARP.
+
+      An ICMP redirect is generated only if the destination IP address
+      is reachable from the local host (as determined by the routing
+      algorithm) and the next hop is via the same interface and the
+      target address is defined in the routing data base.  Redirects
+      should never be sent in response to an IP net or subnet broadcast
+      address or in response to a Class-D or Class-E IP address.
+
+      ICMP redirects are never forwarded, regardless of destination
+      address.  The source IP address of the ICMP redirect itself is not
+      checked, since the sending gateway may use one of its addresses
+      not on the common net.  The source IP address of the encapsulated
+      IP datagram is not checked on the assumption the host or gateway
+      sending the original IP datagram knows what it is doing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NTAG                                                           [Page 20]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+Appendix B.  Policy Issues
+
+   The following sections discuss certain issues of special concern to
+   the NSF scientific networking community.  These issues have primary
+   relevance in the policy area, but also have ramifications in the
+   technical area.
+
+   B.1.  Interconnection Technology
+
+      Currently the most important common interconnection technology
+      between Internet systems of different vendors is Ethernet.  Among
+      the reasons for this are the following:
+
+         1.  Ethernet specifications are well-understood and mature.
+
+         2.  Ethernet technology is in almost all aspects vendor
+             independent.
+
+         3.  Ethernet-compatible systems are common and becoming more
+             so.
+
+      These advantages combined favor the use of Ethernet technology as
+      the common point of demarcation between NSF network systems
+      supplied by different vendors, regardless of technology.  It is a
+      requirement of NSF gateways that, regardless of the possibly
+      proprietary switching technology used to implement a given
+      vendor-supplied network, its gateways must support an Ethernet
+      attachment to gateways of other vendors.
+
+      It is expected that future NSF gateway requirements will specify
+      other interconnection technologies.  The most likely candidates
+      are those based on X.25 or IEEE 802, but other technologies
+      including broadband cable, fiber-optic or other protocols such as
+      DDCMP may also be considered.
+
+   B.2.  Proprietary and Extensible Issues
+
+      Internet technology is a growing, adaptable technology.  Although
+      hosts, gateways and networks supporting this technology have been
+      in continuous operation for several years, vendors users and
+      operators should understand that not all networking issues are
+      fully understood. As a result, when new needs or better solutions
+      are developed for use in the NSF networking community, it may be
+      necessary to field new protocols.  Normally, these new protocols
+      will be designed to interoperate in all practical respects with
+      existing protocols; however, occasionally it may happen that
+      existing systems must be upgraded to support these protocols.
+
+
+NTAG                                                           [Page 21]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+      NSF systems vendors should understand that they also undertake a
+      commitment to remain aware of current Internet technology and be
+      prepared to upgrade their products from time to time as
+      appropriate.  As a result, these vendors are strongly urged to
+      consider extensibility and periodic upgrades as fundamental
+      characteristics of their products.  One of the most productive and
+      rewarding ways to do this on a long-term basis is to participate
+      in ongoing Internet research and development programs in
+      partnership with the academic community.
+
+   B.3.  Multi-Protocol Gateways
+
+      Although the present requirements for an NSF gateway specify only
+      the Internet protocol suite, it is highly desirable that gateway
+      designs allow future extensions to support additional suites and
+      allow simultaneous operation with more than a single one.
+      Clearly, the ISO protocol suite is a prime candidate for one of
+      these suites.  Other candidates include XNS and DECnet.
+
+      Future requirements for NSF gateways may include provisions for
+      other protocol suites in addition to Internet, as well as models
+      and specifications to interwork between them, should that be
+      appropriate.  For instance, it is expected that the ISO suite will
+      eventually become the dominant one;  however, it is also expected
+      that requirements to support other suites will continue, perhaps
+      indefinitely.
+
+      Present NSF gateway requirements do not include protocols above
+      the network layer, such as TCP, unless necessary for network
+      monitoring or control.  Vendors should recognize that future
+      requirements to interwork between Internet and ISO applications,
+      for example, may result in an opportunity to market gateways
+      supporting multiple protocols at all levels through the
+      application level.  It is expected that the network-level NSF
+      gateway requirements summarized in this document will be
+      incorporated in the requirements document for these
+      application-level gateways.
+
+   B.4.  Access Control and Accounting
+
+      There are no requirements for NSF gateways at this time to
+      incorporate specific access-control and accounting mechanisms in
+      the design;  however, these important issues are currently under
+      study and will be incorporated into a redraft of this document at
+      an early date.  Vendors are encouraged to plan for the early
+      introduction of these mechanisms in their products.  While at this
+
+
+
+NTAG                                                           [Page 22]
+
+
+
+RFC 985                                                         May 1986
+Requirements for Internet Gateways -- DRAFT
+
+
+      time no definitive common model for access control and accounting
+      has emerged, it is possible to outline some general features such
+      a model is likely to have, among them the following:
+
+         1.  The primary access control and accounting executive
+             mechanisms will be in the service hosts themselves, not the
+             gateways, packet switches or workstations.
+
+         2.  Agents acting on behalf of access control and accounting
+             executive mechanisms may be necessary in the gateways,
+             packet switches or workstations.  These may be used to
+             collect data, enforce password protection or mitigate
+             resource priority and fairness.  However, the architecture
+             and protocols used by these agents may be a local matter
+             and not possible to specify in advance.
+
+         3.  NSF gateways may be required to incorporate access control
+             and accounting mechanisms based on packet
+             source/destination address, as well as other fields in the
+             IP header, internal priority and fairness.  However, it is
+             extremely unlikely that these mechanisms would involve a
+             user-level login to the gateway itself.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+NTAG                                                           [Page 23]
+