RFC 1009

Requirements for Internet Gateways 🎀

Okay bestie, this is RFC 1009 💖 It's called Requirements for Internet Gateways, written by R. Braden and J. Postel at ISI, dated June 1987 📅 It obsoletes RFC 985 🫶 Also, the Status section calls it an official specification for the Internet community, so this is the real deal 💅

---

Status of this Memo ✨

Okay so this doc is a formal statement of the requirements gateways have to meet in the Internet system 📜 That makes it an official spec for the whole Internet community, and distribution of this memo is unlimited 🦋

This RFC sums up the requirements for gateways used between networks that support the Internet protocols 🌈 It was written specifically to support National Science Foundation research programs, but the requirements are stated in a general context, so they apply throughout the Internet community 💜

The whole point is to give guidance to vendors making gateway products that might be used or adapted for an Internet application 🎀 It lists the protocols required and points to RFCs and other docs that describe the current specs 📚 Honest tea: a bunch of specs are still evolving and may be ambiguous or incomplete, so in those cases the doc includes extra discussion with specific guidance 🫶 Specific policy issues for the NSF scientific networking community are summarized in an Appendix 🍓 As other specs get updated, this doc will be revised too 🔁 Vendors are encouraged to keep in touch with the Internet research community 🌸

---

1. Introduction ✨

This section is an intro and background for anyone who isn't familiar with the Internet architecture and the Internet gateway model 🧚 General background on the architecture and supporting protocol suite can be found in the DDN Protocol Handbook [25] and the ARPANET Information Brochure [26], and see also [19, 28, 30, 31] 📖

The Internet protocol architecture was originally developed under DARPA sponsorship to meet both military and civilian communication requirements [32] 💻 Today the Internet system supports a variety of government and government-sponsored operational and research activities. In particular, the National Science Foundation (NSF) is building a major extension to the Internet to give users access to national supercomputer centers and other national scientific resources, and to give a computer networking capability to a large number of universities and colleges 🎓

Lots of terms in here might be obscure if you're new to the Internet protocols 😭 There's not much to do about that except learn, so dive in 🏊 A few terms get abused in general discussion but are used very carefully and on purpose in this doc, so they're defined right here 💅

• Packet: a packet is the unit of transmission on a physical network 📦
• Datagram: a datagram is the unit of transmission in the IP protocol. To cross a particular network, a datagram gets encapsulated inside a packet 🎁
• Router: a router is a switch that receives data transmission units from input interfaces and, depending on the addresses in those units, routes them to the right output interfaces. Routers can exist at different levels of protocol. For example, Interface Message Processors (IMPs) are packet-level routers 🛤️
• Gateway: in Internet docs generally, and in this doc specifically, a gateway is an IP-level router. The Internet community has a long history of using the term this way [32] 👑

1.1. The DARPA Internet Architecture 🌸

1.1.1. Internet Protocols 🦋

The Internet system is a bunch of interconnected packet networks that let host computers communicate using the Internet protocols 💖 These include the Internet Protocol (IP), the Internet Control Message Protocol (ICMP), the Transmission Control Protocol (TCP), and the application protocols that depend on them [22] 🫶

All Internet protocols use IP as the basic data transport mechanism 🚚 IP [1,31] is a datagram, or connectionless, internetwork service, and it includes provision for addressing, type-of-service specification, fragmentation and reassembly, and security information ✨ ICMP [2] is considered an integral part of IP, even though it's architecturally layered on top of IP 🧩 ICMP provides error reporting, flow control and first-hop gateway redirection 🚦

Reliable data delivery is provided in the Internet protocol suite by transport-level protocols like TCP, which provides end-to-end retransmission, resequencing and connection control 🔁 Transport-level connectionless service is provided by the User Datagram Protocol (UDP) 💜

1.1.2. Networks and Gateways 🌐

The constituent networks of the Internet system are only required to provide packet (connectionless) transport, which means they just need to deliver individual packets 📬 According to the IP service spec, datagrams can be delivered out of order, be lost or duplicated, and/or contain errors 🙈 Reasonable performance for protocols that use IP (e.g., TCP) requires an IP datagram loss rate of less than 5% 📉 In networks providing connection-oriented service, the extra reliability from virtual circuits makes the end-end robustness of the system better, but it's not necessary for Internet operation 🌷

Constituent networks can generally be divided into two classes:

• Local-Area Networks (LANs): LANs may have a variety of designs, typically based on bus, ring, or star topologies. In general, a LAN covers a small geographical area (e.g., a single building or plant site) and provides high bandwidth with low delays 🏢
• Wide-Area Networks (WANs): geographically dispersed hosts and LANs are interconnected by wide-area networks, also called long-haul networks. These may have a complex internal structure of lines and packet-routers (typified by ARPANET), or they may be as simple as point-to-point lines 🗺️

In the Internet model, constituent networks are connected together by IP datagram forwarders called "gateways" or "IP routers" 🔗 In this doc, every use of the term "gateway" is equivalent to "IP router" 🎀 In current practice, gateways are normally built with packet-switching software running on a general-purpose CPU, but special-purpose hardware may also be used (and may be required for future higher-throughput gateways) 🔥

A gateway is connected to two or more networks and appears to each of them as a connected host 🧚 So it has a physical interface and an IP address on each of the connected networks 🪪 Forwarding an IP datagram generally requires the gateway to choose the address of the next-hop gateway or, for the final hop, the destination host 🎯 This choice, called "routing", depends on a routing data-base inside the gateway 🗃️ That data-base should be maintained dynamically to reflect the current topology of the Internet system, and a gateway normally does this by joining distributed routing and reachability algorithms with other gateways 🤝 Gateways only provide datagram transport, and they try to minimize the state information needed to keep this service going, for the sake of routing flexibility and robustness 🦋

Routing devices may also operate at the network level. In this memo, we call these devices MAC routers (informally "level-2 routers", and also called "bridges") 🌉 The name comes from the fact that MAC routers base their routing decisions on the addresses in the MAC headers. For example, in IEEE 802.3 networks, a MAC router bases its decision on the 48-bit addresses in the MAC header 🔢 Network segments connected by MAC routers share the same IP network number, meaning they logically form a single IP network 🧵

Another variation sometimes happens: a set of gateways may be interconnected with only serial lines, effectively forming a network where routing is done at the internetwork (IP) level instead of the network level 🪢

1.1.3. Autonomous Systems 🏛️

For technical, managerial, and sometimes political reasons, the gateways of the Internet system are grouped into collections called "autonomous systems" [35] 👑 The gateways in a single autonomous system (AS) are expected to:

• Be under the control of a single operations and maintenance (O&M) organization;
• Employ common routing protocols among themselves, to maintain their routing data-bases dynamically.

A number of different dynamic routing protocols have been developed (see Section 4.1). The particular choice of routing protocol within a single AS is generically called an interior gateway protocol, or IGP 🧭

An IP datagram may have to traverse the gateways of two or more ASs to reach its destination, and the ASs must provide each other with topology information to allow that forwarding 🗺️ The Exterior Gateway Protocol (EGP) is used for this purpose, between gateways of different autonomous systems 🤝

1.1.4. Addresses and Subnets 🏠

An IP datagram carries 32-bit source and destination addresses. Each of these is partitioned into two parts: a constituent network number and a host number on that network. Symbolically:

IP-address ::=  { <Network-number>,  <Host-number> }

To finally deliver the datagram, the last gateway in its path must map the host-number (or "rest") part of an IP address into the physical address of a host connection to the constituent network 📬

This simple notion has been extended by the concept of "subnets" 🌿 Subnets were 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 🌱 Essentially, subnets provide a two-level hierarchical routing structure for the Internet system. The subnet extension, described in RFC-950 [21], is now a required part of the Internet architecture 💅 The basic idea is to partition the <host number> field into two parts: a subnet number, and a true host number on that subnet 🧩

IP-address ::=
        { <Network-number>, <Subnet-number>, <Host-number> }

Okay so, when an organization has a bunch of LANs hooked up together, they all share the same network number, but each LAN gets its own subnet number 🧚 The subnets inside that network are supposed to stay invisible to everyone else, bestie 🤫 The wide-area routing across the rest of the Internet only looks at the <Network-number> part of the IP destination address. Gateways outside the network just lump <Subnet-number> and <Host-number> together into one uninterpreted "rest" part of the 32-bit IP address 💅 Meanwhile, the local gateways inside have to route on an extended network number, which looks like this:

{ <Network-number>, <Subnet-number> }

The bit positions holding that extended network number are marked by a 32-bit mask called the "subnet mask" [21] 🎀 It is recommended but not required that the <Subnet-number> bits be contiguous and fall between the <Network-number> and <Host-number> fields. And no subnet should be assigned the value zero or -1 (all one bits) 🙅‍♀️

Flexible use of address space is going to be super important as the Internet keeps growing 📈 So we allow a particular subnetted network to use more than one subnet mask. Campuses with very large LAN setups are already building nested hierarchies of subnets, sub-subnets, etc. It's giving Russian nesting doll energy 🪆

There are special considerations for the gateway when a connected network provides a broadcast or multicast capability. We'll get into those later 👀

1.2. The Internet Gateway Model

There are two basic models for connecting local-area networks to wide-area (or long-haul) networks in the Internet. In the first model, the local-area network gets its own network number, and every gateway in the Internet has to know how to route to that network 🗺️ In the second model, the local-area network shares (a small part of) the address space of the wide-area network. Gateways that support this second model are called "address sharing gateways" or "transparent gateways" 🦋 This memo is mostly focused on gateways that do the first model, but that's not meant to rule out transparent gateways, bestie.

1.2.1. Internet Gateways

An Internet gateway is an IP-level router that does the following functions:

1. Conforms to specific Internet protocols specified in this document, including the Internet Protocol (IP), Internet Control Message Protocol (ICMP), and others as necessary. See Section 2 (Protocols Required) 📜
2. Interfaces to two or more packet networks. For each connected network, the gateway must implement the functions that network requires. These functions typically include: a. encapsulating and decapsulating the IP datagrams with the connected network framing (e.g., an Ethernet header and checksum); b. sending and receiving IP datagrams up to the maximum size supported by that network. This size is the network's "Maximum Transmission Unit" or "MTU"; c. translating the IP destination address into an appropriate network-level address for the connected network (e.g., an Ethernet hardware address); d. responding to the network flow control and error indication, if any.

