From the dualstack-is-fun department...

[Mike Leber]

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: <https://lists.cluenet.de/pipermail/ipv6-ops/attachments/20110302/efd66f33/attachment.htm>