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 17:00 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 MAA14460; Mon, 31 Mar 2003 12:00:51 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 1902qp-0006ne-00 for ietf-list@ran.ietf.org; Mon, 31 Mar 2003 12:13:39 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 1902qR-0006mN-00 for ietf@ran.ietf.org; Mon, 31 Mar 2003 12:13:15 -0500
Received: from conure.mail.pas.earthlink.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14244 for <ietf@ietf.org>; Mon, 31 Mar 2003 11:56:53 -0500 (EST)
Received: from user-119b1dm.biz.mindspring.com ([66.149.133.182] helo=envy.indecency.org) by conure.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 1902cq-0001YS-00; Mon, 31 Mar 2003 08:59:13 -0800
Date: Mon, 31 Mar 2003 11:54:10 -0500
From: Keith Moore <moore@cs.utk.edu>
To: alh-ietf@tndh.net
Cc: moore@cs.utk.edu, 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: <20030331115410.58779b94.moore@cs.utk.edu>
In-Reply-To: <069101c2f597$1d7cf330$ee1a4104@eagleswings>
References: <4949597.1048882957@p3.JCK.COM> <069101c2f597$1d7cf330$ee1a4104@eagleswings>
X-Mailer: Sylpheed version 0.8.10 (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

> My arguments are more about acknowledging the reality and requirements
> of the deployed architecture than they are about creating a special
> case. 

Tony,

your arguments are an attempt to perpetuate costly mistakes that provide
little or no value.  you are not acknowledging reality, you are denying it.

> Routing filters do and will exist, ergo local scope addresses will
> exist. 

no.  it doesn't follow.  routing filters do and will exist, ergo there 
will always be some (source, destination) pairs that cannot exchange traffic
while those filters are in place.  this implies nothing about the scope of
those addresses.

> Applications will have to deal with that, yet there is no hint
> unless we provide a well-known flag.

applications cannot be expected to deal with filters in any way other than
to report that the communication is prohibited.  the "well known" flag
exists and is called ICMP.

site locals do not provide a well known flag because an application has
no idea about the site boundary, and when given an SL address has no idea
about which site that address belongs to.  if the app tries to use it from
the wrong site, it might even get sent to the wrong host (though this is
unlikely if stateless autoconfiguration is used).  still, rather than
getting an immediate ICMP prohibited the app gets a timeout, and the app
has no idea whether this is a temporary or permanent failure.  so SLs are
broken even from the standpoint of providing a well known flag.

> I agree that applications should
> not have to understand topology, but when they insist on passing around
> topology information they have bought into the need to understand what
> they are doing. 

apps are not insisting on passing around topology information, because
mere addresses are not topology information.

> DNS is one of the protocols that deals in topology
> information, so it needs to understand topology. We need to make it
> robust enough that applications can rely on it so they will simply pass
> around names. 

false.  there's no way to make this work well.  you are trying to cripple the
v6 architecture so badly as to make it useless. 

> In writing that it occurs to me that one of our failings is that we have
> allowed a component of the system to have a very unrealistic (archaic)
> view of what the network is.

the archaic view is that scoped addresses are acceptable.  we've learned our
lesson with RFC 1918.  we know better now.  the original flat address space
design was superior.