Re: Fwd: Alternative Re: ipv4/25s and above Re: 202212010732.AYC Re: 202211220729.AYC

[Tom Beecher]

Nothing you have said has changed my thoughts or opinions on this proposal.
It still has many direct technical deficiencies , not to mention continuing
to rely on a status change of 240/4, of which there is no forward movement
on actually happening.

I no longer have interest in continuing the conversation because you have
generally replied with hand waved 'solutions' to issues pointed out by many
people who know what they are talking about, and there's no reason to think
that will change.

So again, best of luck to you with this endeavor.

On Fri, Dec 2, 2022 at 10:36 PM Abraham Y. Chen  wrote:

> Dear Mr. Beecher:
>
> 0) Thanks for your reply to close the loop.
>
> 1)" I don't have any interest in continuing this discussion on this
> topic.":I am quite surprised by your nearly 180 degree turn of your
> position from your last MSG. The only thing that I could think of is
> that my last MSG provided the missing information that made the
> difference. I would appreciate very much if you could confirm.
>
> Regards,
>
>
> Abe (2022-12-02 22:35 EST)
>
>
>
> On 2022-12-01 16:34, Tom Beecher wrote:
> > Mr. Chen-
> >
> > I don't have any interest in continuing this discussion on this topic.
> > Best of luck to you.
> >
> > On Thu, Dec 1, 2022 at 7:44 AM Abraham Y. Chen 
> wrote:
> >
> > Dear Tom:
> >
> > Have not heard from you since the below MSG. Could you please let me
> > know if you have seen it, so that we can carry on by avoiding the
> > repeated open-loop situation with this thread?
> >
> > Regards,
> >
> >
> > Abe (2022-12-01 07:44 EST)
> >
> >
> > On 2022-11-22 23:23, Abraham Y. Chen wrote:
> > > Dear Tom:  Please disregard an earlier partial transmission of
> > > this MSG, caused by operator error. ***
> > >
> > > 1) One look at the NANOG archive that you retrieved tells me
> > that we
> > > are the victims of the idiosyncrasies of the eMail system. Unlike
> > > snail mails that are slow but reliable (There was a story that USPS
> > > found a forty years old letter stuck in one of the mail collection
> > > boxes on Boston sidewalk and then delivered it.), eMails are fast
> > > (Once my eMail monitoring account started to receive a long message
> > > that I was sending out, even before it was fully sent.) but
> > > unpredictable from time to time. Unfortunately, most of us are
> > > conditioned with its daily behavior and do not suspect the
> > electronic
> > > system hiccups (As Andrew Grove once said, "It is the software, not
> > > the hardware."). To deal with this kind of issues in none-real-time
> > > communications, I practice a discipline, started from VM and
> > FAX, that
> > > I will do my best to respond within 24 hours. I encourage my
> > > colleagues to start reminding me (either repeat the MSG or using
> > > alternative channels, such as SkyPe - My handle is
> > "Abraham.Y.Chen"),
> > > if they do not hear from me after 48 hours on topics that they
> > expect
> > > my response. This convention prevented much of the disruptions.
> > > Looking at your comments, I definitely would have responded back
> > then
> > > if I saw them. One possibility is that I was in the midst of being
> > > overwhelmed by NANOG posting protocols, such as the digest mode,
> > > uni-code, personal writing styles, etc. and miseed your MSG.
> > Anyway,
> > > allow me to try carrying on.
> > >
> > > 2)   "...Your proposal appears to rely on a specific value in
> > the IP
> > > option header to create your overlay": Not really, as soon
> > as the
> > > 100.64/10 netblock is replaced by the 240/4, each CG-NAT module can
> > > serve a very large area (such as Tokyo Metro and such) that becomes
> > > the RAN in EzIP terminology. Since each RAN is tethered from the
> > > existing Internet core by an umbilical cord operating on one IPv4
> > > public address, this is like a kite floating in the sky which is
> > the
> > > basic building block for the overlaying EzIP Sub-Internet when they
> > > expand wide enough to begin covering significant areas of the
> > world.
> > > Note that throughout this entire process, the Option Word
> > mechanism in
> > > the IP header does not need be used at all. (It turns out that
> > > utilizing the CG-NAT configuration as the EzIP deployment
> > vehicle, the
> > > only time that the Option Word may be used is when subscribers
> > in two
> > > separate RANs wishing to have end-to-end communication, such as
> > direct
> > > private eMail exchanges.)
> > >
> > > 3) " ... to drop any packet with an IP option set that you don't
> > > explicitly want because a significant number of routers kick every
> > > packet with options to CPU, ... ": Yes, this was what we were
> > reminded
> > > of when we started our 

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

[Abraham Y. Chen]

Dear Mark:

1) "... Google's data also shows businesses making at about 4% if you 
look at the weekly trends that show IPv6 usage spiking on the weekend as 
business users traffic drops off. ...": Perhaps the better 
interpretation of this fluctuation is because the residential use (more 
IPv6) of the Internet peaks up during the weekend, and holidays. In 
fact, work from home during COVID-19 had a notable effect to this graph. 
Along this line, you may enjoy reviewing the following article and 
discussions:


https://circleid.com/posts/20190529_digging_into_ipv6_traffic_to_google_is_28_percent_deployment_limit/ 



Regards,


Abe (2022-12-03 18:40 EST)



On 2022-11-27 21:31, Mark Andrews wrote:

On 24 Nov 2022, at 19:53, Abraham Y. Chen  wrote:

Dear Joe:

0) Allow me to share my understanding of the two topics that you brought up.

1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone 
from ~0% to ~40% in 12 years ":  Your numbers may be deceiving.

   A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified 
on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your 
impression. That is, the IPv6 has been around over quarter of a century.

Which doesn’t change that fact that the traffic to Google has gone from ~0% to 
40% in 12 years.  No one claimed that Google has been measuring IPv6 traffic 
since the very beginning nor does it really matter how long it has been since 
IPv6 was defined.  What we are seeing is strong continuing growth in IPv6 usage 
where the S curve is a long way from flattening off.
   

   B. If you read closely, the statement  "The graph shows the percentage of users that access 
Google over IPv6." above the graph actually means "equipment readiness". That is, 
how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose 
title makes this clearer. However, having the capability does not mean the owners are actually 
using it. Also, this is not general data, but within the Google environment. Since Google is one of 
the stronger promoters of the IPv6, this graph would be at best the cap of such data.

If you read it correctly Google is measuring actual traffic.  Thats actual data 
flowing to and from Google's servers be it Gmail, YouTube, search traffic or 
anything else.  It does mean that the owners of the devices are using IPv6.


   C. The more meaningful data would be the global IPv6 traffic statistics. 
Interestingly, they do not exist upon our extensive search. (If you know of 
any, I would appreciate to receive a lead to such.) The closest that we could 
find is % of IPv6 in AMS-IX traffic statistics (see URL below). It is currently 
at about 5-6% and has been tapering off to a growth of less than 0.1% per month 
recently, after a ramp-up period in the past. (Similar saturation behavior can 
also be found in the above Google graph.)

https://stats.ams-ix.net/sflow/ether_type.html

What makes that “more meaningful” data.  I just see different populations of 
users being measured.  Google's data also shows businesses making at about 4% 
if you look at the weekly trends that show IPv6 usage spiking on the weekend as 
business users traffic drops off.


   D.  One interesting parameter behind the last one is that as an 
Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix 
between IPv6 and IPv4. The low numbers from AMS-IX does not support this 
viewpoint for matching with your observation. In addition, traffic through IX 
is the overflow among backbone routers. A couple years ago, there was a report 
that peering arrangements among backbone routers for IPv6 were much less 
matured then IPv4, which meant that AMS-IX should be getting more IPv6 traffic 
than the mix in the Internet core. Interpreted in reverse, % of IPv6 in overall 
Internet traffic should be less than what AMS-IX handles.

   E. This is a quite convoluted topic that we only scratched the surface. They 
should not occupy the attention of colleagues on this list. However, I am 
willing to provide more information to you off-line, if you care for further 
discussion.

2)  "...https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/  ...":  
My basic training was in communication equipment hardware design. I knew little about 
software beyond what I needed for my primary assignment. Your example, however, reminds 
me of a programing course that I took utilizing APL (A Programming Language) for circuit 
analysis, optimization and synthesis. It was such a cryptic symbolic language that 
classmates (mostly majored in EE hardware) were murmuring to express their displeasure. 
One day we got a homework assignment to do something relatively simple. Everyone 
struggled to write the code to do the job. Although most of us did get working codes, 
they were pages long. The shortest one was one full page. Upon reviewed all homework, the 
professor smiled at us and told us to look for 

Re: Fwd: Alternative Re: ipv4/25s and above Re: 202212010732.AYC Re: 202211220729.AYC

[Abraham Y. Chen]

Dear Mr. Beecher:

0) Thanks for your reply to close the loop.

1)    " I don't have any interest in continuing this discussion on this 
topic.":    I am quite surprised by your nearly 180 degree turn of your 
position from your last MSG. The only thing that I could think of is 
that my last MSG provided the missing information that made the 
difference. I would appreciate very much if you could confirm.


Regards,


Abe (2022-12-02 22:35 EST)



On 2022-12-01 16:34, Tom Beecher wrote:

Mr. Chen-

I don't have any interest in continuing this discussion on this topic. 
Best of luck to you.


On Thu, Dec 1, 2022 at 7:44 AM Abraham Y. Chen  wrote:

Dear Tom:

Have not heard from you since the below MSG. Could you please let me
know if you have seen it, so that we can carry on by avoiding the
repeated open-loop situation with this thread?

Regards,


Abe (2022-12-01 07:44 EST)


On 2022-11-22 23:23, Abraham Y. Chen wrote:
> Dear Tom:  Please disregard an earlier partial transmission of
> this MSG, caused by operator error. ***
>
> 1) One look at the NANOG archive that you retrieved tells me
that we
> are the victims of the idiosyncrasies of the eMail system. Unlike
> snail mails that are slow but reliable (There was a story that USPS
> found a forty years old letter stuck in one of the mail collection
> boxes on Boston sidewalk and then delivered it.), eMails are fast
> (Once my eMail monitoring account started to receive a long message
> that I was sending out, even before it was fully sent.) but
> unpredictable from time to time. Unfortunately, most of us are
> conditioned with its daily behavior and do not suspect the
electronic
> system hiccups (As Andrew Grove once said, "It is the software, not
> the hardware."). To deal with this kind of issues in none-real-time
> communications, I practice a discipline, started from VM and
FAX, that
> I will do my best to respond within 24 hours. I encourage my
> colleagues to start reminding me (either repeat the MSG or using
> alternative channels, such as SkyPe - My handle is
"Abraham.Y.Chen"),
> if they do not hear from me after 48 hours on topics that they
expect
> my response. This convention prevented much of the disruptions.
> Looking at your comments, I definitely would have responded back
then
> if I saw them. One possibility is that I was in the midst of being
> overwhelmed by NANOG posting protocols, such as the digest mode,
> uni-code, personal writing styles, etc. and miseed your MSG.
Anyway,
> allow me to try carrying on.
>
> 2)   "...Your proposal appears to rely on a specific value in
the IP
> option header to create your overlay": Not really, as soon
as the
> 100.64/10 netblock is replaced by the 240/4, each CG-NAT module can
> serve a very large area (such as Tokyo Metro and such) that becomes
> the RAN in EzIP terminology. Since each RAN is tethered from the
> existing Internet core by an umbilical cord operating on one IPv4
> public address, this is like a kite floating in the sky which is
the
> basic building block for the overlaying EzIP Sub-Internet when they
> expand wide enough to begin covering significant areas of the
world.
> Note that throughout this entire process, the Option Word
mechanism in
> the IP header does not need be used at all. (It turns out that
> utilizing the CG-NAT configuration as the EzIP deployment
vehicle, the
> only time that the Option Word may be used is when subscribers
in two
> separate RANs wishing to have end-to-end communication, such as
direct
> private eMail exchanges.)
>
> 3) " ... to drop any packet with an IP option set that you don't
> explicitly want because a significant number of routers kick every
> packet with options to CPU, ... ": Yes, this was what we were
reminded
> of when we started our study. However, this appears to be another
> Internet myth. Dr. Chimiak of the EnIP project (see EzIP Draft's
> Refernce 13) told me that his team had successfully sent packets
with
> Option Words. Again, even if the existing routers do knock out
packs
> with Option words, the overlay architecture of the RANs allows the
> search for those do allow this operation. Since the use of the
Option
> Word turns out to be an option to superceed IPv4's capabilities, we
> should treat it as a consideration for future premium services.
>
> 4) " ...Any device that still treated 240/4 differently would
need to
> be updated to treat it like anything else. .. ": Yes, this
applies to
> regions that desire to enjoy the EzIP characteristics. Since the
root
> of each RAN (or sub-RAN) still appears to be one of the current
CG-NAT
> modules, there is no change can be detected 

Re: Fwd: Alternative Re: ipv4/25s and above Re: 202212010732.AYC Re: 202211220729.AYC

[Tom Beecher]

Mr. Chen-

I don't have any interest in continuing this discussion on this topic. Best
of luck to you.

On Thu, Dec 1, 2022 at 7:44 AM Abraham Y. Chen  wrote:

> Dear Tom:
>
> Have not heard from you since the below MSG. Could you please let me
> know if you have seen it, so that we can carry on by avoiding the
> repeated open-loop situation with this thread?
>
> Regards,
>
>
> Abe (2022-12-01 07:44 EST)
>
>
> On 2022-11-22 23:23, Abraham Y. Chen wrote:
> > Dear Tom:  Please disregard an earlier partial transmission of
> > this MSG, caused by operator error. ***
> >
> > 1) One look at the NANOG archive that you retrieved tells me that we
> > are the victims of the idiosyncrasies of the eMail system. Unlike
> > snail mails that are slow but reliable (There was a story that USPS
> > found a forty years old letter stuck in one of the mail collection
> > boxes on Boston sidewalk and then delivered it.), eMails are fast
> > (Once my eMail monitoring account started to receive a long message
> > that I was sending out, even before it was fully sent.) but
> > unpredictable from time to time. Unfortunately, most of us are
> > conditioned with its daily behavior and do not suspect the electronic
> > system hiccups (As Andrew Grove once said, "It is the software, not
> > the hardware."). To deal with this kind of issues in none-real-time
> > communications, I practice a discipline, started from VM and FAX, that
> > I will do my best to respond within 24 hours. I encourage my
> > colleagues to start reminding me (either repeat the MSG or using
> > alternative channels, such as SkyPe - My handle is "Abraham.Y.Chen"),
> > if they do not hear from me after 48 hours on topics that they expect
> > my response. This convention prevented much of the disruptions.
> > Looking at your comments, I definitely would have responded back then
> > if I saw them. One possibility is that I was in the midst of being
> > overwhelmed by NANOG posting protocols, such as the digest mode,
> > uni-code, personal writing styles, etc. and miseed your MSG. Anyway,
> > allow me to try carrying on.
> >
> > 2)   "...Your proposal appears to rely on a specific value in the IP
> > option header to create your overlay": Not really, as soon as the
> > 100.64/10 netblock is replaced by the 240/4, each CG-NAT module can
> > serve a very large area (such as Tokyo Metro and such) that becomes
> > the RAN in EzIP terminology. Since each RAN is tethered from the
> > existing Internet core by an umbilical cord operating on one IPv4
> > public address, this is like a kite floating in the sky which is the
> > basic building block for the overlaying EzIP Sub-Internet when they
> > expand wide enough to begin covering significant areas of the world.
> > Note that throughout this entire process, the Option Word mechanism in
> > the IP header does not need be used at all. (It turns out that
> > utilizing the CG-NAT configuration as the EzIP deployment vehicle, the
> > only time that the Option Word may be used is when subscribers in two
> > separate RANs wishing to have end-to-end communication, such as direct
> > private eMail exchanges.)
> >
> > 3) " ... to drop any packet with an IP option set that you don't
> > explicitly want because a significant number of routers kick every
> > packet with options to CPU, ... ": Yes, this was what we were reminded
> > of when we started our study. However, this appears to be another
> > Internet myth. Dr. Chimiak of the EnIP project (see EzIP Draft's
> > Refernce 13) told me that his team had successfully sent packets with
> > Option Words. Again, even if the existing routers do knock out packs
> > with Option words, the overlay architecture of the RANs allows the
> > search for those do allow this operation. Since the use of the Option
> > Word turns out to be an option to superceed IPv4's capabilities, we
> > should treat it as a consideration for future premium services.
> >
> > 4) " ...Any device that still treated 240/4 differently would need to
> > be updated to treat it like anything else. .. ": Yes, this applies to
> > regions that desire to enjoy the EzIP characteristics. Since the root
> > of each RAN (or sub-RAN) still appears to be one of the current CG-NAT
> > modules, there is no change can be detected by other CG-NAT modules.
> > This avoids interoperability issues during the incremental deployment.
> >
> > 5) "  ...Any existing filters that dropped packets with *any* IP
> > option set would have to be modified to permit the ones you define for
> > EzIP":  Since EzIP is not going to activate Option Words initially
> > for enhancing the CG-NAT, this should not be a concern. In the future,
> > inter-RAN communication by subscribers would use Option words. But, by
> > that time, finite number of backbone / gateway routers among RANs
> > capable of preserving Option Words would have been identified. This
> > approach takes advantage of the hierarchical network configuration
> > that CG-NAT has 

Re: Fwd: Alternative Re: ipv4/25s and above Re: 202212010732.AYC Re: 202211220729.AYC

[Abraham Y. Chen]

Dear Tom:

Have not heard from you since the below MSG. Could you please let me 
know if you have seen it, so that we can carry on by avoiding the 
repeated open-loop situation with this thread?


Regards,


Abe (2022-12-01 07:44 EST)


On 2022-11-22 23:23, Abraham Y. Chen wrote:
Dear Tom:  Please disregard an earlier partial transmission of 
this MSG, caused by operator error. ***


1) One look at the NANOG archive that you retrieved tells me that we 
are the victims of the idiosyncrasies of the eMail system. Unlike 
snail mails that are slow but reliable (There was a story that USPS 
found a forty years old letter stuck in one of the mail collection 
boxes on Boston sidewalk and then delivered it.), eMails are fast 
(Once my eMail monitoring account started to receive a long message 
that I was sending out, even before it was fully sent.) but 
unpredictable from time to time. Unfortunately, most of us are 
conditioned with its daily behavior and do not suspect the electronic 
system hiccups (As Andrew Grove once said, "It is the software, not 
the hardware."). To deal with this kind of issues in none-real-time 
communications, I practice a discipline, started from VM and FAX, that 
I will do my best to respond within 24 hours. I encourage my 
colleagues to start reminding me (either repeat the MSG or using 
alternative channels, such as SkyPe - My handle is "Abraham.Y.Chen"), 
if they do not hear from me after 48 hours on topics that they expect 
my response. This convention prevented much of the disruptions. 
Looking at your comments, I definitely would have responded back then 
if I saw them. One possibility is that I was in the midst of being 
overwhelmed by NANOG posting protocols, such as the digest mode, 
uni-code, personal writing styles, etc. and miseed your MSG. Anyway, 
allow me to try carrying on.


2)   "...Your proposal appears to rely on a specific value in the IP 
option header to create your overlay": Not really, as soon as the 
100.64/10 netblock is replaced by the 240/4, each CG-NAT module can 
serve a very large area (such as Tokyo Metro and such) that becomes 
the RAN in EzIP terminology. Since each RAN is tethered from the 
existing Internet core by an umbilical cord operating on one IPv4 
public address, this is like a kite floating in the sky which is the 
basic building block for the overlaying EzIP Sub-Internet when they 
expand wide enough to begin covering significant areas of the world. 
Note that throughout this entire process, the Option Word mechanism in 
the IP header does not need be used at all. (It turns out that 
utilizing the CG-NAT configuration as the EzIP deployment vehicle, the 
only time that the Option Word may be used is when subscribers in two 
separate RANs wishing to have end-to-end communication, such as direct 
private eMail exchanges.)


3) " ... to drop any packet with an IP option set that you don't 
explicitly want because a significant number of routers kick every 
packet with options to CPU, ... ": Yes, this was what we were reminded 
of when we started our study. However, this appears to be another 
Internet myth. Dr. Chimiak of the EnIP project (see EzIP Draft's 
Refernce 13) told me that his team had successfully sent packets with 
Option Words. Again, even if the existing routers do knock out packs 
with Option words, the overlay architecture of the RANs allows the 
search for those do allow this operation. Since the use of the Option 
Word turns out to be an option to superceed IPv4's capabilities, we 
should treat it as a consideration for future premium services.


4) " ...Any device that still treated 240/4 differently would need to 
be updated to treat it like anything else. .. ": Yes, this applies to 
regions that desire to enjoy the EzIP characteristics. Since the root 
of each RAN (or sub-RAN) still appears to be one of the current CG-NAT 
modules, there is no change can be detected by other CG-NAT modules. 
This avoids interoperability issues during the incremental deployment.


5) "  ...Any existing filters that dropped packets with *any* IP 
option set would have to be modified to permit the ones you define for 
EzIP":  Since EzIP is not going to activate Option Words initially 
for enhancing the CG-NAT, this should not be a concern. In the future, 
inter-RAN communication by subscribers would use Option words. But, by 
that time, finite number of backbone / gateway routers among RANs 
capable of preserving Option Words would have been identified. This 
approach takes advantage of the hierarchical network configuration 
that CG-NAT has already been practicing implicitly.


6) "... ( At one point in the past, one big router vendor only allowed 
you to configure an ip-options filter based on the IANA defined 
values, not others. ) ...": Well, you are talking about the overly 
intertwined relationship between one big roouter vendor and the IANA 
which is sponsored by the former. So, this is not a technical but a 
"busniess" 

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

[Masataka Ohta]

Vasilenko Eduard via NANOG wrote:


Big OTTs installed caches all over the world.
Big OTTs support IPv6.


As large network operational cost to support IPv6 is
negligible for OTTs spending a lot more money at the
application layer, they may.


Hosts prefer IPv6.


No.

As many retail ISPs can not afford operational cost of
IPv6, they are IPv4 only, which makes hosts served by
them IPv4 only.

Possible exceptions are ISPs offering price (not
necessarily value) added network services in
noncompetitive environment. But, end users suffer
from the added price.

Masataka Ohta

RE: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

[Vasilenko Eduard via NANOG]

Big OTTs installed caches all over the world.
Big OTTs support IPv6.
Hosts prefer IPv6.
Hence, traffic becomes IPv6 to big OTTs.
It is not visible for IXes. IXes statistics on IPv6 are not representative.
Ed/
-Original Message-
From: Abraham Y. Chen [mailto:ayc...@avinta.com] 
Sent: Sunday, November 27, 2022 12:35 AM
To: Chris Welti 
Cc: NANOG ; b...@theworld.com; Vasilenko Eduard 

Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

Hi, Chris:

1) "... public fabric ... private dedicated circuits ... heavily biased
...":   You brought up an aspect that I have no knowledge about. 
However, you did not clarify how IPv6 and IPv4 are treated differently by these 
considerations which was the key parameter that we are trying to sort out. 
Thanks.

Regards,

Abe (2022-11-24 15:40)


On 2022-11-24 12:23, Chris Welti wrote:
> Hi Abe,
>
> the problem is that the AMS-IX data only covers the public fabric, but 
> the peering connections between the big CDNs/clouds and the large ISPs 
> all happen on private dedicated circuits as it is so much traffic that 
> it does not make sense to run it over a public IX fabric (in addition 
> to local caches which dillute the stats even more). Thus that data you 
> are referring to is heavily biased and should not be used for this 
> generalized purpose.
>
> Regards,
> Chris
>
> On 24.11.22 18:01, Abraham Y. Chen wrote:
>> Hi, Eduard:
>>
>> 0) Thanks for sharing your research efforts.
>>
>> 1) Similar as your own experience, we also recognized the granularity 
>> issue of the data in this particular type of statistics. Any data 
>> that is based on a limited number of countries, regions, businesses, 
>> industry segments, etc. will always be rebutted with a counter 
>> example of some sort. So, we put more trust into those general 
>> service cases with continuous reports for consistency, such as 
>> AMS-IX. If you know any better sources, I would like to look into them.
>>
>> Regards,
>>
>>
>> Abe (2022-11-24 11:59 EST)
>>
>>
>> On 2022-11-24 04:43, Vasilenko Eduard wrote:
>>> Hi Abraham,
>>> Let me clarify a little bit on statistics - I did an investigation 
>>> last year.
>>>
>>> Google and APNIC report very similar numbers. APNIC permits drilling 
>>> down deep details. Then it is possible to understand that they see 
>>> only 100M Chinese. China itself reports 0.5B IPv6 users. APNIC gives 
>>> Internet population by country - it permits to construct proportion.
>>> Hence, it is possible to conclude that we need to add 8% to Google 
>>> (or APNIC) to get 48% of IPv6 preferred users worldwide. We would 
>>> likely cross 50% this year.
>>>
>>> I spent a decent time finding traffic statics. I have found one DPI 
>>> vendor who has it. Unfortunately, they sell it for money.
>>> ARCEP has got it for France and published it in their "Barometer". 
>>> Almost 70% of application requests are possible to serve from IPv6.
>>> Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6 
>>> worldwide because France is typical.
>>> My boss told me "No-No" for this logic. His example is China where 
>>> we had reliable data for only 20% of application requests served on
>>> IPv6 (China has a very low IPv6 adoption by OTTs).
>>> My response was: But India has a much better IPv6 adoption on the 
>>> web server side. China and a few other countries are not 
>>> representative. The majority are like France.
>>> Unfortunately, we do not have per-country IPv6 adoption on the web 
>>> server side.
>>> OK. We could estimate 60% of the application readiness as a minimum. 
>>> Then 60%*48%=28.8%.
>>> Hence, we could claim that at least 1/4 of the worldwide traffic is 
>>> IPv6.
>>>
>>> IX data shows much low IPv6 adoption because the biggest OTTs have 
>>> many caches installed directly on Carriers' sites.
>>>
>>> Sorry for not the exact science. But it is all that I have. It is 
>>> better than nothing.
>>>
>>> PS: 60% of requests served by web servers does not mean "60% of 
>>> servers". For servers themselves we have statistics - it is just 
>>> 20%+. But it is for the biggest web resources.
>>>
>>> Eduard
>>> -Original Message-
>>> From: NANOG
>>> [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
>>> Behalf Of Abraham Y. Chen
>>> Sent: Thursday, November 24, 2022 11:53 AM
>>> To: Joe Maimon
>>> Cc: NANOG;b...@th

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

[Mark Andrews]

> On 24 Nov 2022, at 19:53, Abraham Y. Chen  wrote:
> 
> Dear Joe:
> 
> 0) Allow me to share my understanding of the two topics that you brought up.
> 
> 1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks like 
> we’ve gone from ~0% to ~40% in 12 years ":  Your numbers may be deceiving.
> 
>   A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified 
> on 2017-07-14. So, the IPv6 efforts have been quite a few years more than 
> your impression. That is, the IPv6 has been around over quarter of a century.

Which doesn’t change that fact that the traffic to Google has gone from ~0% to 
40% in 12 years.  No one claimed that Google has been measuring IPv6 traffic 
since the very beginning nor does it really matter how long it has been since 
IPv6 was defined.  What we are seeing is strong continuing growth in IPv6 usage 
where the S curve is a long way from flattening off.
  
>   B. If you read closely, the statement  "The graph shows the percentage of 
> users that access Google over IPv6." above the graph actually means 
> "equipment readiness". That is, how many Google users have IPv6 capable 
> devices. This is similar as the APNIC statistics whose title makes this 
> clearer. However, having the capability does not mean the owners are actually 
> using it. Also, this is not general data, but within the Google environment. 
> Since Google is one of the stronger promoters of the IPv6, this graph would 
> be at best the cap of such data.

If you read it correctly Google is measuring actual traffic.  Thats actual data 
flowing to and from Google's servers be it Gmail, YouTube, search traffic or 
anything else.  It does mean that the owners of the devices are using IPv6.

>   C. The more meaningful data would be the global IPv6 traffic statistics. 
> Interestingly, they do not exist upon our extensive search. (If you know of 
> any, I would appreciate to receive a lead to such.) The closest that we could 
> find is % of IPv6 in AMS-IX traffic statistics (see URL below). It is 
> currently at about 5-6% and has been tapering off to a growth of less than 
> 0.1% per month recently, after a ramp-up period in the past. (Similar 
> saturation behavior can also be found in the above Google graph.)
> 
> https://stats.ams-ix.net/sflow/ether_type.html

What makes that “more meaningful” data.  I just see different populations of 
users being measured.  Google's data also shows businesses making at about 4% 
if you look at the weekly trends that show IPv6 usage spiking on the weekend as 
business users traffic drops off.

>   D.  One interesting parameter behind the last one is that as an 
> Inter-eXchange operator, AMS-IX should see very similar percentage traffic 
> mix between IPv6 and IPv4. The low numbers from AMS-IX does not support this 
> viewpoint for matching with your observation. In addition, traffic through IX 
> is the overflow among backbone routers. A couple years ago, there was a 
> report that peering arrangements among backbone routers for IPv6 were much 
> less matured then IPv4, which meant that AMS-IX should be getting more IPv6 
> traffic than the mix in the Internet core. Interpreted in reverse, % of IPv6 
> in overall Internet traffic should be less than what AMS-IX handles.
> 
>   E. This is a quite convoluted topic that we only scratched the surface. 
> They should not occupy the attention of colleagues on this list. However, I 
> am willing to provide more information to you off-line, if you care for 
> further discussion.
> 
> 2)  "... https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/ ...": 
>  My basic training was in communication equipment hardware design. I knew 
> little about software beyond what I needed for my primary assignment. Your 
> example, however, reminds me of a programing course that I took utilizing APL 
> (A Programming Language) for circuit analysis, optimization and synthesis. It 
> was such a cryptic symbolic language that classmates (mostly majored in EE 
> hardware) were murmuring to express their displeasure. One day we got a 
> homework assignment to do something relatively simple. Everyone struggled to 
> write the code to do the job. Although most of us did get working codes, they 
> were pages long. The shortest one was one full page. Upon reviewed all 
> homework, the professor smiled at us and told us to look for the solution 
> section at the end of the text book. It turned out to be the answer for a 
> problem in the next chapter to be covered. The code was only three lines 
> long! Although it did not have the codes for debugging purposes, it covered 
> all error messages expected. It was such a shocker that everyone quieted down 
> to focus on the subject for the rest of the semester. During my first 
> employment, we had the need to optimize circuit designs. Since I was the only 
> staff who knew about it, I ended up being the coordinator between several 
> hardware designers and the supporting 

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

[Dave Taht]

On Mon, Nov 21, 2022 at 4:05 PM David Conrad  wrote:
>
> Barry,
>
> On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote:
>
> We've been trying to get people to adopt IPv6 widely for 30 years with very 
> limited success
>
>
> According to https://www.google.com/intl/en/ipv6/statistics.html, it looks 
> like we’ve gone from ~0% to ~40% in 12 years. 
> https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet 
> population of about 5B, this can (simplistically and wrongly) argued to mean 
> 1.5-2B people are using IPv6. For a transition to a technology that the vast 
> majority of people who pay the bills will neither notice nor care about, and 
> for which the business case typically needs projection way past the normal 
> quarterly focus of shareholders, that seems pretty successful to me.
>
> But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, 
> the fundamental and obvious flaw is the assertion of "commenting out one line 
> code”. There isn’t “one line of code”. There are literally _billions_ of 
> instances of “one line of code”, the vast majority of which need to be 
> changed/deployed/tested with absolutely no business case to do so that isn’t 
> better met with deploying IPv6+IPv4aaS. I believe this has been pointed out 
> numerous times, but it falls on deaf ears, so the discussion gets a bit 
> tedious.

I have been trying to steer clear of this debate this time around, but
since I'm the one that made that analogy to begin with...

There are now billions and billions of *non-instances* of this one
line of code, saving nanoseconds on every connection, since 2008 in
the case of 240/4 and 2018 in the case of 0/8 - and that savings
alone, I felt was worth it. No additional future use is required from
my perspective to have realized real economic value from these address
spaces.

It would be rather nice, if, over time, we pretty much agreed that
embedding an 1981 policy into future OS kernels and routers transport
mechanisms was silly.

Full stop. Can someone citing me about the non-wisdom of "delete 1
line of code from everything" try to explain why our OSes MUST
continue enforcing some distinction between 240/4 and 0/8 and the rest
of the known unicast internet?

...

To take the next step - towards some sort of allocation policy - is a
matter of years and years. The subject of current research is what
does trying to make it work, break? I regularly use 240 nowadays
myself where I am not sure where the rfc1918 space is... or on a vpn -
eating my dogfood - but I do think it would be a tragic waste if we
didn't make an effort to make them globally usable in the long run.

I also tend to be upset by the argument that "this must work
internet-wide, on everything, forever, and immediately", which of
course, doesn't apply to ipv6 either.

No, it just needs to work on islands with limited address space,
initially. Tunnels between forward thinking providers, perhaps.
Starlink could use it to address terminals if they wanted - they still
don't have ipv6 working worth a darn -

I've also said a lot, that "the prospect of a portion of the internet
completely immune to windows-born viruses and worms is really
pleasing..." and I get a lot of laughs from that, because it's true -
If you've been in the trenches, fighting those off for the last few
decades, knowing that *some* piece of your infrastructure couldn't be
subject to those sort of attacks from old or windows OSes is a relief.

Arguments for deploying ipv6 remain! There's no escaping ipv6, and I
spend a lot of time trying to convince ISPs nowadays to deploy that,
but *all* of the ones I'm presently working with still must provide
IPv4 space, and thus are deploying CGNAT more rapidly than ipv6. I
will keep trying to get ipv6 deployed at every chance I get! I'm very
happy to have finally got ipv6 trie support into libreqos.io a few
weeks ago - but the demand is all cgnat, and mpls and vlans and ipv4
tunnels - I'd love to find a customer to try out our new ipv6 support,
because despite trying for months, we don't have any, as yet.

Blatant plug: 
https://github.com/LibreQoE/LibreQoS/tree/main/v1.3#v13-ipv4--ipv6-beta

Anyway... some use of these new ipv4 address spaces is inevitable, and
I really do wish y'all cared more about nanoseconds,
here or there, or anywhere.

>
> Regards,
> -drc
>


-- 
This song goes out to all the folk that thought Stadia would work:
https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
Dave Täht CEO, TekLibre, LLC

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

[John Gilmore]

John Curran  wrote:
>> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/
>
> ... this Internet draft ... can't be safely deployed in the actual
> real-world Internet

The draft *has been* safely deployed in the actual real-world Internet.
It is in all Linux nodes since 2008, and all recent Cisco routers.  We
know that this step is safe, because it was already done a decade ago,
and the Internet did not descend into flames (except on mailing lists
;-).  The draft is just trying to help the paperwork catch up with the
implementations.

So it seems that John Curran was criticizing a strawman rather than the
draft above (which I co-authored).  Perhaps the confusion is that John
thought that the draft would actually allocate 240/4 addresses to
end-users for end-user purposes.  Doing that would be unsafe in today's
big Internet (though major squatters are already using these addresses
in private clouds, as RIPE and Google have documented).  Allocating
these addresses would be far more controversial than just updating the
code in IPv4 implementations.  Therefore, the draft doesn't do that.
Instead it would just clear out the cobwebs in implementations, which
would some years later, after more work, allow a responsible party to
make such allocations.  John's suggestion that "it's unsafe to do this
safe change, because we don't yet know *when* some later change will be
safe" is simply incorrect.

Perhaps what the draft failed to explain is that "Merely implementing
unicast treatment of 240/4 addresses in routers and operating systems,
as this draft proposes, does not cause any interoperability issues.
Hundreds of millions of IPv4 nodes currently contain this unicast
treatment, and all are interoperating successfully with each other and
with non-updated nodes."  We'll add something like that to the next
version.

John Gilmore
IPv4 Unicast Extensions Project

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

[Abraham Y. Chen]

Hi, Chris:

1) "... public fabric ... private dedicated circuits ... heavily biased 
...":   You brought up an aspect that I have no knowledge about. 
However, you did not clarify how IPv6 and IPv4 are treated differently 
by these considerations which was the key parameter that we are trying 
to sort out. Thanks.


Regards,

Abe (2022-11-24 15:40)


On 2022-11-24 12:23, Chris Welti wrote:

Hi Abe,

the problem is that the AMS-IX data only covers the public fabric, but 
the peering connections between the big CDNs/clouds and the large ISPs 
all happen on private dedicated circuits as it is so much traffic that 
it does not make sense to run it over a public IX fabric (in addition 
to local caches which dillute the stats even more). Thus that data you 
are referring to is heavily biased and should not be used for this 
generalized purpose.


Regards,
Chris

On 24.11.22 18:01, Abraham Y. Chen wrote:

Hi, Eduard:

0) Thanks for sharing your research efforts.

1) Similar as your own experience, we also recognized the granularity 
issue of the data in this particular type of statistics. Any data 
that is based on a limited number of countries, regions, businesses, 
industry segments, etc. will always be rebutted with a counter 
example of some sort. So, we put more trust into those general 
service cases with continuous reports for consistency, such as 
AMS-IX. If you know any better sources, I would like to look into them.


Regards,


Abe (2022-11-24 11:59 EST)


On 2022-11-24 04:43, Vasilenko Eduard wrote:

Hi Abraham,
Let me clarify a little bit on statistics - I did an investigation 
last year.


Google and APNIC report very similar numbers. APNIC permits drilling 
down deep details. Then it is possible to understand that they see 
only 100M Chinese. China itself reports 0.5B IPv6 users. APNIC gives 
Internet population by country - it permits to construct proportion.
Hence, it is possible to conclude that we need to add 8% to Google 
(or APNIC) to get 48% of IPv6 preferred users worldwide. We would 
likely cross 50% this year.


I spent a decent time finding traffic statics. I have found one DPI 
vendor who has it. Unfortunately, they sell it for money.
ARCEP has got it for France and published it in their "Barometer". 
Almost 70% of application requests are possible to serve from IPv6.
Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6 
worldwide because France is typical.
My boss told me "No-No" for this logic. His example is China where 
we had reliable data for only 20% of application requests served on 
IPv6 (China has a very low IPv6 adoption by OTTs).
My response was: But India has a much better IPv6 adoption on the 
web server side. China and a few other countries are not 
representative. The majority are like France.
Unfortunately, we do not have per-country IPv6 adoption on the web 
server side.
OK. We could estimate 60% of the application readiness as a minimum. 
Then 60%*48%=28.8%.
Hence, we could claim that at least 1/4 of the worldwide traffic is 
IPv6.


IX data shows much low IPv6 adoption because the biggest OTTs have 
many caches installed directly on Carriers' sites.


Sorry for not the exact science. But it is all that I have. It is 
better than nothing.


PS: 60% of requests served by web servers does not mean "60% of 
servers". For servers themselves we have statistics - it is just 
20%+. But it is for the biggest web resources.


Eduard
-Original Message-
From: NANOG 
[mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Abraham Y. Chen

Sent: Thursday, November 24, 2022 11:53 AM
To: Joe Maimon
Cc: NANOG;b...@theworld.com
Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

Dear Joe:

0) Allow me to share my understanding of the two topics that you 
brought up.


1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks 
like we’ve gone from ~0% to ~40% in 12 years ": Your numbers may 
be deceiving.


    A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 
and ratified on 2017-07-14. So, the IPv6 efforts have been quite a 
few years more than your impression. That is, the IPv6 has been 
around over quarter of a century.


    B. If you read closely, the statement  "The graph shows the 
percentage of users that access Google over IPv6." above the graph 
actually means "equipment readiness". That is, how many Google users 
have IPv6 capable devices. This is similar as the APNIC statistics 
whose title makes this clearer. However, having the capability does 
not mean the owners are actually using it. Also, this is not general 
data, but within the Google environment. Since Google is one of the 
stronger promoters of the IPv6, this graph would be at best the cap 
of such data.


    C. The more meaningful data would be the global IPv6 traffic 
statistics. Interestingly, they do not exist upon our extensive search.
(If you kn

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

[Abraham Y. Chen]

Hi, Douglas:

0) Thanks for the feedback.

1)  I do not sort eMail with any tools. Other than important ones that 
do I save a copy off the system as a document for long term reference, I 
only flag those of substance for the keeps and allow the rest to 
"expire" (I do house cleaning every three months or so.). Consequently, 
I have no idea about the terminologies that you mentioned.


2)  My basic understanding is, an eMail in its entirety is the original 
work of its composer / writer / sender. As such, a receiver is free to 
do anything with it, but not to impose certain "rules" back onto the 
writing. Through the years, eMail writing styles have diversified from 
the business letter protocols that I knew so much that I had to develop 
my own conventions of writing that enabled me to organize my eMails for 
retrieval. They seem to be tolerated by most parties that communicated 
with except NANOG. If you have certain clear rules that can pass my 
"logistics" considerations, I will definitely learn and follow.


Regards,


Abe (2022-11-24 16:00 EST)



On 2022-11-24 06:51, Douglas Fischer wrote:

Hello Abraham!

I believe your e-mail client (MUA) is splitting every message on a new 
thread.
I'm not sure if it is happening with everyone, but using Gmail as MUA, 
it isn't aggregating the mails on the same thread.


Cloud you please check the confs of your tool to avoid it?

Thanks in advance.

Em qui., 24 de nov. de 2022 às 05:56, Abraham Y. Chen 
 escreveu:


Dear Joe:

0) Allow me to share my understanding of the two topics that you
brought up.

1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks
like we’ve gone from ~0% to ~40% in 12 years ":  Your numbers
may be
deceiving.

   A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and
ratified on 2017-07-14. So, the IPv6 efforts have been quite a few
years
more than your impression. That is, the IPv6 has been around over
quarter of a century.

   B. If you read closely, the statement  "The graph shows the
percentage of users that access Google over IPv6." above the graph
actually means "equipment readiness". That is, how many Google users
have IPv6 capable devices. This is similar as the APNIC statistics
whose
title makes this clearer. However, having the capability does not
mean
the owners are actually using it. Also, this is not general data, but
within the Google environment. Since Google is one of the stronger
promoters of the IPv6, this graph would be at best the cap of such
data.

   C. The more meaningful data would be the global IPv6 traffic
statistics. Interestingly, they do not exist upon our extensive
search.
(If you know of any, I would appreciate to receive a lead to
such.) The
closest that we could find is % of IPv6 in AMS-IX traffic statistics
(see URL below). It is currently at about 5-6% and has been
tapering off
to a growth of less than 0.1% per month recently, after a ramp-up
period
in the past. (Similar saturation behavior can also be found in the
above
Google graph.)

https://stats.ams-ix.net/sflow/ether_type.html

   D.  One interesting parameter behind the last one is that as an
Inter-eXchange operator, AMS-IX should see very similar percentage
traffic mix between IPv6 and IPv4. The low numbers from AMS-IX
does not
support this viewpoint for matching with your observation. In
addition,
traffic through IX is the overflow among backbone routers. A couple
years ago, there was a report that peering arrangements among
backbone
routers for IPv6 were much less matured then IPv4, which meant that
AMS-IX should be getting more IPv6 traffic than the mix in the
Internet
core. Interpreted in reverse, % of IPv6 in overall Internet traffic
should be less than what AMS-IX handles.

   E. This is a quite convoluted topic that we only scratched the
surface. They should not occupy the attention of colleagues on this
list. However, I am willing to provide more information to you
off-line,
if you care for further discussion.

2)  "...
https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/
...":  My basic training was in communication equipment hardware
design.
I knew little about software beyond what I needed for my primary
assignment. Your example, however, reminds me of a programing course
that I took utilizing APL (A Programming Language) for circuit
analysis,
optimization and synthesis. It was such a cryptic symbolic
language that
classmates (mostly majored in EE hardware) were murmuring to express
their displeasure. One day we got a homework assignment to do
something
relatively simple. Everyone struggled to write the code to do the
job.
Although most of us did get working codes, they were pages long. The
shortest one 

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

[Fred Baker]

> What's the group's current thought on emergence or prevalence of
> IPv6-only hosts ?

They aren’t needed; dual stack hosts will work just fine in a single stack 
network. When they’re needed, they will be normal but nobody will care.

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

[Chris Welti]

Hi Abe,

the problem is that the AMS-IX data only covers the public fabric, but 
the peering connections between the big CDNs/clouds and the large ISPs 
all happen on private dedicated circuits as it is so much traffic that 
it does not make sense to run it over a public IX fabric (in addition to 
local caches which dillute the stats even more). Thus that data you are 
referring to is heavily biased and should not be used for this 
generalized purpose.


Regards,
Chris

On 24.11.22 18:01, Abraham Y. Chen wrote:

Hi, Eduard:

0) Thanks for sharing your research efforts.

1) Similar as your own experience, we also recognized the granularity 
issue of the data in this particular type of statistics. Any data that 
is based on a limited number of countries, regions, businesses, 
industry segments, etc. will always be rebutted with a counter example 
of some sort. So, we put more trust into those general service cases 
with continuous reports for consistency, such as AMS-IX. If you know 
any better sources, I would like to look into them.


Regards,


Abe (2022-11-24 11:59 EST)


On 2022-11-24 04:43, Vasilenko Eduard wrote:

Hi Abraham,
Let me clarify a little bit on statistics - I did an investigation 
last year.


Google and APNIC report very similar numbers. APNIC permits drilling 
down deep details. Then it is possible to understand that they see 
only 100M Chinese. China itself reports 0.5B IPv6 users. APNIC gives 
Internet population by country - it permits to construct proportion.
Hence, it is possible to conclude that we need to add 8% to Google 
(or APNIC) to get 48% of IPv6 preferred users worldwide. We would 
likely cross 50% this year.


I spent a decent time finding traffic statics. I have found one DPI 
vendor who has it. Unfortunately, they sell it for money.
ARCEP has got it for France and published it in their "Barometer". 
Almost 70% of application requests are possible to serve from IPv6.
Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6 
worldwide because France is typical.
My boss told me "No-No" for this logic. His example is China where we 
had reliable data for only 20% of application requests served on IPv6 
(China has a very low IPv6 adoption by OTTs).
My response was: But India has a much better IPv6 adoption on the web 
server side. China and a few other countries are not representative. 
The majority are like France.
Unfortunately, we do not have per-country IPv6 adoption on the web 
server side.
OK. We could estimate 60% of the application readiness as a minimum. 
Then 60%*48%=28.8%.
Hence, we could claim that at least 1/4 of the worldwide traffic is 
IPv6.


IX data shows much low IPv6 adoption because the biggest OTTs have 
many caches installed directly on Carriers' sites.


Sorry for not the exact science. But it is all that I have. It is 
better than nothing.


PS: 60% of requests served by web servers does not mean "60% of 
servers". For servers themselves we have statistics - it is just 
20%+. But it is for the biggest web resources.


Eduard
-Original Message-
From: NANOG 
[mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Abraham Y. Chen

Sent: Thursday, November 24, 2022 11:53 AM
To: Joe Maimon
Cc: NANOG;b...@theworld.com
Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

Dear Joe:

0) Allow me to share my understanding of the two topics that you 
brought up.


1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks 
like we’ve gone from ~0% to ~40% in 12 years ":  Your numbers may 
be deceiving.


    A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and 
ratified on 2017-07-14. So, the IPv6 efforts have been quite a few 
years more than your impression. That is, the IPv6 has been around 
over quarter of a century.


    B. If you read closely, the statement  "The graph shows the 
percentage of users that access Google over IPv6." above the graph 
actually means "equipment readiness". That is, how many Google users 
have IPv6 capable devices. This is similar as the APNIC statistics 
whose title makes this clearer. However, having the capability does 
not mean the owners are actually using it. Also, this is not general 
data, but within the Google environment. Since Google is one of the 
stronger promoters of the IPv6, this graph would be at best the cap 
of such data.


    C. The more meaningful data would be the global IPv6 traffic 
statistics. Interestingly, they do not exist upon our extensive search.
(If you know of any, I would appreciate to receive a lead to such.) 
The closest that we could find is % of IPv6 in AMS-IX traffic 
statistics (see URL below). It is currently at about 5-6% and has 
been tapering off to a growth of less than 0.1% per month recently, 
after a ramp-up period in the past. (Similar saturation behavior can 
also be found in the above Google graph.)


https://stats.ams-ix.net/sfl

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

[Abraham Y. Chen]

Hi, Eduard:

0) Thanks for sharing your research efforts.

1) Similar as your own experience, we also recognized the granularity 
issue of the data in this particular type of statistics. Any data that 
is based on a limited number of countries, regions, businesses, industry 
segments, etc. will always be rebutted with a counter example of some 
sort. So, we put more trust into those general service cases with 
continuous reports for consistency, such as AMS-IX. If you know any 
better sources, I would like to look into them.


Regards,


Abe (2022-11-24 11:59 EST)


On 2022-11-24 04:43, Vasilenko Eduard wrote:

Hi Abraham,
Let me clarify a little bit on statistics - I did an investigation last year.

Google and APNIC report very similar numbers. APNIC permits drilling down deep 
details. Then it is possible to understand that they see only 100M Chinese. 
China itself reports 0.5B IPv6 users. APNIC gives Internet population by 
country - it permits to construct proportion.
Hence, it is possible to conclude that we need to add 8% to Google (or APNIC) 
to get 48% of IPv6 preferred users worldwide. We would likely cross 50% this 
year.

I spent a decent time finding traffic statics. I have found one DPI vendor who 
has it. Unfortunately, they sell it for money.
ARCEP has got it for France and published it in their "Barometer". Almost 70% 
of application requests are possible to serve from IPv6.
Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6 worldwide 
because France is typical.
My boss told me "No-No" for this logic. His example is China where we had 
reliable data for only 20% of application requests served on IPv6 (China has a very low 
IPv6 adoption by OTTs).
My response was: But India has a much better IPv6 adoption on the web server 
side. China and a few other countries are not representative. The majority are 
like France.
Unfortunately, we do not have per-country IPv6 adoption on the web server side.
OK. We could estimate 60% of the application readiness as a minimum. Then 
60%*48%=28.8%.
Hence, we could claim that at least 1/4 of the worldwide traffic is IPv6.

IX data shows much low IPv6 adoption because the biggest OTTs have many caches 
installed directly on Carriers' sites.

Sorry for not the exact science. But it is all that I have. It is better than 
nothing.

PS: 60% of requests served by web servers does not mean "60% of servers". For 
servers themselves we have statistics - it is just 20%+. But it is for the biggest web 
resources.

Eduard
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Abraham Y. Chen
Sent: Thursday, November 24, 2022 11:53 AM
To: Joe Maimon
Cc: NANOG;b...@theworld.com
Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

Dear Joe:

0) Allow me to share my understanding of the two topics that you brought up.

1) "...https://www.google.com/intl/en/ipv6/statistics.html, it looks like we’ve gone 
from ~0% to ~40% in 12 years ":  Your numbers may be deceiving.

    A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified 
on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your 
impression. That is, the IPv6 has been around over quarter of a century.

    B. If you read closely, the statement  "The graph shows the percentage of users that 
access Google over IPv6." above the graph actually means "equipment readiness". That 
is, how many Google users have IPv6 capable devices. This is similar as the APNIC statistics whose 
title makes this clearer. However, having the capability does not mean the owners are actually 
using it. Also, this is not general data, but within the Google environment. Since Google is one of 
the stronger promoters of the IPv6, this graph would be at best the cap of such data.

    C. The more meaningful data would be the global IPv6 traffic statistics. 
Interestingly, they do not exist upon our extensive search.
(If you know of any, I would appreciate to receive a lead to such.) The closest 
that we could find is % of IPv6 in AMS-IX traffic statistics (see URL below). 
It is currently at about 5-6% and has been tapering off to a growth of less 
than 0.1% per month recently, after a ramp-up period in the past. (Similar 
saturation behavior can also be found in the above Google graph.)

https://stats.ams-ix.net/sflow/ether_type.html

    D.  One interesting parameter behind the last one is that as an 
Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix 
between IPv6 and IPv4. The low numbers from AMS-IX does not support this 
viewpoint for matching with your observation. In addition, traffic through IX 
is the overflow among backbone routers. A couple years ago, there was a report 
that peering arrangements among backbone routers for IPv6 were much less 
matured then IPv4, which meant that AMS-IX should be getting more 

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

[Douglas Fischer]

Hello Abraham!

I believe your e-mail client (MUA) is splitting every message on a new
thread.
I'm not sure if it is happening with everyone, but using Gmail as MUA, it
isn't aggregating the mails on the same thread.

Cloud you please check the confs of your tool to avoid it?

Thanks in advance.

Em qui., 24 de nov. de 2022 às 05:56, Abraham Y. Chen 
escreveu:

> Dear Joe:
>
> 0) Allow me to share my understanding of the two topics that you brought
> up.
>
> 1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks
> like we’ve gone from ~0% to ~40% in 12 years ":  Your numbers may be
> deceiving.
>
>A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and
> ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years
> more than your impression. That is, the IPv6 has been around over
> quarter of a century.
>
>B. If you read closely, the statement  "The graph shows the
> percentage of users that access Google over IPv6." above the graph
> actually means "equipment readiness". That is, how many Google users
> have IPv6 capable devices. This is similar as the APNIC statistics whose
> title makes this clearer. However, having the capability does not mean
> the owners are actually using it. Also, this is not general data, but
> within the Google environment. Since Google is one of the stronger
> promoters of the IPv6, this graph would be at best the cap of such data.
>
>C. The more meaningful data would be the global IPv6 traffic
> statistics. Interestingly, they do not exist upon our extensive search.
> (If you know of any, I would appreciate to receive a lead to such.) The
> closest that we could find is % of IPv6 in AMS-IX traffic statistics
> (see URL below). It is currently at about 5-6% and has been tapering off
> to a growth of less than 0.1% per month recently, after a ramp-up period
> in the past. (Similar saturation behavior can also be found in the above
> Google graph.)
>
> https://stats.ams-ix.net/sflow/ether_type.html
>
>D.  One interesting parameter behind the last one is that as an
> Inter-eXchange operator, AMS-IX should see very similar percentage
> traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not
> support this viewpoint for matching with your observation. In addition,
> traffic through IX is the overflow among backbone routers. A couple
> years ago, there was a report that peering arrangements among backbone
> routers for IPv6 were much less matured then IPv4, which meant that
> AMS-IX should be getting more IPv6 traffic than the mix in the Internet
> core. Interpreted in reverse, % of IPv6 in overall Internet traffic
> should be less than what AMS-IX handles.
>
>E. This is a quite convoluted topic that we only scratched the
> surface. They should not occupy the attention of colleagues on this
> list. However, I am willing to provide more information to you off-line,
> if you care for further discussion.
>
> 2)  "... https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/
> ...":  My basic training was in communication equipment hardware design.
> I knew little about software beyond what I needed for my primary
> assignment. Your example, however, reminds me of a programing course
> that I took utilizing APL (A Programming Language) for circuit analysis,
> optimization and synthesis. It was such a cryptic symbolic language that
> classmates (mostly majored in EE hardware) were murmuring to express
> their displeasure. One day we got a homework assignment to do something
> relatively simple. Everyone struggled to write the code to do the job.
> Although most of us did get working codes, they were pages long. The
> shortest one was one full page. Upon reviewed all homework, the
> professor smiled at us and told us to look for the solution section at
> the end of the text book. It turned out to be the answer for a problem
> in the next chapter to be covered. The code was only three lines long!
> Although it did not have the codes for debugging purposes, it covered
> all error messages expected. It was such a shocker that everyone quieted
> down to focus on the subject for the rest of the semester. During my
> first employment, we had the need to optimize circuit designs. Since I
> was the only staff who knew about it, I ended up being the coordinator
> between several hardware designers and the supporting programmer. From
> that teaching, I am always looking for the most concise solution to an
> issue, not being distracted or discouraged by the manifestation on the
> surface.
>
> https://en.wikipedia.org/wiki/APL_(programming_language)
>
> 3) Fast forward half a century, I am hoping that my "one-line code"
> serves the purpose of "there exists" an example in proofing a
> mathematical theorem for  inspiring software colleagues to review the
> network codes in front of them for improvement, instead of presenting
> such as a valid hurdle to progress.
>
>
> Regards,
>
>
> Abe (2022-11-24 03:53 EST)
>
>
>
>
>
> 

RE: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

[Vasilenko Eduard via NANOG]

Hi Abraham,
Let me clarify a little bit on statistics - I did an investigation last year.

Google and APNIC report very similar numbers. APNIC permits drilling down deep 
details. Then it is possible to understand that they see only 100M Chinese. 
China itself reports 0.5B IPv6 users. APNIC gives Internet population by 
country - it permits to construct proportion.
Hence, it is possible to conclude that we need to add 8% to Google (or APNIC) 
to get 48% of IPv6 preferred users worldwide. We would likely cross 50% this 
year.

I spent a decent time finding traffic statics. I have found one DPI vendor who 
has it. Unfortunately, they sell it for money.
ARCEP has got it for France and published it in their "Barometer". Almost 70% 
of application requests are possible to serve from IPv6.
Hence, 70%*48%=33.6%. We could claim that 1/3 of the traffic is IPv6 worldwide 
because France is typical.
My boss told me "No-No" for this logic. His example is China where we had 
reliable data for only 20% of application requests served on IPv6 (China has a 
very low IPv6 adoption by OTTs).
My response was: But India has a much better IPv6 adoption on the web server 
side. China and a few other countries are not representative. The majority are 
like France.
Unfortunately, we do not have per-country IPv6 adoption on the web server side.
OK. We could estimate 60% of the application readiness as a minimum. Then 
60%*48%=28.8%.
Hence, we could claim that at least 1/4 of the worldwide traffic is IPv6.

