Dear Policy Dave, SIG Chairs, and Community,

Thank you for the Secretariat's detailed review and impact assessment
of prop-165-v003.

We appreciate the constructive feedback and the effort invested in
analysing the proposal and its implementation implications. We would
like to provide the following clarifications and possible refinements
for community consideration.


- Monitoring use of IPv4 resources for IPv6-only network support

The intent of this proposal is not to create a new continuous
compliance monitoring framework or require APNIC to actively inspect
network operations.

Our expectation is that applicants would submit an IPv6-only
Deployment Declaration describing:

 - the planned IPv6-only deployment;
 - the transition-related services requiring IPv4 connectivity; and
 - the intended use of the requested IPv4 /24.

In response to the Secretariat's question regarding how APNIC might
determine whether the resources continue to support an IPv6-only
deployment, we believe a declaration-based approach supplemented by
reasonable evidence may be sufficient.

Historically, APNIC has assessed specialised policy requests by
requesting evidence of operational requirements. For example, during
the transition from 2-byte to 4-byte ASNs, applicants seeking
continuation of a 2-byte ASN could be required to demonstrate that
they operated equipment or software that was not compatible with
4-byte ASNs.

A similar approach could be applied here. Where necessary, APNIC may
request supporting evidence that the member operates IPv6-capable
infrastructure or services associated with the declared IPv6-only
deployment.

The authors do not expect APNIC to perform technical audits or ongoing
operational monitoring. Instead, any review should remain lightweight
and declaration-based.

To further clarify this intent, the authors are considering replacing:

  >  "must be used solely to support IPv6-only network operations and
related transitional functions"

with:

  >  "must be used primarily to support IPv6-only network operations
and related transitional functions, as described in the applicant's
deployment declaration."


- Clarification regarding reassignment

The phrase:

  >  "must not be permanently reassigned to another organisation"

was intended only to prevent transfer of control of the resource to
another legal entity.

It was not intended to establish a distinction between permanent and
temporary reassignment.

To remove ambiguity, we propose replacing this text with:

  >  "must not be transferred, reassigned, or otherwise made available
for use by another organisation."

This wording more clearly reflects the intended policy objective.


- Clarification regarding periodic review

The periodic review mechanism is intended to be lightweight and
administrative in nature.

The review would be limited to confirming that:

 - the associated IPv6 allocation remains valid;
 - the IPv6-only deployment remains operational; and
 - the delegated IPv4 resources continue to be required for
transitional purposes.

Where necessary, APNIC may request an updated IPv6-only Deployment
Declaration and supporting information relevant to the deployment.

No detailed utilisation calculations, host-count justifications, or
technical inspections are intended.


- Clarification regarding the Sunset Provision

We agree with the Secretariat that additional specificity would assist
implementation.

The current proposal uses a forecast-based trigger:

 > APNIC projects that the IPv4 address space available for delegation
under the Final /8 Policy will be exhausted within six months, based
on the average allocation rate during the preceding twelve-month
period.

We continue to believe this is an objective and transparent mechanism.

However, an alternative approach may be to maintain a fixed
reservation from the remaining Final /8 pool.

For example, the policy could cease issuing new delegations when the
available Final /8 pool falls below a reserved operational threshold,
such as a /15 equivalent of IPv4 address space.

Such an approach may provide a simpler and more predictable
implementation model because it relies on an absolute inventory
threshold rather than a forecast of future consumption.

The authors welcome community input regarding whether:

 - a forecast-based threshold;
 - a fixed-reserve threshold; or
 - a combination of both

would be more appropriate.


- Applications in progress

We agree that applications already under assessment should be
addressed explicitly.

The authors propose:

> Applications approved prior to activation of the sunset condition shall 
> continue to be processed normally.
>
> Applications that have not yet been approved at the time the sunset condition 
> is activated shall be assessed under the policies then in force.


- Operational impact

We acknowledge that implementation would require APNIC to:

 - identify delegations made under this policy;
 - link them to the qualifying IPv6 allocation; and
 - support a declaration-based review process.

However, the Secretariat notes that only approximately 1.2% of APNIC
members held IPv6 resources without IPv4 resources as of 30 June 2026.

Given the limited target population and the restriction of one /24 per
eligible organisation, we expect the operational impact to remain
relatively small.


- Conclusion

