Yes, my suggestion wasn't to permit 240/4 for use in EzIP, rather it was for it to be reclassified as Unicast (instead of Reserved) space for delegations by RIRs to members.
100.64/10 will never go back into the free pool, it's too heavily integrated into CG-NATted networks. The technical involvement for global networks to renumber makes this impossible. It's akin to recalling 192.168/16 RFC1918 space. Regards, Christopher Hawker On Fri, 12 Jan 2024 at 15:40, Abraham Y. Chen <ayc...@avinta.com> wrote: > Hi, Christopher: > > 1) " ... I would like to see 240/4 reclassified as unicast space ... > ": > > We are in agreement with this first part. > > 2) " ... 2 x /8s delegated to each RIR with the /8s for AFRINIC ... ": > > This second part is not what EzIP is proposing, because it will run > into the old trap of "quickly used up". Instead, 240/4 should be used to > replace 100.64/10 in creating RANs (Regional Area Networks) that are the > same as the existing CG-NAT clusters but 64 fold bigger. So that 240/4 is > reused worldwide like the RFC6598 netblocks, plus other possible benefits > such as putting 100.64/10 back into the allocatable pool (Wasn't this > pulled out of ARIN for worldwide use?) doing so, we do not have 240/4 > exhaustion issue to consider. > > Regards, > > Abe (2024-01-11 23:40) > > > > On 2024-01-11 05:54, Christopher Hawker 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.t...@gmail.com> wrote: > >> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher <beec...@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 < >> i...@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 >> > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > Virus-free.www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > <#m_-4203599433410923242_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >
