Alternative Re: ipv4/25s and above Re: 202211210951.AYC

Mon Nov 21 23:47:29 UTC 2022

This is basically exactly what has come out of the IETF for this and
similar ideas.

I doubt it will ever stop them from being put forth though.

On Mon, Nov 21, 2022 at 6:39 PM Eric Kuhnke <eric.kuhnke at gmail.com> wrote:

> Option A) Spend engineering time and equipment purchases to implement
> 240/4 as unicast globally. At present consumption rates and based on the
> number of entities in ARIN, RIPE, APNIC regions that could *immediately*
> take /18 to /16 sized blocks of it, please quantify exactly how many years
> this amount of "new" IP space you predict to be useful before once again
> reaching ipv4 exhaustion. End result: Problem not solved. Thus my analogy
> of building a sand castle while the tide is coming in.
>
> Option B) Spend engineering time and equipment purchases (yes, very
> possibly much more time and more costly) to implement ipv6.
>
>
> Even if option B is much more costly and time consuming, the end result
> will be much better.
>
>
>
> On Mon, 21 Nov 2022 at 14:48, Joe Maimon <jmaimon at jmaimon.com> wrote:
>
>>
>>
>> Eric Kuhnke wrote:
>> > Quite simply, expecting the vast amount of legacy ipv4-only equipment
>> > out there in the world that is 10, 15, 20 years old to magically
>> > become compatible with the use of 240/4 in the global routing table is
>> > a non viable solution. It is not a financial reality for many small to
>> > medium sized ISPs in lower income countries.
>> >
>> > The amount of time and effort that would be required to implement your
>> > proposal is much better spent on ipv6 implementation and various forms
>> > of improved cgnat.
>>
>> In specific focus on 240/4
>>
>> Simultaneously claiming that enabling 240/4 as unicast involves
>> difficulty that in comparison makes IPv6 (and then you add in CGNAT!)
>> somehow more achievable is ridiculous.
>>
>> Regardless of the exact scenario.
>>
>> Joe
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221121/be435615/attachment.html>