From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4315 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: IPv4 and IPv6 addresses in resolv.conf Date: Sat, 30 Nov 2013 12:42:58 -0500 Message-ID: <20131130174258.GT24286@brightrain.aerifal.cx> References: <20131130031744.GM24286@brightrain.aerifal.cx> <20131130035116.GO24286@brightrain.aerifal.cx> <20131130035912.GP24286@brightrain.aerifal.cx> <20131130170112.GR24286@brightrain.aerifal.cx> <20131130173026.GS24286@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1385833385 394 80.91.229.3 (30 Nov 2013 17:43:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Nov 2013 17:43:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4319-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 30 18:43:10 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1VmoZS-00082I-Pl for gllmg-musl@plane.gmane.org; Sat, 30 Nov 2013 18:43:10 +0100 Original-Received: (qmail 28343 invoked by uid 550); 30 Nov 2013 17:43:10 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28335 invoked from network); 30 Nov 2013 17:43:09 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4315 Archived-At: On Sat, Nov 30, 2013 at 05:33:35PM +0000, Rob wrote: > Rich Felker, Sat, 30 Nov 2013: > >> > >>It is EAFNOSUPPORT if no kernel support at all. > >> > >>Actually I don't think there can be any cases where sending to the > >>v4-mapped address (ie ::ffff:1.2.3.4) can fail where an ipv4 socket > >>will succeed because those are basically ipv4 sockets with just ipv6 > >>notation, those addresses can't be routed by the ipv6 stack. So it > > > >One thing I'm confused about is the addresses on the actual packets. > >If we've already called bind for address :: and gotten assigned port > >N, does this also reserve port N on 0.0.0.0, which will be needed when > >sending from (and receiving back) IPv4 packets? Also, is there some > >kernel option we might need to worry about that prevents :: from > >receiving packets sent to IPv4 addresses, or does that only apply to > >TCP, not UDP? > > I've been seeing this output consistently from mpd at startup: > > listen: bind to '0.0.0.0:6600' failed: Address already in use > (continuing anyway, because binding to '[::]:6600' succeeded) > > mpd is the only program on my machine that binds to 6600 so it would > appear that :: port bindings reserve the ipv4 port too. Could be a > kernel configuration option though... It looks like this depends on the value of the socket option IPV6_V6ONLY, which on Linux gets its default from /proc/sys/net/ipv6/bindv6only, which in turn is 0 (off) by default. So on systems with non-default configuration, the proposed musl strategy could badly break use of v4 nameservers (in a mixed environment). I think manually setting IPV6_V6ONLY to 0 with setsockopt before the bind should make it possible to reliably get the behavior you described (and which we want). Rich