GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc985

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc985.txt · Last modified: 1986/05/14 18:19 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki