prop-168: Increase to maximum IPv4 delegations

Current address policy only allows for the maximum delegation of up to and including a /23 to new and existing account holders.

This policy change will allow a sub-set of account holders with less than an aggregated /22 to receive an additional delegation of up to a maximum of a /22 IPv4 delegation.

Christopher Hawker

prop-168-v001.txt

prop-168-v002.txt

prop-168-v003.txt

This impact assessment is for v003

1. APNIC’s Understanding of the Proposed Policy

APNIC understands this proposal as allowing account holders with less than an aggregated /22 of IPv4 space to apply for additional IPv4 space, up to a combined maximum of /22.

Account holders who have transferred any IPv4 address space out of their accounts WOULD NOT be eligible for additional delegations.

No IPv4 transfers would be permitted for a period of 5 years for ANY delegated IPv4 address space from the date of the most recent delegation.

The proposal also reserves a /12 IPv4 pool for IPv4-to-IPv6 transition after the general available pool has been exhausted. APNIC secretariat has noted that this /12 would need to be reserved immediately if the proposal reaches consensus, because there would be nothing left to reserve once the available pool is exhausted.

APNIC Secretariat is requesting if this /22 maximum would also apply to any new member who applies after the policy is implemented.

2. Impact of Proposed Policy on Registry and Addressing System

Changes would be required to front-end and back-end systems to allow for:

• the increased delegations size

• transfer-lock calculations

• reservation and management of a /12 IPv4 transition pool

• separate rules for delegations for resources from the transition pool

Secretariat also notes that as of 13 August 2026, APNIC held 11,729 /24 IPv4 Prefixes. After reserving a /12, this would leave 7,633 available /24 prefixes which will not be sufficient if all eligible APNIC and NIR member request additional space.

As noted in the assessment for prop-168-v002:
There is already provision in policy for re-instatement of a waitlist (section 6.1) however this may require amendments as outlined below.

If this Proposal becomes Policy, the Secretariat suggests that the waitlist text in section 6.1 be changed from “A waiting list will be created once APNIC runs out of all IPv4 addresses.” to “A waiting list will be created once APNIC has exhausted the 103/8 IPv4 address pool.” This would allow for the waitlist to be created for ordinary IPv4 delegations while the proposed /12 reserved pool for IPv6 transition still exists (if that is the intention of the proposal).

3. Impact of Proposed Policy on APNIC Operation/Services

If this Proposal was to reach consensus, a high volume of applications would be likely and cause significant delays in processing.
APNIC would communicate those longer wait times to all applicants to set expectations.
Delegations made under this proposal would not be subject to the standard APNIC SLA framework.
APNIC will strive to maintain standard helpdesk SLAs to ensure continuity of service for regular helpdesk queries.

Changes would be required to back-end and front-end systems to re-instate the waiting list

A key operational issue is the proposed five-year transfer restriction. The proposal appears to apply the transfer lock from the date of the most recent delegation and to both market and M&A transfers.

APNIC secretariat has noted that this may conflict with examples provided by the author on the mailing list on 10 August 2026, and should be clarified.

4. Legal Impact of Policy

Much of this has already been covered in the previous impact assessment.

Changes are recommended to the Proposal to ensure consistency of language and use of terminology such as “available pool” (the policy document does not use the term “available pool” at present, instead referring to “103/8 pool”). We note the proposed removal of paragraph 3 from section 6.1 will remove the references to “recovered non-103/8 resources [being] considered the same as 103/8 addresses” which would suggest that recovered non-103/8 resources are to be treated differently if this Proposal becomes policy.

Clarity is also requested from the author on whether the Proposal is intended to impact any other policies such as IXP (6.2.4), temporary assignment (15.1), or experimental (5.7) policies.

For Example: Company A can join and apply for /24 under last /8 policy and grow that up to /22. After that, they can apply for /26 under prop-154 IXP policy and grow that up to /22 as IXP assignments are not delegated under the last /8 policy. In this way, company A ends up with total of /21 IPv4.
Company B can join and apply for /26 under prop-154 IXP policy and grow that up to /22. They can also apply for /24 under last /8 policy but they will only be able to grow that to /23 because they already hold /22 under IXP policy.

The addition of Section 5.1.5 may create a procedural and timing conflict as the trigger event for enablement of the /12 pool in this proposal is the exhaustion of the available address pool which is also the trigger event for the /16 reservation under section 5.1.1 (from Prop-62). It is unclear if the intention is for the /12 pool in this proposal to only come into effect after the /16 pool in section 5.1.1, or at the same time.

The Secretariat notes that the changes in section 11.1.1 would not apply to resources that have been transferred in by account holders from other RIRs

5. Implementation

If this policy was to reach consensus

Changes would be required to front-end and back-end systems to allow for:

• the increased delegations size

• transfer-lock calculations

• reservation and management of a /12 IPv4 transition pool

• seperate rules for delegations for resources from the transition pool

Changes would also be required to APNIC-127

Implementation would be approximately 9 months subject to call for editorial comments.

prop-168-v001-IA.txt