Summary
- RFC 791 fixed each IPv4 source and destination address at 32 bits and initially interpreted ordinary unicast addresses through three classes; it did not prescribe regional registries, demand forecasts, utilisation tests, provider dependence, audits, sanctions, or appeals.
- The nominal (2^{32}), or 4,294,967,296, possible 32-bit values were never one pool of assignable public host addresses. Class structure, special values, reservations, allocation holdings, routing visibility, and actual use created different denominators that cannot be combined.
- From 1993 to 1996, published guidelines selected consequential rules: 24-month forecasts and Class B thresholds in RFC 1466; topology-based aggregation in RFC 1519; and slow-start allocations, provider hierarchy, utilisation tests, audits, address return, and parent-registry appeals in RFC 2050.
- Conservation and aggregation answered genuine engineering dangers, especially classful waste and routing-table growth. The political element lay not in inventing scarcity, but in identifiable institutions choosing among feasible ways to distribute its costs, authority, exceptions, and remedies.
- Public allocation records show successful outputs, not the requests, refusals, revisions, delays, or informal guidance that produced them. The regime's text and technical rationale can be reconstructed more confidently than its full distributional effect.
Architecture set the boundary; administration selected the test
Two dated records establish the essential distinction.
In September 1981, RFC 791 specified a Source Address field and a Destination Address field, each 32 bits wide. It defined an Internet address as four octets and divided its initial ordinary unicast interpretation among Class A, Class B, and Class C formats. A Class A address used one class-identifying bit, seven network-number bits, and 24 local-address bits. Class B used two class bits, 14 network-number bits, and 16 local-address bits. Class C used three class bits, 21 network-number bits, and eight local-address bits. Those were protocol features, stated in the addressing discussion and header specification. RFC 791, September 1981, sections 2.3 and 3.1, pages 7 and 11–12
In May 1993, RFC 1466 recommended that a registry size contiguous Class C grants from a subscriber's projection of required end-system addresses over the following 24 months. A projection below 256 addresses mapped to one Class C network number; below 512 to two; below 1,024 to four; and so on, up to 64 contiguous Class C network numbers for a projection below 16,384. For a Class B, the document said an applicant should show more than 32 subnets and more than 4,096 hosts, supported by an engineering plan covering the next 24 months. RFC 1466, May 1993, sections 4.2.1 and 4.3, pages 6–8
RFC 1466 was Informational. Its status notice expressly said that it did not specify an Internet standard. Elise Gerich authored it; the abstract recorded general support for its recommendations from the Federal Engineering Planning Group acting for the Federal Networking Council, the co-chairs of the Intercontinental Engineering Planning Group, and RIPE. That combination is evidence of an authored recommendation with institutional support. It is not evidence that every registry immediately implemented every threshold, that an IETF standards action compelled the policy, or that every affected network agreed with it. RFC 1466, status, abstract and acknowledgements, pages 1 and 9
The protocol and the guideline answered different questions. A 32-bit field defined the outer mathematical space. It did not select a forecast horizon, an allocation hierarchy, a utilisation formula, a geographic region, an audit power, or an appeal route. The rules may have been prudent responses to genuine constraints, but they were not derivable from the header.
That is the bounded meaning of political here. It identifies a decision by a named authoring or implementing institution among technically and administratively plausible arrangements, where the selection shifted authority or imposed different documentation, delay, provider-dependence, routing, renumbering, or review costs. It does not mean that scarcity was fabricated, that the actors were partisan, or that their choices were corrupt. It asks who selected the rule, which alternative parameter could have been selected under period conditions, and where the resulting burden or authority fell.
One address space produced several incompatible denominators
The familiar arithmetic is exact:
[ 2^{32}=4,294,967,296 ]
Its unit is nominal binary values per 32-bit source or destination address field. It is not a count of assignable public hosts, organisations, customer connections, registry grants, routed prefixes, or applications for space.
The class bits immediately divided that mathematical space. The raw Class A network-number field contained (2^7=128) bit patterns; Class B contained (2^{14}=16,384); and Class C contained (2^{21}=2,097,152). Administrative accounting did not treat every raw pattern as an ordinary network number. RFC 1466's May 1992 table instead counted 126 Class A, 16,383 Class B, and 2,097,151 Class C network numbers. Those figures are classful network-number populations, not address values or organisations.
The table also recorded 49 allocated Class A network numbers, 7,354 allocated Class B network numbers, and 44,014 allocated Class C network numbers as of May 1992. These are successful entries in a particular administrative table. They neither reveal the number of applicants nor measure how many addresses were occupied, announced, reachable, or requested. RFC 1466, section 3, Table 1, page 3
A defensible denominator audit therefore separates the following populations.
| Population | Date, unit and administrative level | Direct source and measured meaning | Exclusions and limits |
|---|---|---|---|
| Nominal address values | September 1981; (2^{32}=4,294,967,296) bit patterns per source or destination field; protocol level | RFC 791 sections 2.3 and 3.1 define four-octet addresses and the two 32-bit header fields | Not assignable public hosts; does not deduct class markers, special meanings, reservations, or administrative holdings |
| Raw classful network patterns | September 1981 interpretation; 128 Class A, 16,384 Class B, and 2,097,152 Class C network-number bit patterns; protocol-format level | Arithmetic from RFC 791's 7-, 14-, and 21-bit network-number fields | Raw patterns are not RFC 1466's administratively counted network totals |
| Administratively counted classful capacity | May 1992 table; 126 Class A, 16,383 Class B, and 2,097,151 Class C network numbers; top-level registry accounting | RFC 1466 Table 1's stated network-number populations | Not addresses, applicants, organisations, routes, hosts, or observed use |
| Recorded allocated classful networks | May 1992 table; 49 Class A, 7,354 Class B, and 44,014 Class C network numbers; top-level allocation output | RFC 1466 Table 1's allocated rows | No request, refusal, withdrawal, delay, assignment, route, or utilisation denominator |
| Administratively reserved Class C-form space | May 1993 policy version; 208.0.0.0–223.255.255.255 withheld until further notice; IANA and central Internet Registry level | RFC 1466 section 3 states that this range would remain unallocated and unassigned | A policy reserve is not a protocol impossibility, and release under period conditions is not assumed safe |
| Dated top-level IANA view | IANA file collected 14 September 2005; address volume expressed in /8 equivalents; IANA-to-RIR level |
CAIDA reconstructed IANA allocations and stated that 150 of the 256 /8-equivalent positions had been allocated to RIRs at the study date |
(256-150) is not a valid residual public pool because special, reserved, legacy, and non-RIR categories are not thereby removed; no residual value is asserted here |
| RIR holding | RIR WHOIS snapshots dated 31 August 2005; unassigned address volume within IANA-associated RIR space, measured in addresses or /8 equivalents; RIR level |
CAIDA calculated working pools after normalising four RIR datasets | No AfriNIC snapshot; no single holding value is extracted here, so this remains an unquantified conceptual category in this article |
| ISP allocation | 31 August 2005 reconstruction; address-volume blocks first issued by a covered RIR to an ISP or other customer; RIR-to-provider level | CAIDA's “first allocation” series distinguishes the first downstream registry occurrence | Not an end-enterprise assignment, route, announcement, use observation, or request population |
| End-enterprise assignment | 31 August 2005 reconstruction; most-specific registry row by address volume; provider or registry to end-user level | CAIDA's “most specific assignment” series | Registry-row specificity does not count connected hosts, interfaces, customers, or operational occupation |
| BGP-visible advertised route | January 1992: 4,526 routes; December 1992: 8,561 routes; MERIT-sourced routing-table observations | RFC 1519 Table I reports advertised routes by month from a specific routing-data source | Not allocated addresses, unique organisations, requests, all routers, or global utilisation |
| Observed use | No common value measured by the cited 1981–1996 records; possible unit would require one specified instrument, population and date | An unquantified conceptual category required to separate connected hosts or another observation from administrative records | Hosts, interfaces, customers, responding addresses and assignments cannot be combined into one utilisation numerator |
| Applicant demand | No complete population measured in the cited public records; unit would be requests by defined applicant class, rule version, region and period | An unquantified conceptual category absent from allocation output | Must include unsuccessful, revised, withdrawn, discouraged and never-filed cases before applicant incidence can be estimated |
The distinctions are not semantic fussiness. Each row answers a different question. A top-level allocation reduces one administrative pool without showing that the allocated space is announced. A route can cover a large block with few occupied endpoints. Several routes can represent one allocation. An assignment can remain unused, while one host can have several addresses or interfaces. RFC 791 itself contemplated hosts with multiple physical interfaces and multiple logical Internet addresses. A registry ledger and a routing table cannot be merged merely because both contain prefixes.
The period's ordinary host-identifier convention created yet another population. RFC 1519 described a Class C network as supporting at most (2^8-2=254) ordinary host identifiers and a Class B as supporting at most (2^{16}-2=65,534), after excluding the all-zero and all-one local values used under the cited convention. These are potential ordinary identifiers inside one network, not counts of connected hosts. RFC 1519, Proposed Standard, September 1993, section 1, pages 1–2
Suppose, only for scale, that one identifier were required for each of 600 connected hosts. A Class B's 65,534 ordinary identifiers would provide (65,534/600=109.223) times the stated requirement, leaving (65,534-600=64,934) ordinary identifiers outside that immediate requirement. The calculation demonstrates classful granularity; it does not prove that a real 600-host applicant needed no reserve, had a flat topology, or could operate an arbitrary classless block.
RFC 1466 offered a different 600-host example. If 600 hosts were divided equally across ten Ethernets and the topology made a shared Class C block difficult, the subscriber could receive ten Class C network numbers, one per Ethernet, subject to an engineering justification for deviating from the default power-of-two table. The unit there was Class C network numbers, not 600 addresses drawn from a free pool. RFC 1466, section 4.3, page 8
Later evidence requires equal care. CAIDA's IPv4 consumption study was constructed from an IANA file collected on 14 September 2005 and WHOIS snapshots taken on 31 August 2005 for ARIN, APNIC, LACNIC, and RIPE. It lacked an AfriNIC snapshot. CAIDA removed format differences to create a shared representation and restricted each RIR's rows to space associated with that registry in the IANA file, reducing duplicate appearances caused by migration and cross-referencing. It combined migrated legacy material into a separate “various” set. CAIDA, “IPv4 Consumption Rates,” Methodology and Caveats
Its figures used address volume, commonly expressed as equivalent /8 quantities. They distinguished IANA allocations, the first downstream registry occurrence, and the most-specific assignment found in the data. CAIDA expressly said that the graphs showed allocations, not announcements or reachability. It also explained that an IANA clean-up assigned August 1993 to many legacy records for which precise historical dates were unavailable. Those are backfilled administrative dates, not recovered transaction dates. CAIDA, Methodology, Caveats and Figures 1–7
The reconstruction is useful for showing why administrative levels must be separated. It is not contemporaneous evidence of applicant experience in 1993. It does not measure requests, refusals, revisions, routes, announcements, reachable hosts, occupied interfaces, motive, or policy causality.
Richter, Allman, Bush, and Paxson's A Primer on IPv4 Scarcity is later still. The paper was submitted on 10 November 2014, revised on 27 February 2015, and published as an editorial contribution in ACM Computer Communication Review 45(2) in April 2015. It is a valuable retrospective synthesis and a source lead for technical, institutional, and exhaustion-era developments. It cannot establish what an actor knew in 1981–1998, how a period applicant experienced a registry, whether a mechanism was deployed, or whether contemporaries held a later market or property doctrine. Richter et al., “A Primer on IPv4 Scarcity,” publication record
The outer mathematical boundary was singular. Operational scarcity was not. It appeared in classful network-number counts, reserved ranges, registry holdings, assignment units, and router state, each with its own date and denominator.
Classful waste and routing pressure were genuine
The first immediate pressure came from granularity. An organisation requiring more than 254 ordinary host identifiers did not have a native classful allocation unit proportionate to a requirement of 300, 600, or 4,000. A Class B could be far too large. A collection of Class Cs could be closer in address volume but harder to manage and, before effective aggregation, more expensive for the global routing system.
Subnetting helped inside an existing classful network. RFC 950, an August 1985 standards-track specification, defined an address mask that divided the local-address field into subnet and host portions. An organisation could use one externally recognised network number across multiple internal subnets rather than advertise each internal cable as an independent network. It did not by itself let a registry issue arbitrary globally routed prefix lengths to an Internet whose inter-domain machinery still relied on class interpretation. RFC 950, August 1985, section 2.1, pages 4–6
The second pressure was the forwarding table. Replacing one former Class B grant with 16 separately advertised Class C networks could preserve a Class B network number while adding 16 routing entries where aggregation was unavailable. Address conservation and routing conservation could therefore point in opposite directions.
RFC 1519, published as a Proposed Standard in September 1993, described three problems: rapid depletion of Class B network numbers, routing-table growth beyond the capability of available software and routers, and eventual exhaustion of the 32-bit space. Its immediate strategy was CIDR: issue more appropriately sized contiguous blocks, align distribution with topology, and advertise aggregates when protocol support and connectivity permitted. RFC 1519, status and sections 1–3, pages 1–9
Its quantitative argument needs both the exact table and the rounded prose.
Table I, sourced to MERIT, recorded 4,526 advertised routes in January 1992 and 8,561 in December 1992. Section 3.3.2 instead described the January NSFNET routing database as containing “approximately 4700” entries and the December table as containing 8,500. It said the historical table had doubled on average every ten months between 1988 and 1991 and published a projection of approximately 30,000 entries two years after the January 1992 baseline. RFC 1519, Table I and section 3.3.2, pages 7–9
That projection does not follow from the stated rounded inputs:
[ 4,700\times 2^{24/10}=24,806.75 ]
Using the exact January Table I observation gives:
[ 4,526\times 2^{24/10}=23,888.37 ]
Neither result is approximately 30,000 under ordinary rounding. The article can preserve 30,000 only as the RFC authors' published, unreconciled projection. The source does not explain the roughly 5,193-entry difference between 30,000 and the rounded-input result. It would be improper to invent a different baseline, growth interval, or hidden adjustment to close the gap.
The December comparison is more straightforward. Table I's observed unit was 8,561 advertised routes in December 1992. Section 3.3.2 rounded that to 8,500 and compared it with more than 9,400 predicted by an earlier curve. The authors said they could not tell whether the lower observation represented a meaningful change in growth. These were observations and forecasts from the MERIT/NSFNET context, not a census of every router or a physical limit at which the Internet would fail.
The RFC also considered the effect of issuing four to 16 Class C routes where a Class B might previously have been used. It conditionally projected that the routing table could exceed 10,000 entries within six months and 20,000 within a year. Those were scenario results based on separately advertised Class C networks, not observed outcomes. Aggregation was intended to prevent precisely that multiplication.
The engineering logic was strong. If customers connected through one provider received contiguous subsets of the provider's block, the provider could advertise one less-specific route. Ten independently routed customer blocks might require ten globally visible entries; ten topology-aligned customer blocks could, subject to exceptions and correct operation, sit behind one aggregate. The exact saving depended on multihoming, routing policy, failures, filters, and whether more-specific routes still had to be propagated.
The transition was not automatic. RFC 1338, an Informational proposal published in June 1992 and later obsoleted by RFC 1519, warned that both the new addressing plan and changes to inter-domain routing protocols were required. It stated that routing tables could grow very rapidly in the interval between deployment of topology-oriented allocations and deployment of compatible protocols. RFC 1338, June 1992, section 2.1, page 4
BGP-4 supplied a specification for carrying classless prefixes and aggregating routes, but publication status must not be confused with deployment. RFC 1654 was a standards-track BGP-4 specification in July 1994. RFC 1771, also standards track, superseded it in March 1995 and described support for IP prefixes, removal of the network-class concept within BGP, and route and AS-path aggregation. RFC 1654, July 1994, status and sections 1–2, pages 1–2; RFC 1771, March 1995, status and sections 1–2, pages 1–2
Those publications establish specification status and documented capability. They do not establish how many routers ran BGP-4 on a given date, which networks exchanged classless routes, how much of the table was aggregated, or whether adoption was universal by 1998. Without a named routing snapshot series, observation date, population, and vantage point, no numerical deployment rate or “established by 1998” claim is justified.
The forecast rule allocated uncertainty
RFC 1466's Class B rule exposes the institutional choice most clearly. Its stated criteria asked for more than 32 subnets and more than 4,096 hosts. The applicant also had to show why a block of Class Cs was unreasonable and provide expected host and subnet counts for the next 24 months. If the plan did not warrant a Class B, the stated outcome was a block of Class Cs. An applicant that failed the numeric criteria but could not use Class Cs could make an engineering case. The document called the thresholds suggested criteria rather than a protocol invariant. RFC 1466, section 4.2.1, pages 6–7
The immediate technical objective was conservation of Class B network numbers. Under the period convention, one Class B exposed 65,534 ordinary host identifiers. Granting that unit to a network with a much smaller requirement could strand a large share of its capacity. The subnet plan tested whether the applicant needed the topology a Class B could accommodate rather than simply preferring its convenience.
RFC 1466 acknowledged the burden. It said restrictions on Class B allocations could require some organisations to expend additional resources using multiple Class C network numbers. The document regarded that cost as unfortunate but necessary to pursue conservation. This is unusually direct evidence of cost incidence: the authoring recommendation selected a conservation rule and identified extra engineering expenditure by affected applicants as a consequence. RFC 1466, section 4.2, page 6
The 24-month horizon was nonetheless a parameter. The Informational RFC documented why forecasts were required, but it did not demonstrate that 24 months uniquely minimised total address waste, processing cost, delay, or forecast error. A 12-, 18-, or 36-month test would be an analyst-constructed variation unless a direct period proposal were produced. Such variations are administratively conceivable because the same applicant could submit the same categories of engineering evidence over a different horizon. Their practical performance remains unknown: a shorter horizon would reduce exposure to optimistic growth but increase repeat applications, while a longer horizon could reduce transaction frequency at the cost of larger forecast error.
Classless allocation was a more technically grounded alternative by 1993, but only within limits. RFC 1338 had proposed contiguous provider blocks in June 1992, and RFC 1519 specified the CIDR assignment and aggregation strategy in September 1993. Their own warnings show the assumptions required: registries had to allocate on suitable boundaries, providers had to maintain topology-aligned blocks, and inter-domain protocols and routers had to support arbitrary network-and-mask pairs. Before those conditions were sufficiently implemented, issuing finer blocks could multiply routes rather than reduce them.
RFC 2050 shifted the forecast design in November 1996. It separated ISP allocations from end-enterprise assignments. Section 2.1 said that new ISPs would receive a minimal allocation based on immediate requirements. Later allocations could grow after the ISP supplied utilisation verification, and additional space was intended to support approximately three months of downstream assignments. The projected customer base was said to have little effect; demonstrated requirements governed. RFC 2050, BCP 12, November 1996, section 2.1, pages 4–5
The famous 25 and 50 per cent figures belonged elsewhere. They appeared in section 3.1, within the assignment framework for end enterprises: a 25 per cent immediate utilisation rate and a 50 per cent utilisation rate within one year. Section 3.6 defined the numerator as the number of hosts connected to the network and the denominator as the total possible hosts on that network. The one-year criterion therefore meant that connected hosts were expected to reach at least 50 per cent of the network's possible host population within that horizon. It was not a ratio of customers to addresses, assigned addresses to allocation size, interfaces to addresses, or downstream assignments to an ISP allocation. RFC 2050, sections 3.1 and 3.6, pages 7 and 9
The distinction changes the institutional analysis. End enterprises faced a connected-host utilisation test against possible hosts on their proposed network. ISPs faced slow start, verified downstream use, and a replenishment quantity intended to cover about three months of additional assignments. Combining them would create a fictitious common metric.
Both designs placed forecast uncertainty somewhere. A longer initial grant exposed the common pool if demand did not materialise. A smaller initial grant increased the importance of registry responsiveness and the applicant's ability to document repeated growth. The RFCs establish the selected rules and their stated objectives. They do not supply processing-time distributions, initial requested amounts, revision histories, or evidence that one applicant class systematically bore more delay.
Hierarchy converted topology into dependence
RFC 1466 proposed dividing portions of the Class C-form number space into large geographic blocks and delegating primary allocation responsibility to qualifying regional registries. It described the division as “primarily an administrative division” intended to support distributed registration. It favoured one regional registry at that level, expected the organisation to be recognised and adequately resourced, and required commitment to IANA and central Internet Registry guidelines. The central registry remained available to serve a subscriber if necessary, although it could refer the subscriber to the regional body. RFC 1466, sections 2, 3 and 4.3, pages 2–4 and 7
The surrounding plan linked distributed administration with potential aggregation. Geographic blocks could reduce central workload and might support coarse summaries where geography and topology aligned. Neither relationship was guaranteed. A continent was not encoded in the IPv4 header, and physical or provider topology did not necessarily follow a regional boundary.
The choice of a single recognised regional registry concentrated interpretive authority over local allocations, evidence and exceptions. A shared database with overlapping registries, or a general applicant choice between central and regional decision-makers, would be an analytical alternative rather than a documented period proposal in the sources used here. Its feasibility would assume timely database coordination, reliable uniqueness checks, common allocation rules, and a way to prevent competing grants. Those assumptions were administratively demanding in 1993. The alternative is useful for locating authority, not for claiming that overlapping registries would have performed better.
RFC 1519 moved the hierarchy toward provider topology. It recommended that most, if not all, network numbers be distributed through service providers. Its engineering rationale was direct: addresses taken from a provider's block could be represented by the provider's aggregate, whereas independently located blocks often required more-specific routes. The document also argued that distributed allocation reduced the bureaucratic burden on the central numbering authorities. RFC 1519, sections 2.2 and 3, pages 5–8
RFC 2050 described a three-level registry system: IANA, regional Internet registries, and local Internet registries. Within the ISP framework, an ISP exchanging routes at multiple locations without default routing could seek space directly from its regional registry. Other ISPs were told to request space from an upstream provider. Direct regional access was associated with multihoming or connection to a major neutral exchange, which the RFC defined as connecting four or more unrelated ISPs. RFC 2050, sections 1.1 and 2.1, pages 3–4
The same section encouraged providers to treat customer assignments as loans for the duration of connectivity. When a customer changed provider, it recommended return of the old addresses and renumbering into the new provider's space, with sufficient transition time before reuse. This was a routing strategy with a switching-cost consequence. Provider-derived space improved the opportunity for aggregation; continuity of the customer's addresses became dependent on the provider relationship.
The costs were already recognised. RFC 1900, an Informational statement by the Internet Architecture Board in February 1996, said organisations that failed to renumber after changing providers could face limited connectivity, extra cost to support the resulting routing overhead, or both. Its title, Renumbering Needs Work, captured the state of the technique. It called for development and deployment of mechanisms to make changes easier; it did not report that renumbering had become cheap or routine. RFC 1900, February 1996, section 1, pages 2–3
The named decision-makers and implementers were RFC authors, IANA and registry authorities, regional and local registries, providers that assigned space, and transit networks that accepted or filtered routes. The feasible period alternative was not unlimited portable addressing. It was a different balance: more direct allocations would reduce some customer renumbering dependence but, absent reliable aggregation or route-acceptance coordination, could add globally visible prefixes. The surviving record proves the direction of the trade. It does not quantify how many customers renumbered, how many retained old routes, what they paid, or how consistently providers enforced return.
Audit power existed on paper; its practice remains unmeasured
The third institutional choice concerned verification and consequence.
RFC 1466 allowed the central Internet Registry to receive accounting and engineering plans from delegated regional allocations and to audit those plans for consistency with the guidelines. Exceptions to the Class C sizing criteria were to be decided case by case. The document did not provide an exception register, a standard response period, a published burden of proof, or an independent reviewer. RFC 1466, sections 4.2.2 and 4.3, pages 7–8
RFC 2050 described a more extensive body of evidence. A registry could require subnet masks, host counts, topology, routing plans, deployment schedules, prior assignments, and corroboration. Previous space held by divisions or subsidiaries under a common parent could be considered at enterprise level. Requests were handled case by case, with routing efficiency among the relevant considerations. RFC 2050, sections 3.2–3.5, pages 8–9
Section 4 stated that all address requests were subject to audit and verification by any means the regional registry considered appropriate. If an assignment was found to rest on false information, the registry could invalidate the request and return the assigned addresses to the free pool. Section 3.1 separately stated that an address remained valid while the qualifying criteria continued to be met and reserved an invalidation power when the need no longer existed. Section 2.1's return recommendation applied to provider-derived customer addresses when connectivity ended. These were related but distinct authorities: false-information invalidation, continuing-need review, and provider-change return. RFC 2050, sections 2.1, 3.1 and 4, pages 4–5, 7 and 10
The text also supplied hierarchical review. Section 6 allowed an organisation dissatisfied with an assigning registry to appeal to the parent registry. Relevant documentation was to be made available, and further appeal could move up the chain to IANA. Each registry was expected to document its appeal process. The reviewer remained within the same registry hierarchy; the RFC did not create an external tribunal. RFC 2050, section 6, page 11
These provisions authorised enforcement and review. They do not demonstrate practice. No cited file establishes how often an audit occurred, what methods were used, whether applicants received notice or a cure opportunity, how forecast error was distinguished from misrepresentation, how often addresses were returned, or whether an appeal altered an outcome. The text cannot show consistency across registries or individual cases.
Several procedural variations are conceivable under 1996 technology because they change administration rather than packet formats: written reasons for exceptions, a defined audit protocol, a notice-and-cure period, anonymised statistics, or review by officials outside the original decision chain. They are analyst-constructed parameters unless a dated proposal is produced. They would require staff, recordkeeping, confidentiality controls and agreed authority. Their costs and effects cannot be estimated from the RFC alone.
The institutional choice was therefore real but bounded. RFC 2050 gave regional registries discretion over verification and stated consequences, while placing review in the parent chain. That design could deter false claims and preserve address records. It also concentrated fact-finding, exception and enforcement authority. Evidence that the authority existed is strong; evidence about its invocation and distributional effects is absent.
The RIPE record proves less than a grant file would
The RIPE episode provides evidence of delegated operation, but not a complete allocation decision.
RIPE-062, RIPE NCC Internet Numbers Registration Procedures, version 0.5 dated July 1992, appeared as Appendix A to the RIPE NCC's first quarterly report. It said the RIPE NCC had acted since 1 May 1992 as a delegated registry for European Internet network numbers. Its procedure was to provide numbers to service providers and national or local coordination bodies rather than directly to individual organisations. It allowed service providers to request Class B network numbers one at a time and required justification based on the organisation's size, existing network, expected growth, and inability to use a Class C block. RIPE-062, version 0.5, July 1992, page 25 and following
RFC 1466 section 3 later recorded two narrower facts. RIPE NCC had already received the Class C network-number interval from 193.0.0 through 193.255.255 before adoption of the RFC's proposal, and it had agreed to allocate within that interval under RFC 1466's guidelines. RFC 1466, section 3, page 3
The interval contains (2^{16}=65,536) /24-sized Class C network numbers. Expressed as the later CIDR interval 193.0.0.0/8, it covers (2^{32-8}=16,777,216) nominal address values. The first number counts Class C network-number units; the second counts binary values covered by the interval. Neither measures connected hosts, downstream grants, announcements, use, or the amount RIPE NCC requested.
The surviving records do not provide the underlying request, a formal grant instrument, a decision memorandum, alternative block sizes considered, negotiated conditions, or an exact grant date. RIPE-062 proves a delegated procedure. RFC 1466 proves prior possession of the 193.* block and agreement to use the new guidelines. Distributed administration and potential aggregation were objectives of the surrounding policy plan; they cannot be asserted as the documented motive or negotiated condition of this particular grant.
The record also contains no appeal or review file concerning the delegation. It supports a registry-level finding that delegation was operating by 1992. It cannot support an applicant-level conclusion about refusal, unequal treatment, delay, or the incidence of a threshold.
The technical responses arrived in stages
The period did not offer one fully formed substitute for rationing. It offered partial responses with different statuses, prerequisites and cost transfers.
| Date and historical status | Response | Constraint addressed | New cost, authority or evidence limit |
|---|---|---|---|
| August 1985; RFC 950 standards-track specification | Subnetting within a classful network | Internal address organisation and reduction of separately exposed local networks | Required compatible hosts and gateways; did not establish arbitrary global prefix allocation |
| June 1992; RFC 1338 Informational proposal | Provider blocks and supernetting | Class B granularity, central allocation load and routing-table growth | Address plan could begin, but useful aggregation required inter-domain protocol changes; transition could increase routes |
| September 1993; RFC 1519 Proposed Standard | CIDR allocation and aggregation strategy | Finer allocation granularity and default-free route growth | Required classless routing implementation, aligned allocations, provider cooperation and longest-match behaviour; specification did not prove deployment |
| March 1994, revised February 1996; RFC 1597 then BCP 5/RFC 1918 | Reusable private address space | Demand for globally unique addresses inside enterprises | Private hosts lacked direct external network-layer connectivity; movement between private and public space changed addresses, DNS and configuration |
| May 1994; RFC 1631 Informational preliminary design with prototypes | Network Address Translation | Reuse of internal values and reduced public-address demand at stub borders | Added state, obscured end-to-end identity and required application-aware translation where payloads contained addresses |
| July 1994 and March 1995; standards-track RFC 1654 then RFC 1771 | BGP-4 specifications | Carriage and aggregation of classless inter-domain prefixes | Publication established specifications, not installed population or operational adoption |
| December 1995; standards-track RFC 1883 | IPv6 with 128-bit addresses | Long-term architectural limit and addressing hierarchy | Required a new protocol stack and transition; specification did not make IPv6 an immediate substitute for IPv4 allocations |
| February 1996; RFC 1900 Informational | Renumbering improvement agenda | Provider changes and preservation of topology-based aggregation | Documented that renumbering still needed work and could otherwise cause limited connectivity or extra routing cost |
| November 1996; BCP 12/RFC 2050 | Slow start, verified utilisation, provider hierarchy, return and invalidation authority | Conservation, routability and registration accuracy | Increased registry judgement and repeated reporting; supplied authority but no invocation-frequency dataset |
| November 1996; RFC 2050 future condition, not observed deployment | Larger or more dynamic router tables and alternative aggregation methods | Potential relaxation of routing-state constraints | The RFC left future review open; it supplied no dated hardware population or measured capacity trend |
Private space illustrates the difference between specification and substitution. RFC 1918, BCP 5 in February 1996, reserved three blocks for private internets. It required an enterprise to decide which hosts did not need external network-layer connectivity. Moving a host between private and public status involved changing its IP address, relevant DNS entries, and configuration files on other hosts that referred to the address. Private routing information was not to propagate across enterprise boundaries, and private DNS references required containment. RFC 1918, February 1996, sections 2–5, pages 3–7
NAT was more than a concept by May 1994 but less than a proven universal solution. RFC 1631 was Informational and described a preliminary design. Section 3 explained that applications carrying an IP address in their data could fail unless the translator recognised and rewrote the content; encryption could make that impossible. Section 4 identified experimental implementations in KA9Q software and a Cray Communications router, tested with Telnet and FTP, and said the prototypes demonstrated transparency only within the paper's stated limitations. RFC 1631, May 1994, sections 3 and 4, pages 6–9
IPv6 changed the architectural denominator. RFC 1883, a standards-track specification published in December 1995, increased the IP address size from 32 to 128 bits. It did not replace installed IPv4 hosts, routers, applications or operating procedures on publication. For a registry handling an IPv4 request in 1996, IPv6 was a specified successor, not evidence that the immediate IPv4 allocation problem had disappeared. RFC 1883, December 1995, status and section 1, pages 1 and 3
Reclamation also had stages. RFC 2050 recommended return of provider-derived addresses after connectivity ended and authorised invalidation in specified circumstances. It did not contain a dataset of recovered blocks or establish how readily operational networks could relinquish them. Reclamation was an authorised mechanism, not a measured supply response.
Hardware improvement remained a conditional possibility. RFC 2050 stated that the addressing constraints reflected router technology, assignment practice and architectural history. The document reported a conclusion by its authors, the reviewing IETF working group and the IESG that no other currently deployable technology overcame those limitations, while allowing review if routers later handled larger, more dynamic tables or aggregation became possible by other means. That is a contemporaneous institutional assessment of technology, not a benchmark of every router and not proof that the accompanying forecast, audit and appeal parameters were institutionally unique. RFC 2050, Introduction, page 2
RFC 2050 represented practice without receiving a policy endorsement
Institutional role matters because “the IETF decided” would collapse several different acts.
RFC 2050 was BCP 12, published in November 1996, and authored by Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg, and Jon Postel. Its abstract described the policies then used by regional registries to implement IANA-developed guidelines and said that the rules remained subject to revision. RFC 2050, title page, abstract and Introduction, pages 1–2
The IESG note was deliberately narrower than endorsement. In approving the document as a Best Current Practice, the IESG said it believed the policy accurately represented current registry practice. It expressly withheld endorsement or recommendation of the policy and scheduled reconsideration in light of further working-group discussion. Approval of descriptive accuracy, authoring of the text, development of registry guidelines, implementation by registries, and advice from a working group were separate institutional roles.
The RFC presented conservation, routability and registration as three goals. It also acknowledged conflict among those goals and with the interests of end users and providers. Conservation favoured close matching of supply to demonstrated need. Routability favoured hierarchical, topology-sensitive distribution. Registration favoured accurate records of assignments. A grant optimised for one objective could perform poorly against another: a small direct allocation could conserve address volume but add a route; a provider block could aggregate well but impose renumbering; extensive verification could improve records but increase transaction cost.
This acknowledgement is the strongest internal counterevidence against a simplistic account of arbitrary bureaucracy. The authors recognised a multi-objective engineering problem and called for careful judgement. The record supports taking that problem seriously. It does not convert every threshold or institutional remedy into a necessary consequence of the header.
The strongest engineering defence survives the audit
A fair judgment begins with the danger of irreversible over-allocation. Once addresses entered router configurations, DNS, access rules, application settings, customer systems and documentation, recovery became costly. An optimistic large grant could not be assumed to return cleanly after forecasts failed. Smaller initial allocations limited that exposure.
Slow start addressed information asymmetry. A new provider knew its business plan better than a registry, but neither side could observe future customer demand. RFC 2050's process used immediate requirements, verified downstream assignments and repeated applications to replace some forecast uncertainty with observed administrative history. That could conserve the pool and improve registration accuracy.
Classless allocation corrected a severe size mismatch. The choice between 254 and 65,534 ordinary identifiers was badly suited to medium-sized networks. Contiguous prefixes could approximate need more closely than a native Class B while avoiding an arbitrary collection of unrelated Class Cs.
Aggregation addressed a separate shared resource. The January and December 1992 route observations, despite the RFC's unreconciled two-year forecast, showed rapid growth in a concrete MERIT-sourced table. Provider aggregates could reduce the number of destinations that default-free routers carried. The gain depended on topology, software and cooperation, but it was technically substantive.
Provider hierarchy followed from that aggregation logic. If a customer used addresses drawn from its provider's block, the rest of the Internet could often rely on the provider aggregate. Portable space reduced dependence on one provider but could require a distinct global route. The wider network, not only the customer and registry, bore the state associated with that route.
Documentation also served more than conservation. Assignment records supported contactability, reverse DNS, avoidance of duplicate grants, and verification of downstream use. An applicant requesting additional capacity possessed information the registry did not. Some review was therefore rational even if every procedural detail was contestable.
Exception authority could prevent a numerical rule from defeating its engineering purpose. Multihoming, unusual topology, equipment limitations or a large direct requirement might make a default block unsuitable. Case-by-case treatment allowed the registry to accommodate circumstances that a single host percentage could not capture.
These considerations establish a serious engineering case for conservation, aggregation, registration, slow start and careful judgement. A flat system of unconditional large grants could have consumed scarce classful units faster. A flat system of small, independently routed grants could have expanded default-free tables. A ruleless system would have made duplicate allocation and comparable need assessment harder.
The defence does not establish institutional uniqueness. It does not show that 24 months was the optimal forecast horizon, that the RFC 2050 ISP replenishment period minimised combined registry and applicant cost, that one regional registry was the only workable structure, or that hierarchical appeal was superior to partially independent review. Engineering evidence supports the goals and some mechanisms. Applicant, routing, staffing and outcome data would be required to rank the complete designs.
A constrained 1996 comparison locates authority, not outcomes
A useful counterfactual can be set at November 1996, when RFC 2050 was published. Hold constant the IPv4 32-bit fields, the installed classless-capable and classful remnants of the period, the BGP-4 specifications then available, limited router resources, uncertain demand, costly renumbering, and the absence of immediate universal IPv6 conversion. Do not assume universal BGP-4, NAT or private-address deployment, because the cited specifications do not measure adoption.
Begin with the documented baseline: provider-oriented allocation, slow start for new ISPs, additional capacity intended to cover approximately three months of assignments, end-enterprise utilisation tests, case-by-case exceptions, registry audit authority, and parent-registry appeal.
Now vary three institutional parameters analytically.
The first variation changes the replenishment interval. An ISP could receive enough for six months rather than approximately three. This is not a documented historical proposal. It is administratively plausible only under the assumption that the parent registry could size a larger contiguous block without changing packet formats and that provider forecasts were sufficiently credible. The likely authority effect is fewer registry transactions and less dependence on rapid replenishment. The likely conservation risk is more unused capacity when growth fails. Without request histories, forecast errors and assignment data, neither magnitude can be estimated.
The second variation retains three-month slow start but publishes allocation bands and a standard evidence schedule in advance. This too is analyst-constructed. It assumes registries possessed the staffing and record systems to maintain public rules while protecting customer-sensitive material. It could reduce uncertainty about documentation and make similar cases easier to compare, but it might invite strategic presentation around published thresholds and reduce flexibility for unusual networks.
The third variation keeps the technical hierarchy but changes review. Initial allocation and audit decisions remain with the registry; a panel not responsible for the original decision reviews written exceptions and invalidations. No direct source shows that such a panel was proposed in 1996. The variation is administratively conceivable only if the registry system could appoint reviewers, share confidential evidence under safeguards and fund additional process. It relocates some review authority without adding address bits or changing route aggregation.
A broader direct-allocation variation can also be described, but its assumptions are heavier. Smaller single-homed organisations could receive direct regional blocks and retain them when changing providers, subject to an agreed minimum globally accepted prefix. That minimum, the route-acceptance agreement and the administrative capacity are all analytical parameters, not recovered historical rules. The design might reduce customer renumbering but increase independently visible routes. The cited record does not prove that transit providers would have accepted those routes or that period routers could absorb the resulting table.
The comparison reveals where costs and discretion sit. Short replenishment places more transaction and timing risk on the ISP while limiting the pool's exposure to failed forecasts. Larger initial grants reverse part of that incidence. Published bands trade discretion for rule visibility. A separate reviewer moves some remedial authority out of the original decision chain. Broader portability transfers continuity toward the customer and routing-state cost toward the wider network.
It cannot show which variation was feasible at scale, how many addresses each would consume, how many routes each would generate, or which would improve welfare. Calibration would require applicant requests, granted and refused amounts, processing times, forecast errors, provider routing policies, router capacity, staff costs, renumbering outcomes, audit files, and comparable utilisation observations. Those inputs are absent.
The evidence-bounded finding is therefore narrower: RFC 2050 did not itself demonstrate the institutional uniqueness of its design. It documented then-current registry practice, stated a contemporaneous technological judgment, and described rules intended to reconcile competing goals. The analytical variations identify decisions embedded in those rules. They do not prove superior performance.
Four conclusions, with different levels of confidence
The architectural fact is the strongest. RFC 791 fixed each IPv4 source and destination field at 32 bits. The result was (2^{32}) nominal values per field, not an unlimited namespace and not 4,294,967,296 assignable public hosts.
The classful and routing consequences are also well supported. Large gaps between ordinary Class C and Class B host capacity made medium-sized grants inefficient. Multiple Class Cs could conserve a Class B network number while adding routes. RFC 1519's MERIT table documented 4,526 advertised routes in January 1992 and 8,561 in December 1992. Its approximately 30,000 two-year projection cannot be reproduced from the stated doubling formula, but the underlying concern about route growth and classful granularity did not depend on that arithmetic error alone.
The administrative choices are identifiable. Gerich's Informational RFC recommended 24-month forecasts, thresholds, geographic divisions, audits and case-specific exceptions. CIDR authors connected allocation to provider topology and classless aggregation. Hubbard, Kosters, Conrad, Karrenberg, and Postel documented BCP 12's slow start, hierarchy, connected-host utilisation tests, audit authority, invalidation, return and hierarchical appeal. IANA, regional and local registries, providers and transit networks occupied different implementation roles. The IESG accepted RFC 2050 as an accurate representation of current practice while withholding endorsement of the policy.
The full outcomes remain unresolved. Allocation records do not contain the request denominator. The cited sources do not reveal all refusals, reductions, withdrawals, informal guidance, delays, audit cures, returns, exceptions or appeal results. Later registry data contain inherited and backfilled dates. No cited period dataset measures universal BGP-4 deployment, complete address occupation, comparable applicant burden, or the causal contribution of a single threshold to conservation.
The headline can bear those distinctions. The finite field was technical. Classful allocation and router state created real engineering pressure. The rationing regime was political in the limited, evidence-led sense that identifiable institutions chose forecast horizons, allocation levels, hierarchies, evidentiary tests, exception authority and remedies under constraints that did not dictate one complete administrative constitution.
Technical necessity justified collective action. It did not, by itself, determine who would define need, hold confidential evidence, grant exceptions, impose consequences, or decide the final appeal.