Classful IPv4 and the Birth of Administrative Scarcity

Summary

A network requiring 300 ordinary host addresses exceeded one Class C network’s practical capacity of 254 by 46 addresses. The next native class offered 65,534 ordinary host addresses, while two Class Cs offered 508 at the possible cost of an additional route and more coordination. Classful geometry therefore made allocation a choice among unlike costs rather than a simple reading of host demand.
Three contemporaneous snapshots show that Class C networks dominated the count of assigned network-number units while Class A assignments dominated represented address capacity. In January 1983, 31 Class A assignments represented 99.648 per cent of the numerical address values covered by the published totals; 1,042 Class Cs represented 0.051 per cent.
The surviving material does not provide a matched sample of early applications, refusals and decisions. It cannot establish a general first-mover effect, unequal applicant access or the criteria used in a particular early class decision. It supports a narrower conclusion: durable assignments made before later criteria became explicit could create a plausible path-dependent option advantage.
Address-space scarcity, routing-state growth, an individual applicant’s sizing problem and limited administrative attention were separate constraints. They appeared at different times and often pointed toward different allocation choices.
Multiple Class Cs, subnetting, contiguous blocks and regional delegation were feasible period alternatives, but each imposed routing, hardware, coordination or administrative costs. A fair counterfactual cannot assume that classless routing was available throughout the 1980s.

A network planner expecting 300 ordinary hosts encountered a precise discontinuity. One Class C network contained 256 possible values in its eight-bit local-address field. Under the later clarified restrictions on all-zero and all-one host values, it supplied 254 ordinary host addresses. The requirement was therefore 46 addresses beyond one Class C, not two. The number two describes the difference between 256 numerical values and 254 ordinary host addresses; it does not describe the shortfall against a 300-host plan.

Two Class C networks could cover the immediate requirement with 508 ordinary host addresses. Yet they remained two classful networks, potentially requiring two externally visible routing entries, two registrations and additional local coordination. The next native class, Class B, supplied 65,536 numerical local-address values, or 65,534 ordinary host addresses. That was about 258.008 times the practical host capacity of a Class C and more than 218 times the stated 300-host requirement.

The protocol did not contain an intermediate class. It did not decide whether conservation of address values was more important than conservation of routing state, whether the organisation’s hardware could subnet safely, whether two smaller networks could be coordinated without disruption, or how much growth should be credited. Those questions had to be resolved outside the bit pattern.

This is the point at which technical granularity became administrative scarcity. Scarcity did not begin only when the remaining pool approached exhaustion. It also appeared whenever an applicant’s need fell into the wide gap between the available units and an administrator had to determine which cost the allocation system would accept.

The geometry created a decision boundary

RFC 791, published in September 1981, defined an Internet address as four octets, or 32 bits. Its high-order bits selected one of three ordinary address formats and thereby fixed the division between the network number and the local address.

Contemporary class	High-order pattern	Network-number bits after pattern	Local-address bits	Numerical values in one network	Ordinary host addresses under later clarified rules	Modern translation
Class A	`0`	7	24	16,777,216	16,777,214	/8
Class B	`10`	14	16	65,536	65,534	/16
Class C	`110`	21	8	256	254	/24

The slash notation is included only as a modern translation of the fixed class boundaries. It should not be read backward as evidence that an administrator in 1981 could assign an arbitrary prefix length. A Class B was not one point on a continuous menu. Its leading bits told classful implementations to treat the first two octets as the network portion. A Class C fixed the boundary after three octets. The system did not natively offer a globally routable allocation halfway between them.

The numerical capacity ratio from one class to the next was exactly 256. A Class A contained (2^{24}) local-address values, a Class B (2^{16}), and a Class C (2^8). After excluding the ordinary all-zero and all-one host values, the practical ratios were slightly larger:

(16,777,214 / 65,534 = 256.007782) Class B capacities per Class A.
(65,534 / 254 = 258.007874) Class C capacities per Class B.

The exclusions need to be dated. RFC 791 established the class geometry but did not publish a modern usable-host table. RFC 950, issued in 1985, explained the special meanings of zero and all-one fields in the context of subnetting and broadcasts. RFC 1122 stated in 1989 that host, network and subnet fields could not take all-zero or all-one values except in defined special cases.

For comparing allocations, total numerical values are the least assumption-dependent measure: (2^{24}), (2^{16}) or (2^8) per network. For reconstructing an applicant’s ordinary host-capacity problem under the later clarified rules, the familiar minus-two figures are appropriate. Mixing those two measures produces misleading claims, as the 300-host example demonstrates.

