Burn Rate? Re: 202401100645.AYC Re: IPv4 address block
Abraham Y. Chen
aychen at avinta.com
Fri Jan 12 12:07:43 UTC 2024
Hi, Owen:
1) "... it seemed the 240/4 lasting a year was an optimistic count. ":
EzIP proposes that 240/4 be used like 10.64/10 in CG-NAT. which is
reusable for each isolated geographical area. Thus, there is no
"Burn-rate" to talk about.
Regards,
Abe (2024-01-12 07:07)
On 2024-01-11 19:10, Owen DeLong wrote:
> 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> 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> 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>
>> wrote:
>>
>> On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher
>> <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> 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
>>
>
--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240112/aa9783be/attachment.html>
More information about the NANOG
mailing list