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

Michael Peddemors michael at linuxmagic.com
Wed Feb 21 11:45:10 EST 2024


Owen, I don't think these statements about IPv4 being obsolete help the 
conversation, it is an opinion, and inflammatory.. While I get that 
'advocates' of IPv6 want to do whatever it takes to force a worldwide 
change, the death of IPv4 has been heralded for almost 20 years.. but..

IPv4 is very much part of the current eco-system, and still very much a 
business tool, and for some parts of the eco-system, still very much the 
standard.

Let's see if we can make arguments less biased on the desire for change, 
and more about real world conditions.  I am sure that everyone has some 
opinions or what 'is best'.. but these ideas change with time, and 
everyone has a strong opinion on their own visions of the future.

Just saying, don't think your opinions on this topic are helpful in the 
context of moving policy forward..

(But feel free to keep up the IPv6 fight elsewhere)

	-- Michael --

On 2024-02-21 07:30, Owen DeLong via ARIN-PPML wrote:
> 
> 
>> On Feb 21, 2024, at 07:20, Fernando Frediani <fhfrediani at gmail.com> wrote:
>>
>> 
>>
>> Hi
>>
>> This rather seems to be a vague assumption as you didn't provide 
>> anything substantial for it to be a blocker to have a policy adjusted 
>> in order to contemplate only new entrants.
>> Why is it bad ? Do you think it is still rational to keep supplying IP 
>> addresses to those who already have some in detriment to those who 
>> have nothing ?
>>
> I think any legitimate use of IPv4 addresses is no more or less worthy 
> than any other. I see no reason to elevate theoretical new entrants to 
> the point of depriving existing legitimate users.
> 
> IPv4 is an obsolete technology. Preserving an IPv4 free pool against 
> legitimate demand to facilitate latecomers and laggards failure to 
> deploy IPv6 is simply not in the overall best interests of the internet.
>>
>> This is not unenforceable and just a supposition unsupported by real 
>> data. ARIN has means to develop ways to check these newer 
>> organizations and separate the possible fraudsters from the legit 
>> ones. Just before there it serves to inhibit a lot of organization to 
>> even request IPs under the waitlist making it much cleaner and fair. 
>> LACNIC has been doing it for years and it has proven to be successful 
>> in terms of fairness and possibility to check these organization 
>> requests correctly. Are we going to avoid having a policy which is the 
>> right thing to do just on the supposition that there will be fraud ?
>>
> 
> While I stayed that the process in question was morally equivalent to 
> fraud, it is 100% legal and utterly indistinguishable from a legitimate 
> new entrant.
> 
> The policy you are proposing is not only the wrong thing to do (see 
> above), it is also quite trivially worked around. One can legitimately 
> spin up an organization for a few hundred dollars and a few hours of work.
> 
> ARIN can prevent the recording of that organization’s subsequent 
> acquisition in the ARIN database, but that’s about all that ARIN can do.
> 
> Owen
> 
>> Fernando
>>
>> On 21/02/2024 04:13, Owen DeLong via ARIN-PPML wrote:
>>> Anyone using IP to conduct business should recognize that IPv4 is out 
>>> and they’ll need IPv6 to do business going forward.
>>>
>>> I oppose Fernando’s idea that the waitlist should be limited to new 
>>> entrants. In addition to being bad policy, this is completely 
>>> unenforceable and only leads to widespread workarounds (which are 
>>> morally equivalent to fraud but probably don’t quite fit the legal 
>>> definition of the term). (The cost to spin up an organization to 
>>> acquire resources and then acquire the organization is trivial 
>>> compared to the value of the IPv4 resources obtained).
>>>
>>> Owen
>>>
>>>> On Feb 20, 2024, at 19:28, Denis Motova <dmotova at brcrude.com> wrote:
>>>>
>>>> Owen:
>>>>
>>>> I appreciate your thoughtful and constructive suggestion.
>>>>
>>>> There are a couple of factors at play here that I'd like to address 
>>>> directly, if possible:
>>>>
>>>> Regarding the Existing Waiting List - I'm uncertain about the 
>>>> rationale behind altering the current waiting list and applying new 
>>>> criteria to members who have already been approved. I believe any 
>>>> new policy should not retroactively affect those who have already 
>>>> undergone approval. Approved members should continue to receive the 
>>>> resources they were initially granted based on their justification 
>>>> until such point as new users are added under the new policy (after 
>>>> its approval) and its updated distribution methods are implemented.
>>>>
>>>> As for the New Policy for Future Applicants - Future applicants may 
>>>> be required to select from a /22, /23, or /24 allocation, with the 
>>>> decision weighted based on the considerations Owen has mentioned 
>>>> regarding the allocation of new resources.
>>>>
>>>> I support the sentiments expressed by Fernando Frediani; there 
>>>> should be a reasonable approach that balances the need to avoid 
>>>> impacting the size of routing tables while still providing users 
>>>> with the flexibility they require to conduct business rather than 
>>>> treating IPs as a hobby.
>>>>
>>>> Thanks again,
>>>> Denis
>>>>
>>>>
>>>>> On 20 Feb 2024, at 21:53, Owen DeLong <owen at delong.com> wrote:
>>>>>
>>>>> How about this:
>>>>>
>>>>> Each waitlist recipient specifies a desired block size and a 
>>>>> minimum acceptable block size. Wait list recipients can change 
>>>>> their minimum acceptable block size at any time so long as it is no 
>>>>> shorter than their originally approved block size.
>>>>>
>>>>> When ARIN receives a block to fulfill a waitlist request, the first 
>>>>> waitlister in line with a minimum acceptable block size ≥ the 
>>>>> available block size gets it.
>>>>>
>>>>> In other words, let’s say we have the following waitlist:
>>>>>
>>>>> PartyApprovedMinimum acceptable
>>>>> A/23/23
>>>>> B/22/23
>>>>> C/22/24
>>>>> D/24/24
>>>>> E/22/23
>>>>> F/22/24
>>>>>
>>>>>
>>>>> Let’s say ARIN receives a /24. The first /24 would go to party C.
>>>>> If ARIN then received another /24, it would go to party D.
>>>>> If ARIN then received a /22, Parties A and B would receive a /23 each.
>>>>>
>>>>> Owen
>>>>>
>>>>>
>>>>>> On Feb 16, 2024, at 17:01, Denis Motova <dmotova at brcrude.com> wrote:
>>>>>>
>>>>>> Dear Scott,
>>>>>>
>>>>>> I appreciate the innovative perspective and thorough thought 
>>>>>> process you've articulated in your email.
>>>>>>
>>>>>> There are a couple of points I'd like to highlight:
>>>>>>
>>>>>> The new policy shouldn’t be retroactive, it should be only a 
>>>>>> policy going forward. I mention it only because I think it’s 
>>>>>> important to make that distinction clear.
>>>>>>
>>>>>> Secondly, I find your proposed approach in the second paragraph 
>>>>>> intriguing. It's far more nuanced than simply restricting everyone 
>>>>>> to a maximum of a /24. I believe you're onto something promising 
>>>>>> here, and it could serve as a sensible strategy moving forward.
>>>>>>
>>>>>> Regarding the issue of "time," it's important to acknowledge the 
>>>>>> existence of a secondary market for IPs. If there's significant 
>>>>>> pressure, purchasing IPs should be considered a viable option 
>>>>>> rather than solely relying on expedited access through the waiting 
>>>>>> list. Maintaining a balance is key; those with urgent needs can 
>>>>>> acquire IPs through purchase, while others can join the waiting 
>>>>>> list and adhere to the traditional process. Personally, I believe 
>>>>>> this approach strikes a fair and equitable balance.
>>>>>>
>>>>>> -Denis
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 16 Feb 2024, at 21:14, Scott Leibrand 
>>>>>>> <scottleibrand at gmail.com> wrote:
>>>>>>>
>>>>>>> The point isn't to "improve the visual appearance of the waiting 
>>>>>>> list numbers". Everyone knows the free pool is empty except for 
>>>>>>> the reclaimed dregs, and we're deciding who should get how much 
>>>>>>> of the dregs. The point of this proposal, limiting the maximum 
>>>>>>> allocation to /24, is to allocate smaller netblocks to 
>>>>>>> organizations that have been waiting a shorter amount of time, 
>>>>>>> instead of making everyone wait longer while those with a 
>>>>>>> non-time-sensitive justification for a larger block can get one 
>>>>>>> and those who only need a smaller block wait in line longer.
>>>>>>>
>>>>>>> Another alternative to limiting everyone to a /24 would be to 
>>>>>>> prioritize the waitlist such that everyone's place in line is 
>>>>>>> determined by how long they've been waiting divided by how many 
>>>>>>> /24s they're requesting. So at any given time, we might be 
>>>>>>> fulfilling /24 requests that have been waiting 6 months, /23 
>>>>>>> requests that have been waiting a year, and /22 requests that 
>>>>>>> have been waiting 2 years. (Or 1, 2, and 4 years, respectively.) 
>>>>>>> That way no one is penalized for accepting a smaller block, and 
>>>>>>> an organization who can usefully use a /24 now and a /24 later 
>>>>>>> gets a /23 worth of space in the same amount of time as someone 
>>>>>>> holding out for a contiguous /23.
>>>>>>>
>>>>>>> -Scott
>>>>>>>
>>>>>>> On Fri, Feb 16, 2024 at 12:56 PM Denis Motova 
>>>>>>> <dmotova at brcrude.com> wrote:
>>>>>>>
>>>>>>>     Dear William,
>>>>>>>
>>>>>>>     I appreciate your message and your input.
>>>>>>>
>>>>>>>     I have some reservations about agreeing with the statement
>>>>>>>     you made, and I'll explain my reasoning below:
>>>>>>>
>>>>>>>     I strongly believe that there are numerous legitimate
>>>>>>>     businesses currently on the waiting list seeking IP space
>>>>>>>     allocations of /22, /23, and /24. By removing the option for
>>>>>>>     these allocations, we essentially transform the waiting list
>>>>>>>     into what you described in a previous post as catering to
>>>>>>>     "hobbyists and speculators." It's unlikely that any serious
>>>>>>>     company would require only 256 IPs within a network; that's
>>>>>>>     essentially a micro-network.
>>>>>>>
>>>>>>>     As you are aware, there are multiple avenues for obtaining IP
>>>>>>>     space, including the waiting list and authorized purchase
>>>>>>>     methods. From my perspective, if a business urgently needs IP
>>>>>>>     space, they would likely follow the example of AWS and invest
>>>>>>>     in acquiring the necessary resources rather than wait through
>>>>>>>     the waiting list.
>>>>>>>
>>>>>>>     For instance, one of our customers acquired a /17 by
>>>>>>>     purchasing it from the market after providing justifications
>>>>>>>     to ARIN for the IP space. While this involved a significant
>>>>>>>     financial investment, it demonstrated the seriousness of
>>>>>>>     their business needs.
>>>>>>>
>>>>>>>     I fail to see the value in limiting everyone's network size
>>>>>>>     solely to improve the visual appearance of the waiting list
>>>>>>>     numbers.
>>>>>>>
>>>>>>>     Thank you once again for your collaborative spirit and feedback.
>>>>>>>
>>>>>>>     Sincerely,
>>>>>>>     Denis
>>>>>>>
>>>>>>>
>>>>>>>>     On 16 Feb 2024, at 15:52, William Herrin <bill at herrin.us> wrote:
>>>>>>>>
>>>>>>>>     On Fri, Feb 16, 2024 at 8:52 AM Denis Motova
>>>>>>>>     <dmotova at brcrude.com> wrote:
>>>>>>>>>     A. Decreasing the allocation to a /24 means that new allocation
>>>>>>>>>     holders would receive a minuscule network, hardly
>>>>>>>>>     sufficient for
>>>>>>>>>     small to mid-sized deployments.
>>>>>>>>
>>>>>>>>     Hi Denis,
>>>>>>>>
>>>>>>>>     At this point, the wait list is for hobbyists and
>>>>>>>>     speculators: people
>>>>>>>>     who can afford to wait, which a serious business cannot.
>>>>>>>>
>>>>>>>>     Tell me I'm wrong.
>>>>>>>>
>>>>>>>>     Regards,
>>>>>>>>     Bill Herrin
>>>>>>>>
>>>>>>>>
>>>>>>>>     -- 
>>>>>>>>     William Herrin
>>>>>>>>     bill at herrin.us
>>>>>>>>     https://bill.herrin.us/
>>>>>>>
>>>>>> _______________________________________________
>>>>>> 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.
>>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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 contactinfo 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.
> 
> _______________________________________________
> 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.


-- 
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Reg. TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada




More information about the ARIN-PPML mailing list