Call for Votes (getaddrinfo)
-----BEGIN PGP SIGNED MESSAGE-----
This time can we _please_ try to get quorum ? You must send in your
vote within 7 days of me sending this message, for it to count, ie by
approximately 2007-12-06 19:50 +0000.
-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<-
-=-=-=-=-=- 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 M: Leave the choice up to the maintainers.
[ ] Choice F: Further discussion
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=-
For clarity, with the above I do the following formal acts:
* Propose the resolution you see between -8<- marks
(represented in the ballot as choice X)
* Propose but do not accept two separate amendments for
ballot choices S and M each of which deletes the text of the
resolution and replaces it with the corresponding summary line.
* Call for a vote.
I hereby also vote as follows:
[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
[4] Choice M: Leave the choice up to the maintainers.
My rationale:
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.
Backporting to current stable
26. In my opinion this change should be backported to current
stable. However, this decision does not need to be taken now. We
can wait for experience with the change in unstable and testing,
which will help convince doubters that there is no compatibility
problem.
27. I encourage the submitter and other interested parties to pursue
getting this changed in a stable update, and to bring the matter
back to the Technical Committee if necessary to achieve this.
Responsibility of the Technical Committee to decide
28. One committee member has insisted on the presence of `leave the
choice up to the maintainer' on the ballot (option M). My
understanding of the meaning of this wording is that if that
option wins we refuse to make a decision on the matter and also
refuse to deal with it any more. Ie, this option is equivalent to
Further Discussion except that the committee will not discuss or
vote any more but instead considers the matter closed.
29. I do not consider it appropriate for the committee to decline to
issue a ruling. Once a matter has reached us it is for us to make
a decision and we should not abdicate that responsibility. If the
committee disagrees with the maintainer, but not sufficiently
overwhelmingly so as to be able to overrule the maintainer, we
should nevertheless issue a ruling clearly stating that we
disagree. In this particular case the committee does seem
to have a sufficient majority to overrule, if we can only get the
mechanics of voting working properly.
30. It has also been suggested that we should not overrule the
maintainer unless we consider the bug release-critical. This is
an abdication of the responsibility of the committee. In
particular, whether or not to overrule the maintainer should
depend primarily on how _clear_ it is that the maintainer is
wrong, rather than on how _serious_ the consequences are. The
constitution's supermajority condition gives effect to the
requirement for high confidence in a decision to overrule, and of
course individual committee members will want to be sure of their
ground in such a case.
31. Therefore I reject the suggestions that we should not decide the
matter, or that we should not overrule without concluding that the
problem is release-critical.
Ian.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBR08YRMMWjroj9a3bAQHTYQP8Dr1sO32ZVHanP33C+CUDfpEqMvtKSC+z
pEEQ9glm9UmUNUoQzyaMztst1RDfZtihsLyepKIwbw/OV8Jl1gti5+aLbQe7IqwT
7wtGFHmejeBiI7KUNjjVUrsf/cuvog8FVetZXiNq6c9TGspBms/AUJ/G0vNzFw5c
smw/X2zfAwM=
=T/Pb
-----END PGP SIGNATURE-----
Reply to: