[...] it looks to me that stable end-point identifiers are mainly needed to make applications survive IP address changes. ...
There is more to stable end-point identifiers than just the ability to
make an application resilient. I will argue that IP addresses *do not*
identify end-points, but node interfaces.
I think we agree. At least I think we agree pretty much on the role of IP addresses. I would even go further, and state that IP addresses identify network interfaces, not node interfaces, as Dave Crocker recently put it.
Personally, I do believe that we should have explicit names for end-points, e.g., due to the reasons that you explained. However, I am not quite sure if everybody agrees with that. Hence, what I am merely trying to say is that we probably *could* continue to live without explicit end-point identifiers, and still get the desired mobility and multi-homing properties.
Even facing the danger of opening yet another rat hole, in my opinion we should not have a very strict definition for end-point. That is, IMHO end-point should and could be a fuzzy concept, somewhat like the concept of a site is today.
From my point of view, an end-point may be a process, a group of processes, a host, or even a server cluster offering services as a unit. To me, it looks like fate sharing and common semantics are the
key points here. An end-point should either work or fail, it should
not be usual for half of an end-point fail while the other half is continuing. An end-point should also be considered at the application level as a single unit.
The question that that raises is, whether it is reasonable to use such an inclusive notion of an end-point, and what is the simplest kind of structure or object we can use to implement an end-point identifier? We might have to restrict the notion of an end-point somewhat.
Well, as I tried to say, I'd prefer to have some functional and semantic restrictions, and not just denotational restrictions. That is, if we say that an end-point must fail as a unit, that is a reasonable restriction. Likewise, if we say that an end-point must act as if it had unique state, that is a good restriction, too. That does not preclude one from creating distributed end-points, as long as each distributed end-point appears to have a unique state at each point of time.
A related question is also the structure and semantics of the end-point identifiers. The simplest identifiers would be sufficiently long random numbers, with a probability of collisions low enough. However, I tend to believe in identifiers that have more structure, and preferably even cryptographic semantics.
More on a new thread.
--Pekka Nikander