nanog mailing list archives

Re: 202401100645.AYC Re: IPv4 address block


From: Matthew Petach <mpetach () netflight com>
Date: Thu, 11 Jan 2024 13:05:22 -0800

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.

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



Thanks!

Matt

Current thread: