Summary

  • APNIC proposal prop-165 v004 would let an organization eligible for an initial IPv6 Provider Aggregatable allocation request one IPv4 /24 for specified transition services, without detailed host-count justification.
  • The proposal includes a declaration, periodic review, mandatory return triggers and pool-level sunset rules. Whether these controls form a credible exit path depends on how APNIC applies them while avoiding an inspection duty the text does not require.

An IPv6-only network is not necessarily an IPv4-free network. It may need to resolve names for a service that answers only over IPv4, exchange mail through a gateway, collect monitoring data from a legacy endpoint or keep logs moving across a mixed environment. These are not reasons to build a second general-purpose IPv4 network. They are the sort of remaining dependencies that can complicate a transition even when the operator intends to use IPv6 for the network itself.

That distinction is the starting point of APNIC proposal prop-165 v004. Published for discussion on 27 August 2026, it would let an organization eligible for an initial IPv6 Provider Aggregatable allocation request a single IPv4 /24. The proposal names DNS resolvers, mail gateways, network monitoring, logging and access to IPv4-only services as possible transitional uses. It says no detailed host-based IPv4 justification would be required. The applicant would instead file an IPv6-only Deployment Declaration describing the intended deployment, the services that require IPv4 connectivity and its acknowledgement of the conditions.

This is a proposed exception to a familiar allocation logic. A needs test based on the number of planned IPv4 hosts would be awkward for a network designed to use IPv6 internally but still dependent on a narrow set of IPv4-facing services. The proposal’s declaration model asks a different question: is the organization building or operating the described IPv6-only environment, and does the small IPv4 delegation support its transition? APNIC may request reasonable supporting information, such as documentation of the deployment, IPv6-capable equipment or services operating within the declared environment.

The text frames that request as proof that the deployment exists or is being implemented, rather than a detailed inventory of IPv4 hosts.

The one-block limit is only one part of the conservation design. The proposed /24 would come from APNIC’s Final /8 pool. It would count toward the recipient’s existing maximum IPv4 entitlement and would not increase the total IPv4 holdings that the organization is permitted to hold. The block would be marked in APNIC registry records and linked to the IPv6 allocation that qualified the organization. It could not be transferred, reassigned or made available for use by another organization. Those provisions make the exception visible in the registry and constrain its use as an asset that can move to a different holder.

The limit also sets up the proposal’s central operational test. A /24 can be small relative to a network’s total address demand while still being consequential to an organization that has no other IPv4 allocation. The text does not estimate the number of eligible applicants or the amount of demand. Nor does it report a measured outcome: v004 is a policy proposal, not a record of allocations made under the proposed rule. The relevant question is therefore how the safeguards would work if the proposal were adopted, not whether a claimed benefit has already been observed.

The proposal uses three layers of continuing control. First, the recipient must use the block primarily to support the IPv6-only network operation and related transition functions described in its declaration. Second, APNIC may periodically ask whether the linked IPv6 allocation remains valid, the IPv6-only deployment remains operational and the IPv4 resource is still required for transition purposes. The review is declaration-based and does not require technical inspection of the member’s network.

Third, the recipient must return the IPv4 block if its associated IPv6 allocation is returned, the IPv6-only deployment ceases, the transition need ends or the policy conditions are no longer met.

Together, those rules describe a lifecycle rather than a one-time allocation. But a lifecycle is only as clear as the state changes that move a resource from one stage to another. “Primarily” supporting the declared network leaves room for operational judgment. A resolver serving both IPv6 and IPv4 clients may support the IPv6-only deployment while also doing broader work. A gateway may remain in service because an external service still accepts only IPv4, even as the operator’s internal network becomes more fully IPv6-capable.

The proposal says what a recipient must declare and when the resource must be returned, but it does not prescribe a technical metric for how much transition work is enough or how APNIC should distinguish continuing need from convenience.

That gap is not necessarily a flaw. A rigid measurement could require intrusive inspection, expose operational details or impose a heavier burden than the small allocation warrants. The proposal explicitly avoids a technical inspection requirement. Yet a review that relies only on repeated declarations could become a paper ritual if a member can renew the same statement without explaining what remains dependent on IPv4, what has changed since the previous review or what would count as the end of the transition need.

A practical review could remain declaration-based while still asking for a dated account of the service dependency: which transition functions use the block, whether those functions are operating, what material change has occurred since the last confirmation and what condition would permit release. APNIC could request supporting information where a declaration leaves a material question open; v004 already permits reasonable requests to assess whether the deployment exists or is being implemented. That is different from requiring continuous technical monitoring of a member’s network.

The proposal does not specify such a review form or timetable, so this is an implementation question, not a requirement already stated in v004.

The return triggers are stronger when read as separate observable events. Returning the qualifying IPv6 allocation is a direct registry state. A deployment ceasing operation is a change in network operation. A transition need ending is a judgment about the service environment. A failure to satisfy policy conditions is a compliance conclusion. These events will not always arrive together or be equally easy to establish. The distinction matters because one generic annual affirmation could obscure a return trigger that has already occurred.

A clear process would tell recipients what change they must report, how APNIC confirms it and what happens when a review response is missing.

The proposal’s sunset addresses the shared pool rather than the continued need of any one recipient. APNIC would stop issuing new delegations if its 12-month average monthly IPv4 delegation rate projected the Final /8 pool to be exhausted within six months, or if the remaining pool fell below a minimum reserve determined by the APNIC community. APNIC would publish the projected exhaustion date and remaining space at least quarterly. Once a trigger activated, no new blocks would be issued under the proposed policy.

Existing delegations could continue if compliant; approved applications would keep being processed, while applications not yet approved would be assessed under the policies then in force.

This separates two decisions that can easily be confused. A pool-level sunset can stop new awards without proving that an existing recipient no longer needs its block. Conversely, an individual return rule can recover a block even when the pool remains above the sunset threshold. A credible design needs both: a fair rule for the next eligible organization and a rule for ending an individual delegation when its purpose has expired.

The reserve trigger is transparent in concept but incomplete in value until the community chooses the minimum. The six-month trigger is more explicit: it uses the previous 12 months’ average monthly delegation rate. A projection is still a projection. Its usefulness depends on publishing the input period, remaining pool, calculation and any material change from the previous quarter in a form that readers can compare. The proposal commits to quarterly publication of the projected exhaustion date and remaining space, but it does not specify the publication format or calculation details.

Those details would make the automatic stop easier to understand when conditions change quickly.

The official status also sets a boundary on what can be concluded. The APNIC 62 report lists prop-165 among proposals for which no consensus call was held. The APNIC proposal page continues to describe the proposal as under discussion and labels the Secretariat impact assessment posted there as applying to v003. That earlier assessment raised implementation questions about monitoring, review and sunset mechanics, but it is not an assessment of v004. Version 004 was published after it. The available official record therefore supports neither a claim that the proposal was adopted nor a claim that participants rejected its substance.

Heng Lu’s Note 73 offers a useful discipline here: a room of participants and a decision with a defined mandate are not the same thing. Applied narrowly, that means treating the APNIC meeting record as evidence of process status, not as an endorsement that the record does not state. It does not determine whether prop-165 is good policy. That judgment depends on the proposal’s mechanics and on the evidence APNIC would publish if a rule were adopted.

The most consequential test is whether the proposal can keep the allocation small in purpose as well as in size. The /24 cap, Final /8 accounting, recipient entitlement limit and no-transfer condition address the initial grant. The declaration and return conditions address the recipient’s continued need. The sunset and quarterly reporting address the pool. If those records are linked and updated when the underlying states change, the exception could function as a bounded transition aid. If they are treated as unrelated paperwork, the initial cap will not by itself show that the bridge has remained temporary.

For operators, the proposal points toward a simple discipline: document which IPv4-facing functions remain in the transition plan and identify the event that would allow each one to be retired. For APNIC, the design challenge is to keep the review proportionate while making the return events legible to both recipient and registry. For policy participants, the open questions are specific: what evidence is enough to establish continued transitional need without technical inspection, how “primarily” will be interpreted, what reserve protects the remaining pool and how the quarterly projection can be checked over time.

A small block can reduce friction at the edge of an IPv6 deployment. It cannot make an incomplete transition complete by itself. Prop-165 v004’s strongest idea is that the exception should expire when either its individual purpose ends or the shared pool reaches a published stopping point. Its credibility will rest on whether those exits are clear enough to act on, and public enough to be examined.

Sources