Hi,
we do we have have AI_ADDRCONFIG in nbdkit, from historical commit
999797badf48 ("Implement nbdkit server.", 2013-06-21)?
It prevents nbdkit from binding ::1, either automatically (when -i is
not specified at all), or in response to a manual request ("-i ::1"):
nbdkit: getaddrinfo: ::1: 32776: Address family for hostname not supported
Based on the explanation in
<https://bugzilla.redhat.com/show_bug.cgi?id=808147>, this behavior is
actually expected of getaddrinfo() when the host has no public IPv6
address configured.
So I think it's wrong for nbdkit to use AI_ADDRCONFIG -- why restrict
nbdkit to binding public IPv6 addresses, and exclude ::1?
The POSIX spec is terse on this:
https://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html
If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
returned only if an IPv4 address is configured on the local system,
[IP6] [Option Start] and IPv6 addresses shall be returned only if
an IPv6 address is configured on the local system. [Option End]
Ulrich Drepper's IPv6 programming intro says:
https://akkadia.org/drepper/userapi-ipv6.html
AI_ADDRCONFIG
This flag should always be set when the returned values are needed
to make connections. If no specific protocol is requested, the Linux
getaddrinfo implementation returns both IPv4 and IPv6 addresses.
This can be less than optimal and is certainly slower if the machine
has only interfaces for one protocol. These days there are still
many systems which have no configured IPv6 address at all. In that
case using an IPv6 address will always fail. Worse, it might cause
the IPv6 kernel module to be loaded unnecessarily. Using
AI_ADDRCONFIG avoids this by determining what protocols are
supported by the currently configured network interfaces and return
only addresses for those.
But in nbdkit's case, we're not making connections -- we're binding
interfaces and listening to / accepting connections. In
bind_tcpip_socket(), we have
hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG;
... Here's another bit of info:
https://fedoraproject.org/wiki/QA/Networking/NameResolution/ADDRCONFIG
Note under "Proposed solutions":
https://fedoraproject.org/wiki/QA/Networking/NameResolution/ADDRCONFIG#Proposed_solutions
(1a) Remove all code that deals with AI_ADDRCONFIG, effectively
disabling it in the general getaddrinfo() code [then links a bugzilla
attachment for glibc, AFAICT!]
(2a) Remove AI_ADDRCONFIG in all software that uses it. Deprecate
AI_ADDRCONFIG and prevent/reject modifications that add it to any software.
My reason to ask about this: on my Fedora 34 host, which has no public
IPv6 address assigned, the connect-tcp6 test case always fails. It is
not possible for me to skip it (from the make check command line), and
this failure masks further test failures -- as it prevents the rest of
the test suite from running. I could create a local branch that simply
exits with code 77, but I think using AI_ADDRCONFIG is wrong in the
first place.
Thanks,
Laszlo
Richard W.M. Jones
2022-Jan-17 14:03 UTC
[Libguestfs] why do we have AI_ADDRCONFIG in nbdkit?
On Mon, Jan 17, 2022 at 02:51:49PM +0100, Laszlo Ersek wrote:> Hi, > > we do we have have AI_ADDRCONFIG in nbdkit, from historical commit > 999797badf48 ("Implement nbdkit server.", 2013-06-21)? > > It prevents nbdkit from binding ::1, either automatically (when -i is > not specified at all), or in response to a manual request ("-i ::1"): > > nbdkit: getaddrinfo: ::1: 32776: Address family for hostname not supported > > Based on the explanation in > <https://bugzilla.redhat.com/show_bug.cgi?id=808147>, this behavior is > actually expected of getaddrinfo() when the host has no public IPv6 > address configured. > > So I think it's wrong for nbdkit to use AI_ADDRCONFIG -- why restrict > nbdkit to binding public IPv6 addresses, and exclude ::1? > > The POSIX spec is terse on this: > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/freeaddrinfo.html > > If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be > returned only if an IPv4 address is configured on the local system, > [IP6] [Option Start] and IPv6 addresses shall be returned only if > an IPv6 address is configured on the local system. [Option End] > > Ulrich Drepper's IPv6 programming intro says: > > https://akkadia.org/drepper/userapi-ipv6.html > > AI_ADDRCONFIG > > This flag should always be set when the returned values are needed > to make connections. If no specific protocol is requested, the Linux > getaddrinfo implementation returns both IPv4 and IPv6 addresses. > This can be less than optimal and is certainly slower if the machine > has only interfaces for one protocol. These days there are still > many systems which have no configured IPv6 address at all. In that > case using an IPv6 address will always fail. Worse, it might cause > the IPv6 kernel module to be loaded unnecessarily. Using > AI_ADDRCONFIG avoids this by determining what protocols are > supported by the currently configured network interfaces and return > only addresses for those. > > But in nbdkit's case, we're not making connections -- we're binding > interfaces and listening to / accepting connections. In > bind_tcpip_socket(), we have > > hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG; > > ... Here's another bit of info: > > https://fedoraproject.org/wiki/QA/Networking/NameResolution/ADDRCONFIG > > Note under "Proposed solutions": > > https://fedoraproject.org/wiki/QA/Networking/NameResolution/ADDRCONFIG#Proposed_solutions > > (1a) Remove all code that deals with AI_ADDRCONFIG, effectively > disabling it in the general getaddrinfo() code [then links a bugzilla > attachment for glibc, AFAICT!] > > (2a) Remove AI_ADDRCONFIG in all software that uses it. Deprecate > AI_ADDRCONFIG and prevent/reject modifications that add it to any software. > > My reason to ask about this: on my Fedora 34 host, which has no public > IPv6 address assigned, the connect-tcp6 test case always fails.I have noticed this test failing too, but it only failed on some machines and not on others and I was never able to get to the bottom of why this happened.> It is not possible for me to skip it (from the make check command > line), and this failure masks further test failures -- as it > prevents the rest of the test suite from running. I could create a > local branch that simply exits with code 77, but I think using > AI_ADDRCONFIG is wrong in the first place.Almost certainly it's there because it was copied from some other place and I didn't look into whether it was needed. It sounds from the description above as if it should not be there. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html