Pekka,
PN> Merriam-Webster on-line defines as follows:
uh oh. when discussion starts including dictionary definitions, it is
often worth stepping back and making sure that the right issue is being
discussed.
I was not criticising your usage, but rather noting that it was
different from mine. And that observation was only intended to be
relevant as an indicator that we (the community) probably do not have
sufficient commonality to our use of the terms, for this line of
discussion.
This being a technical discussion, we had better have some useful,
technical definitions. Then we can switch to having a debate about
problems and solutions. There is technical history to the terms at
issue, here. However they suffer different definitions in different
technical discussions.
That's bad, at least until we all agree on a single set of definitions.
DC>> I do not understand "intrinsically bound", but it sounds interesting.
PN> Well, in my thinking a specific identifier is only able
PN> to denote a specific entity. That is, the relationship
PN> between an identifier and the corresponding identity should
PN> be a function, i.e., there must not be any identifiers
PN> that denote more than one entities. Typically the
PN> relationship is (or should be) bijective.
Apologies, but I am still not understanding well enough, I think. By
way of seeing whether I am understanding at all:
Some mappings between strings and objects are by arbitrary assignment.
Some have a "semantic" process so that the string actually can be
analyzed. Calling a computer "aland" does not really tell you anything
about it, nevermind also not telling you where it is. Calling it
"aland.bbn.com" at least tells you something about the
administrative agency that assigned the name. (It still does not tell
you anything about where it is, even though you might think it does.)
Also, aland is likely not to have a unique, whereas aland.bbn.com is
required to be unique.
(The question of uniqueness depends on context. For most
computer-related assignment processes, uniqueness is required.)
PN>> In other words, an identifier implies sameness and stability of
PN>> the identified entity, while a name does not have those connotations
PN>> to the same extent.
DC>> I guess I need some examples to understand this.
PN> Well, as I wrote above, I think that a name can be re-bound
PN> while an identifier should not be re-bindable.
In the Internet context. what would be an example of an identifier that
cannot be re-bound? (And let me alert you to my belief that all of them
can be. So when you provide your example, please anticipate that I will
be likely to cite examples that show the non-rebinding feature is a
matter of policy, or otherwise itself is "re-bindable"... In other
words, all this stuff depends on precise -- and often arbitrary --
definitions and policy.)
PN> In a
PN> micro-mobility solution, it may make sense to use IP addresses more
PN> like topology-unrelated names, and record a route for each address
PN> separately.
right. as you noted later in your reply, whenever we talk about mobility
we need to be careful to specify scope of possible change and rate of
possible change. extremes seem to demand very different solutions.
DC>> Hence a mobility mechanism needs to support end-to-end exchanges that
DC>> may have changing IP addresses over the life of the association.
PN> I concur. Furthermore, not only (macro)mobility mechanisms but
PN> also multi-address multi-homing mechanisms.
I'm finding myself viewing multi-homing as a simple (ie, degenerate)
case of mobility.
PN>> Now, you may be able to do rendezvous with just names, e.g., with
PN>> domain names. And for referencing external objects, it is often much
PN>> better to use names than identifiers.
PN> Rendezvous is needed for two purposes:
PN> - to allow initial connections
PN> - to resolve the loss of working addresses caused by
PN> simultaneous movement
ack.
PN> As you write, the difference between client-side mobilty and P2P
PN> mobility lies in rendezvous. On the other hand, we also have to
PN> remember that more and more servers are becoming mobile, in some way
PN> or another (re-hosting, network re-numbering, etc). Hence, I would
PN> not consider these two types of mobility that different.
In the long term, no. but it's worth considering a simpler solution,
for the simpler case, if a) we think there will be significant benefit,
and b) deferring the more difficult part does not make it harder or less
likely to be solved.
The mobile-client/stable-server example requires no new rendezvous
mechanism and I think it covers a very, very large portion of current
mobility needs. And I think that the rendezvous function needed for
mutual mobility can be solved independently. So there is no real
disadvantage to deferring it from the "addressing" problem.
PN> No problem here. On the other hand, if we had proper and secure
PN> identifiers, packet forwarding would not be an architectural
PN> problem, either.
we probably disagree. packet forwarding requires creating additional
infrastructure, as we have been seeing for the considerable number of
years of effort for the mobile ip work. that's another reason for
carving off forwarding to be separate from higher-level
(non-infrastructure) mobility support. At that point, forwarding
becomes an optimization, rather than a necessity.
PN>> On the other hand, domain names are not very good
PN>> for security.
DC>> I've been trained to prefer separating security from naming.
DC>> Overloading the two gets confusing and often doesn't work very well.
PN> With all respect, IMHO separating naming and security is a
PN> serious mistake. All security is based on identifiability.
PN> If you cannot securely identify you peers, you can't do much.
I didn't mean that security wasn't important. I mean that separating
the security mechanism from the name administration (and, therefore, the
"meaning" of the name) is usually better.
Clearly, the ability to hijack a name can be a very serious danger.
DC>> In any event, please clarify what security concerns you have.
PN> Well, I am mostly concerned secure identifiability. Is that
PN> clear enough, or should I pursue the issue more?
a bit more, please. remember that we are trying to understand why
end-point identifiers are required, or at least what they are required
for. i'm not seeing how security is a serious issue for that goal.
PN> For now, it suffices to
PN> notice that the immediate incentives for people to start
PN> using decure DNS are fairly slim, at least compared to the
PN> efford required.
Alas, the IETF has an essentially unbroken track record of failing to
gain large-scale use for any security technology created in the IETF.
I am used to terminology use that derives from Shoch
ASUS> Shoch convention of "names, addresses, routes" was
ASUS> found to be ambigous in many contexts. Please refer
ASUS> RFC 1498 - where Saltzer points out some of the
ASUS> problems with shoch terminology.
That's why I said "derived".
d/
--
Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
Brandenburg InternetWorking <http://www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>