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