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

[bzs]

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 "awa 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| b...@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*

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

[Lincoln Dale]

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

[John Curran]

> On Nov 21, 2022, at 11:12 PM, Joe Maimon  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” 
 
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

[Joe Maimon]

Lincoln Dale wrote:
On Tue, Nov 22, 2022 at 11:20 AM Joe Maimon > 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

[Joe Maimon]

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

[Joe Maimon]

John Curran wrote:



On Nov 21, 2022, at 7:18 PM, Joe Maimon  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

[Abraham Y. Chen]

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

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

[Lincoln Dale]

On Tue, Nov 22, 2022 at 11:20 AM Joe Maimon  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

[John Curran]

> On Nov 21, 2022, at 7:18 PM, Joe Maimon  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

[Eric Kuhnke]

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

[John Curran]

On Nov 21, 2022, at 7:18 PM, Joe Maimon  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 –  
 )

FYI,
/John

John Curran
President and CEO
American Registry for Internet Numbers

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

[Joe Maimon]

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

[Eric Kuhnke]

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

[Joe Maimon]

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

[Tom Beecher]

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

[Eric Kuhnke]

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

[Joe Maimon]

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

[Eric Kuhnke]

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

[Abraham Y. Chen]

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