Re: IPv4 and IPv6 addresses in resolv.conf

[Rich Felker <dalias@aerifal.cx>]

On Sat, Nov 30, 2013 at 05:43:11PM +0000, Justin Cormack wrote:
> On Sat, Nov 30, 2013 at 5:33 PM, Rob <robpilling@gmail.com> 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...
> >
> 
> Yes the default is that ipv6 binds to both ipv6 and ipv4. There is a
> sockopt IPV6_V6ONLY or /proc/sys/net/ipv6/bindv6only which defaults to
> 0.
> 
> I guess scheme above is going to fail if /proc/sys/net/ipv6/bindv6only
> is set to 1, so the sockopt will have to be set manually as well to
> force binding on both.

OK, I've committed an implementation based on the above discussion,
and tested casually that it works with v4-only, v6-only, or a mix of
addresses (including both v4-mapped v6 addresses and real v6
nameservers). I have not followed up on orc's further report to see
whether this fixes the issues he was experiencing.

Rich