IPv6 adoption calculation

I’m wondering if I’ve found a bug in the way IPv6 adoption is calculated/presented. Not only in the percentages, but also the fact that the page in question (“Adoption & Usage”) has an error (“Unknown Error”).

When I view the requests on the Overview page via Network inspector, and in particular the JSON of the IP version, I get the following output:
{“series”:{“IPv4”:“99.658036”,“IPv6”:“0.341964”}

When I go to the Adoption & Usage page I see the “Unknown Error” but I do see JSON returned to all requests. The Timeseries shows almost no IPv6 percentages.

In the JSON above I see 0.34% IPv6 and on the detail page it is almost always 0. In our Netflow monitor, however, I see that +/- 33% of our traffic now (we are busy with the implementation) is on IPv6 with the filter specifically Cloudflare, a much higher number than what Cloudflare indicates.

I’m curious if more people are experiencing this,

Hi… Can you please share the specific URL you are encountering this at so that I can ask the Radar team to investigate?

Thank you - stay tuned.

When you say “on the detail page”, do you mean the Adoption & Usage page, and specifically the IPv4/IPv6 graph? If so, the 0% representation may be due to rounding, but I am fairly certain that we’d be displaying the 0.34% (or at least 0.3%) instead of rounding to 0%.
As we note in the Glossary, the IPv6 percentage is calculated as (IPv6 requests / requests for dual-stacked content), so the volume of traffic over IPv6 that we are seeing from your ASN for dual-stacked content appears to be minimal.

So that’s the funny thing, we are rolling out dual-stack on all servers and I see +/- 30% of our traffic running over IPv6 and downloading mainly from Cloudflare. It is correct that not all services we host are fully dual-stack yet, but the traffic to/from that platform should be very minimal.

Doesn’t change the fact that I shouldn’t see the “unexpected error”, I think.

Sorry i can’t edit my message. As i stated, that page throws an error.

Yes, I have asked the team to look into why the page is throwing an error. I was able to reproduce, and it obviously should not be happening.

The 0.34% represents traffic we are seeing from that ASN (yours?) to Cloudflare for dual-stacked content. Are you saying that the bulk of your IPv6 traffic (the 33% you originally referenced) is from your origin to Cloudflare – our edge servers coming back and making requests to you over IPv6?

Thanks

This is our ASN indeed. Just to be absolutely sure; Since it concerns (from our point of view) downloads from Cloudflare, whether or not IPv6 is enabled/available is up to you, right? Our hosts are dual-stack with IPv4/IPv6 and prefer IPv6. This 33% (downloads) i see matches roughly the amount of servers i dual-stacked already, so from our monitoring point of view makes sense.

In fact, to get back to what I just said - we have not yet enabled all services we host with IPv6/AAAA, but what strikes me is that the service with the most traffic is dual-stacked, and that Cloudflare is eagerly communicating with it. Thats actually where almost all inbound traffic from Cloudflare is going to.

If you are serving content through Cloudflare, then it is my understanding that IPv6 (dual stack) is enabled by default. You should be able to check that in the Network section of Cloudflare Dash.

So what we are showing as a summary for the last week is that an average of 3 of every 1000 requests (0.3%) from your ASN to Cloudflare for dual-stacked content from any Cloudflare customer came in over IPv6.

The issue has been fixed, and the Adoption and Usage page for your ASN no longer displays an error.