[arin-ppml] Summary & Update: Draft Policy ARIN-2023-8: Reduce 4.1.8 maximum allocation
Scott Leibrand
scottleibrand at gmail.com
Thu Jun 26 21:10:24 EDT 2025
This revised policy seems like a sensible compromise to me.
-Scott
On Thu, Jun 26, 2025 at 12:48 PM Gerry E.. George <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;
> *DigiSolv, Inc.* [P.O. Box 1677, Castries, Saint Lucia]
> ------------------------------
> *Mobile*: (758) 728-4858 /* Int'l Office*: (347) 450-3444 / Skype:
> DigiSolv
> *Email*: 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 (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/20250626/9d7bf908/attachment-0001.htm>
More information about the ARIN-PPML
mailing list