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
