RFC 940

RFC 940 ✨ Toward an Internet Standard Scheme for Subnetting

Okay bestie, the title block 🎀 says this is RFC 940, dated April 1985, from the Network Working Group (the label on the page is GADS). The author is the Gateway Algorithms and Data Structures (GADS) Task Force, chaired by David L. Mills 💅. There's no category line in the title block, and no "obsoletes" or "updates" line either, so it doesn't name any RFC it replaces or changes 🫶.

Status of This Memo 📜

This RFC is all about standardizing the protocol used in subnetted environments in the ARPA-Internet 🌈. Distribution of this memo is unlimited 🦋.

The author is the Gateway Algorithms and Data Structures (GADS) Task Force, chaired by David L. Mills 👑.

Introduction 🌸

Okay so, lots of sites have a whole complex of local links connected to the Internet through a gateway 🧚. The inside details of how everything connects are honestly not that interesting to the rest of the Internet 🙈.

One way to organize those local complexes is to use the same move the Internet uses to organize networks ✨. You declare each link to be an entity (kind of like a network), then wire the links together with devices that do routing (kind of like gateways). This whole setup is called subnetting 💖. The individual links are called subnets, and the connecting devices are called subgateways (or bridges, or gateways) 🎀.

Every host on the Internet has to make a decision whenever it sends a datagram. It has to answer "Is this datagram addressed to a host on a directly connected network, or must it be sent to a gateway?" 🤔. In a subnetted environment the question gets bigger: "Is this datagram addressed to a host on a directly connected subnet, or must it be sent to a (sub)gateway?" 💅. Answering this question is what we call making the routing decision 🦋.

Hosts in a subnetted environment must have procedures for making the routing decision built into their IP or network interface software 🔥. Those hosts can come from all sorts of sources, so it's super important to pin down a standard subnetting scheme. Then different suppliers can build hosts that are compatible with each other and with the complexes at different sites 🫶. Without a designated standard, suppliers just can't create compatible hosts 😭.

The big problem is that if different suppliers come up with different subnetting schemes, a customer who installs hosts from two or more suppliers might find they don't work together at all 💀.

This topic has been covered in a set of RFCs [1,2,3,4] and in a whole flurry of messages in the Gateway Algorithms and Data Structures Task Force 🌈. It's strongly suggested that if you use subnetting at all, you do it according to this new standard scheme 👑.

Approach 🧚

Right now an Internet address is a two-layer hierarchy: a 'network' part and a per-network 'rest' field 💜. This subnet scheme adds an optional 'subnet' layer and field on top 🦋.

The subnet field gets made by stealing some bits from the rest (or host) field of the address ✨. The details of the subnet field are site specific 🎀. All three classes of networks (A, B, and C) can be subnetted 💅.

Using subnets is an optional local decision 🌸. The fact that a network has subnets is invisible outside that network, so the change is totally local and a site can set it up without any global Internet perturbations 😭. A complex of links gets one IP network number, and from the outside it looks like a single network with that number. Only on the inside does the local structure show up 🫶.

Here's the twist 🔥: even though using subnets is optional, any IP implementation which may possibly be used in a potentially subnetted environment should provide for subnet field configuration as described above 👑. An implementation like that works properly with or without subnetting 🌈. Implementations that lack this provision will not function in a subnetted environment, which makes them potentially less useful 💀.

This specification is not meant to require one particular implementation technique inside the host 🧚. It defines the external behavior of the host in a subnetted environment instead 🦋. It doesn't say how routing gets done or go into the details of how hosts are built 🎀. And yes, gateways are hosts too 💖.

Still, it's easiest to understand the approach by looking at one possible host implementation 💜.

Example Implementation 🌈

Let's use "subnet" to mean the locally attached transmission medium 💅.

The key decision is "Is the destination IP address on my subnet or not?" ✨ Once that's decided, the host knows whether to send the datagram directly to the destination on the subnet or to send it to a gateway 🔥.

The host uses a 32-bit mask, along with the host's own IP address, to figure out whether destination IP addresses are on its subnet 🎀.

The mask can be configured at boot time as a static quantity, or it can be distributed by a protocol that's beyond the scope of this memo 🌸.

If the bitwise AND of the mask with the destination IP address matches the bitwise AND of the mask with the host's own IP address, the destination is assumed to be on its subnet 🫶. If not, the destination is assumed to be on a subnet or network reachable only via a gateway 🦋.

Note: if the mask is all zeros, all destinations will appear to be on this subnet 🙈. If the mask is all ones, only the sending host itself will appear to be on this subnet 💀. If the mask has ones in the network field and zeros in the rest field, subnets are not in use 💅.

The procedure above must be treated as a per interface procedure for multihomed hosts 👑.

For further info on the background and rationale, check out RFC-917, "Internet Subnets" [1] 📚 💖.

References 📚

• [1] Mogul, J., "Internet Subnets", RFC-917, Stanford University, October 1984.
• [2] Postel, J., "Multi-LAN Address Resolution", RFC-925, USC/Information Sciences Institute, October 1984.
• [3] Clark, D., "A Subnetwork Addressing Scheme", RFC-932, MIT LCS, January 1985.
• [4] Karels, M., "Another Internet Subnet Addressing Scheme", RFC-936, UC Berkeley, February 1985.