See Section 3 (Constituent Network Interface) for details on particular constituent network interfaces. 🔌

3. Receives and forwards Internet datagrams. Important issues are buffer management, congestion control, and fairness. See Section 4 (Gateway Algorithms) 🚦 a. Recognizes various error conditions and generates ICMP error and information messages as required. b. Drops datagrams whose time-to-live fields have reached zero. c. Fragments datagrams when necessary to fit into the MTU of the next network.
4. Chooses a next-hop destination for each IP datagram, based on the information in its routing data-base. See Section 4 (Gateway Algorithms) 🧭
5. Supports an interior gateway protocol (IGP) to carry out distributed routing and reachability algorithms with the other gateways in the same autonomous system. In addition, some gateways will need to support the Exterior Gateway Protocol (EGP) to exchange topological information with other autonomous systems. See Section 4 (Gateway Algorithms) 🗣️
6. Provides system support facilities, including loading, debugging, status reporting, exception reporting and control. See Section 5 (Operation and Maintenance) 🛠️

1.2.2. Embedded Gateways

A gateway can be a stand-alone computer system, dedicated to its IP router functions. Or, it's possible to embed gateway functionality within a host operating system that supports connections to two or more networks. The best-known example of an operating system with embedded gateway code is the Berkeley BSD system 🐡 The embedded gateway feature seems to make internetting super easy, but it has a number of hidden pitfalls:

1. If a host has only a single constituent-network interface, it should not act as a gateway.

For example, hosts with embedded gateway code that gratuitously forward broadcast packets or datagrams on the same net often cause packet avalanches. 🌊💀

2. If a (multihomed) host acts as a gateway, it must implement ALL the relevant gateway requirements contained in this document.

For example, the routing protocol issues (see Sections 2.6 and 4.1) and the control and monitoring problems are as hard and as important for embedded gateways as they are for stand-alone gateways 😭

Since Internet gateway requirements and specifications may change independently of operating system changes, an administration that operates an embedded gateway in the Internet is strongly advised to have an ability to maintain and update the gateway code (e.g., this might require gateway code source). 🔄

3. Once a host runs embedded gateway code, it becomes part of the Internet system. Thus, errors in software or configuration of such a host can hinder communication between other hosts. As a consequence, the host administrator must lose some autonomy. 🥺

In many circumstances, a host administrator will need to disable gateway code embedded in the operating system, and any embedded gateway code must be organized so it can be easily disabled. 🔒

4. If a host running embedded gateway code is concurrently used for other services, the O&M (operation and maintenance) requirements for the two modes of use may be in serious conflict.

For example, gateway O&M will in many cases be performed remotely by an operations center. This may require privileged system access, which the host administrator would not normally want to distribute. 🙈

1.2.3. Transparent Gateways

The basic idea of a transparent gateway is that the hosts on the local-area network behind such a gateway share the address space of the wide-area network in front of the gateway. In certain situations this is a very useful approach, and the limitations don't present significant drawbacks 🍓

The words "in front" and "behind" point to one of the limitations of this approach: this model of interconnection is suitable only for a geographically (and topologically) limited stub environment. It requires that there be some form of logical addressing in the network-level addressing of the wide-area network. That means all the IP addresses in the local environment map to a few (usually one) physical address in the wide-area network, in a way consistent with the { IP address <-> network address } mapping used throughout the wide-area network 🧩

Multihoming is possible on one wide-area network, but it may present routing problems if the interfaces are geographically or topologically separated. Multihoming on two (or more) wide-area networks is a problem because of the confusion of addresses 😵‍💫

The behavior that hosts see from other hosts in what is apparently the same network may differ if the transparent gateway cannot fully emulate the normal wide-area network service. For example, if there were a transparent gateway between the ARPANET and an Ethernet, a remote host would not receive a Destination Dead message [3] if it sent a datagram to an Ethernet host that was powered off. Not it, not receiving the message 💀

1.3. Gateway Characteristics

Every Internet gateway must perform the functions listed above. However, a vendor will have lots of choices on power, complexity, and features for a particular gateway product. It's helpful to notice that the Internet system is neither homogeneous nor fully-connected. For reasons of technology and geography, it's growing into a global-interconnect system plus a "fringe" of LANs around the "edge" 🌍✨

• The global-interconnect system is made up of a number of wide-area networks that have gateways from several ASs attached to them. There are relatively few hosts connected directly to it. The global-interconnect system includes the ARPANET, the NSFNET "backbone", the various NSF regional and consortium networks, other ARPA-sponsored networks such as the SATNET and the WBNET, and the DCA-sponsored MILNET 🏛️ It's anticipated that additional networks sponsored by these and other agencies (such as NASA and DOE) will join the global-interconnect system 🚀
• Most hosts are connected to LANs, and many organizations have clusters of LANs interconnected by local gateways. Each such cluster is connected by gateways at one or more points into the global-interconnect system. If it's connected at only one point, a LAN is known as a "stub" network 🌸

Gateways in the global-interconnect system generally require:

• Advanced routing and forwarding algorithms

These gateways need routing algorithms that are highly dynamic and also offer type-of-service routing. Congestion is still not a completely resolved issue [24]. Improvements to the current situation will be implemented soon, as the research community is actively working on these issues 🧠💖

• High availability

Okay so these gateways need to be super reliable 💅, running 24 hours a day, 7 days a week, no days off. If something breaks they MUST recover quickly, bestie 😭

Advanced O&M features 🛠️ These gateways will typically be run remotely from a regional or national monitoring center. In their interconnect role they'll need sophisticated ways to monitor and measure traffic and other events, and to diagnose faults. It's giving control room energy 🎀

High performance 🚀 Long-haul lines on the Internet today are mostly 56 Kbps, but DS1 lines (1.5 Mbps) are becoming super important, and even faster speeds are likely coming. Full-duplex operation is provided at any of these speeds ✨

The average Internet datagram is pretty small, on the order of 100 bytes. At DS1 speeds, the per-datagram processing power of the gateway, not the line speed, is likely to be the bottleneck 🙈 To fill a DS1 line with average-sized datagrams, a gateway would need to pass (receive, route, and send) 2,000 datagrams per second per interface. So a gateway with 3 DS1 lines and an Ethernet interface would need to handle a dazzling 2,000 datagrams per second in each direction on each interface, or an aggregate throughput of 8,000 datagrams per second, to fully use those DS1 lines. That is beyond what current gateways can do 💀

📝 Note: some vendors count input and output operations separately in their datagrams per second figures. For those vendors, the example above would imply 16,000 datagrams per second !

Gateways out on the "LAN fringe" (think campus networks) usually have to meet less strict requirements for performance, availability, and maintenance 🌸 They may be high or medium-performance devices, probably bought competitively from several different vendors and run by an internal organization (like a campus computing center). The design of these gateways SHOULD put the emphasis on low average delay and good burst performance, plus delay- and type-of-service-sensitive resource management. In this environment there's less formal O&M, more hand-crafted static configurations for special cases, and more need to work with gateways from other vendors. The routing mechanism will need to be very flexible, but it doesn't need to be as highly dynamic as in the global-interconnect system 🧚

It's important to realize that Internet gateways normally operate in an unattended mode, but equipment and software faults can have a wide-spread (sometimes global) effect 😬 In any environment, a gateway MUST be highly robust and able to operate, possibly in a degraded state, under conditions of extreme congestion or failure of network resources.

Even though the Internet system isn't fully interconnected, many parts of it do need redundant connectivity 🫶 Rich connectivity allows reliable service despite failures of communication lines and gateways, and it can also improve service by shortening Internet paths and providing extra capacity. The engineering tradeoff between cost and reliability MUST be made for each component of the Internet system 👑

---

2. Protocols Required in Gateways 🦋

The Internet architecture uses datagram gateways to interconnect constituent networks. This section walks through the various protocols a gateway needs to implement 💖

2.1. Internet Protocol (IP) 🌈

IP is the basic datagram protocol used in the Internet system [19, 31]. It's described in RFC-791 [1] and also in MIL-STD-1777 [5] as clarified by RFC-963 [36] ([1] and [5] are meant to describe the same standard, but in pretty different words 🙃). The subnet extension is described in RFC-950 [21].

With respect to current gateway requirements, the following IP features can be ignored, although they may be required in the future: Type of Service field, Security option, and Stream ID option. However, if a gateway recognizes them, the interpretation of these quantities MUST conform to the standard specification.

It's important for gateways to implement both the Loose and Strict Source Route options. The Record Route and Timestamp options are useful diagnostic tools and MUST be supported in all gateways 🔥

The Internet model requires that a gateway be able to fragment datagrams as necessary to match the MTU of the network they're being forwarded to, but reassembly of fragmented datagrams is generally left to the destination hosts. Therefore, a gateway will not perform reassembly on datagrams it forwards 🍓

However, a gateway will generally receive some IP datagrams addressed to itself. For example, these may be ICMP Request/Reply messages, routing update messages (see Sections 2.3 and 2.6), or datagrams for monitoring and control (see Section 5). For these datagrams the gateway is functioning as a destination host, so it MUST implement IP reassembly in case the datagrams were fragmented by some transit gateway. The destination gateway MUST have a reassembly buffer that is at least as large as the maximum of the MTU values for its network interfaces and 576. Note also that a particular protocol implemented by a host or gateway might require a lower bound on reassembly buffer size that's larger than 576. Finally, a datagram addressed to a gateway MAY use any of that gateway's IP addresses as its destination address, regardless of which interface the datagram enters 💜

There are five classes of IP addresses: Class A through Class E [23]. Of these, Class D and Class E addresses are reserved for experimental use. A gateway that isn't participating in these experiments MUST ignore all datagrams with a Class D or Class E destination IP address. ICMP Destination Unreachable or ICMP Redirect messages MUST NOT result from receiving such datagrams 🚫

There are certain special cases for IP addresses, defined in the latest Assigned Numbers document [23]. These special cases can be concisely summarized using the earlier notation for an IP address:

         IP-address ::=  { <Network-number>, <Host-number> }

            or

         IP-address ::=  { <Network-number>, <Subnet-number>,
                                                         <Host-number> }

This works if we also use the notation "-1" to mean the field contains all 1 bits. Some common special cases are as follows 🧩