IX data shows much low IPv6 adoption because the biggest OTTs have many caches 
installed directly on Carriers' sites.

Sorry for not the exact science. But it is all that I have. It is better than 
nothing.

PS: 60% of requests served by web servers does not mean "60% of servers". For 
servers themselves we have statistics - it is just 20%+. But it is for the 
biggest web resources.

Eduard
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Abraham Y. Chen
Sent: Thursday, November 24, 2022 11:53 AM
To: Joe Maimon 
Cc: NANOG ; b...@theworld.com
Subject: Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC

Dear Joe:

0) Allow me to share my understanding of the two topics that you brought up.

1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks like 
we’ve gone from ~0% to ~40% in 12 years ":  Your numbers may be deceiving.

   A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and ratified 
on 2017-07-14. So, the IPv6 efforts have been quite a few years more than your 
impression. That is, the IPv6 has been around over quarter of a century.

   B. If you read closely, the statement  "The graph shows the percentage of 
users that access Google over IPv6." above the graph actually means "equipment 
readiness". That is, how many Google users have IPv6 capable devices. This is 
similar as the APNIC statistics whose title makes this clearer. However, having 
the capability does not mean the owners are actually using it. Also, this is 
not general data, but within the Google environment. Since Google is one of the 
stronger promoters of the IPv6, this graph would be at best the cap of such 
data.

   C. The more meaningful data would be the global IPv6 traffic statistics. 
Interestingly, they do not exist upon our extensive search. 
(If you know of any, I would appreciate to receive a lead to such.) The closest 
that we could find is % of IPv6 in AMS-IX traffic statistics (see URL below). 
It is currently at about 5-6% and has been tapering off to a growth of less 
than 0.1% per month recently, after a ramp-up period in the past. (Similar 
saturation behavior can also be found in the above Google graph.)

https://stats.ams-ix.net/sflow/ether_type.html

   D.  One interesting parameter behind the last one is that as an 
Inter-eXchange operator, AMS-IX should see very similar percentage traffic mix 
between IPv6 and IPv4. The low numbers from AMS-IX does not support this 
viewpoint for matching with your observation. In addition, traffic through IX 
is the overflow among backbone routers. A couple years ago, there was a report 
that peering arrangements among backbone routers for IPv6 were much less 
matured then IPv4, which meant that AMS-IX should be getting more IPv6 traffic 
than the mix in the Internet core. Interpreted in reverse, % of IPv6 in overall 
Internet traffic should be less than what AMS-IX handles.

   E. This is a quite convoluted topic that we only scratched the surface. They 
should not occupy the attention of colleagues on this list. However, I am 
willing to provide more information to you off-line, if you care for further 
discussion.

2)  "... https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/
...":  My basic training was in communication equipment hardware design. 
I knew little about software beyond what I needed for my primary

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

[Abraham Y. Chen]

Dear Mathew:

0) Appreciate very much for your professionalism. Technical discussions 
over cyberspace like this are very challenging because the lack of 
instant feedback. One person could write a long essay without knowing 
that it is already off the track. Compounded with not knowing the other 
person's background, knowledge, current situation, etc., it takes some 
effort to zero into the essence for synchronizing the two parties. I am 
glad for your patience and persistence in drilling into the topic of 
your concern and pressing me for the answer. This is the only way to 
move forward.


1) From what you detailed, I believe that I now know the gap between us. 
What I have been describing is EzIP's proposal of enhancing CG-NAT, not 
deploying a brand new network. It is implicit that everything else in 
the current CG-NAT shall not be touched. That is, simply replacing 
100.64/10 netblock with 240/4 netblock will complete the first and key 
step of the EzIP deployment. All of the existing CG-NAT configurations 
and operations that you referred to are not to be disturbed.


2)  As to the "umbilical cord" versus "single point of failure", 
"multi-homing" concerns, I was talking about EzIP from network 
architectural point of view, which needs only one physical channel. This 
does not prevent additional facilities for operational considerations 
such as traffic volume, load balancing, reliability, redundancy, etc. 
That is, it is implicit from the way that Pt. 1) is presented these are 
not to be removed.


Hope this quick brief response brings us back on track. Let me know if 
the above makes sense. Then, I will work on other topics.


Regards,


Abe (2022-11-24 04:41 EST)


On 2022-11-23 22:36, Matthew Petach wrote:



On Tue, Nov 22, 2022 at 8:26 PM Abraham Y. Chen  wrote:

Dear Tom: *

[...]


2)   "...Your proposal appears to rely on a specific value in the IP
option header to create your overlay": Not really, as soon as the
100.64/10 netblock is replaced by the 240/4, each CG-NAT module can
serve a very large area (such as Tokyo Metro and such) that
becomes the
RAN in EzIP terminology. Since each RAN is tethered from the existing
Internet core by an umbilical cord operating on one IPv4 public
address,
this is like a kite floating in the sky which is the basic building
block for the overlaying EzIP Sub-Internet when they expand wide
enough
to begin covering significant areas of the world. Note that
throughout
this entire process, the Option Word mechanism in the IP header
does not
need be used at all. (It turns out that utilizing the CG-NAT
configuration as the EzIP deployment vehicle, the only time that the
Option Word may be used is when subscribers in two separate RANs
wishing
to have end-to-end communication, such as direct private eMail
exchanges.)



Hi Abraham,

I notice you never replied to my earlier questions about EzIP deployment.
I'll assume for the moment that means my concerns were without merit, and
will leave them aside.

But in reading this new message, I find myself again rather confused.

You stated:
"Since each RAN is tethered from the existing Internet core by an 
umbilical cord operating on one IPv4 public address,"


I find myself staring at that statement, and puzzling over and over again
at how multi-homing would work in the EzIP world.

Would a given ISP anycast their single global public IPv4 address
to all their upstream providers from all of their edge routers,
and simply trust stable routing in the DFZ to ensure packets arrived
at the correct ingress location to be mapped from the public internet
into the RAN?

Or do you really mean that every RAN will have one giant single point
of failure, a single uplink through which all traffic must pass in 
order to

reach the DFZ public internet?

If your regional network is a housing subdivision, I can understand the
model of a single uplink connection for it; but for anything much larger,
a single uplink seems like an unsustainable model.  You mention Tokyo 
Metro
in your message as an example.  What size single uplink do. you think 
would
be sufficient to support all the users in the Tokyo Metro region?  And 
how
unhappy would they be if the single router their 1 public IP address 
lived

on happened to have a hardware failure?

Wouldn't it be better if the proposed model built in support for
multihoming from day one, to provide a similar level of redundancy
to what is currently available on the Internet today?

Or is EzIP designed solely for small, singled-homed residential
customers, and is not intended at all for enterprise customers
who desire a more resilient level of connectivity?

As I noted in my previous message, this seems like an awful lot of
work to go through for relatively little benefit--but this may simply be
due to a lack of essential clue on my part.  I would very much like to
be enlightened.

Thank you!

Matt




--

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

[Abraham Y. Chen]

Dear Joe:

0) Allow me to share my understanding of the two topics that you brought up.

1) "... https://www.google.com/intl/en/ipv6/statistics.html, it looks 
like we’ve gone from ~0% to ~40% in 12 years ":  Your numbers may be 
deceiving.


  A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and 
ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years 
more than your impression. That is, the IPv6 has been around over 
quarter of a century.


  B. If you read closely, the statement  "The graph shows the 
percentage of users that access Google over IPv6." above the graph 
actually means "equipment readiness". That is, how many Google users 
have IPv6 capable devices. This is similar as the APNIC statistics whose 
title makes this clearer. However, having the capability does not mean 
the owners are actually using it. Also, this is not general data, but 
within the Google environment. Since Google is one of the stronger 
promoters of the IPv6, this graph would be at best the cap of such data.


  C. The more meaningful data would be the global IPv6 traffic 
statistics. Interestingly, they do not exist upon our extensive search. 
(If you know of any, I would appreciate to receive a lead to such.) The 
closest that we could find is % of IPv6 in AMS-IX traffic statistics 
(see URL below). It is currently at about 5-6% and has been tapering off 
to a growth of less than 0.1% per month recently, after a ramp-up period 
in the past. (Similar saturation behavior can also be found in the above 
Google graph.)


https://stats.ams-ix.net/sflow/ether_type.html

  D.  One interesting parameter behind the last one is that as an 
Inter-eXchange operator, AMS-IX should see very similar percentage 
traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not 
support this viewpoint for matching with your observation. In addition, 
traffic through IX is the overflow among backbone routers. A couple 
years ago, there was a report that peering arrangements among backbone 
routers for IPv6 were much less matured then IPv4, which meant that 
AMS-IX should be getting more IPv6 traffic than the mix in the Internet 
core. Interpreted in reverse, % of IPv6 in overall Internet traffic 
should be less than what AMS-IX handles.


  E. This is a quite convoluted topic that we only scratched the 
surface. They should not occupy the attention of colleagues on this 
list. However, I am willing to provide more information to you off-line, 
if you care for further discussion.


2)  "... https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/ 
...":  My basic training was in communication equipment hardware design. 
I knew little about software beyond what I needed for my primary 
assignment. Your example, however, reminds me of a programing course 
that I took utilizing APL (A Programming Language) for circuit analysis, 
optimization and synthesis. It was such a cryptic symbolic language that 
classmates (mostly majored in EE hardware) were murmuring to express 
their displeasure. One day we got a homework assignment to do something 
relatively simple. Everyone struggled to write the code to do the job. 
Although most of us did get working codes, they were pages long. The 
shortest one was one full page. Upon reviewed all homework, the 
professor smiled at us and told us to look for the solution section at 
the end of the text book. It turned out to be the answer for a problem 
in the next chapter to be covered. The code was only three lines long! 
Although it did not have the codes for debugging purposes, it covered 
all error messages expected. It was such a shocker that everyone quieted 
down to focus on the subject for the rest of the semester. During my 
first employment, we had the need to optimize circuit designs. Since I 
was the only staff who knew about it, I ended up being the coordinator 
between several hardware designers and the supporting programmer. From 
that teaching, I am always looking for the most concise solution to an 
issue, not being distracted or discouraged by the manifestation on the 
surface.


https://en.wikipedia.org/wiki/APL_(programming_language)

3) Fast forward half a century, I am hoping that my "one-line code" 
serves the purpose of "there exists" an example in proofing a 
mathematical theorem for  inspiring software colleagues to review the 
network codes in front of them for improvement, instead of presenting 
such as a valid hurdle to progress.



Regards,


Abe (2022-11-24 03:53 EST)





On 2022-11-21 19:30, Joe Maimon wrote:



David Conrad wrote:

Barry,

On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote:
We've been trying to get people to adopt IPv6 widely for 30 years 
with very limited success


According to https://www.google.com/intl/en/ipv6/statistics.html, it 
looks like we’ve gone from ~0% to ~40% in 12 years. 
https://stats.labs.apnic.net/ipv6 has it around 30%. Given an 
Internet population of about 5B, this can (simplistically and 

Re: Alternative Re: ipv4/25s and above

[Matthew Petach]

On Tue, Nov 22, 2022 at 8:26 PM Abraham Y. Chen  wrote:

> Dear Tom: *
>
[...]

>
> 2)   "...Your proposal appears to rely on a specific value in the IP
> option header to create your overlay": Not really, as soon as the
> 100.64/10 netblock is replaced by the 240/4, each CG-NAT module can
> serve a very large area (such as Tokyo Metro and such) that becomes the
> RAN in EzIP terminology. Since each RAN is tethered from the existing
> Internet core by an umbilical cord operating on one IPv4 public address,
> this is like a kite floating in the sky which is the basic building
> block for the overlaying EzIP Sub-Internet when they expand wide enough
> to begin covering significant areas of the world. Note that throughout
> this entire process, the Option Word mechanism in the IP header does not
> need be used at all. (It turns out that utilizing the CG-NAT
> configuration as the EzIP deployment vehicle, the only time that the
> Option Word may be used is when subscribers in two separate RANs wishing
> to have end-to-end communication, such as direct private eMail exchanges.)
>


Hi Abraham,

I notice you never replied to my earlier questions about EzIP deployment.
I'll assume for the moment that means my concerns were without merit, and
will leave them aside.

But in reading this new message, I find myself again rather confused.

You stated:
"Since each RAN is tethered from the existing Internet core by an umbilical
cord operating on one IPv4 public address,"

I find myself staring at that statement, and puzzling over and over again
at how multi-homing would work in the EzIP world.

Would a given ISP anycast their single global public IPv4 address
to all their upstream providers from all of their edge routers,
and simply trust stable routing in the DFZ to ensure packets arrived
at the correct ingress location to be mapped from the public internet
into the RAN?

Or do you really mean that every RAN will have one giant single point
of failure, a single uplink through which all traffic must pass in order to
reach the DFZ public internet?

If your regional network is a housing subdivision, I can understand the
model of a single uplink connection for it; but for anything much larger,
a single uplink seems like an unsustainable model.  You mention Tokyo Metro
in your message as an example.  What size single uplink do. you think would
be sufficient to support all the users in the Tokyo Metro region?  And how
unhappy would they be if the single router their 1 public IP address lived
on happened to have a hardware failure?

Wouldn't it be better if the proposed model built in support for
multihoming from day one, to provide a similar level of redundancy
to what is currently available on the Internet today?

Or is EzIP designed solely for small, singled-homed residential
customers, and is not intended at all for enterprise customers
who desire a more resilient level of connectivity?

As I noted in my previous message, this seems like an awful lot of
work to go through for relatively little benefit--but this may simply be
due to a lack of essential clue on my part.  I would very much like to
be enlightened.

Thank you!

Matt

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

[Abraham Y. Chen]

Dear Eric:

0) Your analysis may have started from an assumption that is different 
from that of the EzIP. That is,


1)  The EzIP proposes to use the 240/4 as a replacement of the 100.64/10 
of RFC6598 for enhancing the CG-NAT. Thus, 240/4 will be used as 
reusable netblocks like those in RFC1918. There will be nothing for 
corporate to grab.


2)  In addition, it is implicitly stated that the addresses in 240/4 
will be assigned within a geographical Region, much like telephone 
numbers that are administrated by governments of respective 
jurisdictions as natural resources, not by global businesses as private 
properties.


3)  This may sound like against the "Internet way", but likely can 
eliminate the negative consequences of the current IP address allocation 
/ assignment practices.


Regards,


Abe (2022-11-23 15:25 EST)



On 2022-11-21 19:43, 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.








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




--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Fwd: Alternative Re: ipv4/25s and above Re: 202211220729.AYC

[Abraham Y. Chen]

Dear Tom:  Please disregard an earlier partial transmission of this 
MSG, caused by operator error. ***


1) One look at the NANOG archive that you retrieved tells me that we are 
the victims of the idiosyncrasies of the eMail system. Unlike snail 
mails that are slow but reliable (There was a story that USPS found a 
forty years old letter stuck in one of the mail collection boxes on 
Boston sidewalk and then delivered it.), eMails are fast (Once my eMail 
monitoring account started to receive a long message that I was sending 
out, even before it was fully sent.) but unpredictable from time to 
time. Unfortunately, most of us are conditioned with its daily behavior 
and do not suspect the electronic system hiccups (As Andrew Grove once 
said, "It is the software, not the hardware."). To deal with this kind 
of issues in none-real-time communications, I practice a discipline, 
started from VM and FAX, that I will do my best to respond within 24 
hours. I encourage my colleagues to start reminding me (either repeat 
the MSG or using alternative channels, such as SkyPe - My handle is 
"Abraham.Y.Chen"), if they do not hear from me after 48 hours on topics 
that they expect my response. This convention prevented much of the 
disruptions. Looking at your comments, I definitely would have responded 
back then if I saw them. One possibility is that I was in the midst of 
being overwhelmed by NANOG posting protocols, such as the digest mode, 
uni-code, personal writing styles, etc. and miseed your MSG. Anyway, 
allow me to try carrying on.


2)   "...Your proposal appears to rely on a specific value in the IP 
option header to create your overlay": Not really, as soon as the 
100.64/10 netblock is replaced by the 240/4, each CG-NAT module can 
serve a very large area (such as Tokyo Metro and such) that becomes the 
RAN in EzIP terminology. Since each RAN is tethered from the existing 
Internet core by an umbilical cord operating on one IPv4 public address, 
this is like a kite floating in the sky which is the basic building 
block for the overlaying EzIP Sub-Internet when they expand wide enough 
to begin covering significant areas of the world. Note that throughout 
this entire process, the Option Word mechanism in the IP header does not 
need be used at all. (It turns out that utilizing the CG-NAT 
configuration as the EzIP deployment vehicle, the only time that the 
Option Word may be used is when subscribers in two separate RANs wishing 
to have end-to-end communication, such as direct private eMail exchanges.)


3) " ... to drop any packet with an IP option set that you don't 
explicitly want because a significant number of routers kick every 
packet with options to CPU, ... ": Yes, this was what we were reminded 
of when we started our study. However, this appears to be another 
Internet myth. Dr. Chimiak of the EnIP project (see EzIP Draft's 
Refernce 13) told me that his team had successfully sent packets with 
Option Words. Again, even if the existing routers do knock out packs 
with Option words, the overlay architecture of the RANs allows the 
search for those do allow this operation. Since the use of the Option 
Word turns out to be an option to superceed IPv4's capabilities, we 
should treat it as a consideration for future premium services.


4) " ...Any device that still treated 240/4 differently would need to be 
updated to treat it like anything else. .. ": Yes, this applies to 
regions that desire to enjoy the EzIP characteristics. Since the root of 
each RAN (or sub-RAN) still appears to be one of the current CG-NAT 
modules, there is no change can be detected by other CG-NAT modules. 
This avoids interoperability issues during the incremental deployment.


5) "  ...Any existing filters that dropped packets with *any* IP option 
set would have to be modified to permit the ones you define for 
EzIP":  Since EzIP is not going to activate Option Words initially 
for enhancing the CG-NAT, this should not be a concern. In the future, 
inter-RAN communication by subscribers would use Option words. But, by 
that time, finite number of backbone / gateway routers among RANs 
capable of preserving Option Words would have been identified. This 
approach takes advantage of the hierarchical network configuration that 
CG-NAT has already been practicing implicitly.


6) "... ( At one point in the past, one big router vendor only allowed 
you to configure an ip-options filter based on the IANA defined values, 
not others. ) ...": Well, you are talking about the overly intertwined 
relationship between one big roouter vendor and the IANA which is 
sponsored by the former. So, this is not a technical but a "busniess" 
issue. We have talked with "white box" vendors. One assured us that EzIP 
can be quickly activated in thier programs if customers do ask for it.


7) "... This is a LOT of work and time for an overlay. ...":  You are 
probably visualizing a complete overlay network right from the 

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

[Abraham Y. Chen]

Dear Tom:

1)  One look at the NANOG archive that you retrieved tells me that we 
are the victims of the idiosyncrasies of the eMail system. Unlike the 
snail mails are slow but reliable (There was a story that USPS found a 
forty years old letter stuck in one of the mail collection boxes on 
Boston sidewalk and then delivered it.), eMails are fast (Once my eMail 
monitoring account started to receive a long message that I was sending 
out, even before it was fully sent.) but unpredictable from time to 
time. Unfortunately, most of us are conditioned with the normal speed 
and do not suspect the electronic system hiccups (As Andrew Grove once 
said, "It is the software, not the hardware.). To deal with this kind of 
issues in none-real time communication, I practice a discipline started 
from VM and FAX that I will respond within 24 hours. I encourage 
colleagues to start reminding me (either repeat the MSG or using 
alternative channels, such as SkyPe - My handle is A"Abraham.Y.Chen"), 
if they do not hear from me on topics expecting responses after 48 
hours. This convention prevented much of the disruptions. Looking at 
your comments, I definitely would have responded back then if I saw it. 
One possibility is that I was in the middle of trying to get used to 
NANOG posting protocols. I was probably overwhelmed by the digest mode, 
uni-code,etc. issues. Anyway, allow me to try carry on.


2) "...Your proposal appears to rely on a specific value in the IP 
option header to create your overlay": Not really, as soon as the 
100.64/10 netblock is replaced by the 240/4, each CG-NAT module can 
serve a very large area (such as Tokyo Metro and such) that becomes the 
RAN in EzIP terminology. Each RAN is tethered from the existing Internet 
core by an umbilical core based on one IPv4 public address. This is like 
a kite floating in the sky which is basic building block of the 
overlaying Sub-Internet when they expand to cover the entire world. 
Throughout this entire process, the Option Word mechanism in the IP head 
doe not need be used at all. (It turns out that utilizing the CG-NAT 
configuration as the starting point, the only time that the Option Word 
may be used is when subscribers in two separate RANs wishing to have 
end-to-end communication, such as direct private eMail exchanges.





On 2022-11-21 18:46, Tom Beecher wrote:


1) As requested, please be specific and speak only for yourself. So
that we can carry on a professional dialog meaningfully.


I will start by citing one of my own responses to you :

https://mailman.nanog.org/pipermail/nanog/2022-March/218291.html

I do not leave a loose end to any  technical
discussion with substance.


With the utmost amount of respect, you do.

Many people on this list have provided specific , technical issues 
with your proposal. Others have commented on non-technical, but 
practical considerations. In all cases, you have simply handwaved them 
away or not commented on them further.




On Mon, Nov 21, 2022 at 5:16 PM Abraham Y. Chen  wrote:

Dear Tom:

1)  As requested, please be specific and speak only for yourself. So
that we can carry on a professional dialog meaningfully.

2) Hint: I signed up to NANOG.org only early this year. So,
whatever you
have in mind might be from somewhere else. In addition, even
though I do
not have good memory, I do not leave a loose end to any technical
discussion with substance. The revisions of the EzIP documentation
have
always been improving the presentation style for easing the reader's
efforts, not about modifying our basic scheme. So, you need to be
clear
about the topics that you are referring to. Thanks.

Regards,


Abe (2022-11-21 17:16 EST)



On 2022-11-21 13:23, Tom Beecher wrote:
>
>     1) "... for various technical reasons , ...":  Please give a
couple
>     examples, and be specific preferably using expressions that
colleagues
>     on this forum can understand.
>
>
> Myself and multiple others provided specific technical rebuttals to
> the proposal in the past on this list.
>
>
>
> On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen

> wrote:
>
>     Dear Tom:
>
>     1) "... for various technical reasons , ...":  Please give a
couple
>     examples, and be specific preferably using expressions that
>     colleagues
>     on this forum can understand.
>
>     Thanks,
>
>
>     Abe (2022-11-21 12:29 EST)
>
>
>
>
>     On 2022-11-21 10:44, Tom Beecher wrote:
>     >
>     >     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:
>     >
>     >
>

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

[John Curran]

> On Nov 22, 2022, at 2:13 PM, Tom Beecher  wrote:
> 
>> Serious consideration requires a serious proposal - I don’t think we’ve seen 
>> one yet.
> 
> I would posit that draft-schoen-intarea-unicast-240-03 ( 
> https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ ) should 
> be considered a serious proposal, in so much as what is proposing is the most 
> direct:
> 
> - Redesignate 240/4 from RESERVED - Future Use to be available for allocation 
> as 'standard' IPv4 addresses. 
> 
> I personally disagree with their position, as does the IETF, so it doesn't 
> appear there will be any more movement on it, but I do believe that the idea 
> itself was serious.

Tom - 

Well, at least it is a readable and clear proposal, but again it lacks any 
meaningful treatment of interoperability – instead comparing the de-reservation 
and potential for future use of 240/4 with the various de-bogon efforts that 
were predominantly efforts to get long-time _already valid_ address space to be 
properly treated in the Internet –  

   Such a host might be inaccessible by some devices either on its local
   network segment or elsewhere on the Internet, due to a combination of
   host software limitations or reachability limitations in the network.
   IPv4 unicast interoperability with 240/4 can be expected to improve
   over time following the publication of this document.  Before or
   after allocations are eventually made within this range,
   "debogonization" efforts for allocated ranges can improve
   reachability to the whole address block.  Similar efforts have
   already been done by Cloudflare on 1.1.1.1 [Cloudflare], and by RIPE
   Labs on 1/8 [RIPElabs18], 2a10::/12 [RIPElabs2a1012], and 128.0/16
   [RIPElabs128016].  The Internet community can use network probing
   with any of several measurement-oriented platforms to investigate how
   usable these addresses are at any particular point in time, as well
   as to localize medium-to-large-scale routing problems.  (Examples are
   described in [Huston], [NLNOGRing], and [Atlas].)  Any network
   operator to whom such addresses are made available by a future
   allocation will have to examine the situation in detail to determine
   how well its interoperability requirements will be met.

I.w.  the suggestion that the utilization of 240/4 space will solely be an 
issue for the "operator to whom such addresses are made available “ to examine 
(with respect to their requirements) really completely ignores the fact that 
such address space utilized in the production Internet will experience 
unpredictable intermittent communication failures for years (if not decades) to 
come, and hence it an issue of concern for the entire operations community, not 
just those who may receive such allocations.   Again, the IETF's host and 
router requirements documents has specified discard of these packets since the 
90’s, so there needs to be a clear model for transition (rather than vague 
statements left to the reader)l that covers how network operators at both ends 
will know of the failure (and workarounds) when the use of these addresses 
results in failed communication.  Absent such, I’m not sure why anyone should 
give consideration to this Internet draft– it can’t be safely deployed in the 
actual real-world Internet, making it more of a paper chimera than a serious 
proposal. 

Thanks,
/John

p.s.  Disclaimer(s):  my views alone - any hazards seen in them may be much 
closer than they appear…

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

[Tom Beecher]

>
> Serious consideration requires a serious proposal - I don’t think we’ve
> seen one yet.
>

I would posit that draft-schoen-intarea-unicast-240-03 (
https://datatracker.ietf.org/doc/draft-schoen-intarea-unicast-240/ ) should
be considered a serious proposal, in so much as what is proposing is the
most direct:

- Redesignate 240/4 from RESERVED - Future Use to be available for
allocation as 'standard' IPv4 addresses.

I personally disagree with their position, as does the IETF, so it doesn't
appear there will be any more movement on it, but I do believe that the
idea itself was serious.

Of course, I also agree with you that there have been plenty of un-serious
proposals floated too which don't really require discussion. :)

On Tue, Nov 22, 2022 at 1:48 PM John Curran  wrote:

>
>
> On Nov 22, 2022, at 1:19 PM, Joe Maimon  wrote:
>
> John Curran wrote:
>
>
> By the way, you shouldn’t feel particularly bad about skipping out on the
> interoperability requirement – anything involving interworking with the
> installed Internet is hard, and this is the same lesson that the IPv6 folks
> found out the hard way…   I will confess that I was a member of the IETF's
> IPng Directorate and thus inherently complicit in that particular fiasco –
>
>
> John,
>
> Flags days on the internet of today have proven to be of limited value.
>
>
> Joe -
>
> I am not suggesting a flag day for 240/4 (or any other particular
> approach) - merely noting that anyone who wishes to promote 240/4 has a
> wide range of options to consider when they decide to get serious and
> actually consider interoperability approaches.
>
> The part I feel bad about is that I am actually un-involved in much of
> anyway with the 240/4 or other ideas, my sole input has been to attempt to
> encourage serious consideration and to rebut  naysaying.
>
>
> Serious consideration requires a serious proposal - I don’t think we’ve
> seen one yet.
>
> Yes, a standards update is only the beginning of a real effort, although
> plenty has changed even without that.
>
> Yes, there may and likely will be a large extent of interoperability and
> usability challenges for quite some time, perhaps even enough time that the
> issue becomes moot.
>
> Yes, it may be insurmountable.
>
> Yes, it may render 240/4 unusable and undesirable to the extent that it
> has little contributory effect on IPv4.
>
> However it may not and discouraging serious consideration is actually a
> contributing factor preventing any such potential.
>
>
> I certainly am not discouraging serious consideration… simply awaiting
> something sufficient complete to discuss.
>
> (Saying that “this proposal likely will create interoperability and
> usability challenges – but let’s all talk about the merits of it while
> ignoring that detail for now” doesn’t cut it – I’ve seen that approach once
> before and hasn’t turned out particularly well for anyone involved…)
>
> Best wishes,
> /John
>
> p.s. Disclaimer(s) - my views alone - please remember to have your arms
> and legs fully inside before the ride starts...
>
>
>

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

[John Curran]

> On Nov 22, 2022, at 1:19 PM, Joe Maimon  wrote:
> 
> John Curran wrote:
>> 
>> By the way, you shouldn’t feel particularly bad about skipping out on the 
>> interoperability requirement – anything involving interworking with the 
>> installed Internet is hard, and this is the same lesson that the IPv6 folks 
>> found out the hard way…   I will confess that I was a member of the IETF's 
>> IPng Directorate and thus inherently complicit in that particular fiasco –
> 
> John,
> 
> Flags days on the internet of today have proven to be of limited value.

Joe - 

I am not suggesting a flag day for 240/4 (or any other particular approach) - 
merely noting that anyone who wishes to promote 240/4 has a wide range of 
options to consider when they decide to get serious and actually consider 
interoperability approaches. 

> The part I feel bad about is that I am actually un-involved in much of anyway 
> with the 240/4 or other ideas, my sole input has been to attempt to encourage 
> serious consideration and to rebut  naysaying.

Serious consideration requires a serious proposal - I don’t think we’ve seen 
one yet.

> Yes, a standards update is only the beginning of a real effort, although 
> plenty has changed even without that.
> 
> Yes, there may and likely will be a large extent of interoperability and 
> usability challenges for quite some time, perhaps even enough time that the 
> issue becomes moot.
> 
> Yes, it may be insurmountable.
> 
> Yes, it may render 240/4 unusable and undesirable to the extent that it has 
> little contributory effect on IPv4.
> 
> However it may not and discouraging serious consideration is actually a 
> contributing factor preventing any such potential.

I certainly am not discouraging serious consideration… simply awaiting 
something sufficient complete to discuss. 

(Saying that “this proposal likely will create interoperability and usability 
challenges – but let’s all talk about the merits of it while ignoring that 
detail for now” doesn’t cut it – I’ve seen that approach once before and hasn’t 
turned out particularly well for anyone involved…) 

Best wishes,
/John

p.s. Disclaimer(s) - my views alone - please remember to have your arms and 
legs fully inside before the ride starts...

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

[Joe Maimon]

John Curran wrote:



On Nov 22, 2022, at 9:09 AM, John Curran  wrote:
...
Interoperability isn’t insurmountable, but does take some investment 
of effort.  One can imagine any number of techniques (e.g.  flag day 
after which “production devices” on the Internet must support 240/4, 
or DNS resolver hacks that fail to return “A” records with 240/4 
addresses unless a flag is set that says “we’re in the 240/4 routable 
Internet” [ick], etc., etc.)  It doesn’t seem particularly hard to 
come up with some approaches to solve the interoperability problem, 
but completely ignoring it is not an answer (and makes it rather 
difficult to take your proposal seriously…)


Joe -

By the way, you shouldn’t feel particularly bad about skipping out on 
the interoperability requirement – anything involving interworking 
with the installed Internet is hard, and this is the same lesson that 
the IPv6 folks found out the hard way…   I will confess that I was a 
member of the IETF's IPng Directorate and thus inherently complicit in 
that particular fiasco –


John,

Flags days on the internet of today have proven to be of limited value.

Suppose complete interoperability is never actually solved. Why does 
240/4 utilitarian value have to be binary? I think we should be trying 
to discover these things instead of using them to handwave away any attempt.


The part I feel bad about is that I am actually un-involved in much of 
anyway with the 240/4 or other ideas, my sole input has been to attempt 
to encourage serious consideration and to rebut  naysaying.


Yes, a standards update is only the beginning of a real effort, although 
plenty has changed even without that.


Yes, there may and likely will be a large extent of interoperability and 
usability challenges for quite some time, perhaps even enough time that 
the issue becomes moot.


Yes, it may be insurmountable.

Yes, it may render 240/4 unusable and undesirable to the extent that it 
has little contributory effect on IPv4.


However it may not and discouraging serious consideration is actually a 
contributing factor preventing any such potential.


And to the extent that you and others have discussed and aired various 
points of views and insights, I think I have had some success with my 
efforts thus far.





With IPv6, the first answer to interoperability was “let’s do tunnels 
between IPng islands”; i.e. helpful for lab environments but useless 
otherwise.  We then declared that transition was a problem “to be 
solved later” but that shouldn’t get in the way of the declaration of 
IPng as the new IPv6.  Finally, after failing to solve the problem, we 
reverted to “ships in the night”; i.e. IPv4 and IPv6 running in 
parallel on the same infrastructure – it works, but defeats the entire 
idea of IPv6 as a functional substitute for IPv4 for connecting new 
customers and infrastructure to the existing IPv4-based Internet 
(Luckily, the service provider industry that was growing most rapidly 
realized that they really needed IPv6, and they really needed 
transition solutions that allowed IPv6 to interoperate for IPv4 for 
new connections, and so we eventually saw real solutions such 
as 464xlat, ds-lite, etc.)


I feel there is some value for the internet record to contain as much as 
possible real debate and consideration instead of group think, 
short-sightedness, idealouges and top down approaches which may not look 
pretty in hindsight. Such as contained in the much larger details of 
your brief recap and that you and others have expanded upon here and 
elsewhere in the past.


In other words, a loyal opposition.



Maintaining interoperability with the existing base is hard - far 
harder than just “updating the standard” -
Without a standard update, there is a bit of a chicken and egg problem 
with pursuing interoperability with any seriousness.


I think 100.64/10 was a missed opportunity to incentivize the industry 
to pursue interoperability.


but is absolutely essential if you want viable reuse of 240/4.  Of 
course, it does raise the question of whether the total effort will be 
worth the purported gain, but that really can’t be assessed until 
there's some specification of the proposed solution for 
interoperability with the existing deployed devices that don’t know 
about the 240/4 change.


Thanks,
/John

p.s.  Disclaimer(s): my views alone. Warning: may cause dizziness, 
headaches, or nausea.



Best,

Joe

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

[John Curran]

> On Nov 22, 2022, at 9:09 AM, John Curran  wrote:
> ...
> Interoperability isn’t insurmountable, but does take some investment of 
> effort.  One can imagine any number of techniques (e.g.  flag day after which 
> “production devices” on the Internet must support 240/4, or DNS resolver 
> hacks that fail to return “A” records with 240/4 addresses unless a flag is 
> set that says “we’re in the 240/4 routable Internet” [ick], etc., etc.)  It 
> doesn’t seem particularly hard to come up with some approaches to solve the 
> interoperability problem, but completely ignoring it is not an answer (and 
> makes it rather difficult to take your proposal seriously…) 

Joe - 

By the way, you shouldn’t feel particularly bad about skipping out on the 
interoperability requirement – anything involving interworking with the 
installed Internet is hard, and this is the same lesson that the IPv6 folks 
found out the hard way…   I will confess that I was a member of the IETF's IPng 
Directorate and thus inherently complicit in that particular fiasco –   

With IPv6, the first answer to interoperability was “let’s do tunnels between 
IPng islands”; i.e. helpful for lab environments but useless otherwise.  We 
then declared that transition was a problem “to be solved later” but that 
shouldn’t get in the way of the declaration of IPng as the new IPv6.  Finally, 
after failing to solve the problem, we reverted to “ships in the night”; i.e. 
IPv4 and IPv6 running in parallel on the same infrastructure – it works, but 
defeats the entire idea of IPv6 as a functional substitute for IPv4 for 
connecting new customers and infrastructure to the existing IPv4-based Internet 
(Luckily, the service provider industry that was growing most rapidly realized 
that they really needed IPv6, and they really needed transition solutions that 
allowed IPv6 to interoperate for IPv4 for new connections, and so we eventually 
saw real solutions such as 464xlat, ds-lite, etc.) 

Maintaining interoperability with the existing base is hard - far harder than 
just “updating the standard” - but is absolutely essential if you want viable 
reuse of 240/4.  Of course, it does raise the question of whether the total 
effort will be worth the purported gain, but that really can’t be assessed 
until there's some specification of the proposed solution for interoperability 
with the existing deployed devices that don’t know about the 240/4 change. 

Thanks,
/John

p.s.  Disclaimer(s): my views alone. Warning: may cause dizziness, headaches, 
or nausea.

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

[John Curran]

> On Nov 22, 2022, at 2:09 AM, Joe Maimon  wrote:
> 
> David Conrad wrote:
>> 
>> Again, the issue isn’t fixing a bit of code in a known source tree. It is 
>> getting all the instantiations of that bit of code implemented, tested, and 
>> deployed across all the myriad supported and unsupported systems (both 
>> operational and management) that support 5 billion+ Internet users globally 
>> in a timeframe and for a cost that makes business sense.
> 
> Lets agree to stop conflating the issue of products under active support and 
> refresh cycles with the issue of those that are obsolete and only subject to 
> attrition.

Joe - 

  Ah, if it were only that simple…   service providers have a _huge_ 
amount of installed infrastructure, and it’s in various phases of support (i.e. 
can get new updates, or critical fixes only, or is self-maintained, etc.) 

Vendors supporting 240/4 as general purpose space does not automatically equate 
to Internet infrastructure supporting 240/2, as it requires service providers 
to make conscious decisions to do maintenance on gear that may (in many cases) 
have been effectively frozen in terms of software updates that aren’t critical… 
customer installs and capacity upgrades almost always get first cut at 
resources, and so no, it is not just a case of updating the standards - even 
presuming that the provider has the equipment under software updates, 
availability of such doesn’t mean it will be installed.   You are talking about 
a long period between standards update and actual deployment, and that’s 
presuming actively supported gear. 

> The former, yes it is trivial. An update in standards could yield rapid 
> results here.

Absolutely – but only if you are talking about an equally trivial network 
infrastructure or pure lab environment – otherwise, the standards change is the 
very _beginning_ of a lengthy process for network operators of any size. 

You once again have avoided the question of interoperability during the 
transition period.

Interoperability isn’t insurmountable, but does take some investment of effort. 
 One can imagine any number of techniques (e.g.  flag day after which 
“production devices” on the Internet must support 240/4, or DNS resolver hacks 
that fail to return “A” records with 240/4 addresses unless a flag is set that 
says “we’re in the 240/4 routable Internet” [ick], etc., etc.)  It doesn’t seem 
particularly hard to come up with some approaches to solve the interoperability 
problem, but completely ignoring it is not an answer (and makes it rather 
difficult to take your proposal seriously...) 

Thanks,
/John

p.s.  disclaimer: my views alone (little chance any one else would risk blame 
for them!) 
 

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

[Joe Maimon]

Jay Hennigan wrote:

On 11/21/22 16:30, Joe Maimon wrote:





IMNSHO, if such a proposal were to gain traction, by the time that 
gear capable of using 240/4 as unicast were to be widely deployed, 
IPv6-capable gear would be much more widely deployed.


Considering that is already the situation, whats your point?



META: Can whoever is doing so please stop creating new time-stamped 
subject lines for the same topic? It makes things hard to follow.

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

[Joe Maimon]

David Conrad wrote:
How trivial would the change be in a product by a company that no 
longer exists or a product line that is no longer supported? Will 
Microsoft update all previous versions of Windows? Will the myriad of 
deployed embedded systems sitting forgotten in closets be updated? And 
if you’re going to the trouble to update those systems (in most cases, 
by simply throwing them away), why not upgrade to IPv6+IPv4aaS?

Especially as we have examples of what that type of effort might look like.

Again, the issue isn’t fixing a bit of code in a known source tree. It is 
getting all the instantiations of that bit of code implemented, tested, and 
deployed across all the myriad supported and unsupported systems (both 
operational and management) that support 5 billion+ Internet users globally in 
a timeframe and for a cost that makes business sense.

Regards,
-drc



Lets agree to stop conflating the issue of products under active support 
and refresh cycles with the issue of those that are obsolete and only 
subject to attrition.


Two different problems areas entirely.

The former, yes it is trivial. An update in standards could yield rapid 
results here.


The latter takes time. An update in standards could take years to bear 
enough fruit. All the more reason it should have happened then, all the 
more reason to let it happen now.


Joe

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: 202211201009.AYC

[Joe Maimon]

David Conrad wrote:

Barry,

On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote:
We've been trying to get people to adopt IPv6 widely for 30 years 
with very limited success


According to https://www.google.com/intl/en/ipv6/statistics.html, it 
looks like we’ve gone from ~0% to ~40% in 12 years. 
https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet 
population of about 5B, this can (simplistically and wrongly) argued 
to mean 1.5-2B people are using IPv6. For a transition to a technology 
that the vast majority of people who pay the bills will neither notice 
nor care about, and for which the business case typically needs 
projection way past the normal quarterly focus of shareholders, that 
seems pretty successful to me.


But back to the latest proposal to rearrange deck chairs on the IPv4 
Titanic, the fundamental and obvious flaw is the assertion of 
"commenting out one line code”. There isn’t “one line of code”. There 
are literally _billions_ of instances of “one line of code”, the vast 
majority of which need to be changed/deployed/tested with absolutely 
no business case to do so that isn’t better met with deploying 
IPv6+IPv4aaS. I believe this has been pointed out numerous times, but 
it falls on deaf ears, so the discussion gets a bit tedious.


Regards,
-drc

Re-replying. Changing the standards is not what is intended to drive 
vendor changes. Userbase requests and projected needs do that.


The standards are not responsible for the business case. However, they 
should not unreasonably impede it.


Joe

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: 202211201009.AYC

[Owen DeLong via NANOG]

Much of India operates this way today.

Owen


> On Nov 21, 2022, at 15:06, Rubens Kuhl  wrote:
> 
> (forwarded to break thread since this is a different topic)
> What's the group's current thought on emergence or prevalence of
> IPv6-only hosts ? Will they exist soon, in some time or in a very long
> time?
> 
> 
> Rubens
> 
> 
> -- Forwarded message -
> From: 
> Date: Mon, Nov 21, 2022 at 8:02 PM
> Subject: Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC
> To: NANOG 
> 
> 
> 
> My suggestion is ignore anyone who says it would be too difficult to
> get people to adopt a change or take too long. Someone always says
> that, a reasonable riposte is "what would be a reasonable number of
> people / years?" Surely they must have some numbers in mind, no?
> 
> We've been trying to get people to adopt IPv6 widely for 30 years with
> very limited success so perhaps that's a pretty time to shoot for, for
> example. Anything less than 30 years would be an improvement.
> 
> I suppose some might leap on that as evidence of the above cautions
> but it's really not. It's just being argumentative. It feels like a
> reasonable argument pattern but it's not because it ignores why that
> previous attempt mostly failed and tries to equate them (we failed for
> 30 years so therefore you will fail for 30 years???)
> 
> That said, what's needed is a working demo preferably within both a
> simulation environment and live because the devil is always in the
> details and the only way to vet that is by testing working code.
> 
> A mere proposal is of some value, one can glance at it and try to spot
> any fatal flaws for example. But it's only a tiny step along the path.
> 
> However, that it might take a while to become adopted is, to me, like
> saying forget trying to mitigate climate change, it'll take decades
> and require hundreds of govts, thousands of industries, and billions
> of people to change their behavior which is all true but hardly an
> argument as to why not to try.
> 
> Aside: A pretty good rule of thumb with replacement technologies is
> that something has to be 10x better than what it replaces to get wide
> adoption. Ok maybe not 10, that's a figure of speech, but a lot, and
> certainly not introduce impediments to its own adoption and use.
> 
> On November 21, 2022 at 12:00 beec...@beecher.cc (Tom Beecher) wrote:
>>As stated in Subsection 4.A. of the "Revamp The
>>Internet" whitepaper, all need be done is "Simply disable the existing
>>software codes that have been disabling the use of the 240/4 netblock."
>> 
>> 
>> Some friendly feedback. The phrase "all that needs to be done" , is
>> exceptionally reductive, and in the case of internet standards, also always
>> going to end up being wrong.
>> 
>> On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen  wrote:
>> 
>>Dear Mark:
>> 
>>0) Thanks for the clarification. I understand. A short message through
>>the cyberspace, especially between parties who have never met can be
>>easily skewed. I am glad that I asked you, instead of taking it
>>negatively without raising my hand.
>> 
>>1) "...I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c. ...
>>": Since EzIP is still being further refined, it may not be clear in our
>>documentation about how much work is required to get the IPv4 out of the
>>current depletion mode. As stated in Subsection 4.A. of the "Revamp The
>>Internet" whitepaper, all need be done is "Simply disable the existing
>>software codes that have been disabling the use of the 240/4 netblock."
>>In fact, we have found examples that this means commenting out one line
>>code that searches for then discards packets with 240/4 addressing. It
>>seems to me that there is no easier task than this.
>> 
>>https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>> 
>>Regards,
>> 
>>Abe (2022-11-21 11:18 EST)
>> 
>> 
>> 
>>On 2022-11-20 23:56, Mark Tinka wrote:
>>> 
>>> 
>>> On 11/20/22 19:02, Abraham Y. Chen wrote:
>>> 
>>>> Dear Mark:
>>>> 
>>>> 0)  I am surprised at your apparently sarcastic opinion.
>>>> 
>>>> 1)  The EzIP proposal as referenced by my last MSG is the result of
>>>> an in-depth system engineering effort. Since the resultant schemes do
>>>> not rely on any protocol development, IETF does not need be involved.
>>>> Especially, its first step of disabli

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: 202211201009.AYC

[David Conrad]

Joe,

On Nov 21, 2022, at 4:30 PM, Joe Maimon  wrote:
> As I and others have pointed out, it depends on how it is used.

Sure, and with enough thrust and an appropriate trajectory, pigs fly quite 
well, although the landing can get messy.  With enough constraints, any problem 
becomes trivially solvable. Whether it is a useful problem to solve is the 
question.

> And perhaps the attempt should be made regardless of knowing in advance which 
> it will be.

You’ll get no argument from me. In the past, I’ve suggested a Cloudflare 
1.1.1.1-like experiment would provide useful data.

> You can hardly attempt to convince anybody that 240/4 as unicast would not be 
> the more trivial change made in any of these products natural life cycle 
> points.


How trivial would the change be in a product by a company that no longer exists 
or a product line that is no longer supported? Will Microsoft update all 
previous versions of Windows?  Will the myriad of deployed embedded systems 
sitting forgotten in closets be updated? And if you’re going to the trouble to 
update those systems (in most cases, by simply throwing them away), why not 
upgrade to IPv6+IPv4aaS?

> Especially as we have examples of what that type of effort might look like.

Again, the issue isn’t fixing a bit of code in a known source tree. It is 
getting all the instantiations of that bit of code implemented, tested, and 
deployed across all the myriad supported and unsupported systems (both 
operational and management) that support 5 billion+ Internet users globally in 
a timeframe and for a cost that makes business sense.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Alternative Re: ipv4/25s and above

[Jay Hennigan]

On 11/21/22 16:30, Joe Maimon wrote:

You can hardly attempt to convince anybody that 240/4 as unicast would 
not be the more trivial change made in any of these products natural 
life cycle points.


One can and indeed some do attempt to do just that. The likelihood of 
these attempts actually convincing those in a position to influence 
change is what is in question.


IMNSHO, if such a proposal were to gain traction, by the time that gear 
capable of using 240/4 as unicast were to be widely deployed, 
IPv6-capable gear would be much more widely deployed.


META: Can whoever is doing so please stop creating new time-stamped 
subject lines for the same topic? It makes things hard to follow.


--
Jay Hennigan - j...@west.net
Network Engineering - CCIE #7880
503 897-8550 - WB6RDV

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: 202211201009.AYC

[Joe Maimon]

David Conrad wrote:

Barry,

On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote:
We've been trying to get people to adopt IPv6 widely for 30 years 
with very limited success


According to https://www.google.com/intl/en/ipv6/statistics.html, it 
looks like we’ve gone from ~0% to ~40% in 12 years. 
https://stats.labs.apnic.net/ipv6 has it around 30%. Given an Internet 
population of about 5B, this can (simplistically and wrongly) argued 
to mean 1.5-2B people are using IPv6. For a transition to a technology 
that the vast majority of people who pay the bills will neither notice 
nor care about, and for which the business case typically needs 
projection way past the normal quarterly focus of shareholders, that 
seems pretty successful to me.


But back to the latest proposal to rearrange deck chairs on the IPv4 
Titanic, the fundamental and obvious flaw is the assertion of 
"commenting out one line code”. There isn’t “one line of code”. There 
are literally _billions_ of instances of “one line of code”, the vast 
majority of which need to be changed/deployed/tested with absolutely 
no business case to do so that isn’t better met with deploying 
IPv6+IPv4aaS. I believe this has been pointed out numerous times, but 
it falls on deaf ears, so the discussion gets a bit tedious.


Regards,
-drc

Had the titanic stayed afloat some hours more, many more would have 
survived and been rescued when assistance eventually arrived. So that 
makes this a debate over whether this is deck chair re-arrangement or 
something more meaningful.


As I and others have pointed out, it depends on how it is used. And 
perhaps the attempt should be made regardless of knowing in advance 
which it will be.


You assertion needs some back of the envelope numbers, which once 
provided, I suspect will render your estimate grossly incorrect.


You can hardly attempt to convince anybody that 240/4 as unicast would 
not be the more trivial change made in any of these products natural 
life cycle points.


Especially as we have examples of what that type of effort might look 
like. IGTFY and here


https://lore.kernel.org/lkml/20080108011057.ga21...@cisco.com/

The burdensome position is ridiculous even more so when stated with a 
straight face.


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: 202211201009.AYC

[David Conrad]

Barry,

On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote:
> We've been trying to get people to adopt IPv6 widely for 30 years with very 
> limited success

According to https://www.google.com/intl/en/ipv6/statistics.html, it looks like 
we’ve gone from ~0% to ~40% in 12 years. https://stats.labs.apnic.net/ipv6 has 
it around 30%. Given an Internet population of about 5B, this can 
(simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a 
transition to a technology that the vast majority of people who pay the bills 
will neither notice nor care about, and for which the business case typically 
needs projection way past the normal quarterly focus of shareholders, that 
seems pretty successful to me.

But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, 
the fundamental and obvious flaw is the assertion of "commenting out one line 
code”. There isn’t “one line of code”. There are literally _billions_ of 
instances of “one line of code”, the vast majority of which need to be 
changed/deployed/tested with absolutely no business case to do so that isn’t 
better met with deploying IPv6+IPv4aaS. I believe this has been pointed out 
numerous times, but it falls on deaf ears, so the discussion gets a bit tedious.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

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: 202211211223.AYC

[Tom Beecher]

>
> 1)  As requested, please be specific and speak only for yourself. So
> that we can carry on a professional dialog meaningfully.
>

I will start by citing one of my own responses to you :

https://mailman.nanog.org/pipermail/nanog/2022-March/218291.html

I do not leave a loose end to any  technical
> discussion with substance.
>

With the utmost amount of respect, you do.

Many people on this list have provided specific , technical issues with
your proposal. Others have commented on non-technical, but practical
considerations. In all cases, you have simply handwaved them away or not
commented on them further.



On Mon, Nov 21, 2022 at 5:16 PM Abraham Y. Chen  wrote:

> Dear Tom:
>
> 1)  As requested, please be specific and speak only for yourself. So
> that we can carry on a professional dialog meaningfully.
>
> 2) Hint: I signed up to NANOG.org only early this year. So, whatever you
> have in mind might be from somewhere else. In addition, even though I do
> not have good memory, I do not leave a loose end to any  technical
> discussion with substance. The revisions of the EzIP documentation have
> always been improving the presentation style for easing the reader's
> efforts, not about modifying our basic scheme. So, you need to be clear
> about the topics that you are referring to. Thanks.
>
> Regards,
>
>
> Abe (2022-11-21 17:16 EST)
>
>
>
> On 2022-11-21 13:23, Tom Beecher wrote:
> >
> > 1) "... for various technical reasons , ...":  Please give a couple
> > examples, and be specific preferably using expressions that
> colleagues
> > on this forum can understand.
> >
> >
> > Myself and multiple others provided specific technical rebuttals to
> > the proposal in the past on this list.
> >
> >
> >
> > On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen 
> > wrote:
> >
> > Dear Tom:
> >
> > 1) "... for various technical reasons , ...":  Please give a couple
> > examples, and be specific preferably using expressions that
> > colleagues
> > on this forum can understand.
> >
> > Thanks,
> >
> >
> > Abe (2022-11-21 12:29 EST)
> >
> >
> >
> >
> > On 2022-11-21 10:44, Tom Beecher wrote:
> > >
> > > 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:
> > >
> > >
> >
> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
> > >
> > >
> > > For the benefit of anyone who may not understand, this is not an
> > > 'alternative'. This is an idea that was initially proposed by the
> > > authors almost exactly 6 years ago. It's received almost no
> > interest
> > > from anyone involved in internet standards, and for
> > various technical
> > > reasons , likely never will.
> > >
> > > On Fri, Nov 18, 2022 at 10:52 PM 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:
> > >
> > >
> >
> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
> > >
> > > 2)  If this looks a bit too technical due to the nature of
> > such a
> > > document, there is a distilled version that provides a
> > bird-eye's
> > > view
> > > of the solution:
> > >
> > > https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
> > >
> > > 3)  All of the above can start from making use of the 240/4
> > > netblock as
> > > a reusable (by region / country) unicast IP address
> > resources that
> > > could
> > > be accomplished by as simple as commenting out one line of the
> > > existing
> > > network router program code. I will be glad to go into the
> > > specifics if
> > > you can bring their attention to this almost mystic topic.
> > >
> > > Regards,
> > >
> > >
> > > Abe (2022-11-19 22:50 EST)
> > >
> > >
> > > On 2022-11-18 18:20, Owen DeLong via NANOG wrote:
> > > >
> > > >> On Nov 18, 2022, at 03:44, Joe Maimon
> >  wrote:
> > > >>
> > > >>
> > > >>
> > > >> Mark Tinka wrote:
> > > >>>
> > > >>> On 11/17/22 19:55, Joe Maimon wrote:
> > > >>>
> > >  You could instead use a /31.
> > > >>> We could, but many of our DIA customers have all manner of
> > > CPE's that may or may not support this. Having unique
> > designs per
> > > customer does not scale well.
> > > >> its almost 2023. /31 support is easily mandatory. You should
> > > make it 

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

Fwd: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[Rubens Kuhl]

(forwarded to break thread since this is a different topic)
What's the group's current thought on emergence or prevalence of
IPv6-only hosts ? Will they exist soon, in some time or in a very long
time?


Rubens


-- Forwarded message -
From: 
Date: Mon, Nov 21, 2022 at 8:02 PM
Subject: Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC
To: NANOG 



My suggestion is ignore anyone who says it would be too difficult to
get people to adopt a change or take too long. Someone always says
that, a reasonable riposte is "what would be a reasonable number of
people / years?" Surely they must have some numbers in mind, no?

We've been trying to get people to adopt IPv6 widely for 30 years with
very limited success so perhaps that's a pretty time to shoot for, for
example. Anything less than 30 years would be an improvement.

I suppose some might leap on that as evidence of the above cautions
but it's really not. It's just being argumentative. It feels like a
reasonable argument pattern but it's not because it ignores why that
previous attempt mostly failed and tries to equate them (we failed for
30 years so therefore you will fail for 30 years???)

That said, what's needed is a working demo preferably within both a
simulation environment and live because the devil is always in the
details and the only way to vet that is by testing working code.

A mere proposal is of some value, one can glance at it and try to spot
any fatal flaws for example. But it's only a tiny step along the path.

However, that it might take a while to become adopted is, to me, like
saying forget trying to mitigate climate change, it'll take decades
and require hundreds of govts, thousands of industries, and billions
of people to change their behavior which is all true but hardly an
argument as to why not to try.

Aside: A pretty good rule of thumb with replacement technologies is
that something has to be 10x better than what it replaces to get wide
adoption. Ok maybe not 10, that's a figure of speech, but a lot, and
certainly not introduce impediments to its own adoption and use.

On November 21, 2022 at 12:00 beec...@beecher.cc (Tom Beecher) wrote:
 > As stated in Subsection 4.A. of the "Revamp The
 > Internet" whitepaper, all need be done is "Simply disable the existing
 > software codes that have been disabling the use of the 240/4 netblock."
 >
 >
 > Some friendly feedback. The phrase "all that needs to be done" , is
 > exceptionally reductive, and in the case of internet standards, also always
 > going to end up being wrong.
 >
 > On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen  wrote:
 >
 > Dear Mark:
 >
 > 0) Thanks for the clarification. I understand. A short message through
 > the cyberspace, especially between parties who have never met can be
 > easily skewed. I am glad that I asked you, instead of taking it
 > negatively without raising my hand.
 >
 > 1) "...I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c. ...
 > ": Since EzIP is still being further refined, it may not be clear in our
 > documentation about how much work is required to get the IPv4 out of the
 > current depletion mode. As stated in Subsection 4.A. of the "Revamp The
 > Internet" whitepaper, all need be done is "Simply disable the existing
 > software codes that have been disabling the use of the 240/4 netblock."
 > In fact, we have found examples that this means commenting out one line
 > code that searches for then discards packets with 240/4 addressing. It
 > seems to me that there is no easier task than this.
 >
 > https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
 >
 > Regards,
 >
 > Abe (2022-11-21 11:18 EST)
 >
 >
 >
 > On 2022-11-20 23:56, Mark Tinka wrote:
 > >
 > >
 > > On 11/20/22 19:02, Abraham Y. Chen wrote:
 > >
 > >> Dear Mark:
 > >>
 > >> 0)  I am surprised at your apparently sarcastic opinion.
 > >>
 > >> 1)  The EzIP proposal as referenced by my last MSG is the result of
 > >> an in-depth system engineering effort. Since the resultant schemes do
 > >> not rely on any protocol development, IETF does not need be involved.
 > >> Especially, its first step of disabling one line of existing
 > >> networking program code empowers any party to begin deploying EzIP
 > >> stealthily for mitigating the IPv4 address pool depletion issues.
 > >> Note that EzIP is a generic solution applicable to everyone, not
 > >> limited to Africa.
 > >>
 > >> 2)  Of course, constructive criticism is always appreciated. However,
 > >>

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

