From the dualstack-is-fun department...

[Mike Leber]

My bad (I think),

I was having a little trouble following this thread and appear to 
mistaken the context of "HE tunnels".

So many IPv6 threads!!! It's awesome...  I'll go back my corner and lurk.

Mike.
ps. hahahahahaha whoops.

>
>
> On 3/1/11 10:04 AM, Cameron Byrne wrote:
>> I am not saying HE is bad in any way, i am just saying we need to go
>> real slow and be VERY grounded in reality.  The only way i can think
>> to do that is to add MUST NOT be on by default.  HE is a good
>> work-around *NOT A FIX* for broken connections.... and masking issues
>> is only ok for a short time if we are really going to follow-up and
>> fix it.  That said, lets wait for symptoms before applying the
>> tourniquet, and yes, HE is a tourniquet... but hopefully only cutting
>> off circulation on a per destination basis for a short amount of time.
>
> Injecting some reality into this conversation...
>
> The amount of native IPv6 traffic on our network far exceeds the 
> amount of traffic seen for 6to4, Teredo, statically routed 6in4, and 
> 6in4 tunnels with BGP capability, *combined*.
>
> Further, 6to4 and Teredo traffic *far exceeds* the traffic seen by our 
> statically routed 6in4 tunnel servers which exceeds the traffic seen 
> by the designated routers used to terminate 6in4 tunnels with BGP 
> capability.
>
> Anyway, the point was, the amount of IPv6 traffic on our network that 
> uses BGP IPv6 tunnel routers is miniscule by comparison to other IPv6 
> traffic sources (native or tunneled).  Just saying.  As always, we 
> highly recommend native IPv6.  The vast majority of the IPv6 BGP 
> sessions we have are native.
>
> In other news:
>
> With regards to latency of IPv6 vs IPv4, when testing to dual stacked 
> reverse DNS servers, in 782 cases out of 1300 IPv6 was faster than 
> IPv4 by more than 1 millisecond ( 
> http://bgp.he.net/ipv6-progress-report.cgi ).  I attribute this to the 
> IPv6 network guys not being locked into whatever suboptimal purchasing 
> policies that are enforced for their IPv4 transit purchases. ;)    
> I'll work on getting latency data for dual stacked web servers as 
> well, so we can see how widespread the "IPv6 often faster than IPv4" 
> phenomena is.
>
> Mike.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20110302/68f5f1b4/attachment-0001.html