The authors thank the Secretariat for the detailed assessment.

Based on this feedback, we are considering revisions that:

 - clarify that review is declaration-based;
 - permit supporting evidence where appropriate;
 - remove ambiguity regarding reassignment;
 - simplify and clarify the sunset mechanism;
 - define handling of applications already in progress; and
 - minimise operational overhead while preserving the policy objective
of supporting IPv6-only deployment.

We look forward to further discussion from the community.

Kind regards,

Tomohiro Fujisaki
Hiroki Kawabata

Authors, prop-165

2026年8月18日(火) 8:59 Dave Phelan <[email protected]>:
>
> Dear SIG Members,
>
> Please find below the Secretariat impact assesment for prop-165-v003 : 
> Provision of IPv4 Address Space to IPv6-only Networks for Transitional Purpose
>
>
>
> Dave Phelan
>
> Policy Manager and Senior Network Analyst
>
>
>
> -----
>
> 1. APNIC’s Understanding of the Proposed Policy
>
> APNIC understands this proposal as allowing members that hold an IPv6 
> allocation to request one IPv4 /24 delegation for IPv6-only network 
> transition purposes.
>
> The proposal is expected to affect a limited number of members. APNIC 
> Secretariat notes that, as of 30 June 2026, 1.2% of APNIC members held IPv6 
> but not IPv4.
>
> The proposal states that the IPv4 block must not be permanently reassigned to 
> another organisation.
>
>
>
> 2. Impact of Proposed Policy on Registry and Addressing System
>
> Registry systems would need to identify IPv4 /24 delegations made under this 
> policy, link them to the member’s IPv6 allocation, and apply the specific 
> policy conditions.
>
> Additional clarification may be needed on whether these blocks can be 
> temporarily reassigned or sub-assigned, given the proposal only prohibits 
> permanent reassignment
>
> The following question from the previous assessment still remain outstanding
>
> How should the Secretariat monitor if their IPv4 is being used to support 
> their IPv6-only network and not being used for some other purpose?
>
> 3. Impact of Proposed Policy on APNIC Operation/Services
>
> APNIC would need to create an assessment process for requests under this 
> policy and provide guidance on how to conduct periodic reviews.
>
> The Secretariat is requesting guidance on how they should periodically check 
> whether the IPv4 resources remain necessary for transitional purposes.
>
> The sunset provision requires further clarification before implementation. 
> The proposal includes three separate triggers: projected exhaustion of the 
> Final /8 pool within six months, a community-determined minimum threshold, 
> and a determination by the APNIC Executive Council that continued operation 
> would materially threaten equitable access to remaining IPv4 resources.
>
> APNIC would need a clear operational method for applying these triggers, 
> including how exhaustion projections are calculated, how often they are 
> reviewed, what data is used, and how the result is published. The proposal 
> does not currently define the community threshold, which would need to be 
> specified before that trigger could be implemented.
>
> The EC-based trigger would also require clarification, including the criteria 
> for making such a determination, whether the suspension of new delegations is 
> temporary or permanent, and how this interacts with the normal policy process.
>
> 4. Legal Impact of Policy
>
> We note that the phrase ‘permanently re-assigned’ implies some form of 
> reassignment may be allowed, provided it is not permanent. It would be 
> helpful to understand if there is a deliberate intention behind this to guide 
> our interpretation and the development of corresponding procedures.
>
> The Proposed Policy will require a number of amendments to APNIC-127, however 
> the specific implementation of such changes has not been made clear by the 
> Authors. This uncertainty may create a number of enforcement and assessment 
> challenges depending on its implementation, which can be considered further 
> following clarification of the Secretariat’s questions in other parts of this 
> impact assessment.
>
> 5. Implementation
>
> Implementation would require clarification of the sunset mechanism, including 
> the calculation method for projected exhaustion, the value and form of the 
> community-determined threshold, and the process for any EC determination. 
> APNIC would also need to define how applications in progress are handled if a 
> sunset condition is triggered.
> Until such point as these clarifications are made, we are unable to make a 
> determination on implementation process and time frames.
>
> _______________________________________________
> SIG-policy - https://mailman.apnic.net/[email protected]/
_______________________________________________
SIG-policy - https://mailman.apnic.net/[email protected]/
To unsubscribe send an email to [email protected]

Reply via email to