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

Re: glibc's getaddrinfo() sort order

Ian Jackson writes ("Re: Call for Votes (Re: glibc's getaddrinfo() sort order)"):
> Result:
>  Further Discussion.

I'd like to understand what there is left to discuss.

On the substantive level it seems to me that we have comprehensively
demonstrated that rule 9 for IPv4 is just wrong.  Just in case someone
has missed it I'll summarise the reasons again below.

Many of the same reasons apply to IPv6.  We are less confident of the
situation with IPv6 particularly because there is less of an installed
base in the DNS (of publication of multiple addresses).

On the procedural level we had an argument about NMUs.
I think my most recent posting on this subject
  Date: Sun, 23 Sep 2007 16:02:25 +0100
addresses this most cogently and no-one has replied to it at all.
Does that mean you all agree with it ?

We also had a discussion about the nature of our recommendation to the
IETF.  I originally proposed one short wording:
    3. We recommend to the IETF that RFC3484 s6 rule 9 should be
       abolished, definitely for IPv4, and probably for IPv6 too.
AJ objected that he felt we should be "making a definitive statement"
to the IETF.  I think this statement is quite definitive enough and we
should let the IETF get on with it.  But I did suggest a longer
alternative in my mail of
  Date: Sun, 23 Sep 2007 16:23:54 +0100
and no-one replied.

Reasons for disapproving of RFC3484 section 6 rule 9 for IPv4:

* The existing de-facto standard for the interpretation of multiple
  IPv4 addresses published in the global DNS is DNS round robin.
  Therefore Debian applications should follow this standard, even if
  they use getaddrinfo.

* getaddrinfo's primary purpose is the IPv6-capable replacement for
  gethostbyname and there is no reason to for an application's sorting
  of IPv4 addresses to change when the call to gethostbyname is

* There are no applications that use getaddrinfo specifically to get
  different semantics for address sorting.

* Rule 9 for IPv4 caused serious operational problems (our own ftp
  sites failed!) when we introduced it (as part of IPv6 transition and
  conversion of applications to getaddrinfo).  Ie, rule 9 (not the
  lack of it) is what has compatibility problems.

* Lack of rule 9 for IPv4 has not caused any practical problems in the
  past and we have no reason to believe that it will if we make
  getaddrinfo not do rule 9 for IPv4.  No concrete example has been
  advanced of any application or protocol which might break.

* Even on its own terms (trying to find nearby hosts) rule 9 for IPv4
  does not make much sense given current IPv4 addressing policies.

* Rule 9 has been alleged to be a standard however it is at best at an
  early level of maturity which we should follow with care and with
  our eyes open, and at worst is a superseded proposal which is in any
  case inapplicable to IPv4.

* The purpose of standards is interoperability and where following a
  standard makes us less interoperable we should not follow the

Taken together these reasons make it impossible to conclude in favour
of IPv4.  As I said some weeks ago, I think the point about
compatibility with existing deployments advertising multiple IPv4
records in the global DNS is irrefutable.  No-one has even come close
to refuting it.


Reply to: