> 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