<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">+1 to the Christopher comment<br><div><br><blockquote type="cite"><div>On 11-Jan-2024, at 16:24, chris@thesysadmin.au wrote:</div><br class="Apple-interchange-newline"><div><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/">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">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">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>
</div></blockquote></div><br></body></html>