nanog at daork.net
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.
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
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.
More information about the NANOG