RFC 932

RFC 932 🎀 A Subnetwork Addressing Scheme 🌸

Written by David D. Clark from MIT, LCS, dated January 1985. It's a proposed protocol for the ARPA-Internet community, and it doesn't obsolete or update anything (no obsoletes or updates are listed in the title block). 🧚

STATUS OF THIS MEMO 💅

okay so this RFC suggests a proposed protocol for the ARPA-Internet community and literally asks everyone to discuss it and send in suggestions for improvements 🫶. Distribution of this memo is unlimited, so share it with everyone you know ✨.

INTRODUCTION 🦋

Several recent RFCs have talked about needing a "subnet" structure inside the internet addressing scheme, and they've proposed strategies for "subnetwork" addressing and routing. The one that stands out is Jeff Mogul's RFC-917, "Internet Subnets" 👑. In it, a variable number of the leading bits of the host portion of the address get used to identify the subnet. The catch is that you have to modify the host implementation to make that work 😭. It's a simple change, but it has to be retrofitted into every implementation, including the ones that are already out in the field. (Check RFC-917 by Mogul for other approaches to this problem, like using Address Resolution Protocol 💜.)

This RFC proposes a different addressing scheme for subnets that, in most cases, needs zero changes to host software 🙈. The downsides are that the total number of subnets in any one network is limited, and that every gateway has to be modified 💀.

THE PROPOSAL 🌈

Here's the vibe: the individual subnets of a network get numbered using Class C addresses ✨. Now, a Class C address used for a subnet has to be distinguishable from a Class C address used for an isolated network, so we're reserving the upper half of the Class C address space for subnetworks. In other words, every Class C address whose high order bit is on 🔥. When a network is going to be organized as a series of subnetworks, a block of those reserved Class C addresses gets assigned to it. Specifically, that's a block of 256 addresses that all have the same first two bytes. So the subnetworks of a network are told apart by the third byte of the Internet address 🍓. (Heads up: this scheme means there can only be 256 subnetworks in a net. If you need more, you allocate two blocks and treat the total as two separate networks 🎀.)

The gateways and hosts attached to a subnetted network just use these addresses as ordinary Class C addresses, so no modification to any host software is required for hosts attached to a subnetwork 💖.

Now for gateways that aren't directly attached to the subnetted network. It's an unacceptable burden for them to separately store routing information for each of the subnets 😤. The whole goal of any subnet addressing scheme is a strategy that lets distant gateways store routing information for the network as a whole 👑. Here, since the first two bytes of the address are the same for every subnet in the network, a distant gateway can store and manipulate those first two bytes as if they were a single Class B address 🦋. These addresses can be used as either a Class B or a Class C address, depending on what's appropriate, and they've been informally called Class "B 1/2" addresses 🌸.

Here's the detailed version of how a gateway handles Class C addresses under this scheme 🧚. First, test whether the high order bit of the address is on. If it's not, the address is an ordinary Class C address and should be treated as one.

If the bit is on, this Class C address identifies a subnet of a network. Test whether this gateway is attached to that network. If it is, treat the address as an ordinary Class C address.

If the gateway is not attached to the network containing that subnetwork, discard the third byte of the Class C address and treat the resulting two bytes as a Class B address 😭. There's no conflict between this two-byte pattern and an ordinary Class B address, because the first bits of this address aren't those of a valid Class B address. They're the bits of a Class C address 💅.

OPTIMIZATIONS ✨

If a network grows to more than 256 subnetworks, it'll need two distinct blocks of special Class C addresses, and you view that aggregate as two separate networks 🎀. But the gateways of those two networks can, with proper design, run a joint routing algorithm that keeps optimal routes between the two halves, even when they're connected by a bunch of gateways 🔥.

Also, in general, gateways that aren't directly attached to a subnetworked network can be specially programmed to remember the individual Class C addresses, if doing that gives a greatly improved network efficiency in some particular case 🌈.

Earlier we said no modification to host software is necessary for this scheme. There's one case where a minor modification might help 🙈. Picture a distant host, one that isn't immediately attached to this subnetworked network. Even from far away, that host will still keep separate routing entries for each distinct subnetwork address it knows about 🧚. For most hosts, that's no problem at all, because most implementations don't try to remember routing information for every network address in the Internet. They only keep the addresses that are of current interest 💖. But if, for some reason, a host has a table that tries to remember routing information for every Internet address it has ever seen, then that host should be programmed to understand the gateway's algorithm for collapsing the addresses of distant subnets from three bytes to two 🫶. Still, it's not a recommended implementation strategy for a host to keep that much routing information, so under normal circumstances the host doesn't need to worry about the C to B conversion 💅.

DRAWBACK 😭

The big drawback here is that any implementation storing large tables of addresses has to be changed to know the "B 1/2" conversion rule. Most importantly, all gateways must be programmed to know this rule 💀. So adopting this scheme requires a scheduled, mandatory change in every gateway implementation. How hard that is to organize is unknown 🙈.

OTHER VARIATIONS 🦋

You could imagine other variations on the patterns of collapsing addresses 🌸. For example, 256 Class B addresses could be gathered together and collapsed into one Class A address. But since the first three bits of the resulting Class A address would be constrained, that would only allow 32 such subnetted networks to exist 😤. A more interesting option is to let Class C addresses collapse into a single Class A address. It's not totally obvious how to best organize the sub-fields of that address, but this combination would let a few very large nets of subnets get assembled within the Internet 👑.

The most interesting variation of "B 1/2" addresses is to increase the number of bits used to identify the subnet by taking bits from the resulting Class B address 🔥. For example, if 10 bits were used to identify the subnet (giving 1024 subnets per network), then the gateway, when forming the equivalent address, wouldn't just drop the third byte. It would also mask the last two bits of the B address 🧚. Since the first three bits of the address are constrained, that leaves 13 bits for the network number, or 8192 possible subnetworked networks 💖. That's not as large as we'd like, so it's clear that picking the size of the subnet field is an important compromise 🫶.

Danny Cohen has suggested that this scheme should be fully generalized, so the boundaries between the network, subnetwork, and host fields can be arbitrarily movable ✨. The problem with that generalization is figuring out how the gateway maintains the table or algorithm that lets the address collapsing happen 🤔. So this RFC proposes that, in the short run, only one single form of "B 1/2" addresses gets implemented as an Internet subnet standard 💅🌈.