Tore Anderson <[email protected]> writes: > Hm, from a very quick glance at the getaddrinfo() calls in the ntpd > directory of the source tree it seems none of them are passing in the > AI_ADDRCONFIG hint. That's the one that prevents getaddrinfo() from > returning "unusable" addresses (i.e., no IPv6 addresses if the node is > IPv4-only and vice versa).
AI_ADDRCONFIG is useless in all but a tiny minority of cases. Most *nix systems today are on IPv4-only networks but have autoconfigured link-local IPv6 addresses on all interfaces. The converse (a system on a pure IPv6 network having useless IPv4 addresses) is probably less common but not unthinkable. For instance, a laptop or desktop computer on an IPv6-only network might correctly discover its IPv6 address through SLAAC but still attempt DHCP for IPv4 and end up with a 169.254 address. At the University of Oslo, we have a large cluster that uses routable IPv6 addresses but also has RFC1918 addresses for internal communication with software that does not understand IPv6 (including software from a major player in the Linux arena that crashes if it sees an IPv6 address in /etc/resolv.conf, which the vendor told us they *might* fix in the next version... three years ago). What it boils down to is that, in the overwhelming majority of cases, *the only way to find out what will work is to try it*. /This message was brought to you by "google python lbyl eafp". Thank you for reading, and have a nice day./ DES -- Dag-Erling Smørgrav - [email protected] _______________________________________________ pool mailing list [email protected] http://lists.ntp.org/listinfo/pool
