On Thu, Jan 11, 2024 at 9:29 AM 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.


Hi Tom,

I think that's a bit of an unfair categorization--we can't look at pre-exhaustion demand numbers and extrapolate to post-exhaustion allocations, given the difference in allocation policies pre-exhaustion versus post-exhaustion.

If we limited ISPs to a single /22 of post-exhaustion space, with a minimum 1 year waiting period to come back to request an additional /22, 240/4 would last a good long time.
That aligns with ARIN's current NPRM initial allocation, post-exhaustion:

4.2.2. Initial Allocation to ISPs

All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /22, subject to ARIN’s minimum allocation size.


If you already *have* existing IPv4 space, I would propose you be ineligible to apply to ARIN for space from within 240/4; you already have a functioning business with some amount of IPv4 space, and can look at either trying to be more efficient with what you have (more CG-NAT, renumber off public space for internal links, etc.), or participating in the open market for IPv4 space transfers.

240/4 can be made to last a very long time, if we apply post-exhaustion rules, rather than allowing pre-exhaustion demand curves to continue forward.


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. 

The key difference is that IPv6-only doesn't (currently) work, transition/translation mechanisms require an entity to have at least *some* IPv4 addresses to anchor their transition/translation mechanisms to, and we've created a situation that presents significant barriers to entry for new applicants that existing entities don't face.  At some point in the near future, I suspect governments will begin to look at the current ISP environment as anti-competitive if we don't adjust our stance to ensure a fair and level playing field for new entrants as well as existing incumbent providers.  I think we're going to need to ensure that new applicants are able to get their initial allocation of space for the foreseeable future in order to fend off increasing regulatory pressure.  Adding space from 240/4 to the initial-allocations-only pool would help ensure that.

 

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.


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.


Regards,
Christopher Hawker


Thanks!

Matt