Re: glibc's getaddrinfo() sort order
On Sun, Sep 23, 2007 at 09:31:55AM +0200, Marc 'HE' Brockschmidt wrote:
> Ian Jackson <ian@davenant.greenend.org.uk> writes:
> > Slavish adherence to standards, or to the views of mistaken upstreams,
> > is a generally a mistake. This is particularly the case for the
> > Debian Technical Committee.
> > The TC's job is to decide what the correct behaviour is, by
> > considering the technical merits. The TC's job is not to interpret
> > standards documents. (Indeed, within our jurisdiction, our job
> > includes changing them if we disagree with them.)
> As there's no actual standard document that describes this behavior,
> it's a bit weird you feel that you should be the one to change it.
> While I agree that the RFC is proposing a sort order which isn't useful
> (at all) in the actual implementation of internet routing, I believe
> diverging from upstream and the standard without proposing a better way
> to solve this problem to be a bad idea. A bad RFC is a (smallish)
> problem, but a slightly different, probably under-documented [1]
> behavior can lead to, eh, interesting problems as soon as applications
> use the upstream behavior for something useful.
> To avoid this, spending some time to come up with a better solution
> that can be standardized seems like a good idea.
*Not* using Section 6, rule 9 for IPv4 addresses *is* a better solution.
Another better solution is to sort by prefix match length only for IPv4
prefix matches of /22 or longer (the longest prefix that ARIN will delegate
as an IPv4 allocation; networks with longer prefixes are advertised in BGP
in some cases, but this is bad for the stability of the Internet so I won't
shed any tears for users on small multihomed networks who are negatively
affected by this kind of IPv4 address sorting).
Also better would be to not attempt to sort IPv6 addresses when the prefix
match length is /16 or less (why should a host with a production IPv6
address universally give precedence to a 6to4 destination address over a
6bone destination address?), and possibly not when it's /32 or less (the
minimum size for an IPv6 allocation from the RIRs, and therefore optimally
the longest prefix that will be globally advertised).
So finding a better solution than what's currently recommended by RFC3484 is
actually not that hard; the hard part is to identify which solution is the
one that might end up as a standard later ("can be standardized").
Anyway, of these options the simplest to implement and simplest to explain
is to disable use of rule 9 for ipv4 address sorting. I think that's the
right place for us to start, both in terms of fixing the behavior of glibc
and in opening a dialogue with the relevant IETF WG about correcting RFC
3484.
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: