Drop AI_ADDRCONFIG when resolving TCP addresses
authorMichael Stapelberg <michael@stapelberg.de>
Thu, 18 Aug 2011 19:38:28 +0000 (21:38 +0200)
committerJamey Sharp <jamey@minilop.net>
Thu, 18 Aug 2011 20:39:56 +0000 (13:39 -0700)
commit4f25ee16443b29e1a25bd26a724e1e0a577e21ff
treefb42a2c1326241c67e288ab3da76ff7c9842099e
parent662ad589c5d6f03757ae57a926d3800bfb528b30
Drop AI_ADDRCONFIG when resolving TCP addresses

When a system is completely offline (no interface has an IP address but 'lo'),
xcb could not connect to localhost via TCP, e.g. connections with
DISPLAY=127.0.0.1:0 fail.

AI_ADDRCONFIG will only return IPv4 addresses if the system has an IPv4
address configured (likewise for IPv6). This also takes place when
resolving localhost (or 127.0.0.0/8 or ::1). Also, as per RFC 3493,
loopback addresses are not considered as valid addresses when
determining whether to return IPv4 or IPv6 addresses.

As per mailing-list discussion on the xcb list started with message
20110813215405.5818a0c1@x200, the AI_ADDRCONFIG flag is there for historical
reasons:

    In the old days, the "default on-link" assumption in IPv6 made the flag vey
    much indispensable for dual-stack hosts on IPv4-only networks. Without it,
    there would be long timeouts trying non-existent IPv6 connectivity. Nowadays,
    this assumption has been flagged as historic bad practice by IETF, and hosts
    should have been updated to not make it anymore.

    Then AI_ADDRCONFIG became mostly cosmetic: it avoids phony "Protocol family
    not supported" or "Host unreachable" errors while trying to connect to a dual-
    stack mode from a host with no support for source address selection.

    Nowadays, on up-to-date systems, this flag is completely useless. Then again,
    I understood only the very latest MacOS release is "up-to-date" with this
    definition.
src/xcb_util.c