Summary
- RFC 1466's classful thresholds and stepped Class C rules were superseded by RFC 2050's classless framework, but the 1993 plan contained no sunset for regional delegation, applicant disclosure, or discretionary review.
- The published record shows textual recurrence and a dated 1993 form-level implementation but lacks denominators for requests, refusals, exceptions, audits, appeals, and outcomes, so later institutional persistence cannot be attributed to the 1993 plan without operational evidence.
The title is a hypothesis, not a quotation
The adjective “temporary” is this article’s retrospective hypothesis. The May 1993 plan, RFC 1466, uses neither “temporary,” “interim,” nor “sunset.” It gives no expiry date for its allocation rules and no schedule for reconsidering the regional institutions associated with them. Its conclusion says the recommendations would delay depletion rather than postpone it indefinitely. That establishes bounded technical efficacy. It does not establish a promised institutional expiry.
The distinction is essential because RFC 1466 combined several different interventions. It addressed the scarcity of desirable classful network numbers, especially Class B units. It sought to reserve address space for a future numbering plan. It arranged Class C allocations so that emerging aggregation techniques could use contiguous blocks. It proposed geographically distributed registration as a way to serve an increasingly international population. It required applicants to disclose network plans, and it left registries with authority to judge exceptions.
Those interventions did not share one lifespan. The classful tests were tied to a technical environment already under pressure. Geographic Class C blocks were partly an administrative arrangement and partly preparation for aggregation. Applicant disclosure and registry judgement were reusable administrative capacities. Regional organisations could continue serving applicants even when the original Class B-versus-Class C problem no longer determined allocation size.
The plan’s opening described demand for network numbers as having grown significantly during the previous two years. It retained the Internet Registry as the principal and default registry while proposing that qualified organisations receive blocks and assignment responsibilities. Its stated service case was global diversity: registries closer to applicants might better understand local languages and customs. Its technical case concerned depletion and routing pressure. These arguments converged in one document, but they should not be treated as one indivisible mandate.
RFC 1466 was published as Informational. Its abstract recorded general consensus among the Federal Engineering Planning Group, the co-chairs of the Intercontinental Engineering Planning Group and RIPE in support of the recommendations. That is evidence of review by named technical groups. It is not a constituency denominator for Internet service providers, network subscribers or applicants, and it does not prove operator-wide consent.
Nor did RFC 1466 originate every regional development later associated with it. The document states that RIPE NCC had received a Class C block before the proposal was adopted. A later retrospective account, RFC 7020, traces the proposal to delegate responsibility to regional bodies to RFC 1366. RFC 1466 therefore codified, revised and associated specific provisions with an already developing regional process. It cannot safely be described as having created regional administration alone.
The useful question is narrower than whether the whole plan became permanent. Which technical rules lost authority? Which administrative capacities reappeared in later text? Which provisions reached a dated form used by applicants? Which institutional roles were described again under a changed technical rationale? And what evidence would be required to move from textual lineage to a claim about continuous operation or causation?
Scarcity in classful units
RFC 1466’s numerical opening is easy to misread because its units were network numbers, not individual addresses. The document reproduced allocation statistics dated May 1992. Its Class A row listed 126 total network-number units and 49 allocated. The table printed 38 per cent, but the arithmetic is 49 / 126 = 38.888889%, which rounds to 39 per cent rather than 38. The discrepancy should be preserved as a feature of the published table, not silently converted into a mathematically exact result.
The Class B row listed 16,383 network-number units and 7,354 allocated. Here 7,354 / 16,383 = 44.887994%, consistent with the printed 45 per cent. The Class C row listed 2,097,151 network-number units and 44,014 allocated. The ratio, 44,014 / 2,097,151 = 2.098752%, is consistent with the printed 2 per cent when expressed as a whole percentage.
None of these ratios measures hosts connected, applicants served, requests approved, prefixes announced, address utilisation, refusals or consent. They compare allocated classful network-number slots with the denominator printed for the relevant class. The rows are not interchangeable because a Class A, Class B and Class C contained radically different quantities of host-address values.
RFC 1466 separately characterised Class A as representing 50 per cent of total IP host addresses, Class B as 25 per cent and Class C as approximately 12 per cent. The theoretical Class C share is 12.5 per cent of the full IPv4 space. That address-space distribution helps explain why only about 2 per cent of Class C network-number units could be allocated while concern remained intense: the immediate problem was not a simple count of all raw IPv4 values.
Classful addressing offered organisations sharply discontinuous choices. A Class C network contained 256 raw address values. Under the period’s conventional treatment of a network identifier and broadcast identifier, it offered 254 usable host identifiers. A Class B supplied a much larger host field. Many organisations therefore preferred a Class B to the operational complexity of joining numerous Class C networks, even when their projected populations occupied only a fraction of the Class B capacity.
The resulting scarcity had at least three dimensions. First, Class B network-number units were being consumed rapidly relative to their finite count. Second, large assignments could leave much of their address capacity unused. Third, replacing one Class B with many Class C networks could multiply routing entries unless aggregation techniques and topology permitted those networks to be represented together.
RFC 1466 addressed all three, but not with one metric. Its Class B restrictions conserved a desirable classful unit. Its Class C schedule converted projected need into contiguous allocations. Its geographic blocks created an administrative structure compatible with potential aggregation. Its regional-registry provisions distributed the work of applying those rules. The plan joined scarcity management to institutional design because somebody had to receive forecasts, evaluate network architecture, preserve confidential information and decide whether exceptions were justified.
This was a scarcity-shaped response, not merely a table of engineering limits. Once a forecast became evidence, allocation depended on an institution capable of interpreting it. Once multiple contiguous networks replaced a single Class B, the allocator had to decide block size and location. Once geographic divisions became the basis for primary responsibility, a technical distribution plan also organised service relationships.
Yet the numbers constrain how far that interpretation can go. The table says nothing about why any one network number was assigned. It offers no population of applications, no comparison of accepted and rejected plans and no account of applicants who altered or withdrew requests. The statistics establish the classful setting in which the policy was written. They do not establish the effects of any individual provision.
The Class B gate
The plan’s most explicit allocation gate concerned Class B requests. Earlier guidance had favoured a subnetted Class B over multiple Class C networks. RFC 1466 reversed that preference where multiple Class Cs were practical, citing the scarcity of Class B network numbers and their underuse by many organisations.
An organisation seeking a Class B was expected to satisfy two conjunctive criteria: a subnetting plan documenting more than 32 subnets and more than 4,096 hosts. It also had to submit an engineering plan showing why a block of Class C networks was unreasonable for its design. The plan had to state the projected number of hosts and hosts per subnet over the next 24 months.
The thresholds were important, but they were not a self-executing entitlement. More than 32 subnets without more than 4,096 hosts did not satisfy the suggested conjunction. More than 4,096 hosts without the required subnet structure did not do so either. Even when the numerical conditions were presented, the registry still had to assess whether the engineering explanation justified the scarcer classful unit.
The vocabulary placed judgement at the centre. The applicant had to demonstrate that a Class C block was unreasonable to engineer. The registry decided whether the application was justified and whether the plan warranted a Class B. If it did not, the described alternative was a block of Class C network numbers. The submitted plan was to be held in strict confidence and used only to judge the application.
RFC 1466 also preserved exceptions. It acknowledged that an organisation might be unable to use a Class C block even without meeting the suggested Class B criteria. Such an applicant could explain the engineering constraint. The text did not enumerate every acceptable topology, assign weights to evidence or publish a formula that eliminated reviewer judgement.
At the level above an applicant, the central Internet Registry could allocate small Class B blocks to a regional registry if that improved community service. It could issue more specific sub-assignment guidance, require accounting for the block, receive applicants’ engineering plans and audit them for consistency with the guidelines. These clauses identify an authorised actor and possible forms of oversight. They do not show that an audit occurred, how often one was considered or what consequences followed.
The arrangement thus contained a technical premise, an allocation criterion, an institutional criterion and an exception. The technical premise was Class B scarcity and underuse. The ordinary criterion combined subnet and host thresholds with a 24-month engineering plan. The institutional criterion was the registry’s capacity to evaluate and protect that plan. The exception permitted a case outside the suggested thresholds to be considered on engineering grounds.
Its burdens were asymmetrical. An applicant had to convert uncertain future growth into a documented architecture. The registry retained discretion over whether the forecast was credible and whether multiple Class Cs were practical. That asymmetry did not arise from an allocation database alone; it was written into the evidentiary relationship between requester and reviewer.
Still, it would be an error to describe every later demand for applicant information as survival of this Class B rule. The original test asked whether a classful alternative was feasible over a two-year horizon. By November 1996, the published framework used prefix length, utilisation and staged allocations. Forecast review recurred, but the object of review and its time horizons changed. Continuity of an administrative function is not continuity of the original threshold.
Contiguous Class Cs and the arithmetic of aggregation
RFC 1466 attempted to conserve Class A and Class B units by assigning multiple Class Cs where possible. That response created its own routing problem. If each Class C appeared separately, the number of routing entries could grow quickly. The plan therefore arranged Class C units in contiguous, power-of-two blocks compatible with aggregation.
The geographic division must be described in the correct unit. RFC 1466 divided the range from 192.0.0.0 through 207.255.255.255 into eight blocks, each covering two first-octet values. Each block contained 131,072 Class C network-number units: 2 × 65,536. That is 6.25 per cent of the theoretical 2,097,152-unit Class C network-number space. It is also 131,072 × 256 = 33,554,432 raw IPv4 addresses.
The theoretical denominator of 2,097,152 Class C units is distinct from the 2,097,151 total printed in RFC 1466’s allocation table. The difference should not be hidden by treating the two figures as if they came from the same calculation. The table reported its classful inventory; the 6.25 per cent block share follows from the theoretical 21-bit Class C network-number field.
The plan reserved the upper half of the mostly unassigned Class C range, 208.0.0.0 through 223.255.255.255, until further notice. In the lower half, 192.0.0.0 through 193.255.255.255 was described as multi-regional because assignments there predated implementation. Europe received the 194–195 block, North America 198–199, Central and South America 200–201, and the Pacific Rim 202–203. Three other two-octet blocks were retained for flexibility.
RFC 1466 called the division primarily administrative and said it laid the groundwork for distributed registries. It was also designed to be compatible with potential address-aggregation techniques. Compatibility is the correct level of claim. Geographic contiguity alone did not cause routing aggregation. Whether a block could be announced as one route depended on network topology, provider relationships, routing policy and the technology actually deployed.
Within those broad blocks, the plan used a stepped schedule based on an organisation’s 24-month projection of required end-system addresses. Fewer than 256 addresses mapped to one Class C; fewer than 512 to two; fewer than 1,024 to four; fewer than 2,048 to eight; fewer than 4,096 to 16; fewer than 8,192 to 32; and fewer than 16,384 to 64 contiguous Class C networks.
Those thresholds referred to raw address-block sizes. They should not be silently merged with usable-host examples. One Class C contains 256 raw values but 254 period-conventional usable host identifiers. Thirty-two Class Cs contain 8,192 raw values. Treated as 32 separate Class C networks, they contain 8,128 such usable host identifiers. Sixty-four Class Cs contain 16,384 raw values and 16,256 classful usable-host slots. The same contiguous address span corresponds to a single /18 prefix, but that prefix notation does not erase the distinction between raw values and the usable-host convention applied to separate Class C networks.
The schedule had exceptions. If a subscriber’s network comprised logically distinct local-area networks for which the default block was difficult to use, the criteria could be applied per local network. RFC 1466 gave an example of 600 hosts distributed across ten Ethernets, potentially producing ten Class C assignments. It also warned against extravagant waste where subnetting was feasible and allowed registries to request an engineering explanation.
A subscriber requiring more than 4,096 unique addresses might qualify for a Class B, yet the regional registry could honour a request for a larger Class C block. Sixty-four contiguous Class Cs were described as the maximum ordinary block, with deviations determined case by case. The schedule was consequently structured but not mechanical.
This provision reveals a plan already leaning beyond the class labels it formally used. Its allocation vocabulary remained Class C, but powers of two, bitwise contiguity and an 18-bit prefix pointed toward classless representation. The plan did not solve the tension between conservation and routing pressure; it arranged allocations so later routing techniques might manage it.
A retrospective visual source cannot supply the missing causal bridge. CAIDA’s Visual History of Internet IPv4 Address Allocations was published on 18 July 2020. Its stated method groups address blocks by the organisation regulating allocation, using the IANA IPv4 address-space file and RFCs as its source basis. The public material does not provide a reproducible historical source snapshot, allocation-event denominator, exclusions, applicant records or decision reasons. It can illustrate CAIDA’s retrospective grouping. It cannot show that RFC 1466 caused an allocation, that a registry refused an alternative, or that an applicant used or declined a fallback route.
Regional service, delegated responsibility and a central fallback
RFC 1466’s regional provisions were justified first as a service response to an increasingly diverse Internet. A registry located closer to a community might better serve applicants in local languages and customs. Europe, North America, Central and South America, and the Pacific Rim were named as sufficiently mature areas in which delegation could be considered.
Proximity alone was not enough. A candidate organisation was expected to be legitimised by networking authorities in its geographic area, well established, and recognised beyond the registry function. It had to commit adequate resources for stable, timely and reliable service. It was to follow IANA and Internet Registry guidelines and coordinate qualifications and sub-allocation strategies with the centre.
The plan also said a regional registry should be unbiased and widely recognised by network providers and subscribers. It considered one registry at that regional level important for efficient and fair sub-allocation. These statements were criteria for institutional selection. They were not proof that all affected providers or subscribers authorised the candidate. The document supplies no constituency denominator for “networking authorities,” recognition or review-group support.
Once selected, a regional registry was empowered by IANA and the Internet Registry to provide registration service in a geographic area. Where one existed, primary responsibility for allocation from the relevant Class C block could be delegated to it. Where no designated authority existed, the central registry remained the default.
The plan did not make the regional channel textually absolute. An applicant could contact the central Internet Registry directly. Depending on the circumstances, the applicant might be referred to the regional registry, but the central registry said it would be prepared to serve any network subscriber if necessary.
That fallback must remain part of the 1993 architecture. It prevents the document from being rewritten as an unqualified grant of exclusive jurisdiction. At the same time, its practical significance is unknown. RFC 1466 did not define “necessary,” establish an enforceable service test or specify how a disagreement about referral would be resolved. The source confirms the route in the published plan; it does not reveal its frequency, accessibility or applicant consequences.
The pre-adoption position of RIPE NCC further limits RFC-centred causation. RFC 1466 records that RIPE NCC had already received the 193.0.0.0 through 193.255.255.255 Class C block before adoption of the proposal and had agreed to allocate within it under the new guidelines. The plan therefore attached its criteria to an existing delegation rather than creating that delegation from nothing.
RFC 7020’s retrospective account reinforces the point without resolving every historical detail. It says RFC 1366 proposed delegating responsibility to regional bodies and notes the succession through RFC 1466 and RFC 2050. It also says the number-registry system changed significantly after RFC 2050. That establishes a recognised lineage in a 2013 Informational document, not an unchanged mandate stretching from 1993 into a later five-registry system.
The defensible 1993 claim is that RFC 1466 codified qualifications for regional delegates, associated geographic Class C blocks with primary regional responsibility and retained a central fallback. It linked service, allocation and coordination inside a developing institutional structure. Whether the regional tier later endured because it offered better service, held delegated resources, reduced central workload or became costly to replace requires evidence beyond the provision itself.
RIPE 95: one dated form-level implementation
The European IP Network Number Application Form and Supporting Notes, RIPE 95, provides a more concrete but tightly bounded view. Issued on 1 October 1993, it stated that it was valid only until 30 December 1993. It is evidence of a particular European form and prescribed submission channels during that period, not an indefinitely operative rulebook.
Its opening described a distributed arrangement in which InterNIC delegated blocks to RIPE NCC, which in turn delegated to local Internet registries. Applicants were directed to apply first through a local registry. A customer of an Internet service provider was told to contact that provider; an applicant without such a provider was directed toward the appropriate non-service-provider local registry. Someone uncertain about the correct route could contact RIPE NCC for advice. The form did not generally authorise uncertainty as a reason to bypass the first-instance local route.
Class B requests followed a clearer escalation. The applicant submitted through a local registry. If the local registry considered the request justified, it forwarded the material to RIPE NCC, which alone assigned Class B numbers in Europe under the stated arrangement. That is evidence of prescribed channels and review levels. It is not evidence of the number of requests forwarded, refused or altered.
The form divided information into public administrative material and confidential technical material. Public fields covered the network name, organisation description, country, administrative and technical contacts, addresses and communication details. The technical section, described as confidential and excluded from the public RIPE database, asked for the class and quantity requested, current machines, one- and two-year machine estimates, current and projected subnets, Internet-connectivity status, existing network numbers and the countries in which the network would operate.
Its examples make the raw-versus-usable distinction visible. The form listed one Class C as a maximum of 254 hosts, two as 508, four as 1,016, eight as 2,032, 16 as 4,064 and 32 as 8,128. These were period-conventional usable-host maxima after excluding two identifiers per Class C network. They did not change RFC 1466’s raw schedule of 256 address values per Class C.
Requests for more than two Class Cs required a fuller network description. Applicants were asked to account for subnet sizes, transit networks and terminal servers. Existing allocations mattered: organisations seeking additional space were expected to describe used and unused network numbers, installed subnets, connected hosts and other structural facts. The stated aims were efficient use and contiguous assignments where possible so routing information could be aggregated.
For Class B requests, RIPE 95 described the criteria as extremely strict because of global scarcity. Host estimates were to be supported by information such as employee numbers, geographic distribution and host types. Applicants had to explain why contiguous Class Cs could not support the design. Administrative convenience was expressly discounted. Multiple Class B requests required detailed justification capable of persuading both the local registry and RIPE NCC.
This is stronger evidence than a policy document alone for one limited proposition: RFC-era information requirements reached a dated applicant form in Europe. The fields show how projected machines, subnets, prior assignments and connectivity were made legible to reviewers. The first-instance local route and Class B escalation identify the prescribed administrative path.
The form is much weaker evidence for adjudication. It contains no denominator for completed applications, referrals, approvals, refusals or withdrawals. It does not show whether two similar applicants were treated alike, whether reviewers followed every field, how exceptions were reasoned, whether forecasts were later checked or whether an applicant regarded the process as legitimate. A standard form can demonstrate expected disclosure without demonstrating consistent decisions.
It also cannot establish continuity through 1996. Its expiry date is explicit. A later form might have retained, modified or removed individual fields, but that conclusion requires the later instrument. RIPE 95 should therefore remain one dated observation: a form-level implementation of parts of the 1993 architecture, bounded to late 1993 and Europe.
November 1996: a textual replacement, not an instantaneous event
In November 1996, RFC 2050 expressly obsoleted and replaced RFC 1466. Published as Best Current Practice 12, it said the earlier guidelines and procedures had been updated and modified in light of experience. Textually, the succession is unambiguous.
Its status note requires precision. The Internet Engineering Steering Group said approval reflected its belief that the policy accurately represented current registry assignment practice. The note immediately added that approval did not constitute IESG endorsement or recommendation. It also anticipated reevaluation in December 1997 following further discussion.
That note supports a claim of published codification and claimed current practice. It does not authenticate a separate institutional-retention decision, establish uniform implementation across registries or prove that every provision took effect simultaneously on publication. RFC status, obsolescence, claimed practice and implementation are distinct propositions.
The technical changes were substantial. RFC 2050 organised distribution around three goals: conservation, routability and registration. Conservation meant fair distribution based on operational need and prevention of stockpiling. Routability meant hierarchical distribution that assisted routing scalability, while expressly refusing to guarantee that assigned addresses would be routed. Registration meant maintaining a public record to preserve uniqueness and support troubleshooting.
The document acknowledged that these objectives could conflict with one another and with the interests of end users and service providers. It called for analysis and judgement in individual cases. The later discretion therefore had a newly articulated three-goal basis rather than merely repeating the Class B-versus-Class C problem.
RFC 2050 described an established hierarchy of IANA, regional registries and local registries. At the time it named three regional registries: InterNIC, RIPE NCC and APNIC. That 1996 description should not be replaced by later five-registry geography. Regional registries operated in large geopolitical areas, coordinated local registries and were described as established under IANA authority with regional Internet-community consensus.
Allocation was now explicitly classless. Regional registries issued blocks on CIDR-supported bit boundaries. Assignments were made by prefix length rather than as Class Bs or Class Cs. Classful assumptions made for administrative convenience required special justification. An organisation that might previously have been described as receiving a Class B would instead receive a /16 prefix if that size were justified, regardless of historical address class.
Provider hierarchy became central to routability. An Internet service provider meeting specified routing conditions, including qualifying multihoming or direct connection to a defined major exchange, could request space from a regional registry in its geographic area. A provider without a designated regional registry could contact another regional registry, which could handle or refer the request. Other providers were generally directed to obtain space from an upstream provider so assignments could fit provider aggregates.
The document warned that addresses issued directly by a registry were among the least likely to be globally routable. It encouraged providers to treat customer assignments as loans for the duration of connectivity and contemplated renumbering when a customer changed providers. This was a different relationship between aggregation and allocation from RFC 1466’s broad geographic Class C grid.
For new service providers, RFC 2050 prescribed slow start. The initial allocation was to be minimal and based on immediate demonstrated requirement. Later blocks could increase after the regional registry verified utilisation. Parent registries determined initial and subsequent sizes. Projected customer numbers had little influence, and an additional allocation was intended to cover approximately three months of assignments.
That provider-allocation rule must remain separate from the end-enterprise assignment guideline. For an end enterprise, RFC 2050 listed 25 per cent immediate utilisation and 50 per cent utilisation within one year. It defined utilisation as connected hosts divided by the total possible hosts on the network. An organisation had to show high confidence in its one-year projection and provide supporting documentation. Topology could justify exceptions, but the percentages were presented as the common guideline.
The later document also required network engineering plans. Before assignment, a registry was to examine subnet masks, hosts per subnet, topology, routing plans and protocol limitations, with subnet and host information covering at least one year. Previous address assignments across divisions and subsidiaries had to be accounted for. Registries could require corroborating evidence and information confirming organisational identity.
These information demands resemble the 1993 architecture at a high level but served a changed test. RFC 1466 used a 24-month forecast to determine whether multiple Class Cs were reasonable and to select a stepped classful block. RFC 2050 used immediate need, one-year utilisation, prior-use evidence, prefix sizing, provider aggregation and staged allocations. The applicant still supplied information; the information no longer answered the same allocation question.
Audit authority also changed. RFC 1466 allowed the central registry to audit regional Class B engineering plans. RFC 2050 said all address requests were subject to audit and verification by means a regional registry considered appropriate. False information could support invalidation and return of assigned addresses to the free pool. Regional registries could set size thresholds requiring a second opinion.
Confidentiality and review routes were more fully described. Information identified by an applicant as sensitive had to be treated as confidential. If the assigning registry could not assure privacy, its parent might make the assignment. An organisation dissatisfied with an assignment decision had a written right to appeal to the parent registry, with further appeal ultimately possible to IANA after other avenues were exhausted.
These were published powers and safeguards. Their inclusion says nothing by itself about audit selection, appeal frequency, reversal rates or access in practice. Yet they demonstrate that the later framework was not merely RFC 1466 with class names removed. It recast allocation around CIDR, provider hierarchy, utilisation, slow start, verification and appeal.
Textual obsolescence therefore matters. After November 1996, the authoritative published baseline was RFC 2050, not a silently continuing RFC 1466. Equally, publication cannot show the date on which every regional form, reviewer habit, software tool or applicant channel changed. Rule continuity and institutional continuity must be assessed separately.
Four explanations for apparent persistence
Three broad features associated with RFC 1466 reappeared after its classful mechanics lost authority: regional organisations, applicant information burdens and discretionary review. Their recurrence does not identify its own cause.
Four explanations deserve consideration. The first is continuing technical need. Unique allocation, finite address pools and routing aggregation could independently justify coordinated registries and evidence-based review after the Class B problem changed.
The second is delegated responsibility. An organisation holding address blocks, records and obligations to downstream registries had practical responsibilities that did not vanish when a successor RFC appeared. Continuation might reflect the need to preserve accurate assignments and operational service rather than attachment to the earlier text.
The third combines switching cost and administrative inertia. Existing staff, forms, databases, confidential channels, escalation relationships and applicant knowledge make institutional replacement costly. That mechanism is plausible once infrastructure exists, but plausibility is not measurement. The reviewed sources do not price the transition or document a rejected alternative.
The fourth is later textual codification. RFC 2050 described regional hierarchy, applicant documentation, verification and appeals under a classless framework. This shows that later authors restated and reorganised broad administrative functions. It is weaker than an authenticated decision record identifying a responsible body, a retained 1993 provision, reasons for retention and an implementation date.
These explanations are not mutually exclusive. Continuing technical need can coexist with delegated responsibility. A useful institution can also be costly to replace. Later codification can recognise arrangements that developed through practice rather than create them. The evidence permits selective testing of each possibility, not a numerical allocation of causation.
Regional organisations after the geographic grid
The precise 1993 provision joined qualified regional organisations to primary responsibility within broad Class C blocks while preserving central default service and a direct fallback. Its technical setting was classful allocation compatible with potential aggregation. Its institutional setting was a developing model of geographically distributed service.
By 1996, RFC 2050 described regional registries as established components of a three-level hierarchy. IANA allocated to them; they coordinated local registries; local registries and providers served downstream users. The mechanism was no longer the simple pairing of a regional organisation with one two-octet Class C block. It involved CIDR allocations, provider-based addressing, reassignment records and hierarchical review.
The later text did not repeat the entire 1993 qualification list. Language and custom, legitimacy outside the registry function, a single regional organisation per area and universal central service “if necessary” were not restated in the same form. RFC 2050 instead referred to regional Internet-community consensus, IANA authority and coordination of local registries.
The observed evidence within the period remains bounded. RIPE 95 shows a European local-to-regional arrangement in late 1993. RFC 2050 codifies a regional hierarchy in November 1996 and characterises it as current registry practice, subject to the IESG note’s limitation. RFC 7020 later recognises the institutional lineage while recording major subsequent change.
Continuing technical need is a strong alternative to RFC-centred causation. Address uniqueness required coordination, and aggregation benefited from hierarchical distribution. Regional service could reduce central workload and place reviewers nearer applicants. None of those needs depended on continued use of the 1993 Class C map.
Delegated responsibility is also plausible. RIPE NCC already held a block before RFC 1466’s adoption. Once regional and local registries held address space, maintained records and served downstream organisations, abrupt replacement would have required transfers of data, authority and technical functions. The sources show these responsibilities existed; they do not establish the complete instruments by which each was sustained.
Switching cost is suggested by the form-level infrastructure visible in RIPE 95. Applicants had recognised channels, public and confidential fields, local contacts and an escalation route for Class B review. Replacing those arrangements would impose effort. No reviewed evidence shows that a proposed alternative was rejected because the cost was considered excessive.
Later codification is the clearest documentary fact. RFC 2050 published a hierarchy under a different allocation regime. Calling this textual readoption avoids mistaking publication for proof of a distinct retention decision or universal operation.
The central fallback is where a claim of unchanged continuity fails most sharply. RFC 1466 said the central registry would serve a subscriber if necessary. RFC 2050 instead described ordinary provider and regional channels, cross-regional contact where no regional registry existed, parent intervention for confidentiality and hierarchical appeals. These superior-level mechanisms are not the same as the earlier assurance.
The sources do not show whether the RFC 1466 fallback was frequently used, rarely used, narrowed, transformed or left dormant. They also do not establish its enforceability or practical convenience. The safe conclusion is that regional administration persisted in published form while its technical basis and service hierarchy changed. The role endured; the 1993 allocation grid and fallback language did not demonstrably endure unchanged with it.
Applicant disclosure after classful thresholds
RFC 1466 required a Class B applicant to present subnet and host projections, explain why Class Cs were unreasonable and disclose a 24-month engineering plan. Its Class C schedule also depended on a two-year estimate of required end-system addresses. RIPE 95 translated related demands into fields covering present and future machines, subnets, connectivity, prior assignments and network structure.
RFC 2050 retained the general proposition that a request was not self-validating. A registry examined evidence about network plans, topology, routing, previous use and expected utilisation. Providers seeking further allocations had to demonstrate use. End enterprises faced immediate and one-year utilisation expectations. Corroboration could be required.
The carrying actors differed by level. A local registry or provider might receive an ordinary request. A regional registry could review larger or direct allocations. A parent registry could become involved in confidentiality, second opinions or appeals. The applicant remained dependent on an institutional assessment, but the reviewing body and evidentiary purpose varied.
The mechanism changed more than the recurrence of forms might suggest. In 1993, a two-year projection selected among Class B eligibility and power-of-two Class C blocks. In 1996, a new provider began with minimal space based on immediate need, while additional provider space covered roughly three months after utilisation verification. An end enterprise was assessed against immediate and one-year utilisation, defined by connected hosts over possible hosts.
That shift materially reduced the role of speculative growth for providers. RFC 2050 said projected customer base had little effect on parent-registry allocations. Historical use and staged need became more important. Information collection survived, but its logic moved from choosing classful units to controlling classless allocation over time.
Continuing scarcity supplies an independent explanation. A finite pool and uncertain demand create a reason to ask applicants for evidence even if no earlier form exists. Routability adds another: topology and provider relationships affect whether a prefix can contribute to aggregation. The later information burden could therefore be justified by current technical conditions rather than inherited habit.
Existing administrative capacity remains a plausible contributor. Reviewers already knew how to handle confidential plans, prior assignments and projections. Applicants already encountered standardised questions. A changed technical test could be inserted into familiar channels. That is a credible account of adaptability, not proof that inertia caused the later rules.
Published codification is again the firmest result. RFC 2050 required documentation under a new framework. The article can establish textual recurrence and one 1993 form-level implementation. It cannot establish uninterrupted use of the same form, stable reviewer practice or consistent effects across the 1993–1998 period.
The institutional afterlife is therefore narrower than the survival of a particular threshold. The durable feature was a request architecture in which an applicant supplied network evidence and a registry interpreted it against shared resource and routing aims. The 32-subnet, 4,096-host and 24-month tests did not survive as the general allocation grammar.
Discretion recodified under different technical goals
RFC 1466 reserved judgement at several points. Class A assignments remained at IANA’s discretion. A Class B applicant outside the suggested thresholds could argue that Class Cs were technically unusable. A Class C allocation could depart from the default schedule where local-network structure justified it. Larger Class C blocks and other exceptions were determined case by case.
Its possible audit concerned the central registry’s oversight of engineering plans supporting regional Class B assignments. The authority was permissive: the registry could require accounting and could audit. That wording establishes discretion to act, not evidence that action was frequent or systematic.
RFC 2050 recodified discretion more broadly. Conservation, routability and registration could conflict with one another and with individual interests. Registries were expected to exercise judgement. Topological considerations could justify departures from utilisation guidelines. Routing efficiency, prior assignment history and network plans were assessed case by case. Second opinions could be required above a regional threshold.
The later document also stated that all requests were subject to audit and verification and allowed invalidation where an assignment rested on false information. At the same time, it formalised confidentiality obligations and an appeal route. The published architecture combined reviewer authority with stated avenues for superior review.
This was not unchanged continuation of RFC 1466. The earlier judgement centred on class selection, multiple-Class-C feasibility and departures from a classful schedule. The later judgement concerned prefix length, immediate need, utilisation, provider aggregation, routing probability and classless network design. Similar institutional verbs concealed different technical objects.
Continuing need is especially persuasive here. No fixed threshold can represent every topology, and conservation can conflict with routing aggregation. Expert judgement may persist because cases vary, not because an organisation is unable to abandon an earlier practice.
Administrative inheritance may still matter. A registry already equipped to receive plans and protect confidential information could extend review to utilisation and routing evidence. Hierarchical delegation also placed judgement at multiple levels. Yet the sources do not reveal whether reviewers applied a stable interpretive culture across the documentary break.
Later codification is observable in the text. Operational consistency is not. A written exception says atypical cases may be considered; it does not reveal exception frequency or direction. Audit authority identifies a power; it does not reveal the selection method, findings or consequences. A written appeal route identifies a remedy; it does not establish accessibility, use or reversal.
The appropriate afterlife claim is thus functional and limited. Registry discretion over resource conservation and network design reappeared under RFC 2050, with broader audit language and a written appeal provision. The substantive criteria changed, and the evidence does not show that later discretion was caused by RFC 1466 or exercised uniformly.
What the published record establishes—and withholds
The documentary sequence is clear at several points. RFC 1466 was published in May 1993 as an Informational plan. It contained classful statistics, Class B tests, contiguous Class C schedules, regional qualification criteria, case-by-case exceptions and a direct central fallback. It also acknowledged that RIPE NCC held a Class C block before adoption.
RIPE 95, valid until 30 December 1993, shows a European form requesting present and projected network information and prescribing a first-instance local-registry route. RFC 2050 was published in November 1996 as BCP 12, expressly replaced RFC 1466 and codified classless allocation, provider hierarchy, slow start, utilisation review, verification and appeals. RFC 7020 supplied a 2013 retrospective lineage while acknowledging significant later change.
The record is thin when the unit changes from a document to a case. No reviewed source provides a denominator for total requests, approvals, refusals, withdrawals, exceptions, audits, appeals, direct-IR contacts, referrals or abandoned requests. There is no linked population showing which channel an applicant first used, what evidence was requested, how a reviewer reasoned, what block was assigned, whether an exception applied, whether an audit occurred or whether an appeal changed the result.
Aggregate allocation records cannot recover all those facts. An issued block identifies an allocation outcome, but not rejected alternatives, withdrawn requests, unsuccessful applicants, reviewer motives or the route by which the request arrived. A retrospective grouping of blocks by regulating organisation cannot identify which rule caused an individual assignment.
The missing denominators limit claims in different ways. Without direct-IR cases, the 1993 fallback cannot be classified as robust, nominal or impractical. Without exception populations, the published thresholds cannot be translated into actual regularity. Without audit records, authority cannot be converted into enforcement frequency. Without appeal records, a written remedy cannot be evaluated for access or effect.
Contemporaneous correspondence around RFC 2050 would answer a different question. The successor said it updated and modified the earlier provisions in light of experience, but the sources reviewed here do not supply a complete clause-by-clause account of what the authors intended to preserve, what they considered obsolete or what may already have fallen out of use. Textual replacement proves succession. It does not disclose every replacement motive.
Absence of these records is not evidence of consent, opposition, fairness or failure. It is a boundary on inference. The documents show what institutions published, what one late-1993 form asked applicants to provide and how a 1996 successor described the registry system. They do not establish a population-wide operational history.
That boundary also protects against an opposite mistake: assuming institutional persistence merely because later retrospective accounts recognise lineage. A lineage can contain extensive revision. RFC 2050 displaced the classful thresholds, changed the allocation unit to prefix length, formalised slow start and recast aggregation around providers and CIDR. RFC 7020 itself says the system changed significantly after 1996.
A bounded answer
RFC 1466 was not textually temporary. It supplied no expiry, no interim label and no institutional sunset. Its statement that the recommendations would only delay depletion described the limits of the technical remedy, not a promise that regional delegation, applicant disclosure or registry judgement would expire with classful allocation.
It was, however, textually obsoleted in November 1996. RFC 2050 materially displaced its Class B test, geographic Class C algorithm and 24-month classful schedule. Prefix-length allocation, CIDR boundaries, provider hierarchy, slow start, verified utilisation and one-year end-enterprise projections became the published framework.
Some administrative capacities associated with the 1993 plan reappeared. Regional organisations occupied a published position between IANA and downstream registries. Applicants continued to provide network evidence. Registries continued to judge scarcity, topology and aggregation, now under different criteria. RIPE 95 supplies one dated example of form-level implementation, while RFC 2050 supplies later codification and a claim about current practice.
The sources do not establish that RFC 1466 caused those capacities to persist. Regional administration was already developing before its adoption. Continuing technical need, delegated responsibility, switching cost, administrative inertia and later codification remain plausible and overlapping explanations. The record does not apportion their causal weight.
The final distinction is therefore sharp. RFC 1466 was not textually temporary; it was textually obsoleted in 1996; and the published evidence shows limited form-level implementation and later codification without proving that the 1993 plan caused the operational persistence attributed to it.