[140424] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Yahoo and IPv6

daemon@ATHENA.MIT.EDU (Iljitsch van Beijnum)
Wed May 11 04:53:55 2011

From: Iljitsch van Beijnum <iljitsch@muada.com>
In-Reply-To: <1305074385.18376.566.camel@karl>
Date: Wed, 11 May 2011 10:53:00 +0200
To: Karl Auer <kauer@biplane.com.au>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org

On 11 mei 2011, at 2:39, Karl Auer wrote:

> On Wed, 2011-05-11 at 10:19 +1000, Mark Andrews wrote:
>> For the record Apple's current iChat (the OS (10.6.7) is completely
>> up to date) fails such a test.  It will try IPv6 and not fallback
>> to IPv4.  End users shouldn't be seeing these sorts of errors.

Hm, I've had a very hard time finding any IPv6-capable servers to let my =
iChat talk to...

> Is that possibly a failure of the underlying resolver library? Do =
other
> applications on the same platform behave correctly?

Apple's Mail application used to do this, but after many years they =
fixed this, it will now fall back to IPv4 without trouble. This isn't a =
resolver issue, as the resolver can't know whether IPv6 connectivity =
does or doesn't work. The resolver simply gives applications that don't =
explicitly ask for a particular address type all of the addresses of all =
types for which the system currently has connectivity, I think as =
determined by the presence of a default route, maybe the presence of an =
address also matters.

What applications need to do when they connect to a remote server is to =
try the next address when the first one fails and cycle through all =
addresses before giving up. Of course with IPv4 having multiple =
addresses is extremely rare so IPv4 applications typically don't bother =
with this, so it has to be addressed when IPv6ifying applications.=


home help back first fref pref prev next nref lref last post