Mailing List Archive

1 2  View All
Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC [ In reply to ]
> On Nov 22, 2022, at 2:13 PM, Tom Beecher <beecher@beecher.cc> 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: 202211232221.AYC [ In reply to ]
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.GA21168@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, bzs@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.GA21168@cisco.com/
>
> The burdensome position is ridiculous even more so when stated with a
> straight face.
>
> Joe
>
>
>


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
RE: Alternative Re: ipv4/25s and above Re: 202211232221.AYC [ In reply to ]
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.com@nanog.org] On Behalf Of Abraham Y. Chen
Sent: Thursday, November 24, 2022 11:53 AM
To: Joe Maimon <jmaimon@jmaimon.com>
Cc: NANOG <nanog@nanog.org>; bzs@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.GA21168@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, bzs@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.GA21168@cisco.com/
>
> The burdensome position is ridiculous even more so when stated with a
> straight face.
>
> Joe
>
>
>


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC [ In reply to ]
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 <aychen@avinta.com>
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.GA21168@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, bzs@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.GA21168@cisco.com/
> >
> > The burdensome position is ridiculous even more so when stated with a
> > straight face.
> >
> > Joe
> >
> >
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>


--
Douglas Fernando Fischer
Engº de Controle e Automação
Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC [ In reply to ]
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.com@nanog.org] On Behalf Of Abraham Y. Chen
> Sent: Thursday, November 24, 2022 11:53 AM
> To: Joe Maimon<jmaimon@jmaimon.com>
> Cc: NANOG<nanog@nanog.org>;bzs@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.GA21168@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,bzs@theworld.com wrote:
>>>> We've been trying to get people to adopt IPv6 widely for 30 years
>>>> with very limited success
>>> According tohttps://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.GA21168@cisco.com/
>>
>> The burdensome position is ridiculous even more so when stated with a
>> straight face.
>>
>> Joe
>>
>>
>>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>


--
This email has been checked for viruses by Avast antivirus software.
www.avast.com
Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC [ In reply to ]
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.com@nanog.org] On
>> Behalf Of Abraham Y. Chen
>> Sent: Thursday, November 24, 2022 11:53 AM
>> To: Joe Maimon<jmaimon@jmaimon.com>
>> Cc: NANOG<nanog@nanog.org>;bzs@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.GA21168@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,bzs@theworld.com  wrote:
>>>>> We've been trying to get people to adopt IPv6 widely for 30 years
>>>>> with very limited success
>>>> According tohttps://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.GA21168@cisco.com/
>>>
>>> The burdensome position is ridiculous even more so when stated with a
>>> straight face.
>>>
>>> Joe
>>>
>>>
>>>
>> --
>> This email has been checked for viruses by Avast antivirus software.
>> www.avast.com
>>
>
>
Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC [ In reply to ]
> 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 [ In reply to ]
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
> <aychen@avinta.com> 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.GA21168@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, bzs@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.GA21168@cisco.com/
> >
> > The burdensome position is ridiculous even more so when stated
> with a
> > straight face.
> >
> > Joe
> >
> >
> >
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com <http://www.avast.com>
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC [ In reply to ]
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.com@nanog.org] On
>>> Behalf Of Abraham Y. Chen
>>> Sent: Thursday, November 24, 2022 11:53 AM
>>> To: Joe Maimon<jmaimon@jmaimon.com>
>>> Cc: NANOG<nanog@nanog.org>;bzs@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.GA21168@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,bzs@theworld.com wrote:
>>>>>> We've been trying to get people to adopt IPv6 widely for 30 years
>>>>>> with very limited success
>>>>> According tohttps://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.GA21168@cisco.com/
>>>>
>>>> The burdensome position is ridiculous even more so when stated with a
>>>> straight face.
>>>>
>>>> Joe
>>>>
>>>>
>>>>
>>> --
>>> This email has been checked for viruses by Avast antivirus software.
>>> www.avast.com
>>>
>>
>>
Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC [ In reply to ]
John Curran <jcurran@istaff.org> 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: 202211201009.AYC [ In reply to ]
On Mon, Nov 21, 2022 at 4:05 PM David Conrad <drc@virtualized.org> wrote:
>
> Barry,
>
> On Nov 21, 2022, at 3:01 PM, bzs@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-6981366665607352320-FXtz
Dave Täht CEO, TekLibre, LLC
Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC [ In reply to ]
> On 24 Nov 2022, at 19:53, Abraham Y. Chen <aychen@avinta.com> 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.GA21168@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, bzs@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.GA21168@cisco.com/
>>
>> The burdensome position is ridiculous even more so when stated with a straight face.
>>
>> Joe
>>
>>
>>
>
>
> --
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
RE: Alternative Re: ipv4/25s and above Re: 202211232221.AYC [ In reply to ]
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:aychen@avinta.com]
Sent: Sunday, November 27, 2022 12:35 AM
To: Chris Welti <chris.welti@switch.ch>
Cc: NANOG <nanog@nanog.org>; bzs@theworld.com; Vasilenko Eduard <vasilenko.eduard@huawei.com>
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.com@nanog.org] On
>>> Behalf Of Abraham Y. Chen
>>> Sent: Thursday, November 24, 2022 11:53 AM
>>> To: Joe Maimon<jmaimon@jmaimon.com>
>>> Cc: NANOG<nanog@nanog.org>;bzs@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.GA21168@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,bzs@theworld.com wrote:
>>>>>> We've been trying to get people to adopt IPv6 widely for 30 years
>>>>>> with very limited success
>>>>> According tohttps://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,
>>>>> IPv6+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.GA21168@cisco.com/
>>>>
>>>> The burdensome position is ridiculous even more so when stated with
>>>> a straight face.
>>>>
>>>> Joe
>>>>
>>>>
>>>>
>>> --
>>> This email has been checked for viruses by Avast antivirus software.
>>> www.avast.com
>>>
>>
>>
Re: Alternative Re: ipv4/25s and above Re: 202211232221.AYC [ In reply to ]
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 [ In reply to ]
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<aychen@avinta.com> 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.GA21168@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,bzs@theworld.com wrote:
>>>>> We've been trying to get people to adopt IPv6 widely for 30 years with very limited success
>>>> According tohttps://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.GA21168@cisco.com/
>>>
>>> The burdensome position is ridiculous even more so when stated with a straight face.
>>>
>>> Joe
>>>
>>>
>>>
>> --
>> This email has been checked for viruses by Avast antivirus software.
>> www.avast.com

1 2  View All