Recently I installed a Debian 7 VPS on Linode and as first thing I wanted to do an update of the system, but I found a small problem in doing this :
# apt-get update 0% [Connecting to ftp.us.debian.org (2610:148:1f10:3::89)] [Connecting to security.debian.org (2607:ea00:101:3c0b:207:e9ff:fe00:e595)] Get:1 http://ftp.us.debian.org wheezy Release.gpg [1,672 B] ... Get:15 http://security.debian.org wheezy/updates/main Translation-en [56.6 kB] Fetched 16.3 MB in <strong>4min 0s</strong> (67.5 kB/s) Reading package lists... Done |
So 4 minutes to just update my repositories (and I had just the default for a Debian 7 just installed), this is due to the fact that linode VPS are IPV6 ready and so the servers of this company try to connect to security.debian.org via its IPv6 address by default when running apt-get update, and that results in having to wait for a lengthy timeout whenever you try to download updates of any sort.
But luckily change the system so apt-get will use IPV4 it’s not so hard.
Let’s say that we have the server name security.debian.org these are all the IPs associated with that name on the DNS:
# host security.debian.org security.debian.org has address 128.101.240.212 security.debian.org has address 149.20.20.6 security.debian.org has address 128.31.0.36 security.debian.org has IPv6 address 2607:ea00:101:3c0b:207:e9ff:fe00:e595 security.debian.org has IPv6 address 2001:4f8:8:36::6 security.debian.org mail is handled by 10 chopin.debian.org. |
As you can see this name has both ipv4 and ipv6 addresses, to check which address are you using by default you can use the telnet command on port 80 (http)
# telnet security.debian.org 80 Trying 2607:ea00:101:3c0b:207:e9ff:fe00:e595... |
What we want to do now it’s tell to apt-get to use as precedence the ipv4 address, and to do this you can change the file /etc/gai.conf, from it’s man page:
NAME
gai.conf - getaddrinfo(3) configuration file
DESCRIPTION
A call to getaddrinfo(3) might return multiple answers. According to RFC 3484 these answers must be sorted so that the answer with the highest success rate is
first in the list. The RFC provides an algorithm for the sorting. The static rules are not always adequate, though. For this reason the RFC also requires
that system administrators get the chance to dynamically change the sorting. For the glibc implementation this can be achieved with the /etc/gai.conf file. |
Now to make it shorter I’ll tell you that you have to add at the bottom of the file /etc/gai.conf this directive:
precedence ::ffff:0:0/96 100 |
And to test that everything is working as expected use the telnet command once again:
root@li419-225:~# telnet security.debian.org 80 Trying 128.31.0.36... |
As you can see the system it’s now using the ipv4 ip to connect to the website security.debian.org.
Congratulations now your VPS will prefer IPV4, if you now use apt-get commands you’ll see a much faster answer and no timeout at all.
Once that you want to restore the default (IPV6 as first choice), you just have to remove that line and everything will work with IPV6.
Reference:
Popular Posts:
- None Found
This is sad but a good workaround. I think someone should make sure that it works with IPv6 🙂
I had the same problem on one of my virtual machines running Ubuntu 12.04 LTS (hosted by a different VPS provider).
The real problem was that the host had “IPv6 Privacy Extensions” enabled. This tries to give you randomly generated IPv6 addresses. The randomly generated addresses did however not have any internet connectivity, so trying to reach any host from them, or reaching those randomly generated IPv6 addresses always failed.
You can easily check how many IPv6 addresses your host is reporting at the moment with the command:
ip -6 address show eth0
Most hosting providers only give you one public IPv6 address, thus you should most likely only have one row with a public IPv6 address. Please note that addresses fe80::/64 are link local addresses.
In my case I saw a lot of IPv6 addresses and tried to ping6 them all from another host, and the ping6 failed for each except the “real one” that was set up by my VPS provider.
Alternatively, you can check if you have the privacy extension enabled by checking the output of
cat /proc/sys/net/ipv6/conf/all/use_tempaddr
The values are:
0 - don’t use privacy extensions.
1 - generate privacy addresses
2 - prefer privacy addresses and use them over the normal addresses.
In Ubuntu, I found that the easiest way to get rid of the randomly generated IPv6 addresses was to just remove the file /etc/sysctl.d/10-ipv6-privacy.conf, that was actually how the VPS provider had set it up on the other virtual machine, that was running problem free. I preferred to reboot the machine to see it was working as expected after a reboot, but you should be able to just restart your networking or disable the privacy extension on the fly (google for “use_tempaddr”).
The main two configs that have to be changed is to set number 2 to 0 in the lines:
net.ipv6.conf.all.use_tempaddr = 2
net.ipv6.conf.default.use_tempaddr = 2
But as I said, on Ubuntu the easiest way is just to remove the file /etc/sysctl.d/10-ipv6-privacy.conf
Worked like a charm for me, including retrieving bug reports (apt-listbugs). The following tip did not work when retrieving bug reports.
https://askubuntu.com/questions/759524/problem-with-ipv6-sudo-apt-get-update-upgrade
Also, shoutout to Linuxaria for not requiring a login just to comment. You guys and gals rock!