[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#438179: getaddrinfo() sorts results.



On Thu, Aug 16, 2007 at 10:42:20PM +0200, Aurelien Jarno wrote:
> >>    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.
> 
> The fact you have a 10.0.0.0/8 does not changes anything to the way the
> list is sorted in rule 9. Only the returned addresses are taken into
> account.

It sorts the list in such a way that the top most bits are the same.
So it first sorts by:
10.0.0.0/8
then:
10.0.0.0/7
8.0.0.0/6
8.0.0.0/5
0.0.0.0/4
0.0.0.0/3
0.0.0.0/2
0.0.0.0/1

And then finaly the rest (128.0.0.0/1)

The first of those makes sense for me, the rest doesn't.


Kurt




Reply to: