Re: ingress/egress 9/8 gov.xxx.ticket; was: Re: pls pls me 80/81...

[J. Hellenthal via NANOG]

Nothing like a good ole April fools please fill my empty repo with your code. Happy 旅 genocide day everyone.--  J. HellenthalThe fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.On Nov 24, 2022, at 14:12, Matthew Petach  wrote:Whoa!Is it the start of April already?  I must have overslept last night, I could have sworn we just barely made it to Thanksgiving!MattOn Tue, Nov 22, 2022 at 6:48 AM AQ Glass  wrote:anybody interested in this project?@oracle can own the .ticket tld; NS * ticket. -> virtualhost 96hr netflow + tech/biz/admin for adnetworks to reg their new xxx. with gov.xxx.ticket signup and further instructions//https://twitter.com/element9v/status/1579552246911885312?t=NdYwACGQsPkg0o0sHtIiqA=19codedevs can commit tohttps://github.com/element9v/takebackdarpathx-eOn Thu, Nov 17, 2022, 3:50 PM AQ Glass  wrote:https://twitter.com/element9v/status/1592162934658334720?t=f1cpwD_kr3wwIVlnrzCT4A=19#routetonull discuss#takebackdarpa-e

Re: ingress/egress 9/8 gov.xxx.ticket; was: Re: pls pls me 80/81...

[Matthew Petach]

Whoa!

Is it the start of April already?
I must have overslept last night, I could have sworn we just barely made it
to Thanksgiving!

Matt

On Tue, Nov 22, 2022 at 6:48 AM AQ Glass  wrote:

> anybody interested in this project?
>
> @oracle can own the .ticket tld; NS * ticket. -> virtualhost
>
> 96hr netflow + tech/biz/admin for adnetworks to reg their new xxx. with
> gov.xxx.ticket signup and further instructions
>
> //
>
> https://twitter.com/element9v/status/1579552246911885312?t=NdYwACGQsPkg0o0sHtIiqA=19
>
> codedevs can commit to
> https://github.com/element9v/takebackdarpa
>
> thx
> -e
>
> On Thu, Nov 17, 2022, 3:50 PM AQ Glass  wrote:
>
>>
>> https://twitter.com/element9v/status/1592162934658334720?t=f1cpwD_kr3wwIVlnrzCT4A=19
>>
>> #routetonull discuss
>>
>> #takebackdarpa
>>
>> -e
>>
>

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/sflow/ether_type.html

    D.  One interesting parameter behind the 

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 IPv6 traffic 
than the mix in the Internet core. Interpreted in 

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 assignment. 
Your example, however, reminds me of a programing course 

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