The high-order patterns also divided the entire 32-bit space unevenly. Addresses beginning with 0 occupied half of all bit strings. The 10 pattern occupied one quarter. The 110 pattern occupied one eighth. The remaining high-order patterns were reserved or developed for other purposes, including multicast and experimentation. Thus a small count of Class A network numbers controlled an enormous part of the numerical address space, while the much larger inventory of Class C network numbers occupied a smaller fraction.

This distinction between network-number units and represented capacity is fundamental. A register could contain thousands of Class C entries and only a few dozen Class A entries, making Class C appear dominant as a workload. The same register, measured by numerical address values, could be overwhelmingly concentrated in Class A. Neither denominator is inherently wrong. They answer different questions.

Network-number count approximates the number of classful units that had to be registered and, when externally visible, routed. Represented capacity measures how many address values lay inside the listed assignments. Neither is an applicant count. Neither measures active hosts, utilisation, routing visibility, organisational ownership or economic value.

Classful architecture therefore produced two forms of coarseness at once. It provided too few intermediate capacities for applicants, and it made the apparent distribution depend heavily on the observer’s unit of analysis. Administrative judgment entered at the first boundary. Historical judgment can go wrong at the second.

Routing made the larger unit operationally attractive

The gap between Class B and Class C would have been less consequential if routers could aggregate arbitrary adjacent networks without changing their interpretation. For much of the period, they could not.

The original architecture treated the Internet as a hierarchy of classful networks. A gateway could route on the network portion while leaving the recipient to interpret the local-address field. That arrangement was economical when one network number corresponded reasonably well to one physical network or one organisation. It became harder to sustain as universities, companies and public networks accumulated buildings, local-area networks, point-to-point connections and internal gateways.

RFC 950 described three broad options for an organisation with multiple LANs. It could obtain a separate Internet network number for every cable. It could make several LANs appear to be one transparent network. Or it could divide a single assigned network into subnets.

The first option preserved simple host implementations but exported local complexity into the global routing system. RFC 950 warned that propagating every local network globally would cause an explosion in routing-table size, including on gateways with little space for routing information. Transparent bridging avoided additional Internet network numbers but brought its own scaling and failure-domain limitations. Subnetting allowed one external classful network to contain several internal networks, conserving global routing entries at the cost of more capable local implementations.

The subnet arithmetic illustrates why Class B became attractive to a growing campus. If six bits of its 16-bit local field were used for subnets, the raw geometry produced 64 subnet patterns and 1,024 host patterns within each subnet. Under the period convention that excluded the all-zero and all-one subnet patterns, 62 ordinary subnets remained. Applying the ordinary host exclusions left 1,022 host values per subnet. The product was:

[ 62 \times 1,022 = 63,364 ]

That organisation could operate dozens of internal networks behind one external Class B number. The arrangement used far more address values than a small campus initially required, but it economised on externally visible network numbers and left space for internal growth.

Subnetting was not costless. Hosts and gateways needed to understand masks. Existing assignments within the local field could conflict with a newly chosen subnet boundary. Software had to decide whether a destination was local or required a gateway using more than the fixed class boundary.

The 1989 operational guide RFC 1118 described the compatibility problem directly. Much available software, notably 4.2BSD, could not handle subnetted addresses without additional software, while 4.3BSD supported subnetting as released. Other systems varied. Some could function as leaves but not as gateways inside a subnetted part of the network.

RFC 1118 also gave the routing cost a concrete scale. It said that some important nodes could store and exchange information for only about 700 networks. It advised a campus not to announce more than two discrete network numbers. A site expecting to exceed that limit was told to consider subnetting.

The allocator’s dilemma was therefore not simply “large block versus small block.” It was a choice between resources consumed in different places:

A Class B consumed a large part of the finite address pool but could conserve external routing entries.
Several Class Cs conserved numerical address values but could add routes and local coordination work.
Subnetting conserved external state but required compatible equipment and operational competence.
Deferring the decision conserved neither future renumbering effort nor administrative attention if the applicant soon outgrew the initial assignment.

The growth of routing state made the trade-off increasingly urgent. RFC 1338 reproduced a Merit series showing 173 advertised routes in July 1988, 603 in July 1989 and 4,775 in February 1992. The complete July 1988 to February 1992 comparison was:

[ 4,775 / 173 = 27.601 ]

That was a 27.601-fold increase over 43 months. The shorter July 1989 to February 1992 comparison was:

[ 4,775 / 603 = 7.919 ]

That was a 7.919-fold increase over 31 months. These are different comparisons and should not be combined.

RFC 1338 argued that allocating four to sixteen Class Cs instead of a Class B could slow Class B depletion but worsen routing-table growth unless inter-domain routing protocols could represent arbitrary network-and-mask aggregates. The proposed remedy therefore depended on more than a new registration rule. Routers and protocols had to carry information that did not fit the old class boundaries.

The 300-host applicant now looks less like a trivial arithmetic exercise. Two Class Cs offered sufficient immediate capacity, but they could require two routes. One Class B reduced the external representation to one network while reserving 65,536 numerical values. The architecture created the discontinuity. Routing and equipment determined the relative costs. The administrative system had to select an imperfect option.

The early decision interface remains incomplete

RFC 791 explained what a class meant. It did not specify who should receive one. That decision moved through a changing set of institutions and procedures.

In September 1981, RFC 790 published assigned network numbers and directed requests for assignments to Jon Postel at the University of Southern California’s Information Sciences Institute. The register showed assigned, reserved and unassigned numbers, but it did not publish a complete general test for choosing among Class A, B and C.

By January 1983, RFC 820 documented a more elaborate policy environment. It labelled assignments as research and development, defence or commercial. Its appendix summarised recommendations agreed between the Defense Data Network programme office and DARPA in September 1982. For the research community, the recommendations linked the grant of network identifiers to evidence that the applicant was acquiring standard gateway software or implementing a gateway meeting the External Gateway Protocol requirements.

That criterion concerned eligibility and operational readiness. It did not supply a complete sizing rule. It could distinguish an applicant prepared to participate in the relevant network environment from one without suitable gateway capability, but it did not tell an administrator whether a qualified organisation planning 500 hosts should receive two Class Cs or one Class B.

RFC 820 also recorded an implementation gap between the intended division of responsibilities and actual operation. The proposed division had not been fully implemented, and Postel remained the coordinator for number assignments. Formal role descriptions and day-to-day handling were still converging.

The institutional arrangement changed during the decade. The Computer History Museum’s Guide to the SRI ARC/NIC Records dates the transfer of Assigned Numbers administration and global IP address allocation from USC-ISI to the SRI NIC contract to 1987. The finding aid identifies correspondence and naming-and-addressing material that could contain request records, but it does not itself reveal the reasoning behind any individual class decision.

RFC 1118 supplied a public description of the applicant-facing procedure in 1989. A prospective connected network was instructed to send a message to [email protected], request the connected-address template, complete it and return it. The assigned address would then be sent back by electronic or postal mail. The guide added that few Class A numbers remained and that, in practical terms, most applicants had to choose between Class B and Class C.

This establishes that there was a form, a return channel and a result. It does not reproduce the completed forms or demonstrate which fields determined the class selected in any specific case. A procedural description is not a request-decision dataset.

The surviving confirmation sent to the University of Bristol is similarly limited. The university reproduces a message dated 8 March 1991 assigning 137.222.0.0, a Class B network, to BRISTOL-NET. It identifies the class, number, technical contact and date. It also advises the recipient on host-table registration, broadcast addressing and address resolution.

The confirmation does not contain Bristol’s submitted application, host forecast, subnet plan, alternatives considered, questions asked by the hostmaster or reasons for selecting Class B. It proves an outcome, not the administrator’s decision rule. It is one response without the corresponding request and deliberation.

The direct evidence assembled here therefore does not reconstruct a complete early request-response or request-decision pair. Claims about what an early administrator actually saw must remain hypotheses. A plausible administrator might have considered expected hosts, topology, gateways, software and connectivity because those matters were operationally relevant and appeared in public guidance. The surviving material does not demonstrate that all of them were submitted or weighted in a particular early decision.

The distinction matters because completed allocation tables are especially tempting evidence. They show what was recorded after approval. They do not show the class requested, the size first offered, an applicant’s forecast, a refusal, a reduction, a delay or an unsubmitted need. Inferring the decision interface from the completed table would turn outcomes into motives.

In August 1990, RFC 1174 described the institutional roles more formally. The IANA function at USC-ISI retained central authority to allocate and assign numeric identifiers and discretionary authority to delegate portions of that responsibility. Responsibility for network and autonomous-system identifiers had been lodged with the Internet Registry operated by SRI International at the DDN-NIC. The document recommended retaining central IANA and Internet Registry functions while delegating blocks to approved organisations internationally.

Those roles should not be collapsed. The IANA function, the Internet Registry, the NIC service and the Internet Activities Board occupied related but distinct positions. The IAB issued recommendations. The IANA function held allocation and delegation authority. The Internet Registry gathered and maintained records and processed number assignments. The applicant usually encountered the system through a hostmaster and a returned number.

RFC 1174 proves that discretion and delegation were recognised institutional concepts by 1990. It does not prove how discretion was exercised in a particular 1983 or 1991 case.

Measuring distribution without inventing applicants

A reproducible measurement can be built from contemporaneous published snapshots, provided its observation unit remains narrow.

The unit used here is one classful network-number unit as counted by the cited source. It is not an organisation, applicant, routed prefix, host, present holder, transfer or economic transaction. If a source associates a range containing 1,024 Class C networks with one name, the measurement counts 1,024 classful units. It does not pretend that the range represents 1,024 beneficiaries.

Three published snapshots provide useful points of comparison:

RFC 820’s January 1983 totals for assigned Class A, B and C network numbers.
RFC 1166, published in July 1990, and its totals for networks allocated for Internet and independent uses.
RFC 1466, published in May 1993, and its table labelled “Network Number Statistics (May 1992).”

Reserved and unassigned ranges, autonomous-system numbers, multicast space and experimental classes are excluded. Represented numerical values are calculated by multiplying each source count by (2^{24}), (2^{16}) or (2^8). The calculation does not subtract host, subnet or broadcast reservations because recipients could structure their local fields differently and because the purpose is to measure the numerical capacity encompassed by each classful assignment.

For January 1983:

[ (31 \times 16,777,216) + (24 \times 65,536) + (1,042 \times 256) = 521,933,312 ]

For July 1990:

[ (34 \times 16,777,216) + (2,533 \times 65,536) + (16,214 \times 256) = 740,578,816 ]

For the May 1992 statistics:

[ (49 \times 16,777,216) + (7,354 \times 65,536) + (44,014 \times 256) = 1,315,302,912 ]

Snapshot and source definition	Class A networks	Class B networks	Class C networks	Total classful units	Numerical address values represented	A share	B share	C share
January 1983, assigned totals in RFC 820	31	24	1,042	1,097	521,933,312	99.648%	0.301%	0.051%
July 1990, Internet and independent allocations in RFC 1166	34	2,533	16,214	18,781	740,578,816	77.024%	22.415%	0.560%
May 1992 statistics reproduced in RFC 1466	49	7,354	44,014	51,417	1,315,302,912	62.501%	36.642%	0.857%

Class C networks dominated the count of network-number units in all three selected snapshots. They did not dominate represented capacity. In January 1983, 31 Class A assignments encompassed 99.648 per cent of the numerical address values in the published totals. The 1,042 Class C units encompassed 0.051 per cent.

The first row contains an important concentration. RFC 820 associated the range from 192.1.xxx through 192.4.xxx with “BBN local networks.” Each complete second-octet value covered 256 Class C network numbers. Four such values therefore covered:

[ 4 \times 256 = 1,024 ]

Those 1,024 units accounted for:

[ 1,024 / 1,042 = 98.272553% ]

of the Class C count in the January 1983 total. Their combined numerical capacity was:

[ 1,024 \times 256 = 262,144 ]

That was equal to four Class B networks in raw numerical capacity:

[ 4 \times 65,536 = 262,144 ]

The range shows why network-unit counts cannot be read as beneficiary counts. It also shows that the class selected was not a mechanical function of aggregate numerical capacity. One prominent organisation could appear as a large collection of small classful units rather than as a single coarse block.

The published table does not say why. It does not show whether the BBN networks were separately routed, used for testing, reserved for different local environments or organised under some other technical plan. Substituting four Class Bs in a counterfactual preserves raw capacity but not necessarily topology, experimentation, routing behaviour or the intended administrative structure. The range is therefore evidence against a simplistic one-organisation/one-class reading, not evidence of the original administrator’s reasoning.

RFC 820 also contains apparent publication irregularities. Several defence Class C lines repeat a numerical value while the totals count distinct units. Temporary numbers, renamed networks and transition entries appear elsewhere. The source’s own totals are consequently safer for aggregate measurement than a naïve count of visible lines. They remain dependent on the source’s definitions.

The 1990 snapshot introduces a different denominator. RFC 1166 separately reported 4,210 networks assigned for the ARPA-Internet and DDN-Internet and 18,781 allocated for Internet and independent uses. The connected subset included 29 Class As, 1,209 Class Bs and 2,972 Class Cs. The broader allocation total contained 34 Class As, 2,533 Class Bs and 16,214 Class Cs.

The broader total is appropriate for measuring globally unique classful capacity placed into assigned or allocated use, including independent networks. The connected subset is closer to a count of networks within the specified Internet environments. Neither total is an applicant count. Neither reveals how many requests were denied or revised.

The 1992 sources warn against forcing the snapshots into a falsely precise continuous series. RFC 1338 reported that an analysis of the DDN-NIC’s network-contacts.txt file found 46 allocated Class A and 5,467 allocated Class B numbers on 25 February 1992. RFC 1466 later reproduced May 1992 totals of 49 and 7,354. The documents also used different Class B pool denominators: 16,256 in RFC 1338 and 16,383 in RFC 1466.

It would be unsafe to interpret the entire difference as a three-month allocation surge. The files, filters, treatment of reserved ranges or meanings of “allocated” may have differed. Without the dated underlying files and their transformation rules, the discrepancy cannot be resolved from the two totals alone. The contemporary authors clearly perceived rapid growth, but that perception does not make unlike measurements interchangeable.

Recipient names do not repair the missing denominator

Assigning geography is harder than multiplying class counts. The early registers did not provide a standard country field beside every network. Some names explicitly identified a place or institution. Others described a project, experimental system, contractor or transnational network. A contact address could identify where administration occurred without identifying every country in which the network operated.

RFC 1166’s Class A entries included clearly non-US cases, among them RSRE in the United Kingdom, CAN-INET in Canada and JAPAN-A with a University of Tokyo contact. Earlier registers included University College London and transatlantic packet or satellite networks. This is enough to reject the claim that large-class assignments were exclusively American. It is not enough to produce a reliable country percentage.

A transatlantic satellite network resists assignment to a single country. A corporation may operate in several jurisdictions. A project name may outlive its original institutional location. Later registry records may reflect mergers, transfers, reorganisations or changed contacts. Present geography cannot be projected backward as original recipient geography without a documented chain.

Names also change the observation unit. Several entries may belong to one organisation; one entry may support several organisations or operating sites. The BBN Class C range is the clearest example of many network-number units under one name. Merit’s later use of network 35 across several autonomous systems illustrates the reverse problem: one classful network could participate in a distributed routing arrangement.

The absence of unsuccessful demand is more serious. Published registers predominantly show completed assignments. They do not disclose the full population of applicants. Missing observations may include:

requests returned for additional information;
requests granted at a smaller class than originally sought;
applications delayed or abandoned;
organisations directed to a provider or another registry;
networks that used private or non-unique numbering;
organisations that did not know the relevant procedure;
applicants deterred by gateway, connectivity or equipment requirements;
successful recipients whose original forms no longer survive.

Without this denominator, the snapshots cannot measure approval rates, delays, unequal access or applicant-level first-mover advantage. They cannot show whether technically similar applicants received different classes. They cannot establish that one organisation’s engineering capacity made success more likely.

The data can establish coarseness, concentration and the changing distribution of classful units. It can identify a mechanism by which durable early assignments might preserve later options. It cannot convert that mechanism into a measured social effect without matched requests and outcomes.

This limit changes the language of the conclusion. “Early recipients had better access” would require evidence about comparable applicants. “Administrators favoured capable incumbents” would require evidence about decisions and alternatives. The defensible claim is conditional: if an organisation received and deployed a large assignment before stricter published criteria, the cost of renumbering could allow it to retain an option set that a later applicant might not receive on the same terms.

That is plausible path dependence. It is not a quantified first-mover dividend.

Public criteria emerged as pressure accumulated

The incomplete early interface should not be confused with an absence of all criteria. The record shows some early eligibility rules and much more explicit later allocation guidance.

RFC 820’s research criterion tied number assignment to gateway readiness. It also recommended continuity when an experimental network became operational: if renumbering caused hardship, the network could retain its identifier while its administrative category changed. This was an explicit recognition that deployment created switching costs. It does not show that administrators anticipated a future market value. It shows that continuity already mattered operationally.

By 1990, RFC 1174 used scarcity language directly. Rapid growth and internationalisation made further delegation timely, and Class A and B identifiers were described as increasingly scarce resources requiring careful allocation. The document joined a capacity concern to an administrative one. A global applicant population depended on functions still centred in US institutions, while the number of networks and records was increasing.

The proposed response was controlled distribution rather than immediate abandonment of central authority. The Internet Registry would remain the principal registry and default where no delegated authority existed. Approved organisations could receive blocks and delegated responsibility. Copies of aggregate registration data would be distributed, while updates remained centralised.

RFC 1366, published in October 1992, turned the direction into more specific rules. Candidate regional registries were expected to be recognised in their geographic areas, stable, properly resourced and committed to common IANA and Internet Registry guidelines. The central functions retained responsibility for Class B space, with regional registries assisting in evaluation.

For Class B, RFC 1366 stated two criteria: a subnetting plan documenting more than 32 subnets and more than 4,096 hosts. It allowed case-by-case consideration where a block of Class Cs was technically unsuitable. For Class C, it proposed bitwise contiguous blocks sized according to need and a 24-month projection.

