On killing IPv6 transition mechanisms
gert at space.net
Tue Mar 16 11:05:17 CET 2010
On Tue, Mar 16, 2010 at 06:38:24PM +0900, Erik Kline wrote:
> > So I'd like to see these 150ms qualified - in this discussion, it seems
> > to be the assumption that "IPv6 will *always* be 150ms slower", which
> > is most definitely not the case.
> Things definitely improved a bit (brought the average extra latency
> down to between 50 and 100 msec) when we started getting a different
> 2002::/16 at one point, IIRC.
So this extra latency is only for 6to4 clients?
Now that doesn't me surprise at all :-) - but it's actually not that bad
at the end. Operating systems with working policy tables[*] will not(!)
use 6to4 if a target site is dual-stacked, and native IPv4 connectivity
exists - so you only see the extra latency if you go to a v6-only site
(or have v6-only testing pixels on your web site).
[*] with the exception of broken clients that bypass OS policy tables,
see the list archives for the affected Opera 10 versions
Total number of prefixes smaller than registry allocations: 150584
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 306 bytes
Desc: not available
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20100316/daf1cf16/attachment.bin
More information about the ipv6-ops