[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Call for Votes (was Re: glibc's getaddrinfo() sort order)


(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:


 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.


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.


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 =-=-=-=-=-=-=-=-


 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 would prefer to make a connection to rather than to

 3. This has been implemented in glibc upstream by having the DNS
    resolver sort addresses before passing them to the application via

 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

 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.


 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.


 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

 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.


Version: 2.6.3ia
Charset: noconv


Reply to: