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