Safari on IPv6 ?
ayourtch at cisco.com
Wed Feb 3 13:41:51 CET 2010
On Tue, 2 Feb 2010, Shane Kerr wrote:
> On 2010-02-02 14:13, Martin Millnert wrote:
>> On Tue, 2010-02-02 at 13:57 +0100, Shane Kerr wrote:
>>> As I understand it, Safari does the equivalent of:
>>> 1. DNS lookup
>>> 2. TCP connection
>>> 3. HTTP request
>>> In both IPv4 and IPv6 at the same time. Whichever gets to step #3
>>> first goes to completion "wins", and the other is canceled.
>>> Note that once the A and AAAA record are in the DNS cache, then you
>>> are really just looking at connecting on whichever TCP session opens
>> this might very well be their goal, but it doesn't seem to be what's
>> going on, since Ron showed us on Monday that the mDNSResponder just
>> shuts down the remaining queries (one lingering AAAA in the example),
>> after having received its first reply.
> Even when (if?) they fix mDNSResponder not to be horribly broken, you
> will still have non-deterministic behavior, depending on whether your
> IPv4 or IPv6 connection happens to be faster. FWIW, I think this is
> actually the right thing to do, much as it sucks for network engineers.
I agree this is the right thing to do from the user perspective - though
one thing that may help is making it more explicit in the
UI/documentation - i.e. indicating somewhere whether the connection was
made over IPv4 or IPv6, and, more importantly, *why*. Then this can give
actionable input to the network engineers as well.
>> In other words, the actual implementation, intended or not, is right now
>> that whoever accomplishes #1 first, may continue.
>> I would be more inclined to agree with that whoever performs #3 first
>> wins, than #1. DNS lookup speed says nothing definite about IPv4 vs
>> IPv6 network/routing topologies and round trip times.
> Well, #2. You really don't want to actually ask for the web page twice,
> because this can mean a lot of work for the web server if you've got a
> dynamic page, and is a bit unfriendly. Even Apple has limits as to how
> much they are willing to abuse the network to improve the user
> experience. ;)
In http://tools.ietf.org/html/draft-wing-http-new-tech we tried to strike
a balance between that and just deciding based on which of the DNS
response comes first. In the tests it was rather quickly converging to
either IPv4 or IPv6 - and then after a few initial attempts the client
would not need extra TCP connections. (Also, if the request is stopped at
the TCP level, with non-forking servers it would be a relatively small
overhead compared to full HTTP parsing).
More information about the ipv6-ops