Summary

  • Prop-165 version 4 would offer one non-transferable IPv4 /24 to an organisation eligible for an initial IPv6 allocation, specifically for an IPv6-only deployment and its transition services.
  • The block would remain within the recipient's existing IPv4 entitlement, be linked in APNIC's registry to the qualifying IPv6 allocation, and be subject to declaration-based review and return conditions.
  • A rate-based exhaustion trigger or a community-set reserve threshold would stop new delegations, but demand, review frequency, compliance practice and the final APNIC 62 outcome remained unknown at the reporting freeze.

An IPv6-only network can still encounter a stubbornly IPv4-shaped edge. The proposal's authors point to DNS resolvers, mail gateways, monitoring, logging and access to legacy IPv4-only services as examples of functions for which a small IPv4 block may remain operationally useful. Prop-165 version 4 attempts to meet that residual need without treating it as a general route to more IPv4 space.

The current text, posted on 27 August 2026, would make an organisation eligible for an initial IPv6 allocation eligible to request one IPv4 /24. The applicant would submit an IPv6-only Deployment Declaration describing the deployment, its transitional services and its compliance with the policy. It would not have to justify the block by counting IPv4 hosts.

That is an important design choice. The proposal substitutes a bounded purpose and continuing obligations for conventional address-by-address need evidence. APNIC could request evidence that the IPv6-only deployment exists or is being implemented. Periodic review, however, would be declaration-based and would not require technical inspection of the member's network.

The proposed grant would not enlarge the recipient's overall IPv4 ceiling. It would come from APNIC's Final /8 pool, count toward the organisation's existing IPv4 entitlement and be recorded with its policy basis. Registry records would link it to the qualifying IPv6 allocation. The block would have to be used primarily for the declared IPv6-only network and transition functions, and it could not be transferred, reassigned or made available to another organisation.

Return conditions would follow the same linkage. The recipient would have to return the /24 if it returned the associated IPv6 allocation, ended the declared deployment, no longer needed the transition functions or ceased to satisfy the policy conditions. In other words, version 4 frames the IPv4 block as a revocable bridge attached to an IPv6 deployment, rather than a free-standing asset.

The proposal also includes a sunset mechanism. New delegations would stop if APNIC projected that the available pool would be exhausted within six months, using the preceding 12 months' average delegation rate, or if the pool reached a reserve threshold determined by the community. APNIC would publish the remaining pool and projected exhaustion date at least quarterly. Applications already approved would continue; applications not yet approved would be assessed under the policies then in force.

The text was listed as “For Discussion at APNIC62 OPM” when this report was frozen on 4 September 2026. That status is not consensus, adoption or implementation. The proposal names Tomohiro Fujisaki and Hiroki Kawabata as its authors, so claims about expected benefits and burdens should be understood as their case for the change unless APNIC independently establishes them.

The Secretariat material displayed with the proposal requires a further time distinction. APNIC posted an impact assessment for version 3 on 18 August, nine days before version 4 was posted. The assessment reported that 1.2% of APNIC members held IPv6 but not IPv4 as of 30 June 2026. It also identified registry changes needed to mark and link these delegations, and raised questions about monitoring transitional use, temporary reassignment, periodic review, sunset calculation, an unspecified community threshold, Executive Council discretion and applications in progress.

Version 4 addresses some, but not necessarily all, of those concerns. It removes the version-3 Executive Council sunset trigger and states how approved and unapproved applications would be handled when the sunset activates. The displayed assessment is not labelled as a fresh assessment of version 4, so it should not be treated as confirmation that every operational question has been resolved or that an implementation timetable exists.

Sources