276

The ISP I work at is setting up an internal IPv6 network in preparation for eventually connecting to the IPv6 internet. As a result, several of the servers in this network now 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 I'm downloading updates of any sort.

Is there a way to tell apt to either prefer IPv4 or ignore IPv6 altogether?

5
  • 3
    Shouldn't that return immediately with a routing failure?
    – pjc50
    Mar 23, 2011 at 11:46
  • 8
    No, it's entirely possible that their internal network has routing between multiple subnets (and hosts have an IPv6 default gateway) but no IPv6 connectivity to the outside world.
    – nobody
    Mar 23, 2011 at 13:51
  • 5
    There's probably a way to set up /etc/gai.conf so that security.debian.org's A record are returned before the AAA record, but I don't know precisely what to put in that file. Mar 24, 2011 at 0:10
  • 3
    @AndrewMedico - but shouldn't their network's default gateways know that there isn't external ipV6 connectivity and reject the outbound attempt at the edge pretty quickly? I think there's a network issue here as well as the question being asked. Nov 12, 2013 at 13:21
  • 8
    Fixing the edge router/firewall/whatever is causing the problem is the "best" way to handle this. It should be returning an ICMP destination unreachable packet. This is either not happening, or something is blocking it. Either way, the problem should be reported to your network people. Apr 9, 2014 at 22:25

8 Answers 8

368

Add -o Acquire::ForceIPv4=true when running apt-get.

If you want to make the setting persistent just create /etc/apt/apt.conf.d/99force-ipv4 and put Acquire::ForceIPv4 "true"; in it:

echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

Config options Acquire::ForceIPv4 and Acquire::ForceIPv6 were added to version 0.9.7.9~exp1 (see bug 611891) which is available since Ubuntu Saucy (released in October 2013) and Debian Jessie (released in April 2015).

9
  • 8
    Moving the "accepted" to this one; while the original 30-point answer is perfectly correct, it's applicable on a much broader scale while this provides the option to just restrict apt-get.
    – Shadur
    Nov 12, 2013 at 18:21
  • Please be properly descriptive in your answer. -o Acquire::ForceIPv4=true is the addition to the command to allow a user to use ipv4
    – Kendrick
    May 23, 2014 at 1:42
  • Answer updated following Kendrick's suggestion
    – mmoya
    May 23, 2014 at 8:02
  • 1
    Judging from the rest of my apt.conf you need to write it like this: Acquire::ForceIPv4 "true"; (with double quotes)
    – mirabilos
    Dec 13, 2014 at 15:09
  • 8
    @ZAB because if you don't have write access to the file, sudo echo 'test' > file wouldn't work because the redirection is executed with the user permissions
    – LeartS
    Sep 30, 2016 at 9:54
94

As Gilles says, use gai.conf. Notes:

  1. This works at a much lower level (DNS and IP networking) than APT, so it will change how all your applications network--at least, all that use getaddrinfo.
  2. Before editing your gai.conf, you should back it up, and also read it (don't worry, it's short). The edits below are probably already mentioned in your current file; if the current file indicates something different from what's mentioned below, you should probably prefer what's in your current file.

But if this is what you want (which it probably is), let's proceed. Say we have two hosts www.he.net and www.ripe.net :

$ host www.he.net
www.he.net is an alias for he.net.
he.net has address 216.218.186.2
he.net has IPv6 address 2001:470:0:76::2

$ host www.ripe.net
www.ripe.net has address 193.0.6.139
www.ripe.net has IPv6 address 2001:67c:2e8:22::c100:68b

Case 1: prefer IPV4 for all hosts

Append to /etc/gai.conf the following line:

precedence ::ffff:0:0/96  100

After saving the edited file (no need to restart), you should see networking apps (e.g., telnet) using IPV4: e.g.,

$ telnet www.ripe.net 81
Trying 193.0.6.139...
^C
$ telnet www.he.net 81
Trying 216.218.186.2...

Case 2: prefer IPV6 for specific hosts

If we want to prefer IPV6 only for www.he.net or its network, we can append a mask/prefix for all, or just some part, of its IPV6 address to /etc/gai.conf. E.g., the following line:

precedence 2001:470::/32 100

(after saving the edited file) produces

$ telnet www.ripe.net 81
Trying 193.0.6.139...
^C
$ telnet www.he.net 81
Trying 2001:470:0:76::2...
^C

Case 3: prefer IPV4 for specific hosts

If we invert the mask will the reverse be true? According to @GrueMaster, appending

precedence 2001:470::/96 100

worked for him after disabling IPV6 for security.ubuntu.com (otherwise it stalls forever).


See also:

3
  • Perhaps summarize content in case the above links disappear? May 16, 2011 at 15:04
  • So, what's the syntax to disable IPv6 for a particular name, or at least for a particular address (range)? If you add that to your post, it'll be the best answer here. May 16, 2011 at 16:16
  • Thanks. I added 2 lines #security.debian.org has IPv6 address 2610:148:1f10:3::73 \n #security.debian.org has IPv6 address 2001:4f8:8:36::6 \n precedence 2001:4f8::/96 100 \n precedence 2610:148::/96 100 to my /etc/gai.conf and apt-get update works perfect now.
    – don bright
    Jun 1, 2015 at 0:49
