Re: IPv6 traffic percentages?

2018-02-01 Thread nanog
More stats : https://as24904.kwaoo.net/as-stats/top.php

We are one of raf's competitor in France, FTTH based operator

~ 20% of our customers are ipv6-enabled

~ 5% of total traffic is IPv6


On 19/06/2017 13:52, Aaron Gould wrote:
> When you say some percentage is with Google, what do you mean by that ?  What 
> do you mean by "with Google" ?
> 
> - Aaron Gould
> 
> 



Re: IPv6 traffic percentages?

2017-06-23 Thread Jima

On 2017-06-23 09:09, Lee Howard wrote:

But I think you’re asking for a business education series that goes:
1. Enterprise business consideration of IPv6
a. It’s already on your network. All computers, tablets and phones have
at least Link Local, and some set up tunnels. Plus, if your employees have
dual-stack at home but single—stack VPN, you may not like your split
tunnel.


Speaking with my Enterprise Day Job hat on...

I started doing analytics on IPv6 client support regarding a (currently 
IPv4-only) employee-facing web app my team hosts. Turns out that in 15% 
of connections with IPv6, the IPv4 is coming from a subsidiary VPN, but 
the IPv6 isn't VPN'd -- supporting your point. (That number may be 
artificially low, in that not all of our business units restrict the 
users' source IP.)



d. IPv4 runout doesn’t matter much to most enterprises. They only need
a couple of addresses for new branch offices. Those enterprises who have
their own IPv4 address block (from RIR, not ISP/LIR) should consider how
much they could sell it for. At $15/address, a /16 approaches US$1
million, which is real money to most CTOs.


When you get big enough (and go through enough mergers & acquisitions), 
RFC1918 runout becomes a serious, legitimate concern. That's been a big 
selling point for me.


 Jima


Re: IPv6 traffic percentages?

2017-06-23 Thread Rod Beck
The RIPE lab tests don't indicate any compelling network performance edge for 
IPV6. https://labs.ripe.net/Members/gih/examining-ipv6-performance. Large 
businesses have huge sunk costs in their existing infrastructure. Top it off 
with conservative bureaucratic mentalities and it is pretty clear why they 
avoid IPV4.


From: NANOG <nanog-boun...@nanog.org> on behalf of Lee Howard <l...@asgard.org>
Sent: Friday, June 23, 2017 5:09:23 PM
To: Radu-Adrian Feurdean; Mukom Akong T.
Cc: NANOG list
Subject: Re: IPv6 traffic percentages?



On 6/22/17, 3:00 AM, "NANOG on behalf of Radu-Adrian Feurdean"
<nanog-boun...@nanog.org on behalf of na...@radu-adrian.feurdean.net>
wrote:

>On Thu, Jun 22, 2017, at 08:18, Mukom Akong T. wrote:
>>
>> On 18 June 2017 at 17:36, Radu-Adrian Feurdean <nanog@radu-
>> adrian.feurdean.net> wrote:>> so for the record, business customers are
>>much more active in
>>>  *rejecting* IPv6, either explictely (they say they want it
>>>  disabled) or>>  implicitly (they install their own router, not
>>>configured for
>>>  IPv6). The>>  bigger the business, the bigger the chance of rejection.
>>
>>
>> Did they per chance state their reasons for rejecting it?
>
>Not explicitly. But when we get something like "turn off that IPv6 crap
>!" we take it for: - they don't have a clearly defined need for it
> - they don't know how to deal with it
> - they don't want to deal with things they don't need (see the
>   irst point)... usually all of them at the same time.

That is my experience, too. When I was in IT, my response was to block
IPv6 at the firewall (until I learned my firewall was incapable of
examining IPv6 packets and therefore allowed ALL IPv6; I wasn’t allowed to
change firewalls so I used a router ACL to block it while I reviewed our
IPv6 security policy and looked for another job). When I was at an ISP, we
could route IPv6 to the customer, but until they enabled it, no traffic
would follow.

>
>To make it short : education. And we as as small ISP we have neither the
>resources, nor the motivation (because $$$ on the issue is negative) to
>do it (the education).

I think you’re talking about business education, not technical IPv6
education, right?
I recently posted my suggested technical reading list:
http://www.wleecoyote.com/blog/IPv6reading.html

But I think you’re asking for a business education series that goes:
1. Enterprise business consideration of IPv6
   a. It’s already on your network. All computers, tablets and phones have
at least Link Local, and some set up tunnels. Plus, if your employees have
dual-stack at home but single—stack VPN, you may not like your split
tunnel.
   b. Lower latency.
   c. Using IPv6 in interesting ways, like Segment Routing, Terastream bit
masking, IPv6 address as process ID.
   d. IPv4 runout doesn’t matter much to most enterprises. They only need
a couple of addresses for new branch offices. Those enterprises who have
their own IPv4 address block (from RIR, not ISP/LIR) should consider how
much they could sell it for. At $15/address, a /16 approaches US$1
million, which is real money to most CTOs.
http://www.wleecoyote.com/blog/2017prices.htm

2. Enterprise IPv6 implementation guidance
  a. https://tools.ietf.org/html/rfc7381  “Enterprise IPv6 Deployment
Guidelines”
  b. Cost to Renumber and Sell IPv4
http://retevia.net/Downloads/EnterpriseRenumbering.pdf


I’ll see if I can write up #1 into a single paper or blog post in the next
few days. Anything else I should add?

Lee

>




Re: IPv6 traffic percentages?

2017-06-23 Thread Lee Howard


On 6/22/17, 3:00 AM, "NANOG on behalf of Radu-Adrian Feurdean"

wrote:

>On Thu, Jun 22, 2017, at 08:18, Mukom Akong T. wrote:
>> 
>> On 18 June 2017 at 17:36, Radu-Adrian Feurdean > adrian.feurdean.net> wrote:>> so for the record, business customers are
>>much more active in
>>>  *rejecting* IPv6, either explictely (they say they want it
>>>  disabled) or>>  implicitly (they install their own router, not
>>>configured for
>>>  IPv6). The>>  bigger the business, the bigger the chance of rejection.
>> 
>> 
>> Did they per chance state their reasons for rejecting it?
>
>Not explicitly. But when we get something like "turn off that IPv6 crap
>!" we take it for: - they don't have a clearly defined need for it
> - they don't know how to deal with it
> - they don't want to deal with things they don't need (see the
>   irst point)... usually all of them at the same time.

That is my experience, too. When I was in IT, my response was to block
IPv6 at the firewall (until I learned my firewall was incapable of
examining IPv6 packets and therefore allowed ALL IPv6; I wasn’t allowed to
change firewalls so I used a router ACL to block it while I reviewed our
IPv6 security policy and looked for another job). When I was at an ISP, we
could route IPv6 to the customer, but until they enabled it, no traffic
would follow.

>
>To make it short : education. And we as as small ISP we have neither the
>resources, nor the motivation (because $$$ on the issue is negative) to
>do it (the education).

I think you’re talking about business education, not technical IPv6
education, right?
I recently posted my suggested technical reading list:
http://www.wleecoyote.com/blog/IPv6reading.html

But I think you’re asking for a business education series that goes:
1. Enterprise business consideration of IPv6
   a. It’s already on your network. All computers, tablets and phones have
at least Link Local, and some set up tunnels. Plus, if your employees have
dual-stack at home but single—stack VPN, you may not like your split
tunnel.
   b. Lower latency.
   c. Using IPv6 in interesting ways, like Segment Routing, Terastream bit
masking, IPv6 address as process ID.
   d. IPv4 runout doesn’t matter much to most enterprises. They only need
a couple of addresses for new branch offices. Those enterprises who have
their own IPv4 address block (from RIR, not ISP/LIR) should consider how
much they could sell it for. At $15/address, a /16 approaches US$1
million, which is real money to most CTOs.
http://www.wleecoyote.com/blog/2017prices.htm

2. Enterprise IPv6 implementation guidance
  a. https://tools.ietf.org/html/rfc7381  “Enterprise IPv6 Deployment
Guidelines” 
  b. Cost to Renumber and Sell IPv4
http://retevia.net/Downloads/EnterpriseRenumbering.pdf


I’ll see if I can write up #1 into a single paper or blog post in the next
few days. Anything else I should add?

Lee

>




Re: IPv6 traffic percentages?

2017-06-22 Thread Mukom Akong T.
On 18 June 2017 at 17:36, Radu-Adrian Feurdean <
na...@radu-adrian.feurdean.net> wrote:

> so for the record, business customers are much more active in
> *rejecting* IPv6, either explictely (they say they want it disabled) or
> implicitly (they install their own router, not configured for IPv6). The
> bigger the business, the bigger the chance of rejection.
>


Did they per chance state their reasons for rejecting it?


-- 

Mukom Akong T.

LinkedIn:Mukom   |  twitter:
@perfexcellent


--
“When you work, you are the FLUTE through whose lungs the whispering of the
hours turns to MUSIC" - Kahlil Gibran
---


Re: IPv6 traffic percentages?

2017-06-22 Thread Mikael Abrahamsson

On Thu, 22 Jun 2017, Radu-Adrian Feurdean wrote:


To make it short : education. And we as as small ISP we have neither the
resources, nor the motivation (because $$$ on the issue is negative) to
do it (the education).


An ISP should be an enabler, and have a service portfolio to cover most 
customers need. Not all customers will want all the services, so if a 
customer doesn't want IPv6 then fine, turn it off for them. When they come 
back later and want it, they know you have it.


You've done your part, and that's great!

--
Mikael Abrahamssonemail: swm...@swm.pp.se


Re: IPv6 traffic percentages?

2017-06-22 Thread Radu-Adrian Feurdean
On Thu, Jun 22, 2017, at 08:18, Mukom Akong T. wrote:
> 
> On 18 June 2017 at 17:36, Radu-Adrian Feurdean  adrian.feurdean.net> wrote:>> so for the record, business customers are much 
> more active in
>>  *rejecting* IPv6, either explictely (they say they want it
>>  disabled) or>>  implicitly (they install their own router, not configured 
>> for
>>  IPv6). The>>  bigger the business, the bigger the chance of rejection.
> 
> 
> Did they per chance state their reasons for rejecting it?

Not explicitly. But when we get something like "turn off that IPv6 crap
!" we take it for: - they don't have a clearly defined need for it
 - they don't know how to deal with it
 - they don't want to deal with things they don't need (see the
   irst point)... usually all of them at the same time.

To make it short : education. And we as as small ISP we have neither the
resources, nor the motivation (because $$$ on the issue is negative) to
do it (the education).
--
R-A.F.


Re: IPv6 traffic percentages?

2017-06-19 Thread Radu-Adrian Feurdean
On Mon, Jun 19, 2017, at 14:17, f...@fhrnet.eu wrote:
> I assume it means 60% of all their IPv6 traffic is reaching Google
> services, ie GMail or YouTube.
Exactly.

Or otherwise said, more than 60% of the IPv6 bytes (NOT flow entries)
accounted via Sflow (residential) or sampled Netflow (whole traffic)
come from or go to 2a00:1450::/29. We had month with over 67%.


RE: IPv6 traffic percentages?

2017-06-19 Thread fhr


RE: IPv6 traffic percentages?

2017-06-19 Thread Aaron Gould
When you say some percentage is with Google, what do you mean by that ?  What 
do you mean by "with Google" ?

- Aaron Gould




Re: IPv6 traffic percentages?

2017-06-18 Thread Radu-Adrian Feurdean
On Mon, Jun 5, 2017, at 14:51, Bajpai, Vaibhav wrote:
 
> The v6 numbers from ^ NANOG post are now more than 1 year old. Thought 
> to re-bump this thread. Would it be possible to share updated numbers 
> of v6 traffic share within your network and % contribution by top apps.

Hello,

A little late and "out-of-geography", but still... On small-ish French
ISP we have :
 - on the residential-only FTTH part, where all clients have IPv6 by
 default (unless they do something to avoid using it - and some do) : up
 to 30% of total is IPv6, and at least 60% of IPv6 is with Google.
 - globally (residential+business), the rate drops to 9% with peaks
 towards 20% on week-ends and public holidays. Same thing with Google
 doing most of IPv6.

For the record, apart Google, there are less than 10 ASes that have more
than 1% (but less than 10%) of the total IPv6 traffic. Everybody else is
just traces

Also for the record, business customers are much more active in
*rejecting* IPv6, either explictely (they say they want it disabled) or
implicitly (they install their own router, not configured for IPv6). The
bigger the business, the bigger the chance of rejection.

--
R-A.F.



Re: IPv6 traffic percentages?

2016-01-25 Thread Owen DeLong
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  wrote:
> 
> 
>> On Jan 20, 2016, at 6:14 AM, nanog-...@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-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
> 
> 
> 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.cur...@ndsu.edu
> Certified NetAnalyst II701-231-8527
> North Dakota State University
> 



Re: IPv6 traffic percentages?

2016-01-24 Thread Bruce Curtis

> On Jan 20, 2016, at 6:14 AM, nanog-...@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-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


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.cur...@ndsu.edu
Certified NetAnalyst II701-231-8527
North Dakota State University



Re: IPv6 traffic percentages?

2016-01-21 Thread Job Snijders
On Thu, Jan 21, 2016 at 11:44:34PM +0900, Randy Bush wrote:
> > 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.
> 
> but could you explain in detail how this tests the hypothesis?
> 
> even of all your traffic entered on a bgp hop and exited on a bgp hop,
> and all bgp entries set next_hop (which i think you do), you would be
> ignoring the 'distance' the packet traveled from source to get to your
> entry and traveled from your exit to get to the final destination.

Yes, correct. This is why I mentioned before: "However, this would be
just one network's (biased) view on things."

With this I meant that I can measure something, but only within a subset
of the entire path a packet might traverse. (just that one routing
domain), so not end-to-end. And what might be true for us might not be
true for others.


Re: IPv6 traffic percentages?

2016-01-21 Thread Randy Bush
> With this I meant that I can measure something, but only within a subset
> of the entire path a packet might traverse.

considering your original hypothesis was about length of paths, this
seems a kind of dead end.  you might get a modest improvement by turning
off hot potato :)

> so not end-to-end

which is the problem

> And what might be true for us might not be true for others.

yes.  but if it actually measured what we wanted, it would be a useful
measurement.  but it doesn't.

randy


Re: IPv6 traffic percentages?

2016-01-20 Thread nanog-isp
On Wednesday, January 20, 2016 Niels Bakker wrote:
> 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


Re: IPv6 traffic percentages?

2016-01-20 Thread Matt Palmer
On Wed, Jan 20, 2016 at 01:14:42PM +0100, nanog-...@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



Re: IPv6 traffic percentages?

2016-01-20 Thread Job Snijders
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? :)


Re: IPv6 traffic percentages?

2016-01-20 Thread Randy Bush
> 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


Re: IPv6 traffic percentages?

2016-01-20 Thread Owen DeLong

> On Jan 20, 2016, at 04:41 , Job Snijders  wrote:
> 
> On Wed, Jan 20, 2016 at 01:32:11PM +0100, nanog-...@mail.com wrote:
>> 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
> 
> 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



Re: IPv6 traffic percentages?

2016-01-20 Thread Owen DeLong

> On Jan 20, 2016, at 06:45 , Jared Mauch  wrote:
> 
>> 
>> On Jan 20, 2016, at 9:31 AM, Job Snijders  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



Re: IPv6 traffic percentages?

2016-01-20 Thread Randy Bush
>>> 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


Re: IPv6 traffic percentages?

2016-01-20 Thread Randy Bush
> 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


Re: IPv6 traffic percentages?

2016-01-20 Thread Tassos Chatzithomaoglou via NANOG
In our case IPv6 traffic is ~27% of total, with ~58% dual-stack subscribers and 
~7% ds-lite subscribers.

--
Tassos

nanog-...@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-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
>



Re: IPv6 traffic percentages?

2016-01-20 Thread nanog-isp


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 :)


Re: IPv6 traffic percentages?

2016-01-20 Thread Job Snijders
On Wed, Jan 20, 2016 at 01:32:11PM +0100, nanog-...@mail.com wrote:
> 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

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


Re: IPv6 traffic percentages?

2016-01-20 Thread Job Snijders
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


Re: IPv6 traffic percentages?

2016-01-20 Thread Jared Mauch

> On Jan 20, 2016, at 9:31 AM, Job Snijders  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


Re: IPv6 traffic percentages?

2016-01-20 Thread Niels Bakker

* nanog-...@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-exhaustion-global-heat-map-network-country-growth-data.html


-- Niels.


Re: IPv6 traffic percentages?

2016-01-20 Thread Randy Bush
> 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