RFC 985

Network Working Group RFC 985 💖

okay bestie, let's start at the top 🎀 This is RFC 985, titled "Requirements for Internet Gateways -- Draft", from May 1986. It was written by the Network Technical Advisory Group at the NSF (National Science Foundation), under the Network Working Group banner. The header doesn't list anything it obsoletes or updates, so it's standing on its own 🧚

---

Status of this Memo ✨

okay so this RFC is a summary of the requirements for gateways that run on networks using the DARPA Internet protocols. It's written for NSF research programs, but the requirements are stated generally, and the authors think they apply across the whole Internet community 🌐

It was made by the Gateway Requirements Subcommittee of the NSF Network Technical Advisory Group, working together with the Internet Activities Board, the Internet Architecture Task Force, and the Internet Engineering Task Force. They're asking for discussion and suggestions for improvements, and distribution of the memo is unlimited 💅

The whole point is to give guidance to vendors whose products might be used or adapted for an Internet application. It lists the protocols that are needed and points to RFCs and other documents that describe the current specs. Some specs are still evolving and can be ambiguous or incomplete, so in those spots the doc adds extra guidance. Policy issues for the NSF scientific networking community get their own Appendix 🔬

🚨 DRAFT ALERT 🚨 This is a DRAFT edition of the gateway requirements statement. Comments are wanted so they can be considered and maybe added to the final edition. People actually building gateways are especially wanted, along with vendors and potential vendors. The comment period is 90 days, ending 15-Aug-86. After that, a revised edition gets issued with a new RFC number 🦋

Suggestions and comments can go to the subcommittee chairman, Dave Mills, at mills@usc-isid.arpa, or to the NTAG committee chairman, Dave Farber, at farber@huey.udel.edu. Here's the subcommittee roster with affiliations and mailboxes:

Hank Dardy, NRL                 dardy@nrl.arpa
Dave Farber, U Delaware         farber@huey.udel.edu
Dennis Jennings, JVNC         jennings%pucc.bitnet@wiscvm.wisc.edu
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 also wants to thank these extra contributors and invited referees, who really helped make this happen 🫶

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

that's part 1 of 7 done 🌸 more parts are coming, so stay tuned, bestie 💜

1. Introduction ✨

okay so this section is the "new here? let me explain" part 🫶 it's for anyone who isn't familiar with the DARPA Internet architecture and the Internet gateway model. if you want the big-picture background on the Internet architecture and supporting protocol suite, check out the DDN Protocol Handbook [25] and the ARPANET Information Brochure [26]. both were available from the Network Information Center, SRI International, Menlo Park, CA 94025 💖 if you already know this stuff, skip straight to Section 2, no judgment 💅

1.1. The DARPA Internet Architecture

the DARPA Internet system is a bunch of gateways and networks working together to carry packets for hosts that use the DARPA Internet protocol architecture 🌐 the protocols in that family are IP (Internet Protocol), ICMP (Internet Control Message Protocol), TCP (Transmission Control Protocol), and the application protocols that depend on them. everything uses IP as the basic packet-transport mechanism 📦 IP is a datagram (connectionless) service, and it includes provisions for service specification, fragmentation/reassembly, and security information 🔐

ICMP counts as an integral part of IP, even though it's architecturally layered on top of it 🧚 it handles error reporting, flow control, and first-hop gateway redirection. reliable data delivery comes from TCP, which gives you end-to-end retransmission, resequencing, and connection control 🎀 and connectionless service is provided by UDP (User Datagram Protocol) 🦋

the community is seriously big now 🤯 it currently includes several thousand hosts connected to over 400 networks, with about 120 gateways. there are well over 2400 hosts registered in the ARPA domain alone, plus an unknown number registered in other domains, and the total is growing at about ten percent each month 📈 a lot of the hosts, gateways, and networks are run by civil organizations like universities, research labs, and equipment manufacturers 🎓 most of the rest are run by the US DoD and count as part of the DDN Internet. that currently has three sets of networks: the experimental segment (ARPANET), the unclassified segment (MILNET), and the classified segment, which doesn't have a collective name yet 🕵️‍♀️

here's the vibe of the Internet model: its constituent networks are called local networks, to tell them apart from the Internet system as a whole 🏘️ they only have to provide datagram (connectionless) transport. that means best-effort delivery of individual packets, aka datagrams 🤷‍♀️ each datagram carries 32-bit source and destination addresses. those addresses come in three formats that give you a two-part address: one part is the local-network number, and the other is the host number on that local net 🗺️

according to the Internet service specification, datagrams can arrive out of order, get lost, get duplicated, and/or contain errors. yikes, right? 😭 in networks that do provide connection-oriented service, virtual circuits add extra reliability that makes the end-to-end robustness of the system better, but it isn't strictly necessary 💜

local networks get connected together through Internet gateways 🌉 these gateways only provide datagram transport, and they normally try to keep the state information they need for this service to a minimum. that's all for the sake of routing flexibility and robustness 🧠 in the conventional model, a gateway has a physical interface and an address on each of the local nets it forwards between 🔌 gateways also take part in one or more distributed routing or reachability algorithms, like the Gateway-Gateway Protocol (GGP) or the Exterior Gateway Protocol (EGP), so they can keep their routing tables up to date 🗂️

1.2. The Internet Gateway Model

an Internet gateway is a self-contained, stand-alone packet switch 🖥️ it does the following:

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 when multiple gateways operate 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 in line with good engineering practice for managing 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 setups, gateways may be connected to packet-switching local nets that handle generic local-net routing, error control, and resource management 🫧 in others, gateways are connected directly over serial lines, so the gateways themselves have to provide those functions 🔧

there are three typical scenarios that gateway vendors should address 👀

1. National or regional network. Gateways in this class should be able to switch multiple continuous flows in the 1.5-Mbps range, at rates up to several thousand packets per second 🚀 they'll be high-performance, possibly redundant, multiple-processor devices. they'll probably be bought as a system and run remotely from a regional or national monitoring center. the design should put the emphasis on high aggregate throughput, throughput-sensitive 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 in this class should be able to switch some burst flows at 10-Mbps (Ethernets, etc.), along with some flows in the 64-Kbps range or lower, at rates up to perhaps several thousand packets per second 🏫 they'll be medium-performance devices, probably competitively procured from different vendors for each campus, and run from a campus computing center. the design should emphasize low average delay and good burst performance, plus delay- and type-of-service-sensitive resource management ⏱️ their chief function might be interconnecting various LANs and campus computing resources, including a high-speed link to a national or regional net. a very flexible routing mechanism matters a lot here, since these gateways may have to pick among several backbone nets based on cost and performance 💅
3. Department network. Gateways in this class should be able to switch a small number of burst flows at 10-Mbps (Ethernets, etc.), along with a small number of flows in the 64-Kbps range or lower, at rates of a few hundred packets per second 🌸 they'll be medium-performance devices from a variety of vendors, used for protocol matching, LAN repeating, and as general-purpose utility packet switches. they'll probably be maintained locally by the various users, and they won't typically be used as transit switches 🧸

okay, real talk: Internet gateways normally run unattended 🤖 but equipment and software faults can affect the entire Internet, which is kind of terrifying 😳 some of the scenarios above involve positive control of certain gateways from a monitoring center, usually over a path that goes through other networks and Internet gateways. others might involve much less formal control procedures. so gateways have to be highly robust, and they're expected to keep operating, possibly in a degraded state, through extreme congestion or failure of network resources 🛡️✨

2. Protocols Required ✨

Okay so the Internet architecture uses datagram gateways to link up networks and subnetworks 🌐. These gateways act as intermediate systems (IS) with respect to the ISO connectionless network model, and they bring along 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 of the Internet system 💖. It's described in RFC-791 [1] and also MIL-STD-1777 [5], which are both meant to describe the same standard, just in quite different words 📚.

