Re: glibc's getaddrinfo() sort order
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.
vorlon@debian.org http://www.debian.org/
[1] http://xkcd.com/195/ :-)
Reply to: