Summary

  • RFC 9812 replaces IESG Approval with IETF Review for major non-routine releases from the IETF-reserved IPv6 address pool, requiring a public IETF-stream RFC, IETF Last Call and an IESG consensus determination.
  • The stronger process authorizes a registry change; it does not itself allocate space to an operator, create a route, make a prefix globally reachable or confer a general political mandate on the IETF community.

The word reserved is easy to misread. In ordinary commercial language, a reserved room has a customer. A reserved seat has a passenger. In an IANA registry, the direction is almost the opposite. RFC 8126 defines a reserved value as unassigned and unavailable for assignment, held for a special use such as expanding a namespace later. Reservation suspends ordinary allocation. It does not name a beneficiary.

That distinction governs RFC 9812, a short Best Current Practice with a large control surface. IPv6 supplies 128-bit addresses. The currently designated global-unicast range, 2000::/3, occupies one-eighth of the whole mathematical space. RFC 7249 described approximately seven-eighths as reserved by the IETF for future needs. The live IANA IPv6 Address Space registry still shows the hierarchy: 2000::/3 is Global Unicast, while many other top-level blocks are Reserved by IETF.

The scale of the reserve created an authority problem. RFC 1881 had delegated IPv6 address-space management to IANA in 1995 but did not specify how this reserve should later be opened. At some point the IANA table showed “IESG approval.” That looked like a procedure. It was not commensurate with the decision.

Under RFC 8126, IESG Approval can be granted without an RFC. The Internet Engineering Steering Group may ask for documentation, but the policy does not require a public, permanent RFC record. The mechanism is supposed to be uncommon: a fallback when another process cannot be used in time or when a compelling reason exists. RFC 8126 even warns that it is not intended to circumvent public review.

An emergency valve had quietly become the displayed gate for most of IPv6's spare top-level space. RFC 9812 does not allege abuse. It identifies a structural mismatch. A decision capable of changing the future address architecture should not depend on whether a small executive body chooses to request documentation in a particular case.

The repair is IETF Review. That term is more precise than the vague phrase “community approval.” RFC 8126 specifies its mechanics. A new assignment must be documented in an RFC in the IETF Stream, produced as an IETF working-group or area-director-sponsored document, exposed to IETF Last Call, and approved by the IESG as representing IETF consensus. Working groups, directorates, specialists and the wider review process can inspect the proposal for interoperability damage or inappropriate protocol extension.

The durable receipt is therefore not a show of hands. It is a chain: a proposal with an exact prefix and purpose; an accountable document path; a public review interval; recorded objections and revisions; an IESG decision; a permanent RFC; and an IANA registry change tied to that RFC. Participation contributes evidence and technical challenge. The authorizing act remains bounded by the process and the shared namespace it governs.

RFC 9812 also rejects a superficially stronger alternative. Standards Action would restrict qualifying assignments to Standards Track or Best Current Practice RFCs. IETF Review normally accepts any IETF-stream RFC category, including Informational, Experimental or Historic. Why leave that flexibility when the reserve is so consequential? Because opening an address range need not define a new protocol standard.

That sentence prevents process theatre. A standards label should describe the normative work being done, not serve as ceremonial armor for a registry decision. Forcing every release onto the Standards Track could distort document classification, delay legitimate experiments, or imply an interoperability mandate that the proposal does not contain. RFC 9812 chooses stronger review without demanding the wrong type of artifact.

The three policies form a useful authority ladder. IESG Approval can operate as exceptional executive discretion and may lack an RFC. IETF Review requires public IETF process and a durable RFC but permits several RFC statuses. Standards Action narrows the acceptable RFC statuses to Standards Track or BCP. “Stronger” is therefore not a single scalar. The right rule must match the decision's risk and its semantic nature.

The precedent was already visible. RFC 9602 requested 5f00::/16 for Segment Routing over IPv6 SIDs. The proposal went through the IPv6 Maintenance working group and IETF review. IANA then recorded the block in the IPv6 Special-Purpose Address Registry. RFC 9812 cites that path as evidence that the proposed review level was workable.

But the example must not be expanded beyond its record. RFC 9602 marks the block as not globally reachable. It asks the SRv6 operational community to develop further conventions. Networks outside an SR domain need not give the prefix special semantics. An RFC, an IANA row and a reserved-purpose description do not prove that a vendor supports the function, that an operator accepts the route, that a packet crosses a boundary or that a service works.

Even the word moved needs a ledger. 5f00::/16 sits inside a top-level block still shown as Reserved by IETF. The special-purpose registry adds a more specific purpose and flags. It does not magically turn the surrounding address space into general unicast inventory. Parent reservation, child allocation, reachability flag and observed routing are separate objects.

The institutional boundaries are equally important. RFC 7020 describes the Internet Numbers Registry System as a hierarchy. IANA manages the top of the IP-address and AS-number allocation system. Regional Internet Registries perform regional allocation functions and develop policies through their own processes. RFC 7249 separately places non-reserved globally unique unicast allocations in that RIR path.

RFC 9812 does not annex routine RIR policy. It regulates a prior decision: whether and how a major non-routine part of the IETF-reserved top-level pool may leave reservation. Once a range enters another registry or allocation regime, later actors have their own powers and evidence. Collapsing them into “the Internet community allocated an address” destroys the very accountability the new rule was meant to create.

RFC 2860 supplies another boundary. IANA performs technical-parameter assignments under IETF policy. That relationship makes an IANA registry update an execution receipt for an approved policy. It does not make IANA the political owner of the namespace, and it does not make the IETF the operator of networks that later use a prefix.

The IPv6 Global Unicast Address Space registry and the special-purpose registry exist separately because their claims differ. One records global-unicast allocation structure. The other records prefixes with special protocol purposes and explicit properties. A top-level address-space row, a child special-purpose row and an RIR allocation record cannot substitute for one another.

There is a temptation to turn IETF Review into a larger legitimacy story. That would repeat the error exposed in Heng Lu's Multi-Stakeholder Mirage: attendance, expertise and objection are not automatically a mandate over absent principals. RFC 9812 is defensible precisely because its scope is narrower. The IETF maintains a shared protocol namespace. Releasing a top-level portion can alter interoperability assumptions for everyone implementing IPv6. Technical review is tied to that common dependency.

The process does not represent every user in a political sense. It does not authorize the IETF to govern an operator's balance sheet, seize an existing allocation or replace public law. It asks whether a proposed namespace change has been exposed to the technical community responsible for interoperability and whether a durable RFC supports it. The distinction between stakeholder evidence and principal authority remains intact because the object and the process are named.

This is where Minimum Initial Specification adds discipline. The common rule should be as narrow as the shared invariant requires. RFC 9812 specifies the review needed to open reserved top-level space. It does not prescribe every downstream routing policy, filter, product decision or commercial use. Local actors remain visible rather than being absorbed into the initial specification.

Reality Layers supplies the audit structure. A proposal exists. The IETF reviews it. The IESG approves an RFC. IANA changes a registry. A downstream body allocates or reserves a child. Operators create route objects or RPKI material. Routers accept or reject announcements. Packets succeed or fail. Each layer may be true while the next is false.

Running-Code Primacy keeps the final claim honest. A registry can say IETF Review; it cannot make a future network recognize a new semantic. Code, configuration and observed traffic show adoption. That does not demote the registry. It limits the registry to the function it can actually perform.

RFC 9812 contains an apparently minor historical correction that reinforces this method. RFC 1881 had been shown in the RFC index as Legacy, although it was a joint IAB and IESG publication following IETF Last Call and belonged to the IETF Stream under RFC 8729. Correcting classification metadata does not rewrite the old delegation. It restores the evidence chain around it.

The security section is similarly restrained. RFC 9812 says the change has no direct security impact, while careful review of allocation mechanisms supports operational address accountability. The first clause is about this policy document. It is not a blanket claim that every later use of released space is safe. Security consequences arrive with the proposal, implementation, filtering and deployment.

For leaders, the practical artifact is an allocation receipt with layers that cannot be merged. Record the exact prefix and parent state. Preserve the draft, sponsor, stream and Last Call. Capture objections, IESG disposition and final RFC status. Record the IANA ticket, row, flags and timestamp. Then start a new ledger for downstream allocation, RPKI, routing, implementation, filters and measured service.

That discipline explains the title. The space was reserved, but nobody had been promised it. Executive approval was available, but the decision was too consequential to rely on optional documentation. Community review became mandatory, but it did not become sovereignty. The registry changed, but the packets had not yet moved.

Sources