"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.
|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. 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. 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. 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 latter final response is assumed to come from a server under
the control of the owner of the identifier. 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).
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]
--------------------------------------------------------------------
