202401100645.AYC Re: IPv4 address block

Thu Jan 11 15:56:50 UTC 2024

+1 to the Christopher comment

> On 11-Jan-2024, at 16:24, chris at thesysadmin.au wrote:
> 
> 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.
> 
> 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.
> 
> https://www.apnic.net/manage-ip/ipv4-exhaustion/
> 
> 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.
> 
> https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-240-00.html
> 
> Regards,
> Christopher Hawker
> 
> On Thu, 11 Jan 2024 at 20:40, Dave Taht <dave.taht at gmail.com <mailto:dave.taht at gmail.com>> wrote:
>> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher <beecher at beecher.cc <mailto:beecher at beecher.cc>> wrote:
>> >>
>> >> There's a whole bunch of software out there that makes certain
>> >> assumptions about allowable ranges. That is, they've been compiled with
>> >> a header that defines ..
>> >
>> >
>> > 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.
>> >
>> > It's consistently a topic in the debates about 240/4 reclassification.
>> 
>> There's debates still? I gave up. After making 240/4 and 0/8 work
>> across all of linux and BSD and all the daemons besides bird (which
>> refused the patch , I took so much flack that I decided I would just
>> work on other things. So much of that flack was BS - like if you kill
>> the checks in the OS the world will end - that didn't happen. Linux
>> has had these two address ranges just work for over 5 years now.
>> 
>> 240/4 is intensely routable and actually used in routers along hops
>> inside multiple networks today, but less so as a destination.
>> 
>> I would really like, one day, to see it move from reserved to unicast
>> status, officially. I would have loved it if 0/8 was used by a space
>> RIR, behind CGNAT, for starters, but with a plan towards making it
>> routable. I am not holding my breath.
>> 
>> The principal accomplishment of the whole unicast extensions project
>> was to save a nanosecond across all the servers in the world on every
>> packet by killing the useless 0/8 check. That patch paid for itself
>> the first weekend after that linux kernel deployed. It is the
>> simplest, most elegant, and most controversial patch I have ever
>> written.
>> 
>> https://news.ycombinator.com/item?id=20430096
>> 
>> 
>> >
>> > On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <imb at protected-networks.net <mailto:imb at protected-networks.net>> wrote:
>> >>
>> >> On 1/10/24 10:12, Tom Beecher wrote:
>> >> > Karim-
>> >> >
>> >> > Please be cautious about this advice, and understand the full context.
>> >> >
>> >> > 240/4 is still classified as RESERVED space. While you would certainly
>> >> > be able to use it on internal networks if your equipment supports it,
>> >> > you cannot use it as publicly routable space. There have been many
>> >> > proposals over the years to reclassify 240/4, but that has not happened,
>> >> > and is unlikely to at any point in the foreseeable future.
>> >>
>> >> While you may be able to get packets from point A to B in a private
>> >> setting, using them might also be .. a challenge.
>> >>
>> >> There's a whole bunch of software out there that makes certain
>> >> assumptions about allowable ranges. That is, they've been compiled with
>> >> a header that defines ..
>> >>
>> >> #define IN_BADCLASS(i)  (((in_addr_t)(i) & 0xf0000000) == 0xf0000000)
>> >>
>> >>         Michael
>> >>
>> 
>> 
>> -- 
>> 40 years of net history, a couple songs:
>> https://www.youtube.com/watch?v=D9RGX6QFm5E
>> Dave Täht CSO, LibreQos

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240111/6f53112f/attachment.html>