Call for Votes (was Re: glibc's getaddrinfo() sort order)
-----BEGIN PGP SIGNED MESSAGE-----
(I'm resending this lost mail from the 8th of November, intending to
restart the 7-day clock:)
It seems that discussion on this has dried up. Although my very
similar proposal was defeated the first time, I think it probably by
now falls to me by default to propose a new version. So:
-8<-
1. RFC3484 s6 rule 9 should not be applied to IPv4 addresses
by Debian systems, and we DO overrule the maintainer.
2. RFC3484 s6 rule 9 should not be applied to IPv6 addresses
by Debian systems. We do NOT overrule the maintainer.
3. We recommend to the IETF that RFC3484 s6 rule 9 should be
abolished for IPv4, and that it should be reconsidered for IPv6.
-8<-
For the sake of clarity, we should at least have the libc maintainer's
position on the ballot, so I propose and call for a vote.
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
[ ] Choice X: Do not use rule 9, overrule maintainer, etc., as above.
[ ] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo
[ ] Choice F: Further discussion
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
I've left off `do not use rule 9, do not overrule maintainer' as a
choice as no-one seemed to be arguing for it.
-8<-
Here is my vote and my opinion:
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
[1] Choice X: Do not use rule 9, overrule maintainer, etc., as above.
[2] Choice F: Further discussion
[3] Choice S: Sort IPv4 addrs according to rule 9 in getaddrinfo
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
Introduction
1. We have been asked to rule on the application of RFC3484 section 6
rule 9 by the resolver in glibc.
2. Rule 9 requires a host to sort addresses according to the length
of the initial prefix common with the host's own address, when
deciding which of a peer's addresses to try in which order. Thus
eg, a host 172.18.45.11 would prefer to make a connection to
172.18.45.6 rather than to 172.31.80.8.
3. This has been implemented in glibc upstream by having the DNS
resolver sort addresses before passing them to the application via
getaddrinfo.
Background and history
4. Prior to the publication and implementation of RFC3484, and prior
to the introduction of getaddrinfo, most hosts would use an
implementation of gethostbyname to find IPv4 addresses to use for
a peer, given its hostname. gethostbyname has almost universally
returned the addresses in the order supplied by whatever DNS
nameserver it was using.
5. In 1993, the then-ubiquitous nameserver implementation BIND was
modified to implement a feature known as `DNS Round Robin'. This
does not need to be explained in detail, but the intended and
actual effect was that clients would be provided addresses (and
other records) in a deliberately varying order, so that in the
aggregate clients' choice of address to use would be distributed
uniformly across the published addresses.
6. Between then and the recent implementation of rule 9 by some
hosts, DNS round robin became universally deployed. It has been
implemented by other nameservers and has become a de facto
standard at least for the interpretation of multiple IPv4
addresses in the global DNS.
IPv6 transition
7. The primary use of getaddrinfo is to replace gethostbyname when an
application is converted to support IPv6. gethostbyname cannot be
sensibly used to support IPv6; while there are other interfaces
that can be used instead, the routine practice has been to make
certain very consistent sets of changes to applications, which
include replacing the use of gethostbyname by getaddrinfo.
8. gethostbyname in current glibc does not implement rule 9. The
effect therefore is that whether a particular host follows rule 9
for a particular protocol depends mainly on whether that
particular version of the application in question has been updated
in the host's operating system to support IPv6. (As well as, of
course, whether the operating system's getaddrinfo uses rule 9.)
9. There are no known applications which specifically desire the
rule 9 behaviour; we know of no case where an application uses
getaddrinfo specifically to get rule 9.
10. There is therefore no rational reason for the difference
between the behaviour of gethostbyname and getaddrinfo, other than
perhaps implementation convenience.
Compatibility and benefits
11. Rule 9 is incompatible with the DNS Round Robin. Prior to rule
9, a system administrator would publish multiple addresses in the
intent and expectation of getting roughly equal client load on
each address.
12. When Debian's apt changed its behaviour to follow rule 9,
it broke ftp.us.debian.org because the load suddenly became very
unbalanced. Thus this incompatibility causes actual operational
problems.
13. We know of no situations where multiple IPv4 addresses on the
global Internet are published with the intent and expectation that
rule 9 will be followed by client systems.
14. The nature of the IPv4 address space structure suggests that rule
9 is not in practice useful for IPv4 on the global Internet.
History and status of RFC3484
15. RFC3484 and rule 9 forms part of a document set published as part
of early IPv6 work.
16. At the time of publication of RFC3484, the intended IPv6 addressing
architecture had a significantly different shape. 3484 and rule 9
appear to form part of a set of behaviours which go alongside
rapid renumbering, which has now fallen out of favour.
17. There is no evidence that the authors of RFC3484, which is
specifically headed as an IPv6 document, considered specifically
the behaviour for IPv4 or realised that the specification
conflicted with the widely-used DNS Round Robin.
18. RFC3484 was a product of IPv6 (ie networking) working groups, not
DNS working groups.
Standards
18. The purpose of standards is interoperability. Where following a
standard makes us less interoperable we should not follow the
standard. Debian is entitled to deviate from standards, including
published documents, if we consider it appropriate to do so.
19. We should of course consider carefully before going against a
published document. However, when the situation is clear, we
should not be overly reluctant to do so. In cases where de jure
and de facto standards disagree, we must make a judgement which we
prefer based on all of the circumstances.
20. In any case RFC3484 is currently `Proposed Standard', which is
the earliest and least mature form of standards track document,
which can be expected to have rough edges.
Conclusions
21. Rule 9 is not the standard behaviour for IPv4, RFC3484
notwithstanding. Round Robin is the de facto standard behaviour
(despite not having been officially standardised), and there can
be little justification for making such a radical change at this
stage.
22. RFC3484 is therefore in error when it applies rule 9 to IPv4.
Not using rule 9 for IPv4 is unquestionably preferable.
23. It appears that RFC3484 is also unhelpful for IPv6. However,
since there is no existing de-facto standard for IPv6, this
conclusion is arguable.
24. Therefore I would insist on traditional DNS Round Robin, rather
than rule 9, for IPv4; but I would only recommend against rule 9
in the case of IPv6.
25. It is clear that the IETF needs to revisit this issue and I would
formally recommend to them that they do so.
Ian.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBRzya/cMWjroj9a3bAQENxwQAgYG83KvPXS32JHWWoZLqafLIOHqDAnQa
35ORgS3/Bf9QPvzJVzNBnmnMPjhtcodEpTMVpn8dmSone7h5BpB9zd5PNV+kkhlY
iXQKgg4oLsEpODyJ6txFjpkMTxI4JO4+lhQoTzIyVLW2nntrY3dvZm5VBx3I0FS+
Ik6SXp+F1Ao=
=QqKO
-----END PGP SIGNATURE-----
Reply to: