[arin-ppml] ARIN-2023-8: Reduce 4.1.8 Maximum Allocation

Wed Dec 18 15:59:28 EST 2024

Gerry,

First thank you for all the effort you have put into trying to fully present this policy proposal. As the co-shepherd I realize just how much time you have spent with this proposal. Taking off my AC hat for a moment I believe I have changed my mind at least three times concerning how I think we should proceed concerning this proposal. At this point I am of the opinion that we have thoroughly went through all the options you mention below plus a couple more not mentioned.

When this proposal started out I was thinking, probably like much of the community, that this would fulfill many of the requests on the waitlist, but that initial reaction was short lived after discovering that many entities are requesting much more than a /24 and therefore this proposal began to lose steam.

After thinking about the problem of folks needing more than a /24 for their business needs to get up and running, it began to seem like maybe the best option would be to eliminate the waitlist and add all the remaining and returned IPv4 address space to the 4.10 special needs pool for IPv6 transition forcing those who really need more than a /24 of IPv4 to go get it from the transfer market or leasing options. After all there is no more IPv4 free pool.

However the sentiment that eliminating the waitlist is somehow unfair still lingered. Even though I believe if you really have critical business needs for IPv4 address space that a company should be budgeting for those resources as a purchase or lease option since there is no more free pool and if you have to wait for two years to receive the space from the waitlist is it really a critical need… I have still come to the conclusion at this point that we have put too much time into this proposal and that we should do nothing. There will continue to be some recovered and eventually vetted and released IPv4 address space that trickles back into the waitlist, and there will still be those who will want to sign up to receive some of those “free” addresses, therefore there needs to be a holding pen for them to be serviced through e.g. the waitlist.

My vote at this point is that we do nothing, leaving section 4.1.8 as it is currently working. This proposal will not reduce the waitlist numbers or waiting times in any real impactful way which is the part of original problem statement to be resolved IMHO.

_
Brian
Exchange
bjones at vt.edu

On Dec 18, 2024, at 15:10, Gerry E.. George <ggeorge at digisolv.com> wrote:

So the dust has settled, and the curtains came down on ARIN 54 in Toronto.

The presentation of Draft Policy ARIN-2023-8, saw continued and expected robust discussion regarding the proposal.

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.

There were also some minor editorial changes made to the September 30, 2024 version which was presented at ARIN 54. The suggested Draft Policy is presented here:

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 the implementation of this policy. Requests received before the policy change will be evaluated based on the policy in place at the time of the request.

Current NRPM Text: https://www.arin.net/participate/policy/nrpm/#4-1-8-arin-waitlist

I have provided a summary of the main positions below, along with the questions posed to the community regarding further work on the draft policy.

  *   In response to community feedback on PPML and during ARIN 53, and also echoed at ARIN 54, there is overwhelming support for the protection clause for those already on the waitlist, as a condition to consideration of support for the policy, as it was generally felt that a retroactive implementation would be unfair to those currently on the list.
Therefore, if the policy is implemented, it will only impact new waitlist entrants (as at date of policy adoption)
  *   Reducing the allocation from /22 to /24 will not solve any tangible problem, but rather create a new one as /24 is too small for even the smaller organizations to use it properly to connect people and businesses;
  *   The proposal may be aimed at reducing anxiety from the waitlist’s long times, but the reality is that there are no more IPv4 addresses available to replenish the pool, and it has been so for a while;
  *   The waitlist is 2+ years long, with justifications of a 2-year projection. The needs as per the justification projections may have changed before the request is fulfilled. Does it matter if the needs-test is accurate at the time of allocation?

Q: Wasn't there just a distribution in the ARIN-ISSUED report that would change the situation?
A: Yes, there were 318 /24s allocated to 117 organizations on the waitlist in early October (The last distribution was completed Friday, 4 October 2024). There were 819 organizations on the waitlist at the time of distribution with 702 remaining upon completion of the distribution. The oldest request was from January 31, 2023 (20 months) and the newest request filled was from April 25, 2023 (17 months). If the maximum allocated had been limited to /24 by policy then 318 requests would have been filled leaving 501 remaining on the list with the newest request being filled near the end of September 2023 (12 months).
Current waitlist as at December 18 is 831 (up from 792 on November 20, 709 on October 4 and was 824 on September 27); The next distribution will occur on or about Monday, 6 January 2025.

As we can see, the list does not seem to be reducing, but rather holding steady at the current size of 700 - 800+.

There were some interesting discussions presented at the "Table Topic" during the ARIN 54 session, but mostly within the scope of the options presented.

Policy Impact - Options:
Do Nothing:
• 2+ year wait for current/existing requests to be completely fulfilled;
• Waitlist times are likely to increase;
• Run out will eventually happen unless organizations return IP address space to ARIN;
• The number of transfers & cost of IPv4 could be impacted;

Protection Clause: Same 2+ year wait time for fulfilment before the new policy comes into effect;
No protections, immediate reductions: Will see a significant reduction in wait times from an immediate reduction to /24 for all requests;

We are now seeing 4 feasible options for this Draft Policy:
1. Consider revised policy as written (with proposed retroactive protections - still 3+-year lag and wait times);
2. Consider policy without any retroactive protections (reduction in wait times by ⅔s);
3. Do away with the Waitlist completely (new policy would be required);
4. Abandon the policy (essentially, do nothing, no changes to current operations)

We would like to determine some definite support for the listed options, to determine a way forward.
- Option #2 didn't seem to have much support, as many voices were raised in favor of the "Protection Clause".
- Option #3 & #4 both essentially mean an abandonment of the current draft policy (as written).

Please weigh in and register your comments, opinions, support and/or suggestions.

Regards,

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<mailto:ggeorge at digisolv.com>    /    LinkedIn: https://www.linkedin.com/in/gerrygeorge/

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20241218/6de9ab90/attachment-0001.htm>