Burn Rate? Re: 202401100645.AYC Re: IPv4 address block

["Abraham Y. Chen" <aychen () avinta com>]

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 () 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 () 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 () 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>
> >         wrote:
> >
> >             On Wed, Jan 10, 2024 at 11:06 AM Tom Beecher
> >             <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=20430096
> >
> >
> >             >
> >             > On Wed, Jan 10, 2024 at 10:45 AM Michael Butler
> >             <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


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com