Re: interop problems with getaddrinfo() address selection

Tony Finch <dot@dotat.at> Sun, 09 December 2007 20:10 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 1J1STa-000812-0o; Sun, 09 Dec 2007 15:10:10 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1STY-00080w-3g for discuss-confirm+ok@megatron.ietf.org; Sun, 09 Dec 2007 15:10:08 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1STX-00080o-Q0 for discuss@apps.ietf.org; Sun, 09 Dec 2007 15:10:07 -0500
Received: from ppsw-8.csi.cam.ac.uk ([131.111.8.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1STW-00016M-CY for discuss@apps.ietf.org; Sun, 09 Dec 2007 15:10:07 -0500
X-Cam-SpamDetails: Not scanned
X-Cam-AntiVirus: No virus found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:58334) by ppsw-8.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1J1STT-0002xZ-RB (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Sun, 09 Dec 2007 20:10:03 +0000
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1J1STT-0001wz-DA (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Sun, 09 Dec 2007 20:10:03 +0000
Date: Sun, 9 Dec 2007 20:10:03 +0000
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk
To: Keith Moore <moore@cs.utk.edu>
Subject: Re: interop problems with getaddrinfo() address selection
In-Reply-To: <475B0ABC.5090806@cs.utk.edu>
Message-ID: <Pine.LNX.4.64.0712092000150.29087@hermes-1.csi.cam.ac.uk>
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> <475B0ABC.5090806@cs.utk.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
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

On Sat, 8 Dec 2007, Keith Moore wrote:
>
> 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.

The problem isn't specific to IPv6 - for example see the comments about
address selection for "multihomed" MXs in RFC 2821. However in practice we
ignore this possibility and treat host names with multiple IP addresses as
equally reachable at any address. I don't think IPv6 substantially changes
this situation, because most of its common extra addresses have limited
scope and will not be published in the DNS.

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

That's essentially what RFC 3484 recommends, and what causes the problem.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
FORTIES: CYCLONIC 7 TO SEVERE GALE 9 BECOMING NORTHERLY 5 TO 7. ROUGH OR VERY
ROUGH, OCCASIONALLY HIGH AT FIRST. RAIN OR SHOWERS. MODERATE OR GOOD.