Date: Mon, 9 Jul 2018 18:38:05 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: getaddrinfo(3) / AI_ADDRCONFIG On Mon, Jul 09, 2018 at 11:16:04AM -0400, Christopher Friedt wrote: > Hi list, > > I have a patch for getaddrinfo(3) so that AI_ADDRCONFIG is properly > supported. Currently, if user code passes in the aforementioned flag, > there is no check to see whether a non-loopback network interface is > configured with the specified (or unspecified) address family before > returning results, which is what getaddrinfo(3) should do according to > . > > As a result of the current behaviour, musl's getaddrinfo(3) would > return e.g. "::1" to user code even when no interfaces (including lo) > were configured with IPv6 addresses. I've documented this to some > extent here . > > Please see the patch at  for my fix. Any feedback is welcome. The > patch It applies against master and 1.1.19, but possibly other > releases. > > C > >  http://man7.org/linux/man-pages/man3/getaddrinfo.3.html >  https://issues.apache.org/jira/browse/THRIFT-4594 >  https://patch-diff.githubusercontent.com/raw/cfriedt/musl/pull/1 > https://patch-diff.githubusercontent.com/raw/cfriedt/musl/pull/1.diff AI_ADDRCONFIG was discussed in 2014 as part of the "Remaining tasks on resolver overhaul" thread: http://openwall.com/lists/musl/2014/06/02/1 The consensus at the time was that it should be left as-is, in accordance with "Current implementation of AI_ADDRCONFIG considered harmful" (re: glibc implementation): https://fedoraproject.org/wiki/QA/Networking/NameResolution/ADDRCONFIG POSIX does not clearly specify how "only if an IPv6 address is configured on the local system" is determined, but the glibc behavior of ignoring ::1 on lo seems clearly non-conforming. My assumption at the time was that ::1 would always be configured and available unless IPv6 support was omitted from the kernel, so that any test involving iteration of interfaces would be meaningless; at most probing ::1, or probably just trying socket(AF_INET6,...) would suffice to determine what to do. It's unclear to me (and I think to everyone) what an application actually wants when it uses AI_ADDRCONFIG. Neither knowing whether IPv6 is supported at all on the host, nor whether there happens to be *some* interface or non-lo interface with an IPv6 address (think: it might just be a private-network VPN), tells you anything about whether the IPv6 addresses for the particular hostname you're looking up with getaddrinfo is routable. The more likely thing an application might want is to request whichever result is routable, but THAT ALREADY HAPPENS without AI_ADDRCONFIG: the results are sorted such that 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. 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. 2. Implementing AI_ADDRCONFIG as detection for the case where IPv6 has been completely disabled at the kernel or container level. I'm not sure what option 2 entails if IPv6 is disabled at the container level but socket(AF_INET6,...) still succeeds, so we should perhaps look into that if you or other users feel strongly that AI_ADDRCONFIG should do something here. But it shouldn't involve any O(n) iteration of interfaces, allocation, or pulling in other heavy code. Rich
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.