On Tue, Sep 18, 2007 at 05:09:43PM +0100, Ian Jackson wrote:
> Andreas Barth writes ("Re: glibc's getaddrinfo() sort order"):
> > [stuff]
> So, trying to keep stuff simple, I propose:
> 1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses
> by Debian systems, and we overrule the maintainer.
By making "sortv4" default to yes when unspecified in gai.conf? Does
this need to change for stable too?
> 2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses
> by Debian systems, but we do not overrule the maintainer
> on this point.
Why are we weaker on this point? Should we simply say "wrt IPv6 addresses,
the RFC should be followed", and leave the behaviour we think proper
up to the results of:
> 3. We recommend to the IETF that RFC3484 s6 rule 9 should be
> abolished, definitely for IPv4, and probably for IPv6 too.
?
> AJ: if you don't wholly agree yet, would you like to make clear your
> counterproposal so we can vote ?
I don't disagree, I'm just not convinced that the behaviour is bad
enough to warrant violating the standard or diverging from upstream. I'm
suspicious that the standard doesn't specify what's actually been
implemented for the past decade or so too though, but haven't verified
that.
I do think the standard's wrong, clearly for IPv4, and at this point
probably for IPv6. I'm not sure if changing the standard at this point
will do any good, or if application authors will have to do their own
randomising anyway in order to work on non-Debian or non-Linux systems.
glibc's behaviour seems oddly unpredictable, too. Bah, apparently because
that roundrobin.c program is buggy, bleh. Hrm, but no, even then it
still behaves oddly. On lenny, without sortv4 disabled, in 50 runs of
getaddrinfo() on rule9.erisian.com.au, I get:
1st: 192.192.192.192 (50 out of 50)
2nd: 208.208.208.208 (50 out of 50)
3rd: 224.224.224.224 (50 out of 50)
4th-7th is where it starts going weird:
4th 5th 6th 7th
128.128.128.128 39 5 2 4
144.144.144.144 4 39 5 2
160.160.160.160 2 4 39 5
176.176.176.176 5 2 4 39
I get similar behaviour for 8th-14th, but 240.240.240.240 is last for
all 50 results.
Ah, that'll be because the ordering's simply rotating, rather than being
random: so we're assuming from A > B,C,D > E and getting:
ABCDE -> ABCDE
BCDEA -> ABCDE
CDEAB -> ACDBE
DEABC -> ADBCE
EABCD -> ABCDE
which biasses B to being in second place, C in third, and D in fourth,
simply because all but twice, B is ahead of C and D in the input because
it's just being rotated, not shuffled.
Okay, at first pass, it looks like woody's getaddrinfo() didn't reorder
things at all and neither did sarge's. etch's and lenny's do.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature