IPv6 Wow

Mon Oct 13 06:34:31 UTC 2008

On 13/10/2008, at 7:24 PM, Mikael Abrahamsson wrote:
> On Sun, 12 Oct 2008, Daniel Senie wrote:
>
>> I do wonder whether where the Vista machines on public IPs really  
>> are. I also have to wonder if performance is really better when  
>> those users are routed over 6to4 in Europe from, say California, or  
>> whether they'd actually get better performance if they stuck in a  
>> NAT box, resulting in their using IPv4 instead?
>
> I'd say it's very rare where IPv6 will give you better performance  
> than IPv4 right now.
>
> Regarding where they are, I'd say all over the place. It's very  
> common in my regional market to hand out one or more public IPs, and  
> if the customer doesn't put their own NAT box there, then their  
> Vista computer(s) will have public IPs and will use 6to4.
>
> Regarding 6to4 or Teredo, I've done some testing of my own and the  
> statelessness of 6to4 makes it avoid some of the session setup/NAT  
> travesal magic of Teredo that slows Teredo down. I'd much rather see  
> the NAT boxes do 6to4 and run native on their local LAN segment,  
> than having end hosts do Teredo to get thru the NAT. It'll give the  
> end user a better IPv6 experience.

Long term I agree, but short term I prefer Teredo for regular end  
users' experience. Where regular end user means an end user  
communicates with a relatively small number of remote hosts.

Several reasons:
1) 6to4 currently lacks a testing mechanism to ensure that it is  
functioning at startup, and that it is still functioning. Packets are  
sent and blackholed by the network, resulting in a 90s timeout waiting  
for a response to the three SYN packets in a TCP connection set up.  
90s is a long time for users today, and my experience shows that they  
consider a service to be 'broken' before they wait for the timeout to  
expire.
2) If Teredo relays are deployed close to the service (ie. content,  
etc.) then performance is almost equivalent to IPv4. 6to4 relies on  
relays being close to both the client and the server, which requires  
end users' ISPs to build at least *some* IPv6 infrastructure, maintain  
transit, etc. When you consider that this infrastructure and transit  
is quite likely to be over long tunnels to weird parts of the world,  
this is a bad thing. Putting relays close to the content helps for the  
reverse path (ie. content -> client), however the forward path (client  
-> content) is likely to perform poorly.

--
Nathan Ward