Re: Thinking differently about names and addresses

Keith Moore <moore@cs.utk.edu> Tue, 01 April 2003 19:26 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 OAA09176; Tue, 1 Apr 2003 14:26:37 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 190RZi-0003hr-00 for ietf-list@ran.ietf.org; Tue, 01 Apr 2003 14:37:38 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 190RXh-0003Wq-00 for ietf@ran.ietf.org; Tue, 01 Apr 2003 14:35:33 -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 OAA08699 for <ietf@ietf.org>; Tue, 1 Apr 2003 14:18:44 -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 h31JK6A18435; Tue, 1 Apr 2003 14:20:06 -0500 (EST)
Date: Tue, 01 Apr 2003 14:20:06 -0500
From: Keith Moore <moore@cs.utk.edu>
To: alh-ietf@tndh.net
Cc: moore@cs.utk.edu, dhc2@dcrocker.net, ietf@ietf.org
Subject: Re: Thinking differently about names and addresses
Message-Id: <20030401142006.1dbdb6f3.moore@cs.utk.edu>
In-Reply-To: <087201c2f87c$778a4a20$ee1a4104@eagleswings>
References: <5854435704.20030401082235@brandenburg.com> <087201c2f87c$778a4a20$ee1a4104@eagleswings>
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

> And my point is that when you take that uninterpreted label out of its
> context of uniqueness, it can't be used as a meaningful name.

which is why addresses need to be unique.

> The real problem that the app community has with 1918 & SL is that
> they validly want a single namespace, but they also want to insist on
> using addresses as names. 

not exactly.  there are valid cases for apps using addresses even when
names exist.  sometimes you really do want to talk to a host that is at
a particular network location.  

as for 'apps insist on using addresses as names' - this is because the
architecture doesn't provide names that are good enough to use as
endpoint identifiers for all or even most cases.  you might think this
is unfortunate, and I might agree, but it doesn't follow that we should
force all apps to use DNS.  and fixing the architecture to have a
reliable endpoint identifier is a pipe dream.  nobody has demonstrated
how to make it workable.

also re: 'using addresses as names' -  this is a bogus distinction,
addresses *are* names to a large degree.  the prefix of an address is an
arbitrary bit pattern (i.e. a name), the suffix is an arbitrary bit
pattern. only the bits in the middle have anything to do with topology. 
maybe they're closer to names of locations than to names of hosts, but
they're still names.

> What the app community is indirectly saying is that we use topology
> locators as names, we have to have a single rooted name space,
> therefore the locators have to point at a unified topology. 

at least in the current IP architecture, and we're nowhere close to
having a workable new architecture that separates locators from names.

> The reality of deployed networks is that there will be routing
> filters, therefore we have a disjoint views of the address space. In
> addition, the app community expects their use of the topology locator
> as a name to be stable over a long period,

not just the app community.  TCP expects this; it cannot recover from
address changes. or does the routing community think that it's okay to
interrupt TCP connections at a whim?

> while the routing community
> wants the flexibility to change the locator as needed for significant*
> topology changes. These 'USES' are clearly at odds.

yes, there are competing concerns.  this calls for a compromise about
how stable addresses need to be, not for having infinitely stable
addresses nor for having addresses change at a whim. 

> > At this stage, I would want to hear the requirements (or 
> > probably better, the desired usage scenarios) before being 
> > certain that a modified DNS is the answer.
> 
> We agree that we need to understand the requirements before starting
> on a design.

the new namespace:

a) must to work underneath transport and other protocols, so that
those protocols' associations can survive address changes.
b) must provide quick, secure, reliable indirection
c) must provide for timely update and/or the ability to recover from
stale mapping information quickly and transparently to the application
d) must have appropriate granularity/precision - generally that of
a host/port, so that connections from multiple sources to the same
endpoint identifier reach the same process 
e) requirement c notwithstanding, there's some need for ability to do
redirects at connection setup time and possibly later, to support
process mobility and/or fanout within server farms
f) must have global scope so that referrals work

> Clearly the app community has taken advantage of using the 'where'
> identifier as a 'what' identifier. This worked fine until ~1987 when
> people started putting in routing filters which fragmented views of
> the'where' space. 

no, it still works fine in a global address space.  you are confusing 
address scope with address reachability.  apps aren't expected to be
able to reach hosts when there are explicit filters in place, so the
fact that those filters break apps is considered a feature.  however
apps are expected to accomodate private addresses, and the fact that
many apps cannot reasonably do this is considered a bug in the app.

> What the
> anti-SL camp is arguing is that if we only take one step back, we will
> rid ourselves of the problem of fragmented views.

what the consensus is arguing is that private addresses were a mistake.

> What they miss is
> that reintroduces the market demand for squatting, because we offer no
> alternative,

there is no demand for squatting until addresses are scarce.  v6
addresses are not scarce.

> We really need a big-picture perspective here before any knee-jerk
> reactions. I have one alternative for how to preallocate space to deal
> with the squatting issue, but even that doesn't solve the disconnect
> between the app community view of a unified 'where' space to be used
> as'whats', when the network managers will continue to install route
> filters and fragment the 'where' space. 

the route filters do not fragment the where space, so this is not a
problem.

Keith