"Tony Hain" <[EMAIL PROTECTED]> wrote:
|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.
Why? The level of churn is determined by how often you renumber, not
by where you translate the identifier to the locator.
|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.
My proposal works equally well in end nodes or in edge routers. Obviously
you get somewhat more benefit from a shared cache on the edge router, but
you seem to be saying something more significant is going on.
|> |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.
Is existing code a reasonable argument for sticking with the current system?
Inertia seems to be the justification for much of what we have. Any new system
that required wholesale changes in higher layers would be shot down for just
that reason. You can't have it both ways.
|> 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.
This doesn't make any sense. The applications never see anything but the
portable identifiers.
|If there is a 'transparent'
|mapping function in the system, apps that expect that service will
|break.
Applications won't "expect" anything. If this system were implemented
it would simply replace what we currently call addresses with portable
identifiers.
|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.
Not the table, just the entries that are of interest to particular consumers.
Why do you believe that this is any more difficult than what DNS is currently
expected to do?
|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.
Yes, of course the source has to be mapped as well. There are different
ways to handle this, perhaps avoiding the overhead of explicitly carrying
around both values. See my original notes in the Sep. 99 archives for some
possibilities.
|> 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 !?!?!
No, you are completely missing the point. If the fast-changing mappings
are handled in a separate 128b->128b transformation (one perhaps optimized
just for this purpose) then there is no need to fix the existing DNS to deal
with fast-changing mappings. The DNS would continue to hold long-term mappings
(from name to portable identifier) which could continue to be updated with
the existing semi-manual process. The duplicate effort that is avoided is
that of enhancing the DNS to deal with fast-changing dymanic mappings.
|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.
You are introducing a different problem. I proposed only to fix the
aggregation/allocation/renumbering mess. I said it would likely make
mobile IP easier; I didn't say it would make it free. How exactly do you
think the use of arbitrary strings will solve the new problem that you
have introduced?
|If that problem is solved, there is no reason for
|such a mapping system be limited to 16B fixed length strings.
There is no correlation between solving that problem and selecting a 128->128
mapping. The latter is purely a matter of convenience for existing code.
If you want to scrap the entire existing v6 suite and start over then I'd
be happy to help, but I don't think that is going to happen. If we did do
this then we could just start with an explicit source-route model and avoid
the trap from the beginning.
|> 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.
We seem to be confusing two different things. The actual transformation
of addresses in packets can happen at end nodes or in edge routers. The
servers that provide the information necessary to perform those mappings
can exist anywhere, much as DNS servers do today. I would not be inclined
to make the latter servers resident within the edge routers, but it is not
out of the question.
|> 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.
Are you kidding? Yes, sure, if you made domain allocation hierarchical and
forced people to change their names when they changed providers then there
would be more opportunity for deepening the tree. This would make names almost
as useless as addresses. Talk about a step in the wrong direction...
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]
--------------------------------------------------------------------
