Requirements for Internet gateways - draft RFC 985

Document type: RFC - Unknown (Legacy Stream)Obsoleted by RFC 1009Published: 1986-05Other versions: plain text, pdf, htmlIPR Disclosures | Dependencies to this RFCNetwork Working Group Network Technical Advisory GroupRequest for Comments: 985 NSFMay1986Requirements for Internet Gateways -- DraftStatus of this MemoThis RFC summarizes the requirements for gateways to be usedonnetworks supporting the DARPA Internet protocols. Whileit appliesspecifically to National Science Foundation research programs, therequirements are stated in a general context and are believedapplicable throughout the Internet community. This document wasprepared by the Gateway Requirements Subcommittee of the NSF NetworkTechnical Advisory Group in cooperation with the Internet ActivitiesBoard, Internet Architecture Task Force and Internet Engineering TaskForce. It requests discussion and suggestions for improvements.Distribution of this memo is unlimited.The purpose of this document is to present guidance for vendorsoffering products that might be used or adapted for use inanInternet application. It enumerates the protocolsrequired and givesreferences to RFCs and other documents describing the currentspecifications. In a number of cases the specifications are evolvingand may contain ambiguous or incomplete information. In these casesfurther discussion giving specific guidance is included in thisdocument. Specific policy issues relevant to the NSF scientificnetworking 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 andpossibly incorporated in the final edition. Comments areespecially sought from those actually developing gateways,particular vendors and potential vendors of gateways. The periodfor comments is 90 days ending 15-Aug-86, at which time revisededition will be issued with a new RFC number.*********************************************************************Suggestions and comments on this document can be sent to thesubcommittee chairman Dave Mills (mills@usc-isid.arpa), or NTAGcommittee chairman Dave Farber (farber@). Thesubcommittee members, present affiliations and Internet mailboxes areas follows:Hank Dardy, NRL dardy@nrl.arpaDave Farber, U Delaware farber@Dennis Jennings, JVNCjennings%pucc.bitnet@NTAG [Page 1]RFC 985 May 1986Requirements for Internet Gateways -- DRAFTLarry Landweber, U Wisconsin landweber@ Tony Lauck, DECrhea!bergil!lauck@decwrl.arpaDave Mills (Chairman), Linkabit mills@usc-isid.arpa Dennis Perry, DARPA/IPTO perry@ipto.arpaThe 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@Noel Chiappa, MIT/Proteon jnc@proteon.arpaDoug Comer, Purdue U dec@Ira Fuchs, Princeton Ufuchs%pucc.bitnet@Ed Krol, U Illinoiskrol%uiucvmd.bitnet@Barry Leiner, RIACS leiner@riacs.arpaMike Muuss, BRL mike@brl.arpaRon Natalie, BRL ron@brl.arpaHarvey Newman, CIT newman@cit-hex.arpaJon Postel, ISI postel@usc-isib.arpaMarshall Rose, NRTCmrose@Jeff Schiller, MIT jis@Lixia Zhang, MIT lixia@1. IntroductionThe following sections are intended as an introduction and backgroundfor those unfamiliar with the DARPA Internet architecture and theInternet gateway model. General background and discussion on theInternet architecture and supporting protocol suite can be found inthe 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 theseconcepts can proceed directly to Section 2.1.1. The DARPA Internet ArchitectureThe DARPA Internet system consists of a number of gateways andnetworks that collectively provide packet transport for hostssubscribing to the DARPA Internet protocol architecture. Theseprotocols include the Internet Protocol (IP), Internet ControlMessage Protocol (ICMP), Transmission Control Protocol (TCP) andapplication protocols depending upon them. All protocols use IPas the basic packet-transport mechanism. IP is a datagram, orconnectionless, service and includes provision for servicespecification, fragmentation/reassembly and security information.ICMP is considered an integral part of IP, although it isNTAG [Page 2]RFC 985 May 1986Requirements for Internet Gateways -- DRAFTarchitecturally layered upon it. ICMP provides error reporting,flow control and first-hop gateway redirection. Reliable datadelivery is provided in the protocol suite by TCP, which providesend-end retransmission, resequencing and connection control.Connectionless service is provided by the User Datagram Protocol(UDP).The Internet community presently includes several thousand hostsconnected to over 400 networks with about 120 gateways. There arenow well over 2400 hosts registered in the ARPA domain alone andan unknown number registered in other domains, with the totalincreasing at about ten percent each month. Many of the hosts,gateways and networks in the Internet community are administeredby civil organizations, including universities, researchlaboratories and equipment manufacturers. Most of the remainderare administered by the US DoD and considered part of the DDNInternet, which presently consists of three sets of networks: theexperimental segment, or ARPANET, the unclassified segment, orMILNET, and the classified segment, which does not yet have acollective name.The Internet model includes constituent networks, called localnetworks 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 individualpackets, or datagrams. Each datagram carries 32-bit source anddestination addresses, which are encoded in three formatsproviding a two-part address, one of which is thelocal-networknumber and the other the host number on that local net. Accordingto the Internet service specification, datagrams can be deliveredout of order, be lost or duplicated and/or contain errors. Inthose networks providing connection-oriented service the extrareliability provided by virtual circuits enhances the end-endrobustness of the system, but is not strictly necessary.Local networks are connected together in the Internet model bymeans of Internet gateways. These gateways provide datagramtransport only and normally seek to minimize the state informationnecessary to sustain this service in the interest of routingflexibility and robustness. In the conventional model the gatewayhas a physical interface and address on each of the local netsbetween which it provides forwarding services. The gateway alsoparticipates in one or more distributed routing or reachabilityalgorithm such as the Gateway-Gateway Protocol (GGP) or ExteriorGateway Protocol (EGP) in order to maintain its routing tables.NTAG [Page 3]RFC 985 May 1986Requirements for Internet Gateways -- DRAFT1.2. The Internet Gateway ModelAn Internet gateway is a self-contained, stand-alone packet switchthat performs the following functions:1. Interfaces to two or more packet-switching networks,including encapsulation, address transformation and flowcontrol.2. Conforms to specific DARPA Internet protocols specified inthis document, including the Internet Protocol (IP),Internet Control Message Protocol (ICMP), Exterior GatewayProtocol (EGP) and others as necessary.3. Supports an interior gateway protocol (IGP) reachability orrouting algorithm in cases of multiple gateways operatingas a system. Supports the EGP reachability algorithm toexchange routes between systems, in particular the DARPA"core" system operated by BBN.4. Receives and forwards Internet datagrams consistent withgood engineering practice in the management of resources,congestion control and fairness. Recognizes various errorconditions and generates ICMP error and informationmessages as required.5. Provides system support facilities, including loading,debugging, status reporting, exception reporting andcontrol.In some configurations gateways may be connected to packet-switching local nets that provide genericlocal-netrouting, error-control and resource-management functions. Inothers gateways may be directly connected via serial lines, sothat these functions must be provided by the gateways themselves.There are three typical scenarios that should be addressed bygateway vendors:1. National or regional network. Gateways of this classshould be capable of switching multiple continuous flows inthe 1.5-Mbps range at rates to several thousand packets persecond. They will be high-performance, possibly redundant,multiple-processor devices, probably procured as a systemand operated remotely from a regional or national monitoring center. The design of these gateways shouldemphasize high aggregate throughput,throughput-sensitiveNTAG [Page 4]RFC 985 May 1986Requirements for Internet Gateways -- DRAFTresource management and very high reliability. The typicalapplication would be an NSF backbone net or one of theconsortium or regional nets.2. Campus network. Gateways of this class should be capableof switching some burst flows at 10-Mbps (Ethernets, etc.),together with some flows in the 64-Kbps range or lower, atrates to perhaps several thousand packets per second. Theywill be medium-performance devices, probably competitivelyprocured from different vendors for each campus andoperated from a campus computing center. The design ofthese gateways should emphasize low average delay and goodburst performance, together with delay andtype-of-servicesensitive resource management. Their chief function mightbe to interconnect various LANs and campus computingresources, including a high-speed interconnect to anational or regional net. An important factor will be avery flexible routing mechanism, since these gateways mayhave to select among several backbone nets based oncost/performance considerations.3. Department network. Gateways of this class should becapable of switching a small number of burst flows at10-Mbps (Ethernets, etc.), together with a small number offlows in the range 64-Kbps or lower, at rates of a fewhundred packets per second. They will bemedium-performance devices procured from a variety ofvendors and used for protocol-matching, LAN repeaters andas general utility packet switches. They will probably belocally maintained by the various users and not be used astransit switches.It is important to realize that Internet gateways normally operatein an unattended mode, but that equipment and software faults canaffect the entire Internet. While some of the above scenariosinvolve positive control of some gateways from a monitoringcenter, usually via a path involving other networks and Internetgateways, others may involve much less formal control procedures.Thus the gateways must be highly robust and be expected tooperate, possibly in a degraded state, under conditions of extremecongestion or failure of network resources.NTAG [Page 5]RFC 985 May 1986Requirements for Internet Gateways -- DRAFT2. Protocols RequiredThe Internet architecture uses datagram gateways to interconnectnetworks and subnetworks. These gateways function as intermediatesystems (IS) with respect to the ISO connectionless network model andincorporate defined packet formats, routing algorithms and relatedprocedures. In the following it is assumed the protocol implementation supports the full protocol, including all requiredoptions, 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 ofwhich are intended to describe the same standard, but in quitedifferent words.With respect to current gateway requirements the following can beignored, although they may be required in future: Type of Servicefield, Security option, Stream ID option and Timestamp option.However, if recognized, the interpretation of these quantitiesmust conform to the standard specification.Note that the Internet gateway model does not require that thegateway reassemble IP datagrams with destination address otherthan the gateway itself. However, in the case of those protocolsin which the gateway directly participates as a peer, includingrouting and monitor/control protocols, the gateway may have toreassemble datagrams addressed to it. This consideration is mostpertinent to EGP.Note that, of the five classes of IP addresses. Class-A throughClass-E, Class-D and Class-E addresses are reserved for experimental use. A gateway which is not participating in theseexperiments should ignore all packets with a Class-D or Class-Edestination IP address. No ICMP Destination Unreachable or ICMPRedirect messages should result from receiving such packets.2.2. Internet Control Message Protocol (ICMP)This is an auxiliary protocol used to convey advice and errormessages and is described in RFC-792 [2].The distinction between subnets of a subnetted network, whichdepends on an arbitrary mask as described in RFC-950 [21], is ingeneral not visible outside that network. This distinction isimportant in the case of certain ICMP messages, including the ICMPNTAG [Page 6]RFC 985 May 1986Requirements for Internet Gateways -- DRAFTDestination Unreachable and ICMP Redirect messages. The ICMPDestination Unreachable message is sent by a gateway in responseto a datagram which cannot be forwarded because the destination isunreachable or down. A choice of several types of these messagesis available, including one designating the destination networkand another the destination host. However, the span of addressesimplied by the former is ill-defined unless the subnet mask isknown to the sender, which is in general not the case. It isrecommended that use of the ICMP Destination Network Unreachablemessages be avoided. Instead, an ICMP Destination Host Unreachable message should be sent for each distinct unreachableIP address.The ICMP Redirect message is sent by a gateway to a host in orderto change the address used by the host for a designated host ornet. A choice of four types of messages is available, dependingon whether it applies to a particular host, network or service.As in the previous case, these distinctions may depend upon thesubnet mask. As in the above case, it is recommended that the useof ICMP messages implying a span of addresses (e.g. net unreachable, net redirect) be avoided in favor of those implyingspecific addresses (e.g. host unreachable, host redirect).The ICMP Source Quench message has been the subject of muchcontroversy. It is not considered realistic at this time tospecify in detail the conditions under which this message is to begenerated or interpreted by a host or gateway.New host and gateway implementations are expected to support theICMP Address Mask messages described in RFC-950. It is highlydesirable, although not required, to provide correct data for ICMPTimestamp messages, which have been found useful in networkdebugging and maintenance.2.3. Exterior Gateway Protocol (EGP)This is the basic protocol used to exchange information betweengateway systems of the Internet and is described in RFC-904 [11].However, EGP as presently specified is an asymmetric protocol withonly the "non-core" procedures defined in RFC-904. There are atpresent no "core" procedures specified, which would be necessaryfor a stand-alone Internet. RFC-975 [27] suggests certainmodifications leading to a symmetric model; however, this is notan official specification.In principle, a stand-alone Internet can be built with non-coreEGP gateways using the EGP distance field to convey some metricNTAG [Page 7]RFC 985 May 1986Requirements for Internet Gateways -- DRAFTsuch as hop count. However, the use of EGP in this way as arouting algorithm is discouraged, since typical implementationsadapt very slowly to changing topology and have no loop-protectionfeatures.The EGP model requires each gateway belong to an autonomous systemof gateways. If a routing algorithm is operated in one or moregateways of an autonomous system, its data base must be coupled tothe EGP implementation in such a way that, when a net is declareddown by the routing algorithm, the net is also declared down viaEGP to other autonomous systems. This requirement is designed tominimize spurious traffic to "black holes" and insure fairutilization of the resources on other systems.There are no peer-discovery or authentication procedures definedin the present EGP specification and no defined interpretation ofthe distance fields in the update messages, although such procedures may be defined in future (see RFC-975). There iscurrently no guidance on the selection of polling parameters andno specific recovery procedures in case of certain error messages(e.g. "administratively prohibited"). It is recommended that EGPimplementations include provisions to initialize these parametersas part of the monitoring and control procedures and that changingthese procedures not require recompilation or rebooting thegateway.2.4. Address Resolution Protocol (ARP)This is an auxiliary protocol used to manage theaddress-translation function between hardware addresses in alocal-net environment and Internet addresses and described inRFC-826 [4]. However, there are a number of unresolved issueshaving to do with subnets and response to addresses not in thesame subnet or net. These issues, which are intertwined with ICMPand various gateway models, are discussed in Appendix A.3. SubnetsThe concept of subnets was introduced in order to allow arbitrarycomplexity of interconnected LAN structures within an organization,while insulating the Internet system against explosive growth innetwork numbers and routing complexity. The subnet architecture,described in RFC-950 [21], is intended to specify a standard approachthat does not require reconfiguration for host implementations,regardless of subnetting scheme. The document also specifies a newNTAG [Page 8]RFC 985 May 1986Requirements for Internet Gateways -- DRAFTICMP Address Mask message, which a gateway can use to specify certaindetails of the subnetting scheme to hosts and is required in new hostand gateway implementations.The current subnet specification RFC-950 does not describe thespecific procedures to be used by the gateway, except by implication.It is recommended that a (sub)net address and address mask beprovided for each network interface and that these values beestablished as part of the gateway configuration procedure. It isnot usually necessary to change these values during operation of anyparticular gateway; however, it should be possible to add newgateways and/or (sub)nets and make other configuration changes to agateway without taking the entire network down.4. Local Network InterfaceThe packet format used for transmission of datagrams on the varioussubnetworks is described in a number of documents summarized below.4.1. Public data networks via X.25The formats specified for public data networks via X.25 access aredescribed in RFC-877 [8]. Datagrams are transmitted over standardlevel-3 virtual circuits as complete packet sequences. Virtualcircuits are usually established dynamically as required and timeout after a period of no traffic. Retransmission, resequencingand flow control are performed by the network for each virtualcircuit and by the LAPB link-level protocol. Multiple parallelvirtual circuits are often used in order to improve the utilization of the subscriber access line, which can result inrandom resequencing. The correspondence between Internet andX.121 addresses is usually established by table-lookup. It isexpected that this will be replaced by some sort of directoryprocedure in future.4.2. ARPANET via 1822 Local Host, Distant Host or HDLC Distant HostThe formats specified for ARPANET networks via 1822 access aredescribed in BBN Report 1822 [3], which includes the proceduresfor several subscriber access methods. The Local Host (LH) andVery Distant Host (VDH) methods are not recommended for newimplementations. The Distant Host (DH) method is used when thehost and IMP are separated by not more than about 2000 feet ofcable, while the HDLC Distant Host is used for greater distanceswhere a modem is required. Retransmission, resequencing and flowcontrol are performed by the network and by the HDLC link-levelprotocol, when used. While the ARPANET 1822 protocols are widelyNTAG [Page 9]RFC 985 May 1986Requirements for Internet Gateways -- DRAFTused at present, they are expected to be eventually overtaken bythe DDN Standard X.25 protocol (see below) and the new PSNEnd-to-End Protocol described in RFC-979 [29].While the cited report gives details of the various ARPANETsubscriber access methods, it specifies neither the IP packetencapsulation format nor address mappings. While these aregenerally straightforward and easy to implement, the detailsinvolve considerations beyond the scope of readily accessabledocumentation. Potential vendors are encouraged to contact one ofthe individuals listed at the beginning of this document forfurther information.Gateways connected to ARPANET/MILNET IMPs must incorporatefeatures to avoid host-port blocking (RFNM counting) and to detectand report (as ICMP Unreachable messages) the failure ofdestination hosts or gateways.4.3. ARPANET via DDN Standard X.25The formats specified for ARPANET networks via X.25 are describedin the Defense Data Network X.25 Host Interface Specification [6].This document describes two sets of procedures, the DDN Basic X.25and the DDN Standard X.25, but only the latter is suitable for usein the Internet system. The DDN Standard X.25 procedures aresimilar to the public data subnetwork X.25 procedures, except inthe address mappings. Retransmission, resequencing and flowcontrol are performed by the network and by the LAPB link-levelprotocol.4.4. EthernetsThe formats specified for Ethernet networks are described inRFC-894 [10]. Datagrams are encapsulated as Ethernet packets with48-bit source and destination address fields and a 16-bit typefield. Address translation between Ethernet addresses and Internetaddresses is managed by the Address Resolution Protocol, which isrequired in all Ethernet implementations. There is no explicitretransmission, resequencing or flow control. although mosthardware interfaces will retransmit automatically in case ofcollisions on the cable.It is expected that amendments will be made to this specificationas the result of IEEE 802.3 evolution. See RFC-948 [20] forfurther discussion and recommendations in this area. Note alsothat the IP broadcast address, which has primary application toEthernets and similar technologies that support an inherentNTAG [Page 10]RFC 985 May 1986Requirements for Internet Gateways -- DRAFTbroadcast function, has an all-ones value in the host field of theIP address. Some early implementations chose theall-zeros valuefor this purpose, which is presently not in conformance with thedefinitive specification RFC-950 [21].See Appendix A for further considerations.4.5. Serial-Line ProtocolsGateways may be used as packet switches in order to build networks. In some configurations gateways may be interconnectedwith each other and some hosts by means of serial asynchronous orsynchronous lines, with or without modems. When justified by theexpected error rate and other factors, a link-level protocol maybe required on the serial line. While there is no requirement thata particular standard protocol be used for this, it is recommendedthat standard hardware and protocols be used, unless a convincingreason to the contrary exists. In order to support the greatestvariety of configurations, it is recommended that some variationon full X.25 (i.e. "symmetric mode") be used where resourcespermit; however, X.25 LAPB would also be acceptable whererequirements permit. In the case of asynchronous lines no clearchoice is apparent.5. InteroperabilityIn order to assure interoperability between gateways procured fromdifferent vendors, it is necessary to specify points of protocoldemarcation. With respect to interoperability of the routingfunction, this is specified as EGP. All gateway systems must includeone or more gateways which support EGP with a core gateway, asdescribed in RFC-904 [11]. It is desirable that these gateways beable to operate in a mode that does not require a core gateway orsystem. Additional discussion on these issues can be found inRFC-975 [27].With respect to the interoperability at the network layer and below,two points of protocol demarcation are specified, one for Ethernetsand the other for serial lines. In the case of Ethernets theprotocols are as specified in Section 4.4 and Appendix A of thisdocument. 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 1986Requirements for Internet Gateways -- DRAFT6. Subnetwork ArchitectureIt is recognized that gateways may also function as general packetswitches to build networks of modest size. This requires additionalfunctionality in order to manage network routing, control andconfiguration. While it is beyond the scope of this document tospecify the details of the mechanisms used in any particular, perhapsproprietary, architecture, there are a number of basic requirementswhich must be provided by any acceptable architecture.6.1. Reachability ProceduresThe architecture must provide a robust mechanism to establish theoperational status of each link and node in the network, includingthe gateways, the links connecting them and, where appropriate,the hosts as well. Ordinarily, this requires at least alink-level reachability protocol involving a periodic exchange ofhello messages across each link. This function might be intrinsicto the link-level protocols used (e.g. LAPB, DDCMP). However, itis in general ill-advised to assume a host or gateway is operatingcorrectly if its link-level reachability protocol is operating。