IPv4 and IPv6 addresses in resolv.conf

IPv4 and IPv6 addresses in resolv.conf

[orc]

Hi list,
It is possible in future to have both ipv4 and ipv6 addresses in resolv.conf?
Currently dns resolver reads first address and if it is ipv6 address then it goes on and second address (127.0.0.1 as example) also interpreted as ipv6 one, result is attempt to send data to 127::7f00:1.

Re: IPv4 and IPv6 addresses in resolv.conf

[Rich Felker]

On Fri, Nov 29, 2013 at 06:09:26PM +0800, orc wrote:
> Hi list,
> It is possible in future to have both ipv4 and ipv6 addresses in resolv.conf?
> Currently dns resolver reads first address and if it is ipv6 address
> then it goes on and second address (127.0.0.1 as example) also
> interpreted as ipv6 one, result is attempt to send data to
> 127::7f00:1.

If this is happening, it's a bug. The intent is that both v4 and v6
are supported. I'll see if I can reproduce it and if it's not too hard
to fix I'll try to get a fix in before the release.

Rich

Re: IPv4 and IPv6 addresses in resolv.conf

[Rich Felker]

On Fri, Nov 29, 2013 at 12:44:10PM -0500, Rich Felker wrote:
> On Fri, Nov 29, 2013 at 06:09:26PM +0800, orc wrote:
> > Hi list,
> > It is possible in future to have both ipv4 and ipv6 addresses in resolv.conf?
> > Currently dns resolver reads first address and if it is ipv6 address
> > then it goes on and second address (127.0.0.1 as example) also
> > interpreted as ipv6 one, result is attempt to send data to
> > 127::7f00:1.
> 
> If this is happening, it's a bug. The intent is that both v4 and v6
> are supported. I'll see if I can reproduce it and if it's not too hard
> to fix I'll try to get a fix in before the release.

Can you clarify if you're using latest git or 0.9.14? I can't
reproduce this in current git, but it looks like the misinterpretation
was due to __ipparse bugs which nsz fixed. The behavior I'm seeing,
which is what was intended (I was slightly wrong in my above
expression of intent) is that only nameservers in the same address
family as the first nameserver get used, and nameservers in the other
get ignored. This is suboptimal but at least not horribly broken.

What I think would be the correct behavior is noting whether any v6
addresses are seen, and if so, converting the v4 addresses to
v4-mapped v6 addresses and using IPv6 for all communication. Does this
sound reasonable?

Rich

Re: IPv4 and IPv6 addresses in resolv.conf

[Strake]

On 29/11/2013, Rich Felker <dalias@aerifal.cx> wrote:
> What I think would be the correct behavior is noting whether any v6
> addresses are seen, and if so, converting the v4 addresses to
> v4-mapped v6 addresses and using IPv6 for all communication. Does this
> sound reasonable?

It would be simpler to just always convert to v6.

Re: IPv4 and IPv6 addresses in resolv.conf

[Rich Felker]

On Fri, Nov 29, 2013 at 08:18:20PM -0500, Strake wrote:
> On 29/11/2013, Rich Felker <dalias@aerifal.cx> wrote:
> > What I think would be the correct behavior is noting whether any v6
> > addresses are seen, and if so, converting the v4 addresses to
> > v4-mapped v6 addresses and using IPv6 for all communication. Does this
> > sound reasonable?
> 
> It would be simpler to just always convert to v6.

But that would mean complete unconditional DNS failure on systems
lacking IPv6.

Rich

Re: IPv4 and IPv6 addresses in resolv.conf

[Strake]

On 29/11/2013, Rich Felker <dalias@aerifal.cx> 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.

Re: IPv4 and IPv6 addresses in resolv.conf

[Rich Felker]

On Fri, Nov 29, 2013 at 10:45:26PM -0500, Strake wrote:
> On 29/11/2013, Rich Felker <dalias@aerifal.cx> 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
an easy question to answer, but it's not just a rhetorical question
either since we need to know for the AI_ADDRCONFIG flag that's not yet
working, so this may very well be the right way to go.

One other option that's of course the safest is just opening two
sockets, one for IPv4 and one for IPv6, if both are needed, but that
of course complicates, bloats, and slows down the code and adds
failure cases so I'd rather avoid it.

Rich

Re: IPv4 and IPv6 addresses in resolv.conf

[Rich Felker]

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 <dalias@aerifal.cx> 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.

Rich

Re: IPv4 and IPv6 addresses in resolv.conf

[Laurent Bercot]

> OK, so how do we detect if the system "has IPv6"? I don't think it's
> an easy question to answer, but it's not just a rhetorical question
> either since we need to know for the AI_ADDRCONFIG flag that's not yet
> working, so this may very well be the right way to go.

  Is there any problem with a build-time test that opens an IPv6 socket ?
This is what skalibs does and it's been working so far. Of course, any
build-time test makes cross-compilation difficult, but this is why we
have configure options, to manually bypass auto-detection when it cannot
be relied on.


