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

[Owen DeLong]

> On Feb 21, 2024, at 10:09, Fernando Frediani <fhfrediani at gmail.com> wrote:
> 
> Hi
> 
> On Wed, 21 Feb 2024, 14:09 Owen DeLong, <owen at delong.com <mailto:owen at delong.com>> wrote:
>> 
>> <clip>
>> 
>> As the old saying goes… a bird in the hand. 
>> 
>> Existing users have a track record and a current documented need if they are applying for additional addresses. New entrants may or may not exist at some point in the future and are 100% speculation at this time. 
>> 
>> I see no reason to advantage speculative purposes over documented need. Who is being vague now?
> 
> 
> This is LACNIC waiting list which has always assigned *only to new entrants*. It is currently easily on 5 years wait time. Is this still to vague ?
> 
> https://www.lacnic.net/6335/2/lacnic/ipv4-address-waitlist

And? What does this have to do with whether it’s good policy in the ARIN region or not?

IMHO, it’s also bad policy in the LACNIC region, but I have less of a stake in the outcome in their region, so I don’t argue as strongly there.
Also, since I don’t speak Spanish, participation on their policy list would be difficult for me. It works for the majority in the region so I am not complaining about this, merely stating it as fact.

With few exceptions, I still see no valid reason to disadvantage existing need for speculative future use. Those exceptions are well covered by 4.4 and 4.10 (which LACNIC does not have equivalent policies to the best of my knowledge, so perhaps that is why they limit to new entrants here).

>> 
>>> There are countless ways to always better use of what one already has and it sounds very unreasonable to continue assigning more addresses to these organizations in times of exahustion. Need to balance things correctly, face reality and be reasonable given the current scenario.
>> 
>> This is purely your opinion. In my opinion, you shouldn’t get to make that decision on behalf of existing organizations and tell them how to run their networks. 
> 
> 
> Oh again this.
> Yes people can chose whatever they want to run their networks, but one that keeps refusing to implement CGNAT in their operation and wishes the luxury to keep assigning a Public IPv4 to each individual customer, we as policymakers are able to limit their choices by letting them to go to the transfer market in order to fullfil their choice and not mess with a bet in the waiting list.

If we think that’s good policy, yes, we can do that. Personally, I do not think forcing CGNAT in order to provide possible addresses for some as yet unknown future use is a good policy tradeoff. Obviously you think it is good policy. That’s fine, we can agree to disagree and I’m sure others will express opinions as well.

>>>> <clip>
>>> 
>>> 
>>> Well, that's another discussion. Newcomers don't have any and cannot do anything without a minimal IPv4 even if they prefectly deploy IPv6.
>> 
>> Not true. They can do many things without v4. What they can’t do is communicate with sites that have been too lazy or inattentive to deploy IPv6. Guess what… the only thing that’s going to get many of those sites to deploy IPv6 is when they are faced with a world where they need to communicate with those new entrants that have no IPv4.
> 
> 
> You can't serious about it !
> If you are not joking than that is precisely ideology about forcing a situation over businesses and ignoring the practical side of things.

No, it’s a completely accurate statement of fact. It is an exact description of the current situation.

It has nothing to do with ideology and everything to do with facing the actual reality.

Are you really claiming that nothing can be done over IPv6? I can show you logs from my web server and mail server that contradict that claim quite easily. Google has published statistics that contradict that claim. Facebook contradicts that claim. The list goes on.

In fact, (at long last), I’ve even been able to order items from amazon without IPv4.

So I stand by my statement that they can do many things without IPv4.

Are you claiming there is something one cannot do with IPv6 besides communicating with an IPv4 only site?

What, exactly would that be?

>> Will that be painful and disruptive in the short run? You bet. Horribly so. But we’ve frittered away more than 20 years encouraging graceful transition with only about 50% uptake to show for it. 
> 
> No, it is completelly unpractical.

Potato, po-tah-toe.

Continuing to pay for other organizations failure to act is also completely impractical, yet we continue to do that. Continuing to allow organizations to externalize costs onto other ISPs, Cloud Providers, Developers, and virtually everyone else because they are simply unwilling to deploy IPv6 is completely impractical, yet that situation has continued for more than a decade at this point.

> Anyone in the Internet business industry still require a minimal amount of IPv4 in order to do a minimal CGNAT/NAT64 and exist in the practical Internet everybody uses.

Those needs are entirely covered under 4.4 and 4.10. There is no need for them to use the waiting list.

>> <clip>
> 
>> Policy is all about balancing ideology and pragmatism. However, as I see it, it’s a 100% pragmatic reality that the longer we prolong the ability to remain addicted to IPv4, the more we enable these organizations that have failed to deploy IPv6 to externalize the costs of their failure onto the rest of us.
> 
> 
> I agree to have mechanisms that limit options to tjhse who have been refusing to implement IPv6, but in all cases where there is the most perfect IPv6 implementation that requires a minimal ammount of IPv4 to start with.

No, it really doesn’t. The only thing that requires IPv4 is communicating with the sites that have not implemented IPv6.

If you think that’s not true, please present examples of other things one cannot do with IPv6 only. I am happy to debunk them.

Owen


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20240221/da8f9699/attachment.htm>