[bzs]

My suggestion is ignore anyone who says it would be too difficult to
get people to adopt a change or take too long. Someone always says
that, a reasonable riposte is "what would be a reasonable number of
people / years?" Surely they must have some numbers in mind, no?

We've been trying to get people to adopt IPv6 widely for 30 years with
very limited success so perhaps that's a pretty time to shoot for, for
example. Anything less than 30 years would be an improvement.

I suppose some might leap on that as evidence of the above cautions
but it's really not. It's just being argumentative. It feels like a
reasonable argument pattern but it's not because it ignores why that
previous attempt mostly failed and tries to equate them (we failed for
30 years so therefore you will fail for 30 years???)

That said, what's needed is a working demo preferably within both a
simulation environment and live because the devil is always in the
details and the only way to vet that is by testing working code.

A mere proposal is of some value, one can glance at it and try to spot
any fatal flaws for example. But it's only a tiny step along the path.

However, that it might take a while to become adopted is, to me, like
saying forget trying to mitigate climate change, it'll take decades
and require hundreds of govts, thousands of industries, and billions
of people to change their behavior which is all true but hardly an
argument as to why not to try.

Aside: A pretty good rule of thumb with replacement technologies is
that something has to be 10x better than what it replaces to get wide
adoption. Ok maybe not 10, that's a figure of speech, but a lot, and
certainly not introduce impediments to its own adoption and use.

On November 21, 2022 at 12:00 beec...@beecher.cc (Tom Beecher) wrote:
 > As stated in Subsection 4.A. of the "Revamp The
 > Internet" whitepaper, all need be done is "Simply disable the existing
 > software codes that have been disabling the use of the 240/4 netblock."
 > 
 > 
 > Some friendly feedback. The phrase "all that needs to be done" , is
 > exceptionally reductive, and in the case of internet standards, also always
 > going to end up being wrong. 
 > 
 > On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen  wrote:
 > 
 > Dear Mark:
 > 
 > 0) Thanks for the clarification. I understand. A short message through
 > the cyberspace, especially between parties who have never met can be
 > easily skewed. I am glad that I asked you, instead of taking it
 > negatively without raising my hand.
 > 
 > 1) "...I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c. ...
 > ": Since EzIP is still being further refined, it may not be clear in our
 > documentation about how much work is required to get the IPv4 out of the
 > current depletion mode. As stated in Subsection 4.A. of the "Revamp The
 > Internet" whitepaper, all need be done is "Simply disable the existing
 > software codes that have been disabling the use of the 240/4 netblock."
 > In fact, we have found examples that this means commenting out one line
 > code that searches for then discards packets with 240/4 addressing. It
 > seems to me that there is no easier task than this.
 > 
 > https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
 > 
 > Regards,
 > 
 > Abe (2022-11-21 11:18 EST)
 > 
 > 
 > 
 > On 2022-11-20 23:56, Mark Tinka wrote:
 > >
 > >
 > > On 11/20/22 19:02, Abraham Y. Chen wrote:
 > >
 > >> Dear Mark:
 > >>
 > >> 0)  I am surprised at your apparently sarcastic opinion.
 > >>
 > >> 1)  The EzIP proposal as referenced by my last MSG is the result of
 > >> an in-depth system engineering effort. Since the resultant schemes do
 > >> not rely on any protocol development, IETF does not need be involved.
 > >> Especially, its first step of disabling one line of existing
 > >> networking program code empowers any party to begin deploying EzIP
 > >> stealthily for mitigating the IPv4 address pool depletion issues.
 > >> Note that EzIP is a generic solution applicable to everyone, not
 > >> limited to Africa.
 > >>
 > >> 2)  Of course, constructive criticism is always appreciated. However,
 > >> unspecific comments that confuse and distract the readers only
 > >> provide dis-service to those disadvantaged population who are
 > >> enduring the handicaps of being the late-comers to the Internet.
 > >
 > > My comment was not directed at you. Sorry.
 > >
 > > I have nothing against the EzIP proposal. It just does not add any
 > > real value in solving the IPv4 depletion problem for the amount of
 > > effort required to implement it, in my view. I'd, rather, expend those
 > > resources on IPv6, 464XLAT, e.t.c.
 > >
 > > 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

[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: 202211211223.AYC

[Abraham Y. Chen]

Dear Tom:

1)  As requested, please be specific and speak only for yourself. So 
that we can carry on a professional dialog meaningfully.


2) Hint: I signed up to NANOG.org only early this year. So, whatever you 
have in mind might be from somewhere else. In addition, even though I do 
not have good memory, I do not leave a loose end to any  technical 
discussion with substance. The revisions of the EzIP documentation have 
always been improving the presentation style for easing the reader's 
efforts, not about modifying our basic scheme. So, you need to be clear 
about the topics that you are referring to. Thanks.


Regards,


Abe (2022-11-21 17:16 EST)



On 2022-11-21 13:23, Tom Beecher wrote:


1) "... for various technical reasons , ...":  Please give a couple
examples, and be specific preferably using expressions that colleagues
on this forum can understand.


Myself and multiple others provided specific technical rebuttals to 
the proposal in the past on this list.




On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen  
wrote:


Dear Tom:

1) "... for various technical reasons , ...":  Please give a couple
examples, and be specific preferably using expressions that
colleagues
on this forum can understand.

Thanks,


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




On 2022-11-21 10:44, Tom Beecher wrote:
>
>     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:
>
>

https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
>
>
> For the benefit of anyone who may not understand, this is not an
> 'alternative'. This is an idea that was initially proposed by the
> authors almost exactly 6 years ago. It's received almost no
interest
> from anyone involved in internet standards, and for
various technical
> reasons , likely never will.
>
> On Fri, Nov 18, 2022 at 10:52 PM 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:
>
>

https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
>
>     2)  If this looks a bit too technical due to the nature of
such a
>     document, there is a distilled version that provides a
bird-eye's
>     view
>     of the solution:
>
> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>
>     3)  All of the above can start from making use of the 240/4
>     netblock as
>     a reusable (by region / country) unicast IP address
resources that
>     could
>     be accomplished by as simple as commenting out one line of the
>     existing
>     network router program code. I will be glad to go into the
>     specifics if
>     you can bring their attention to this almost mystic topic.
>
>     Regards,
>
>
>     Abe (2022-11-19 22:50 EST)
>
>
>     On 2022-11-18 18:20, Owen DeLong via NANOG wrote:
>     >
>     >> On Nov 18, 2022, at 03:44, Joe Maimon
 wrote:
>     >>
>     >>
>     >>
>     >> Mark Tinka wrote:
>     >>>
>     >>> On 11/17/22 19:55, Joe Maimon wrote:
>     >>>
>      You could instead use a /31.
>     >>> We could, but many of our DIA customers have all manner of
>     CPE's that may or may not support this. Having unique
designs per
>     customer does not scale well.
>     >> its almost 2023. /31 support is easily mandatory. You should
>     make it mandatory.
>     > Much of Africa in 2023 runs on what the US put into the resale
>     market in the late 1990s, tragically.
>     >
>     >> Its 2023, your folk should be able to handle addressing more
>     advanced than from the 90s. And your betting the future on IPv6?
>     > They don’t really have a lot of alternatives.
>     >
>     >>> To be honest, we'll keep using IPv4 for as long as we
have it,
>     and for as long as we can get it from AFRINIC. But it's not
where
>     we are betting the farm - that is for IPv6.
>     > And yet you wonder why I consider AFRINIC’s artificial
extension
>     of the free pool through draconian austerity measures to be a
>     global problem?
>     >
>     >> Its on Afrinic to try and preserve their pool if they wish to
>     by doing things such as getting it across that progress in
>     addressing efficiency is an important consideration in
fulfilling
>     requests for additional resources.
>     > Instead of this, they’re mostly ignoring policy, implementing
>     

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: 202211211223.AYC

[Tom Beecher]

>
> 1) "... for various technical reasons , ...":  Please give a couple
> examples, and be specific preferably using expressions that colleagues
> on this forum can understand.
>

Myself and multiple others provided specific technical rebuttals to the
proposal in the past on this list.



On Mon, Nov 21, 2022 at 12:29 PM Abraham Y. Chen  wrote:

> Dear Tom:
>
> 1) "... for various technical reasons , ...":  Please give a couple
> examples, and be specific preferably using expressions that colleagues
> on this forum can understand.
>
> Thanks,
>
>
> Abe (2022-11-21 12:29 EST)
>
>
>
>
> On 2022-11-21 10:44, Tom Beecher wrote:
> >
> > 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:
> >
> >
> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
> >
> >
> > For the benefit of anyone who may not understand, this is not an
> > 'alternative'. This is an idea that was initially proposed by the
> > authors almost exactly 6 years ago. It's received almost no interest
> > from anyone involved in internet standards, and for various technical
> > reasons , likely never will.
> >
> > On Fri, Nov 18, 2022 at 10:52 PM 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:
> >
> >
> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
> >
> > 2)  If this looks a bit too technical due to the nature of such a
> > document, there is a distilled version that provides a bird-eye's
> > view
> > of the solution:
> >
> > https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
> >
> > 3)  All of the above can start from making use of the 240/4
> > netblock as
> > a reusable (by region / country) unicast IP address resources that
> > could
> > be accomplished by as simple as commenting out one line of the
> > existing
> > network router program code. I will be glad to go into the
> > specifics if
> > you can bring their attention to this almost mystic topic.
> >
> > Regards,
> >
> >
> > Abe (2022-11-19 22:50 EST)
> >
> >
> > On 2022-11-18 18:20, Owen DeLong via NANOG wrote:
> > >
> > >> On Nov 18, 2022, at 03:44, Joe Maimon 
> wrote:
> > >>
> > >>
> > >>
> > >> Mark Tinka wrote:
> > >>>
> > >>> On 11/17/22 19:55, Joe Maimon wrote:
> > >>>
> >  You could instead use a /31.
> > >>> We could, but many of our DIA customers have all manner of
> > CPE's that may or may not support this. Having unique designs per
> > customer does not scale well.
> > >> its almost 2023. /31 support is easily mandatory. You should
> > make it mandatory.
> > > Much of Africa in 2023 runs on what the US put into the resale
> > market in the late 1990s, tragically.
> > >
> > >> Its 2023, your folk should be able to handle addressing more
> > advanced than from the 90s. And your betting the future on IPv6?
> > > They don’t really have a lot of alternatives.
> > >
> > >>> To be honest, we'll keep using IPv4 for as long as we have it,
> > and for as long as we can get it from AFRINIC. But it's not where
> > we are betting the farm - that is for IPv6.
> > > And yet you wonder why I consider AFRINIC’s artificial extension
> > of the free pool through draconian austerity measures to be a
> > global problem?
> > >
> > >> Its on Afrinic to try and preserve their pool if they wish to
> > by doing things such as getting it across that progress in
> > addressing efficiency is an important consideration in fulfilling
> > requests for additional resources.
> > > Instead of this, they’re mostly ignoring policy, implementing
> > draconian restrictions on people getting space from the free pool,
> > and buying into various forms of reality avoidance.
> > >
> > >> But see the crux above. If your RiR isnt frowning on such
> > behavior then its poor strategy to implement it.
> > > So far, AFRINIC has given a complete pass to Tinka’s
> > organization and their documented excessive unused address space
> > despite policy that prohibits them from doing so. However, AFRINIC
> > management and board seem to have extreme difficulty with reading
> > their governing documents in anything resembling a logical
> > interpretation.
> > >
> > > Owen
> > >
> >
> >
> > --
> > This email has been checked for viruses by Avast antivirus software.
> > www.avast.com 
> >
>
>

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

[Abraham Y. Chen]

Dear Tom:

0) Thanks for your advice.

1) What I wrote was just informal online chatting. I was not attempting 
to make a water-tight legal statement. The fact is, we have identified 
at least one concise case of how this task could be done easily, as 
reported in Appendix D of the EzIP IETF Draft. Although no references 
have been published, I believe that colleagues on the IPv4 Unicast 
Extensions Project have seen similar situations.  Even without the 
latter, a "there exists one reference" should be sufficient to encourage 
other software engineers to review their own work. They should question 
the quality of their own programs if they are more complex, instead of 
ridiculing the concise example on the table.


Regards,


Abe (2022-11-21 12:54 EST)


On 2022-11-21 12:00, Tom Beecher wrote:


As stated in Subsection 4.A. of the "Revamp The
Internet" whitepaper, all need be done is "Simply disable the existing
software codes that have been disabling the use of the 240/4
netblock."


Some friendly feedback. The phrase "all that needs to be done" , is 
exceptionally reductive, and in the case of internet standards, also 
always going to end up being wrong.


On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen  
wrote:


Dear Mark:

0) Thanks for the clarification. I understand. A short message
through
the cyberspace, especially between parties who have never met can be
easily skewed. I am glad that I asked you, instead of taking it
negatively without raising my hand.

1) "...I'd, rather, expend those resources on IPv6, 464XLAT,
e.t.c. ...
": Since EzIP is still being further refined, it may not be clear
in our
documentation about how much work is required to get the IPv4 out
of the
current depletion mode. As stated in Subsection 4.A. of the
"Revamp The
Internet" whitepaper, all need be done is "Simply disable the
existing
software codes that have been disabling the use of the 240/4
netblock."
In fact, we have found examples that this means commenting out one
line
code that searches for then discards packets with 240/4
addressing. It
seems to me that there is no easier task than this.

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

Regards,

Abe (2022-11-21 11:18 EST)



On 2022-11-20 23:56, Mark Tinka wrote:
>
>
> On 11/20/22 19:02, Abraham Y. Chen wrote:
>
>> Dear Mark:
>>
>> 0)  I am surprised at your apparently sarcastic opinion.
>>
>> 1)  The EzIP proposal as referenced by my last MSG is the
result of
>> an in-depth system engineering effort. Since the resultant
schemes do
>> not rely on any protocol development, IETF does not need be
involved.
>> Especially, its first step of disabling one line of existing
>> networking program code empowers any party to begin deploying EzIP
>> stealthily for mitigating the IPv4 address pool depletion issues.
>> Note that EzIP is a generic solution applicable to everyone, not
>> limited to Africa.
>>
>> 2)  Of course, constructive criticism is always appreciated.
However,
>> unspecific comments that confuse and distract the readers only
>> provide dis-service to those disadvantaged population who are
>> enduring the handicaps of being the late-comers to the Internet.
>
> My comment was not directed at you. Sorry.
>
> I have nothing against the EzIP proposal. It just does not add any
> real value in solving the IPv4 depletion problem for the amount of
> effort required to implement it, in my view. I'd, rather, expend
those
> resources on IPv6, 464XLAT, e.t.c.
>
> Mark.
>


-- 
This email has been checked for viruses by Avast antivirus software.

www.avast.com 

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

[Abraham Y. Chen]

Dear Tom:

1) "... for various technical reasons , ...":  Please give a couple 
examples, and be specific preferably using expressions that colleagues 
on this forum can understand.


Thanks,


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




On 2022-11-21 10:44, Tom Beecher wrote:


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:


https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space


For the benefit of anyone who may not understand, this is not an 
'alternative'. This is an idea that was initially proposed by the 
authors almost exactly 6 years ago. It's received almost no interest 
from anyone involved in internet standards, and for various technical 
reasons , likely never will.


On Fri, Nov 18, 2022 at 10:52 PM 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:


https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space

2)  If this looks a bit too technical due to the nature of such a
document, there is a distilled version that provides a bird-eye's
view
of the solution:

https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

3)  All of the above can start from making use of the 240/4
netblock as
a reusable (by region / country) unicast IP address resources that
could
be accomplished by as simple as commenting out one line of the
existing
network router program code. I will be glad to go into the
specifics if
you can bring their attention to this almost mystic topic.

Regards,


Abe (2022-11-19 22:50 EST)


On 2022-11-18 18:20, Owen DeLong via NANOG wrote:
>
>> On Nov 18, 2022, at 03:44, Joe Maimon  wrote:
>>
>>
>>
>> Mark Tinka wrote:
>>>
>>> On 11/17/22 19:55, Joe Maimon wrote:
>>>
 You could instead use a /31.
>>> We could, but many of our DIA customers have all manner of
CPE's that may or may not support this. Having unique designs per
customer does not scale well.
>> its almost 2023. /31 support is easily mandatory. You should
make it mandatory.
> Much of Africa in 2023 runs on what the US put into the resale
market in the late 1990s, tragically.
>
>> Its 2023, your folk should be able to handle addressing more
advanced than from the 90s. And your betting the future on IPv6?
> They don’t really have a lot of alternatives.
>
>>> To be honest, we'll keep using IPv4 for as long as we have it,
and for as long as we can get it from AFRINIC. But it's not where
we are betting the farm - that is for IPv6.
> And yet you wonder why I consider AFRINIC’s artificial extension
of the free pool through draconian austerity measures to be a
global problem?
>
>> Its on Afrinic to try and preserve their pool if they wish to
by doing things such as getting it across that progress in
addressing efficiency is an important consideration in fulfilling
requests for additional resources.
> Instead of this, they’re mostly ignoring policy, implementing
draconian restrictions on people getting space from the free pool,
and buying into various forms of reality avoidance.
>
>> But see the crux above. If your RiR isnt frowning on such
behavior then its poor strategy to implement it.
> So far, AFRINIC has given a complete pass to Tinka’s
organization and their documented excessive unused address space
despite policy that prohibits them from doing so. However, AFRINIC
management and board seem to have extreme difficulty with reading
their governing documents in anything resembling a logical
interpretation.
>
> Owen
>


-- 
This email has been checked for viruses by Avast antivirus software.

www.avast.com 

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

[Tom Beecher]

>
> As stated in Subsection 4.A. of the "Revamp The
> Internet" whitepaper, all need be done is "Simply disable the existing
> software codes that have been disabling the use of the 240/4 netblock."
>

Some friendly feedback. The phrase "all that needs to be done" , is
exceptionally reductive, and in the case of internet standards, also always
going to end up being wrong.

On Mon, Nov 21, 2022 at 11:19 AM Abraham Y. Chen  wrote:

> Dear Mark:
>
> 0) Thanks for the clarification. I understand. A short message through
> the cyberspace, especially between parties who have never met can be
> easily skewed. I am glad that I asked you, instead of taking it
> negatively without raising my hand.
>
> 1) "...I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c. ...
> ": Since EzIP is still being further refined, it may not be clear in our
> documentation about how much work is required to get the IPv4 out of the
> current depletion mode. As stated in Subsection 4.A. of the "Revamp The
> Internet" whitepaper, all need be done is "Simply disable the existing
> software codes that have been disabling the use of the 240/4 netblock."
> In fact, we have found examples that this means commenting out one line
> code that searches for then discards packets with 240/4 addressing. It
> seems to me that there is no easier task than this.
>
> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>
> Regards,
>
> Abe (2022-11-21 11:18 EST)
>
>
>
> On 2022-11-20 23:56, Mark Tinka wrote:
> >
> >
> > On 11/20/22 19:02, Abraham Y. Chen wrote:
> >
> >> Dear Mark:
> >>
> >> 0)  I am surprised at your apparently sarcastic opinion.
> >>
> >> 1)  The EzIP proposal as referenced by my last MSG is the result of
> >> an in-depth system engineering effort. Since the resultant schemes do
> >> not rely on any protocol development, IETF does not need be involved.
> >> Especially, its first step of disabling one line of existing
> >> networking program code empowers any party to begin deploying EzIP
> >> stealthily for mitigating the IPv4 address pool depletion issues.
> >> Note that EzIP is a generic solution applicable to everyone, not
> >> limited to Africa.
> >>
> >> 2)  Of course, constructive criticism is always appreciated. However,
> >> unspecific comments that confuse and distract the readers only
> >> provide dis-service to those disadvantaged population who are
> >> enduring the handicaps of being the late-comers to the Internet.
> >
> > My comment was not directed at you. Sorry.
> >
> > I have nothing against the EzIP proposal. It just does not add any
> > real value in solving the IPv4 depletion problem for the amount of
> > effort required to implement it, in my view. I'd, rather, expend those
> > resources on IPv6, 464XLAT, e.t.c.
> >
> > Mark.
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>

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

[Abraham Y. Chen]

Dear Mark:

0) Thanks for the clarification. I understand. A short message through 
the cyberspace, especially between parties who have never met can be 
easily skewed. I am glad that I asked you, instead of taking it 
negatively without raising my hand.


1) "...I'd, rather, expend those resources on IPv6, 464XLAT, e.t.c. ... 
": Since EzIP is still being further refined, it may not be clear in our 
documentation about how much work is required to get the IPv4 out of the 
current depletion mode. As stated in Subsection 4.A. of the "Revamp The 
Internet" whitepaper, all need be done is "Simply disable the existing 
software codes that have been disabling the use of the 240/4 netblock." 
In fact, we have found examples that this means commenting out one line 
code that searches for then discards packets with 240/4 addressing. It 
seems to me that there is no easier task than this.


https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

Regards,

Abe (2022-11-21 11:18 EST)



On 2022-11-20 23:56, Mark Tinka wrote:



On 11/20/22 19:02, Abraham Y. Chen wrote:


Dear Mark:

0)  I am surprised at your apparently sarcastic opinion.

1)  The EzIP proposal as referenced by my last MSG is the result of 
an in-depth system engineering effort. Since the resultant schemes do 
not rely on any protocol development, IETF does not need be involved. 
Especially, its first step of disabling one line of existing 
networking program code empowers any party to begin deploying EzIP 
stealthily for mitigating the IPv4 address pool depletion issues. 
Note that EzIP is a generic solution applicable to everyone, not 
limited to Africa.


2)  Of course, constructive criticism is always appreciated. However, 
unspecific comments that confuse and distract the readers only 
provide dis-service to those disadvantaged population who are 
enduring the handicaps of being the late-comers to the Internet.


My comment was not directed at you. Sorry.

I have nothing against the EzIP proposal. It just does not add any 
real value in solving the IPv4 depletion problem for the amount of 
effort required to implement it, in my view. I'd, rather, expend those 
resources on IPv6, 464XLAT, e.t.c.


Mark.




--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Re: Alternative Re: ipv4/25s and above

[Tom Beecher]

>
> 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:
>
>
> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space


For the benefit of anyone who may not understand, this is not an
'alternative'. This is an idea that was initially proposed by the authors
almost exactly 6 years ago. It's received almost no interest from
anyone involved in internet standards, and for various technical reasons ,
likely never will.

On Fri, Nov 18, 2022 at 10:52 PM 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:
>
>
> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space
>
> 2)  If this looks a bit too technical due to the nature of such a
> document, there is a distilled version that provides a bird-eye's view
> of the solution:
>
> https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf
>
> 3)  All of the above can start from making use of the 240/4 netblock as
> a reusable (by region / country) unicast IP address resources that could
> be accomplished by as simple as commenting out one line of the existing
> network router program code. I will be glad to go into the specifics if
> you can bring their attention to this almost mystic topic.
>
> Regards,
>
>
> Abe (2022-11-19 22:50 EST)
>
>
> On 2022-11-18 18:20, Owen DeLong via NANOG wrote:
> >
> >> On Nov 18, 2022, at 03:44, Joe Maimon  wrote:
> >>
> >>
> >>
> >> Mark Tinka wrote:
> >>>
> >>> On 11/17/22 19:55, Joe Maimon wrote:
> >>>
>  You could instead use a /31.
> >>> We could, but many of our DIA customers have all manner of CPE's that
> may or may not support this. Having unique designs per customer does not
> scale well.
> >> its almost 2023. /31 support is easily mandatory. You should make it
> mandatory.
> > Much of Africa in 2023 runs on what the US put into the resale market in
> the late 1990s, tragically.
> >
> >> Its 2023, your folk should be able to handle addressing more advanced
> than from the 90s. And your betting the future on IPv6?
> > They don’t really have a lot of alternatives.
> >
> >>> To be honest, we'll keep using IPv4 for as long as we have it, and for
> as long as we can get it from AFRINIC. But it's not where we are betting
> the farm - that is for IPv6.
> > And yet you wonder why I consider AFRINIC’s artificial extension of the
> free pool through draconian austerity measures to be a global problem?
> >
> >> Its on Afrinic to try and preserve their pool if they wish to by doing
> things such as getting it across that progress in addressing efficiency is
> an important consideration in fulfilling requests for additional resources.
> > Instead of this, they’re mostly ignoring policy, implementing draconian
> restrictions on people getting space from the free pool, and buying into
> various forms of reality avoidance.
> >
> >> But see the crux above. If your RiR isnt frowning on such behavior then
> its poor strategy to implement it.
> > So far, AFRINIC has given a complete pass to Tinka’s organization and
> their documented excessive unused address space despite policy that
> prohibits them from doing so. However, AFRINIC management and board seem to
> have extreme difficulty with reading their governing documents in anything
> resembling a logical interpretation.
> >
> > Owen
> >
>
>
> --
> 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

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

[Abraham Y. Chen]

Dear Mathew:

0) Thanks for raising a very valid observation. Your line of reasoning 
and conclusion including the conundrum that IPv6 faces do conform with 
my understanding of the current Internet conventions and practices. 
However, this is only following the track that most people have been 
conditioned into. If one practices "think out of the box" while 
examining EzIP, as marketers frequently like to say, you may come to a 
totally different perspective. That is, if you do not mind to flip a few 
coins along the way, even though individually may seem insignificant by 
itself, the accumulated effect can change the story. Allow me to go 
through the analysis that helped us to solidify the EzIP plan.


1) What you identified was a serious hurdle that stumbled us for quite 
awhile after we initially worked out the scheme of making use of the 
long-reserved 240/4 netblock to expand the publicly assignable IPv4 
pool. It turned out that being a novice to the Internet, we tried too 
hard by trapping ourselves into literally attempting to achieve the 
end-to-end connectivity as well, immediately. By approaching the issue 
via the "Divide and Conquer" principle, the latest EzIP deployment 
strategy has been broken into two phases. The first is basic (obvious 
necessity) and straightforward. The second is optional (since it is more 
than the current Internet capable of) and requiring some efforts. 
However, both bypass the "top 50 websites" issue that you are concerned 
with. In a nutshell, they will never see EzIP, if they do not intend to 
be involved.


2)  The above is hard to visualize if you followed the bulk of the EzIP 
IETF Draft because its initial intent was to present the full EzIP 
technique and configuration for the long term which may not be 
universally needed based on our latest analysis. If you start reading 
the EzIP Draft from Appendix F and on that were added upon our 
realization of the above trade-off, you will get the sense that the "top 
50 websites" are not necessarily part of the considerations. This is 
because the RAN (Regional Area Network) which is architecturally the 
same as an existing CG-NAT "module" (pardon me for not knowing the 
correct terminology of an area served by a 100.64/10 netblock), but much 
(64 times) larger. Consequently, a RAN can be self-contained for all 
practical purposes and collectively behave as a Sub-Internet. That is, 
the port translation at the highest level of a CG-NAT module does not 
need be disturbed upon the address transition. Similarly, the "Revamp 
The Internet" whitepaper was written after we realized this two-phase 
approach. So, it focused only on phase one.


3)  The first phase of EzIP deployment will be only replacing the 
100.64/4 netblock of RFC6598 with the 240/4 netblock. This process can 
be achieved by just activating the use of the 240/4 netblock by the 
existing networking equipment. (This could be as simple as disabling one 
line of the code in a networking program that has been disabling the use 
of the 240/4 addresses.) The CG-NAT operations will not be perturbed. 
Since this transition will be confined within a RAN (replacing a few 
CG-NAT modules), the operation of distributed caching proxies used by 
the "top 50 websites" to support the CDN (Content Delivery Network) 
business configuration remain the same. So, the "top 50 websites" would 
not sense any changes due to EzIP deployment. One important benefit of 
this step is that static addresses may now be administrated to 
streamline daily operations that harden the defense against cyber 
intrusions.


4)  Once the above is done, there is a practical intermediate phase 
before attempting the worldwide end-to-end connectivity which has been 
elusive for the existing Internet. That is, since each RAN can be fairly 
large (Even without making use of private netblocks from RFC1918, each 
240/4 can serve an area with the population as big as Tokyo Metro or 
over 75% of smaller countries around the world.), subscribers within 
each RAN can begin to enjoy end-to-end connectivity such as direct eMail 
exchanges. This is equivalent to domestic postal mails and telephony 
calls which are what ordinary citizens would care about most of the 
time, anyway. At this phase, no new capability is offered across RAN 
boundaries. Current eMail facility (which is by store and forward 
anyway) and similar will continue for such needs.


5)  Next, if anyone really cares for exchange messages directly with 
someone remote (beyond the local RAN), the full EzIP header format will 
be utilized (Remember the dial-up modem supported direct PC connections 
via international phone calls over the worldwide PSTN?). Still, the "top 
50 websites" can continue their operations unaffected, unless they want 
to be more directly interacting with individuals in such activities.


6) Since the root of each RAN is connected to the Internet core via a 
public IPv4 address channel, the former can be regarded as a 

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

[Mark Tinka]

On 11/20/22 19:02, Abraham Y. Chen wrote:


Dear Mark:

0)  I am surprised at your apparently sarcastic opinion.

1)  The EzIP proposal as referenced by my last MSG is the result of an 
in-depth system engineering effort. Since the resultant schemes do not 
rely on any protocol development, IETF does not need be involved. 
Especially, its first step of disabling one line of existing 
networking program code empowers any party to begin deploying EzIP 
stealthily for mitigating the IPv4 address pool depletion issues. Note 
that EzIP is a generic solution applicable to everyone, not limited to 
Africa.


2)  Of course, constructive criticism is always appreciated. However, 
unspecific comments that confuse and distract the readers only provide 
dis-service to those disadvantaged population who are enduring the 
handicaps of being the late-comers to the Internet.


My comment was not directed at you. Sorry.

I have nothing against the EzIP proposal. It just does not add any real 
value in solving the IPv4 depletion problem for the amount of effort 
required to implement it, in my view. I'd, rather, expend those 
resources on IPv6, 464XLAT, e.t.c.


Mark.

Re: Alternative Re: ipv4/25s and above

[Eric Kuhnke]

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

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

[Abraham Y. Chen]

Dear Rubens:

0) Very good question. It is right to the point!

1) Initially, we thought that we were doing conventional protocol 
development engineering that was triggered by our curiosity about why 
IPv4 address pool was depleted. So, IETF Draft was the natural place to 
report what we were doing.


2)  As time went on, it became evident that our scheme was rather 
unorthodox. That is, it was surprisingly simpler than any other known 
techniques. As well, the benefits were more and better than we could 
have dreamed for. At the same time, developed countries such as US where 
I was in, were not in any material need for IPv4 addresses, yet 
promoting IPv6. Not being able to sort out this contradiction, it was 
necessary to keep a continuous public record as IETF Draft revisions of 
EzIP evolution as we continued to refine our scheme which had turned 
into a concise system engineering solution, or almost appeared to be a 
marketing trick.


3)  In a sense, we have been purposely publishing our work on the web 
(beyond IETF Draft) to invite critiques. So far, we have not received 
any explicit feedback pointing to its flaws, while there have been more 
than a couple subtle confirmations from rather senior Internet experts. 
I am sure that you would understand that we can not disclose the latter 
on our own. Nevertheless, they do enforce our confidence in the EzIP plan.


4)  In anticipation of your next question, I would like to add the 
following. To be sure that our discovery is protected from being claimed 
by others and then its fair use discouraged, the essence of the EzIP 
concept was submitted to US Patent Office and has been granted with US 
Pat. No. 11,159,425. This assures that EzIP may be openly discussed to 
reach as much general public as possible.


Hope the above background recap is sufficient to clear your concerns. I 
look forward to our additional exchanges.



Regards,


Abe (2022-11-20 17:00 EST)




On 2022-11-20 13:41, Rubens Kuhl wrote:

On Sun, Nov 20, 2022 at 2:03 PM Abraham Y. Chen  wrote:

Dear Mark:

0)  I am surprised at your apparently sarcastic opinion.

1)  The EzIP proposal as referenced by my last MSG is the result of an
in-depth system engineering effort. Since the resultant schemes do not
rely on any protocol development, IETF does not need be involved.

If IETF does not need to be involved, why have you submitted 12
versions of your Internet draft to IETF ?
https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/

Rubens




--
This email has been checked for viruses by Avast antivirus software.
www.avast.com

Re: Alternative Re: ipv4/25s and above

[Matthew Petach]

On Fri, Nov 18, 2022 at 7:53 PM 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:
>
>
> https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space


Hi Abraham,

I know I'm not the sharpest tool in the shed, but I'm having some
trouble understanding the deployment model for EzIP.  Perhaps you
could help clear it up for me?

A non-EzIP web server is only going to see the global destination
IP address and TCP port number as the unique session identifiers
for communication, so the vast amount of additional IP space you
postulate existing behind the SPR functionally collapses down into
the 64K TCP port range available today in traditional port-based NAT
setups.  As long as the top 50 websites aren't EzIP-aware, there appears
to be no benefit for an ISP to deploy EzIP, because it doesn't actually
gain them anything beyond what existing CG-NAT devices already provide
as far as their web-browsing customer base is concerned.  Most of their
communication will still be port-based-NAT, with all the headaches and
restrictions inherent in that.

And for the top 50 websites, there's a lot of expense and absolutely no
upside
involved in deploying EzIP.  They don't care about how much IP space you
have
behind your NAT device, and whether it's uniquely identifiable within your
local
realm; it's not information they can access for tracking users, as they
don't know
what your internal mapping is, so they'll continue to rely on browser
cookies and
the like for tracking actual user sessions, regardless of the IP addressing
format
being used.

So, you've got a model where there's functionally almost no benefit to the
end user
until the major websites start deploying EzIP-aware infrastructure, and
there's
pretty much no incentive for major websites to spend money upgrading their
infrastructure to support EzIP, because it provides no additional benefit
for them.

This is pretty much exactly the same conundrum that IPv6 faced (and still
faces
today).  I don't see why EzIP is any better than IPv6 or CG-NAT in terms of
solving
the IPv4 address shortage problem, and it seems to involve more expense for
web
providers, because it requires them to deploy additional SPR mapping
routers into
their infrastructure in order to use it, with essentially no additional
benefit.

Is there a piece to the picture I'm not understanding correctly?

Thanks!

Matt

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

[Rubens Kuhl]

On Sun, Nov 20, 2022 at 2:03 PM Abraham Y. Chen  wrote:
>
> Dear Mark:
>
> 0)  I am surprised at your apparently sarcastic opinion.
>
> 1)  The EzIP proposal as referenced by my last MSG is the result of an
> in-depth system engineering effort. Since the resultant schemes do not
> rely on any protocol development, IETF does not need be involved.

If IETF does not need to be involved, why have you submitted 12
versions of your Internet draft to IETF ?
https://datatracker.ietf.org/doc/draft-chen-ati-adaptive-ipv4-address-space/

Rubens

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

[Abraham Y. Chen]

Dear Mark:

0)  I am surprised at your apparently sarcastic opinion.

1)  The EzIP proposal as referenced by my last MSG is the result of an 
in-depth system engineering effort. Since the resultant schemes do not 
rely on any protocol development, IETF does not need be involved. 
Especially, its first step of disabling one line of existing networking 
program code empowers any party to begin deploying EzIP stealthily for 
mitigating the IPv4 address pool depletion issues. Note that EzIP is a 
generic solution applicable to everyone, not limited to Africa.


2)  Of course, constructive criticism is always appreciated. However, 
unspecific comments that confuse and distract the readers only provide 
dis-service to those disadvantaged population who are enduring the 
handicaps of being the late-comers to the Internet.


Regards,


Abe (2022-11-20 12:02 EST)


On 2022-11-19 07:58, 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

[Mark Tinka]

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.

Alternative Re: ipv4/25s and above

[Abraham Y. Chen]

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:


https://datatracker.ietf.org/doc/html/draft-chen-ati-adaptive-ipv4-address-space

2)  If this looks a bit too technical due to the nature of such a 
document, there is a distilled version that provides a bird-eye's view 
of the solution:


https://www.avinta.com/phoenix-1/home/RevampTheInternet.pdf

3)  All of the above can start from making use of the 240/4 netblock as 
a reusable (by region / country) unicast IP address resources that could 
be accomplished by as simple as commenting out one line of the existing 
network router program code. I will be glad to go into the specifics if 
you can bring their attention to this almost mystic topic.


Regards,


Abe (2022-11-19 22:50 EST)


On 2022-11-18 18:20, Owen DeLong via NANOG wrote:



On Nov 18, 2022, at 03:44, Joe Maimon  wrote:



Mark Tinka wrote:


On 11/17/22 19:55, Joe Maimon wrote:


You could instead use a /31.

We could, but many of our DIA customers have all manner of CPE's that may or 
may not support this. Having unique designs per customer does not scale well.

its almost 2023. /31 support is easily mandatory. You should make it mandatory.

Much of Africa in 2023 runs on what the US put into the resale market in the 
late 1990s, tragically.


Its 2023, your folk should be able to handle addressing more advanced than from 
the 90s. And your betting the future on IPv6?

They don’t really have a lot of alternatives.


To be honest, we'll keep using IPv4 for as long as we have it, and for as long 
as we can get it from AFRINIC. But it's not where we are betting the farm - 
that is for IPv6.

And yet you wonder why I consider AFRINIC’s artificial extension of the free 
pool through draconian austerity measures to be a global problem?


Its on Afrinic to try and preserve their pool if they wish to by doing things 
such as getting it across that progress in addressing efficiency is an 
important consideration in fulfilling requests for additional resources.

Instead of this, they’re mostly ignoring policy, implementing draconian 
restrictions on people getting space from the free pool, and buying into 
various forms of reality avoidance.


But see the crux above. If your RiR isnt frowning on such behavior then its 
poor strategy to implement it.

So far, AFRINIC has given a complete pass to Tinka’s organization and their 
documented excessive unused address space despite policy that prohibits them 
from doing so. However, AFRINIC management and board seem to have extreme 
difficulty with reading their governing documents in anything resembling a 
logical interpretation.

Owen




--
This email has been checked for viruses by Avast antivirus software.
www.avast.com