<div dir="ltr">Hello Abraham!<br><br>I believe your e-mail client (MUA) is splitting every message on a new thread.<br>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.<br><br>Cloud you please check the confs of your tool to avoid it?<br><br>Thanks in advance.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em qui., 24 de nov. de 2022 às 05:56, Abraham Y. Chen <<a href="mailto:aychen@avinta.com">aychen@avinta.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Joe:<br>
<br>
0) Allow me to share my understanding of the two topics that you brought up.<br>
<br>
1) "... <a href="https://www.google.com/intl/en/ipv6/statistics.html" rel="noreferrer" target="_blank">https://www.google.com/intl/en/ipv6/statistics.html</a>, it looks <br>
like we’ve gone from ~0% to ~40% in 12 years.... ":  Your numbers may be <br>
deceiving.<br>
<br>
   A. The IPv6 was introduced in 1995-12, launched on 2012-06-06 and <br>
ratified on 2017-07-14. So, the IPv6 efforts have been quite a few years <br>
more than your impression. That is, the IPv6 has been around over <br>
quarter of a century.<br>
<br>
   B. If you read closely, the statement  "The graph shows the <br>
percentage of users that access Google over IPv6." above the graph <br>
actually means "equipment readiness". That is, how many Google users <br>
have IPv6 capable devices. This is similar as the APNIC statistics whose <br>
title makes this clearer. However, having the capability does not mean <br>
the owners are actually using it. Also, this is not general data, but <br>
within the Google environment. Since Google is one of the stronger <br>
promoters of the IPv6, this graph would be at best the cap of such data.<br>
<br>
   C. The more meaningful data would be the global IPv6 traffic <br>
statistics. Interestingly, they do not exist upon our extensive search. <br>
(If you know of any, I would appreciate to receive a lead to such.) The <br>
closest that we could find is % of IPv6 in AMS-IX traffic statistics <br>
(see URL below). It is currently at about 5-6% and has been tapering off <br>
to a growth of less than 0.1% per month recently, after a ramp-up period <br>
in the past. (Similar saturation behavior can also be found in the above <br>
Google graph.)<br>
<br>
<a href="https://stats.ams-ix.net/sflow/ether_type.html" rel="noreferrer" target="_blank">https://stats.ams-ix.net/sflow/ether_type.html</a><br>
<br>
   D.  One interesting parameter behind the last one is that as an <br>
Inter-eXchange operator, AMS-IX should see very similar percentage <br>
traffic mix between IPv6 and IPv4. The low numbers from AMS-IX does not <br>
support this viewpoint for matching with your observation. In addition, <br>
traffic through IX is the overflow among backbone routers. A couple <br>
years ago, there was a report that peering arrangements among backbone <br>
routers for IPv6 were much less matured then IPv4, which meant that <br>
AMS-IX should be getting more IPv6 traffic than the mix in the Internet <br>
core. Interpreted in reverse, % of IPv6 in overall Internet traffic <br>
should be less than what AMS-IX handles.<br>
<br>
   E. This is a quite convoluted topic that we only scratched the <br>
surface. They should not occupy the attention of colleagues on this <br>
list. However, I am willing to provide more information to you off-line, <br>
if you care for further discussion.<br>
<br>
2)  "... <a href="https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/" rel="noreferrer" target="_blank">https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/</a> <br>
...":  My basic training was in communication equipment hardware design. <br>
I knew little about software beyond what I needed for my primary <br>
assignment. Your example, however, reminds me of a programing course <br>
that I took utilizing APL (A Programming Language) for circuit analysis, <br>
optimization and synthesis. It was such a cryptic symbolic language that <br>
classmates (mostly majored in EE hardware) were murmuring to express <br>
their displeasure. One day we got a homework assignment to do something <br>
relatively simple. Everyone struggled to write the code to do the job. <br>
Although most of us did get working codes, they were pages long. The <br>
shortest one was one full page. Upon reviewed all homework, the <br>
professor smiled at us and told us to look for the solution section at <br>
the end of the text book. It turned out to be the answer for a problem <br>
in the next chapter to be covered. The code was only three lines long! <br>
Although it did not have the codes for debugging purposes, it covered <br>
all error messages expected. It was such a shocker that everyone quieted <br>
down to focus on the subject for the rest of the semester. During my <br>
first employment, we had the need to optimize circuit designs. Since I <br>
was the only staff who knew about it, I ended up being the coordinator <br>
between several hardware designers and the supporting programmer. From <br>
that teaching, I am always looking for the most concise solution to an <br>
issue, not being distracted or discouraged by the manifestation on the <br>
surface.<br>
<br>
<a href="https://en.wikipedia.org/wiki/APL_(programming_language)" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/APL_(programming_language)</a><br>
<br>
3) Fast forward half a century, I am hoping that my "one-line code" <br>
serves the purpose of "there exists" an example in proofing a <br>
mathematical theorem for  inspiring software colleagues to review the <br>
network codes in front of them for improvement, instead of presenting <br>
such as a valid hurdle to progress.<br>
<br>
<br>
Regards,<br>
<br>
<br>
Abe (2022-11-24 03:53 EST)<br>
<br>
<br>
<br>
<br>
<br>
On 2022-11-21 19:30, Joe Maimon wrote:<br>
><br>
><br>
> David Conrad wrote:<br>
>> Barry,<br>
>><br>
>> On Nov 21, 2022, at 3:01 PM, <a href="mailto:bzs@theworld.com" target="_blank">bzs@theworld.com</a> wrote:<br>
>>> We've been trying to get people to adopt IPv6 widely for 30 years <br>
>>> with very limited success<br>
>><br>
>> According to <a href="https://www.google.com/intl/en/ipv6/statistics.html" rel="noreferrer" target="_blank">https://www.google.com/intl/en/ipv6/statistics.html</a>, it <br>
>> looks like we’ve gone from ~0% to ~40% in 12 years. <br>
>> <a href="https://stats.labs.apnic.net/ipv6" rel="noreferrer" target="_blank">https://stats.labs.apnic.net/ipv6</a> has it around 30%. Given an <br>
>> Internet population of about 5B, this can (simplistically and <br>
>> wrongly) argued to mean 1.5-2B people are using IPv6. For a <br>
>> transition to a technology that the vast majority of people who pay <br>
>> the bills will neither notice nor care about, and for which the <br>
>> business case typically needs projection way past the normal <br>
>> quarterly focus of shareholders, that seems pretty successful to me.<br>
>><br>
>> But back to the latest proposal to rearrange deck chairs on the IPv4 <br>
>> Titanic, the fundamental and obvious flaw is the assertion of <br>
>> "commenting out one line code”. There isn’t “one line of code”. There <br>
>> are literally _billions_ of instances of “one line of code”, the vast <br>
>> majority of which need to be changed/deployed/tested with absolutely <br>
>> no business case to do so that isn’t better met with deploying <br>
>> IPv6+IPv4aaS. I believe this has been pointed out numerous times, but <br>
>> it falls on deaf ears, so the discussion gets a bit tedious.<br>
>><br>
>> Regards,<br>
>> -drc<br>
>><br>
> Had the titanic stayed afloat some hours more, many more would have <br>
> survived and been rescued when assistance eventually arrived. So that <br>
> makes this a debate over whether this is deck chair re-arrangement or <br>
> something more meaningful.<br>
><br>
> As I and others have pointed out, it depends on how it is used. And <br>
> perhaps the attempt should be made regardless of knowing in advance <br>
> which it will be.<br>
><br>
> You assertion needs some back of the envelope numbers, which once <br>
> provided, I suspect will render your estimate grossly incorrect.<br>
><br>
> You can hardly attempt to convince anybody that 240/4 as unicast would <br>
> not be the more trivial change made in any of these products natural <br>
> life cycle points.<br>
><br>
> Especially as we have examples of what that type of effort might look <br>
> like. IGTFY and here<br>
><br>
> <a href="https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/" rel="noreferrer" target="_blank">https://lore.kernel.org/lkml/20080108011057.GA21168@cisco.com/</a><br>
><br>
> The burdensome position is ridiculous even more so when stated with a <br>
> straight face.<br>
><br>
> Joe<br>
><br>
><br>
><br>
<br>
<br>
-- <br>
This email has been checked for viruses by Avast antivirus software.<br>
<a href="http://www.avast.com" rel="noreferrer" target="_blank">www.avast.com</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Douglas Fernando Fischer<br>Engº de Controle e Automação<br><div style="padding:0px;margin-left:0px;margin-top:0px;overflow:hidden;color:black;text-align:left;line-height:130%;font-family:"courier new",monospace"></div></div></div>