Re: getaddrinfo(3) / AI_ADDRCONFIG

[Rich Felker <dalias@libc.org>]

On Tue, Jul 10, 2018 at 09:01:19PM -0400, Christopher Friedt wrote:
> On Tue, Jul 10, 2018 at 8:38 PM Rich Felker <dalias@libc.org> wrote:
> > Regardless of what's done on the musl side, I think it would make
> > sense for thrift to change its strategy for selecting an address to
> 
> Let's take thrift out of the equation and read the POSIX spec.
> Directrly from [1]:
> 
> "If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
> returned only if an IPv4 address is configured on the local system,
> and IPv6 addresses shall be returned only if an IPv6 address is
> configured on the local system."
> 
> There are precisely zero IPv6 addresses configured on the local
> system. There is precisely two IPv4 address configured on the local
> system (127.0.0.1, and 172.17.0.2 in this case).
> 
> Regardless of whether loopbacks are ignored, you are breaking POSIX
> spec with your current implementation. Period.

What you're asking for does not solve your problem, but does solve a
particular special case of it, which is why I asked if you're happy
with that and suggested that there's probably additional stuff to do
on your side. But I'm happy to put that aside and focus just on musl.

The patch you provided mimics the glibc behavior and does not give
results any more conformant than the current musl behavior; it's just
differently non-conformant. In particular it will wrongly suppress
IPv6 results when the only interfaces with v6 addresses are loopback.

With the current musl behavior, there is only a conformance question
at all if no-IPv6 (i.e. not even loopback) is a supported
configuration. It probably should be, since some embedded (and as you
mentioned now, container) users setup environments where v6 is not
supported.

Pulling in large amounts of additional code and O(n) runtime cost
(some container users have hundreds or even thousands of interfaces)
for AI_ADDRCONFIG is not an acceptable appproach to this, and I don't
think it gives meaningfully-better behavior than just probing
routability of ::1. Are you asking that "no IPv6 on loopback, but IPv6
present on other interfaces" be a supported configuration? Or
something else?

Rich