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