In message <[email protected]>, 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-server-over-tcp -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [email protected]
