Mailing List Archive

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

0) Your opinion by itself is very valid and much appreciate. However, it
is from a very remotely related perspective. That is, you are looking at
the financial disadvantage of the less developed regions. What I am
talking about is the generic issue of communication system address
management that applies across the board. This subject is normally
designed by system planners. The result is given to the product
development engineers who usually do not have enough knowledge to
question it.

1)  The IPv4 address pool depletion issue was caused by the poor
"resources management" concepts. In this case, the insistence on the
Internet addressing should be flat (instead of hierarchical) led to the
quick depletion of the finite sized 32-bit pool. The fact is that the
current prevalent CDN (Content Delivery Network) business model based on
CG-NAT configuration is a clear hierarchical network, anyway. All what
EzIP proposes is to make it explicit and universal for improving the
performance.

2)  To create a viable hierarchical network with depleted address pool
like IPv4 was practically an impossible task. Fortunately, the 240/4
netblock is available because it was "reserved for future use" ever
since 1981-09, yet no clear application cases could be found. So, this
is a natural resources that will benefit everyone without reference to
financial status, although the developing regions can benefit more by
utilizing it to leap frog out of the current disadvantaged situations.

Hope this explanation makes sense to you.


Regards,


Abe (2022-11-21 10:29 EST)




On 2022-11-20 17:56, Eric Kuhnke wrote:
> If I had a dollar for every person who has lived their entire life in
> a high-income western country (US, Canada, western Europe, etc) and
> has zero personal experience in developing-nation telecom/ISP
> operations and their unique operational requirements, yet thinks
> they've qualified to offer an opinion on it...
>
> People should go look at some of the WISPs in the Philippines for an
> example of ISPs building last and middle mile infrastructure on
> extremely limited budgets. Or really just about anywhere else where
> the residential broadband market has households where the entire
> household monthly income is the equivalent of $500 USD.
>
>
>
> On Sat, 19 Nov 2022 at 04:59, Mark Tinka <mark@tinka.africa> wrote:
>
>
>
> On 11/19/22 05:50, Abraham Y. Chen wrote:
>
> > Dear Owen:
> >
> > 1) "... Africa ... They don’t really have a lot of alternatives.
> ...":
> > Actually, there is, simple and in plain sight. Please have a
> look at
> > the below IETF Draft:
>
> It's most amusing, to me, how Africa needs to be told how to be...
>
> Some folk just can't help themselves.
>
> Mark.
>


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
Quite simply, expecting the vast amount of legacy ipv4-only equipment out
there in the world that is 10, 15, 20 years old to magically become
compatible with the use of 240/4 in the global routing table is a non
viable solution. It is not a financial reality for many small to medium
sized ISPs in lower income countries.

The amount of time and effort that would be required to implement your
proposal is much better spent on ipv6 implementation and various forms of
improved cgnat.

Trying to extend the use of ipv4 space resources for a few more years is
directly analogous to building sand castles on the beach when the tide is
obviously coming in.




On Mon, 21 Nov 2022 at 07:29, Abraham Y. Chen <aychen@avinta.com> wrote:

> Dear Eric:
>
> 0) Your opinion by itself is very valid and much appreciate. However, it
> is from a very remotely related perspective. That is, you are looking at
> the financial disadvantage of the less developed regions. What I am
> talking about is the generic issue of communication system address
> management that applies across the board. This subject is normally
> designed by system planners. The result is given to the product
> development engineers who usually do not have enough knowledge to
> question it.
>
> 1) The IPv4 address pool depletion issue was caused by the poor
> "resources management" concepts. In this case, the insistence on the
> Internet addressing should be flat (instead of hierarchical) led to the
> quick depletion of the finite sized 32-bit pool. The fact is that the
> current prevalent CDN (Content Delivery Network) business model based on
> CG-NAT configuration is a clear hierarchical network, anyway. All what
> EzIP proposes is to make it explicit and universal for improving the
> performance.
>
> 2) To create a viable hierarchical network with depleted address pool
> like IPv4 was practically an impossible task. Fortunately, the 240/4
> netblock is available because it was "reserved for future use" ever
> since 1981-09, yet no clear application cases could be found. So, this
> is a natural resources that will benefit everyone without reference to
> financial status, although the developing regions can benefit more by
> utilizing it to leap frog out of the current disadvantaged situations.
>
> Hope this explanation makes sense to you.
>
>
> Regards,
>
>
> Abe (2022-11-21 10:29 EST)
>
>
>
>
> On 2022-11-20 17:56, Eric Kuhnke wrote:
> > If I had a dollar for every person who has lived their entire life in
> > a high-income western country (US, Canada, western Europe, etc) and
> > has zero personal experience in developing-nation telecom/ISP
> > operations and their unique operational requirements, yet thinks
> > they've qualified to offer an opinion on it...
> >
> > People should go look at some of the WISPs in the Philippines for an
> > example of ISPs building last and middle mile infrastructure on
> > extremely limited budgets. Or really just about anywhere else where
> > the residential broadband market has households where the entire
> > household monthly income is the equivalent of $500 USD.
> >
> >
> >
> > On Sat, 19 Nov 2022 at 04:59, Mark Tinka <mark@tinka.africa> wrote:
> >
> >
> >
> > On 11/19/22 05:50, Abraham Y. Chen wrote:
> >
> > > Dear Owen:
> > >
> > > 1) "... Africa ... They don’t really have a lot of alternatives.
> > ...":
> > > Actually, there is, simple and in plain sight. Please have a
> > look at
> > > the below IETF Draft:
> >
> > It's most amusing, to me, how Africa needs to be told how to be...
> >
> > Some folk just can't help themselves.
> >
> > Mark.
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
Eric Kuhnke wrote:
> Quite simply, expecting the vast amount of legacy ipv4-only equipment
> out there in the world that is 10, 15, 20 years old to magically
> become compatible with the use of 240/4 in the global routing table is
> a non viable solution. It is not a financial reality for many small to
> medium sized ISPs in lower income countries.
>
> The amount of time and effort that would be required to implement your
> proposal is much better spent on ipv6 implementation and various forms
> of improved cgnat.

In specific focus on 240/4

Simultaneously claiming that enabling 240/4 as unicast involves
difficulty that in comparison makes IPv6 (and then you add in CGNAT!)
somehow more achievable is ridiculous.

Regardless of the exact scenario.

Joe
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
Option A) Spend engineering time and equipment purchases to implement 240/4
as unicast globally. At present consumption rates and based on the number
of entities in ARIN, RIPE, APNIC regions that could *immediately* take /18
to /16 sized blocks of it, please quantify exactly how many years this
amount of "new" IP space you predict to be useful before once again
reaching ipv4 exhaustion. End result: Problem not solved. Thus my analogy
of building a sand castle while the tide is coming in.

Option B) Spend engineering time and equipment purchases (yes, very
possibly much more time and more costly) to implement ipv6.


Even if option B is much more costly and time consuming, the end result
will be much better.



On Mon, 21 Nov 2022 at 14:48, Joe Maimon <jmaimon@jmaimon.com> wrote:

>
>
> Eric Kuhnke wrote:
> > Quite simply, expecting the vast amount of legacy ipv4-only equipment
> > out there in the world that is 10, 15, 20 years old to magically
> > become compatible with the use of 240/4 in the global routing table is
> > a non viable solution. It is not a financial reality for many small to
> > medium sized ISPs in lower income countries.
> >
> > The amount of time and effort that would be required to implement your
> > proposal is much better spent on ipv6 implementation and various forms
> > of improved cgnat.
>
> In specific focus on 240/4
>
> Simultaneously claiming that enabling 240/4 as unicast involves
> difficulty that in comparison makes IPv6 (and then you add in CGNAT!)
> somehow more achievable is ridiculous.
>
> Regardless of the exact scenario.
>
> Joe
>
>
>
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
This is basically exactly what has come out of the IETF for this and
similar ideas.

I doubt it will ever stop them from being put forth though.

On Mon, Nov 21, 2022 at 6:39 PM Eric Kuhnke <eric.kuhnke@gmail.com> wrote:

> Option A) Spend engineering time and equipment purchases to implement
> 240/4 as unicast globally. At present consumption rates and based on the
> number of entities in ARIN, RIPE, APNIC regions that could *immediately*
> take /18 to /16 sized blocks of it, please quantify exactly how many years
> this amount of "new" IP space you predict to be useful before once again
> reaching ipv4 exhaustion. End result: Problem not solved. Thus my analogy
> of building a sand castle while the tide is coming in.
>
> Option B) Spend engineering time and equipment purchases (yes, very
> possibly much more time and more costly) to implement ipv6.
>
>
> Even if option B is much more costly and time consuming, the end result
> will be much better.
>
>
>
> On Mon, 21 Nov 2022 at 14:48, Joe Maimon <jmaimon@jmaimon.com> wrote:
>
>>
>>
>> Eric Kuhnke wrote:
>> > Quite simply, expecting the vast amount of legacy ipv4-only equipment
>> > out there in the world that is 10, 15, 20 years old to magically
>> > become compatible with the use of 240/4 in the global routing table is
>> > a non viable solution. It is not a financial reality for many small to
>> > medium sized ISPs in lower income countries.
>> >
>> > The amount of time and effort that would be required to implement your
>> > proposal is much better spent on ipv6 implementation and various forms
>> > of improved cgnat.
>>
>> In specific focus on 240/4
>>
>> Simultaneously claiming that enabling 240/4 as unicast involves
>> difficulty that in comparison makes IPv6 (and then you add in CGNAT!)
>> somehow more achievable is ridiculous.
>>
>> Regardless of the exact scenario.
>>
>> Joe
>>
>>
>>
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
Eric,

