Re: Glibc reordering of IPv6 and IPv4
måndag den 17 maj 2010 klockan 10:11 skrev Ken Raeburn detta:
> On May 16, 2010, at 18:42, Mats Erik Andersson wrote:
> > in the bug reports #580473 and #581552, for atftp and vtun,
> > respectively, I have tried to bring attention to the fact
> > that a new resolve ordering between IPv4 and IPv6 is in effect
> > from Debian testing and onwards.
>
> This isn't an ordering issue; standard gethostbyname() simply doesn't return IPv6 addresses.
>
If the gethostbyname() present in libc6-2.7 (Lenny) and
libc6-2.10.2 (testing/Squeeze) are considered non-standard,
I could possibly agree.
Using "options inet6", either implementation __does__ indeed
return IPv6 addresses. The manual page clearly state that
the call is allowed to do so! And yes, resolv.conf(5) warns
about using this optional setting.
> Are they turning on "options inet6" in resolv.conf (or hard-coding the equivalent in libc)? From what I read in the man page for resolv.conf, it sounds like that returns only IPv6-format addresses (mapping IPv4 addresses to IPv6 in the process), instead of the standard IPv4 addresses, which I think would break every gethostbyname() application that doesn't know about this extension and explicitly check for it. (Really, I can't figure out what "options inet6" is good for. If you're going to hack your application to know about these extensions, you might as well just use getaddrinfo. Even if you do hack some of your applications to expect IPv6 addresses from gethostbyname, the config file option affects *every* such application.)
>
[[[Crappy clients produce crappy line breaks!]] Use Mutt/Vim instead. ]
This is close to my point, software should be written to use getaddrinfo(),
since 'hints.af_family = AF_INET' is the proper way of restricting to a
single family. The issue at hand must be to locate software which presupposes
that gethostbyname() returns addresses of true IPv4 size.
> If it's intentional, it might have been better to simply remove gethostbyname altogether and force packages to break in more obvious ways instead of occasionally subtle ones (e.g., failing to process addresses correctly in infrequently-used paths). Or, a more gentle approach: First, mark gethostbyname deprecated, so the compiler and/or linker warn every time it's seen.
>
Are you suggesting to remove gethostbyname() from glibc/eglibc entirely?
The manual page already states that gethostbyname() and gethostbyaddr()
are to be considered obsolete, and to be replaced by getaddrinfo() and
getnameinfo().
> And, if it's intentional, where was it discussed before the decision was made? Is there a more appropriate list for that discussion than this one??
>
We have to start somewhere, if nobody else does. Right?
I admit that the word "order" is not entirely to the point for gethostbyname(),
but it is for getaddrinfo(). In a discussion earlier this year with Aurelien Jarno,
I got confirmed that the default setting in Glibc changed between 2.7 and 2.10.2,
in the sense that getaddrinfo() now orders IPv6 before IPv4 in the answer list.
I did complain on this new behaviour, but had to do with the fact that any
software that does not loop through the output list from getaddrinfo() is
misconceived from the start.
In my view, the addressed problem with gethostbyname() is an offspring of this deeper fact.
> That makes me wonder if it's just a mistake, that should be corrected soon....
>
Doubtful. Said behaviour is now claimed to be standard in Ubuntu, Fedora, SuSe;
you name them all. And as Aurelien Jarno pointed out, the order has never been
specified in any standard, every output strategy is equally valid. It is the
responsibility of the developer to identify the week assumptions.
> Ken
Mats Erik Andersson, fil. dr
Reply to: