On 2026-09-08 16:21:10 +0000, Andy Smith wrote:
> On Tue, Sep 08, 2026 at 05:40:35AM +0200, Vincent Lefevre wrote:
> > On a machine without IPv6 support (IPv6 disabled in the kernel,
> > and no IPv6 addresses), how to prevent programs from using IPv6
> > by default?
>
> In Linux, programs do not try to use IPv6 unless the system has at least
> one global scope IPv6 address. Since IPv6 has been in the Linux kernel
> for decades, if this mechanism were faulty, we would be inundated with
> problem reports all day every day.
Actually some of them do, but probably due to another issue: it now
becomes clear that due to a bug affecting getaddrinfo (see below),
they think that the target host has no IPv4 addresses; they only get
an IPv6 address, and they try to use it.
> It should not be required to do gross hacks like messing with gai.conf
> or hacking your DNS resolver to not return AAAA records. The default
> gai.conf is fine for systems that don't have IPv6, and it is normal to
> see AAAA responses in DNS.
>
> I haven't seen anywhere in this thread that you have shown us the output
> of
>
> $ ip address show
I said that there are no IPv6 addresses. But you can see:
citron:~> ip address show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether 24:6e:96:16:b5:6c brd ff:ff:ff:ff:ff:ff
altname eno3
altname enp7s0f0
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether 24:6e:96:16:b5:6d brd ff:ff:ff:ff:ff:ff
altname eno4
altname enp7s0f1
inet 140.77.12.21/23 metric 1024 brd 140.77.13.255 scope global dynamic eth1
valid_lft 68205sec preferred_lft 68205sec
4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group
default qlen 1000
link/ether 24:6e:96:16:b5:68 brd ff:ff:ff:ff:ff:ff
altname eno1
altname enp1s0f0
inet 140.77.14.52/24 metric 1024 brd 140.77.14.255 scope global dynamic eth2
valid_lft 25009sec preferred_lft 25009sec
5: eth3: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group
default qlen 1000
link/ether 24:6e:96:16:b5:6a brd ff:ff:ff:ff:ff:ff
altname eno2
altname enp1s0f1
> to show us all addresses on your system. It's possible I missed it, and
> if so I apologise. Either way, please could you check it again to see if
> there are any global scope IPv6 addresses there.
>
> The issue is that either your system is broken in some bizarre and
> rarely seen way, or else there is an IPv6 address there that you weren't
> expecting.
getaddrinfo is broken. I recall:
Family: AF_UNSPEC
[IPv6] IP: 2001:4b99:1:3:216:3eff:fe20:ac98 (Port: 80)
Family: AF_INET
[IPv4] IP: 155.133.131.76 (Port: 80)
Family: AF_INET6
[IPv6] IP: 2001:4b99:1:3:216:3eff:fe20:ac98 (Port: 80)
The call with AF_INET shows that there is an IPv4 address.
But it is not given by the call with AF_UNSPEC.
According to some sources, calls with AF_INET are not cached
(though I could not check), contrary to AF_UNSPEC. And according
to
https://sourceware.org/bugzilla/show_bug.cgi?id=27929
glibc's stub resolver treats SERVFAIL (which I get intermittently for
new hosts or hosts with expired TTL) as NODATA as long as there is
another IP address (IPv4 or IPv6). And the result seems to be that
SERVFAIL, seen as NODATA, is cached by nscd at least for AF_UNSPEC
(so the failure becomes permanent for a few hours).
> Note that IPv6 addresses can be acquired in several ways
> without your positive action, e.g. router advertisements and DHCP.
IPv6 got disabled in the kernel, so this should be ignored.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
