Theodore Ts'o wrote:
No, but stable address that can be routed globally satifies
the goal having an address which can be passed from B to C
and still be used to
reach A. That was my point.
Only if there is a route from C to A for the address that was passed. If
there is a list that B can reach A by, it needs a way to tell C to get
its own list, or a way to sort out which will actually be useful to C.
It seems to me that you have this alternate solution which
requires using the DNS instead. But given the choice between
forcing applications to be rewritten, or leaning on the ISP's
to provide globally routable, provider-independent addresses
that *can* be passed from B to C and used to reach A, we know
what network managers have done, successfully --- they lean
on their ISP's.
I agree, but just because an address is unique does not mean it is
globally routable. If B passes an address for A that it can reach, but C
has no route to, this is not accomplishing the network manager's goal.
For some reason the network manager doesn't want C to contact A by a
particular address, so B shouldn't be passing it.
... and your solution is that IPv6 shouldn't do any of this
work? Make the the application writers modify all of their
protocols and implementations, as well as forcing the DNS to
retool? No wonder your proposed solution is so popular. :-)
IPv6 didn't cause this problem, it only makes it harder to ignore.
Yes, but at the same time it is no *more* work than that
which is required by your scheme. Regardless of whether we
put this work all on the shoulders of the DNS and application
folks, we still need to have to provide the same solution.
So your scheme of forcing the DNS to do all of this work
isn't any easier.
I didn't say DNS has to do all of the work. All name resolutions
services need to as well as any other process that passes around
addresses that it intends the receiver to use as a topology locator.
This is a simple engineering function of making the data useful in the
context it is intended to be used.
Mangling the address field in the packet only allows the app to use
part of the address for the identifier. There is no reason that the
identifier has to be part of the address.
Yes, applications would have to be changed to recognize that
only part of the "IPv6 address" is useful as the identifier.
But I suspect when you compare the utility of a fixed-length
identifier which is guaranteed to be unique, as opposed to a
variable-length, often-inconsistent user-provided string,the
fixed-length identifier will be considered much superior.
Uniqueness does not guarantee utility, and having something that can
consistently be turned into a useful value is always superior to quickly
getting the wrong answer.
The bottom line is that in order to solve the problem right,
I think everyone will have to make some changes. Perhaps
part of the problem here is that **everyone** has been
saying, "my part of the stack is perfect --- everything else
in the stack needs to change in order to accomodate *me*".
For example, saying that nothing needs to change in IPv6, but
rather the IESG must force the DNS direct to do all sorts of
things, and that application writers must be forced to make
all sorts of changes to conform to a particular architecture,
might not necessarily been the course of success. In fact,
it probably would just cause a general consensus to deprecate
site-local addresses. :-)
IE: Shoot the messenger rather than deal with the issues that have been
ignored for 15+ years ... :(
The problem will not be solved by PI addressing. I don't
care if apps
pass around addresses, as long as they are doing the work
to make sure
the address is consistent with the topology the app is
intentionally
describing. If the app is not going to learn about topology (and I
agree the app shouldn't) it needs to rely on a service that has the
means to do the job. We agree, the current DNS is not up to
the task.
What if applications pass around a fixed-length identifier
which they consider to be a globally unique "address", and
the IP layer contacted some locator server (to be defined) a
routable entity which it considers an "address"? It's the
same pieces which you outlined; it's just simply a matter of
factoring the pieces slightly different, and recognizing that
there is only one IP layer, and many applications. So
modifying the IP layer to make use of the locator service is
much less work than forcing all of the applications to be
changed to contact this posited locator service.
I don't have a conceptual problem with the approach, but such a service
would have many of the same issues that DNS should be dealing with
anyway. In particular it would need to converge quickly on a global
basis, at the same time the resolution function is widely distributed to
scale appropriately. Someone would have to show me how the
fixed/variable length issue makes any difference to the hard part of
this problem.
Tony