Summary

  • RFC 9812 replaces IESG Approval with IETF Review for future non-routine use of IETF-reserved IPv6 space. It changes who must review a future decision and what public artifact that decision requires.
  • The RFC’s direct IANA action is a registration-procedure update. It does not choose a prefix, approve a purpose, delegate space to an RIR, authorize a route or prove deployment.
  • A reservation-to-use receipt should keep the standing policy, later request, IETF decision, exact registry mutation, delegation and operational observation separate; this is Daniel Kade’s editorial proposal, not an RFC field.

The registry row is easy to misread. A large portion of IPv6 space is labelled “Reserved by IETF,” and the registry now cites RFC 9812 for the applicable procedure. Put those two facts beside the phrase “IETF Review” and a loose account can sound as if the IETF has just released another address block.

It has not.

RFC 9812 is a short Best Current Practice about the gate through which a future decision must pass. Its direct effect is to replace the registration procedure shown for the IPv6 Address Space registry. The older label, IESG Approval, allowed the Internet Engineering Steering Group to approve an assignment case by case without necessarily requiring an RFC. The new label, IETF Review, requires an IETF-stream RFC, IETF Last Call and an IESG conclusion that the document has IETF consensus. The procedure is stricter because the record and review surface are larger.

That does not make the object on the other side of the gate real. No exact prefix is requested by RFC 9812. No intended use is selected. No downstream registry entry is created for a new purpose. No address is delegated to a Regional Internet Registry. No network originates a route. The RFC strengthens the conditions of a future act; it does not perform that act.

The reserve and the live pool are different states

RFC 9812 starts with the architecture of the namespace. 2000::/3 is the presently designated global-unicast range from which IANA assignments are recorded in the global-unicast registry. Much of the rest of the top-level space is retained as “Reserved by IETF” for possible future use if the current 125-bit unicast space becomes inadequate or inappropriate.

Reserved is a disposition, not a forecast. It does not mean unused in every subrange, available on request, owned by an operator, delegated to an RIR, accepted by routers or promised for release. The live IANA table itself carries qualifications: several top-level reserved ranges contain partial special-purpose allocations or historical uses. The label tells a reader where the authority to change the disposition sits, not what tomorrow’s addressing plan will be.

That distinction matters because the scale invites drama. RFC 9812 describes roughly seven-eighths of the whole address space as reserved. A large denominator can make a procedural change sound like a resource event. Yet the quantity placed behind a stronger gate has not been moved by the act of strengthening it.

IESG Approval and IETF Review are not synonyms

RFC 8126 defines the two policies precisely. IESG Approval permits the IESG to approve a new assignment without an RFC, although it can request documentation or consult the community. The mechanism is meant to be unusual: a fallback where another policy cannot be used in time or where a compelling reason exists. It is explicitly not a shortcut around public review that could have been used.

IETF Review demands a different chain. The assignment must be documented in an IETF-stream RFC shepherded through the IESG as a working-group or AD-sponsored document. It goes through IETF Last Call and receives IESG approval as representing IETF consensus. The RFC need not be Standards Track. That last boundary is deliberate: opening a new address range could need public IETF review without defining a new protocol standard.

RFC 9812 therefore changes the minimum proof of authority. A future allocation can no longer rest only on an exceptional IESG decision under this registry policy. It needs a durable IETF document and the public process that supports it. What becomes stronger is the provenance of the decision, not evidence that the decision has already happened.

One earlier allocation is an example, not the payload

The RFC points to 5f00::/16. RFC 9602 assigned that block for Segment Routing over IPv6 Segment Identifiers and added it to the special-purpose registry. The document moved through a working group and the stronger review path. RFC 9812 uses it to show that a substantial allocation could already satisfy IETF Review.

The chronology prevents a common error. RFC 9602 was published in October 2024. RFC 9812 followed in October 2025. The latter did not allocate 5f00::/16; it cited the earlier case when explaining the new standing policy. Nor does the example mean every future request should copy the SRv6 purpose, block size or registry destination. Each later request must name its own resource, intended use and IANA actions.

A governance account should therefore label 5f00::/16 as precedent evidence. It is neither a new allocation produced by RFC 9812 nor a prediction of the next reserved block to move.

A policy row is not an execution log

IANA registries do several jobs at once. They show present dispositions, references, sometimes dates, and the policy under which future changes may be made. Those fields relate to one another, but they are not one event.

RFC 9812’s IANA Considerations section asks for the procedure to become IETF Review. Once IANA performs that edit, the policy row proves what approval standard governs the next qualifying request. It does not prove that a request is pending. If a later IETF-stream RFC authorizes a prefix, that RFC proves the approved instruction. The changed registry row then proves that IANA executed the instruction. A later IANA-to-RIR delegation, route announcement and observed reachability would each require their own evidence.

Compressing this chain into “the IETF allocated space” destroys the question RFC 9812 was designed to answer: which public review made the change legitimate? It also creates false operational confidence. A registry reference cannot show that filters accept the range, equipment supports the use, routes propagate consistently or an application works.

The old document-status correction is another warning

RFC 9812 also addresses the status of RFC 1881. That 1995 document delegated management of IPv6 address space to IANA through a joint IAB/IESG publication that followed IETF Last Call. It had been listed as Legacy in the RFC index even though, under the later RFC-series framework, it belongs to the IETF Stream.

The correction is small but instructive. A metadata label can drift away from the procedure that actually produced the document. Fixing the label does not rerun the 1995 decision or change every operational allocation made since then. It repairs the record so that later readers can attribute authority correctly.

The same discipline should govern the new policy. Record what changed, under which document, in which registry and at what time. Do not infer a resource action merely from a procedural label.

Build a reservation-to-use receipt

A useful evidence record begins before any prefix moves. The reservation-to-use receipt proposed here is an editorial control, not a field in RFC 9812 or an instruction to IANA.

Its first layer records the standing state: exact registry, exact reserved range, applicable policy, controlling reference and observation time. Its second layer records a later request: requested prefix, purpose, requesting document, stream, sponsor, working-group state and the precise source and destination registries that would change.

The decision layer preserves Last Call, material revisions, consensus conclusion, IESG approval and the final RFC. The execution layer records each IANA mutation independently: old row, new row, reference, date and whether the action created, moved, split or reclassified space. No downstream action is marked complete merely because the RFC was published.

The operational layer is separate again. If relevant, it links an IANA-to-RIR allocation, RIR record, route origination, filtering observations and deployment claims to their own sources and dates. Unknown is a valid state. “Approved but not yet reflected,” “registered but not delegated,” and “announced but not broadly reachable” are not failures of the receipt; they are the distinctions it exists to preserve.

The minimum public statement can then be exact: the policy changed; a request entered review; a document was approved; IANA changed a row; an operator began use. Each verb closes only with its own evidence.

Accountability resides between the rows

RFC 9812 says the change has no direct security impact, while carefully reviewed allocation mechanisms are necessary for operational address accountability. That sentence does not promise that community review prevents every poor decision. It identifies the cost of an allocation whose authority and purpose cannot later be reconstructed.

The stronger procedure makes a future decision easier to inspect. It does not eliminate incentives to overstate the result. Authors may want to present policy progress as deployment progress. Operators may treat an assignment as proof that the wider Internet will accept it. Institutions may point to consensus without showing execution. Dashboards may show a registry state without its effective date or source decision.

The antidote is not another slogan about scarcity or abundance. It is a chain of attributable state changes. RFC 9812 changes the first state in that chain: the rule for making a major decision. The integrity of every later state remains to be earned.

Sources