Firstly, it was determined that there seems to be some value of
providing
"a lowest layer that supports location independent identifiers"
Could you explain a little bit more what you mean by this? Lowest layer
of what & what value is there? Do you mean a lowest layer 3.5?
Well, it was really John Wroclawski who made the statement, but
I'll try to explain how I understood it.
In the good old days, i.e. before NATs, firewalls, and mobility,
when you had an IP address you could hand it around and know that
you can make a connection to that host without too much worries.
As we know well, that was all broken by NATs, firewalls, mobility,
etc.
Today, we have a number of layers where you do have identifiers
that still have the property that you can hand them around and get
your communication done. E-mail addresses and SIP URLs are good
examples. But they are application level entities, not lower in
the stack.
Now, if we had somewhere down the stack a layer with identifiers
that you can hand around and use independent of your own current
location in the network and the other node's current location,
that would have some value. In more practical terms, that means
that the layer would need to support mobility, multi-homing, middle
box traversal including legacy NATs and future architected middle
boxes, and probably some amount of security awareness to allow
authorised firewall traversal.
I am not saying that layer 3.5 is necessarily the right place
for this. There are many reasons why layer 4.5 or even 5 _might_
be more appropriate. On the other hand, having the functionality
below the socket API might have some value from the point of view
of better supporting legacy applications. But you could probably
implement things also at layer 4.5 and still make it to support
the current socket API. Indeed, I think that designing such a
protocol would be quite an interesting thing. More generally, it
looks that we need to redesign the stack from roughly middle of
layer 3 to the socket API. Such redesign is likely to involve
more than just adding a new layer 3.5 or 4.5.
Secondly, some people expressed their discomfort with the HIP approach
of combining identifiers and security. Ion Stoica and Scott Shenker
put it out nicely, saying that HIP provides
A. A mapping from a public key to an identifier, and
B. A mapping from an identifier to a set of locators
Based on this observation, we came to an analogy. Consider the case
with current TCP and UDP. They are on the same layer, and provide the
same kind of *identifier* abstraction. However, they provide different
communication semantics. In a way, one could perhaps characterise that
"UDP is TCP without congestion control". (I know, that is not quite
true, but I wish you get the point.)
I get this point, but you should at least add that different protocols
use different transport protocols because these transport protocols
provide different services.
Right. That is exactly the point. Some protocols might want to
have B but not A, for example, because they rely on other security
measures and would not get any value from A.
In the same way, there might be value to have more than one protocols
at the "lowest layer that supports location independent identifiers".
This might be useful, but you should be mindful that [the different
protocols], then, could potentially provide different services to
the protocols that run on top of them. The reasons for [selecting
to use a specific protocol], then, could be based upon the services
provided.
If generalised as I suggest to interpret your words above, I fully
concur.
--Pekka Nikander