The criteria made some factors public while leaving room for judgment. “More than 32 subnets” depended on a proposed topology. “More than 4,096 hosts” depended on what counted as a host and whether the number described current deployment or credible growth. Technical unsuitability required explanation rather than automatic calculation.

The canonical period source RIPE-048, published on 1 August 1992, shows the developing European interface. It said the RIPE NCC handled requests from European organisations and that applicants would usually return the supplied material through an IP service provider or the RIPE NCC. It connected allocation to provider relationships and prospective external connectivity.

RIPE-048 stated that Class A and B numbers were scarce and required justification in terms of expected network size and structure. A Class A request required detailed technical justification and global review that could take several months. It advised using a reasonable set of Class Cs instead of a Class B where the network could be engineered that way, explicitly noting that this reversed earlier advice motivated by routing-table constraints.

The document referred to a separate one-page Class B information sheet, but the inspected RIPE-048 text does not reproduce that sheet. It would therefore be improper to attribute a detailed list of projected-host, subnet and utilisation fields to RIPE-048 itself. The direct support is narrower: expected size and structure, provider or connectivity context, Class C suitability, detailed justification for Class A and the possibility of a lengthy global review.

RFC 1466, published in May 1993, provides the detailed fields directly. A Class B applicant was expected to document more than 32 subnets and more than 4,096 hosts. The engineering plan had to explain why a block of Class Cs was unreasonable and include the number of hosts expected within 24 months and the number of hosts per subnet within that period. The plans were to remain confidential and be used to judge whether the application was justified. An applicant failing the test would receive a Class C block, while exceptions remained possible.

For Class C, RFC 1466 established a contiguous allocation ladder based on the subscriber’s 24-month projection:

Projected requirement	Default assignment
Fewer than 256 addresses	1 Class C
Fewer than 512	2 contiguous Class Cs
Fewer than 1,024	4 contiguous Class Cs
Fewer than 2,048	8 contiguous Class Cs
Fewer than 4,096	16 contiguous Class Cs
Fewer than 8,192	32 contiguous Class Cs
Fewer than 16,384	64 contiguous Class Cs

These thresholds used address requirements, not the 254-host practical capacity used in the opening example. That distinction reflects the document’s own allocation ladder and should not be silently “corrected” into a different convention.

The policy allowed adjustment for topology. An organisation with 600 hosts distributed equally across ten Ethernets might receive ten Class Cs, one per LAN, if it supported the deviation with an engineering plan. Registries could also request an explanation where failure to subnet Class C networks would consume excessive space.

The late-period decision interface was therefore more visible than the early one. Applicants knew that host totals, subnet plans, a 24-month horizon and Class C suitability mattered. They also knew that exceptions and registry judgment remained. The change was not from discretion to no discretion. It was from thin public criteria toward structured discretion.

Boundary cases prevent a morality tale

The aggregate measurements can support several simplistic stories if their limitations are ignored. The named cases are valuable because they weaken those stories without pretending to reveal undocumented motives.

The BBN range challenges the proposition that prominent incumbents invariably received one coarse class. In January 1983, “BBN local networks” accounted for 1,024 of the 1,042 Class C units in the source total. Four Class Bs would have provided the same raw numerical capacity with four classful units. Yet the register displayed the fine class in bulk.

This does not prove that administrators preferred fine-grained allocation for BBN. The original rationale is absent. The range may have supported testing, separate local networks, experimentation or internal administrative purposes. Its members may not all have appeared as independent global routes. The defensible finding is simply that institutional prominence did not mechanically map to one large-class assignment.

Bristol challenges a different claim. A European university received a Class B on 8 March 1991, after routing growth was evident and before the detailed 1992–1993 criteria were published. The confirmation rules out an absolute proposition that medium-sized legacy classes were closed to non-US universities.

It does not establish equal treatment. The application is missing, and there is no matched group of unsuccessful universities. The case proves that such an outcome occurred, not how often or why.

Merit’s network 35 provides an operational boundary case. RFC 1166 listed network 35 among the Class A allocations. RFC 1482, published in July 1993, showed it configured on the NSFNET T3 backbone so that routing announcements could be expected from as many as six autonomous systems.

That 1993 configuration does not establish the rationale for the original allocation. It does show that a single classful network number could later perform an aggregation-like operational role across a substantial routed environment. A retrospective utilisation test based solely on the count of active hosts would omit that routing function.

These cases constrain, rather than prove, the thesis. Large assignments were not necessarily irrational. Collections of small networks were not confined to marginal applicants. Non-US universities were not categorically excluded from Class B. A large network number could have a routing role beyond the number of hosts visible at one moment.

Falsification here works by removing universal claims. It does not supply the missing decision files. BBN, Bristol and Merit should be treated as boundary cases against simplistic explanations, not as windows into the administrator’s original reasoning.

Four pressures appeared on different clocks

The word scarcity can obscure more than it explains unless the constrained resource is named.

Finite address-space scarcity concerned the bounded 32-bit space and, more immediately, the limited inventories of Class A and Class B network numbers. A Class A encompassed (2^{24}) numerical local-address values and consumed one of roughly 126 ordinary network-number slots recognised in the period tables. RFC 1466 reported only about 11 Class A numbers as unassigned or unreserved under its policy definitions and reserved the upper half of the Class A space indefinitely.

Routing-state scarcity concerned memory, processing, protocol updates and operational stability. It could become acute while large portions of the numerical address space remained unassigned. Each separately visible Class C could add a destination to a router’s table. RFC 1118’s warning about nodes limited to roughly 700 networks and RFC 1338’s routing series show why one subnetted Class B could appear operationally cheaper than several smaller networks.

Applicant-level need was different again. The 300-host organisation did not experience the full IPv4 pool as abundant. It experienced one available class as 46 ordinary host addresses too small and the next as vastly larger than required. Two Class Cs solved capacity but introduced possible routing and coordination costs. The applicant’s scarcity was a lack of a well-fitting allocation unit.

Administrative attention concerned the ability to receive forms, ask questions, assess plans, reconcile records, coordinate delegations and return decisions. RFC 1174 linked further delegation to rapid growth and internationalisation. RFC 1466 said demand had increased significantly within two years and that allocation needed a more systematic approach. RIPE-048 warned that global review of a Class A request could take several months.

These pressures did not move together. Routing tables could grow rapidly even though millions of Class C network numbers remained theoretically available. A small applicant could encounter a severe class boundary while total numerical exhaustion remained distant. A central registry could face increasing workload even if each individual form was easy. A policy designed to conserve Class B numbers could deliberately impose more equipment or routing costs on applicants.

The separation also prevents causal shortcuts. The existence of a finite 32-bit space did not dictate a particular administrative regime. The class design determined the available units. Routing constraints altered their relative operational costs. Administrative institutions decided how to distribute authority and evaluate exceptions. Applicants supplied incomplete forecasts and chose which requests to make.

Scarcity was not one event. It was a set of mismatched constraints.

The feasible alternatives all carried costs

A period counterfactual should ask what could reasonably have been done with the protocols, equipment and institutions then available. It should not assume that an administrator in 1981 could solve the problem by writing a modern arbitrary prefix into a register.

Consider an organisation expecting 1,000 ordinary hosts. Four Class Cs offered:

[ 4 \times 254 = 1,016 ]

ordinary host addresses. One Class B offered 65,534. In address-conservation terms, four Class Cs were dramatically better. In a classful routing system, they could require four externally visible network entries. RFC 1118’s advice that a campus announce no more than two discrete networks made that cost material by 1989.

The first feasible alternative was to allocate multiple Class Cs and accept the additional network numbers. This required no new address format. It conserved numerical capacity and could accommodate equipment that did not subnet. Its costs included additional registration, configuration and potentially global routes. Future growth could trigger another request or renumbering.

The second alternative was to allocate one Class B and require internal subnetting. This conserved external routing state and gave the organisation considerable room for growth. Its costs were a much larger reservation of numerical address values and dependence on subnet-capable hosts and gateways. During a period of mixed 4.2BSD, 4.3BSD and other implementations, compatibility was an operational concern rather than an administrative fiction.

A third option was to allocate contiguous Class Cs in preparation for later aggregation. Contiguity helped preserve the possibility of representing several networks as one prefix once routing protocols and routers supported arbitrary network-and-mask information. Before such support, the classful system still interpreted the components as individual Class C networks. Contiguity alone did not make the routing entries disappear.

RFC 1338 made this dependency explicit. Its proposed assignment plan could give appropriately sized Class C blocks to medium organisations, but the routing benefit required inter-domain protocols to represent arbitrary network-plus-mask destinations. Multihomed organisations might still require more-specific advertisements. Deployment demanded software changes, operational coordination and agreement among the NIC, IANA and service providers.

Earlier subnetting was another feasible response, but it solved internal topology within an assigned class. It did not reduce the size of the class granted. A subnetted Class B still placed 65,536 numerical values under one assignment. Dividing a Class A among unrelated organisations would have required a shared routing and administrative layer or classless external support that the original two-level architecture did not provide.

