In message <03C70CDE-8169-437B-8394-26F839413893@muada.com>, Iljitsch van Beijn um writes:
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...
Well I found this bug because the jabber server was IPv4 only and the box it is on got a AAAA address. The jabber server is now running dual stack with the IPv6 ports being forwarded to the IPv4 ports. It's not optimal but it works.
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.=
This is basic RFC 1123 multihome support. Also see https://www.isc.org/community/blog/201101/how-to-connect-to-a-multi-homed-se... -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org