Description of problem: Currently, when a hostname resolves to both ipv4 and ipv6 addresses, curl and firefox try the ipv6 address first. With current network hardware, this is less likely to work; until ipv6 functionality is more universal, the ipv4 address should be preferred. Many consumer-level routers (such as the two I have) seem to just drop ipv6 packets on the floor. RFC 3484 talks about configuring this preference in section 10.3. I could override it myself via gai.conf, but I doubt I am the only one for whom this is an issue. Version-Release number of selected component (if applicable): glibc-2.10.2-1.i686 How reproducible: Always Steps to Reproduce: 1. curl -v fedoraproject.org Actual results: * About to connect() to fedoraproject.org port 80 (#0) * Trying 2610:28:200:1::fed0:1... Timeout [after 1 minute wait] * Trying 66.35.62.162... connected Expected results: * About to connect() to fedoraproject.org port 80 (#0) * Trying 66.35.62.162... connected Additional info: curl-7.19.7-3.fc11.i586
Hmm, the gai.conf precedence lines from the man page adjusted as suggested in 10.3 of the RFC don't produce the desired result for me: precedence ::1/128 50 precedence ::/0 40 precedence 2002::/16 30 precedence ::/96 20 precedence ::ffff:0:0/96 100 and curl/firefox are still trying the ipv6 address first, even after a reboot. There's also a typo ("precendence") in those lines in the man page, but I get the same behavior with either spelling (or with no gai.conf).
What do you get from getent ahosts fedoraproject.org?
2610:28:200:1::fed0:1 STREAM fedoraproject.org 2610:28:200:1::fed0:1 DGRAM 2610:28:200:1::fed0:1 RAW 66.35.62.162 STREAM 66.35.62.162 DGRAM 66.35.62.162 RAW 80.239.156.214 STREAM 80.239.156.214 DGRAM 80.239.156.214 RAW 152.46.7.221 STREAM 152.46.7.221 DGRAM 152.46.7.221 RAW
You need to fix your network configuration, glibc is following RFC 3484.
Regardless of the default, surely gai.conf should work as documented? From /usr/share/doc/glibc-common*/gai.conf: # For sites which prefer IPv4 connections change the last line to # precedence ::ffff:0:0/96 100 ...but this doesn't work.
If you are behind a NAT you need to adjust the scope table so that your interface address is no longer classified as link-local. Otherwise a global scope address will never match.
I have no idea how to do that, and it seems rather unfortunate to require users in an extremely common situation (i.e. behind a consumer-level NAT router) to jump through so many hoops to get basic functionality to work properly.