While I support the idea of giving more v4 address space (I twice proposed to do this in the past) but I believe that ship has sailed. I pulled the APNIC delegation records and ran the numbers against the Secretariat's latest impact assessment, and I think prop-168 has a feasibility issue worth discussing:
- Eligible population is large: 15,037 account holders (58% of everyone ever delegated APNIC IPv4) currently hold less than /22, so under v3's objective, just "less than /22" - all of them would qualify for a top-up. - Pool can't cover demand as we can see as per the Secretariat's note, APNIC holds 11,729 x /24, dropping to 7,633 x /24 after the mandatory /12 IPv6-transition reservation. Demand from the full eligible population is ~33,231 x /24 - the pool covers only ~23% of that. Even the age-based subset that joined post-2019 alone needs ~25,432 x /24, still leaving the pool covering under a third but then there is no coverage for only post-2019 eligible holders. - Since supply falls well short of demand, APNIC will need to reinstate the old waitlist mechanism (section 6.1) to manage this. That's not just a policy text change - it's an ongoing operational process: every application in queue has to be reviewed for eligibility, approved applicants get delegated space, rejected ones free up their place so the next applicant in line can be pulled in and reviewed. At the volumes implied by 15,037 potentially eligible entities against a 7,633 x /24 pool, this becomes a large, indefinite administrative workload, policy doesn't talk about implementation mechanism leaving this for secretariat misinterpretation. - NIR timing compounds this issue as a large share of eligible entities (mostly Indonesia and India) are served via NIRs, not direct APNIC membership. NIRs need to separately implement the policy before distributing to their members. If EC holds a moratorium until all NIRs are ready, demand likely arrives in one large wave rather than gradually - accelerating exhaustion and pushing most applicants straight into the queue described above. We are talking about applications received at what minute and at what second. Thats not equitable process. - Other open items from the Secretariat's assessment also require some clarification, transfer-out exclusion isn't yet reflected in eligibility criteria, the 5-year transfer lock applies to an applicant's entire existing holding (not just the top-up), and there's a sequencing conflict between this proposal's /12 reservation and the existing /16 reservation under section 5.1.1. Which one holds. Given the pool covers well under a third of demand and would require standing up an ongoing queue-management process, I don't think this is implementable and status-quo is the best solution we have now unless you want to go down to /24 allocation only to all eligible members rather. Regards, Aftab A. Siddiqui On Tue, 18 Aug 2026 at 09:38, Dave Phelan <[email protected]> wrote: > Dear SIG Members, > > Please find below the Secretariat impact assesment for prop-168-v003: > Increase to maximum IPv4 delegations > > > > Dave Phelan > > Policy Manager and Senior Network Analyst > > > > ----- > 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 > - > > seperate 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. > > > _______________________________________________ > SIG-policy - https://mailman.apnic.net/[email protected]/ > To unsubscribe send an email to [email protected]
_______________________________________________ SIG-policy - https://mailman.apnic.net/[email protected]/ To unsubscribe send an email to [email protected]
