Summary
- Paul Robinson’s informational RFC 1375 proposed F, G, H and K classes to let small sites use fewer IPv4 addresses than a conventional Class C network offered.
- The proposal also considered regional and device meanings for address bits, but said routers, bridges and other software had to permit its smaller local fields; its Class K prose and diagram do not agree.
A block could be too large
The address problem in 1992 was not only that IPv4 had a finite 32-bit space. The sizes available under the familiar network classes could fit organisations badly. RFC 1375 described a Class C network as allowing up to 254 local machines and argued that a site with four or five machines could waste more than 240 addresses. It imagined a growing population of small installations, bulletin-board systems moving from telephone access to Telnet or FTP, and even printers, fax machines and pagers reachable through Internet protocols.
Paul Robinson’s answer was to redraw the class boundaries. The memo proposed changing the leading bits of Class C and using part of that space for four new labels: F, G, H and K. The proposed local fields became progressively smaller. Class F was intended for sites with roughly 1–15 connected addresses; H for sites not expected to exceed seven; K for sites with one or two. The counts and network fields were part of a fixed class scheme, not a general instruction to choose any prefix length.
This was an attempt to fit network size into address structure. It was not a registry policy, a record of assignments, or evidence that these classes were allocated. RFC 1375 calls itself Informational and explicitly says it does not specify an Internet standard. Its summary even allows for the implementation method not yet being available, while suggesting that the corresponding space be reserved.
The compatibility condition was the real work
The memo did not assume that new bit patterns would work by themselves. It said the method should avoid problems only if bridges, routers, and other hardware and software did not assume that the final eight bits were always the local address and could permit smaller local fields. That sentence turns an apparently local allocation idea into a network-wide compatibility question. An address class is useful only when the devices that parse, configure, route, and administer it agree on what its bits mean.
RFC 1375 also looked beyond block size. An optional section suggested that selected bits might serve as regional routing codes, by analogy with international telephone numbering. The author immediately qualified the analogy: Internet numbers did not themselves identify a geographic place, and such codes were not necessary to routing. Notes in the memo went further, imagining address digits that could distinguish pagers, fax machines, gateways, or other device classes. These were speculative ideas in one informational proposal, not features of the deployed Internet.
One detail makes the specification’s limits unusually visible. In the prose, Class K has a seven-bit prefix written as 1101111, a 25-bit network number and a one-bit local address. The accompanying figure instead prints 110100 and a 26-bit network field. Those descriptions cannot both define the same layout. The discrepancy is in the published text; the available sources do not establish whether anyone implemented the proposal or what role this inconsistency played in its history.
A different way to make small blocks usable
The 1992 record also contains other responses to address and routing pressure. RFC 1338 proposed hierarchical allocation to service providers and supernetting; RFC 1366 addressed distribution of the registration function and network-number space. In September 1993, Standards Track RFC 1519 described CIDR: variable-length, bitmask-oriented allocations, often drawn from a provider’s block, alongside route aggregation. It stressed that allocation changes and routing-protocol changes had to work together for aggregation to become effective.
That later approach did not ask every address to announce a named network class or an optional geography or device type. It made the prefix length the relevant boundary. By 1995, RFC 1812 required IPv4 routers to support subnetting and CIDR; RFC 1878 tabulated variable-length subnets down to individual host routes. These later documents show the vocabulary that standards eventually used. They do not prove a simple causal chain in which CIDR replaced RFC 1375, nor do they tell us why Robinson’s proposal received no standard-track continuation.
Heng Lu’s Note 48 is useful here as an editorial lens: an IP address can be understood first as a unique numerical label whose records must remain coherent. That lens invites a question about scope. How much should an address itself encode, and how much should be handled by allocation records, masks, routing protocols, or application-level naming? RFC 1375’s answer ranged from network size to possible geography and device class. CIDR’s later answer concentrated on variable-length prefixes and aggregation. The difference was not just how many addresses a small site received; it was where the Internet placed the complexity of interpreting them.
Sources
- RFC 1375: Suggestion for New Classes of IP Addresses
- RFC 1174: Identifier Assignment and Connected Status
- RFC 1340: Assigned Numbers
- RFC 1338: Supernetting
- RFC 1366: Guidelines for Management of IP Address Space
- RFC 1519: Classless Inter-Domain Routing
- RFC 1812: Requirements for IP Version 4 Routers
- RFC 1878: Variable Length Subnet Table for IPv4
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
