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
- RE: Thinking differently about the site local pro… Michel Py
- RE: Thinking differently about the site local pro… Christian Huitema
- Re: Thinking differently about the site local pro… Keith Moore
- RE: Thinking differently about the site local pro… Margaret Wasserman
- RE: Thinking differently about the site local pro… Jeroen Massar
- RE: Thinking differently about the site local pro… Vernon Schryver
- RE: Thinking differently about the site local pro… Tony Hain
- Re: Thinking differently about the site local pro… Eliot Lear
- Re: Thinking differently about the site local pro… Valdis.Kletnieks
- Thinking differently about names and addresses Dave Crocker
- Re: Thinking differently about the site local pro… Måns Nilsson
- Re: Thinking differently about the site local pro… Stephen Sprunk
- RE: Thinking differently about the site local pro… Margaret Wasserman
- Re: Thinking differently about the site local pro… Keith Moore
- Re: Thinking differently about the site local pro… Keith Moore
- RE: Thinking differently about the site local pro… Jeroen Massar
- Re: Thinking differently about the site local pro… Matt Crawford
- Re: Thinking differently about the site local pro… Matt Crawford
- RE: Thinking differently about the site local pro… Michel Py
- Re: Thinking differently about the site local pro… Keith Moore
- Re: Thinking differently about the site local pro… Keith Moore
- Re: Thinking differently about the site local pro… Keith Moore
- Re: Thinking differently about the site local pro… Valdis.Kletnieks
- Re: Thinking differently about the site local pro… Matt Crawford
- RE: Thinking differently about the site local pro… John C Klensin
- RE: Thinking differently about the site local pro… Jeroen Massar
- Re: Thinking differently about the site local pro… Keith Moore
- Re: Thinking differently about the site local pro… Keith Moore
- RE: Thinking differently about the site local pro… Tony Hain
- Re: Thinking differently about the site local pro… Valdis.Kletnieks
- RE: Thinking differently about the site local pro… Jeroen Massar
- RE: Thinking differently about the site local pro… Jeroen Massar
- Re: Thinking differently about the site local pro… Keith Moore
- Re: Thinking differently about the site local pro… S Woodside
- RE: Thinking differently about the site local pro… Michel Py
- RE: Thinking differently about names and addresses Tony Hain
- Re: Thinking differently about names and addresses Dave Crocker
- site locals are bankrupt Keith Moore
- Re: Thinking differently about names and addresses John C Klensin
- Re: Thinking differently about names and addresses Harald Tveit Alvestrand
- Re: Thinking differently about the site local pro… John Stracke
- RE: Thinking differently about names and addresses Tony Hain
- Re: Thinking differently about the site local pro… John Stracke
- Re: Thinking differently about the site local pro… J. Noel Chiappa
- Re: Thinking differently about the site local pro… J. Noel Chiappa
- Re: Thinking differently about names and addresses Keith Moore
- Re: Thinking differently about names and addresses Dave Crocker
- Re: Thinking differently about names and addresses Dave Crocker
- Re: Thinking differently about the site local pro… Keith Moore
- RE: Thinking differently about names and addresses Tony Hain
- Re: Thinking differently about names and addresses Keith Moore
- Re: Thinking differently about the site local pro… Bill Manning
- Re: Thinking differently about the site local pro… Michael Richardson
- Re: Thinking differently about the site local pro… Pekka Savola
- Re: Thinking differently about the site local pro… Harald Tveit Alvestrand
- RE: Thinking differently about the site local pro… Jeroen Massar
- RE: Thinking differently about the site local pro… Spencer Dawkins
- Re: Thinking differently about the site local pro… Keith Moore
- RE: Thinking differently about the site local pro… Jeroen Massar
- Re: Thinking differently about the site local pro… Bill Manning
- Re: Thinking differently about the site local pro… Keith Moore
- Re: Thinking differently about the site local pro… Keith Moore
- Re: Thinking differently about the site local pro… Keith Moore
- RE: Thinking differently about the site local pro… Jeroen Massar
- Re: Thinking differently about the site local pro… John C Klensin
- RE: Thinking differently about the site local pro… Jeroen Massar
- Re: Thinking differently about the site local pro… Keith Moore
- Re: Thinking differently about the site local pro… Randy Bush
- RE: Thinking differently about the site local pro… Tony Hain
- RE: Thinking differently about the site local pro… Daniel Senie
- RE: Thinking differently about the site local pro… Jeroen Massar
- RE: Thinking differently about the site local pro… Jeroen Massar
- RE: Thinking differently about the site local pro… Jeroen Massar
- RE: Thinking differently about the site local pro… Tony Hain
- Re: Thinking differently about the site local pro… John Stracke
- Re: Thinking differently about the site local pro… Keith Moore
- RE: Thinking differently about the site local pro… Brian Zill
- Re: Thinking differently about the site local pro… Fredrik Nyman
- RE: Thinking differently about the site local pro… Jeroen Massar
- RE: Thinking differently about the site local pro… Margaret Wasserman
- RE: Thinking differently about the site local pro… Jeroen Massar
- Re: Thinking differently about the site local pro… John Stracke
- Re: Thinking differently about the site local pro… Keith Moore
- Re: Thinking differently about the site local pro… John Stracke
- v6 support (was Re: Thinking differently about th… Keith Moore
- Re: v6 support (was Re: Thinking differently abou… Steven M. Bellovin
- Re: v6 support (was Re: Thinking differently abou… Eric Rosen