202401100645.AYC Re: IPv4 address block

Fri Jan 12 00:10:19 UTC 2024

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.

Owen

> On Jan 11, 2024, at 13:15, Christopher Hawker <chris at thesysadmin.au> wrote:
> 
> Hi Tom,
> 
> 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.
> 
> Looking at an APNIC Blog article authored by Guangliang Pan on 09 October 2023 (https://blog.apnic.net/2023/10/09/nearing-the-end-of-103-8/), 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.
> 
> 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.
> 
> Regards,
> Christopher Hawker
> 
> 
> 
> On Fri, 12 Jan 2024 at 04:26, Tom Beecher <beecher at beecher.cc <mailto:beecher at beecher.cc>> wrote:
>> Christopher-
>> 
>>> 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.
>> 
>> Citing Nick Hilliard from another reply, this is an incorrect statement. 
>> 
>>> on this point: prior to RIR depletion, the annual global run-rate on /8s
>>> measured by IANA was ~13 per annum. So that suggests that 240/4 would
>>> provide a little more than 1Y of consumption, assuming no demand
>>> back-pressure, which seems an unlikely assumption.
>> 
>>> 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.
>> 
>> 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. 
>> 
>> On Thu, Jan 11, 2024 at 5:54 AM Christopher Hawker <chris at thesysadmin.au <mailto: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/9db0190b/attachment.html>