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