• (a) {0, 0}: This host on this network. Can only be used as a source address (see note later).
• (b) {0, <Host-number>}: Specified host on this network. Can only be used as a source address.
• (c) { -1, -1}: Limited broadcast. Can only be used as a destination address, and a datagram with this address MUST never be forwarded outside the (sub-)net of the source.
• (d) {<Network-number>, -1}: Directed broadcast to specified network. Can only be used as a destination address.
• (e) {<Network-number>, <Subnet-number>, -1}: Directed broadcast to specified subnet. Can only be used as a destination address.
• (f) {<Network-number>, -1, -1}: Directed broadcast to all subnets of a specified subnetted network. Can only be used as a destination address.
• (g) {127, <any>}: Internal host loopback address. SHOULD never appear outside a host.

The following two are conventional notation for network numbers, and don't really represent IP addresses. They can never be used in an IP datagram header as an IP source or destination address 🙈

• (h) {<Network-number>, 0}: Specified network (no host).
• (i) {<Network-number>, <Subnet-number>, 0}: Specified subnet (no host).

Note also that the IP broadcast address, which has primary application to Ethernets and similar technologies that support an inherent 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 not in conformance with the specification [23, 49, 50] 💅

2.2. Internet Control Message Protocol (ICMP) 🎀

ICMP is an auxiliary protocol used to convey advice and error messages, and it's described in RFC-792 [2].

We'll discuss the issues that come up when a gateway handles particular ICMP messages. The ICMP messages are grouped into two classes: error messages and information messages. ICMP error messages are never sent about ICMP error messages, nor about broadcast or multicast datagrams 🙅‍♀️

The ICMP error messages are: Destination Unreachable, Redirect, Source Quench, Time Exceeded, and Parameter Problem.

The ICMP information messages are: Echo, Information, Timestamp, and Address Mask.

2.2.1. Destination Unreachable 💌

The distinction between subnets of a subnetted network, which depends on the address mask described in RFC-950 [21], MUST NOT be visible outside that network. This distinction matters a lot for the ICMP Destination Unreachable message 🫣

The ICMP Destination Unreachable message is sent by a gateway in response to a datagram it can't forward because the destination is unreachable or down. The gateway chooses one of the following two types of Destination Unreachable messages to send:

• Net Unreachable
• Host Unreachable

Net Unreachable implies that an intermediate gateway couldn't forward a datagram, because its routing database gave no next hop for it, or because all paths were down. Host Unreachable implies that the destination network was reachable, but a gateway on that network couldn't reach the destination host. This might happen if the destination network was able to determine that the desired host was unreachable or down. It might also happen when the destination host was on a subnetted network and no path was available through that network's subnets to the destination. Gateways SHOULD send Host Unreachable messages whenever other hosts on the same destination network might be reachable. Otherwise, the source host may erroneously conclude that ALL hosts on the network are unreachable, and that may not be the case 😱

2.2.2. Redirect 🦋

The ICMP Redirect message is sent by a gateway to a host on the same network, in order to change the gateway that the host uses for routing certain datagrams. There's a choice of four types of Redirect messages, so you can specify datagrams destined for a particular host or network, and possibly with a particular type-of-service 🌟

If the directly-connected network is not subnetted, a gateway can normally send a network Redirect that applies to all hosts on a specified remote network 🦋. Using a network Redirect instead of a host one MAY economize slightly on network traffic and host routing table storage, bestie 🧚. But the saving is not significant, and subnets make things ambiguous about which subnet mask to use when interpreting a network Redirect 💀. In a general subnet environment, it's honestly so hard to pin down exactly when network Redirects can be used 😭.

So, it is RECOMMENDED that a gateway send only host (or host and type-of-service) Redirects. 🎀

2.2.3. Source Quench ✨

All gateways MUST contain code for sending ICMP Source Quench messages when they are forced to drop IP datagrams due to congestion 🚨. Okay so Source Quench is kinda an imperfect way to do Internet congestion control, and people are still working on more effective options 🔬. Even so, it's considered way too valuable to leave out of production gateways 👑.

There is some argument that the Source Quench SHOULD be sent before the gateway is forced to drop datagrams [62] 🤔. For example, a parameter X could be established and set to have Source Quench sent when only X buffers remain. Or, a parameter Y could be established and set to have Source Quench sent when only Y per cent of the buffers remain.

Two problems for a gateway sending Source Quench are: (1) the consumption of bandwidth on the reverse path, and (2) the use of gateway CPU time 😩. To ameliorate these problems, a gateway MUST be prepared to limit the frequency with which it sends Source Quench messages. This MAY be on the basis of a count (e.g., only send a Source Quench for every N dropped datagrams overall or per given source host), or on the basis of a time (e.g., send a Source Quench to a given source host or overall at most once per T milliseconds). The parameters (e.g., N or T) MUST be settable as part of the configuration of the gateway. Furthermore, there SHOULD be some configuration setting which disables sending Source Quenches. These configuration parameters, including disabling, SHOULD ideally be specifiable separately for each network interface.

Note that a gateway itself MAY receive a Source Quench as the result of sending a datagram targeted to another gateway. Such datagrams might be an EGP update, for example.

2.2.4. Time Exceeded ⏳

The ICMP Time Exceeded message MAY be sent when a gateway discards a datagram due to the TTL being reduced to zero. It MAY also be sent by a gateway if the fragments of a datagram addressed to the gateway itself cannot be reassembled before the time limit.

2.2.5. Parameter Problem 🧩

The ICMP Parameter Problem message MAY be sent to the source host for any problem not specifically covered by another ICMP message.

2.2.6. Address Mask 🎭

Host and gateway implementations are expected to support the ICMP Address Mask messages described in RFC-950 [21].

2.2.7. Timestamp ⏰

The ICMP Timestamp message has proven to be useful for diagnosing Internet problems 🔍. The preferred form for a timestamp value, the "standard value", is in milliseconds since midnight GMT. However, it MAY be difficult to provide this value with millisecond resolution. For example, many systems use clocks which update only at line frequency, 50 or 60 times per second. Therefore, some latitude is allowed in a "standard" value:

• The value MUST be updated at a frequency of at least 30 times per second (i.e., at most five low-order bits of the value MAY be undefined).
• The origin of the value MUST be within a few minutes of midnight, i.e., the accuracy with which operators customarily set CPU clocks.

To meet the second condition for a stand-alone gateway, it will be necessary to query some time server host when the gateway is booted or restarted. It is RECOMMENDED that the UDP Time Server Protocol [44] be used for this purpose. A more advanced implementation would use NTP (Network Time Protocol) [45] to achieve nearly millisecond clock synchronization. However, this is not REQUIRED.

Even if a gateway is unable to establish its time origin, it ought to provide a "non-standard" timestamp value (i.e., with the non-standard bit set), as a time in milliseconds from system startup.

New gateways, especially those expecting to operate at T1 or higher speeds, are expected to have at least millisecond clocks.

2.2.8. Information Request/Reply 📡

The Information Request/Reply pair was intended to support self-configuring systems such as diskless workstations, to allow them to discover their IP network numbers at boot time. However, the Reverse ARP (RARP) protocol [15] provides a better mechanism for a host to use to discover its own IP address, and RARP is RECOMMENDED for this purpose. Information Request/Reply need not be implemented in a gateway.

2.2.9. Echo Request/Reply 🪞

A gateway MUST implement ICMP Echo, since it has proven to be an extremely useful diagnostic tool 💖. A gateway MUST be prepared to receive, reassemble, and echo an ICMP Echo Request datagram at least as large as the maximum of 576 and the MTU's of all of the connected networks. See the discussion of IP reassembly in gateways, Section 2.1.

The following rules resolve the question of the use of IP source routes in Echo Request and Reply datagrams. Suppose a gateway D receives an ICMP Echo Request addressed to itself from host S.

1. If the Echo Request contained no source route, D SHOULD send an Echo Reply back to S using its normal routing rules. As a result, the Echo Reply MAY take a different path than the Request; however, in any case, the pair will sample the complete round-trip path which any other higher-level protocol (e.g., TCP) would use for its data and ACK segments between S and D.
2. If the Echo Request did contain a source route, D SHOULD send an Echo Reply back to S using as a source route the return route built up in the source-routing option of the Echo Request.

2.3. Exterior Gateway Protocol (EGP) 🌐

EGP is the protocol used to exchange reachability information between Autonomous Systems of gateways, and is defined in RFC-904 [11]. See also RFC-827 [51], RFC-888 [46], and RFC-975 [27] for background information. The most widely used EGP implementation is described in RFC-911 [13].

When a dynamic routing algorithm is operated in the gateways of an Autonomous System (AS), the routing data-base MUST be coupled to the EGP implementation. This coupling SHOULD ensure that, when a net is determined to be unreachable by the routing algorithm, the net will not be declared reachable to other ASs via EGP. This requirement is designed to minimize spurious traffic to "black holes" and to ensure fair utilization of the resources on other systems.

The present EGP specification defines a model with serious limitations, most importantly a restriction against propagating "third party" EGP information in order to prevent long-lived routing loops [27]. This effectively limits EGP to a two-level hierarchy. The top level is formed by the "core" AS, while the lower level is composed of those ASs which are direct neighbor gateways to the core AS. In practice, in the current Internet, nearly all of the "core gateways" are connected to the ARPANET, while the lower level is composed of those ASs which are directly gatewayed to the ARPANET or MILNET.

RFC-975 [27] suggested one way to generalize EGP to lessen these topology restrictions. It has not been adopted as an official specification, although its ideas are finding their way into the new EGP developments. There are efforts underway in the research community to develop an EGP generalization which will remove these restrictions.

In EGP, there is no standard interpretation (i.e., metric) for the distance fields in the update messages, so distances are comparable only among gateways of the same AS. In using EGP data, a gateway SHOULD compare the distances among gateways of the same AS and prefer a route to that gateway which has the smallest distance value.

The values to be announced in the distance fields for particular networks within the local AS SHOULD be a gateway configuration parameter. By suitable choice of these values, it will be possible to arrange primary and backup paths from other AS's. There are other EGP parameters, such as polling intervals, which also need to be set in the gateway configuration.

When routing updates become large, they MUST be transmitted in parts. One strategy is to use IP fragmentation, another is to explicitly send the routing information in sections. The Internet Engineering Task Force is currently preparing a recommendation on this and other EGP engineering issues.

2.4. Address Resolution Protocol (ARP) 🔍

ARP is an auxiliary protocol used to perform dynamic address translation between LAN hardware addresses and Internet addresses, and is described in RFC-826 [4].

