Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 9 Jul 2018 20:59:43 -0400
From: Rich Felker <>
Subject: Re: getaddrinfo(3) / AI_ADDRCONFIG

On Mon, Jul 09, 2018 at 08:11:48PM -0400, Christopher Friedt wrote:
> > getaddrinfo is routable. The more likely thing an application might
> > want is to request whichever result is routable
> ^^
> > want is to request whichever result is routable, but THAT ALREADY
> > HAPPENS without AI_ADDRCONFIG: the results are sorted such that
> In fact IT DOES NOT ALREADY HAPPEN. Musl's getaddrinfo does not
> provide a routable socket at all in the example I provided. In fact,
> there are exactly zero network interfaces with an IPv6 address in this
> case, but somehow musl comes back with "::1" for localhost, which is
> more damaging than useful in this use case. You could almost say that
> musl is currently also non-conformant in that sense.
> > routable ones come before non-routable ones, so if you try them in
> > order, you'll never hit a non-routable address family unless all the
> > results for the other family fail to be reachable.
> Want proof? Download the tarball I provided here:
> [...]
> So there you have it. A use case with a demonstrated bug and fix that
> is 100% reproducible.

Can you provide a minimized test case (short single C source file) to
reproduce this, or an strace log of the test that fails? The latter is
probably actually be better if the behavior is dependent on the Docker
network configuration. Assuming the test is attempting to lookup and
bind on "localhost" by name, which is what it appears to be doing

the behavior you're experiencing is not what I expect from musl;
rather my expectation is that you would get as the first
result and ::1 as the second, and this is exactly what I see if I do:

ip addr del ::1 dev lo

on my laptop running Alpine, then call getaddrinfo for localhost with
a small test program.

The logic to sort results does gratuitously depend on v4mapped
addresses working to do the IPv4 routability probing; if something
about the configuration suppresses their ability to work, it will
break. This is a known open issue I want to go back and fix. Seeing
the strace would show me right away if it's the source of your
problem, and even if not chances are very good that it would point out
whatever the cause is.

> > So at this point my leaning is somewhere between:
> >
> > 1. Saying it's 2018 and having a system without IPv6 support (at least
> >    ::1) is an unsupported configuration.
> That's a slippery-slope argument. Just because a system supports IPv6
> does not imply that a network interface needs to be configured with an
> IPv6 address. As an example, my lame cable ISP does not route IPv6
> traffic nor does it provide an IPv6 prefix.

Right. But unless you actively suppress it you'll have ::1 and
link-local IPv6 addresses, which would cause AI_ADDRCONFIG to produce
IPv6 results.

> They are IPv4-only (you
> may think I live in the dark ages). Therefore, it does not even make
> sense for the average customer to configure IPv6 on their LAN. Does my
> OS support IPv6? Of course. ... Did I bypass them with a 6in4 tunnel -
> you can be damn sure ;-) But many people wouldn't bother with that.
> > 2. Implementing AI_ADDRCONFIG as detection for the case where IPv6 has
> >    been completely disabled at the kernel or container level.
> That's not at all the case here.
> 3. Where a user's OS supports IPv6 but they have simply opted not to
> assign an IPv6 address to their network interface or use a link-local
> address.

AI_ADDRCONFIG is not designed to help you here, but getaddrinfo
already does help you (with or without passing that flag) by sorting
results by routability.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.