I appreciate your willingness to actual consider this rationally.

Every facet of this debate has been fully aired on this forum (and
others), numerous times.

Allow me to pick it apart again. Apologies to those who are ad nausem.

Eric Kuhnke wrote:
> Option A) Spend engineering time and equipment purchases to implement
> 240/4 as unicast globally. At present consumption rates and based on
> the number of entities in ARIN, RIPE, APNIC regions that could
> *immediately* take /18 to /16 sized blocks of it, please quantify
> exactly how many years this amount of "new" IP space you predict to be
> useful before once again reaching ipv4 exhaustion. End result: Problem
> not solved. Thus my analogy of building a sand castle while the tide
> is coming in.
>
> Option B) Spend engineering time and equipment purchases (yes, very
> possibly much more time and more costly) to implement ipv6.

This is know a false dichotomy. There is no actual reason to believe
that any effort on option A detracts from available effort of option B.
And when you purchase your new gear, or update the software, with its
many many lines of code changes, it is not unreasonable to expect that
at least some might be IPv4 related and that the removal of restriction
on 240/4 would be the more trivial of those.

Indeed that is exactly what has been happening since the initial
proposals regarding 240/4. To the extent that it is now largely
supported or available across a wide variety of gear, much of it not
even modern in any way.

Further, presentment of options in this fashion presumes that we have
some ability to control or decide how engineering efforts across the
entirety of the internet should be spent.

Respectively, amusing and alarming.

To be clear, the only thing preventing the Internet in freely organizing
its own efforts is the unwillingness of curmudgeons to remove the
reserved status in this particular instance.

As no-one is requesting that you (or others of this persuasion) lend
their personal efforts, your concern on the budgeting of efforts is out
of place and worse, of dictatorial bend.

For the sake of argument, ignoring above, presuming our control over the
internet engineering efforts et al.

Were I to propose to you that 240/4 be utilized only for new or existing
organizations with less than /20 total resources or some other useful
constraint, it would be easy to see that 240/4 would last a very long
time and potentially have quite a significant impact.

Earlier in this thread I contrasted a reduction from 12 to 1 of ip
address consumption per new customer, depending on the practices
employed by the service provider. As you can see, consumption rate is
actually quite flexible, even now, today.

So the answer to your question is it depends how freely it is handed
out. Certainly not very long if it is business as usual prior to runout.
Potentially much longer if not.

And in a nod to your concern over effort expenditure, but even more so,
conscious of 240/4 being the 32bit space last big easy gasp, I would be
a strong proponent that it NOT be.

However, even if it were, what exactly are we saving it for, if not for
use by those who need it?

Or is it to be a hedge over some eventuality where IPv6 has failed to
the point of abandonment? I might actually respect that position, even
as I doubt (and fear and hope against) such an eventualities actual
occurrence.

The more galling aspect of the 240/4 wars is that "it will take too long
and then Ipv6 will be deployed" crowd that managed to stifle it
initially continue to reuse that line again, in essence blase self
perpetuation.

Its only taking that long because of this attitude.

Joe
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
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.

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

> Eric,
>
> I appreciate your willingness to actual consider this rationally.
>
> Every facet of this debate has been fully aired on this forum (and
> others), numerous times.
>
> Allow me to pick it apart again. Apologies to those who are ad nausem.
>
> Eric Kuhnke wrote:
> > Option A) Spend engineering time and equipment purchases to implement
> > 240/4 as unicast globally. At present consumption rates and based on
> > the number of entities in ARIN, RIPE, APNIC regions that could
> > *immediately* take /18 to /16 sized blocks of it, please quantify
> > exactly how many years this amount of "new" IP space you predict to be
> > useful before once again reaching ipv4 exhaustion. End result: Problem
> > not solved. Thus my analogy of building a sand castle while the tide
> > is coming in.
> >
> > Option B) Spend engineering time and equipment purchases (yes, very
> > possibly much more time and more costly) to implement ipv6.
>
> This is know a false dichotomy. There is no actual reason to believe
> that any effort on option A detracts from available effort of option B.
> And when you purchase your new gear, or update the software, with its
> many many lines of code changes, it is not unreasonable to expect that
> at least some might be IPv4 related and that the removal of restriction
> on 240/4 would be the more trivial of those.
>
> Indeed that is exactly what has been happening since the initial
> proposals regarding 240/4. To the extent that it is now largely
> supported or available across a wide variety of gear, much of it not
> even modern in any way.
>
> Further, presentment of options in this fashion presumes that we have
> some ability to control or decide how engineering efforts across the
> entirety of the internet should be spent.
>
> Respectively, amusing and alarming.
>
> To be clear, the only thing preventing the Internet in freely organizing
> its own efforts is the unwillingness of curmudgeons to remove the
> reserved status in this particular instance.
>
> As no-one is requesting that you (or others of this persuasion) lend
> their personal efforts, your concern on the budgeting of efforts is out
> of place and worse, of dictatorial bend.
>
> For the sake of argument, ignoring above, presuming our control over the
> internet engineering efforts et al.
>
> Were I to propose to you that 240/4 be utilized only for new or existing
> organizations with less than /20 total resources or some other useful
> constraint, it would be easy to see that 240/4 would last a very long
> time and potentially have quite a significant impact.
>
> Earlier in this thread I contrasted a reduction from 12 to 1 of ip
> address consumption per new customer, depending on the practices
> employed by the service provider. As you can see, consumption rate is
> actually quite flexible, even now, today.
>
> So the answer to your question is it depends how freely it is handed
> out. Certainly not very long if it is business as usual prior to runout.
> Potentially much longer if not.
>
> And in a nod to your concern over effort expenditure, but even more so,
> conscious of 240/4 being the 32bit space last big easy gasp, I would be
> a strong proponent that it NOT be.
>
> However, even if it were, what exactly are we saving it for, if not for
> use by those who need it?
>
> Or is it to be a hedge over some eventuality where IPv6 has failed to
> the point of abandonment? I might actually respect that position, even
> as I doubt (and fear and hope against) such an eventualities actual
> occurrence.
>
> The more galling aspect of the 240/4 wars is that "it will take too long
> and then Ipv6 will be deployed" crowd that managed to stifle it
> initially continue to reuse that line again, in essence blase self
> perpetuation.
>
> Its only taking that long because of this attitude.
>
> Joe
>
>
>
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
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
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
On Nov 21, 2022, at 7:18 PM, Joe Maimon <jmaimon@jmaimon.com> wrote:
...
It’s only taking that long because of this attitude.

Of course, Joe, that attitude might also be cited of IPv6 deployment laggards! ;-) i.e., the mumbling of those in the periphery of Internet regarding why they’re not doing IPv6...

