From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4313 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:30:26 -0500 Message-ID: <20131130173026.GS24286@brightrain.aerifal.cx> References: <20131129174410.GD24286@brightrain.aerifal.cx> <20131130003704.GL24286@brightrain.aerifal.cx> <20131130031744.GM24286@brightrain.aerifal.cx> <20131130035116.GO24286@brightrain.aerifal.cx> <20131130035912.GP24286@brightrain.aerifal.cx> <20131130170112.GR24286@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 1385832633 25334 80.91.229.3 (30 Nov 2013 17:30:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Nov 2013 17:30:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4317-gllmg-musl=m.gmane.org@lists.openwall.com Sat Nov 30 18:30:39 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 1VmoNL-0007Co-3k for gllmg-musl@plane.gmane.org; Sat, 30 Nov 2013 18:30:39 +0100 Original-Received: (qmail 17938 invoked by uid 550); 30 Nov 2013 17:30:38 -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 17930 invoked from network); 30 Nov 2013 17:30:38 -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:4313 Archived-At: On Sat, Nov 30, 2013 at 05:23:22PM +0000, Justin Cormack wrote: > On Sat, Nov 30, 2013 at 5:01 PM, Rich Felker wrote: > > On Sat, Nov 30, 2013 at 09:16:54AM +0000, Justin Cormack wrote: > >> On 30 Nov 2013 03:59, "Rich Felker" wrote: > >> > > >> > On Fri, Nov 29, 2013 at 10:51:16PM -0500, Rich Felker wrote: > >> > > On Fri, Nov 29, 2013 at 10:45:26PM -0500, Strake wrote: > >> > > > On 29/11/2013, Rich Felker wrote: > >> > > > > But that would mean complete unconditional DNS failure on systems > >> > > > > lacking IPv6. > >> > > > > >> > > > We could do so iff system has IPv6. Switching on whether system has > >> > > > IPv6 rather than whether resolv.conf has any IPv6 nameservers means > >> > > > * no check whether resolv.conf includes v6 server > >> > > > * that adding a v6 server to resolv.conf can not break DNS even on > >> > > > systems lacking v6 > >> > > > which seems saner. > >> > > > >> > > OK, so how do we detect if the system "has IPv6"? I don't think it's > >> > > >> > BTW, short of an answer to this question, I think the approach I > >> > already suggested is rather safe. I can't imagine how an IPv6 > >> > nameserver address would end up in resolv.conf on a system completely > >> > lacking IPv6 support at the kernel level. > >> > >> I can imagine how it got there eg if you have a standard config or you > >> compile a new kernel and omit ipv6... > > > > Indeed, this is conceivable. However, if the system is intended to be > > used on an IPv6 network and you compile without IPv6 in the kernel, > > lots of things will break and you probably just need to fix the > > kernel. Still I'd like to avoid more breakage here than necessary. > > > > Can you (or anyone) fill me in on how things fail on a system built > > without IPv6 support or with broken IPv6 configuration? I assume the > > original socket() call will fail (with what errno?) if IPv6 support is > > not even compiled into the kernel, but are there other cases where > > socket() might succeed but then sending to a v4-mapped address would > > fail (where sending to the same v4 address with a v4 socket would > > work)? > > 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? Rich