11

You could setup apt-cacher-ng on a spare machine to act as a proxy/cache for all of your hosts. You can force the configuration to only use specific hosts or use the /etc/hosts trick suggested by @badp on that one machine.

apt-get install apt-cacher-ng

Once you have apt-cache-ng setup you just need to drop the following line (with IP address/hostname altered to point at your cacher machine) in /etc/apt/apt.conf.d/90httpproxy

Acquire::http { Proxy "http://[192.168.1.254]:3142"; };

I use that setup to reduce bandwidth usage but it should workaround your problem. Unfortunately I'm not aware of a way to directly disable ipv6 lookups for apt-get itself.

1
  • Still not a perfect solution, but as good as it's likely going to get. Thanks.
    – Shadur
    Mar 24, 2011 at 10:49
5

You could work around this by setting up a DNS proxy server that dropped ip6 responses.

3
  • Won't your local resolver still try to get the AAAA record? And time out?
    – Mikel
    May 15, 2012 at 14:32
  • That is not a thing I want to even consider doing.
    – Shadur
    Dec 11, 2021 at 11:37
  • .. this question is a decade old, did you ever solve the problem? Or deploy ip6?
    – pjc50
    Dec 11, 2021 at 22:00
5

How about adding a line in /etc/hosts overriding the relevant addresses? e.g.,

130.89.149.226  ftp.debian.org      
195.20.242.89   security.debian.org 
2
  • 14
    I'll save this solution for last if there turns out to be absolutely no other way; I really don't like cluttering /etc/hosts with IP addresses I don't own myself.
    – Shadur
    Mar 23, 2011 at 11:34
  • @Shadur Yes, I can totally see your point :)
    – badp
    Mar 23, 2011 at 12:49
2

As of Oct 08th 2014, I had the same issue, trying to update debian behind a proxy on local network. In the hope it will be relevant to others, I post my response here. As others have mentioned, editing /etc/hosts is something one should be careful with.

But personally I just wanted to have the update done.

Content of /etc/apt/sources.list when doing the update (it was different before the update..):

deb http://http.debian.net/debian/ testing main
deb-src http://http.debian.net/debian/ testing main

deb http://mirrors.kernel.org/debian/ wheezy main
deb-src http://mirrors.kernel.org/debian/ wheezy main

deb http://security.debian.org/ wheezy/updates main
deb-src http://security.debian.org/ wheezy/updates main

Content of /etc/apt/apt.conf:

Acquire::http::proxy "http://192.168.1.10:7777/";
Acquire::http::Timeout "10";
Acquire::ftp::Timeout "10";

Addition to /etc/hosts:

#Workaround for making apt-get work (08-10-2014)
195.20.242.89 security.debian.org
130.89.148.12 ftp.debian.org

Now, running apt-get update ; apt-get upgrade as root worked well.

As mentioned in other answers, use, run host command on the domain to get the correct ip to insert in the hosts file.

Example:

$ host ftp.debian.org
ftp.debian.org has address 130.89.148.12

This successfully updated the system to Debian GNU/Linux testing (jessie). You might not want to run with the testing repositories, then simply remove it from the sources. The testing repositories gives you more recent updates of several packages, but is not considered stable.

1
  • Again, modifying the hosts file is a highly suboptimal solution.
    – Shadur
    Sep 27, 2017 at 9:07
1

Hijacking old topic, but faced with the same problem recently. So, based on the advice given above and the output of host and whois:

# host security.debian.org
security.debian.org has address 212.211.132.250
security.debian.org has address 195.20.242.89
security.debian.org has address 212.211.132.32
security.debian.org has IPv6 address 2001:8d8:580:400:6564:a62:0:2
security.debian.org has IPv6 address 2001:a78:5:0:216:35ff:fe7f:be4f
security.debian.org has IPv6 address 2001:a78:5:1:216:35ff:fe7f:6ceb

Solved problem in a slightly different way - lowered the precedence of the IPv6 networks which contain security.debian.org in /etc/gai.conf:

# Make IPv6 for security.debian.org undesirable
precedence 2001:8d8:580::/48    5
precedence 2001:a78:5::/48      5

So, IPv6 is still preferred except for security.debian.org.

-2

I have found a much better way to do this. Open up your sources.list file and note down the hostnames of the repos. Get their IPv4 addresses, then edit sources.list with the IPv4 addresses rather than the hostnames. Apt-get should now contact the repositories over the IPv4 addresses you specified, bypassing IPv6.

There is the disadvantage that repos usually have some sort of load balancing and/or IP geolocation set up, which this method of course bypasses. However, it shouldn't matter if only a few people are doing it. If you do find one mirror is slow, try getting another repo IP address (for instance, by using an online ping service) and use that.

1
  • 3
    That's a really bad solution, actually, for the reasons you already describe.
    – Shadur
    Apr 18, 2013 at 4:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .