names, addresses, routes

Pekka,

(new subject, to define what I think is a new thread.)


PN> Well, I consider an *identifier* as something that is more or
PN> less intrisically bound to an identity and a *name* as something
PN> that merely indicates an entity,

I had not run into this distinction before.  Now that you raise the
point, I guess I have been thinking of identifier as an intentionally
fuzzy, general term, with name being a more specific reference.

Separate from discussing the merits and details of the specific
distinction you draw, I think your note highlights the need to make sure
we have some common terminology.

I do not understand "intrinsically bound", but it sounds interesting.

I am used to terminology use that derives from Shoch.  A name says what
a thing is, but nothing about where or how to get to it. It can be a
random bit string that unique identifies the entity. Any non-randomness
to the string will be relevant to administration of the string
assignment, but will not provide any information about the location of
the entity or how to reach it.  Two entities that are topological
neighbors are free to have unrelated names.

Addresses contain information about location -- typically topological
location. (The possibility of geographic location gets bandies about,
sometimes.) Addresses are also globally unique.

Routes give directions about how to reach the entity. Routes are
relative to the starting point.


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.

I guess I need some examples to understand this.


PN>  From this point of view, IP addresses are identifiers.

IP addresses have bits that are structured, semantic indicators of
topological location. There is serious semantics in an IP address, not
just guaranteed uniqueness.

That said, an address at one layer of processing is usually a name to
the next layer down.  For example an email "address" divides into two
names, one for the mailbox and one for the containing host.


PN> However, they
PN> are not end-point identifiers but identifiers for topological
PN> locations within the routed network.

In trying to think about mobility, I have been finding this point
extremely helpful. IP addresses define a point of attachment -- a
network interface -- rather than a host interface, as we are used to
saying. As the host interface moves, relative to network attachments, it
needs new IP addresses.

Hence a mobility mechanism needs to support end-to-end exchanges that
may have changing IP addresses over the life of the association.


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.

I probably need to see some examples, here, to understand your point.


PN> Furthermore, I find it hard to
PN> imagine situations where you want to reference objects that are
PN> really outside of any context; IMHO there is always some context,
PN> and names are always bound to such a context.

darn.  you caught me in a fuzzy specification.

What I meant by 'context' was an existing relationship between the two
entities.  When I first contact a server, there is no context.
Afterwards there might be.  How do I find the server that first time?
Is there -- or can there be -- any difference in how I find it later?

The simple example of my finding a server is the difference between
using its domain name versus using its IP address (in the TCP control
block or, at least, the client DNS cache.

It's worth noting that client-side mobility is a very different problem
from peer-to-peer mobility.  Hence, something like MAST is entirely
adequate when it is only the client that is moving around.  The client
can re-find the server the same way it originally did.  With P2P, that
does not work, unless each moving host updates its entry in the
mechanism used to find it.  So, we might consider using dynamic DNS for
this, though I suspect it's not the right solution.

If the mobility is rapid and frequent, the extra traffic and delay of
DNS queries is likely not to be the right answer.

However note that the Internet infrastructure has no problem sending
consecutive packets to different places, as long as they have different
IP addresses.  Hence, the infrastructure can handle mobility just fine
(as long as we ignore the question of forwarded packets that arrive
after the recipient has moved.)


PN> In my opinion, domain names are probably good for coarse grain
PN> rendezvous and expecially object reference (e.g. URLs).  They have
PN> their problems in disconnected networks, but LLMNR / mDNS seems
PN> to help there.

I think the question for disconnected networks is what would work
better, and why.  There might be a way to have domain names satisfy
them, just so we do not have to deal with multiple name spaces.


PN>   On the other hand, domain names are not very good
PN> for security.

I've been trained to prefer separating security from naming.
Overloading the two gets confusing and often doesn't work very well.

In any event, please clarify what security concerns you have.


PN> You need some external infrastructure, and unfortunately
PN> our strawman economic analysis shows that secure DNS may be
PN> economicly infeasibile.

huh?


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>