Curl with ipv6 not working by default

Question

I am trying to curl ipv6 addresses, but without success.

If I try lets say:

curl https://google.com

I wait for a timeout and get network unreachable

If I force ipv4, everything is fine.

curl -4 https://google.com

Then again if I force ipv6, like this:

curl -6 https://google.com

I get:

curl: (7) Failed to connect to 2800:3f0:4001:806::1005: Network is unreachable

I suppose it has to do somehow with resolving ipv6 addresses.

I saw that on other computers that have a newer version of some Linux distro, these requests go fine, so I'm guessing it has to do something with me using Ubuntu 10.10, where this problem isn't solved.

I want to be able to curl normally without using the option: -4, what do I have to modify to be able to use curl normally with ipv6 addresses?

Answer 1

It is not a problem with resolving IPv6 addresses. That name resolution is working fine because curl reports that it cannot reach network 2800:3f0:4001:806::1005; this shows that the name translation did succeed. This is different than an error in name lookup:

 $ curl -6 http://does.not.exist.foo.
 curl: (6) Couldn't resolve host 'does.not.exist.foo.'

In order to reach an IPv6 address, you need to have a route to the destination address and very few connections have any IPv6 connectivity at all. On the machine I'm writing this, I have almost no v6 routes at all:

$ route -A inet6
Kernel IPv6 routing table
Destination                    Next Hop                   Flag Met Ref Use If
fe80::/64                      ::                         U    256 0     0 wlan0
ff00::/8                       ::                         U    256 0     0 wlan0

which says you I know how to reach my local network and nothing more. Contrast this with my IPv4 routes

$ route -n 
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    0      0        0 wlan0
…

which shows I've got one very critical bit of routing information. I know how to get to anywhere that I don't have an explicit route to by handing the packet to my default router at 192.168.1.1.

Your name resolution is working just fine. You do need an IPv6 route to the destination network and too few places provide that facility yet.

Answer 2

Check your ifconfig output for lines that begin with inet6 addr. It is possible that your computer has a IPv6 address assigned that doesn't actually work, and that Linux is now trying to use this non-functional address instead of the working IPv4 address.

Answer 3

I have tried connecting to other networks and it worked.

In the mean time i updated my OS to MINT v15 and the problem still stayed.

Actually it even got weirder cause i could curl once, everything would be okay, than i would do it the second time and it would present the same old error.

At last i called my ISP and they set my modem to factory settings and updated the software.

Now everything seems to work fine.

Answer 4

This is an issue with curl, which has been fixed by the curl people, but many OS distributions package old versions. Basically if curl can find an ipv6 address for the domain in your URL, then it'll try to fetch it, and if that fails, curl fails, without falling back on trying the IPv4 address. You could argue whether that's a bug or not, but broken IPv6 installations are at least as common as working ones.

Here's my bug report for Ubuntu. (Up-votes welcome).

https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1457192

It'd be good to hear which other OS distributions/versions have this issue.

Possible fixes include:

• getting IPv6 working properly on your system.
• removing IPv6 from your system.
• getting a more recent version of curl installed (I don't know of any alternative repositories for this, so it's going to involve a source build)
• using a DNS server which is configured to not serve IPv6 info.

Answer 5

If anybody finds this on Google like I did, to fix the issue I just had to tweak my firewall rules for IPv6.

By default I'd blocked everything on the incoming chain - after I added rules to allow established connections, ping requests and anything from localhost IPv6 connections started working!

Answer 6

For me this odd behavior:

$ curl -6 localhost
curl: (6) Couldn't resolve host 'localhost'
$ host localhost
localhost has address 127.0.0.1
localhost has IPv6 address ::1
$  route -A inet6
/proc/net/ipv6_route: No such file or directory
INET6 (IPv6) not configured in this system.

So it turns out that the DNS server is responding with ::1 for "localhost" but the system itself doesn't "do" ipv6.

$ host -v localhost
Trying "localhost"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2162
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;localhost.         IN  A

;; ANSWER SECTION:
localhost.      604800  IN  A   127.0.0.1

;; AUTHORITY SECTION:
localhost.      604800  IN  NS  localhost.

;; ADDITIONAL SECTION:
localhost.      604800  IN  AAAA    ::1
Received 85 bytes from <my_dns_ip>#53 in 0 ms

So I guess host command is "like dig" and doing manual DNS queries which may or may not be usable/end up being used by the system, depending on what is configured/enabled. Go figure.