I found an issue with libcurl when both IPv6 and c-ares support is
enabled. I think I understand what's going on, but please correct me
if I'm wrong.

When c-ares isn't enabled, libcurl by default calls getaddrinfo with
family set to PF_UNSPEC which causes getaddrinfo to return all
available addresses, both IPv4 and IPv6. Libcurl then tries each one
until it can connect. If the net connection doesn't support IPv6,
libcurl can still fall back to IPv4.

However, since c-ares doesn't support PF_UNSPEC, when it's used it
defaults to using family=PF_INET6 and therefore only returns IPv6
addresses when AAAA records are available, even if IPv4 addresses are
also available. The effect is that since my ISP doesn't do IPv6,
libcurl can't connect at all to a site that has AAAA records. It will
work if I explicitly use CURL_IPRESOLVE_V4 or --ipv4 with the curl
tool. I discovered this when curl would fail to connect to seemingly
random sites. It turns out they weren't random, they were sites with
AAAA records.

The relevant code is from Curl_getaddrinfo in hostares.c:

   switch(data->set.ip_version) {
   case CURL_IPRESOLVE_V4:
     family = PF_INET;
     break;
   default: /* by default we try ipv6, as PF_UNSPEC isn't supported by
(c-)ares */
   case CURL_IPRESOLVE_V6:
     family = PF_INET6;
     break;
   }

Maybe it would be safer to default to PF_INET instead? That's what I
did locally, by deleting the "default:" line. That way one can still
explicitly ask for IPv6, but IPv4 will be used normally. Ultimately, c-
ares should probably be enhanced to better match the behavior of
getaddrinfo, but I'm already a bit over my head here. :)

Daniel
Received on 2008-10-09