[arin-ppml] Summary & Update: Draft Policy ARIN-2023-8: Reduce 4.1.8 maximum allocation

Fri Jun 27 19:35:27 EDT 2025

As long as those currently on the wait list are handled first with current allocation request, I have no problems. 
I would hate to see my request of over 2 years go away. 

Thanks 

From: "Gerry E.. George" <ggeorge at digisolv.com> 
To: "Scott Leibrand" <scottleibrand at gmail.com> 
Cc: "ARIN PPML" <arin-ppml at arin.net>, "Brian Jones" <brian.jones at vt.edu> 
Sent: Friday, June 27, 2025 11:06:12 AM 
Subject: Re: [arin-ppml] Summary & Update: Draft Policy ARIN-2023-8: Reduce 4.1.8 maximum allocation 

Scott, 

To clarify, the policy has not been revised, in as much that the language has been clarified (to align with the NRPM (2025.1), which does not materially change the policy. The main objective of the policy remains the same. 

The other changes (prior to ARIN 55, done in September 2024 & February 2025), were to add protection to those already on the waitlist, and to make some grammatical corrections and clarify the language to remove some ambiguity. 

Gerry E. George 
ICT Consultant and Business Solutions Architect; 
Digi Solv , Inc. [P.O. Box 1677, Castries, Saint Lucia] 

Mobile : (758) 728-4858 / Int'l Office : (347) 450-3444 / Skype: DigiSolv 
Email : [ mailto:ggeorge at digisolv.com | ggeorge at digisolv.com ] / LinkedIn : [ https://www.linkedin.com/in/gerrygeorge/ | https://www.linkedin.com/in/gerrygeorge/ ] 

Please consider the environment before printing this email. Thank you. 

From: "Scott Leibrand" <scottleibrand at gmail.com> 
To: "Gerry George" <ggeorge at digisolv.com> 
Cc: "ARIN PPML" <arin-ppml at arin.net>, "Brian Jones" <brian.jones at vt.edu> 
Sent: Thursday, June 26, 2025 9:10:24 PM 
Subject: Re: [arin-ppml] Summary & Update: Draft Policy ARIN-2023-8: Reduce 4.1.8 maximum allocation 

This revised policy seems like a sensible compromise to me. 
-Scott 

On Thu, Jun 26, 2025 at 12:48 PM Gerry E.. George < [ mailto:ggeorge at digisolv.com | ggeorge at digisolv.com ] > wrote: 

Draft Policy ARIN-2023-8 - Reduce 4.1.8 Maximum Allocation 

June 25, 2025 

PREAMBLE: 

This draft policy was accepted as a proposal on October 26, 2023 and became a Draft Policy on November 21, 2023. 

It has been revised on 2 previous occasions – February 14, 2024 to correct some typos and to make adjustments to the text/wording, and in September 30, 2024 to make allowance for “grandfathering clause” 

The last revision – May 2025 was to synchronize the text of the draft policy to be in line with changes to the NRPM (2025.1) 

The draft policy has also been presented at ARIN 53 (Barbados), 54 (Toronto, Ontario) and 55 (Charlotte, VA). 

As the lead shepherd assigned with the responsibility for this draft policy, I are attempting determine a definitive direction or preference by the community, in order to move forward. I have taken the liberty to summarize the various positions, opinions and discussions in this comprehensive (and long) post, in order to have all of the relevant information in one place to help with distilling the various viewpoints and the available options. I hope this will help distill the associated issues and evoke some guidance from the community. 

Proposed Draft Policy (May 2025) : 

ARIN-2023-8: Reduce 4.1.8 maximum allocation 

Problem Statement: 

4.1.8 waiting times are too long, making justifications untimely by the time a request is met. New entrants to the waiting list are expected to wait three years for their need to be met under current policy, with a waiting list of around 700 at this point. Data indicates that reducing the current /22 maximum further to a /24 would significantly reduce this waiting period, and further tightening the requirements by replacing the /20 recipient maximum holdings with a /24, and preventing multiple visits to the waiting list queue. 

Policy Statement: 

PROPOSED UPDATED TEXT (4.1.8 maximum allocation ) : 

4.1.8. ARIN Waitlist 

ARIN will only issue future IPv4 assignments/allocations (excluding 4.4 and 4.10 space) from the ARIN Waitlist. The maximum size aggregate that an organization may qualify for is a /24. 

Organizations that have ever held any IPv4 space other than special use space received under section 4.4 or 4.10 are not eligible to apply. 

Address space distributed from the waitlist will not be eligible for transfer, with the exception of Section 8.2 transfers, for a period of 60 months. This restriction will be applied to all distributions from the waitlist to also include those organizations or requesters currently listed. 

Qualified requesters will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. 

Waiting list recipients must demonstrate the need for a /24 on an operating network. 

The limitation to a single /24 will be enforced for waitlist requests submitted after this policy takes effect, and will only apply to new entrants to the waitlist. Requests received before the policy change will be evaluated based on the policy in place at the time of the request. 

Note: Sections 4.1.8.1 Sequencing, 4.1.8.2 Fulfillment and 4.1.8.3 Qualification remain unchanged. 

[End of Policy] 

CHANGES : 

In section 4.2.2 replace the sentence: 

FROM: 

“All ISP organizations without any IPv4 addresses from ARIN automatically qualify for an initial allocation of a /24. ISPs providing a 24-month utilization plan for the request size specified may receive up to a /22. ISPs holding reallocations and/or reassignments must show the efficient utilization of their resources consistent with the requirements in sections 4.2.3 and 4.2.4.” 

TO: 

“All ISP organizations without any IPv4 addresses from ARIN automatically qualify for an initial allocation of a /24. ” 

Note: This change is to bring the text of the draft policy in line with changes in the NRPM (2025.1) based on changes adopted 

In section 8.3 Conditions on the source of the transfer, remove this sentence: 
“The source entity will not be allowed to apply for IPv4 address space under Section 4.1.8 ARIN Waitlist for a period of 36 months following the transfer of IPv4 address resources to another party.” 

DISCUSSION: 

Following is a summary of the key discussion points and various positions and opinions expressed regarding the draft policy as expressed on PPML threads, at the ARIN Members Meetings and in various discussions and engagements. 

Main Objective : Reduce wait times (~3 years currently) by capping allocations at a /24 rather than currently allowing larger blocks (/23 & /22), preventing multiple queue entries, and excluding organizations that previously held non-special IPv4 space. 

Suggested Revisions 

    * Feb 2024 : 
    * 
        * Clarification requiring waitlist applicants to demonstrate a /24 need on an active network 
        * Removed several transfer and requeue restrictions to streamline policy 

Community Opinions & Feedback 

    * Mixed community sentiment, 
    * 
        1. No change needed 
        2. Eliminate the waitlist entirely 
        3. Keep /22 but weight requests by need/time 
        4. Proceed with revisions and clarify wording 
        5. Define treatment for existing wait‑listers 
    * Alternate suggestion : let applicants specify a desired and minimum acceptable block size, enabling a flexible allocation process 
    * Weighted queues : Prioritize requests by actual need or length of time waiting. 
    * Time-based revalidation : Automatically clear old entries if need is no longer valid. 
    * Anti-reduction There's no spare IPv4 space—shrinking allocations to /24 would harm newcomers without improving fairness; recommends abandoning. 
    * IPv4 pool is long exhausted, and this is simply postponing the inevitable and thus prolonging the pain. Everyone should simply move to IPv6 
    * Core questions posed : Should the policy move forward? Should it include a weighting formula or grandfathering rule? 

    * Community wants clarity and fairness (grandfathering or equal treatment) 
        * There was overwhelming support for the addition of a clause to ensure protections for those already on the waitlist. Without this protection clause, there was little to no support for the draft policy. 
    * Movement and activity remains mostly deadlocked/stagnant/stalemate. 
    * 
    * Repeated postponement or inaction on waitlist reform has worsened fairness and usability. 
    * Reducing to /24 allows ARIN to stretch remaining IPv4 holdings further, giving more organizations a chance to receive space—even if small. 
    * The original /22 cap was reasonable when first introduced but no longer reflects current IPv4 availability. 

    * Circumstances have changed since 2019 when this was first proposed (n a previous recommendation) 
    * Some persons have changed their position from their initial support of the draft policy 
    * Waitlist should be abandoned! Alternatively, or refine queue allocation mechanisms entirely 
    * Is a /24 useful, sufficient, and/or practical for an organization? 
    * Why still focus on IPv4 with its scarcity when IPv6 is readily available? 
    * List is working; Lease market otherwise 
    * Reducing the allocation from /22 to /24 will not solve any tangible problem, rather create a new one as /24 is too small even for the smaller organizations that are waiting in order to use it properly to connect people and businesses. 
    * A /24 is too small for practical enterprise use or for ISPs needing multiple subnets. 
    * Suggest abandoning the waitlist entirely, calling it “illusionary.” 
    * Claims the policy gives false hope and disadvantages new entrants who need realistic operational space. 

    * 
The proposal may be aiming to reduce anxiety from having to wait too long in the waiting list, but the reality is that there aren't IP addresses left to replenish the pool and has been a fact for a while. 

    * The wait list is 3 years long (currently much less) and the justifications are two-year projections. There is a fundamental issue with needs-testing here. Does it matter if the needs-tests are accurate at the time of allocation? 

    * 
Support exists for the /24 cap, but the community remains divided —some favor abandonment. 

    * 
Instead of rigid caps, allow applicants to specify both:     * 
        * Desired block size 
        * Minimum acceptable size 

This flexible approach would allow ARIN to better match available inventory to demand, while still giving applicants a realistic fallback. 

    * It should be noted that the issue is not the Waitlist length/size which fluctuates, but wait times have been dropping from a high in excess of 30 months to a current estimate of 18-24 months. 
    * It has also been demonstrated (August 2024) that the Waitlist could have been completely cleared on a number of occasions if allocations were limited to /24 cap for all Waitlist recipients 

Based on community input, a recommended forward path is needed. Opinions and suggestions remains mostly varied. 

Future of this Draft Policy ARIN-2023-8: 

Suggestions and Considerations 

Best case scenario: large IPv4 blocks relinquished/returned, IPv4 available pool replenished (unlikely) 

Worst case scenario: IPv4 blocks completely run out , Only transfer and lease markets available, or IPv6 transition 

What happens in the future if demand drops or increases? 

    * Waiting List is somewhat self-adjusting. 
    * Presently, the problem statement may not be completely valid, but this may not continue to be true at some point in the future. If the Waiting List were to expand to where it was before, will it be too late to introduce such a policy? 
    * New policy proposal can be submitted if problem continues, unencumbered by any stipulations or requirements which hamper this current proposal. 

There is no perfect fix, though there is interest in allowing more equitable distribution—even in smaller blocks which seeks to provide better support of IPv4 policy goals during exhaustion. 

Modify Instead of Abandon : 

Keep the draft alive but revise it to balance fairness, usability, and realism. This would require significant changes to the text and substantively change the policy and deviate from the initial problem statement. This, therefore may simply require a new proposal meeting those requirements and incorporating all of those desired changes. 

Presently, the statement may not be valid, but this may not continue to be true at some point in the future. 

If the Waiting List were to expand to where it was before, will it be too late to introduce such a policy? 

New policy proposal can be submitted if problem continues, unencumbered by any stipulations or requirements which hamper this current proposal. 

Question : 

Should the AC continue working on this policy? 

Gerry E. George 
ICT Consultant and Business Solutions Architect; 
Digi Solv , Inc. [P.O. Box 1677, Castries, Saint Lucia] 

Mobile : (758) 728-4858 / Int'l Office : (347) 450-3444 / Skype: DigiSolv 
Email : [ mailto:ggeorge at digisolv.com | ggeorge at digisolv.com ] / LinkedIn : [ https://www.linkedin.com/in/gerrygeorge/ | https://www.linkedin.com/in/gerrygeorge/ ] 

Please consider the environment before printing this email. Thank you. 
_______________________________________________ 
ARIN-PPML 
You are receiving this message because you are subscribed to 
the ARIN Public Policy Mailing List ( [ mailto:ARIN-PPML at arin.net | ARIN-PPML at arin.net ] ). 
Unsubscribe or manage your mailing list subscription at: 
[ https://lists.arin.net/mailman/listinfo/arin-ppml | https://lists.arin.net/mailman/listinfo/arin-ppml ] 
Please contact [ mailto:info at arin.net | info at arin.net ] if you experience any issues. 

_______________________________________________ 
ARIN-PPML 
You are receiving this message because you are subscribed to 
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). 
Unsubscribe or manage your mailing list subscription at: 
https://lists.arin.net/mailman/listinfo/arin-ppml 
Please contact info at arin.net if you experience any issues. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20250627/17af760e/attachment-0001.htm>