I concur with all of Ian's comments, and in particular I would also like to encourage Kurt to champion this issue to the IETF working group. My own past experiences suggest that glibc upstream is willing to hide behind standards not only when they mandate undesirable behavior but also when they fail to /prohibit/ undesirable behavior, so it would be nice to have a solution that in the long term doesn't require the Debian glibc maintainers to diverge from upstream in order to comply with a ruling of the TC.
I would also underscore the additional reason Kurt has pointed out for why RFC3484 section 6 rule 9 is inappropriate for IPv4 networks, even in the absence of NAT. Over the years, the IPv4 address space has become extremely fragmented, in large part due to an incomplete understanding of the long-term significance of early stewardship policies. As an example, by 2003 the ISP I was working for had network allocations in each of 206.x.x.x, 208.x.x.x, and 64.x.x.x, and have since picked up netblocks in 216.x.x.x and 63.x.x.x. While some of these netblocks do share common prefixes, the common prefixes are so short that they aren't even specific to North America[1], and some of the netblocks are far enough apart that rule 9 would give precedence to half the planet over the router down the hall. Rule 9 follows naturally from IPv6 allocation policies which have been crafted in direct response to the experiences with IPv4 with the intent of minimizing address space fragmentation. In IPv6, 64 bits of the address are "host" bits, and another 16 bits of the prefix denote "local" networks, with the remaining 48 bits corresponding fairly well with network topology. This rule is therefore a sensible default for IPv6, but for IPv4 it easily results in pessimal behavior and should not be a default. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ [1] http://xkcd.com/195/ :-) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]