From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13017 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: getaddrinfo(3) / AI_ADDRCONFIG Date: Tue, 10 Jul 2018 21:26:40 -0400 Message-ID: <20180711012640.GW1392@brightrain.aerifal.cx> References: <20180709223805.GS1392@brightrain.aerifal.cx> <20180710005943.GT1392@brightrain.aerifal.cx> <20180710150854.GU1392@brightrain.aerifal.cx> <20180711003816.GV1392@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1531272291 25409 195.159.176.226 (11 Jul 2018 01:24:51 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 11 Jul 2018 01:24:51 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13033-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jul 11 03:24:47 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1fd3s5-0006U6-LK for gllmg-musl@m.gmane.org; Wed, 11 Jul 2018 03:24:45 +0200 Original-Received: (qmail 22055 invoked by uid 550); 11 Jul 2018 01:26:53 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 22034 invoked from network); 11 Jul 2018 01:26:52 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13017 Archived-At: On Tue, Jul 10, 2018 at 09:01:19PM -0400, Christopher Friedt wrote: > On Tue, Jul 10, 2018 at 8:38 PM Rich Felker 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