With respect to current gateway requirements, the following can be ignored: Type of Service field, Security option, Stream ID option and Timestamp option 🙈. They MAY be REQUIRED in future, though! 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 a destination address other than the gateway itself 🧚. However, for protocols where 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 it's 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 for certain ICMP messages, including the ICMP Destination Unreachable and ICMP Redirect messages. The ICMP Destination Unreachable message is sent by a gateway in response to a datagram that can't 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 the host uses 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 it's 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, such as hop count 🔢. However, using EGP 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 to 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 ensure 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. 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 for 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 it's described in RFC-826 [4] 🧩. However, there are a number of unresolved issues having to do with subnets and with responses 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 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 ICMP Address Mask message, which a gateway can use to specify certain details of the subnetting scheme to hosts, and it 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 🌸

okay so this whole section is about the packet formats for sending datagrams over the different subnetworks. bestie, there are a bunch of them and they're all lowkey different 💅

4.1. Public data networks via X.25

the formats for public data networks over X.25 access are described in RFC-877 [8] ✨ datagrams get sent over standard level-3 virtual circuits as complete packet sequences. the circuits usually get set up dynamically when they're needed and they time out after a stretch of no traffic ⏳ the network handles retransmission, resequencing, and flow control for each virtual circuit, and the LAPB link-level protocol does too. using multiple parallel virtual circuits is super common because it helps you use the subscriber access line better, but it can cause random resequencing 🙈 the mapping between Internet and X.121 addresses is usually done with a table lookup, and it's expected that some kind of directory procedure will replace that in the future 🔮

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

the formats for ARPANET networks over 1822 access are in BBN Report 1822 [3], which covers the procedures for several subscriber access methods 📚 the Local Host (LH) and Very Distant Host (VDH) methods are not recommended for new implementations, so skip those 🚫 the Distant Host (DH) method is for when the host and the IMP are separated by no more than about 2000 feet of cable, and the HDLC Distant Host is for longer distances where a modem is required 🔌 retransmission, resequencing, and flow control are handled by the network and by the HDLC link-level protocol when it's used. the ARPANET 1822 protocols are super popular right now, but they're expected to eventually get overtaken by the DDN Standard X.25 protocol (see below) and the new PSN End-to-End Protocol described in RFC-979 [29] 🦋

ngl, the cited report explains the different ARPANET subscriber access methods, but it does not specify the IP packet encapsulation format or the address mappings. those are generally straightforward and easy to implement, but the details go beyond what's readily accessible documentation 😭 potential vendors are encouraged to contact one of the individuals listed at the beginning of this document for more info 🫶

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. this one's a big deal, so don't skip it! 💀

4.3. ARPANET via DDN Standard X.25

the formats for ARPANET networks over X.25 are described in the Defense Data Network X.25 Host Interface Specification [6] 🎀 that document describes two sets of procedures, the DDN Basic X.25 and the DDN Standard X.25, but only the Standard one is suitable for use in the Internet system ✨ the DDN Standard X.25 procedures are basically the same as the public data subnetwork X.25 procedures, except for the address mappings 💖 retransmission, resequencing, and flow control are handled by the network and by the LAPB link-level protocol.

4.4. Ethernets

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

it's expected that amendments will be made to this specification as IEEE 802.3 evolves 🌈 see RFC-948 [20] for more discussion and recommendations in this area. also, the IP broadcast address, which mainly matters for Ethernets and similar technologies that have an inherent broadcast function, has an all-ones value in the host field of the IP address 💜 some early implementations used the all-zeros value for this, which is 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 to build networks 🍓 in some setups, gateways get connected to each other and to some hosts over serial asynchronous or synchronous lines, with or without modems. when the expected error rate and other factors justify it, a link-level protocol may be required on the serial line 🔗 there's no requirement that a particular standard protocol be used for this, but it is recommended that standard hardware and protocols be used, unless there's a convincing reason not to 🙌

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 🌟 X.25 LAPB would also be acceptable where requirements permit 👑 for asynchronous lines, though, no clear choice is apparent 🤷‍♀️

5. Interoperability 🎀

so, to make sure gateways from different vendors work together, we need to specify the points where the protocols get split up 🧩 for the interoperability of the routing function, that's specified as EGP. all gateway systems must include one or more gateways that support EGP with a core gateway, as described in RFC-904 [11] 🦋 it's desirable that these gateways can operate in a mode that doesn't require a core gateway or system. more discussion on this stuff is in RFC-975 [27] 📚

for interoperability at the network layer and below, there are two points of protocol demarcation: one for Ethernets and one for serial lines 🌈 for 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 💅✨

6. Subnetwork Architecture ✨

Okay so gateways can also act as general packet switches to build smaller networks 🧚. That means they need extra machinery to handle routing, control, and configuration. It's out of scope for this doc to spell out the details of any particular architecture (maybe a proprietary one, who knows 🙈), but there are some basic requirements that ANY acceptable architecture MUST provide.

6.1. Reachability Procedures

The architecture MUST provide a robust mechanism to figure out the operational status of every link and node: the gateways, the links connecting them, and the hosts too where it makes sense 🫶. Usually this takes at least a link-level reachability protocol that sends periodic hello messages across each link. That function might be built right into the link-level protocols themselves (like LAPB or DDCMP). But it's generally ill-advised to assume a host or gateway is fine just because its link-level reachability protocol is fine 😭. You need extra confirmation, in the form of a working routing algorithm or a peer-level reachability protocol like the one EGP uses. Additional confirmation is REQUIRED in that form.

Failure and restoration of a link and/or gateway count as network events, and they MUST be reported to the control center. It's desirable, although not REQUIRED, that the reporting paths don't need the routing algorithm itself to be working correctly 💅.

6.2. Routing Algorithm

The Internet community has repeatedly found that the routing mechanism, whether static or dynamic, is the single most important engineering issue in network design 👑. Except for trivial topologies, some degree of routing dynamics is vital to making things work, whether it's handled manually, automatically, or a mix of both. In particular, if routing changes are made manually, they MUST be possible without taking the gateways down for reconfiguration, and preferably they should be possible from a remote site like a control center.

It's not likely that every net can be maintained from a full-service control center, so automatic-fallback or rerouting features may be required. This MUST be considered the normal case, so systems of gateways working as the only packet switches in a network would normally be expected to have a routing algorithm that can react to link and other gateway failures and change routes automatically. Here's the 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 NOT form routing loops between neighbor gateways, and it 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 needed to run the routing algorithm MUST NOT significantly degrade or disrupt normal network operation. Changes in state that might momentarily disrupt normal operation in a local area MUST NOT cause disruption in remote areas of the network 🦋.
4. As the network grows, demand on resources MUST be controlled efficiently 📈. Table lookups SHOULD be hashed, for example, and database updates should be 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 on network-specific broadcast mechanisms. Polling procedures (e.g. for consistency checking) SHOULD be used only sparingly, and in no case should they introduce an overhead exceeding a constant independent of network topology times the longest non-looping path.
5. Using a default gateway to shrink the routing database is strongly discouraged, given all the problems with multiple paths, loops, and misconfiguration vulnerabilities 🙅. If it's used at all, it SHOULD be limited to a discovery function, with operational routes cached from external or internal databases via either the routing algorithm or EGP.
6. This document places no restriction on the type of routing algorithm (node-based, link-based, or any other) or on the metric (delay, hop-count, or anything else) 🌈. However, the size of the routing database MUST NOT be allowed to exceed a constant independent of network topology times the number of nodes times the mean connectivity (average number of incident links). An advanced design wouldn't need the entire routing database kept in any particular gateway, so discovery and caching techniques would be necessary 🧠.

7. Operation and Maintenance 🎀

Gateways and packet switches are often run as a system by some organization that agrees to operate and maintain the gateways, and to sort out link problems with the common carriers. The network control site may not be physically attached to the network it monitors, which is a whole thing 🙈. In general, these requirements apply:

1. Each gateway MUST operate as a stand-alone device for local hardware maintenance. Means MUST be available to run diagnostic programs at the gateway site using only on-site tools, which might be just a diskette or tape and a local terminal. It's desirable, although not REQUIRED, to run diagnostics over the network and to automatically reboot and dump the gateway over the net in case of a fault. In general this needs special hardware 🔧.

