Bug#438179: getaddrinfo() sorts results.

[Kurt Roeckx <kurt@roeckx.be>]

On Thu, Aug 16, 2007 at 10:03:14PM +0200, Aurelien Jarno wrote:
> Kurt Roeckx a écrit :
> > reopen 438179
> > thanks
> > 
> > On Thu, Aug 16, 2007 at 08:24:51PM +0200, Aurelien Jarno wrote:
> >> This is a feature, not a bug. getaddrinfo() sorts results according to
> >> RFC3484. You can configure the way they are sorted using /etc/gai.conf.
> > 
> > None of the rules in rfc3484 say anything about this.  In fact, the last
> > rule says:
> >    Rule 10:  Otherwise, leave the order unchanged.
> >    If DA preceded DB in the original list, prefer DA.  Otherwise prefer
> >    DB.
> 
> Rule 9 comes before:
> 
>    Rule 9:  Use longest matching prefix.
>    When DA and DB belong to the same address family (both are IPv6 or
>    both are IPv4): If CommonPrefixLen(DA, Source(DA)) >
>    CommonPrefixLen(DB, Source(DB)), then prefer DA.  Similarly, if
>    CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)),
>    then prefer DB.

That's a rule that might work for IPv6, but not for IPv4.  But even when
using IPv6, I think you want the CommonPrefixLen to be atleast 24 bit,
maybe even 32, or even 64.

So, because I happen to have a 10.0.0.0/8 address, it prefers addresses
which as many as possible 0's at the front.  This is unlikely to give me
an address that's going to be close network-wise, since none of the
returned addresses are actually in 10.0.0.0/8.

> Anyway if you don't want to sort to the returned addresses,
> you only want to do that for IPv4, and thus need two different interfaces.

I think rule 9 shouldn't be use for IPv4 addresses, or be changed that
the minimum CommonPrefixLen should be the that of the netmask of the
source address.


Kurt