202401100645.AYC Re: IPv4 address block

Thu Jan 11 21:05:22 UTC 2024

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

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 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
>>
>

Thanks!

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20240111/aa4a5cc4/attachment.html>