Summary
- RFC 917 was a proposal, not a standard, and it reported Stanford IP subnetting in operation since early 1982: about 330 hosts, 18 subnets and a similar number of gateways by 1984.
- Stanford mapped Internet subnets onto existing Pup Ethernet numbers; RFC 917 then proposed a variable-width subnet field chosen per network, with RFC 950 standardizing host procedures in 1985.
A standard often gets remembered as the beginning of a system. RFC 917 preserves a less tidy sequence: subnetting had already become a working arrangement at Stanford before Jeffrey Mogul’s October 1984 proposal tried to describe a shared Internet scheme. The RFC’s own status asks for discussion and improvements. Its case study dates Stanford’s IP subnets to early 1982.
The installation did not begin with an empty network. Stanford had used Pup on several Experimental Ethernets since 1979. When Internet Protocol was introduced, Stanford chose an eight-bit subnet number and made each Internet subnet number match the Pup network number for an Ethernet. The eight-bit Pup host number filled the host field. The design reused names and machinery the local network already understood.
That continuity reached into gateways. Stanford’s Pup-only gateways forwarded IP datagrams according to Pup routing tables; they did not parse IP packets deeply enough to adjust the IP Time-to-Live field. Multi-homed Internet hosts that acted as gateways did adjust it. Mogul reported that forwarding-loop bugs had not appeared in that setting. This is a bounded operational observation, not evidence that a gateway can generally ignore TTL.
The 1984 snapshot gives the scale without turning it into an Internet-wide count: roughly 330 Stanford hosts, 18 subnets and a similar number of subnet gateways. Routing tables came from the same process that maintained Pup routes, translated into Internet subnet numbers. When 10-megabit Ethernets arrived, gateways used an ARP-based arrangement that let unmodified hosts participate. The system changed at the edges while preserving parts of the installed base.
MIT had a different local bargain. Before classful network numbers, assigning each of its many links a separate IP network number would consume a large part of available address space. MIT kept one network number and divided the 24-bit “rest” into three eight-bit fields: subnet, a field required to be zero, and host. The subnet byte aligned with CHAOS; the host byte matched common local hardware. MIT’s planned dynamic gateway exchange had not been implemented, so static tables remained. ICMP Host Redirects helped keep changes to host software small.
RFC 917 compared four ways to encode a subnet: variable-width, fixed-width, and two self-encoding variants. It selected a variable-width field whose width stayed constant inside one network but could differ between organizations. Self-encoding might let a host infer subnetting from an address alone, yet it could constrain existing host numbers and cut local address space. For an organization, the choice of how many scarce “rest” bits to spend on subnets remained local.
The proposal also faced a bootstrapping question: how would a diskless host learn that width? RFC 917 proposed ICMP Address Format Request and Reply messages, while allowing stored configuration. If no gateway answered, a host could begin with a zero-width assumption and later adjust when a gateway announced the actual value. That proposal must not be confused with RFC 950’s later Address Mask messages.
RFC 940 made the coordination problem explicit: without a common scheme, hosts from different suppliers could disagree about whether a destination was directly attached or needed a gateway. RFC 950 followed in August 1985, said it was based on RFC 917, and strongly recommended its host procedures when subnetting was used. It did not fully specify procedures between subnet gateways. The record is not “standard, then deployment.” It is local systems, a proposal that made their choices legible, and a later standard that narrowed the host-facing contract.
Read through Heng Lu’s Note 64, the design is an example of a small common rule leaving room for local decisions: the address still identifies one Internet network externally, while a site chooses how to divide its interior. That is an editorial lens, not evidence about Mogul’s, Stanford’s, MIT’s or Postel’s intent.
- Source: RFC 917, “Internet Subnets” (October 1984): https://www.rfc-editor.org/rfc/rfc917.html
- Source: GADS, RFC 940, “Toward an Internet Standard Scheme for Subnetting” (April 1985): https://www.rfc-editor.org/rfc/rfc940.html
- Source: Jeffrey Mogul and Jon Postel, RFC 950, “Internet Standard Subnetting Procedure” (August 1985): https://www.rfc-editor.org/rfc/rfc950.html
- Context: Jon Postel, RFC 791, “Internet Protocol” (September 1981): https://www.rfc-editor.org/rfc/rfc791.html
- Heng Lu, Note 64 (interpretive lens only): https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
