Re: A lowest layer with location independent identifiers with more than one protocols

>> 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