ARP depends upon local network broadcast. In normal ARP usage, the initiating host broadcasts an ARP Request carrying a target IP address. The corresponding target host, recognizing its own IP address, sends back an ARP Reply containing its own hardware interface address.

A variation on this procedure, called "proxy ARP", has been used by gateways attached to broadcast LANs [14]. The gateway sends an ARP Reply specifying its interface address in response to an ARP Request for a target IP address which is not on the directly-connected network but for which the gateway offers an appropriate route. By observing ARP and proxy ARP traffic, a gateway MAY accumulate a routing data-base [14].

Proxy ARP (also known in some quarters as "promiscuous ARP" or "the ARP hack") is useful for routing datagrams from hosts which do not implement the standard Internet routing rules fully -- for example, host implementations which predate the introduction of subnetting. Proxy ARP for subnetting is discussed in detail in RFC-925 [14].

Reverse ARP (RARP) allows a host to map an Ethernet interface address into an IP address [15]. RARP is intended to allow a self-configuring host to learn its own IP address from a server at boot time.

2.5. Constituent Network Access Protocols 🧩

See Section 3.

2.6. Interior Gateway Protocols 🌳

Distributed routing algorithms are still a hot research topic 🔬, and it's likely we'll get some big glow-ups over the next few years 💅. A good algorithm has to respond rapidly to real changes in Internet connectivity, but also stay stable and not freak out over every little transient 🫶. It also needs to synchronize the distributed data-base across the gateways of its Autonomous System quickly (to avoid routing loops 🙈), while only eating a small fraction of the available bandwidth 🦋.

Distributed routing algorithms are commonly broken down into the following three components 🧩:

• A. An algorithm to assign a "length" to each Internet path.
  • The "length" may be a simple count of hops (1, or infinity if the path is broken), or an administratively-assigned cost, or some dynamically-measured cost (usually an average delay).
  • To determine a path length, each gateway must at least test whether each of its neighbors is reachable. For this purpose, there must be a "reachability" or "neighbor up/down" protocol. 🔌
• B. An algorithm to compute the shortest path(s) to a given destination. 🗺️
• C. A gateway-gateway protocol used to exchange path length and routing information among gateways. 🤝

The most commonly-used IGPs in Internet gateways are as follows 👑.

2.6.1. Gateway-to-Gateway Protocol (GGP) 🌸

GGP was designed and implemented by BBN for the first experimental Internet gateways [41]. It's still in use in the BBN LSI/11 gateways, but it's regarded as having serious drawbacks [58] 😬. GGP is based upon an algorithm used in the early ARPANET IMPs, and it was later replaced by SPF (see below).

GGP is a "min-hop" algorithm, which means its length measure is simply the number of network hops between gateway pairs 🦋. It implements a distributed shortest-path algorithm, which requires global convergence of the routing tables after a change in topology or connectivity. Each gateway sends a GGP routing update only to its neighbors, but each update includes an entry for every known network, where each entry contains the hop count from the gateway sending the update 📬.

2.6.2. Shortest-Path-First (SPF) Protocols 🧠

SPF [40] is the name for a class of routing algorithms based on a shortest-path algorithm of Dijkstra. The current ARPANET routing algorithm is SPF, and the BBN Butterfly gateways also use SPF. Its characteristics are considered superior to GGP [58] ✨.

Under SPF, the routing data-base is replicated rather than distributed 🪞. Each gateway has its own copy of the same data-base, containing the entire Internet topology and the lengths of every path. Since each gateway has all the routing data and runs a shortest-path algorithm locally, there's no problem of global convergence of a distributed algorithm, like there is in GGP 💅. To build this replicated data-base, a gateway sends SPF routing updates to ALL other gateways. These updates only list the distances to each of the gateway's neighbors, which makes them much smaller than GGP updates 🥹. The algorithm used to distribute SPF routing updates involves reliable flooding 🌊.

2.6.3. Routing Information (RIP) 🛣️

RIP is the name often used for a class of routing protocols based upon the Xerox PUP and XNS routing protocols. These are relatively simple, and they're widely available because they're incorporated in the embedded gateway code of Berkeley BSD systems. Because of this simplicity, RIP protocols have come the closest of any to being an "Open IGP", i.e., a protocol which can be used between different vendors' gateways 🌈. Unfortunately, there is no standard, and in fact not even a good document, for RIP 😭.

As in GGP, gateways using RIP periodically broadcast their routing data-base to their neighbor gateways, and they use a hop-count as the metric 📡.

A fixed value of the hop-count (normally 16) is defined to be "infinity", i.e., network unreachable 🚫. A RIP implementation must include measures to avoid both the slow-convergence phenomen called "counting to infinity" and the formation of routing loops. One such measure is a "hold-down" rule. This rule establishes a period of time (typically 60 seconds) during which a gateway will ignore new routing information about a given network, once the gateway has learned that the network is unreachable (has hop-count "infinity") ⏳. The hold-down period must be settable in the gateway configuration. If gateways with different hold-down periods are using RIP in the same Autonomous System, routing loops are a distinct possibility 💀. In general, the hold-down period is chosen large enough to allow time for unreachable status to propagate to all gateways in the AS 🧚.

2.6.4. Hello 👋

The "Fuzzball" software for an LSI/11 developed by Dave Mills incorporated an IGP called the "Hello" protocol [39]. This IGP is mentioned here because the Fuzzballs have been widely used in Internet experimentation, and because they've served as a testbed for many new routing ideas 🧪.

2.7. Monitoring Protocols 📊

See Section 5 of this document.

2.8. Internet Group Management Protocol (IGMP) 👯

An extension to the IP protocol has been defined to provide Internet-wide multicasting, i.e., delivery of copies of the same IP datagram to a set of Internet hosts [47, 48]. This delivery is to be performed by processes known as "multicasting agents", which reside either in a host on each net or (preferably) in the gateways 📮.

The set of hosts to which a datagram is delivered is called a "host group", and there is a host-agent protocol called IGMP, which a host uses to join, leave, or create a group. Each host group is distinguished by a Class D IP address 🏷️.

This multicasting mechanism and its IGMP protocol are currently experimental, so implementation in vendor gateways would be premature at this time 🧪. A datagram containing a Class D IP address must be dropped, with no ICMP error message 🙅‍♀️.

3. Constituent Network Interface ✨

okay bestie, this section is the rulebook for how IP datagrams get shipped over the most common kinds of constituent networks 📦. the big vibe: a gateway MUST be able to send and receive IP datagrams of any size up to the MTU of any constituent network it's hooked up to. no exceptions, no cap 💅

3.1. Public data networks via X.25 💌

so the formats for public data networks reached through X.25 are spelled out in RFC-877 [8] 📖. datagrams get sent over standard level-3 virtual circuits as complete packet sequences 🧵. virtual circuits are usually set up dynamically as required and time out after a stretch of no traffic 💤. the network handles link-level retransmission, resequencing and flow control for each virtual circuit, and the LAPB link-level protocol does too 🫶. a single X.25 virtual circuit MAY be used to multiplex all IP traffic between a pair of hosts. but multiple parallel virtual circuits MAY also be used to make better use of the subscriber access line, even though X.25 window sizes are small 🪟. the catch is that this can result in random resequencing 🙈

the mapping between Internet and X.121 addresses is usually done with a table lookup 🗂️. the plan is to swap that for some kind of directory procedure later on ✨. the table of hosts on the Public Data Network lives in the Assigned Numbers [23] 📚.

the normal MTU is 576 🎀. the two DTE's (hosts or gateways) can use X.25 packet size negotiation to bump that up [8] 🚀.

3.2. ARPANET via 1822 LH, DH, or HDH 🛰️

the formats for ARPANET networks using 1822 access are in BBN Report 1822 [3], which covers several subscriber access methods 💁. the Distant Host (DH) method is for when the host and IMP (the Defense Communication Agency calls it a Packet Switch Node or PSN) are separated by not more than about 2000 feet of cable 📏. HDLC Distant Host (HDH) is for longer distances where a modem is needed 📞. under HDH, the network and the HDLC link-level protocol handle retransmission, resequencing and flow control 🔁.

the IP encapsulation is super simple: the IP datagram just rides along as the data portion of an 1822 message 🎁. on top of that, the high-order 8 bits of the Message Id field (also known as the "link" field") SHOULD be set to 155 [23]. the MTU is 1007 octets 📐.

1822 protocols are widely used right now, but they're expected to eventually be overtaken by the DDN Standard X.25 protocol (see Section 3.3) 👀. the original IP address mapping (RFC-796 [38]) is getting replaced by a new interface specification called AHIP-E, and you can check out the proposal in RFC-1005 [61] 🔄.

Gateways connected to ARPANET or MILNET IMPs using 1822 access MUST incorporate features to avoid host-port blocking (i.e., RFNM counting). they also MUST detect and report the failure of destination hosts or gateways as ICMP Unreachable messages (i.e., convert the 1822 error messages to the appropriate ICMP messages) 🚨.

when you're building a network interface, it'll be super useful to review the IMP end-to-end protocol in RFC-979 [29] 📝.

3.3. ARPANET via DDN Standard X.25 📡

the formats for ARPANET networks via X.25 are in the Defense Data Network X.25 Host Interface Specification [6]. it describes two sets of procedures: DDN Basic X.25 and DDN Standard X.25. only DDN Standard X.25 gives you the functionality needed for the interoperability assumptions of the Internet protocol 🤓.

DDN Standard X.25 procedures are basically the same as the public data network X.25 ones, except for the address mappings 💕. retransmission, resequencing and flow control are handled by the network and the LAPB link-level protocol. multiple parallel virtual circuits MAY be used to improve the utilization of the subscriber access line, and this can result in random resequencing 🌀.

Gateways connected to ARPANET or MILNET using Standard X.25 access MUST detect and report the failure of destination hosts or gateways as ICMP Unreachable messages (i.e., convert the X.25 diagnostic codes to the appropriate ICMP messages) 🧯.

to stay compatible with 1822 interfaces, the effective MTU for a Standard X.25 interface is 1007 octets 🫶.

3.4. Ethernet and IEEE 802 🧷

the formats for Ethernet networks are in RFC-894 [10] 🖥️. datagrams are encapsulated as Ethernet packets with 48-bit source and destination address fields and a 16-bit type field (the type field values are listed in the Assigned Numbers [23]). address translation between Ethernet addresses and Internet addresses is managed by the Address Resolution Protocol, which is REQUIRED in all Ethernet implementations 🤝. there's no explicit link-level retransmission, resequencing or flow control, although most hardware interfaces will retransmit automatically when there are collisions on the cable 💥.

IEEE 802 networks use a Link Service Access Point (LSAP) field in pretty much the same way ARPANET uses the "link" field. there's also an extension of the LSAP header called the Sub-Network Access Protocol (SNAP) 🧩.

the 802.2 encapsulation is used on 802.3, 802.4, and 802.5 network by using the SNAP with an organization code that indicates the following 16 bits specify the Ether-Type code [23] 🎀.

   Headers:

      ...--------+--------+--------+
       MAC Header|      Length     |                  802.{3/4/5} MAC
      ...--------+--------+--------+

      +--------+--------+--------+
      | DSAP=K1| SSAP=K1| control|                          802.2 SAP
      +--------+--------+--------+

      +--------+--------+--------+--------+--------+
      |protocol id or org code=K2|    Ether-Type   |       802.2 SNAP
      +--------+--------+--------+--------+--------+

the total length of the SAP Header and the SNAP header is 8-octets, so the 802.2 protocol overhead comes out on a 64-bit boundary 🍓.

K1 is 170. the IEEE likes to talk about things in bit transmission order and specifies this value as 01010101. in big-endian order, which is what the Internet specifications use, this becomes 10101010 binary, or AA hex, or 170 decimal 🔢. K2 is 0 (zero) 🫧.

the use of the IP LSAP (K1 = 6) is reserved for future development 🔮.

the assigned values for the Ether-Type field are the same whether you're using this IEEE 802 encapsulation or the basic Ethernet encapsulation [10] 👯.

in either Ethernets or IEEE 802 nets, the IP datagram is the data portion of the packet, right after the Ether-Type 🎁.

the MTU for an Ethernet or its IEEE-standard equivalent (802.3) is 1500 octets 📏.

3.5. Serial-Line Protocols 🔌

in some configurations, gateways MAY be interconnected with each other through 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 single Internet standard for this protocol, but it's suggested that one of the following protocols be used 💜.

• X.25 LAPB (Synchronous Lines): this is the link-level protocol used for X.25 network access. it includes HDLC "bit-stuffing" as well as rotating-window flow control and reliable delivery.

A gateway MUST be configurable to play the role of either the DCE or the DTE. 🎭

• HDLC Framing (Synchronous Lines): this is just the bit-stuffing and framing rules of LAPB. it's the simplest choice, although it provides no flow control or reliable delivery; however, it does provide error detection 🧼.
• Xerox Synchronous Point-to-Point (Synchronous Lines): this Xerox protocol is an elaboration upon HDLC framing that includes negotiation of maximum packet sizes, dial-up or dedicated circuits, and half- or full-duplex operation [12] 🤩.
• Serial Line Framing Protocol (Asynchronous Lines): this protocol is included in the MIT PC/IP package for an IBM PC and is defined in Appendix I to the manual for that system [20] 💾.

it's super important to make efficient use of the bandwidth on a serial line between gateways 🏃‍♀️. for example, it's desirable to provide some form of data compression. one possible standard compression algorithm, "Thinwire II", is described in RFC-914 [42]. this and similar algorithms are tuned to the particular types of redundancy that occur in IP and TCP headers. however, more work is necessary to define a standard serial-line compression protocol for Internet gateways. until a standard is adopted, each vendor is free to choose a compression algorithm. of course, the result will only be useful on a serial line between two gateways using the same compression algorithm 😅.

another way to get maximum bandwidth use is to avoid unnecessary retransmissions at the link level. for some kinds of IP traffic, low delay matters more than reliable delivery. the serial line driver could tell those datagrams apart by their IP TOS field and put them on a special high-priority, no-retransmission queue 🏎️.

a serial point-to-point line between two gateways MAY be considered to be a (particularly simple) network, a "null net" 🫧. viewed that way, a serial line needs no special considerations in the routing algorithms of the connected gateways, but it does need an IP network number. to avoid the wholesale consumption of Internet routing data-base space by null nets, we strongly recommend that subnetting be used for null net numbering whenever possible 🙌.

   For example, assume that network 128.203 is to be constructed of gateways joined by null nets; these nets are given (sub-)net numbers 128.203.1, 128.203.2, etc., and the two interfaces on each end of null net 128.203.s might have IP addresses 128.203.s.1 and 128.203.s.2.

an alternative model is to treat a serial line not as a network, but as an internal communication path joining two "half gateways". it's possible to design an IGP and routing algorithm that treats a serial line this way [39, 52] 🧠.

4. Gateway Algorithms ✨

gateways are general packet-switches that forward packets according to the IP address, i.e., they are IP routers 🛣️. it's beyond the scope of this document to spell out the details of the mechanisms used in any particular, perhaps proprietary, gateway architecture 🙈. still, there are a number of basic algorithms which MUST be provided by any acceptable design 👑.

4.1. Routing Algorithm 🗺️

okay so the routing mechanism is literally fundamental to how the Internet works 💖 In all but the most trivial network topologies, robust Internet service needs some degree of routing dynamics ✨ Whether that's done by hand, automatically, or a mix of both, it's giving reliability. And if routing changes are made manually, it MUST be possible to make them from a remote Network Operation Center (NOC) without taking down the gateway for reconfiguration 🫶 If static routes are used, there MUST be automatic fallback or rerouting features 🔥

Handling unpredictable changes in Internet connectivity MUST be considered the normal case 💅 So systems of gateways will normally be expected to have a routing algorithm that can react to link and other gateway failures and change routing automatically. Main character energy 👑

This document places no restriction on the type of routing algorithm (node-based, link-based, or anything else) or on the routing distance metric (delay or hop-count, whatever you like) 🦋 However, these features are considered necessary for a successful gateway routing algorithm, so pay attention bestie:

1. The algorithm MUST sense the failure or restoration of a link or other gateway and switch to appropriate paths. A design objective is to switch paths within an interval less than the typical TCP user time-out (one minute is a safe assumption) ⏱️
2. The algorithm MUST suppress routing loops between neighbor gateways and MUST contain provisions to avoid or suppress routing loops that may form between non-neighbor gateways. A design objective is for no loop to persist for longer than an interval greater than the typical TCP user time-out 🌀
3. The control traffic needed to operate 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 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 incremental changes broadcast over a wide-area 🍓
5. The size of the routing data-base 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 might not require that the entire routing data-base be kept in any particular gateway, so discovery and caching techniques would be necessary 💜
6. Reachability and delay metrics, if used, MUST NOT depend on direct connectivity to all other gateways or on the use of network-specific broadcast mechanisms. Polling procedures (e.g., for consistency checking) MUST be used only sparingly, and in no case introduce an overhead exceeding a constant, independent of network topology, times the longest non-looping path 🙈
7. Default routes (generally intended as a means to reduce the size of the routing data-base) MUST be used with care, because of the many problems with multiple paths, loops, and mis-configurations which routing defaults have caused. 😭

The most common application of defaults is for routing within an Internet region that's connected in a strictly hierarchical fashion and is a stub from the rest of the Internet system. In this case, the default is used for routing "up" the tree. Unfortunately, such restricted topology seldom lasts very long, and defaults cease to work 💀

More generally, defaults could be used for initial routing guesses, with final routes discovered and cached from external or internal data-bases via the routing algorithm or EGP 🌸

4.2. Subnets and Routing 🦋

We will call a gateway "subnetted" if at least one of its interfaces is connected to a subnet. The set of gateways directly connected to subnets of the same network is a "subnet cluster" ✨ For example, in the following diagram, network 2 is subnetted, with subnets 2.1 and 2.2, but network 1 is not. Gateways 1, 2, and 3 are subnetted and are members of the same subnet cluster 💖

     (Net 1) === [Gwy 1] === (Net 2.1) === [Gwy 2] === (Net 2.2)
        |                                                   |
        |                                                   |
         =================== [Gwy 3] =======================

Subnets have the following effects on gateway routing 🎀

• A. Non-subnetted gateways are not affected at all. Chill 🌈
• B. The routing data-base in a subnetted gateway MUST consider the address mask for subnet entries. 🧮
• C. Routing updates among the gateways in the same subnet cluster MUST include entries for the various subnets. The corresponding address mask(s) MAY be implicit, but for full generality the mask needs to be given explicitly for each entry. Note that if the routing data-base included a full 32-bit mask for every IP network, the gateway could deal with networks and subnets in a natural way. This would also handle the case of multiple subnet masks for the same subnetted network 🫶
• D. Routing updates from a subnetted gateway to a gateway outside the cluster can contain nets, never subnets. 🌷
• E. If a subnetted gateway (e.g., gateway 2 above) is unable to forward a datagram from one subnet to another subnet of the same network, then it MUST return a Host Unreachable, not a Net Unreachable, as discussed in Section 2.2.1. Be precise, bestie 🔥

When picking a routing protocol, a gateway builder MUST consider how that protocol generalizes for subnets. For some routing protocols it will be possible to use the same procedures in a regular gateway and a subnetted gateway, with only a change of parameters (e.g., address masks) 🧚‍♀️

A different subnet address mask MUST be configurable for each interface of a given gateway. This lets a subnetted gateway connect to two different subnetted networks, or connect two subnets of the same network with different masks. Iconic behavior 👑

4.3 Resource Allocation 💅

In order to perform its basic datagram-forwarding functions, a gateway MUST allocate resources. Its packet buffers and CPU time MUST be allocated to packets it receives from connected networks, while the bandwidth to each of the networks MUST also be allocated for sending packets. The choice of allocation strategies is critical when a particular resource is scarce 😤

The most obvious strategy, first-come-first-served (FCFS), may not be appropriate under overload conditions, and here's why we're gonna explore it ✨

A first example is buffer allocation. It is important for a gateway to allocate buffers fairly among all of its connected networks, even if those networks have widely varying bandwidths 🍓 A high-speed interface MUST NOT be allowed to starve slower interfaces of buffers. For example, consider a gateway with a 10 Mbps Ethernet connection and two 56 Kbps serial lines. A buggy host on the Ethernet may spray that gateway interface with packets at high speed. Without careful algorithm design in the gateway, this could tie up all the gateway buffers so that transit traffic between the serial lines is completely stopped 💀

Allocation of output bandwidth may also require non-FCFS strategies. In an advanced gateway design, allocation of output bandwidth may depend upon Type-of-Service bits in the IP headers. A gateway MAY also want to give priority to datagrams for its own up/down and routing protocols 🌸

Finally, Nagle [24] has suggested that gateways implement "fair queueing", i.e., sharing output bandwidth equitably among the current traffic sources. In his scheme, for each network interface there would be a dynamically-built set of output queues, one per IP source address. These queues would be serviced in a round-robin fashion to share the bandwidth. If subsequent research shows fair queueing to be desirable, it will be added to a future version of this document as a universal requirement 🎀

4.4. Special Addresses and Filters 🙈

Section 2.1 contained a list of the 32-bit IP addresses which have special meanings. They do not in general represent unique IP addresses of Internet hosts, and there are restrictions on their use in IP headers 🧠

We can split these special cases into two classes. The first class (specifically, cases (a), (b), (c), (g), (h), and (i) in section 2.1) contains addresses which SHOULD never appear in the destination address field of any IP datagram, so a gateway SHOULD never be asked to route to one of these addresses. However, in the real world of imperfect implementations and configuration errors, such bad destination addresses do occur 😭 It is the responsibility of a gateway to avoid propagating such erroneous addresses. This is especially important for gateways included in the global interconnect system. In particular, a gateway which receives a datagram with one of these forbidden addresses SHOULD:

1. Avoid inserting that address into its routing database, and avoid including it in routing updates to any other gateway.
2. Avoid forwarding a datagram containing that address as a destination.

To enforce these restrictions, it is suggested that a gateway include a configurable filter for datagrams and routing updates. A typical filter entry might consist of a 32-bit mask and value pair. If the logical AND of the given address with the mask equals the value, a match has been found. Since filtering consumes gateway resources, it is vital that the gateway configuration be able to control the degree of filtering in use 🔥

There is a second class of special case addresses (cases (d), (e), and (f) in section 2.1), the so-called "directed broadcasts". A directed broadcast is a datagram to be forwarded normally to the specified destination (sub-)net and then broadcast on the final hop. An Internet gateway is permitted, but not required, to filter out directed broadcasts destined for any of its locally-connected networks. Hence, it SHOULD be possible to configure the filter to block the delivery of directed broadcasts 🌈

Finally, it will also be useful for Internet O&M to have a configurable filter on the IP source address. This lets a network manager temporarily block traffic from a particular misbehaving host, for example 🧚

4.5. Redirects 🌈

The ICMP Redirect message is only specified for a gateway to update the routing table of a host on the same connected net 🎀 But the Redirect message gets used between gateways too, and here's why it makes sense 👀

• The routing function in a host is lowkey very much like a "dumb gateway" (aka a gateway that only has static routes) 🧸 It is desirable to let a dumb gateway's routing tables get changed under the control of a dynamic gateway (a gateway with full dynamic routing) on the same network. By analogy, it's natural for the dynamic gateway to send ICMP Redirect messages to the dumb gateway ✨

Using ICMP Redirect between gateways like this can count as part of the IGP (honestly the whole IGP, as far as the dumb gateway is concerned!) inside that particular Autonomous System 💁‍♀️ Specifying an IGP is outside the scope of this document, so we're just noting that Redirect could be used this way. Gateways are not REQUIRED to receive and act upon redirects, and dynamic gateways MUST ignore them 🚫 We also note that considerable experience shows dumb gateways often create problems that end up as "black holes" 🕳️ so a full routing gateway is always preferable 👑

Routing table entries established by redirect messages MUST be removed automatically, either by a time-out or when a use count goes to zero 🗑️

---

4.6. Broadcast and Multicast 📣

A host connected to a network (usually a LAN) with an intrinsic broadcast capability may want to use that capability to send IP datagrams to multiple destinations at once 📢 The basic Internet model assumes point-to-point messages, so we must take some care when we bring broadcasting in. It's important to know that broadcast addresses can show up at two protocol levels: the local network header and the IP header 🧐

Mishandling broadcasts has often caused packet avalanches (sometimes called "meltdown") on LANs 🌋 These avalanches are usually caused by gratuitous datagram-forwarding by hosts, or by hosts sending ICMP error messages when they discard broadcast datagrams 😬

Gateways have a responsibility to stop avalanches, or datagrams that can trigger avalanches, from escaping into another network 🚧

In general, a gateway MUST NOT forward a datagram that arrives via local network broadcast, and MUST NOT send an ICMP error message when dropping the datagram 🙅‍♀️ The rules are discussed in Appendix A; see also [50].

As noted in Section 4.4, a gateway is permitted to filter out directed broadcasts. So directed broadcasts will only be useful in limited Internet regions (e.g., within the subnets of a particular campus) where delivery is supported by the gateway administrators 🏫 Host group multicasting (see Sections 2.8 and 4.6) will soon provide a much more efficient mechanism than directed broadcasting 🚀 Gateway algorithms for host group multicasting will be specified in future RFC's 💜

4.7. 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 messages across each link. This function might be intrinsic to the link-level protocols used (e.g., LAPB). However, it is in general ill-advised to assume a host or gateway is operating correctly even 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's desirable, although not REQUIRED, that reporting paths not depend on the correct functioning of the routing algorithm itself 🫶

4.8. Time-To-Live ⏳

The Time-to-Live (TTL) field of the IP header is defined to be a timer limiting the lifetime of a datagram in the Internet. It is an 8-bit field and the units are seconds. This would imply that for a maximum TTL of 255, a datagram would time-out after about 4 and a quarter minutes. Another aspect of the definition requires each gateway (or other module) that handles a datagram to decrement the TTL by at least one, even if the elapsed time was much less than a second. Since this is very often the case, the TTL effectively becomes a hop count limit on how far a datagram can propagate through the Internet 🦋

As the Internet grows, the number of hops needed to get from one edge to the opposite edge increases, i.e., the Internet diameter grows 📈

If a gateway holds a datagram for more than one second, it MUST decrement the TTL by one for each second ⏱️

If the TTL is reduced to zero, the datagram MUST be discarded, and the gateway MAY send an ICMP Time Exceeded message to the source. A datagram SHOULD never be received with a TTL of zero 💀

When it originates a datagram, a gateway is acting in the role of a host and MUST supply a realistic initial value for the TTL 🎀

---

5. Operation and Maintenance 🛠️

5.1. Introduction 🌷

Facilities to support operation and maintenance (O&M) activities form an essential part of any gateway implementation. The following kinds of activity are included under gateway O&M:

• Diagnosing hardware problems in the gateway processor, in its network interfaces, or in the connected networks, modems, or communication lines 🔧
• Installing a new version of the gateway software 💿
• Restarting or rebooting a gateway after a crash 🔄
• Configuring (or reconfiguring) the gateway ⚙️
• Detecting and diagnosing Internet problems such as congestion, routing loops, bad IP addresses, black holes, packet avalanches, and misbehaved hosts 🕵️‍♀️
• Changing network topology, either temporarily (e.g., to diagnose a communication line problem) or permanently 🧩
• Monitoring the status and performance of the gateways and the connected networks 👀
• Collecting traffic statistics for use in (Inter-)network planning 📊

Gateways, packet-switches, and their connected communication lines are often operated as a system by a centralized O&M organization. This organization will maintain a (Inter-)network operation center, or NOC, to carry out its O&M functions. It is essential that gateways support remote control and monitoring from such a NOC, through an Internet path (since gateways might not be connected to the same network as their NOC) 🌐 Furthermore, an IP datagram traversing the Internet will often use gateways under the control of more than one NOC. Therefore, Internet problem diagnosis will often involve cooperation of personnel from more than one NOC 🤝 In some cases, the same gateway may need to be monitored by more than one NOC.

The tools available for monitoring at a NOC may cover a wide range of sophistication. Proposals have included multi-window, dynamic displays of the entire gateway system, and the use of AI techniques for automatic problem diagnosis 🤖

Gateway O&M facilities discussed here are only a part of the large and difficult problem of Internet management. These problems encompass not only multiple management organizations, but also multiple protocol layers. For example, at the current stage of evolution of the Internet architecture, there is a strong coupling between host TCP implementations and eventual IP-level congestion in the gateway system [9]. Therefore, diagnosis of congestion problems will sometimes require the monitoring of TCP statistics in hosts. Gateway algorithms also interact with local network performance, especially through handling of broadcast packets and ARP, and again diagnosis will require access to hosts (e.g., examining ARP caches). However, consideration of host monitoring is beyond the scope of this RFC 🫣

There are currently a number of R&D efforts in progress in the area of Internet management and, more specifically, gateway O&M. It is hoped that these will lead quickly to Internet standards for the gateway protocols and facilities required in this area. This is also an area where vendor creativity can make a significant contribution 💡

5.2. Gateway O&M Models 🧩

There is a range of possible models for performing O&M functions on a gateway. At one extreme is the local-only model, under which the O&M functions can only be executed locally, e.g., from a terminal plugged into the gateway machine. At the other extreme, the fully-remote model allows only an absolute minimum of functions to be performed locally (e.g., forcing a boot), with most O&M done remotely from the NOC. There are intermediate models, e.g., one in which NOC personnel can log into the gateway as a host, using the Telnet protocol, to perform functions which can also be invoked locally. The local-only model may be adequate in a few gateway installations, but in general remote operation from a NOC will be REQUIRED, and therefore remote O&M provisions are REQUIRED for most gateways 🌸

Remote O&M functions may be exercised through a control agent (program). In the direct approach, the gateway would support remote O&M functions directly from the NOC using standard Internet protocols (e.g., UDP or TCP). In the indirect approach, the control agent would support these protocols and control the gateway itself using proprietary protocols. The direct approach is preferred, although either approach is acceptable. The use of specialized host hardware and/or software requiring significant additional investment is 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, with equivalent functionality with respect to a local agent terminal 🎧

It is desirable that a control agent and any other NOC software tools which a vendor provides operate as user programs in a standard operating system. The use of the standard Internet protocols UDP and TCP for communicating with the gateways SHOULD facilitate this 💖

Remote gateway monitoring and (especially) remote gateway control present important access control problems which MUST be addressed 🔐 Care MUST also be taken to ensure control of the use of gateway resources for these functions. It is not desirable to let gateway monitoring take more than some limited fraction of the gateway CPU time, for example. On the other hand, O&M functions MUST receive priority so they can be exercised when the gateway is congested, i.e., when O&M is most needed 🚨

There are no current Internet standards for the control and monitoring protocols, although work is in progress in this area 🛠️. The Host Monitoring Protocol (HMP) [7] could be used as a model until a standard is developed, but it is strongly RECOMMENDED that gateway O&M protocol be built on top of one of the standard Internet end-to-end protocols, UDP or TCP 💅. An example of a very simple but effective approach to gateway monitoring is in RFC-996 [43] ✨.

5.3. Gateway O&M Functions 🔧

Okay so, these are the O&M functions a gateway needs to perform 👀:

A. Maintenance -- Hardware Diagnosis 🩺

Each gateway MUST operate as a stand-alone device for local hardware maintenance, no cap. Someone has to be able to run diagnostic programs at the gateway site using only on-site tools, which could literally be just a diskette or tape and a local terminal 💾. It's desirable, although not REQUIRED, to be able to run diagnostics or dump the gateway over the network when something goes wrong 🌐. Means SHOULD be provided to allow remote control from the NOC of modems attached to the gateway. The most important modem control capability is entering and leaving loopback mode, so you can diagnose line problems 🔍.

B. Control -- Dumping and Rebooting 🔄

It MUST be possible to dump and reboot a stand-alone gateway upon command from the NOC. On top of that, a stand-alone gateway MUST include a watchdog timer that either initiates a reboot automatically or signals a remote control site if it isn't reset periodically by the software ⏲️. Honestly the watchdog timer is giving main character energy 💜. It's desirable that the boot data live at an Internet host (like the NOC host) and get transmitted via the net, but using local devices at the gateway site is acceptable 🫶.

C. Control -- Configuring the Gateway ⚙️

Every gateway will have a bunch of configuration parameters that MUST be set (see the next section for examples 📝). It MUST be possible to update the parameters without rebooting the gateway. At worst, a restart MAY be REQUIRED 😬.

D. Monitoring -- Status and Performance 📊

A mechanism MUST be provided for retrieving status and statistical information from a gateway. A gateway MUST supply that information in response to a polling message from the NOC. Also, it MAY be desirable to configure a gateway to transmit status spontaneously and periodically to a NOC (or a set of NOCs) for recording and display 📈.

Examples of interesting status information include link status, queue lengths, buffer availability, CPU and memory utilization, the routing data-base, error counts, and packet counts. Counts SHOULD be kept for dropped datagrams, separated by reason. Counts of ICMP datagrams SHOULD be kept by type and categorized into those originating at the gateway and those destined for the gateway. It would be useful to maintain many of these statistics by network interface, by source/destination network pair, and/or by source/destination host pair 🎀.

Note that a great deal of useful monitoring data is often to be found in the routing data-base. It's therefore useful to be able to tap into this data-base from the NOC 🕵️‍♀️.

E. Monitoring -- Error Logging 🚨

A gateway SHOULD be capable of asynchronously sending exception ("trap") reports to one or more specified Internet addresses, one of which will presumably be the NOC host. There MUST also be a mechanism to limit the frequency of those trap reports, and the parameters controlling that frequency MUST be settable in the gateway configuration 🔒.

Examples of conditions that SHOULD result in traps include datagrams discarded because of TTL expiration (an indicator of possible routing loops 🔁), resource shortages, or an interface changing its up/down status.

5.4. Gateway Configuration Parameters 🎛️

Every gateway has a set of configuration parameters controlling how it operates. It MUST be possible to set these parameters remotely from the NOC or locally at any time, without taking the gateway down 🙌.

The following is a partial but representative list of possible configuration parameters for a full-function gateway. The items marked with "(i)" SHOULD be settable independently for each network interface 🌸.

• (i) IP (sub-) network address
• (i) Subnet address mask
• (i) MTU of local network
• (i) Hardware interface address
• (i) Broadcast compatibility option (0s or 1s)
• EGP parameters -- neighbors, Autonomous System number, and polling parameters
• Static and/or default routes, if any
• Enable/Disable Proxy ARP
• Source Quench parameters
• Address filter configuration
• Boot-host address
• IP address of time server host
• IP address(es) of logging host(s)
• IP address(es) of hosts to receive traps
• IP address(es) of hosts authorized to issue control commands
• Error level for logging
• Maximum trap frequency
• Hold-down period (if any)

---

Appendix A. Technical Details 📚

This Appendix collects a number of technical details and rules concerning datagram forwarding by gateways and datagram handling by hosts, especially in the presence of broadcasting and subnets 🌈.

A.1. Rules for Broadcasting 📣

The following rules define how to handle broadcasts of packets and datagrams [50]:

a. Hosts (which do not contain embedded gateways) MUST NEVER forward any datagrams received from a connected network, broadcast or not.

When a host receives an IP datagram, if the destination address identifies the host or is an IP broadcast address, the host passes the datagram to its appropriate higher-level protocol module (possibly sending ICMP protocol unreachable, but not if the IP address was a broadcast address). Any other IP datagram MUST simply be discarded, without an ICMP error message. Hosts never send redirects 🙈.

b. All packets containing IP datagrams which are sent to the local-network packet broadcast address MUST contain an IP broadcast address as the destination address in their IP header. Put another way, a gateway (or host) MUST NOT send in a local-network broadcast packet an IP datagram that has a specific IP host address as its destination field.

c. A gateway MUST never forward an IP datagram that arrives addressed to the IP limited broadcast address {-1,-1}. Furthermore, it MUST MUST NOT send an ICMP error message about discarding such a datagram.

d. A gateway MUST NOT forward an IP datagram addressed to network zero, i.e., {0, *}.

e. A gateway MAY forward a directed broadcast datagram, i.e., a datagram with the IP destination address:

{ <Network-number>, -1}

However, it MUST NOT send such a directed broadcast out the same interface it came in, if this interface has <Network-number> as its network number. If the code in the gateway making this decision does not know what interface the directed-broadcast datagram arrived on, the gateway cannot support directed broadcast to this connected network at all.

f. A gateway is permitted to protect its connected networks by discarding directed broadcast datagrams.

A gateway will broadcast an IP datagram on a connected network if it is a directed broadcast destined for that network. Some gateway-gateway routing protocols (e.g., RIP) also require broadcasting routing updates on the connected networks. In either case, the datagram MUST have an IP broadcast address as its destination.

Note: as observed earlier, some host implementations (those based on Berkeley 4.2BSD) use zero rather than -1 in the host field. To provide compatibility during the period until these systems are fixed or retired, it MAY be useful for a gateway to be configurable to send either choice of IP broadcast address and accept both if received 🍓.

A.2. ICMP Redirects 🦋

A gateway will generate an ICMP Redirect if and only if the destination IP address is reachable from the gateway (as determined by the routing algorithm) and the next-hop gateway is on the same (sub-)network as the source host. Redirects MUST NOT be sent in response to an IP network or subnet broadcast address or in response to a Class D or Class E IP address.

A host MUST discard an ICMP Redirect if the destination IP address is not its own IP address, or the new target address is not on the same (sub-)network. An accepted Redirect updates the routing data-base for the old target address. If there is no route 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 💖.

B.1. Proprietary and Extensibility Issues ✨

okay so bestie, hosts, gateways and networks running Internet tech have been up and running for years 🎀 but vendors, users and operators need to know that not every networking problem is fully sorted yet 🙈 so when the NSF networking community needs something new or a better solution, it may be necessary to field new protocols or augment existing ones 💖 normally these new protocols are designed to interoperate in all practical respects with existing protocols 🫶 but sometimes existing systems MUST be upgraded to support these new or augmented protocols 😭

wait, I need to be careful here 💅 the original doesn't say MUST there, so I'm not capitalising it. I'm just saying existing systems may have to be upgraded, which is the same vibe.

okay, back to the tea ☕ NSF systems procurements may favor vendors who commit to keeping up with current Internet technology and being ready to upgrade their products from time to time as appropriate 🦋 so vendors are strongly urged to treat extensibility and periodic upgrades as fundamental characteristics of their products 🔥 one of the most productive and rewarding ways to do this long-term is to join ongoing Internet research and development programs in partnership with the academic community 👑

B.2. Interconnection Technology 🌈

so the NSFNET context wants network-level interoperability between different vendors' gateways 💅 which means a gateway must, at a minimum, support Ethernet connections and serial line protocol connections 🍓

ethernet is currently the most important common interconnection technology between Internet systems from different vendors 🧚 and it's giving because of these reasons:

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 make Ethernet the common point of demarcation between NSF network systems supplied by different vendors, regardless of technology 🦋 it is a requirement of NSF gateways that, no matter what proprietary switching technology a given vendor-supplied network uses, its gateways must support an Ethernet attachment to gateways of other vendors 💖

future NSF gateway requirements are expected to specify other interconnection technologies 🎀 the most likely candidates are those based on X.25 or IEEE 802, but broadband cable, optical fiber, or other media may also be considered 😭 lowkey iconic 💅

B.3. Routing Interoperability 🧚

the Internet doesn't currently have an "open IGP" standard, i.e., a common IGP that would let gateways from different vendors form a single Autonomous System 💀 several approaches to routing interoperability are in use right now among vendors and the NSF networking community 🌸

• Proprietary IGP 🔥

at least one gateway vendor has implemented a proprietary IGP and uses EGP to interface with the rest of the Internet 👑

• RIP 🦋

RIP is undocumented, and various implementations of it differ in subtle ways 🙈 still, it has been used successfully for interoperation among multiple vendors as an IGP ✨

• Gateway Daemon 💜

the NSF networking community built a "gateway daemon" program that can mediate among multiple routing protocols to create a mixed-IGP Autonomous System 🎀 specifically, the prototype gateway daemon runs on a 4.3BSD machine acting as a gateway and exchanges routing information with other gateways, speaking both RIP and Hello protocols 🫶 on top of that, it supports EGP to other Autonomous Systems 💅

B.4. Multi-Protocol Gateways 🌈

the current NSF gateway requirements only specify the Internet protocol IP 🍓 but in a few years the Internet will begin a gradual transition to the functionally-equivalent subset of the ISO protocols [17] 🧚 more and more traffic will use the ISO Connectionless Mode Network Service (CLNS, but commonly called "ISO IP") [33] instead of IP 💖 it's expected that the ISO suite will eventually become the dominant one, but requirements to support Internet IP will probably keep going, maybe forever 😭

to support the transition to ISO protocols and the coexistence stage, it is highly desirable that a gateway design provides for future extensions to support more than one protocol simultaneously, in particular both IP and CLNS [18] 🦋 main character energy 👑

current 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 recognise that future requirements to interwork between Internet and ISO applications, for example, may open up a chance to sell gateways that support multiple protocols at all levels up through the application level [16] 🔥 the network-level NSF gateway requirements summarised in this document are expected to be folded into the requirements document for these application-level gateways 🎀

Internet gateways work as intermediate systems (IS) with respect to the ISO connectionless network model, and they incorporate defined packet formats, routing algorithms and related procedures [33, 34] 🌸 the ISO ES-IS [37] provides the functions of ARP and ICMP Redirect 🌈

B.5. Access Control and Accounting 🔐

there are no requirements for NSF gateways at this time to include specific access-control and accounting mechanisms in the design 🙈 however, these important issues are being studied right now and will be included in a later edition of this document 💖 vendors are encouraged to plan for bringing these mechanisms into their products ✨ no definitive common model for access control and accounting has shown up yet, but it's possible to outline some general features such a model is likely to have 💅 among them:

1. The primary access control and accounting 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 mechanisms may be necessary in the gateways, 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 cannot be specified in advance 🫶
3. NSF gateways may be required to include access control and accounting mechanisms based on datagram source/destination address, as well as other fields in the IP header 🎀
4. NSF gateways may be required to enforce policies on access to gateway and communication resources 🧚 these policies may be based on equity ("fairness") or on inequity ("priority") 💜

Acknowledgments 🫶

an earlier version of this document (RFC-985) [60] was prepared by Dave Mills on behalf of the Gateway Requirements Subcommittee of the NSF Network Technical Advisory Group 🌸 it was done in cooperation with the Internet Activities Board, Internet Architecture Task Force, and Internet Engineering Task Force 💖 this effort was chaired by Dave Mills and contributed to by many people 🔥

the authors of this current document also got help from lots of people in the NSF and ARPA networking community 🥹 we thank you, one and all 💅✨

References and Bibliography 📚

Okay bestie, this is the receipts drawer 🧾 Many of these sources are available from the DDN Network Information Center, SRI International, 333 Ravenswood Avenue, Menlo Park, California 94025 (telephone: 800-235-3155). Call them and ask nicely for your reading list 💅

• [1] Postel, J., "Internet Protocol", RFC-791, USC Information Sciences Institute, September 1981.
• [2] Postel, J., "Internet Control Message Protocol", RFC-792, USC Information Sciences Institute, September 1981.
• [3] BBN, "Interface Message Processor - Specifications for the Interconnection of a Host and an IMP", Report 1822, Bolt Beranek and Newman, December 1981.
• [4] Plummer, D., "An Ethernet Address Resolution Protocol", RFC-826, Symbolics, September 1982.
• [5] DOD, "Military Standard Internet Protocol", Military Standard MIL-STD-1777, United States Department of Defense, August 1983.
• [6] BBN, "Defense Data Network X.25 Host Interface Specification", Report 5476, Bolt Beranek and Newman, December 1983.
• [7] Hinden, R., "A Host Monitoring Protocol", RFC-869, BBN Communications, December 1983.
• [8] Korb, J.T., "A Standard for the Transmission of IP Datagrams over Public Data Networks", RFC-877, Purdue University, September 1983.
• [9] Nagle, J., "Congestion Control in IP/TCP Internetworks", RFC-896, Ford Aerospace, January 1984.
• [10] Hornig, C., "A Standard for the Transmission of IP Datagrams over Ethernet Networks", RFC-894, Symbolics, April 1984.
• [11] Mills, D.L., "Exterior Gateway Formal Specification", RFC-904, M/A-COM Linkabit, April 1984.
• [12] Xerox, "Xerox Synchronous Point-to-Point Protocol", Xerox System Integration Standard 158412, December 1984.
• [13] Kirton, P., "EGP Gateway under Berkeley UNIX 4.2", RFC-911, USC Information Sciences Institute, August 1984.
• [14] Postel, J., "Multi-LAN Address Resolution", RFC-925, USC Information Sciences Institute, October 1984.
• [15] Finlayson, R., T. Mann, J. Mogul, and M. Theimer, "A Reverse Address Resolution Protocol", RFC-904, Stanford University, June 1984.
• [16] NRC, "Transport Protocols for Department of Defense Data Networks", RFC-942, National Research Council, March 1985.
• [17] Postel, J., "DOD Statement on NRC Report", RFC-945, USC Information Sciences Institute, April 1985.
• [18] ISO, "Addendum to the Network Service Definition Covering Network Layer Addressing", 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, IEEE, Washington DC, March 1985. Also in: IEEE Communications Magazine, March 1985. Also available as ISI-RS-85-153.
• [20] Romkey, J., "PC/IP Programmer's Manual", MIT Laboratory for Computer Science, pp. 57-59, April 1986.
• [21] Mogul, J., and J. Postel, "Internet Standard Subnetting Procedure", RFC-950, Stanford University, August 1985.
• [22] Reynolds, J., and J. Postel, "Official Internet Protocols", RFC-1011, USC Information Sciences Institute, May 1987.
• [23] Reynolds, J., and J. Postel, "Assigned Numbers", RFC-1010, USC Information Sciences Institute, May 1987.
• [24] Nagle, J., "On Packet Switches with Infinite Storage", RFC-970, Ford Aerospace, December 1985.
• [25] SRI, "DDN Protocol Handbook", NIC-50004, NIC-50005, NIC-50006, (three volumes), SRI International, December 1985.
• [26] SRI, "ARPANET Information Brochure", NIC-50003, SRI International, December 1985.
• [27] Mills, D.L., "Autonomous Confederations", RFC-975, M/A-COM Linkabit, February 1986.
• [28] Jacobsen, O., and J. Postel, "Protocol Document Order Information", RFC-980, SRI International, March 1986.
• [29] Malis, A.G., "PSN End-to-End Functional Specification", RFC-979, BBN Communications, March 1986.
• [30] Postel, J, "Internetwork Applications using the DARPA Protocol Suite", Proceedings INFOCOM 85, IEEE, Washington DC, March 1985. Also available as ISI-RS-85-151.
• [31] Postel, J, C. Sunshine, and D. Cohen, "The ARPA Internet Protocol", Computer Networks, Vol. 5, No. 4, July 1981.
• [32] Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication", IEEE Transactions on Communication, May 1974.
• [33] ISO, "Protocol for Providing the Connectionless-mode Network Service", RFC-994, DIS-8473, International Standards Organization, March 1986.
• [34] ANSI, "Draft Network Layer Routing Architecture", ANSI X3S3.3, 86-215R, April 1987.
• [35] Rosen, E., "Exterior Gateway Protocol (EGP)", RFC-827, Bolt Beranek and Newman, October 1982.
• [36] Sidhu, D., "Some Problems with the Specification of the Military Standard Internet Protocol", RFC-963, Iowa State University, November 1985.
• [37] ISO, "End System to Intermediate System Routing Exchange Protocol for use in conjunction with ISO 8473", RFC-995, April 1986.
• [38] Postel, J., "Address Mappings", RFC-796, USC/Information Sciences Institute, September 1981.
• [39] Mills, D., "DCN Local Network Protocols", RFC-891, M/A-COM Linkabit, December 1983.
• [40] McQuillan, J. M., I. Richer, and E. C. Rosen, "The New Routing Algorithm for the ARPANET", IEEE Transactions on Communications, May 1980.
• [41] Hinden, R., and A. Sheltzer, "The DARPA Internet Gateway", RFC-823, Bolt Beranek and Newman, September 1982.
• [42] Farber, D., G. Delp, and T. Conte, "A Thinwire Protocol for Connecting Personal Computers to the Internet", RFC-914, University of Delaware, September 1984.
• [43] Mills, D., "Statistics Server", RFC-996, University Of Delaware, February 1987.
• [44] Postel, J. and K. Harrenstien, "Time Protocol", RFC-868, May 1983.
• [45] Mills, D., "Network Time Protocol (NTP)", RFC-958, M/A-Com Linkabit, September 1985.
• [46] Seamonson, L., and E. Rosen, "Stub Exterior Gateway Protocol", RFC-888, Bolt Beranek And Newman, January 1984.
• [47] Deering, S., and D. Cheriton, "Host Groups: A Multicast Extension to the Internet Protocol", RFC-966, Stanford University, December 1985.
• [48] Deering, S., "Host Extensions for IP Multicasting", RFC-988, Stanford University, July 1986.
• [49] Mogul, J., "Broadcasting Internet Datagrams", RFC-919, Stanford University, October 1984.
• [50] Mogul, J., "Broadcasting Internet Datagrams in the Presence of Subnets", RFC-922, Stanford University, October 1984.
• [51] Rosen, E., "Exterior Gateway Protocol", RFC-827, Bolt Beranek and Newman, October 1982.
• [52] Rose, M., "Low Tech Connection into the ARPA Internet: The Raw Packet Split Gateway", Technical Report 216, Department of Information and Computer Science, University of California, Irvine, February 1984.
• [53] Rosen, E., "Issues in Buffer Management", IEN-182, Bolt Beranek and Newman, May 1981.
• [54] Rosen, E., "Logical Addressing", IEN-183, Bolt Beranek and Newman, May 1981.
• [55] Rosen, E., "Issues in Internetting - Part 1: Modelling the Internet", IEN-184, Bolt Beranek and Newman, May 1981.
• [56] Rosen, E., "Issues in Internetting - Part 2: Accessing the Internet", IEN-187, Bolt Beranek and Newman, June 1981.
• [57] Rosen, E., "Issues in Internetting - Part 3: Addressing", IEN-188, Bolt Beranek and Newman, June 1981.
• [58] Rosen, E., "Issues in Internetting - Part 4: Routing", IEN-189, Bolt Beranek and Newman, June 1981.
• [59] Sunshine, C., "Comments on Rosen's Memos", IEN-191, USC Information Sciences Institute, July 1981.
• [60] NTAG, "Requirements for Internet Gateways -- Draft", RFC-985, Network Technical Advisory Group, National Science Foundation, May 1986.
• [61] Khanna, A., and Malis, A., "The ARPANET AHIP-E Host Access Protocol (Enhanced AHIP)", RFC-1005, BBN Communications, May 1987
• [62] Nagle, J., "Congestion Control in IP/TCP Internetworks", ACM Computer Communications Review, Vol.14, no.4, October 1984.