Dan Lanciani wrote: > "Tony Hain" <[EMAIL PROTECTED]> wrote: > > |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. [...] > > It's not much of a suspension. I've been saying for years > that exactly such a mechanism is necessary to push the > routing task out to the end nodes where ample resources will > be available. If it isn't done at some other level it will > have to happen in the DNS. However, I believe that the DNS > is the wrong place for it.
There is an important difference between pushing all the way to the end system, vs. the edge router. While architecturally there is little difference, when the mapping function is in the end system the level of churn on the registration infrastructure is substantially higher. Moving that to the consumer edge/set top provides both a platform that is generally more stable in its availablity, as well as an aggregation point for the bulk of the device churn. > > |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. > > Using name strings may be no more difficult with respect to > the implementation of the name service, but it leverages far > less existing code than would a fixed- length binary > identifier. Existing code is not a reasonable argument to justify the architectural change of inserting an additional name service into the system. > Consider the advantages of using an identifier > that has exactly the same format as what we currently call an > address, i.e., 128 bits. With translation happening near the > bottom of the IP layer, no changes would be necessary in tcp > or in applications. Unless the application was trying to associate the source address of the packet with something it knows about. If there is a 'transparent' mapping function in the system, apps that expect that service will break. If such a mapping service is to work with said apps, there needs to be a mechanism to distribute the mapping table with some level of authenticity. If you are talking about essentially in-line encaps like 8+8, every routing edge would need to map the source locator as well as destination. > The problem of tcp connections > (not) surviving renumbering would disappear. The DNS would > work just the way it is, so no duplicate effort would be > required. Wait, a string to string translation happens in the DNS, then you claim another string to string translation is not a duplicate effort !?!?! > With a little care, multi- homing could be > supported. I suspect that mobile IP would be a lot easier as > well. In contrast, if we fix the DNS to track the topology, > names would have to replace addresses in tcp control blocks > (and packets and many other places) before we would start to > see the aforementioned benefits. > > I have proposed a simple, scalable mapping service that is > vaguely like the DNS in structure but whose purpose is to map > 128-bit identifiers into 128-bit locators (where these > locators correspond to what we currently use as addresses and > treat more as routes) in a flexible way. A request to the > root of this mapping service would be of the form, ``tell me > about this 128-bit identifier.'' A response would either be a > referal to other servers along with a mask to indicate what > other requests should go to that same set of servers or an > answer in the form of a mapping from identifier (with > possible wildcard bits indicated by a mask) to locator (also > with possible wildcards to be filled in from the identifier). The request/response is not the problem. Explain how it handles a scalable, secure update as nodes move between 802.11 hotspots of different providers. If that problem is solved, there is no reason for such a mapping system be limited to 16B fixed length strings. > The latter final response is assumed to come from a server > under the control of the owner of the identifier. Basically what I was suggesting by pushing the service to the customer edge. > Obviously, > responses would also include the usual TTL values and such > much as a DNS response does. The mapping service actually > scales a lot better than the DNS because it can increase the > depth of the tree as necessary by splitting on arbitrary bit > fields in the identifier. This should be transparent (think > unix DBM). The only thing that limits DNS is the assumption that the branching is limited. If name strings were device.customer.aol.cc... there is no real difference to parsing on a bit boundary. Tony > > Dan Lanciani > ddl@danlan.*com > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
