<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span style="font-size:large">EzIP proposes </span></blockquote><div><br></div><div>EzIP is a concept that has zero interest in the field , aside from Mr. Chen himself. It's been discussed and analysed. Legitimate issues have been raised, and Mr. Chen simply handwaves them away. </div><div><br></div><div>The only IETF actions on it has been Mr. Chen refreshing the draft every 6 months. </div><div><br></div><div>There's really no point in talking about what it is , or what it wants to do, when it has the same force and effect as the legendary IPv10 draft, and April Fools RFCs. </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 12, 2024 at 7:08 AM Abraham Y. Chen <<a href="mailto:aychen@avinta.com">aychen@avinta.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"><u></u>
<div>
<div><font size="4">Hi, Owen:</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4">1) "... it seemed the
240/4 lasting a year was an optimistic count. ":</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4"> EzIP proposes that
240/4 be used like 10.64/10 in CG-NAT. which is reusable for
each isolated geographical area. Thus, there is no "Burn-rate"
to talk about.</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4">Regards,</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4"><br>
</font></div>
<div><font size="4">Abe (2024-01-12 07:07)</font><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>On 2024-01-11 19:10, Owen DeLong wrote:<br>
</div>
<blockquote type="cite">
At the time this was being considered, ARIN, APNIC, and RIPE NCC
were each burning approximately 6 /8s per year. 240/4 is 16x/8, so
with an RIR burn rate of 18 /8s per year (not counting LACNIC and
AFRINIC which each accounted for <1 per year IIRC), it seemed
the 240/4 lasting a year was an optimistic count.
<div><br>
</div>
<div>Owen</div>
<div><br>
<div><br>
<blockquote type="cite">
<div>On Jan 11, 2024, at 13:15, Christopher Hawker <a href="mailto:chris@thesysadmin.au" target="_blank"><chris@thesysadmin.au></a>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div dir="ltr">Hi Tom,
<div><br>
</div>
<div>I'm not too sure I understand where the idea came
from that 2 x /8 would only last one year. APNIC
received their final allocation of the 103/8 prefix
from ICANN/IANA on 03 February 2011, and commenced
delegating space from the prefix on 18 April 2011.
With the right policies in place, it can be well and
truly extended.</div>
<div><br>
</div>
<div>Looking at an APNIC Blog article authored by
Guangliang Pan on 09 October 2023 (<a href="https://blog.apnic.net/2023/10/09/nearing-the-end-of-103-8/" target="_blank">https://blog.apnic.net/2023/10/09/nearing-the-end-of-103-8/</a>),
as of the time the article was written there were
121 available /24 prefixes from the 103/8 pool still
available. Not a great deal in the grand scheme of
things, however, it demonstrates that policy works
in preserving what finite resources we have
left, and that a 2 x /8 will last a lot longer than
one year.</div>
<div><br>
</div>
<div>I could say the same, that 2 x /8 lasting a
little more than a year is an extremely remote and
highly unlikely assumption. Bear in mind that APNIC
policy was changed 1/2 way through to drop 103/8
delegations from a /22 to a /23. Based on this,
65,536 x /23 delegations can be made to new members
and as Peter said, if post-exhaustion policy is
applied to 240/4 it'll go an extremely long way.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Christopher Hawker</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Fri, 12 Jan 2024 at
04:26, Tom Beecher <<a href="mailto:beecher@beecher.cc" target="_blank">beecher@beecher.cc</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">
<div dir="ltr">Christopher-
<div><br>
</div>
<div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Reclassifying
this space, would add 10+ years onto the free
pool for each RIR. Looking at the APNIC free
pool, I would estimate there is about 1/6th of a
/8 pool available for delegation, another 1/6th
reserved. Reclassification would see available
pool volumes return to pre-2010 levels.<br>
</blockquote>
<div><br>
</div>
<div>Citing Nick Hilliard from another reply, this
is an incorrect statement. </div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">on
this point: prior to RIR depletion, the annual
global run-rate on /8s<br>
measured by IANA was ~13 per annum. So that
suggests that 240/4 would<br>
provide a little more than 1Y of consumption,
assuming no demand<br>
back-pressure, which seems an unlikely
assumption.<br>
</blockquote>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I
share Dave's views, I would like to see 240/4
reclassified as unicast space and 2 x /8s
delegated to each RIR with the /8s for AFRINIC
to be held until their issues have been
resolved.<br>
</blockquote>
<div><br>
</div>
<div>This has been discussed at great length at
IETF. The consensus on the question has been
consistent for many years now; doing work to
free up 12-ish months of space doesn't make much
sense when IPv6 exists, along with plenty of
transition/translation mechanisms. Unless
someone is able to present new arguments that
change the current consensus, it's not going to
happen. <br>
</div>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jan 11,
2024 at 5:54 AM Christopher Hawker <<a href="mailto:chris@thesysadmin.au" target="_blank">chris@thesysadmin.au</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">
<div dir="ltr">There really is no reason for 240/4
to remain "reserved". I share Dave's views, I
would like to see 240/4 reclassified as unicast
space and 2 x /8s delegated to each RIR with the
/8s for AFRINIC to be held until their issues
have been resolved.
<div><br>
</div>
<div>Reclassifying this space, would add 10+
years onto the free pool for each RIR. Looking
at the APNIC free pool, I would estimate there
is about 1/6th of a /8 pool available for
delegation, another 1/6th reserved.
Reclassification would see available pool
volumes return to pre-2010 levels.</div>
<div><br>
</div>
<div><a href="https://www.apnic.net/manage-ip/ipv4-exhaustion/" target="_blank">https://www.apnic.net/manage-ip/ipv4-exhaustion/</a><br>
</div>
<div><br>
</div>
<div>In the IETF draft that was co-authored by
Dave as part of the IPv4 Unicast Extensions
Project, a very strong case was presented to
convert this space.</div>
<div><br>
</div>
<div><a href="https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html" target="_blank">https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html</a></div>
<div><br>
</div>
<div>Regards,</div>
<div>Christopher Hawker</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, 11 Jan
2024 at 20:40, Dave Taht <<a href="mailto:dave.taht@gmail.com" target="_blank">dave.taht@gmail.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">On
Wed, Jan 10, 2024 at 11:06 AM Tom Beecher <<a href="mailto:beecher@beecher.cc" target="_blank">beecher@beecher.cc</a>>
wrote:<br>
>><br>
>> There's a whole bunch of software out
there that makes certain<br>
>> assumptions about allowable ranges.
That is, they've been compiled with<br>
>> a header that defines ..<br>
><br>
><br>
> Of course correct. It really depends on
the vendor / software / versions in an
environment. A lot of vendors removed that
years ago, because frankly a lot of large
networks have been using 240/4 as pseudo
RFC1918 for years. Others have worked with
smaller vendors and open source projects to do
the same.<br>
><br>
> It's consistently a topic in the debates
about 240/4 reclassification.<br>
<br>
There's debates still? I gave up. After making
240/4 and 0/8 work<br>
across all of linux and BSD and all the
daemons besides bird (which<br>
refused the patch , I took so much flack that
I decided I would just<br>
work on other things. So much of that flack
was BS - like if you kill<br>
the checks in the OS the world will end - that
didn't happen. Linux<br>
has had these two address ranges just work for
over 5 years now.<br>
<br>
240/4 is intensely routable and actually used
in routers along hops<br>
inside multiple networks today, but less so as
a destination.<br>
<br>
I would really like, one day, to see it move
from reserved to unicast<br>
status, officially. I would have loved it if
0/8 was used by a space<br>
RIR, behind CGNAT, for starters, but with a
plan towards making it<br>
routable. I am not holding my breath.<br>
<br>
The principal accomplishment of the whole
unicast extensions project<br>
was to save a nanosecond across all the
servers in the world on every<br>
packet by killing the useless 0/8 check. That
patch paid for itself<br>
the first weekend after that linux kernel
deployed. It is the<br>
simplest, most elegant, and most controversial
patch I have ever<br>
written.<br>
<br>
<a href="https://news.ycombinator.com/item?id=20430096" rel="noreferrer" target="_blank">https://news.ycombinator.com/item?id=20430096</a><br>
<br>
<br>
><br>
> On Wed, Jan 10, 2024 at 10:45 AM Michael
Butler <<a href="mailto:imb@protected-networks.net" target="_blank">imb@protected-networks.net</a>>
wrote:<br>
>><br>
>> On 1/10/24 10:12, Tom Beecher wrote:<br>
>> > Karim-<br>
>> ><br>
>> > Please be cautious about this
advice, and understand the full context.<br>
>> ><br>
>> > 240/4 is still classified as
RESERVED space. While you would certainly<br>
>> > be able to use it on internal
networks if your equipment supports it,<br>
>> > you cannot use it as publicly
routable space. There have been many<br>
>> > proposals over the years to
reclassify 240/4, but that has not happened,<br>
>> > and is unlikely to at any point
in the foreseeable future.<br>
>><br>
>> While you may be able to get packets
from point A to B in a private<br>
>> setting, using them might also be ..
a challenge.<br>
>><br>
>> There's a whole bunch of software out
there that makes certain<br>
>> assumptions about allowable ranges.
That is, they've been compiled with<br>
>> a header that defines ..<br>
>><br>
>> #define IN_BADCLASS(i)
(((in_addr_t)(i) & 0xf0000000) ==
0xf0000000)<br>
>><br>
>> Michael<br>
>><br>
<br>
<br>
-- <br>
40 years of net history, a couple songs:<br>
<a href="https://www.youtube.com/watch?v=D9RGX6QFm5E" rel="noreferrer" target="_blank">https://www.youtube.com/watch?v=D9RGX6QFm5E</a><br>
Dave Täht CSO, LibreQos<br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<p><br>
</p>
<div id="m_-2250022354537390834DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br><table style="border-top:1px solid rgb(211,212,222)"><tbody><tr><td style="width:55px;padding-top:13px"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank"><img src="https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;"></a></td><td style="width:470px;padding-top:12px;color:rgb(65,66,78);font-size:13px;font-family:Arial,Helvetica,sans-serif;line-height:18px">Virus-free.<a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" style="color:rgb(68,83,234)" target="_blank">www.avast.com</a></td></tr></tbody></table><a href="#m_-2250022354537390834_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></div>
</blockquote></div>