> One other option that's of course the safest is just opening two
> sockets, one for IPv4 and one for IPv6, if both are needed, but that
> of course complicates, bloats, and slows down the code and adds
> failure cases so I'd rather avoid it.

  s6-dns opens a different UDP socket, with the appropriate address family,
every time the client changes servers: so the underlying transport matches
exactly what /etc/resolv.conf specifies. You may call it bloated, but I
believe it does just the right thing (and I'm not one to go for
unnecessary features at the expense of simplicity). Speed is not an issue
here, because we're performing network calls: opening sockets is totally
negligible compared to waiting for the network anyway.

-- 
  Laurent

Re: IPv4 and IPv6 addresses in resolv.conf

[Justin Cormack]

[-- Attachment #1: Type: text/plain, Size: 1115 bytes --]

On 30 Nov 2013 03:59, "Rich Felker" <dalias@aerifal.cx> 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 <dalias@aerifal.cx> 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...

[-- Attachment #2: Type: text/html, Size: 1497 bytes --]

Re: IPv4 and IPv6 addresses in resolv.conf

[John Spencer]

Laurent Bercot wrote:
> 
>> OK, so how do we detect if the system "has IPv6"? I don't think it's
>> an easy question to answer, but it's not just a rhetorical question
>> either since we need to know for the AI_ADDRCONFIG flag that's not yet
>> working, so this may very well be the right way to go.
> 
>  Is there any problem with a build-time test that opens an IPv6 socket ?
> This is what skalibs does and it's been working so far. Of course, any
> build-time test makes cross-compilation difficult, 

it also makes binaries that work on some systems, but not on others.
musl follows a philosophy of maximum portable binaries.

Re: IPv4 and IPv6 addresses in resolv.conf

[orc]

[-- Attachment #1: Type: text/plain, Size: 1939 bytes --]

Rich Felker <dalias@aerifal.cx> пишет:
>On Fri, Nov 29, 2013 at 12:44:10PM -0500, Rich Felker wrote:
>> On Fri, Nov 29, 2013 at 06:09:26PM +0800, orc wrote:
>> > Hi list,
>> > It is possible in future to have both ipv4 and ipv6 addresses in
>resolv.conf?
>> > Currently dns resolver reads first address and if it is ipv6
>address
>> > then it goes on and second address (127.0.0.1 as example) also
>> > interpreted as ipv6 one, result is attempt to send data to
>> > 127::7f00:1.
>> 
>> If this is happening, it's a bug. The intent is that both v4 and v6
>> are supported. I'll see if I can reproduce it and if it's not too
>hard
>> to fix I'll try to get a fix in before the release.
>
>Can you clarify if you're using latest git or 0.9.14? I can't
>reproduce this in current git, but it looks like the misinterpretation
>was due to __ipparse bugs which nsz fixed. The behavior I'm seeing,
>which is what was intended (I was slightly wrong in my above
>expression of intent) is that only nameservers in the same address
>family as the first nameserver get used, and nameservers in the other
>get ignored. This is suboptimal but at least not horribly broken.
>
>What I think would be the correct behavior is noting whether any v6
>addresses are seen, and if so, converting the v4 addresses to
>v4-mapped v6 addresses and using IPv6 for all communication. Does this
>sound reasonable?
>
>Rich

I use probably too outdated 0.9.12.

I also got interesting results while testing from git.
Attached logs from strace for busybox ping. Files marked with '4' in names mean that first address in resolv.conf was ipv4 one then ipv6, while other two vice versa.
Git build with ipv4 address given first fails with big loop and no host is resolved (huge log).
Git version was built with debugging, shared and existing binary executed via invoking libc.so.

Since ipv4 addresses are working right if come first, then your approach seems to be fine.

[-- Attachment #2: log.tar.gz --]
[-- Type: application/x-gzip, Size: 40516 bytes --]

Re: IPv4 and IPv6 addresses in resolv.conf

[Rich Felker]

On Sat, Nov 30, 2013 at 09:13:32AM +0000, Laurent Bercot wrote:
> 
> >OK, so how do we detect if the system "has IPv6"? I don't think it's
> >an easy question to answer, but it's not just a rhetorical question
> >either since we need to know for the AI_ADDRCONFIG flag that's not yet
> >working, so this may very well be the right way to go.
> 
>  Is there any problem with a build-time test that opens an IPv6 socket ?

Yes. There's no reason to expect that the system musl is compiled on
is the same as the system a program later linked to it is later run
on.

> This is what skalibs does and it's been working so far. Of course, any
> build-time test makes cross-compilation difficult, but this is why we
> have configure options, to manually bypass auto-detection when it cannot
> be relied on.

This introduces gratuitous complexity and breakage and like you said
breaks cross-compiling. (Unwritten) musl policy forbids any
configure-time tests that require running compiled programs; this
policy should be followed by all applications, IMNSHO. :-)

Aside from the gratuitous breakage, the reason not to do
configure-time tests that require running compiled programs is that
you don't need to. The fact that you're able to detect the behavior at
test program run-time during configure means you could also detect it
at actual application run-time. The reason for compile/link tests at
configure time is that they're measuring things that can't be measured
at run-time; this doesn't apply to run-time tests.

> >One other option that's of course the safest is just opening two
> >sockets, one for IPv4 and one for IPv6, if both are needed, but that
> >of course complicates, bloats, and slows down the code and adds
> >failure cases so I'd rather avoid it.
> 
>  s6-dns opens a different UDP socket, with the appropriate address family,
> every time the client changes servers: so the underlying transport matches

musl couldn't open/close them like this because it does all of the
queries in parallel rather than changing servers in series. We could
use two sockets, one for v4 and one for v6, but this seems like
gratuitous complexity.

> exactly what /etc/resolv.conf specifies. You may call it bloated, but I
> believe it does just the right thing (and I'm not one to go for
> unnecessary features at the expense of simplicity). Speed is not an issue
> here, because we're performing network calls: opening sockets is totally
> negligible compared to waiting for the network anyway.

I agree that speed isn't an issue. However holding two open sockets
and file descriptors when only one is needed may be an issue for
systems under heavy open file/socket load.

Rich

Re: IPv4 and IPv6 addresses in resolv.conf

[Rich Felker]

On Sat, Nov 30, 2013 at 09:16:54AM +0000, Justin Cormack wrote:
> On 30 Nov 2013 03:59, "Rich Felker" <dalias@aerifal.cx> 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 <dalias@aerifal.cx> 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)?

The fallback scheme I'm thinking of using is something like:

	if (have_any_v6_nameservers) {
		if (socket(PF_INET6, ...) && errno=EAFNOSUPPORT) {
			disable any v6 nameservers
			open and use v4 socket
		}
		v4-map all v4 nameservers
		use v6 socket
	} else {
		open and use v4 socket
	}

Does this look reasonable?

Rich

Re: IPv4 and IPv6 addresses in resolv.conf

[Justin Cormack]

On Sat, Nov 30, 2013 at 5:01 PM, Rich Felker <dalias@aerifal.cx> wrote:
> On Sat, Nov 30, 2013 at 09:16:54AM +0000, Justin Cormack wrote:
>> On 30 Nov 2013 03:59, "Rich Felker" <dalias@aerifal.cx> 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 <dalias@aerifal.cx> 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
should be safe to try to open a v6 socket, then if that succeeds,
convert all ipv4 addresses to v4-mapped and use that, else fall back
to v4 socket and drop any v6 addresses. Which is what you have
below...

> The fallback scheme I'm thinking of using is something like:
>
>         if (have_any_v6_nameservers) {
>                 if (socket(PF_INET6, ...) && errno=EAFNOSUPPORT) {
>                         disable any v6 nameservers
>                         open and use v4 socket
>                 }
>                 v4-map all v4 nameservers
>                 use v6 socket
>         } else {
>                 open and use v4 socket
>         }
>
> Does this look reasonable?
>
> Rich

Re: IPv4 and IPv6 addresses in resolv.conf

[Rich Felker]

On Sat, Nov 30, 2013 at 05:23:22PM +0000, Justin Cormack wrote:
> On Sat, Nov 30, 2013 at 5:01 PM, Rich Felker <dalias@aerifal.cx> wrote:
> > On Sat, Nov 30, 2013 at 09:16:54AM +0000, Justin Cormack wrote:
> >> On 30 Nov 2013 03:59, "Rich Felker" <dalias@aerifal.cx> 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 <dalias@aerifal.cx> 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

Re: IPv4 and IPv6 addresses in resolv.conf

[Rob]

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...

Rob

Re: IPv4 and IPv6 addresses in resolv.conf

[Rich Felker]

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

Re: IPv4 and IPv6 addresses in resolv.conf

[Justin Cormack]

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.

Justin

Re: IPv4 and IPv6 addresses in resolv.conf

[Rich Felker]

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

Re: IPv4 and IPv6 addresses in resolv.conf

[Rich Felker]

On Sat, Nov 30, 2013 at 11:27:43PM +0800, orc wrote:
> I use probably too outdated 0.9.12.
> 
> I also got interesting results while testing from git.
> Attached logs from strace for busybox ping. Files marked with '4' in
> names mean that first address in resolv.conf was ipv4 one then ipv6,
> while other two vice versa.
> Git build with ipv4 address given first fails with big loop and no
> host is resolved (huge log).
> Git version was built with debugging, shared and existing binary
> executed via invoking libc.so.
> 
> Since ipv4 addresses are working right if come first, then your
> approach seems to be fine.

I'm still not entirely clear what these logs are showing. I believe
everything is fixed now though, so please let me know if you're still
having problems.

Rich