Re: glibc's getaddrinfo() sort order
Anthony Towns writes ("Re: glibc's getaddrinfo() sort order"):
> So if getaddrinfo() has always behaved in this way, I don't see a great
> deal of justification in changing it. The bug log indicated that there
> were pre-rfc implementations of getaddrinfo() that behaved more like
> gethostbyname() at least wrt round-robin DNS; but I've got no way of
> verifying that.
I don't know whether or not there were previous versions of
getaddrinfo with the same behaviour as gethostbyname, but that is the
wrong way of looking at it. getaddrinfo wasn't in widespread use
until the recent efforts to support IPv6.
Did you miss the bits where I said that
* getaddrinfo is supposed to replace gethostbyname
* applications are being changed t call getaddrinfo instead of
gethostbyname
?
There are only three possibilities:
(a) It is correct that the behaviour of applications (and hence of
hosts) should be changed to comply with rule 9.
(b) Application behaviour should not change; getaddrinfo should
behave the same way as gethostbyname.
(c) Application behaviour should not change but getaddrinfo should
comply with rule 9. Applications should therefore not be changed
to use getaddrinfo instead of gethostbyname.
Which of these are you proposing ? RFC3484 says (a) but is wrong for
the reasons I have explained. (b) is my view. (c) is obviously
unreasonable.
Anthony Towns writes ("Re: glibc's getaddrinfo() sort order"):
> > All existing applications using gethostbyname are not in compliance
> > with rule 9.
>
> The RFC specifies the behaviour of getaddrinfo(), not gethostbyname(),
Nonsense. It doesn't specify the behaviour of any such API at all.
RFCs like this one specify the behaviour of _hosts_. That is, it
specifies what kind of packets the host should emit and accept, on
what interfaces.
There is nothing in RFC3484 that limits its application to getaddrinfo
rather than gethostbyname.
There is discussion in s8 which suggests some possible behaviours of
getaddrinfo as an `implementation strategy' for RFC3484 - but note
that our getaddrinfo doesn't do what s8 suggests (because s8 is
barking mad). If you agree with RFC3484 s8 then you ought to conclude
that similar changes ought to be made to other internal interfaces
which do the same job as getaddrinfo.
> so doesn't affect any apps that solely use gethostbyname(). So no, it
> shouldn't be applied to other functions anymore than the definition of
> tm_year should mean we count from 1900 in every year related function.
This business about tm_year is a complete red herring.
In fact, you've got my argument completely backwards.
If someone wrote in a standards document that tm_year should be zero
at 0AD (whatever that means) rather than 1900AD, what should we do ?
Well, the answer would be obvious: we should continue to do what we
have done forever, so as not to change the meaning of existing
infrastructure: zero at 1900AD.
This is what RFC3484 s6 is doing. It is trying to change the meaning
of existing deployments of multiple IPv4 addresses in the global DNS.
> I think we can safely say that Rule 9 isn't useful for IPv4 addresses.
Are you happy then that we should mandate that the Debian libc
maintainer should change our libc accordingly ?
> I'm not sure that's true or not for IPv6 addresses -- it certainly seems
> an inappropriately hierarchial way of viewing a network that's connected
> much more ... fluidly than that, at any rate. But even if Rule 9 is
> completely useless and counterproductive, it's still the standard for
> that function, which, afaics, we should be meeting.
It is NOT THE STANDARD as I have previously pointed out.
An IETF working group proposed that it ought to become the standard
but 1. the standard has not advanced further 2. that was in a time
when IPv6 addressing structure was understood very differently.
To justify my point 2, that RFC3484 predates substantial changes in
the IPv6 addressing architecture:
Site-local addresses are one of the key features that motivates the
rules in RFC3484. These were deprecated by RFC3879 (status: PROPOSED)
and this was confirmed in RFC4291 (status: DRAFT).
(The standards track goes PROPOSED - DRAFT - STANDARD.)
DNS for IPv6 was originally intended to be supported with A6, DNAME
and bitstring labels according to RFC2874. This was originally
Standards Track and was designed to support rapid and continuous
renumbering. With the publication of RFC3363 (s1.1) and supported by
the arguments in RFC3364, 2874 was moved to EXPERIMENTAL (ie, off the
Standards Track), because rapid and continuous renumbering is no
longer planned.
Ie, the addressing and numbering arrangements for IPv6 have changed
significantly since 3484 was written. That could well be why 3484
hasn't progressed.
> > What about getaddrinfo ? Well, there is no reason why a change in API
> > (to add additional richness needed for new functionality) should so
> > radically change the behaviour.
>
> Agreed in principle, but this is a rule the RFC should've followed;
> since they haven't, I'm not convinced we should.
There is no standards-track RFC defining the behaviour of getaddrinfo.
As I say above, you're relying entirely on RFC3484 which is an
out-of-date and early-stage document, which applies equally well to
gethostbyname as getaddrinfo. 3484 discusses the intended behaviour
of hosts, not of APIs.
> > It is not reasonable for the RFC to attempt to specify that the
> > addresses be returned in a predictable ordering when the established
> > behaviour, relied on throughout the internet for decades, has been
> > that the addresses are _not_ returned in a predictable order.
>
> Again, I agree with that, but the RFC *has* done that.
If an RFC told you to jump off a mountain, would you ?
> > This argument is an argument for accepting any crap that comes out of
> > glibc upstream.
>
> No, it's an argument for accepting any crap that comes out of the Internet
> standards process. :-/
Obviously we shouldn't do that.
Our first obligation is for our systems to be good network citizens,
and the second is for them to interoperate properly. The standards
are guides to achieving these objectives, but if they conflict with
those objectives then we should value proper functionality ahead of
standards-compliance.
> If the Internet standard is explicitly different to what we've shipped
> in the past (back to when getaddrinfo() was introduced, probably slink
> or hamm), and previous documentation hasn't included the info that DNS
> round-robin won't work with getaddrinfo() (which I don't know about,
> but I suspect it didn't), then that's a good argument for ignoring the
> RFC and keeping the sensible behaviour (and contacting the RFC drafters
> with better text).
The question of documentation or otherwise of the broken behaviour is
irrelevant.
getaddrinfo is supposed to be the v6-capable replacement for
gethostbyname. That is its purpose.
You might argue that we ought not to break things by "changing"
getaddrinfo but there are no things that will be broken. If we were
to provide two functions with different names, with the two different
behaviours, then every application ought to use the one which works
like gethostbyname.
> RFC3484 explicilty encompasses getaddrinfo though:
>
> 2. Context in Which the Algorithms Operate
>
> [...]
> As a consequence, we intend that implementations of getaddrinfo()
> will use the destination address selection algorithm specified here
> to sort the list of IPv6 and IPv4 addresses that they return.
That's not the normative text; it's just discussion. That they don't
mention gethostbyname is irrelevant.
RFC3484 says that the host should select its destination address
according to the algorithm in s6. It doesn't limit that to the
situation where the function that is used internally to do the address
lookup is getaddrinfo. (How could it? Your host might not have
anything called getaddrinfo or gethostbyname.)
> > Note that RFC3484 is NOT A STANDARD. It is a `proposed standard' -
> > the earliest possible IETF standards track document status.
>
> Hey, there's no need to shout... (And yes, I had noticed that; but there's
> a lot of proposed standards that're worth following to the letter too)
I DO NEED TO SHOUT because you are NOT LISTENING.
Earlier in this very same mail where you tell me not to shout you say:
> [RFC3484] still the standard for [getaddrinfo]
So RFC3484 is not a standard but is the standard ?!
Even if it were further along the IETF standards track we shouldn't
follow its broken recommendations.
> AFAICS round-robin DNS isn't an Internet standard either, for that matter,
> which seems odd to me. There's a Microsoft page that references rfc1794
> for round-robin load balancing, but it doesn't seem entirely on point, and
> is just a memo anyway.
This just demonstrates how it is wrong to refer solely to documents
rather than reality to try to determine what the expected behaviour of
an Internet host is.
I haven't been able to find an IETF document that describes DNS round
robin. However, DNS round robin is deployed and relied on by the vast
majority of serious setups on the global Internet.
> ] It would be very interesting to hear what the people putting together
> ] (lib)curl for distros think about this.
>
> -- http://curl.haxx.se/mail/lib-2007-07/0181.html
>
> The first message in that thread refers to a test run back in 2005 to
> see how random getaddrinfo() was, which looks like it gave the same sort
> of results we're seeing here.
Yes, but until recently no-one was using getaddrinfo. All serious
applications that support getaddrinfo can also be compiled to use
gethostbyname, because not all systems have getaddrinfo yet.
The past behaviour of getaddrinfo is irrelevant.
Do you understand my point about the behaviour of HOSTS rather than
internal interfaces ? Whether an application on our system happens to
be compiled with IPv6 support should not make any difference in the
behaviour when accessing IPv4-only sites.
Ian.
Reply to: