Alternative Re: ipv4/25s and above Re: 202211210951.AYC

Tue Nov 22 00:43:13 UTC 2022

Assume the following theoretical scenario:

You have a large number of existing RIPE, ARIN, APNIC ASes which will take
any ipv4 resources they can get. They're all on waiting lists or have been
informed no new blocks will be forthcoming.

240/4 is something like 256 million IPs.

Let's say that the global benevolent ipv4 dictator decides that each ISP,
MNO or other waiting list entity gets a single /16, one time only.

That's 64,000 IPs per corporate entity. Not actually very large at all on
the scale of regional mid sized operators with 300,000 last mile broadband
subscribers, or mobile network operators, nevermind top-10-size
DOCSIS3/GPON/DSL last mile operators that have many dozens of millions of
customers. One /16 is a tiny drop in the bucket compared to the demand for
IP space for indivudual-customer DHCP pool usage by an ISP the size of
Astound or a South Korean GPON operator or similar.

That's 4000 entities which each get their one time /16 and then 240/4 is
entirely exhausted.

Unrealistic?  Halve it so that each network operator waiting for IP space
reources gets one/ 17, one time only, I would still bet good money that
there's 8000 ASes out there that right now would happily take their "free
"single /17 , and you'd still have immediate complete exhaustion of 240/8.

On Mon, 21 Nov 2022 at 16:33, Joe Maimon <jmaimon at jmaimon.com> wrote:

>
>
> Eric Kuhnke wrote:
> > In a theoretical scenario where somebody was global benevolent
> > dictator of ipv4 space, even applying a policy which limited block
> > size to a few /14 per ISP, it would be possible to exhaust 240/4/in
> > one week/ if they handed out /14 sized pieces to every existing last
> > mile LTE network operator with 5+ million customers globally. It is
> > not a long term solution or even a good medium term solution.
> >
> To to the LM LTE Operator with 5+ mill. customer globally, it is not.
> Agreed. Also, I think they have already sorted themselves out
> sufficiently in a variety of ways. I am not concerned with them, at all.
>
> Which is why I did not offer that as an example of useful constraint.
> Re-run your projections with what I actually discussed, I think you will
> have a different conclusion.
>
> Joe
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20221121/999d7228/attachment.html>