So here's my understanding of where we're at. First, fact finding. Everything here should be able to be agreed by everyone. getaddrinfo() is a new interface that replaces gethostbyname(). It hasn't different semantics that are intended to make it superior to gethostbyname() and other functions, both in supporting IPv6 and potentially other ways (such as resolving "foo.bar.com:http" differently to "foo.bar.com:https"). The most authoritative document for how getaddrinfo() will order its results is RFC3484, which is a Proposed Standard on the Internet Standards Track and seems to be being implemented by the major vendors including glibc and Windows. The sorting behaviour of getaddrinfo() cannot be relied on in today's Internet, and it behaves differently in different implementations -- particularly due to RFC3484 having been proposed only after getaddrinfo() had already been in wide use. Further, RFC3484 specifically indicates that the sorting behaviour may be overridden if a better order can be determined locally (see the last paragraph of section 6). Beyond that, determining optimal address selection appears to be an open area of research, and modifications to RFC3484 are still being discussed and proposed both within and outside of the RFC context [0]. Note that RFC4294 ("IPv6 Node Requirements") indicates RFC3484 "MUST be implemented", at least in the context of dealing with multiple addresses. The sorting behaviour specified in RFC3484 has not been in common use within the IPv4-based Internet. Instead, by far the most common behaviour has been to use the ordering presented by the DNS, usually simply selecting the first returned result. This behaviour has allowed client address selection to be influenced by the DNS system and thus the provider of the service being addressed, as described in RFC 1794. This has most commonly been implemented by having the DNS servers provide a cyclic, round-robin selection of addresses, such that each address is returned as the first result equally often. This is not the only method for load balancing, though it is one of the simplest and most easily deployed on today's Internet. Others include giving entirely different results to different people doing DNS queries such as described in the supersparrow architecture [1], or doing dynamic load balancing of http queries via the 302 redirect response. The primary expectations for load balancing are generally one or more of: - that load be evenly distributed across hosts - that load be biassed to the closest/cheapest host for the client - that load distribution be controllable by the service provider The prefix-matching procedure described in RFC3484 does not meet those expectations in a number of cases. First, responsibility for destination selection is assumed entirely by the client, so that the only choice the service provider has is to list or not list a host. As such the service provider is faced with a choice of providing only the best servers to the client, and not giving the client the possibility to failover to other servers that might be available; or having the client select a server entirely on its own judgement. Second, when NAT is in use, a relatively small range of prefixes (10/8, 192.168/16, 172.16/12 and potentially 169.254/16) will have a high number of users, thus leading to a bias towards servers matching those prefixes. Further, those prefixes by design do not bear any relationship to their actual position in the network, removing the possibility of the bias being towards close/cheap servers. Third, when round-robin DNS is in use, the ordering procedure described by RFC3484 will not ensure that all servers with the best matching prefix are given equal time as the first address returned, but instead may be biassed towards one address depending on the exact ordering of the addresses presented by the server [2]. Each of these objections apply to the mechanism described in RFC3484 whether applied to IPv4 or IPv6 addresses. In addition, with particular regard to IPv4 addresses, in the present day Internet: - round-robin DNS is normal - NAT is extremely common - the average prefix length in BGP tables is >22 [3], and matches on shorter prefixes do not provide a strong correlation with locality ... Is the above all reasonable and uncontroversial? If so, conclusions that could potentially be drawn: (a) Using prefix matching to select IPv4 addresses isn't useful (b) Using prefix matching to select IPv4 addresses is harmful (c) Using prefix matching to select IPv4 addresses is harmful enough to be an RC issue for Debian (d) Prefix matching IPv4 addresses provided the match is at least 22 bits (or similar) might be reasonable (e) Choosing the best address isn't a job for the client, and is better left to the service provider and DNS system (f) Given the existance of round-robin DNS, if prefix matching is used to select an address, addresses with equal prefix matches should be reordered randomly. I find it hard to see any way around (a), and I'm reasonably convinced of (b). I'm not at all convinced of (c), which I guess is to say my hypothetical vote would be: [ 1 ] (a) + (b) [ 2 ] (a) + (b) + (c) [ 3 ] (a) [ 4 ] Further discussion [ 5 ] !(a) and I imagine I'd be outvoted in favour of (a)+(b)+(c). If so, declaring this to be an RC issue justifies both an update to etch and (if necessary, which I don't expect) an NMU for sid/lenny, which seems all that's needed. Conversely, if we don't consider this an RC issue, changing it for etch doesn't seem appropriate, and at that point I don't see why we'd change it for sid either (at least absent an update via the IETF standards track process). I'd be interested to see explanations of why this should be considered RC. I'm not sure if any or all of (d)-(f) would be sufficient recommendations to close the issue for IPv6 as well, or if there's something else that would make sense. Cheers, aj [0] http://psg.com/lists/v6ops/v6ops.2007/msg00486.html http://www.ops.ietf.org/lists/shim6/msg01040.html http://rfc.net/rfc3879.html [1] http://www.supersparrow.org/ss_paper/html/node13.html [2] http://lists.debian.org/debian-ctte/2007/09/msg00025.html [3] http://bgp.potaroo.net/as2.0/bgp-active.html
Attachment:
signature.asc
Description: Digital signature