Hello all, Would those with IPv6 deployments kindly share some statistics on their percentage of IPv6 traffic? Bonus points for sharing top IPv6 sources. Anything else than the usual suspects, Google/YouTube, Netflix and Facebook? Some public information I've found so far: - Comcast around 25% IPv6 traffic ( http://www.lightreading.com/ethernet-ip/ip-protocols-software/facebook-ipv6-... ) - Comcast has over 1 Tb/s (of mostly YouTube traffic) over IPv6 ( http://corporate.comcast.com/comcast-voices/comcast-reaches-key-milestone-in... ) - Swisscom 26% IPv6 traffic, 60% YouTube ( http://www.swinog.ch/meetings/swinog27/p/01_Martin_Gysi.pdf ) I'd be very much interested in hearing from smaller ISPs, especially those having a very limited number of IPv4 addresses and/or running out. Thanks, Jared
On Jan 20, 2016, at 7:14 AM, nanog-isp@mail.com wrote:
Hello all,
Would those with IPv6 deployments kindly share some statistics on their percentage of IPv6 traffic?
Bonus points for sharing top IPv6 sources. Anything else than the usual suspects, Google/YouTube, Netflix and Facebook?
Some public information I've found so far: - Comcast around 25% IPv6 traffic ( http://www.lightreading.com/ethernet-ip/ip-protocols-software/facebook-ipv6-... ) - Comcast has over 1 Tb/s (of mostly YouTube traffic) over IPv6 ( http://corporate.comcast.com/comcast-voices/comcast-reaches-key-milestone-in... ) - Swisscom 26% IPv6 traffic, 60% YouTube ( http://www.swinog.ch/meetings/swinog27/p/01_Martin_Gysi.pdf )
I'd be very much interested in hearing from smaller ISPs, especially those having a very limited number of IPv4 addresses and/or running out.
Thanks,
Jared
^^^^^^^ Not me ;) I currently see around 56.4:1 with the timing of peaks the same in v4 and v6. I am talking with a few local wireless ISPs in my area that are going to be running fiber, they currently provide a NAT44 experience and I’m pushing them to deploy IPv6 to preserve their CGN state. This is mostly an exercise in them making the time to enable it vs needing convincing. - [another] Jared
On Wednesday, January 20, 2016 Jared Mauch wrote:
I currently see around 56.4:1 with the timing of peaks the same in v4 and v6. So that's more in line with AMS-IX (70G/4T) than Comcast/Swisscom then. AMS-IX: https://ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic
- Jared (the First of his name :)
On Wed, Jan 20, 2016 at 01:32:11PM +0100, nanog-isp@mail.com wrote:
I currently see around 56.4:1 with the timing of peaks the same in v4 and v6. So that's more in line with AMS-IX (70G/4T) than Comcast/Swisscom
On Wednesday, January 20, 2016 Jared Mauch wrote: then. AMS-IX: https://ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic
I propose the following axiom: the greater the distance over which a packet is forwarded, the less likely it is to be an IPv6 packet. Kind regards, Job
I propose the following axiom: the greater the distance over which a packet is forwarded, the less likely it is to be an IPv6 packet.
that is a hypothesis not an axiom, especially without considerable measurement to back it up. but an interesting hypothesis. how do you propose to test it? randy
On Wed, Jan 20, 2016 at 11:13:41PM +0900, Randy Bush wrote:
I propose the following axiom: the greater the distance over which a packet is forwarded, the less likely it is to be an IPv6 packet.
that is a hypothesis not an axiom [...]
Thanks.
but an interesting hypothesis. how do you propose to test it?
We could assert that the TTL is an indication of distance traveled. Maybe one should record the TTL and Address Family of all packets received from the internet ('inbound') at the next NANOG or IETF? Kind regards, Job
On Jan 20, 2016, at 9:31 AM, Job Snijders <job@instituut.net> wrote:
On Wed, Jan 20, 2016 at 11:13:41PM +0900, Randy Bush wrote:
I propose the following axiom: the greater the distance over which a packet is forwarded, the less likely it is to be an IPv6 packet.
that is a hypothesis not an axiom [...]
Thanks.
but an interesting hypothesis. how do you propose to test it?
We could assert that the TTL is an indication of distance traveled.
Maybe one should record the TTL and Address Family of all packets received from the internet ('inbound') at the next NANOG or IETF?
One could likely just watch the traffic from CPE at a home of any DS user and track the TTLs there. The problem of course is networks that do not do TTL decrement, or are doing 6PE over an IPv4 only core. It makes this a less scientific study IMHO. These need to be weighted appropriately in results analysis. Might be an interesting discussion on the mat list, I know we can do SSL cert checks, but can we do http checks yet? (forgot the outcome). Could take the top N names from something like DITL and fetch them. - Jared
On Jan 20, 2016, at 06:45 , Jared Mauch <jared@puck.nether.net> wrote:
On Jan 20, 2016, at 9:31 AM, Job Snijders <job@instituut.net> wrote:
On Wed, Jan 20, 2016 at 11:13:41PM +0900, Randy Bush wrote:
I propose the following axiom: the greater the distance over which a packet is forwarded, the less likely it is to be an IPv6 packet.
that is a hypothesis not an axiom [...]
Thanks.
but an interesting hypothesis. how do you propose to test it?
We could assert that the TTL is an indication of distance traveled.
Maybe one should record the TTL and Address Family of all packets received from the internet ('inbound') at the next NANOG or IETF?
One could likely just watch the traffic from CPE at a home of any DS user and track the TTLs there.
The problem of course is networks that do not do TTL decrement, or are doing 6PE over an IPv4 only core. It makes this a less scientific study IMHO.
I think that’s actually in the noise since we are using TTL as a proxy for distance traveled. The networks you are describing are by and large not international or even continental transit networks. Owen
We could assert that the TTL is an indication of distance traveled.
you might hypothesize it. but the wide variance in per-hop rtt would seem to belie that.
Maybe one should record the TTL and Address Family of all packets received from the internet ('inbound') at the next NANOG or IETF?
we have large bodies of traceroute and ping results in various stores, mlab, atlas, mawi, ... it is the analysis to test your original hypothesis which baffles me. randy
On Thu, Jan 21, 2016 at 08:23:09AM +0900, Randy Bush wrote:
We could assert that the TTL is an indication of distance traveled.
you might hypothesize it. but the wide variance in per-hop rtt would seem to belie that.
Maybe one should record the TTL and Address Family of all packets received from the internet ('inbound') at the next NANOG or IETF?
we have large bodies of traceroute and ping results in various stores, mlab, atlas, mawi, ... it is the analysis to test your original hypothesis which baffles me.
I'm not sure if milions traceroutes to all kinds of places are a good dataset to begin with. I'd try to look at natural / organic traffic, such as can be caught at a dual-stacked CPE or webserver. The majority of the traffic my employer carriers is not traceroute packets but other stuff. When will you have the paper ready for publishing? :)
We could assert that the TTL is an indication of distance traveled.
you might hypothesize it. but the wide variance in per-hop rtt would seem to belie that.
Maybe one should record the TTL and Address Family of all packets received from the internet ('inbound') at the next NANOG or IETF?
we have large bodies of traceroute and ping results in various stores, mlab, atlas, mawi, ... it is the analysis to test your original hypothesis which baffles me.
I'm not sure if milions traceroutes to all kinds of places are a good dataset to begin with.
all depends on what the actual means by which you intend to test your hypothesis, which you have yet to reveal. all i have heard so far is ttl, which we know is no measure of distance. randy
On Jan 20, 2016, at 04:41 , Job Snijders <job@instituut.net> wrote:
On Wed, Jan 20, 2016 at 01:32:11PM +0100, nanog-isp@mail.com wrote:
I currently see around 56.4:1 with the timing of peaks the same in v4 and v6. So that's more in line with AMS-IX (70G/4T) than Comcast/Swisscom
On Wednesday, January 20, 2016 Jared Mauch wrote: then. AMS-IX: https://ams-ix.net/technical/statistics/sflow-stats/ipv6-traffic
I propose the following axiom: the greater the distance over which a packet is forwarded, the less likely it is to be an IPv6 packet.
Kind regards,
Job
I’m not sure that is the issue so much as packets outside of North America are less likely to be IPv6 packets than packets traversing networks entirely within North America. Packets outside of North America and Europe are less likely than packets within those two continents. Asia is more likely than Mexico or Africa, and about equally likely with most of South America. I can see how this circumstance could lead one to believe that there is a correlation with distance, but I draw the distinction because I want to avoid the introduction of “Post hoc ergo propter hoc” based errors into decisions about how to improve the situation. Owen
On Wednesday, January 20, 2016 Niels Bakker wrote:
https://www.stateoftheinternet.com/trends-visualizations-ipv6-adoption-ipv4-...
Thanks, I looked at that link before I posted. Unfortunately the data is both too coarse and too narrow to be of much use. I'm sure it tells us something about Akamai's and their customers' IPv6 efforts, but it does not tell ISPs anything about what kind of IPv6 flows and volumes to expect.
From what I've learned so far IPv6 percentages of total traffic for ISPs vary between very little to a small amount. This pretty much gives lie to the claims that IPv6 efforts will reduce pressure on CGNAT resources.
Jared
* nanog-isp@mail.com [Wed 20 Jan 2016, 13:15 CET]:
Would those with IPv6 deployments kindly share some statistics on their percentage of IPv6 traffic?
https://www.stateoftheinternet.com/trends-visualizations-ipv6-adoption-ipv4-... -- Niels.
In our case IPv6 traffic is ~27% of total, with ~58% dual-stack subscribers and ~7% ds-lite subscribers. -- Tassos nanog-isp@mail.com wrote on 20/1/16 14:14:
Hello all,
Would those with IPv6 deployments kindly share some statistics on their percentage of IPv6 traffic?
Bonus points for sharing top IPv6 sources. Anything else than the usual suspects, Google/YouTube, Netflix and Facebook?
Some public information I've found so far: - Comcast around 25% IPv6 traffic ( http://www.lightreading.com/ethernet-ip/ip-protocols-software/facebook-ipv6-... ) - Comcast has over 1 Tb/s (of mostly YouTube traffic) over IPv6 ( http://corporate.comcast.com/comcast-voices/comcast-reaches-key-milestone-in... ) - Swisscom 26% IPv6 traffic, 60% YouTube ( http://www.swinog.ch/meetings/swinog27/p/01_Martin_Gysi.pdf )
I'd be very much interested in hearing from smaller ISPs, especially those having a very limited number of IPv4 addresses and/or running out.
Thanks,
Jared
On Wed, Jan 20, 2016 at 01:14:42PM +0100, nanog-isp@mail.com wrote:
Would those with IPv6 deployments kindly share some statistics on their percentage of IPv6 traffic?
https://twitter.com/discourse/status/679808652128030720 We're a smallish content source. - Matt
On Jan 20, 2016, at 6:14 AM, nanog-isp@mail.com wrote:
Hello all,
Would those with IPv6 deployments kindly share some statistics on their percentage of IPv6 traffic?
Bonus points for sharing top IPv6 sources. Anything else than the usual suspects, Google/YouTube, Netflix and Facebook?
Some public information I've found so far: - Comcast around 25% IPv6 traffic ( http://www.lightreading.com/ethernet-ip/ip-protocols-software/facebook-ipv6-... ) - Comcast has over 1 Tb/s (of mostly YouTube traffic) over IPv6 ( http://corporate.comcast.com/comcast-voices/comcast-reaches-key-milestone-in... ) - Swisscom 26% IPv6 traffic, 60% YouTube ( http://www.swinog.ch/meetings/swinog27/p/01_Martin_Gysi.pdf )
I'd be very much interested in hearing from smaller ISPs, especially those having a very limited number of IPv4 addresses and/or running out.
Thanks,
Jared
This is some more public info. On this page click to sort on IPv6 deployment. http://www.worldipv6launch.org/measurements/ About 40% of traffic inbound to our University is IPv6. I see several Universities on the list above at more than 60%. There are more links to public info sites at the bottom of the page. You can add Apple and Microsoft to the list of usual suspects, but for state in NAT boxes rather than traffic. With happy eyeballs devices query both IPv4 and IPv6 so end up creating state in the NAT box even if the client ultimately chooses IPv6 for the connection. We have lots of devices that like to check with Apple whenever they wake up and the staff here use Microsoft Exchange in the cloud which is available via IPv6. I don’t have any verified data but I have noticed a relation between Scroll to the bottom of this page and you will see that my latency to Google via IPv6 dropped from 40 ms to 20 ms. http://mcnet.cc.ndsu.nodak.edu/smokeping/?target=Internet.Google_IPv6 If I compare some days before and after the change I see a decrease in my peak NAT pool usage. However on other days I don’t see a difference. The theory is that after my latency dropped to 20 ms that should be less than the magical 25 ms for Apple devices to receive an answer via IPv6 so they don’t even send out an IPv4 query. https://www.ietf.org/mail-archive/web/v6ops/current/msg22455.html This link mentions that Microsoft is already preferring IPv6 over IPv4 95% of the time when both are available. http://labs.apnic.net/?p=657 I’m 30 ms away from Facebook so 95% of Microsoft clients would use IPv6 but for Apple devices it’s a gamble. But it’s not clear if 95% of Microsoft clients would only send an IPv6 SYN and not send an IPv4 SYN (saving NAT table size). The top of our wish list would be for twitter and AWS to support IPv6, I think that those would make the biggest reduction in our NAT table size. If you hover your mouse over the US on this page http://6lab.cisco.com/stats/ it lists 47% for content. What that 47% means is explained here. http://6lab.cisco.com/stats/information.php#content It is fun to play with the type of regression on this page and project 730 days or so in the future. https://www.vyncke.org/ipv6status/project.php --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University
Not to put any sort of damper on wild speculation, but at the Southern California Linux Expo, with native IPv4 and IPv6 dual stack support enabled on the wifi for the show, we saw close to 50% of all traffic on IPv6. Owen
On Jan 24, 2016, at 07:23 , Bruce Curtis <bruce.curtis@ndsu.edu> wrote:
On Jan 20, 2016, at 6:14 AM, nanog-isp@mail.com wrote:
Hello all,
Would those with IPv6 deployments kindly share some statistics on their percentage of IPv6 traffic?
Bonus points for sharing top IPv6 sources. Anything else than the usual suspects, Google/YouTube, Netflix and Facebook?
Some public information I've found so far: - Comcast around 25% IPv6 traffic ( http://www.lightreading.com/ethernet-ip/ip-protocols-software/facebook-ipv6-... ) - Comcast has over 1 Tb/s (of mostly YouTube traffic) over IPv6 ( http://corporate.comcast.com/comcast-voices/comcast-reaches-key-milestone-in... ) - Swisscom 26% IPv6 traffic, 60% YouTube ( http://www.swinog.ch/meetings/swinog27/p/01_Martin_Gysi.pdf )
I'd be very much interested in hearing from smaller ISPs, especially those having a very limited number of IPv4 addresses and/or running out.
Thanks,
Jared
This is some more public info.
On this page click to sort on IPv6 deployment.
http://www.worldipv6launch.org/measurements/
About 40% of traffic inbound to our University is IPv6. I see several Universities on the list above at more than 60%.
There are more links to public info sites at the bottom of the page.
You can add Apple and Microsoft to the list of usual suspects, but for state in NAT boxes rather than traffic. With happy eyeballs devices query both IPv4 and IPv6 so end up creating state in the NAT box even if the client ultimately chooses IPv6 for the connection. We have lots of devices that like to check with Apple whenever they wake up and the staff here use Microsoft Exchange in the cloud which is available via IPv6. I don’t have any verified data but I have noticed a relation between
Scroll to the bottom of this page and you will see that my latency to Google via IPv6 dropped from 40 ms to 20 ms.
http://mcnet.cc.ndsu.nodak.edu/smokeping/?target=Internet.Google_IPv6
If I compare some days before and after the change I see a decrease in my peak NAT pool usage. However on other days I don’t see a difference. The theory is that after my latency dropped to 20 ms that should be less than the magical 25 ms for Apple devices to receive an answer via IPv6 so they don’t even send out an IPv4 query.
https://www.ietf.org/mail-archive/web/v6ops/current/msg22455.html
This link mentions that Microsoft is already preferring IPv6 over IPv4 95% of the time when both are available.
I’m 30 ms away from Facebook so 95% of Microsoft clients would use IPv6 but for Apple devices it’s a gamble. But it’s not clear if 95% of Microsoft clients would only send an IPv6 SYN and not send an IPv4 SYN (saving NAT table size).
The top of our wish list would be for twitter and AWS to support IPv6, I think that those would make the biggest reduction in our NAT table size.
If you hover your mouse over the US on this page
it lists 47% for content. What that 47% means is explained here.
http://6lab.cisco.com/stats/information.php#content
It is fun to play with the type of regression on this page and project 730 days or so in the future.
https://www.vyncke.org/ipv6status/project.php
--- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University
From: "Owen DeLong"
I know, but for the "server guys" turning on IPv6 it's pretty low on priority list.
Which is a selfish, arrogant, and extremely short-sighted and unenlightened view of self-interest. Yes, yes, but is it economically rational?
Jared
participants (9)
-
Bruce Curtis -
Jared Mauch -
Job Snijders -
Matt Palmer -
nanog-isp＠mail.com -
Niels Bakker -
Owen DeLong -
Randy Bush -
Tassos Chatzithomaoglou