Subject: portable identifiers for session stability, multi-homing, etc. (Was: AN interesting article. FYI...)

From: Dan Lanciani <[email-masked]>
Date: Sun, 19 Sep 1999 03:15:28 -0400 (EDT)

[combining responses]

[email-masked] (Niels Mvller) wrote:

|Is there any particular reason why not allocate the identifiers as a
|subspace of the IPv6 address spase (outside of the aggregatable
|unicast space, of course)?

As I pointed out, the existing space could be split on one bit to do
exactly that.  I did not make that part of the base proposal because
I feared it would meet with objections that the routable space absolutely
needs every one of the existing bits.  It would also make the approach
depend on the cooperation of an addressing authority where otherwise
it need not.

|I imagine that would make gradual
|deployment easier; to a host that doesn't know how to map identifier
|addresses, those addresses will simply appear to be unreachable. (It's
|even conceivable to let the local router do the mapping and
|source-route them to the right aggregatable address).

I believe I covered this.

|> I propose a set of servers, similar in many respects to the DNS but
|> designed to facilitate efficient and secure dynamic data updates
|> throughout its fabric while also allowing easy and transparent
|> splitting of zones (i.e., dynamic delegation) to insure scalability.
|
|I suspect this is the difficult part of it all.

I believe I mentioned that as well. :)

|You need some sort of
|hierarchy in order to distribute management and allocation of the
|"identity addresses", where higher nodes delegates part of the space
|to lower nodes, just like in DNS.

You need (or at least would like) a computational hierarchy.  I'm not sure
you need or want a hierarchy of providers if it can be avoided.

|And there are some other interesting
|points comparing this to DNS:
|
|1. Switching "identity provider" is analogous to switching DNS
|   provider. I.e. it implies that your identity or FQDN changes, as
|   the point where it is attached in the delegation hierarchy changes.

You are introducing a concept which virtually defeats the purpose of
my proposal.  I think this is a situation that does not benefit from
multiple administrations.

|2. Currently, DNS-space is not much of a hierarchy. It seems all
|   "sites" buy a name of the type "foo.com.", and put all externally
|   visible machines there. Really large sites or corporations may have
|   one more step of internal delegation. The point is, that this
|   appears to actually work. So perhaps it's good enough to have a flat
|   identity space, or at most two-level space?

As I explained, it would be best to have a space which can split transparently
as it grows, much like DBM hash key space.  It can start out with a single
server and grow as necessary.  Growth does not imply new political registry
entities, just more machines.  At least in an ideal world.  But I suppose
we start getting back to monopoly arguments...

|Another question is exactly what advantage the short "binary"
|addresses have over dns names. You say that they fit easier into
|packet headers, tcp control blocks, etc.

They also fit the existing socket API with no changes.  In other words,
my proposal could work today without wholesale changes above the stack.

|If that is the main reason to
|use them rather than FQDN:s, perhaps we could get away with
|representing a FQDN with its md5 sum, and we will have at least one
|step in the lookup process for free.  Or if that won't work, I think
|the reason why may give some information about the nature of the
|problem.

You seem to be talking about a somewhat different model where
user-level applications probably interact with the mapping.  I'm
not saying this isn't a useful model, but it probably has little
to do with the one I proposed.

|Hmm. Anyway, I don't think this problem will be solved by me or
|anybody else popping ideas from their head.

Well, if the ideas don't come from anybody's head, where will they come from?
Even big committees get their ideas from the members' heads...  I continue to
be perplexed by the untouchable status accorded to this issue.

Thomas Narten <[email-masked]> wrote:

|A few comments.  Unfortunatley, I don't have the time right now to
|respond to all of your proposal in detail,

No problem.  If there is in fact interest, I'm sure others will respond. :)

|but I will observe that
|there are a number of details missing. Unfortunately, the devil is in
|the details and without the details, its hard to call out specific
|issues.

Actually, I believe I outlined an approach at a sufficient level of detail
for a skilled and motivated implementor to prototype a sample in a few
weeks.  A key point is that most of the protocol interactions are sufficiently
similar to existing material that they (and even the code to implement them)
could be readily borrowed.  I'm not sure that it benefits a discussion to start
with a significantly lower-level description than what I gave, but perhaps
that's because I'm too familiar with the kind of code in question.

|Also, you raise an oft-expressed feeling that all that needs to happen
|is for some folks to go off and design such a system.

Not at all.  If I believed that this were true then I would happily design
and implement such a system.  We first should answer the questions I posed:

>>>Do we wish to make it so or not?  If not, why not?  If so, what price
>>>are we willing to pay resource-wise?

There is no point in implementing a solution if in fact _any_ solution
is already deemed undesirable simply because it is a solution or because
it has any non-zero cost.  I happen to think that it would be very useful
to at least get the hooks for some kind of portable identifiers (it certainly
doesn't have to be my proposal) into the protocol before extensive deployment
makes retrofit impossible, but others may well disagree that it is worth
the price.  However, without something along these lines, useful features like
multi-homing may well remain expensive value-added services available only to
big/rich players.  This would be unfortunate, but such is life...

|And, (and this is _key_) would
|the resultant system be any better than what we already have in terms
|of total overall cost, understandabilty, robustness, operational
|complexity, etc?

It's extremely difficult to define "better" in this context without knowing
for whom it is better.  Portable identifiers offer benefits mainly to end
users in the form of flexibility.  They offer little to ISPs and may even
be a negative.  Some of the other attributes you site are mainly the concern
of those ISPs.  It will always be possible for someone in some camp to claim
that there is absolutely no benefit _for them_ in portable identifiers and thus
no tradeoff with any kind of cost is allowable to achieve them.  To understand
total _overall_ cost we would have to know how much non-portable addresses are
going to cost end users.  That is very hard to quantify, though I maintain that
it is by no means negligible.

|I often think that one of curses of IPv4 is that
|both its strengths and weaknesses are well understood. People tend to
|focus on the weaknesses (e.g., non-portable addresses) and
|consequently the grass looks greener on the other side of the hill.

Oddly, I've always looked at portable addresses as a strength of IPv4.
I guess it's just a matter of how long one has been involved...

|Case in point: if we separate the identifier and locator portions of
|an address, one almost certainly needs a way of mapping the identifier
|into an locator. This problem is one that we don't know if it can be
|reasonably solved without seeing the details of a specific
|proposal. Just saying "servers do the mapping" is hand waving.

Ah, but I have a really _good_ hand waving argument.  It's not an argument
that what I suggested can be done, but it's the next best thing.  Again: any
argument that we can't provide a mapping from one fixed-length identifier to
another with current DNS-like technology in the face of currently anticipated
levels of renumbering is equally an argument that we can't support the DNS
itself.  If we can't support the DNS then IPv6 is dead.  On the other hand,
assuming IPv6 is not dead and the DNS can work then we can certainly deploy an
identifier mapping implementation that is at least as scalable as that DNS.  I
would argue that by engineering that implementation for this kind of service in
the first place we can do even better than the DNS, in particular with respect
to dynamic updating.  But that would be gravy, and even if I'm completely wrong
the implementation could always evolve at least as rapidly as the DNS itself
could.  Of course, to the extent that my proposal was deployed, the DNS would
not have to evolve (since it would be dealing with the portable/stable
identifiers) and redundant effort could be avoided.  (Note that I am not
proposing to use the DNS to map the identifiers.  I am merely making an analogy
to the complexity and scalability.)

A couple more hand waving arguments that are less convoluted:

-There is a class of problems that can be solved by adding another level of
indirection.  (The mobile IP efforts generally recognize this, though they
typically deal with indirection of each packet through an intermediate.)  I
believe that the portability/stability/multi-homing problem is of this class.
I have a question for those who follow IP mobility more closely than I: if we
assume hypothetically that my proposal were deployed, could it subsume the
functions of mobile IP/IP mobility or are there collateral services needed
beyond the indirection?

-My approach tends to distribute part of the routing table computation and
storage (i.e., that part dealing with the aspect of portable addresses which
is thought to be so troublesome for core router scaling) to the end nodes.
This can readily transform an O(nodes) problem in the core into an O(1) problem
in each node: the same growth that works against a centralized solution cancels
itself in a distributed one.  There is nothing particularly new here; it's just
the source routing argument without explicit source routes.  Looking at it
from a different perspective, routable IPv6 addresses *are* routes.

|It is an enduring myth that backbone routing can scale arbitrarily and
|that the only issue is an implementation defficiency from one vendor
|(which has long since been fixed).

As I said, it's really hard to discuss scalability without a basis in
various economic assumptions.  IMHO, the myth is that it is completely
obvious that portable address routing cannot scale in general based on
experience with one particular full-knowledge flat model.  I'm not saying
it isn't true (and I'm not saying it is), but I don't believe it is obvious.
I hope we can agree to disagree on this point and simply sidestep the issue.
I designed my proposal to place no additional routing table load on the core
and in fact to require no cooperation at all therefrom.

