202401100645.AYC Re: IPv4 address block

Mailman List Mirror (Read Only)
21

Hi, Michael:

1) " ... While you may be able to get packets from point A to B in a private setting, using them might also be .. a challenge. ... ":

 EzIP uses 240/4 netblock only within the RAN \(Regional Area Network\) as "Private" address, not "publicly" routable, according to the conventional Internet definition\. This is actually the same as how 100\.64/10 is used within CG\-NAT\.

2) However, this might be where the confusion comes from. With the geographical area coverage so much bigger, an RAN is effectively a public network. To mesh the two for consistency, we defined everything related to 240/4 as "Semi-Public" to distinguish this new layer of networking facility from the current public / private separation. That is, the CG-NAT routers will become SPRs (Semi-Public Routers) in EzIP's RAN, once the 240/4 is deployed.

Hope this helps,

Abe (2024-01-11 12:21)

22

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.

23

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

Thought that 12 month argument was purest BS in light of all the
events since 2011. We have been "out" of IPv4 space for many years
now, and there is a functioning market for IPv4 space that seems to be
serving the purpose. 240/4 is only marginally useful today, but useful
it is.

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.

Instead, bigcos like google and amazon have been able to squat on
240/4 and take advantage of it for 5+ years now. I do kind of hope
others are using it up in the same ways they are.

Consensus, no. Just the few, like my team, that looked clearly at the
future internet's needs getting shouted down by those in power over
there. We cited many other arguments in favor of opening it up. There
are rumblings far outside the realm of the ietf.

I was once naive enough to consider the internet a vast, global,
shared, and beloved space with resources that needed to be conserved
and spread to and for all mankind. And while I still do feel that, our
existing bureaucracies and gatekeepers have seemingly infinite power
to say no, to even simple improvements to how the internet could work.

There is no reason whatsoever for 240/4 to remain "reserved". There
are plausible debates as to how it should be used, but rfc1918-style
only benefits the few.

24

Abraham,

You’re arguing semantics instead of the actual point. Residential customers want Internet access, not intranet access. Again, VRFs are plentiful and so are CG-NAT firewall appliances or servers to run those VMs.

Save yourself the time and effort on this and implement IPv6.

Ryan

25

Thought that 12 month argument was purest BS in light of all the
events since 2011. We have been “out” of IPv4 space for many years
now, and there is a functioning market for IPv4 space that seems to be
serving the purpose. 240/4 is only marginally useful today, but useful
it is.

Sure, because even though direct allocations from RIRs are exhausted, there are still TONS of non-RFC1918 IPv4 addresses out there not actually being used at all. We all know that years ago it wasn’t that difficult to get way more than you needed, and there was never any real pressure or incentive to give anything back. Once exhaustion got on people’s radars, hoarding begin in earnest because it wasn’t difficult to predict that there would prob be a way to monetize it later. A former employer of mine is still sitting on around a /12 worth that we had accumulated through some acquisitions. We never NEEDED more than a /19. I left more than a decade ago, and he’s been subsidizing the long , slow decline of the primary business by selling off chunks of that space here and there. Certainly not a unique circumstance. We know there are companies out there that categorize IP addresses as an appreciable investment asset.

The fact that $/IP peaked about 3 years ago, and has steadily been in decline since is instructive that demand for v4 space is decreasing, which tends to toss a wrench in the story that 240/4 is needed.

There are rumblings far outside the realm of the ietf.

AFAIK, at this point IANA will only change the designation of a V4 block if the IETF process decides they should. So I’m not sure why other rumblings matter all that much.

Instead, bigcos like google and amazon have been able to squat on
240/4 and take advantage of it for 5+ years now. I do kind of hope
others are using it up in the same ways they are.

I know a lot of places that are not those companies that are using 240/4 internally. Some are many orders of magnitude smaller.

I would disagree with it being referred to as ‘squatting’. Today, nobody’s usage of 240/4 internally impacts anyone else.

26

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.

27

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

28

ARIN has been gutting IPv4 free-pool based policy left and right lately… Other RIRs have not been quite as aggressive, but have done some similar things. This, if for no other reason, makes it a bad idea to suddenly restore RIR IPv4 free pools.

Just my $0.02.

I’ve got as little power in the IETF as it’s possible to have, but I admit I do share in the consensus view that the effort spent writing up a plan for 240/4 would be better invested in deploying IPv6.

Owen

29

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

30

Hi, Vasilenko:

1) ... These “multi-national conglo” has enough influence on the IETF to not permit it.":

 As classified by Vint Cerf, 240/4 enabled EzIP is an overlay network that may be deployed stealthily \(just like the events reported by the RIPE\-LAB\)\. So, EzIP deployment does not need permission from the IETF\.

Regards,

Abe (2024-01-11 21:38 EST)

31

Hi, Forrest:

0) Thanks for your in-depth analysis.

1) However, my apologies for not presenting the EzIP concept clearer. That is, one way to look at the EzIP scheme is to substitute the current 100.64/10 netblock in the CG-NAT with 240/4. Everything else in the current CG-NAT setup stays unchanged. This makes each CG-NAT cluster 64 fold bigger. And, various capabilities become available.

Regards,

Abe (2024-01-11 22:35)

32

Hi, Nick:

1) Perhaps it will be easier to visualize the EzIP scheme by replacing the 100.64/10 netblock with 240/4, so that the CG-NAT is enhanced, starting from being 64 fold bigger in address capacity.

Regards,

Abe (2024-01-11 22:42)

33

Not going to lie, EzIP just seems to be some version of destination/source NAT on steroids.

Regards,
Christopher Hawker

34

Hi, Nick:

1) " ... So that suggests that 240/4 would provide a little more than 1Y of consumption, ... ":

 EzIP proposes to use 240/4 CG\-NAT&#39;s 100\.64/10\. So, 240/4 will be reusable worldwide and no need to consider consumption rate\.

Regards,

Abe (2024-01-11 23:06)

35

Hi, Christopher:

1) " ... I would like to see 240/4 reclassified as unicast space ... ":

 We are in agreement with this first part\.

2) " ... 2 x /8s delegated to each RIR with the /8s for AFRINIC ... ":

 This second part is not what EzIP is proposing, because it will run into the old trap of &quot;quickly used up&quot;\. Instead, 240/4 should be used to replace 100\.64/10 in creating RANs \(Regional Area Networks\) that are the same as the existing CG\-NAT clusters but 64 fold bigger\. So that 240/4 is reused worldwide like the RFC6598 netblocks, plus other possible benefits such as putting 100\.64/10 back into the allocatable pool \(Wasn&#39;t this pulled out of ARIN for worldwide use?\) doing so, we do not have 240/4 exhaustion issue to consider\.

Regards,

Abe (2024-01-11 23:40)

36

Yes, my suggestion wasn’t to permit 240/4 for use in EzIP, rather it was for it to be reclassified as Unicast (instead of Reserved) space for delegations by RIRs to members.

100.64/10 will never go back into the free pool, it’s too heavily integrated into CG-NATted networks. The technical involvement for global networks to renumber makes this impossible. It’s akin to recalling 192.168/16 RFC1918 space.

Regards,
Christopher Hawker

37

Hi, Saku:

1) " ...we need to figure out why we are in this dual-stack mess, which was never intended, and how to get out of it. ... ":

 After our team worked out the EzIP scheme and then classified by Vint Cerf as an overlay network, more than a couple of the considerations that you outlined could be left alone for them to run their own courses\. This is because the EzIP approach resolved the size limitation of the CG\-NAT which appears \(from my limited knowledge\) to be the primary current IPv4 handicap with respect to IPv6\. EzIP can be configured in parallel to and operates in arm&#39;s length with the existing Internet, so that it can grow independent of the latter\.

Regards,

Abe (2024-01-11 23:54)

38

Abraham,

You may not need permission from the IETF, but you effectively need it from every networking vendor, hardware vendor, and OS vendor. If you do not have buy in from key stakeholders, it’s dead-on arrival.

Ryan

39

We don't need to extend IPv4, we need to figure out why we are in this
dual-stack mess, which was never intended, and how to get out of it.

it was intended. it was the original transition plan. like many things
about ipv6, it could have been a bit better thought out.

randy

40

We don't need to extend IPv4, we need to figure out why we are in this
dual-stack mess, which was never intended, and how to get out of it.

it was intended. it was the original transition plan. like many things
about ipv6, it could have been a bit better thought out.

What was not intended though was the transition period to last for 30 years and counting… If things go reasonably well we’re gonna be dual stack for another 20, at least.