Re: IPv6 traffic distribution
On Jul 28, 2011, at 11:41 PM, Michel Py wrote: IMHO, the only valid stats we can gather are either from a large content provider (which is why Lorenzo's numbers are so interesting) or from a large eyeball ISP. Cisco, Juniper, Apple, the academia, the IETF, etc are NOT valid places to collect data. I think all of the numbers are interesting, but the numbers shouldn't be separated from the conditions under which they were collected. It's reasonable to say Google is now seeing X% 6to4 traffic or My native v6 enterprise network is seeing Y% 6to4 traffic. What's not reasonable is to say that observations under one set of conditions are indicative of the whole network. Even observations made at several points by a large transit carrier might not be indicative of conditions on the other side of the world. It's also dubious to extrapolate from a few data points and call it a long term trend, because we're in a very early phase of v6 deployment (and v4 exhaustion), and there are many factors which could have a large but unpredictable influence on future use of IPv4 vs IPv6. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Jul 29, 2011, at 1:14 AM, Michel Py wrote: Joel Jaeggli wrote: 6rd is global unicast... there's nothing to discriminate it from any other native range. No. there is nothing in the current classification algorithm to discriminate from any other native range. But it's not native, as it has, among other things, the same reliance on IPv4 and the same MTU issues than 6to4 as the core mechanism is based on 6to4 tunneling, or encapsulation, or whatever else you want to call it. Well, maybe. One hopes that if an ISP chooses 6rd as a means to roll out v6 service to its customers, they've considered MTU issues and dealt with them as much as is feasible. It's much easier to do that for TCP traffic than for say UDP. All of these transition mechanisms introduce unpleasant and undesirable corner cases. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
Michel, Joel Jaeggli wrote: 6rd is global unicast... there's nothing to discriminate it from any other native range. No. there is nothing in the current classification algorithm to discriminate from any other native range. But it's not native, as it has, among other things, the same reliance on IPv4 and the same MTU issues than 6to4 as the core mechanism is based on 6to4 tunneling, or encapsulation, or whatever else you want to call it. the 6rd MTU is under control of a single provider. the transport layer MTU can be set large enough to provide a 1500 byte MTU for IPv6. I presume you are arguing that MPLS (6PE) is not native either? cheers, Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
agree but if you're trying to discriminate it by: This graph shows the daily unique queried reverse addresses by type. you can't. On Jul 29, 2011, at 1:14 AM, Michel Py wrote: Joel Jaeggli wrote: 6rd is global unicast... there's nothing to discriminate it from any other native range. No. there is nothing in the current classification algorithm to discriminate from any other native range. But it's not native, as it has, among other things, the same reliance on IPv4 and the same MTU issues than 6to4 as the core mechanism is based on 6to4 tunneling, or encapsulation, or whatever else you want to call it. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On 29/07/2011, at 8:03 AM, Joel Jaeggli wrote: agree but if you're trying to discriminate it by: This graph shows the daily unique queried reverse addresses by type. you can't. Very true Joel. I did, for a while, pattern match the 6rd prefix from Free.FR's declared ranges in RIPE whois but it was pointed out to me that dealing with one ISP like this skews things. After all, other ISps also deploy 6rd, and Comcast do some kind of related work. I can put in a 6rd line, if thats what people *want* -G ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
Le 28 juil. 2011 à 08:07, Michel Py a écrit : James, If I remember correctly, you mentioned a bit ago that your job required you had native IPv6 at home. Question: Does an ISP providing you IPv6 out of the CPE box (meaning, without any software other than dual-stack on the hosts) qualify as native IPv6 if, behind the scenes, they use a tunnel broker, or 6rd? Facts are AFAIK that: - Tunnel brokers need host cooperation. They can't be used behind the scene by ISP's. - 6rd can indeed be used behind the scene by ISP's, without users making the difference with native IPv6 routing in ISP networks. This has been proven on a large scale over 3.5 years. Regards, RD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Jul 29, 2011, at 9:39 AM, Rémi Després wrote: Le 28 juil. 2011 à 08:07, Michel Py a écrit : James, If I remember correctly, you mentioned a bit ago that your job required you had native IPv6 at home. Question: Does an ISP providing you IPv6 out of the CPE box (meaning, without any software other than dual-stack on the hosts) qualify as native IPv6 if, behind the scenes, they use a tunnel broker, or 6rd? Facts are AFAIK that: - Tunnel brokers need host cooperation. They can't be used behind the scene by ISP's. - 6rd can indeed be used behind the scene by ISP's, without users making the difference with native IPv6 routing in ISP networks. This has been proven on a large scale over 3.5 years. I would suspect that there's nothing that prevents an isp running it's own tunnel broker and a compliant cpe from automating that process in much the same way that 6rd in free required control over the firmware. the business case for doing so seems like an exercise for the reader. Regards, RD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
Le 29 juil. 2011 à 15:51, Joel Jaeggli a écrit : On Jul 29, 2011, at 9:39 AM, Rémi Després wrote: Le 28 juil. 2011 à 08:07, Michel Py a écrit : James, If I remember correctly, you mentioned a bit ago that your job required you had native IPv6 at home. Question: Does an ISP providing you IPv6 out of the CPE box (meaning, without any software other than dual-stack on the hosts) qualify as native IPv6 if, behind the scenes, they use a tunnel broker, or 6rd? Facts are AFAIK that: - Tunnel brokers need host cooperation. They can't be used behind the scene by ISP's. - 6rd can indeed be used behind the scene by ISP's, without users making the difference with native IPv6 routing in ISP networks. This has been proven on a large scale over 3.5 years. I would suspect that there's nothing that prevents an isp running it's own tunnel broker and a compliant cpe from automating that process in much the same way that 6rd in free required control over the firmware. Fair enough, that's a technical possibility. the business case for doing so seems like an exercise for the reader. Exactly, I doubt any ISP would do that, in view of the compared simplicity of 6rd. If that would be used, customers would have native prefixes for which they ignore that ISP-network traversal has bee tunneled. Regards, RD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
Le 29 juil. 2011 à 14:16, George Michaelson a écrit : On 29/07/2011, at 8:03 AM, Joel Jaeggli wrote: agree but if you're trying to discriminate it by: This graph shows the daily unique queried reverse addresses by type. you can't. Very true Joel. I did, for a while, pattern match the 6rd prefix from Free.FR's declared ranges in RIPE whois but it was pointed out to me that dealing with one ISP like this skews things. After all, other ISps also deploy 6rd, and Comcast do some kind of related work. I can put in a 6rd line, if thats what people *want* I suppose that te proportion of native IPv6 traffic due to Free will quickly decrease as IPv6 gets really deployed by others. (This proportion was reported to still be slightly above 50% a few months ago, but this was before the World IPv6 day and various other events.) Yes, that would be nice to have this proportion for some time. Thanks, RD -G ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
I have updated the graph to include 6rd, based on my understanding that the prefixes of the form 2a01:e3xx: are your 6rd space. There is *other* FreeNet space, which appears to do things, but I sense its not part of the 6rd deployment since the numberforms in the lower /64 appear to be infrastructure assignment, not classic customer space forms. Please let me know if I have this wrong. You will notice that this count places Free/6rd at a far lower relative % of unique DNS than the measures of traffic and sources people discussing here. I think this bears thinking about. http://labs.apnic.net/dns-measurement/ -George ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
The Comcast 6rd trial will conclude very soon, so I do not recommend doing anything specific for Comcast 6rd. John = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = On 7/29/11 8:16 AM, George Michaelson ggm+i...@apnic.net wrote: On 29/07/2011, at 8:03 AM, Joel Jaeggli wrote: agree but if you're trying to discriminate it by: This graph shows the daily unique queried reverse addresses by type. you can't. Very true Joel. I did, for a while, pattern match the 6rd prefix from Free.FR's declared ranges in RIPE whois but it was pointed out to me that dealing with one ISP like this skews things. After all, other ISps also deploy 6rd, and Comcast do some kind of related work. I can put in a 6rd line, if thats what people *want* -G ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 traffic distribution
James, If I remember correctly, you mentioned a bit ago that your job required you had native IPv6 at home. Question: Does an ISP providing you IPv6 out of the CPE box (meaning, without any software other than dual-stack on the hosts) qualify as native IPv6 if, behind the scenes, they use a tunnel broker, or 6rd? james woodyatt wrote: p1. Those numbers are badly outdated. What is your reading on 6rd numbers? And if these numbers are badly outdated, where do you place the MacOS IPv6 traffic distribution today? p3. Recent measurements of hits originating from Mac OS X hosts on 6to4 prefixed networks are dramatically smaller than when those measurements were taken, because Apple has updated Mac OS X 10.6 and 10.7 with significantly different behavior that will avoid using broken or underperforming 6to4 links. So where does the new behavior switch the traffic to, from 10.6 to 10.7? Back to IPv4? Or some other method? Maybe Apple is using Teredo? (ducks) :P [..] the total world IPv6 traffic now, which again is an embarrassingly small fraction of global Internet traffic. That is another debate. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Jul 28, 2011, at 1:30 AM, james woodyatt wrote: I think the measurements we've all seen at the technical plenary show that 6to4 is a small percentage of the total world IPv6 traffic now, which again is an embarrassingly small fraction of global Internet traffic. What I saw from different presentations seemed to indicate that 6to4 was around 30% of total IPv6 traffic. I think it's hard to conclude much from that in terms of future use of 6to4 vs. native. As you point out, more and more stacks are disabling 6to4 by default. But when the native v6 traffic is dominated by a single AS, it's hard to use that as an indication of how much growth there will be in use of v6. Bottom line: we still have our work cut out for us. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Thu, Jul 28, 2011 at 01:30, james woodyatt j...@apple.com wrote: http://www.pam2010.ethz.ch/papers/full-length/15.pdf Slightly less than 50% of IPv6 traffic comes from a MacOS client (fig 3); about 90% MacOS hits is 6to4, which possibly means (to me) that this piece of 6to4 MacOS software of yours represents a third of global IPv6 traffic. Would you care to comment on the numbers? p1. Those numbers are badly outdated. Speaking as one of the authors of that paper: correct, the numbers are badly outdated. You can find the more recent numbers resulting from those measurements at: http://www.google.com/intl/en/ipv6/statistics/ You will see that 6to4 now accounts for approximately 10% of total IPv6 traffic as measured using that methodology, and is steadily declining (modulo seasonal variations like the French going on holiday). ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 traffic distribution
Lorenzo, Lorenzo Colitti wrote: http://www.google.com/intl/en/ipv6/statistics/ Thanks for the update. Clarification: in your stats, is AS12322's traffic classified as native or as 6to4/teredo? Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Thu, Jul 28, 2011 at 16:51, Michel Py mic...@arneill-py.sacramento.ca.us wrote: Clarification: in your stats, is AS12322's traffic classified as native or as 6to4/teredo? As the webpage says: The Total IPv6 graph shows IPv6 users with any type of connectivity, while the Native IPv6 graph excludes users using 6to4 or Teredo. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On 28 Jul 2011, at 21:51, Michel Py wrote: Lorenzo, Lorenzo Colitti wrote: http://www.google.com/intl/en/ipv6/statistics/ Thanks for the update. Clarification: in your stats, is AS12322's traffic classified as native or as 6to4/teredo? Hi, I just ran a search through our Netflow logs of the most recent flows attempting to traverse our enterprise border and this showed: 2002::/16 (6to4): Summary: total flows: 562468, total bytes: 6.2 G, total packets: 11.0 M 2001::/32 (Teredo): Summary: total flows: 1363887, total bytes: 4.9 G, total packets: 10.1 M Other: Summary: total flows: 23681562, total bytes: 483.1 G, total packets: 546.9 M Teredo appears skewed by one host's behaviour which I'll be looking into, otherwise it's about what I'd expect with around 1% by volume being 6to4. Tim___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 traffic distribution
Bad question, I apologize for the imprecision. Please allow me to rephrase. Michel Py wrote: Clarification: in your stats, is AS12322's traffic classified as native or as 6to4/teredo? Lorenzo Colitti wrote: As the webpage says: The Total IPv6 graph shows IPv6 users with any type of connectivity, while the Native IPv6 graph excludes users using 6to4 or Teredo. How is 6rd traffic classified? as native or as 6to4/teredo? I expect that the bulk of traffic from AS12322 is 6rd. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
Looking at a trace that I got from Geoff Huston a month or two ago, there are 25486 IPv6 TCP sessions of which 10748 have a 6to4 source address. That's surprisingly high, showing that the answer depends greatly on the point of observation, and explains why operators really need to try to run a decent 6to4 relay service as long as so many such clients are observed. Which is why disabling 6to4 in clients has to be the priority; it's far too soon to decommission the relays. Regards Brian Carpenter On 2011-07-29 09:12, Tim Chown wrote: On 28 Jul 2011, at 21:51, Michel Py wrote: Lorenzo, Lorenzo Colitti wrote: http://www.google.com/intl/en/ipv6/statistics/ Thanks for the update. Clarification: in your stats, is AS12322's traffic classified as native or as 6to4/teredo? Hi, I just ran a search through our Netflow logs of the most recent flows attempting to traverse our enterprise border and this showed: 2002::/16 (6to4): Summary: total flows: 562468, total bytes: 6.2 G, total packets: 11.0 M 2001::/32 (Teredo): Summary: total flows: 1363887, total bytes: 4.9 G, total packets: 10.1 M Other: Summary: total flows: 23681562, total bytes: 483.1 G, total packets: 546.9 M Teredo appears skewed by one host's behaviour which I'll be looking into, otherwise it's about what I'd expect with around 1% by volume being 6to4. Tim ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
you may like to look at http://labs.apnic.net/dns-measurement/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Jul 28, 2011, at 7:41 PM, Brian E Carpenter wrote: Looking at a trace that I got from Geoff Huston a month or two ago, there are 25486 IPv6 TCP sessions of which 10748 have a 6to4 source address. That's surprisingly high, showing that the answer depends greatly on the point of observation, and explains why operators really need to try to run a decent 6to4 relay service as long as so many such clients are observed. Which is why disabling 6to4 in clients has to be the priority; it's far too soon to decommission the relays. Actually, it's why making hosts prefer IPv4 over 6to4 is the priority. There's absolutely nothing wrong with using 6to4 if it's the best connectivity to the destination that you have. Also, this isn't a contest, we're on the same team, and we shouldn't be competing against one another. The entire purpose of 6to4 is to allow people to use IPv6 before they have native IPv6 connectivity, because we recognize that the latter is in some cases very difficult to achieve end-to-end and faces numerous barriers that vary from one situation to the next. That's why we have so many technologies for layering IPv6 over IPv4. IOW, 6to4's purpose is to be a gateway drug for native IPv6. And it can serve that purpose even if at any given time only 1% are using it. The main thing is to make sure that people who do try 6to4 find it attractive enough that they want to upgrade to native IPv6. That means not using 6to4 in cases where it will degrade performance compared to what people get already with IPv4, but it doesn't mean disabling 6to4 entirely. It also means that DoS attacks on 6to4 are counterproductive. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 traffic distribution
Brian E Carpenter wrote: Looking at a trace that I got from Geoff Huston a month or two ago, there are 25486 IPv6 TCP sessions of which 10748 have a 6to4 source address. That's surprisingly high, Not to me. showing that the answer depends greatly on the point of observation Indeed this is the key. Validate the sample (the trace). To be meaningful, that is. Collecting IPv6 stats somewhere close to someone heavily involved in IPv6 deployment is meaningless. Among other things, Tim's numbers. Tim, we have met a few times; as I recall, you are the one who convinced me of the inevitability of IPv6 NAT. Your numbers are meaningless; not because you don't collect them right or anything involving your skills or competence, but because you're too close to the problem. That's the geek syndrome. IMHO, the only valid stats we can gather are either from a large content provider (which is why Lorenzo's numbers are so interesting) or from a large eyeball ISP. Cisco, Juniper, Apple, the academia, the IETF, etc are NOT valid places to collect data. George Michaelson wrote: you may like to look at http://labs.apnic.net/dns-measurement/ Same remarks as above, plus I don't see there anything that separates 6rd. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Jul 28, 2011, at 11:41 PM, Michel Py wrote: Same remarks as above, plus I don't see there anything that separates 6rd. 6rd is global unicast... there's nothing to discriminate it from any other native range. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: IPv6 traffic distribution
Joel Jaeggli wrote: 6rd is global unicast... there's nothing to discriminate it from any other native range. No. there is nothing in the current classification algorithm to discriminate from any other native range. But it's not native, as it has, among other things, the same reliance on IPv4 and the same MTU issues than 6to4 as the core mechanism is based on 6to4 tunneling, or encapsulation, or whatever else you want to call it. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Jul 27, 2011, at 11:12 PM, Michel Py wrote: According to this: http://www.pam2010.ethz.ch/papers/full-length/15.pdf Slightly less than 50% of IPv6 traffic comes from a MacOS client (fig 3); about 90% MacOS hits is 6to4, which possibly means (to me) that this piece of 6to4 MacOS software of yours represents a third of global IPv6 traffic. Would you care to comment on the numbers? p1. Those numbers are badly outdated. p2. Hits originating from Mac OS X hosts with their 6to4 tunnels disabled probably account for much of that traffic when it was measured. At that time, Apple's operating systems were the most commonly deployed implementations with IPv6 stacks enabled and running in the stock install. That isn't true any more. p3. Recent measurements of hits originating from Mac OS X hosts on 6to4 prefixed networks are dramatically smaller than when those measurements were taken, because Apple has updated Mac OS X 10.6 and 10.7 with significantly different behavior that will avoid using broken or underperforming 6to4 links. p4. Yes, older gear remains in the field, and some of it doesn't even have a software upgrade path. That gear, no doubt, accounts for a substantial portion of admittedly not very large flows through public 6to4 relays at present. I think the measurements we've all seen at the technical plenary show that 6to4 is a small percentage of the total world IPv6 traffic now, which again is an embarrassingly small fraction of global Internet traffic. p5. We should all be mindful that we're talking about a very small, and as far as I can tell, a not very critical segment of anybody's user base. Which, nevertheless, is still somehow to blame for holding up the global roll-out of IPv6 content. (I'm not sure even the legendary Gnomes of Zürich could do that.) What else is there to say? Oh, I remember now. Those of you 6to4-haters with Lion installed now. Please open a Terminal.app window and type this command: $ sudo sysctl -w net.inet6.icmp6.nd6_accept_6to4=0 That will make the IPv6 stack treat all Prefix Information Options with 2002::/16 prefixed addresses in them as if the A bit is always zero. The system will not auto-configure any 6to4 addresses on any interfaces, even a stf interface. Oh, you want that all the time? Add a line to /etc/sysctl.conf. Done. No more 6to4 for you. Anywhere. Let me know if that changes anything noticeably to the better for you. (On the plus side, it should spare you from suffering any indignity at the hands of a 6to4-PMT service.) -- james woodyatt j...@apple.com member of technical staff, core os networking ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