(It's not an issue for those closer to high-growth areas – e.g. mobile and consumer broadband – as IPv6 has become the default with many of them for their new connections – <https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption> )

FYI,
/John

John Curran
President and CEO
American Registry for Internet Numbers
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
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@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
>
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
> On Nov 21, 2022, at 7:18 PM, Joe Maimon <jmaimon@jmaimon.com> wrote:
> … Further, presentment of options in this fashion presumes that we have some ability to control or decide how engineering efforts across the entirety of the internet should be spent.

Joe -

In the snippet above you allude to a very important aspect of the Internet that is rather germane to this discussion – ii.e. that we really don’t really have any "ability to control or decide how engineering efforts across the entirety of the internet should be spent” –, but then you don’t really work through what that fact means for realistic outcomes of class E space re-utilization…

First, I want to be really clear: I don’t particular care one way or the other regarding the proposal to “de-reserve” 240/4… I don't run a network (nor has the ARIN community discussed the matter and directed that ARIN take a position either way.) However, I do think the operator community should be thinking hard about how such de-reserving and redefinition into general purpose space will impact the Internet operations community and whether such space can realistically ever be utilized in production manner in the public Internet.

As you alluded to, we really don’t have any "ability to control or decide how engineering efforts across the entirety of the internet should be spent”, and the practical implications of this fact is that there will always be many devices out there in production that will not pass IP packets with class E addresses in them… (just as there’s always going to be some devices, somewhere that don’t know about IPv6.)

Of course, the difference is that with IPv6 we can attempt a connection and then fall back to IPv4, and further that devices out there either support and are configured for IPv6 routing, or they are not - networks rather quickly learn not to announce (via routing & DNS) IPv6 connectivity for devices without it actually being in place and operational or having solid IPv4 fall-back and relying fast fallback/happy eyeballs.

With your using repurposed class E address space in the headers, your customers with such addresses are rather unlikely to ever know why a connection won’t establish – or why existing connections sometime fail mid-stream – as it only takes a single non-conforming device along the ever-changing path through any number of network operators to resulting in the silent drop of that packet. That may (or may not) lead to you experiencing what you consider reasonable support costs for your customers, but as we all know, everyone else has customers who are the other ends of those connections who will call their ISP’s customer support line trying to figure out why they can’t get your customer (or can only get there intermittently) – so it appears that your proposed use of de-reserved and repurposed class E space has some real interesting implications about imputed support burdens on everyone else – if indeed the intended use case is includes providing connectivity to the public Internet.

If you’re not proposing public Internet use, and rather just within your own administrative domain, then feel free to do – talk to your vendors, get them to support it, and turn it on. As you already noted, we really don’t centrally decide how everyone runs their own network – so using it locally is fine since it doesn’t presume others will diagnose connection problems with your customer traffic that quite reasonably is categorized as invalid.

Thanks,
/John

p.s. Disclaimer: my views alone. Note: contents may be hot - use caution when opening.
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
On Tue, Nov 22, 2022 at 11:20 AM Joe Maimon <jmaimon@jmaimon.com> wrote:

> Indeed that is exactly what has been happening since the initial
> proposals regarding 240/4. To the extent that it is now largely
> supported or available across a wide variety of gear, much of it not
> even modern in any way.
>

As someone who has been involved in the deployment of network gear into
class E space (extensively, for our own internal reasons, which doesn't
preclude public use of class E), "largely supported" != "universally
supported".

There remains hardware devices that blackhole class E traffic, for which
there is no fix. https://seclists.org/nanog/2021/Nov/272 is where I list
one of them. There are many, many other devices where we have seen
interesting behavior, some of which has been fixed, some of which has not.


cheers,

lincoln.

>
>
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
Dear Eric:

1)  " ... expecting the vast amount of legacy ipv4-only equipment out
there in the world that is 10, 15, 20 years old to magically become
compatible with the use of 240/4 in the global routing table ... ":   
It is apparent that you do not recognize a few unorthodox EzIP
characteristics. For example:

   A. The activation of 240/4 netblocks is very scalable. It can be as
small as starting from a residential home as evidenced by our initial
realization of this technique via expanding the address pool by 256
folds utilizing 192.168.K/24, or as big as or even multiple of 100.64/4
netblocks that have been deployed all over the places for CG-NAT.

  B. Since the enhancement to use 240/4 is from the last-mile equipment
and up, equipment capable of the program change can be enhanced without
coordinating with any router nearby. In fact, they can continue to
communicate through the originally established setup. This is a
selective incremental process. There is no requirement to upgrade them
all at the same time, such as what happened to IPv6. (I hope that you
would not tell me that the routers whose programs were modified to
handle the 100.64/4 netblocks for CG-NAT operation only about one decade
ago are now too old to accept 240/4.)

  C. Once a router is enhanced to use 240/4, its original capability
set continues with the addition of end-to-end connectivity within an
area served by that router. No other routers would know about this change.

  D. This gives incentives to other regions to upgrade at their own
paces, respectively. Note that we are talking about a generic program
enhancement which can be downloaded to routers of the same model series
through maintenance update cycles. So, we should not be discouraged by
counting how many total routers are out there.

  E. Since the first phase of the EzIP deployment is to enhance CG-NAT,
there is no expansion of global routing table.

2) "... directly analogous to building sand castles on the beach when
the tide is obviously coming in. ":  This is the same as "the train has
left the station" metaphor that we were told when we first started to
look into this issue. So, we decided that our work was just for academic
fun. As time went on, however, we learned that the Dual-Stack
configuration was not just necessary but also going to last for a long
time. Recently, we even heard (see the APNIC blog below as an example)
that the IPv4 to IP6 transition may never end. So, I believe that it
would be prudent for everyone to focus on improving his/her preferred
version. There is no more reason to waste energy in discrediting the
other camp's efforts.

The transition to IPv6: Are we there yet?

https://blog.apnic.net/2022/05/04/the-transition-to-ipv6-are-we-there-yet/

3)  " ... Trying to extend the use of ipv4 space resources for a few
more years ...  ":  Unlike other proposals that we are aware of, EzIP is
an enhancement to RF6598 which applies to CG-NAT that is a hierarchical
network. Following such a configuration, the manageable public IPv4 pool
is extended to roughly 983MB addresses (see the last paragraph of
Sub-Section 2.1 in the EzIP Draft). Administrated in the traditional
communication system identification discipline and supplemented by
RFC1918 netblocks, this resources can last for a really long time.


Regards,


Abe (2022-11-21 22:59 EST)



On 2022-11-21 17:04, Eric Kuhnke wrote:
> Quite simply, expecting the vast amount of legacy ipv4-only equipment
> out there in the world that is 10, 15, 20 years old to magically
> become compatible with the use of 240/4 in the global routing table is
> a non viable solution. It is not a financial reality for many small to
> medium sized ISPs in lower income countries.
>
> The amount of time and effort that would be required to implement your
> proposal is much better spent on ipv6 implementation and various forms
> of improved cgnat.
>
> Trying to extend the use of ipv4 space resources for a few more years
> is directly analogous to building sand castles on the beach when the
> tide is obviously coming in.
>
>
>
>
> On Mon, 21 Nov 2022 at 07:29, Abraham Y. Chen <aychen@avinta.com> wrote:
>
> Dear Eric:
>
> 0) Your opinion by itself is very valid and much appreciate.
> However, it
> is from a very remotely related perspective. That is, you are
> looking at
> the financial disadvantage of the less developed regions. What I am
> talking about is the generic issue of communication system address
> management that applies across the board. This subject is normally
> designed by system planners. The result is given to the product
> development engineers who usually do not have enough knowledge to
> question it.
>
> 1)  The IPv4 address pool depletion issue was caused by the poor
> "resources management" concepts. In this case, the insistence on the
> Internet addressing should be flat (instead of hierarchical) led
> to the
> quick depletion of the finite sized 32-bit pool. The fact is that the
> current prevalent CDN (Content Delivery Network) business model
> based on
> CG-NAT configuration is a clear hierarchical network, anyway. All
> what
> EzIP proposes is to make it explicit and universal for improving the
> performance.
>
> 2)  To create a viable hierarchical network with depleted address
> pool
> like IPv4 was practically an impossible task. Fortunately, the 240/4
> netblock is available because it was "reserved for future use" ever
> since 1981-09, yet no clear application cases could be found. So,
> this
> is a natural resources that will benefit everyone without
> reference to
> financial status, although the developing regions can benefit more by
> utilizing it to leap frog out of the current disadvantaged situations.
>
> Hope this explanation makes sense to you.
>
>
> Regards,
>
>
> Abe (2022-11-21 10:29 EST)
>


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
John Curran wrote:
>
>> On Nov 21, 2022, at 7:18 PM, Joe Maimon <jmaimon@jmaimon.com> wrote:
>> … Further, presentment of options in this fashion presumes that we
>> have some ability to control or decide how engineering efforts across
>> the entirety of the internet should be spent.
>
> Joe -
>
> In the snippet above you allude to a very important aspect of the
> Internet that is rather germane to this discussion – ii.e. that we
> really don’t really have any "ability to control or decide how
> engineering efforts across the entirety of the internet should be
> spent” –, but then you don’t really work through what that fact means
> for realistic outcomes of class E space re-utilization…
>
True

>
> As you alluded to, we really don’t have any "ability to control or
> decide how engineering efforts across the entirety of the internet
> should be spent”, and the practical implications of this fact is that
> there will always be many devices out there in production that will
> not pass IP packets with class E addresses in them… (just as there’s
> always going to be some devices, somewhere that don’t know about IPv6.)
To what extent will this be? And to what extent could it have been had
this been seriously considered dozen+ years ago? We wont really know
until we can get serious about it.
>
> Of course, the difference is that with IPv6 we can attempt a
> connection and then fall back to IPv4, and further that devices out
> there either support and are configured for IPv6 routing, or they are
> not - networks rather quickly learn not to announce (via routing &
> DNS) IPv6 connectivity for devices without it actually being in place
> and operational or having solid IPv4 fall-back and relying fast
> fallback/happy eyeballs.

This is a very fair point. Or perhaps we can have reverse happy eyeballs
for IPv4 fallling back to sub-optimal auto-tunneled IPv6?
>
> With your using repurposed class E address space in the headers, your
> customers with such addresses are rather unlikely to ever know why a
> connection won’t establish – or why existing connections sometime fail
> mid-stream – as it only takes a single non-conforming device along the
> ever-changing path through any number of network operators to
> resulting in the silent drop of that packet.

I am not that sure about silent, presumably traceroute will be just as
(un)usable.

