IPv6 content experiment

Kevin Day toasty at dragondata.com
Mon Apr 9 12:09:55 CEST 2007


On Apr 9, 2007, at 3:38 AM, JORDI PALET MARTINEZ wrote:
> I'm not sure if netflow is able to provide measures of different  
> type of
> transition mechanisms, for example Teredo, 6to4, etc. ? I think is  
> very
> important to know what transition mechanisms the people uses, and my
> experience is that the usage of Teredo is growing since Vista has been
> released.
>
> It may be better to do those measurements directly at the web sites  
> being
> hosted as dual stack ? Actually we are doing something similar, but  
> without
> having a specific IPv6 content, just on customers web sites.
>

I'd like to use netflow to gather some stats, but it's not going to  
be able to pull all the information I'm looking for. It will gain  
some info that we can't see from the server side though, which is why  
I plan on using it.

The plan is to use web server logs for the majority of the data  
gathering though, along with some tweaks to the OS to make it easier  
to track things like MTU, window size, packet loss, latency, etc.

I've updated the site (look towards the end) for more information  
about what we're doing with the data.

> I've included some preliminary stats about that in my last week  
> presentation
> at the MENOG
> (http://www.ripe.net/meetings/menog/presentations/ 
> cost_of_not_deploying_ipv6
> .pdf). They also show the % of users from each region (of course  
> this is
> biased depending on the contents).
>

That presentation was actually on my mind when writing some of this.  
You mention "some applications and services 'run only' or 'run  
better' with ISPs offering IPv6 services". However, our experience  
was the opposite.

When we first tried deploying IPv6, we thought we were going to be  
doing a service to the end users by doing so. Some non-technical  
users had IPv6 turned on without actually having IPv6 connectivity,  
and their browsers failed to do the right thing by falling back to  
IPv4. We got complaints from the small number of people who were  
using IPv6 that their connection to us over IPv6 was far worse than  
it was with IPv4, and they were disappointed that the only way they  
could fall back to IPv4 for substantially faster downloads was to  
turn off IPv6 completely. Maybe things are better now. Maybe we were  
doing something wrong. Maybe we just got unlucky. We didn't have the  
time to experiment like that on a production site though, so we're  
trying to see if the problems are still there. If so, I'd like to  
push the right people to fix those problems so that us content- 
provider people can begin using IPv6 without any down sides that we  
can't control.

> It will be also good to include many more tunnel brokers. We have  
> our own
> one and some others at different countries listed at
> http://www.ipv6tf.org/using/connectivity/test.php.
>
> Also, at http://www.ipv6day.org, you have many other TBs and detailed
> instructions for setting up IPv6 at many OSs, in different  
> languages, which
> may be linked to help users that want to try this.
>

Yes, the page that the end-users will see for this experiment will  
have a comprehensive list of tunnel brokers, HOWTO guides, list of  
ISPs with native IPv6, etc. We want to do everything but turn it on  
for them, and see how many are able to do so.


> We will be happy to provide some help if it is required.

Thanks! I know this is a slightly controversial subject/experiment,  
coming from someone that most of you don't know. My intent isn't to  
shame/blame anyone for problems that we've experienced in the past,  
my only goal is to document (in much better detail than we could on a  
high traffic production site) what problems we're experiencing, and  
let the community decide to how to correct/improve them.

-- Kevin




More information about the ipv6-ops mailing list