Using full-blown transport services like TCP is generally ill-advised if they're only needed to reboot and dump the gateway. Consideration SHOULD be given to simple retransmission-overlay protocols based on UDP, or to 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 the software doesn't reset it periodically 🐣. It's desirable that the data involved reside at the control site and get transmitted via the net, but using local devices at the gateway site is acceptable. Nevertheless, the operation of initiating a 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 way to retrieve this data is an explicit, periodic request from the control site using a standard datagram protocol based on UDP or HMP.

Using full-blown transport services like TCP is generally ill-advised if they're only needed to collect statistics from the gateway. Consideration SHOULD be given to simple retransmission-overlay protocols based on UDP or HMP 💅.

4. Exception reports ("traps") caused by hardware or software malfunctions SHOULD be transmitted immediately to the control site (batched to cut down on packet overheads when possible) using a standard datagram protocol based on UDP or HMP 🚨.
5. A mechanism MUST be provided to display link and node status continuously at the control site ✨. While it's desirable that a complete map of all links and nodes be available, it's acceptable for only the components the routing algorithm is using to be displayed. This info is usually available locally at the control site, assuming that site participates in the routing algorithm.

The above functions in general require a control site or agent to take part. The preferred way to do this is a user program that runs in a standard software environment like Unix 💻. The program would use standard IP protocols like TCP, UDP, and HMP to control and monitor the gateways. Using specialized host hardware and software that needs a big additional investment is strongly discouraged 🙅‍♀️. Even so, some vendors may choose to provide the control agent as an integrated part of the network the gateways belong to. If that's the case, it is REQUIRED that there be a means to operate the control agent from a remote site, using Internet protocols and paths, with functionality equivalent to a local agent terminal 🫶.

Remote control of a gateway over Internet paths can work in one of two ways. In the direct approach, the gateway supports TCP and/or UDP itself. In the indirect approach, the control agent supports these protocols and controls the gateway using proprietary protocols. The former is preferred, although either approach is acceptable 💜.

8. References and Bibliography 📚✨

Okay bestie, here's the receipts 🧾 all the RFCs and standards this whole spec is built on. Let's go 💅

• [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.
• [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.
• [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.

---

Appendix A. Ethernet Management 🌸

Okay so this appendix is basically the Ethernet cheat sheet 🧁 It's a summary of the procedures that hosts and gateways on an Ethernet are supposed to follow. Let's gooo 🫶

A.1. Hardware 🔌

A packet only gets accepted from the cable if its destination Ethernet address matches either the assigned interface address or a broadcast/multicast address. 💅 Presumably the interface hardware does this filtering, but if the hardware doesn't, the software driver is expected to step in. Some hosts have an optional feature that ties an assigned multicast address to a specific subnet so access can be restricted for testing and stuff. When that feature is switched on, the assigned multicast address takes the place of the broadcast address. 🎀

A.2. IP datagram 📦

For broadcast/multicast traffic (going by the destination Ethernet address), an IP datagram gets tossed if its source IP address isn't on the same subnet, based on the assigned host IP address and subnet mask. 🙈 It's desirable to be able to override this check with a configuration parameter, because sometimes more than one subnet can coexist on the same cable, and that's rare but real. 🌈

A.3. ARP datagram 🧚

An ARP reply gets discarded if its destination IP address doesn't match the local host address. An ARP request gets discarded if its source IP address isn't on the same subnet. 💜 It's desirable to be able to override this check with a configuration parameter too, for the infrequent cases where more than one subnet may coexist on the same cable (see RFC-925 for examples). An ARP reply is only generated if the destination protocol IP address is reachable from the local host (as determined by the routing algorithm) and the next hop isn't via the same interface. Also, if the local host acts as a gateway, this might lead to ARP replies for destinations that aren't on the same subnet. 👑

A.4. ICMP redirect 🦋

An ICMP redirect gets discarded if its destination IP address doesn't match the local host address, or if the new target address isn't on the same subnet. ✨ An accepted redirect updates the routing data base for the old target address. If there's no route or association with the old target address, the redirect gets ignored. If the old route is tied to a default gateway, a new route tied to the new target address gets inserted into 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's some ambiguity about the scope of a redirect, unless all the hosts and gateways involved already know the subnet masks. 🙃 It's recommended that ICMP network-redirect messages be avoided in favor of ICMP host-redirect messages instead. This requires the original sender (aka the redirect recipient) to support a general IP address-translation cache, rather than the usual network table. Honestly though, that's normally done anyway in the case of ARP. 🍓

An ICMP redirect is only generated if the destination IP address is reachable from the local host (as determined by the routing algorithm), 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 isn't checked, since the sending gateway may use one of its addresses that isn't on the common net. And the source IP address of the encapsulated IP datagram isn't checked either, on the assumption that the host or gateway sending the original IP datagram knows what it's doing. 🫶💅

Appendix B. Policy Issues 🌈

okay so this bit is all about the policy stuff the NSF scientific networking crew was seriously thinking about 🧠 it's mostly policy vibes, but these choices literally ripple into the technical side too, so pay attention bestie 👀

B.1. Interconnection Technology 🔌

ngl, the most important shared interconnection tech between Internet systems from different vendors right now is Ethernet 💖 and it's not hard to see why:

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 they're only getting more common. 🙌

All three of these together make Ethernet the go-to point of demarcation between NSF network systems from different vendors, no matter what technology is running underneath 🫧 So it's a requirement of NSF gateways that, even if the vendor's switching tech is proprietary, the gateways must support an Ethernet attachment to gateways from other vendors. Non-negotiable, bestie 💅

It's expected that future NSF gateway requirements will call out other interconnection technologies too. The most likely candidates are ones based on X.25 or IEEE 802, but broadband cable, fiber-optic, or other protocols like DDCMP may also get considered 🦋

B.2. Proprietary and Extensible Issues 🧩

Internet tech is a growing, adaptable thing, and it's giving evolving 🌱 Hosts, gateways, and networks running it have been in continuous operation for several years, but vendors, users, and operators should understand that not every networking issue is fully understood yet. So when new needs or better solutions pop up for the NSF networking community, it may be necessary to field new protocols 🚀 Usually those new protocols are designed to interoperate in all practical respects with existing ones, but every once in a while existing systems might have to be upgraded to support them 🙈

NSF systems vendors need to know they're also signing up to keep an eye on current Internet tech and be ready to upgrade their products from time to time, as appropriate 💼 That's why these vendors are strongly urged to treat extensibility and periodic upgrades as fundamental characteristics of their products. Main character product energy 👑 One of the most productive and rewarding ways to do this long-term is to take part in ongoing Internet research and development programs in partnership with the academic community 🎓

B.3. Multi-Protocol Gateways 🌐

okay so the current NSF gateway requirements only specify the Internet protocol suite, but it's highly desirable that gateway designs leave room for future extensions to support additional suites, and let them run at the same time as more than one suite. The ISO protocol suite is a clear prime candidate for one of those, and XNS and DECnet are other candidates 🍓

Future NSF gateway requirements might include provisions for other protocol suites alongside Internet, plus models and specifications for interworking between them, if that makes sense down the line 🧚 For example, it's expected that the ISO suite will eventually become the dominant one; however, requirements to support other suites are also expected to keep going, possibly indefinitely 💜

Present NSF gateway requirements don't include protocols above the network layer, such as TCP, unless they're needed for network monitoring or control. Vendors should recognize that future requirements to interwork between Internet and ISO applications, for example, might create an opportunity to market gateways that support multiple protocols at all levels, right up through the application level 💰 It's expected that the network-level NSF gateway requirements summarized in this document will be folded into the requirements document for those application-level gateways 📝

B.4. Access Control and Accounting 🔐

Right now there are no requirements for NSF gateways to build in specific access-control and accounting mechanisms 🙅 But these important issues are under study and will be folded into a redraft of this document at an early date, so vendors are encouraged to plan for early introduction of these mechanisms in their products ⏰ No definitive common model has emerged yet, but it's possible to outline some general features such a model is likely to have, like these:

1. The primary access control and accounting executive mechanisms will live in the service hosts themselves, not in 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. They may be used to collect data, enforce password protection, or mitigate resource priority and fairness. However, the architecture and protocols these agents use may be a local matter, and might not be 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 these mechanisms would involve a user-level login to the gateway itself 🙈