David Conrad wrote: > On Wednesday, January 29, 2003, at 02:33 AM, Brian E Carpenter wrote: > > If we achieve stable locators, this problem largely goes away, but > > stable names in themselves are insufficient IMHO. > > The problem isn't the DNS, but the concept of 'stable > locators'. Given > the need to aggregate, you simply can't have stability in locators if > network topology changes. Since locators need to change when > topology > changes, any solution you come up with will need to deal with > propagation delay and security while at the same time dealing with > scalability and performance. I would argue that the DNS can be > contorted to deal with these requirements (although whether or not > you'd want to is another question).
In the abstract I agree with David that the name system already handles separating the identifier from the locator in a scalable way. What the current DNS implementation is lacking are scalable security, and the appropriate simplicity to push it to the consumer edge. While I think this is an area where solutions are possible, it is not clear that contorting the existing arcane DNS into a scalable, simple tool is the most expedient approach. Suspend disbelief for a moment, and consider a name resolution service where the consumer edge widget was responsible for both tracking topology changes, and updating a branch of the name tree to keep it aligned. Said widget would need a secure mechanism to graft itself to the name tree after an address change, but otherwise might look like a typical DNS server. Nodes served by this widget would have a locally scalable mechanism for secure registration (probably a shared secret). In the global space, caching times for various points in the tree would most likely get shorter as they approach the edge. A consumer widget possibly being susceptible to frequent changes might need to react on the order of a minute. Preventing this from hammering the graft point would require longer branches. Fortunately the current DNS has the concept of structured graft points, so the social change would be limited to getting over the idea that everything is grafted directly to a gtld. Any approach that separates the identifier from the locator will need a secure mechanism to assert a binding. That assertion will need to have a short lifetime to deal with topology changes, and scaling the mapping/verification service will be a challenge. Given that as a starting point, there is no obvious reason that using name strings as the identifier is more difficult than any other approach. The current difficulty is rooted in the concept of a deployed distributed database that requires a high priest to chant the magic incantation before use. Rather than fight with the DNS gods over changes to DNS, hasn't the multi-homing effort spiraled down to the point of having the routing gods define a new name service to be run in series? If we did have a reasonably responsive dynamic name service, wouldn't people naturally use it for the cases where external access to a node might be susceptible to change? At the same time wouldn't the internal use cases where stability is paramount, look for site local? The whole argument about limiting use of SL is based on the lack of a stable identifier that has a real-time binding to the locator. The two work arounds to prevent churning DNS are stable locators (PI), or locator translators (nat). Are we wasting a lot of time and energy trying to solve the problem in routing, when the real solution lies in a complete overhaul of the DNS? Tony -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
