Summary
- RFC 1887 treated IPv6 aggregation as a cost-allocation problem: every multihoming design shifted real expense among sites, providers and routers elsewhere.
- RFC 2073 named registry, provider and subscriber fields inside the address; RFC 2374 revised that hierarchy, and RFC 3587 made its TLA/NLA replacement historic while preserving hierarchical prefixes as an operational tool.
- The sequence separates three things often collapsed in one database row: the address used by packets, the institution that allocated it and the topology that makes its route economical.
The first design began with other routers
In December 1995, RFC 1887 asked how IPv6 addresses should be allocated so that a much larger Internet could still route. Its unit of concern was not the individual host. It was the quantity of reachability information that routers would have to store, exchange and recompute.
The document called the desired reduction “routing data abstraction.” If many sites received contiguous addresses under a provider's larger block, that provider could advertise one prefix instead of a list of customers. The saving accrued mainly outside the site: distant providers saw fewer routes. Address hierarchy was therefore not decorative syntax. It was a way to suppress distributed operating cost.
This reasoning inherited the classless turn recorded in RFC 1518 and RFC 1519. Arbitrary prefix lengths allowed routing to follow topology instead of old address classes. But a classless forwarding algorithm did not make allocation neutral. Someone still had to decide which addresses were contiguous, which exception would be advertised and how far it would propagate.
RFC 1887 named the tension directly: efficiency versus decentralised control. Address administration could be distributed, yet aggregation worked best when assignments followed actual connectivity. Administrative boundaries and network topology did not always coincide. The design problem was not to choose freedom or order once. It was to locate the cost of their mismatch.
Multihoming exposed the invoice
The document's most revealing section offered four approaches for a site attached to several transit routing domains.
A site could obtain one prefix independently of its providers. That preserved one internal numbering plan and gave the organisation a stable aggregate. The price appeared in other networks: providers potentially worldwide needed a separate route for that site.
Alternatively, the site could take a different provider-derived prefix at each connection. Each provider could aggregate its own customers, and traffic could enter near the destination. Yet backup reachability no longer came automatically. A failed connection could strand the addresses derived from that provider, and a change in external connectivity could force internal addresses to change.
A third option selected one provider-derived prefix as the default and disclosed more-specific reachability selectively. A fourth imagined a shared prefix for the overlapping customers of particular providers. Neither eliminated policy. They constrained where extra state had to live and who had to coordinate it.
RFC 1887's summary is more durable than any one option. Each solution, it said, placed a different real—explicitly financial—cost on multihomed organisations and on transit domains, including domains to which the organisation was not attached. Providers would need policies for accepting and propagating non-local prefixes. Those policies would reflect cost.
This is the point at which an address allocation ceases to be a clerical gift. A stable independent prefix can spare one enterprise a renumbering project while obliging the global routing system to carry an exception. A provider-derived prefix can preserve aggregation while making exit more expensive for the customer. Both are technically coherent. Neither is costless.
Five bits gave the registry a visible seat
In January 1997, RFC 2073 turned the architecture into a proposed provider-based format. After a three-bit format prefix came a five-bit Registry ID, then a variable Provider ID, a Subscriber ID and a 64-bit intra-subscriber part.
The named fields made an institutional chain visible inside the allocation format. IANA was the principal registry and could delegate blocks. The document listed identifiers for a multi-regional IANA pool, RIPE NCC, INTERNIC and APNIC. Registries would decide how to divide provider and subscriber space. Providers would structure subscriber IDs. Subscribers controlled their local portion.
Yet the document also contained important limits. It said the format did not preclude other unicast formats. Forwarding was still based on longest-prefix match, not on routers interpreting the Registry or Provider IDs as commands. Some subscribers could obtain space directly from a registry and become independent of their attached providers.
The field named an allocation position. It did not prove a contract, current connectivity, routing origin, beneficial ownership or successful delivery. Nor did the word “provider” give one institution permanent authority over all those layers.
The registry field lasted eighteen months
RFC 2374, published in July 1998, obsoleted RFC 2073. One of its major changes was the removal of registry bits because they were not needed for route aggregation. The new format used Top-Level Aggregation, Next-Level Aggregation and Site-Level Aggregation identifiers, followed by a 64-bit interface identifier.
That revision did not abandon hierarchy. It changed what the hierarchy claimed to represent. Public topology could be organised through providers and exchanges; site topology remained local. Exchange-based allocation was presented as a possible route to independence from long-haul providers and to multihoming without a separate prefix from each one. But the mechanisms for provider selection and portability were expressly out of scope.
The distinction matters. A diagram can reserve a slot for portability without supplying authentication, transfer rules, failure handling or a party obliged to complete the move. Architectural possibility is not an operational outcome.
In August 2003, RFC 3587 made RFC 2374 and the TLA/NLA structure historic. It said that a coordinated allocation policy defined by the Regional Internet Registries had replaced the fixed scheme, that TLA/NLA might not be the technically best approach at that stage of deployment, and that policy was likely to evolve.
What survived was simpler: a global routing prefix, a subnet ID and an interface ID. The global prefix would typically remain hierarchical under RIRs and ISPs; the site administrator would structure the subnet field. Aggregation survived. The standards document stopped assigning permanent names to every external tier.
Renumbering was possible, not free
Provider-based allocation often treats renumbering as the price of changing attachment. IPv6 supplied tools to reduce that price. RFC 4192 described a make-before-break procedure in which old and new prefixes coexist on interfaces while DNS, routing and configuration move.
That procedure is valuable precisely because renumbering is a chain, not one edit. Addresses can be embedded in access-control lists, monitoring systems, application configuration, reverse DNS, filters and documents. The 2007 IAB workshop report, RFC 4984, recorded that these dependencies made renumbering sufficiently difficult to be effectively impossible for some sites.
The same report restated the other side. Provider-independent space helps organisations avoid provider lock and supports multihoming, but it adds non-aggregatable entries whose routing and processing cost is borne across the default-free zone. Provider-allocated space aggregates at one provider; announcements through another can force deaggregation. More address space did not remove the routing-state problem.
The IAB report described a deeper overload: one IP address acts both as a locator, which should track topology, and as an identifier, which users want to remain stable. A single number cannot optimise both functions in every case. RFC 1887 had already shown the invoice; RFC 4984 explained why it kept returning.
Even the neat /48 became advice, then less neat advice
RFC 3177 recommended /48 assignments to end sites in the general case, /64 for a known single subnet and /128 for a known single device. It also acknowledged that technical delegation policy could strongly affect business relationships even while the IETF declined to decide business questions.
A decade later, RFC 6177 obsoleted that one-size-fits-all recommendation. It warned that a few fixed boundaries might be hard-coded into implementations and operating practice—a return to classful thinking. It kept the principle that sites should receive enough room for planned use, but left the exact size to operational judgment.
This was not indecision. It was the architecture learning where precision belonged. Stable forwarding semantics and a generous local boundary could be standardised. The exact allocation tier, institutional label and default site size needed room to change as deployment supplied evidence.
What the address can actually prove
An IPv6 prefix can identify the destination range in a route. An allocation record can state which institution recorded a delegation at a given time. A BGP observation can show which autonomous system originated a route from a particular vantage point. A provider contract can establish a commercial relationship. A packet trace can show a path and an application log can show an outcome.
Those records can be linked. They are not interchangeable. Reading “provider” out of a historical bit field and treating it as proof of ownership would collapse architecture, administration and operation. Treating a registry entry as proof of current reachability would make the same error in another direction.
The early IPv6 sequence offers a better discipline. Keep the routing benefit measurable. Keep the institution accountable for the act it actually performs. Keep allocation policy revisable. And when portability or resilience creates cost, record where the cost lands instead of hiding it inside the apparent permanence of an address.
Sources
- RFC 1518 — An Architecture for IP Address Allocation with CIDR
- RFC 1519 — Classless Inter-Domain Routing
- RFC 1887 — An Architecture for IPv6 Unicast Address Allocation
- RFC 2073 — An IPv6 Provider-Based Unicast Address Format
- RFC 2374 — An IPv6 Aggregatable Global Unicast Address Format
- RFC 3177 — IAB/IESG Recommendations on IPv6 Address Allocations to Sites
- RFC 3587 — IPv6 Global Unicast Address Format
- RFC 4192 — Procedures for Renumbering an IPv6 Network without a Flag Day
- RFC 4984 — Report from the IAB Workshop on Routing and Addressing
- RFC 6177 — IPv6 Address Assignment to End Sites
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