So far the main objection to my proposal has been the header bloat from
carrying around the portable source & destination identifiers.  I agree
that this is unfortunate and I think that, if necessary, the identifiers
can be removed and inferred on reception.  There is some cost in complexity
and flexibility, so perhaps the inclusion of the identifiers could be turned
on and off at a host's option.  Also, I haven't thought through the details
as carefully as for the base proposal, but I think the following would work:

-The destination routable address can easily be mapped to the the destination
host's portable identifier based on that host's own knowledge.  This is trivial.

-The source routable address can be mapped to a portable identifier if the
forward mapping is already in the destination host's cache.  If it is not
then the destination host would send a query to the source routable address
to request its portable identifier.  The destination host would then perform
a forward lookup to verify the mapping before putting it in the cache.  The
intent of the forward lookup is to avoid reducing the trustability of source
addresses: although it's a bad idea to trust addresses in the first place, we
would probably prefer not to significantly worsen the situation for programs
that do just that.

-As an optimization to reduce traffic, a host could send a preemptive hint
of its identifier mapping concurrently with its first communication to a
host which was not already in its cache.  This saves the initial "reverse-
lookup" but does not relieve the target host of the forward lookup.

Quality Quorum <[email-masked]> wrote:

|Hi,
|
|I have simple Joe-six-pack question about renumbering.
|
|If I have IP session (TCP or UDP) and renumbering event happen on
|either end of the connection, then I suppose that my connection will 
|not survive.

Unless something changes, it will not.

|It does not seem like a big deal if session reestablishment 
|will be transparently handled by a protocol stack,

Even if this were the case, it would work only if your application didn't
need to know its address or figured out that it had changed.

|however, it seems like 
|it is not the case, moreover, it seems like say UPD client has no 
|way to figure out that UDP server experienced renumbering events, am
|I correct about it ?

Pretty much.  There is a continuum of applications from ones that are
largely oblivious to their address (or even domain name) to ones that
constantly pass binary addresses across the API and across the net.
TCP tends to make the former possible and UDP tends to encourage the
latter, but you can conceive counter-examples.  A UDP application could
do a DNS lookup before each send.  Assuming a DDNS implementation that
is updated by the renumbering event, the application could survive.  There
is talk of an API based only on names (no numbers) but it will be hard to
retrofit all applications to use it and there are still issues with the
protocol's own recovery from a renumbering event.

Unfortunately, there seems to be some resistance to a names-based API even for
applications that really have no need to deal with a lower-level representation.
Back in the days of tcp/ip API chaos on the PC (this is long before winsock at
a time when both DOS and Windows interfaces were important with DOS perhaps
more so) I pushed hard for a names-based API for simple client-only applications
including mail and news readers.  I even offered to write the appropriate shims
for a few of the popular stacks.  Most folks were violently opposed to the idea.
I never really understood, especially the part about wanting to keep domain
resolution in the application (in spite of the fact that this didn't work for
sites using YP).  Very strange...

				Dan Lanciani
				[email-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------