Re: interop problems with getaddrinfo() address selection

Tony Finch <dot@dotat.at> Mon, 10 December 2007 07:50 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 1J1dP5-0000qR-5D; Mon, 10 Dec 2007 02:50:15 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1dP3-0000qK-5x for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 02:50:13 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1dOx-0000qA-7t for discuss@apps.ietf.org; Mon, 10 Dec 2007 02:50:07 -0500
Received: from ppsw-0.csi.cam.ac.uk ([131.111.8.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1dOw-0001B3-PL for discuss@apps.ietf.org; Mon, 10 Dec 2007 02:50: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]:55712) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:fanf2) id 1J1dOi-0004Gs-2S (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Mon, 10 Dec 2007 07:49:52 +0000
Received: from fanf2 (helo=localhost) by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local-esmtp id 1J1dOi-000783-OG (Exim 4.67) (return-path <fanf2@hermes.cam.ac.uk>); Mon, 10 Dec 2007 07:49:52 +0000
Date: Mon, 10 Dec 2007 07:49:52 +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: <475C5047.3010807@cs.utk.edu>
Message-ID: <Pine.LNX.4.64.0712100739410.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> <Pine.LNX.4.64.0712092000150.29087@hermes-1.csi.cam.ac.uk> <475C5047.3010807@cs.utk.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Spam-Score: -4.0 (----)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
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 Sun, 9 Dec 2007, Keith Moore wrote:
>
> I think it's a stretch to assume that in the future that all IP
> addresses associated with a domain and advertised in DNS are equally
> reachable.

The examples you listed, based on different kinds of connectivity, are
reasonable; what it not is de-randomizing equivalent classes of address.

> What causes the problem is the assumption that a destination can have
> multiple addresses, a source can have multiple addresses, and the party
> initiating the connection can somehow make a good decision about which
> address pair to use without any information from the network.

Yes :-)

> As for DNS randomization, it's never been reasonable to expect an
> application to try each of several addresses in the order returned by
> DNS.

That has been the de facto standard behaviour for over 10 years (though
before getaddrinfo they only tried the first). A lot of sites are going to
be rather upset if wide deployment of RFC 3484 suddenly breaks their
service architecture.

Tony.
-- 
f.a.n.finch  <dot@dotat.at>  http://dotat.at/
DOVER: NORTHWESTERLY 6 TO GALE 8, DECREASING 4 LATER. MODERATE OR ROUGH,
OCCASIONALLY VERY ROUGH. SQUALLY SHOWERS. GOOD.