On Thu, May 01, 2003 at 10:48:03AM -0700, Tony Hain wrote:
The market demand is for stable addresses that can be routed globally.
That does not mean that the network manager wants to globally route
every prefix.
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.
One solution for that would be to not do multihoming, and
simply have servers live on multiple IP addresses belonging
to multiple ISP's, and use multiple DNS 'A' records in order
to provide reachability. I suspect that would be Tony's
solution about what we should be doing today.
That scenario is inconsistent. You start with 'not do multihoming', but
then describe multihomed servers.
I'm saying that's what people want in the real world.
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.
It's certainly true that having a reliable end-point
identifier is critical. But I don't think the DNS is it.
One of my points awhile back was that the current DNS is not up to the
task, and neither are the other name resolution services. Those need to
be addressed at the same time as the applications that insist in doing
the work for themselves.
... 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. :-)
This is why I believe that ultimately 8+8 is the most
interesting approach. As the old saw goes, "there is no
problem in computer science that cannot be solved by adding
an additional level of indirection".
8+8 and similar schemes suffer one of the same problems you are
complaining about. To make them work, the network needs a very fast
converging, global, identifier to locator mapping service.
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.
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.
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. :-)
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.
- Ted