This revised policy seems like a sensible compromise to me. -Scott
On Thu, Jun 26, 2025 at 12:48 PM Gerry E.. George <[email protected]> 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; > *DigiSolv, Inc.* [P.O. Box 1677, Castries, Saint Lucia] > ------------------------------ > *Mobile*: (758) 728-4858 /* Int'l Office*: (347) 450-3444 / Skype: > DigiSolv > *Email*: [email protected] / *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 ([email protected]). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. >
_______________________________________________ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
