Summary

  • RFC 2036 warned that learning one subnet from a historical Class A parent could make classful routing bypass a working default for the parent’s other addresses.
  • Opening the remaining pool therefore forced a coordinated migration across registry allocation, provider routing, customer IGPs, boundary exchange, aggregation and hole disposal.
  • The RFC documented conditions and predicted failure mechanisms, not operator incidence; its later Historic status cannot supply the missing deployment record.

The default stopped being a complete answer

Before the proposed change, classless allocations were often assembled as superblocks of Class C networks. That choice was conservative in a precise way: it allowed old routing behavior to survive beneath a newer allocation policy. A customer domain could run a classful interior protocol, a provider that did not hold the full table could import a default, and another provider could aggregate contiguous classful blocks on its behalf.

RFC 2036 asked what happened when the registry stopped accommodating that compromise. Its subject was a recommendation that IANA begin passing then-unallocated components of Class A space to registries for allocation as classless prefixes. The address stock already existed. The compatibility problem appeared when a prefix boundary no longer matched the first octet’s historical class.

The sharpest sentence in the document concerns a provider that has a default and learns one subnet of a Class A network. Under classful interpretation, that subnet can be treated as knowledge of the whole Class A parent. Traffic for another, unadvertised component need not continue along the default. A fallback route may be present, correct and selected for most of the Internet, yet become irrelevant precisely for the parent whose fragment has been learned.

That is why RFC 2036 said providers had to deploy classless routing even when they depended on a default. Full-table providers already faced that requirement. The proposal removed the exception for smaller providers whose peers had previously performed proxy aggregation. Address-pool activation became a test of routing semantics.

A customer default had to reverse direction

The pressure did not stop at the provider. A non-transit network using classful interior routing could still receive a Class A component, but its safe subnet-default direction was the opposite of the older arrangement.

For allocations aligned with class boundaries, a subnet default pointing away from the provider could prevent a boundary loop. For a classless component cut from a Class A parent, RFC 2036 said the customer’s Class A subnet default had to follow the ordinary default toward the provider. Otherwise the domain could mis-handle destinations outside its deployed component.

That exception carried its own failure surface. Explicit subnet reachability could leak to the provider, leaving the provider to originate the correct aggregate. If the provider proxy-aggregated the entire registry allocation and returned traffic for an undeployed component toward the customer, the packet could circle at the customer-provider interface. If the provider advertised only deployed components, traffic for a hole could travel by default until it reached a router with no default and was discarded elsewhere.

The RFC therefore joined two controls that are often recorded separately: aggregate at the registry-allocated boundary, and install sink subnet routes for every undeployed component. The covering route described reachability policy. The sink stopped that policy from promising an endless path through an empty part of the block. Neither item proves the other was running.

Multi-homing made compatibility transitive

A single-homed customer could be bounded by careful defaults and one classless provider. Multi-homing removed that isolation. Different providers might announce different components of the same historical parent, so the customer’s interior protocol had to preserve prefix lengths rather than collapse them into one Class A network.

Peer connections extended the obligation again. RFC 2036 described a classful domain that learns a component from a classless neighbour and promotes it to the complete parent. That advertisement can override another domain’s provider default. Traffic for every address in the parent is then diverted through the classful peer, passed to the small component’s stub, and discarded when the stub finds no local destination.

No registry can repair this path after allocation. The failure is distributed among what the allocating record means, what each IGP remembers, what each boundary exports and what forwarding does with a hole. A domain that is classless in isolation may still be unsafe when its peer is not. Compatibility becomes transitive across the graph.

The pool was a deployment lever

RFC 2036 proposed staged allocation criteria. Initial recipients should already operate a classless interior environment, or be isolated or singly homed to a classless provider under the restricted classful exception. Vendors should expose explicit classless and classful modes, including whether a subnet default follows the ordinary default or terminates at a sink. Host configuration would eventually need an explicit local prefix rather than only a class, subnet and host decomposition. Providers had to support classless interiors, classless peering and classless customer boundaries.

RFC 2050, published the next month, made the administrative side more direct: assignments assumed variable-length subnet masks and classless technology, and requests based on classful use would not be considered. The allocation rule and the routing requirement thus converged. The registry was no longer merely observing readiness; its choice of granularity changed who could safely receive inventory.

The Address Lifetime Expectations working group supplied the pressure context. Its charter called for IPv4 lifetime estimates, allocation and utilization policy, route-count monitoring, possible reclamation and renumbering, and coordination with CIDR deployment. RFC 2036 reported ALE’s concern that continued drawing from Class C space would exhaust that part of the pool while much of the upper Class A range remained. It did not reproduce ALE’s data or turn a forecast into an outcome.

What later history does—and does not—prove

RFC 2036 was Informational when published and is Historic today. The RFC Editor reports no errata for it. RFC 4632 changed its status in 2006, saying CIDR had been fully deployed and classless allocations from formerly Class A space had accumulated more than six years of experience. RFC 4632 also states the later general rule that an aggregate origin should discard packets matching the aggregate but no more-specific route—the architectural descendant of the hole problem.

That retrospective matters, but its evidence is bounded. It supports the standards community’s later judgment that the transition had moved from live warning to historical practice. It does not enumerate providers, reveal failure rates, show which products changed first, prove every customer migrated cleanly or establish that RFC 2036 caused the result.

Today’s IANA registry no longer shows the unallocated upper-half pool described in 1996, and later IANA records describe the selection of the final /8s and post-exhaustion mechanisms. Those facts close the inventory chapter. They do not convert a deployment forecast into a census.

Six separate receipts

The history becomes clearer when its records are kept apart. A registry receipt shows the allocated prefix and its boundary. A provider receipt shows the received route, default, policy and classless interpretation. A customer receipt shows the interior route, subnet-default direction and external exchanges. An aggregation receipt shows which component activated the covering route and which holes terminate locally. A peer receipt shows that every connected domain preserves prefix length. A forwarding receipt shows the actual next hop or discard for deployed and undeployed test destinations.

Heng Lu’s running-code argument sharpens the distinction: a correct allocation and a correct specification are inputs to execution, not substitutes for it. His reality-layer framework asks where each claim can actually be enforced or observed. Applied here, the lesson is not that coordination records are unreal. It is that the prefix written by a registry must survive every software and policy boundary before it becomes reachability.

RFC 2036 captured a transition at the moment inventory itself became leverage. Opening unused addresses forced hidden classful assumptions into the open. The compatibility test was passed only at the granularity of the whole chain, never by the registry alone.

Sources