Transparent bridging could make several LANs appear to be one network, but it moved complexity into a larger link-layer domain. It did not eliminate failure, performance or coordination costs. It was not a universal substitute for routed subnets.

Regional or provider-based delegation could distribute administrative attention without changing the address format. Blocks of Class C numbers could be delegated to organisations closer to applicants. This could shorten communication paths, improve local-language service and shift routine review away from the central registry.

Delegation also created costs. The central and regional bodies needed consistent records, common criteria and reliable update procedures. Someone had to decide which regional institution possessed legitimacy, resources and neutrality. RFC 1366 and RFC 1466 devoted substantial attention to those qualifications because delegation transferred consequential authority rather than merely postal work.

Another possibility was to require more frequent renumbering or reclamation. That might have recovered unused capacity, but it would have imposed costs on hosts, gateways, access controls, documentation, correspondent networks and operational staff. RFC 820’s continuity recommendation shows that renumbering hardship was already recognised. A rule that ignored those costs would conserve address values by exporting disruption to operators.

Each alternative therefore priced scarcity differently:

Multiple Class Cs conserved address values but could consume routes and administrative transactions.
A subnetted Class B conserved external state but consumed a coarse address unit and required compatible equipment.
Contiguous Class Cs preserved future aggregation options but did not provide immediate classless routing.
Regional delegation distributed review but required coordination, legitimacy and record consistency.
Renumbering recovered capacity at the cost of operational continuity.

The observed system was not the only technically possible system. It was one response to costs that could not all be minimised at once.

What changed, what persisted and what cannot be inferred

The evidence supports a divided allocation of causation.

Classful design created the discontinuities. The 32-bit address could have been divided in other ways, but the deployed architecture offered fixed A, B and C boundaries. For a requirement just above 254 ordinary hosts, there was no native class offering a modest increase. That was a protocol property.

Routing and hardware made the discontinuities economically and operationally significant. Several Class Cs could conserve address values while increasing network-number and routing burdens. A subnetted Class B could conserve external state while requiring suitable software and consuming a much larger allocation. These were constraints visible to contemporary engineers.

Administrative policy determined how the system responded. Early published material contained eligibility and gateway-readiness criteria but does not reconstruct a complete class-selection interface. By 1990–1993, the public record explicitly discussed scarcity, delegation, host and subnet thresholds, 24-month projections, engineering plans and exceptions. Judgment became more structured without disappearing.

Applicant-level outcomes remain underdetermined. The available snapshots lack complete requests, refusals, alternatives, utilisation records and decision explanations. They cannot establish that technically capable applicants enjoyed generally superior access or that administrators systematically favoured incumbents. They also cannot establish that large early allocations were justified in every case.

The snapshots do show a plausible mechanism of path dependence. Once a recipient deployed an assignment, renumbering imposed costs. RFC 820 explicitly recognised hardship as a reason to preserve a number when an experimental network became operational. A large early assignment could therefore remain in place after the criteria for comparable new assignments tightened.

The benefit should be described as an option, not a measured dividend. The recipient could expand internally, continue presenting a classful destination, renumber less often or retain capacity whose later acquisition became difficult. Whether a particular recipient used those options, deserved them or anticipated their later importance is a separate empirical question.

Modern evidence confirms persistence without resolving early motives. A 2017 study of reported IPv4 transfers found that legacy space represented 63.82 per cent of the address space in its reported-transfer sample. The same research showed why later records must be interpreted cautiously: routing changes can reflect provider changes, reassignment, organisational restructuring or complex address management rather than a sale.

That result is relevant only as a narrow check. It shows that pre-registry-era allocations persisted long enough to participate materially in later redistribution. It does not show why a class was selected in 1983, whether the original applicant supplied an accurate forecast, whether the allocation was fair, or what an early administrator intended.

Present monetary value is still further removed from the early decision. A current price applied to all addresses inside a legacy block would ignore unrouted space, policy restrictions, transaction costs, fragmentation, operational dependencies and the distinction between registration and control. More importantly, it would substitute later scarcity for contemporary motive.

The historical conclusion is therefore bounded but consequential. Classful IPv4 converted technical granularity into an administrative decision boundary. Routing limits sometimes made the larger unit defensible. Equipment limits sometimes made subnetting costly. Early applicants and administrators operated with forecasts that cannot now be reconstructed from completed registers. Later policies made the balancing criteria more explicit and shifted work toward regional and provider-based institutions.

Administrative scarcity was born in the gap between 254 and 65,534, but not because the gap dictated one answer. It was born because every available answer imposed costs on a different party or system, and someone had to decide which cost to accept.

The Classful Address Era and the Birth of Administrative Scarcity