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-is-a-real-world-big-deal/a/d-id/718395 )
- Comcast has over 1 Tb/s (of mostly YouTube traffic) over IPv6 ( http://corporate.comcast.com/comcast-voices/comcast-reaches-key-milestone-in-launch-of-ipv6-broadband-network )
- 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
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 
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
> 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
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
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
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
In our case IPv6 traffic is ~27% of total, with ~58% dual-stack subscribers and ~7% ds-lite subscribers.
https://www.stateoftheinternet.com/trends-visualizations-ipv6-adoption-ipv4-exhaustion-global-heat-map-network-country-growth-data.html
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
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
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
jokes aside, Its a hypothesis worth testing. It has qualities which
make it plausible.
So please, between you, find a way to specify and test it!
although the hypothesis has some intuitive appeal, how to test it is far
from obvious. and i note that, as a senior member of the measurement
community, you're saying "you guys do it." thanks a lot.
i considered rtt from a service such as goog to their querriers. there
are the problems of their distributed caches, the politics of getting
their data, and the eyeball bias. maybe find a platform with less of
those biases. dns is far too biased in all sorts of dimensions. your
add clicks? i have found no usable coffee here in nagoya, so i may be
missing something obvious.
randy
Looking at my employers network...
We know the GPS coordinates for each BGP next-hop in the network, and
traffic is sampled on ingress at the edge of the network and reported to
pmacct (*flow), which also receives a RR-style BGP feed for correlation.
We can know where (geographically) a packet enters the network, where it
leaves the network and to what address family it belongs.
However, this would be just one network's (biased) view on things.
We know the GPS coordinates for each BGP next-hop in the network, and
traffic is sampled on ingress at the edge of the network and reported
to pmacct (*flow), which also receives a RR-style BGP feed for
correlation.
We can know where (geographically) a packet enters the network, where
it leaves the network and to what address family it belongs.
i have only seen pmacct used for aggregated flow/traffic. you actually
know where each packet enters and leaves?
randy
No, not each individual packet. That's too much data.
(Taking into consideration that anything reported through flowbased
telemetry to the pmacct instances is heavily sampled)
You can configure pmacct to specify on which properties of the received
flow data it should aggregate its output data, one could configure
pmacct to store data using the following primitives:
($timeperiod, $entrypoint_router_id, $bgp_nexthop, $packet_count)
Where $timeperiod is something like 5 minute ranges, and the post
processing software calculates the distance between the entrypoint
router and where the flow would leave the network ($bgp_nexthop).
See 'aggregate' on http://wiki.pmacct.net/OfficialConfigKeys
In short: you configure pmacct to throw away everything you don't need
(maybe after some light pre-processing), and hope that what remains is
small enough to fit in your cluster and at the same time offers enough
insight to answer the question you set out to resolve.
Kind regards,
Job