> That may (or may not) lead to you experiencing what you consider
> reasonable support costs for your customers, but as we all know,
> everyone else has customers who are the other ends of those
> connections who will call their ISP’s customer support line trying to
> figure out why they can’t get your customer (or can only get there
> intermittently) – so it appears that your proposed use of de-reserved
> and repurposed class E space has some real interesting implications
> about imputed support burdens on everyone else – if indeed the
> intended use case is includes providing connectivity to the public
> Internet.
>
> If you’re not proposing public Internet use, and rather just within
> your own administrative domain, then feel free to do – talk to your
> vendors, get them to support it, and turn it on. As you already noted,
> we really don’t centrally decide how everyone runs their own network –
> so using it locally is fine since it doesn’t presume others will
> diagnose connection problems with your customer traffic that quite
> reasonably is categorized as invalid.
>
> Thanks,
> /John
>
> p.s. Disclaimer: my views alone. Note: contents may be hot - use
> caution when opening.
>
>

Right now the gossiped growing use of 240/4 in private and non
standardized fashions jeopardizes any potential use of it just as much
as the factors you describe.

In either event, my main point of contention is in the lack of
willingness for serious and prudent consideration. Such as along the
lines of what you have brought up.

So thank you.

Best,

Joe
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
Eric Kuhnke wrote:
> 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.
>
>
Right now the IPv4 scarcity is a barrier of entry to new entities and a
major speedbump in basic growth to small entities.

So my constraint has much wider, lasting and meaningful impact than
either of your thought exercises which essentially involve how to enable
existing entities to resume business as usual for some amount of time. I
am sure there many other much more meaningful ways to consider using
240/4 than that.

New IPv4 resources to go towards addressing customers in the same
fashion as was done ten years ago, I wouldn't bother with 240/4 for that
either.

Best,

Joe
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
Lincoln Dale wrote:
> On Tue, Nov 22, 2022 at 11:20 AM Joe Maimon <jmaimon@jmaimon.com
> <mailto:jmaimon@jmaimon.com>> wrote:
>
> Indeed that is exactly what has been happening since the initial
> proposals regarding 240/4. To the extent that it is now largely
> supported or available across a wide variety of gear, much of it not
> even modern in any way.
>
>
> As someone who has been involved in the deployment of network gear
> into class E space (extensively, for our own internal reasons, which
> doesn't preclude public use of class E), "largely supported" !=
> "universally supported".
>
> There remains hardware devices that blackhole class E traffic, for
> which there is no fix. https://seclists.org/nanog/2021/Nov/272 is
> where I list one of them. There are many, many other devices where we
> have seen interesting behavior, some of which has been fixed, some of
> which has not.
>
>
> cheers,
>
> lincoln.
>
>

And I am sure you would agree that un-reserving a decade ago would have
more than likely resulted in a greatly improved situation now. Along the
lines that doing so now could still result in a greatly improved
situation a decade hence. Should we still need it.

Joe
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
> On Nov 21, 2022, at 11:12 PM, Joe Maimon <jmaimon@jmaimon.com> wrote:
>
> John Curran wrote:
>> ..
>> That may (or may not) lead to you experiencing what you consider reasonable support costs for your customers, but as we all know, everyone else has customers who are the other ends of those connections who will call their ISP’s customer support line trying to figure out why they can’t get your customer (or can only get there intermittently) – so it appears that your proposed use of de-reserved and repurposed class E space has some real interesting implications about imputed support burdens on everyone else – if indeed the intended use case is includes providing connectivity to the public Internet.
>>
>> If you’re not proposing public Internet use, and rather just within your own administrative domain, then feel free to do – talk to your vendors, get them to support it, and turn it on. As you already noted, we really don’t centrally decide how everyone runs their own network – so using it locally is fine since it doesn’t presume others will diagnose connection problems with your customer traffic that quite reasonably is categorized as invalid.
>>
>> Thanks,
>> /John
>>
>> p.s. Disclaimer: my views alone. Note: contents may be hot - use caution when opening.
>>
>>
>
> Right now the gossiped growing use of 240/4 in private and non standardized fashions jeopardizes any potential use of it just as much as the factors you describe.

Joe -

That may be the case - I have no data either way, but it would not be surprising if some folks were paying very careful attention to their vendor support of 240/4 routing so that they can use this address space in a private context.

However, I still have not heard any reasonable explanation for how connections using de-reserved 240/4 space in a public scope will be operationally viable, given that there will always be devices which do not forward such packets…

> In either event, my main point of contention is in the lack of willingness for serious and prudent consideration. Such as along the lines of what you have brought up.

You have an opportunity now - please explain how such connections will not pose an operations nightmare for the rest of the public Internet – it is not at all apparent how such is avoided if 240/4 is changed from reserved to general purpose (if that’s what you are suggesting that we should be doing.)

Of course the other alternative is what Abe has been suggesting (repeatedly): note that it is _not_ using 240/4 for general purpose address space, but rather for their "Adaptive IPv4 Address Space” <https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/> mapping protocol. It seems to suffer from the same assumption of unmolested 240/4 transit in the public Internet (despite the current specification of such addresses as invalid) but then adds some further complication… something akin to CG-NAT but with their new EZ-IP protocol and “semi-public routers” as gateways doing the address mapping function.

I am all for serious discussion of either of these interesting proposals, but if we’re going to seriously discuss such being deployed in the real-world then it had best start with the question of how they will handle the current Internet which frequently drops packets containing 240/4 addresses as invalid and will be doing so in places for many years to come. The upgrades in the real world to address that invalid-drop situation will take quite a while to happen (and note that time starts only after there’s an actual consensus for change in this regard), so – just as it was with IPv6 – it's incumbent on those proposing change to explain how interoperability occurs during the transition period.

Thanks,
/John

p.s. Disclaimer(s): my views alone - this message made from 100% recycled electrons.
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
>
> > As someone who has been involved in the deployment of network gear
> > into class E space (extensively, for our own internal reasons, which
> > doesn't preclude public use of class E), "largely supported" !=
> > "universally supported".
> >
> > There remains hardware devices that blackhole class E traffic, for
> > which there is no fix. https://seclists.org/nanog/2021/Nov/272 is
> > where I list one of them. There are many, many other devices where we
> > have seen interesting behavior, some of which has been fixed, some of
> > which has not.
>
> And I am sure you would agree that un-reserving a decade ago would have
> more than likely resulted in a greatly improved situation now. Along the
> lines that doing so now could still result in a greatly improved
> situation a decade hence. Should we still need it.
>

It may well have helped (a decade ago) past-tense, but it isn't the reality
of today.

I've pointed out there is a non-zero number of existing devices, OSs,
things baked into silicon, even widely used BGP stacks today, that can't
currently use class E, and some of them will never be able to.
You seem to be suggesting that class E could be opened up as valid public
IPv4 space. My experience is that it would not be usable public IPv4
address space any time soon, if ever.

I'm not arguing that unreserving it today may address some of that. But it
will never address all of it.


cheers,

lincoln.


>
Re: Alternative Re: ipv4/25s and above Re: 202211210951.AYC [ In reply to ]
I'm not opposed to making 240/4 unicast but I'd agree it wouldn't
solve much globally.

Nonetheless it might help for example some new org which can't get an
IPv4 allocation (or not sufficient.) They may really need to do both
IPv4 and IPv6 for example.

(ok, here we go, point by point alternatives, we've heard them all ok,
imagine there exists ONE worthy applicant for whom the alternatives
won't work or put them at some unfair disadvantage.)

But why bother solving any of this when we have stats!

1. Those stats aren't really that compelling, we have a bifurcated
protocol space w/ maybe/arguably 40% at IPv6 after many years of
trying.

2. I'm too lazy to hunt it down but how much of that IPv6 penetration
are mobile phones and similar endpoints, captive devices with
zeroconfig? Ok who cares if they are, but...

3. Even if we agree for the sake of argument that the net is roughly
50/50 v4/v6 that still means we're dependent on things like CGNAT and
dual-stack and various other hacks which are needed to navigate this
dual protocol universe which one could argue is PRECISELY what we
didn't want back in the pre-IPv6 days.

For example we might have lived up to the original idea of an internet
and supported DECNET and CHAOSNET and SNA and XNS etc etc etc because
we're heterogeneous, we're an INTERnet!

But we didn't because in practice that stinks even if in theory it's
as simple as getting them to float their protocols on IP directly or
encapsulate them over IP or similar. Just set the IP protocol bits and
to quote Jackie Gleason "awayyyy we go!" Or similar (I think DECNET
went for DECNET over TCP but lo I wander.)

It works, many have done it, and it always stinks.

The devil was in the details like getting enough experts around to
debug problems in your TCP/IP net and your XNS/IP or whatever
nets. And the duplication and/or expansion of equipment etc.

But that's where we are w/ IPv4/IPv6 and we think it's ok because we
slowly backed up into this mess all the while saying just think about
the rabbits Lennie (i.e., one day this will all be IPv6.)

So mere penetration is more than a little deceptive.

Granted there may be no great solution tho some proposals in the area
of (perhaps dynamically) federating the address space are at least
interesting in concept.

But I guess my point is let's not discourage those who are trying, the
problem is real.

--
-Barry Shein

Software Tool & Die | bzs@TheWorld.com | http://www.TheWorld.com
Purveyors to the Trade | Voice: +1 617-STD-WRLD | 800-THE-WRLD
The World: Since 1989 | A Public Information Utility | *oo*