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