Re: interop problems with getaddrinfo() address selection

Keith Moore <moore@cs.utk.edu> Sat, 08 December 2007 21:21 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1772-0004gb-EY; Sat, 08 Dec 2007 16:21:28 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1772-0004gT-58 for discuss-confirm+ok@megatron.ietf.org; Sat, 08 Dec 2007 16:21:28 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1771-0004gL-Rh for discuss@apps.ietf.org; Sat, 08 Dec 2007 16:21:27 -0500
Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1770-0006Nj-Ib for discuss@apps.ietf.org; Sat, 08 Dec 2007 16:21:27 -0500
Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id D15A110308D; Sat, 8 Dec 2007 16:21:09 -0500 (EST)
X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu
Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wbn0Gj7qALDk; Sat, 8 Dec 2007 16:21:07 -0500 (EST)
Received: from lust.indecency.org (m740f36d0.tmodns.net [208.54.15.116]) by bes.cs.utk.edu (Postfix) with ESMTP id 269EC103084; Sat, 8 Dec 2007 16:21:01 -0500 (EST)
Message-ID: <475B0ABC.5090806@cs.utk.edu>
Date: Sat, 08 Dec 2007 13:21:00 -0800
From: Keith Moore <moore@cs.utk.edu>
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Tony Finch <dot@dotat.at>
Subject: Re: interop problems with getaddrinfo() address selection
References: <Pine.LNX.4.64.0712061901020.24448@hermes-1.csi.cam.ac.uk> <200712062020.PAA16213@Sparkle.Rodents.Montreal.QC.CA> <Pine.LNX.4.64.0712071735070.24448@hermes-1.csi.cam.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0712071735070.24448@hermes-1.csi.cam.ac.uk>
X-Enigmail-Version: 0.95.5
OpenPGP: id=E1473978
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906
Cc: der Mouse <mouse@Rodents.Montreal.QC.CA>, discuss@apps.ietf.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

Tony Finch wrote:
> On Thu, 6 Dec 2007, der Mouse wrote:
>   
>> I'm interseted in what sort of problems it causes.
>>     
>
> DNS round robin is effective at balancing load evenly across multiple
> servers, because each client is (in effect) directed to one of the servers
> at random. If the client sorts the DNS response before using it then the
> randomization is defeated and the load on the servers is no longer
> balanced.
>   
this seems like an almost-inherent consequence of IPv6's expecting hosts
to have multiple addresses and asking hosts initiating a communication
to do address selection.  it's not specific to getaddrinfo() - any API
that tried to solve that problem would be likely to reorder addresses to
some degree.

though it should be possible for the client implementation to go through
the list of addresses, assign a preference value to each one (based on
address type and number of leading bits in common with one of the
hosts's local addresses), then perform a stable sort by preference value.