nanog mailing list archives
Re: 202401100645.AYC Re: IPv4 address block
From: Gaurav Kansal via NANOG <nanog () nanog org>
Date: Thu, 11 Jan 2024 21:26:50 +0530
+1 to the Christopher comment
On 11-Jan-2024, at 16:24, chris () 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 () gmail com <mailto:dave.taht () gmail com>> wrote:On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher <beecher () beecher cc <mailto:beecher () 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=20430096On Wed, Jan 10, 2024 at 10:45 AM Michael Butler <imb () protected-networks net <mailto:imb () 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
Current thread:
- Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block, (continued)
- Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block Danny Messano via NANOG (Jan 16)
- Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block Owen DeLong via NANOG (Jan 19)
- Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block Abraham Y. Chen (Jan 19)
- Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block Charles Polisher (Jan 19)
- Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block Owen DeLong via NANOG (Jan 19)
- Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block Randy Bush (Jan 14)
- Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block Christopher Hawker (Jan 12)
- Re: Backward Compatibility Re: 202401100645.AYC Re: IPv4 address block Randy Bush (Jan 12)
- Re: IPv4 address block Nick Hilliard (Jan 11)
- Reusable 240/4 Re: IPv4 address block Abraham Y. Chen (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Gaurav Kansal via NANOG (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Tom Beecher (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Dave Taht (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Tom Beecher (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Matthew Petach (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Owen DeLong via NANOG (Jan 11)
- Re: 202401100645.AYC Re: IPv4 address block Nick Hilliard (Jan 12)
- Re: 202401100645.AYC Re: IPv4 address block Matthew Petach (Jan 12)
- Re: IPv4 address block Nick Hilliard (Jan 13)
- Re: IPv4 address block Christopher Hawker (Jan 13)
- Re: IPv4 address block Randy Bush (Jan 13)