Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))

Keith Moore <moore@cs.utk.edu> Mon, 31 March 2003 21:25 UTC

Received: from ran.ietf.org (ran.ietf.org [10.27.6.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25279; Mon, 31 Mar 2003 16:25:44 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 1906zG-0004l2-00 for ietf-list@ran.ietf.org; Mon, 31 Mar 2003 16:38:38 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 1906yr-0004hN-00 for ietf@ran.ietf.org; Mon, 31 Mar 2003 16:38:13 -0500
Received: from astro.cs.utk.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25172 for <ietf@ietf.org>; Mon, 31 Mar 2003 16:21:47 -0500 (EST)
Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with SMTP id h2VLNuA06236; Mon, 31 Mar 2003 16:23:57 -0500 (EST)
Date: Mon, 31 Mar 2003 16:23:56 -0500
From: Keith Moore <moore@cs.utk.edu>
To: Jeroen Massar <jeroen@unfix.org>
Cc: moore@cs.utk.edu, huitema@windows.microsoft.com, alh-ietf@tndh.net, john-ietf@jck.com, ietf@ietf.org
Subject: Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Message-Id: <20030331162356.52a63c86.moore@cs.utk.edu>
In-Reply-To: <004601c2f7b0$f478afd0$210d640a@unfix.org>
References: <DAC3FCB50E31C54987CD10797DA511BA027E0E26@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com> <004601c2f7b0$f478afd0$210d640a@unfix.org>
X-Mailer: Sylpheed version 0.8.9 (GTK+ 1.2.10; i386--netbsdelf)
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: owner-ietf@ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

> > Well, that is emphatically *NOT* what application developers 
> > do. They do not just observe that it does not work, they try
> > to work around, e.g. routing messages to a different address,
> > at a different time, through a third party, or through a
> > different protocol. 
> 
> Indeed, correctly coded applications will use a getaddrinfo()
> and then a connect() in a loop until succesful. 

it's perfectly reasonable to connect to an address without first
doing a DNS lookup.  even when you need to do a DNS lookup,
getaddrinfo() doesn't always do what you need.

Keith