Re: interop problems with getaddrinfo() address selection

Keith Moore <moore@network-heretics.com> Wed, 19 December 2007 17:39 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 1J52tX-0000Sd-Tm; Wed, 19 Dec 2007 12:39:47 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1ol4-0004fD-5W for discuss-confirm+ok@megatron.ietf.org; Mon, 10 Dec 2007 14:57:42 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1J1ol3-0004ez-RS for discuss@apps.ietf.org; Mon, 10 Dec 2007 14:57:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J1obb-0000VQ-PC for discuss@apps.ietf.org; Mon, 10 Dec 2007 14:47:55 -0500
Received: from m1.imap-partners.net ([64.13.152.131]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1J1oba-0002FY-A4 for discuss@apps.ietf.org; Mon, 10 Dec 2007 14:47:55 -0500
Received: from lust.indecency.org (m780f36d0.tmodns.net [208.54.15.120]) by m1.imap-partners.net (MOS 3.8.4-GA) with ESMTP id AIG05276 (AUTH admin@network-heretics.com) for discuss@apps.ietf.org; Mon, 10 Dec 2007 11:46:16 -0800 (PST)
Message-ID: <475D977F.9050308@network-heretics.com>
Date: Mon, 10 Dec 2007 11:46:07 -0800
From: Keith Moore <moore@network-heretics.com>
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> <475B0ABC.5090806@cs.utk.edu> <Pine.LNX.4.64.0712092000150.29087@hermes-1.csi.cam.ac.uk> <475C5047.3010807@cs.utk.edu> <Pine.LNX.4.64.0712100739410.29087@hermes-1.csi.cam.ac.uk>
In-Reply-To: <Pine.LNX.4.64.0712100739410.29087@hermes-1.csi.cam.ac.uk>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
X-TMDA-Confirmed: Mon, 10 Dec 2007 14:57:41 -0500
X-Mailman-Approved-At: Wed, 19 Dec 2007 12:39:46 -0500
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

>> 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).
IIRC, very old versions of gethostbyname() only returned a single
address, but this was fixed in most platforms long before IPv6.  It was
still up to the application to reference h_addr_list rather than h_addr,
and to choose from the list of returned addresses.
>  A lot of sites are going to
> be rather upset if wide deployment of RFC 3484 suddenly breaks their
> service architecture.
>   
yes, they'll be upset,  though I wouldn't pin the blame on RFC 3484. 
and actually I'd be surprised if the sites pinned the blame on RFC 3484
either.  it seems more likely that they'd just blame IPv6.

as for their "service architecture", expecting everyone else in the
Internet to do things your way has always been risky.

Keith

p.s. I wouldn't have much of a problem with clarifying a successor to
RFC 3484 in this regard, though IMHO getaddrinfo() is so messed up that
it really needs to be scrapped.  yes, I realize this would be a PR disaster.