In the weeks since we last published about policy development, the community have contributed five policy proposals for discussion at the Open Policy Meeting (OPM) on 11 September at APNIC 60 in Da Nang, Viet Nam.
Here’s what you need to know about the proposals so that you are ready for what is shaping up to be some robust discussion.
prop-162-v003: whois privacy
The aim of this policy proposal, according to its authors, is to prevent potential abuse of information in bulk whois data. It was first presented at APNIC 59, but did not reach consensus.
The proposal recommends that APNIC remove from bulk whois data resource holder contact information like telephone numbers, email, and physical addresses. The information removed from bulk whois data would still be available through normal whois and Registration Data Access Protocol (RDAP) queries to those with a legitimate need.
Existing re-publishers of bulk APNIC whois data would be required to remove the same information as a condition for ongoing access.
It should be noted that APNIC will have a limited ability to monitor compliance with this change, unless a clear breach of the Acceptable Usage Agreement (AUA) (APNIC-091) has occurred and the breach can be attributed to a specific party.
If this proposal were to reach consensus, it would require significant work from APNIC to:
- Update the AUA.
- Revoke access to bulk whois data from current users.
- Create a system to record acceptance of the new terms of use.
- Ensure compliance with the policy.
prop-164-v002: Allocations of IPv6 Resources longer than a /32 with a nibble boundary alignment
The aim of this policy proposal, according to its authors, is to provide more accurate data about sub-assignment of IPv6 resources by reducing the minimum allocation size of IPv6 prefixes from a /32 to a /36.
The Secretariat notes that discussion of the proposed policy could benefit from a few clarifications.
- One of the proposed changes is an update to the section of the APNIC Internet Number Resource Policies that describes how Local Internet Registries (LIRs) are allowed to assign number resources to downstream, subordinate Internet Service Providers (ISPs). The proposed change (“Add a new line that reads: ‘When an LIR makes a delegation to an ISP'”) does not specify downstream ISPs and could unintentionally expand the scope of the policy.
- The proposed policy does not seem to have considered a situation where a resource holder ‘returns’ the balance of their /32 and holds only a /36.
- The proposed policy uses allocation, assignment, and delegation interchangeably, which may make the policy less clear.
To provide an indication of the impact of this proposed policy change, as of 14 August 2025, there are 3,095 resource holders that hold a /48 IPv6 assignment and either a /23 or /24 IPv4 assignment.
APNIC anticipates that the proposed policy would result in an increase in Members returning larger IPv6 assignments in exchange for /36 assignments, with a resulting workload increase on the Member Services team.
If the proposed policy were to reach consensus, there would be some additional changes to the policy text and changes to front and backend systems.
prop-165-v001: Provision of IPv4 Address Space to IPv6-only Networks for Transitional Purpose
The aim of this proposed policy, according to its authors, is to support the deployment of IPv6-only networks that still require minimal IPv4 resources for transitional purposes.
The proposed policy uses the terms ‘Provider Aggregatable (PI)’ and ‘Provider Independent (PI)’, which have no exact equivalents in the existing policy definitions (APNIC-127), and are not defined in the policy proposal. This discrepancy in terms makes the policy proposal unclear.
The Secretariat has interpreted the intent of the proposed policy as making it easier for resource holders to transition to completely IPv6-based networks by reducing the requirements to receive IPv4 resources needed for the transition.
Specifically, the Secretariat understands that the authors believe the burden of proof for these networks to justify their needs for IPv4 resources might be too high under current policy.
The Secretariat has the following questions in relation to the proposed policy for which clarification is requested:
‘Organizations qualifying for IPv6 PA allocations may request an IPv4 /24‘: The maximum IPv4 delegation under current policy size is a /23. Will this /24 count toward the resource holder’s last /8 holding? If so, can they also apply for their second /24 under regular IPv4 policy?
‘The IPv4 block must be used only for IPv6-only network support’: How should the Secretariat monitor if the resource holder’s IPv4 is being used to support the resource holder’s IPv6-only network and not being used for some other purpose?
‘The block is non-transferable and cannot be leased’: How should the Secretariat monitor if the address is being leased?
‘Additional usage restrictions apply in accordance with current APNIC policies’: Most existing usage restrictions are based on the needs justification required under section 6.2 of APNIC-127, which the proposed policy appears intended to remove. Which specific existing usage restrictions are intended to apply?
If this proposal were to reach consensus, there would be additional work required on the core registry front and back-end systems.
Additional changes to APNIC’s operating procedures will be required to account for exceptions to standing policy, including with respect to reduced demonstrated need (section 6.2 of APNIC-127) and the modified transfer restriction period (section 11 of APNIC-127).
prop-166-v001: Revocation of persistently non-functional RPKI certification authorities
The aim of this proposed policy, according to its authors, is to reduce the relying party workload caused by persistently non-functional RPKI Certificate Authorities (CAs).
This proposed policy would require that APNIC revoke the Resource Public Key Infrastructure (RPKI) certificate for any self-hosted CA that has not updated their manifest or Certification Revocation List (CRL) for longer than 60 days.
Revoked certificates could still be recreated through the normal processes.
It is the Secretariat’s understanding that self-hosted CA RPKI objects, especially ROAs, will not be impacted, nor would National Internet Registry (NIRs) CAs.
The policy proposal uses ‘Delegated CA’ instead of ‘self-hosted’, however, the terms are understood to be interchangeable, and the discrepancy can be resolved in the editorial and comment process (APNIC-112).
If the policy proposal were to reach consensus, the Secretariat anticipates a slight increase in the number of requests to the Member Services team from non-functional CA operators.
Software updates would be required to deliver the following:
- Monitor manifests and CRLs published by each self-hosted CA at a nominated interval.
- Remove self-hosted CAs and revoked resource certificates if APNIC is unable to discover and validate a self-hosted CA’s current manifest and CRL for more than 60 days.
- Send warning emails to known contacts of the self-hosted CA before removing the self-hosted CA.
Additionally, updates would be required to the APNIC Certification Practices Statement (CPS) , and the RPKI Terms and Conditions to encompass the proposed policy requirements.
prop-167-v001: Published statistics on Directory Service usage
The aim of this policy proposal, according to its authors, is to provide APNIC Members and stakeholders with visibility into the use of whois and RDAP services.
This policy proposal would require APNIC to provide resource holders and other stakeholders with visibility into the use of whois and RDAP services.
APNIC would be required to publish statistics, updated hourly in a machine-readable format, about queries received by the whois and RDAP services, including:
- Source Autonomous System Number (ASN) (for at least the top 1,000 ASNs).
- Source IP address per ASN.
- Service (whois vs RDAP).
- Metadata such as query type and method.
This data is already available to our technical teams for internal use. If this policy proposal reaches consensus, APNIC will have to develop a method for extracting and publishing the requested data.
Additionally, if accepted, the proposed collection and publication of service usage data will be integrated into ongoing work at APNIC to develop an enhanced privacy compliance program.
Join the discussion
If you haven’t already, now’s the time to read all of the proposals, join the mailing list, and have your say, whether in person in Da Nang or online.
The Policy SIG welcomes all voices, experienced or new, in shaping the future of Internet number resource management in the Asia Pacific.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.