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

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

Interesting indeed, but way out of scope for multi6.

    Brian

Pekka Nikander wrote:
>>> 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
> 
>