<div dir="ltr"><div>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 <b>immediately</b> 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.<br></div><div><br></div><div>Option B) Spend engineering time and equipment purchases (yes, very possibly much more time and more costly) to implement ipv6.</div><div><br></div><div><br></div><div>Even if option B is much more costly and time consuming, the end result will be much better.</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 21 Nov 2022 at 14:48, Joe Maimon <<a href="mailto:jmaimon@jmaimon.com">jmaimon@jmaimon.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
Eric Kuhnke wrote:<br>
> Quite simply, expecting the vast amount of legacy ipv4-only equipment <br>
> out there in the world that is 10, 15, 20 years old to magically <br>
> become compatible with the use of 240/4 in the global routing table is <br>
> a non viable solution. It is not a financial reality for many small to <br>
> medium sized ISPs in lower income countries.<br>
><br>
> The amount of time and effort that would be required to implement your <br>
> proposal is much better spent on ipv6 implementation and various forms <br>
> of improved cgnat.<br>
<br>
In specific focus on 240/4<br>
<br>
Simultaneously claiming that enabling 240/4 as unicast involves <br>
difficulty that in comparison makes IPv6 (and then you add in CGNAT!) <br>
somehow more achievable is ridiculous.<br>
<br>
Regardless of the exact scenario.<br>
<br>
Joe<br>
<br>
<br>
</blockquote></div>