Re: about Wedgelayer 3.5 / Fat IP approaches

El 28/06/2004, a las 1:51, Erik Nordmark escribió:

>> Among the multiple approaches that have been included within the
>> Wedgelayer 3.5 / Fat IP class, we can find very different mechanisms
>> imho. I I think that additional discussion is needed to understand
>> which one of the different approaches (not particular solution, but
>> general approach) would better fulfill our needs. the goal of this
>> message is then, to provide my opinion of some of the benefits and
>> limitations of each approach in order to foster discussion of this
>> topic.
>>
>> So, as is see it the approaches included within the Wedgelayer 3.5 /
>> Fat IP class use the following types of ULP identifiers:
>> - 128 bit long CBIDs (HIP, SIM)
>> - CGAs (cb64)
>> - Locators (i.e. the use a locators as the ULP id) (NOID, ODT)
>> - ephemeral ids (WIMP, MAST?)
>
> What I'm about to write might make things more confusing, but hopefully
> also more clear.
>
> I think conceptually we are using identifiers for two different 
> purposes,
> but in many (not all) cases the same bit strings serve both purposes.
> 1. A handle passed to the applications that can be used for things like
>     - comparisons
>     - callbacks and referrals
>

I would add initial contact to this list. I mean, an initiator must 
have a stable string to properly indicated the other endpoint of the 
communication.

> 2. A thing used inside the multi6 (sub)layer as part of preventing 
> redirection
>    attacks.
>

This would be essentially what pbk deals with, i guess

Would it be correct to say that the applications have to be aware of 
the string used for #1 but it is not required that apps are aware of 
the string used for #2?

(i am highlighting the *internal* of the #2)

> A current case where they are not the same is in the (now expired) 
> cb64 draft,
> where the application sees a 128-bit handle with IP address semantics,
> but the multi6 layer uses the 64 last bits as a hash of a public key.
> In Santa Monica after the meeting Jukka Ylitalo brought up another 
> interesting
> thing to try; using NOID-style AIDs with WIMP ephemeral IDs underneath.
> (Sounds a bit complex to me, but well worth exploring to further our
> understanding in this space.)

this would mean that you would use hash chains values for #2 and 
regular ip addresses for #1?


>
> Furthermore, we definitely need to be concerned about #1 for existing
> applications. But it migth also make sense to think about applications
> that have been modified to be multi6-aware.
>
> For instance, calling the getpeername() API might return what is 
> essentially
> a designated locator for the peer, which provides support for 
> unmodified
> applications. But we could decide to crate getpeerid() and 
> getpeerlocators()
> which would return more information to modified applications.
> This might mean that unmodified applications would receive limited
> support for callbacks and referrals when a locator becomes unreachable,
> but the modified applications would be robust against such failures.
>

Another case, imho would be to consider a non multi6 aware application 
running on a multi6 aware host.
In this case, the multi6 layer could provide enhanced services and 
preserve connectivity even if the locator used on the refferral or call 
back becomes unreachable.
So i guess that we can have 4 cases:
a- non multi6 aware app running on a non multi6 aware host: in this 
case a locator must be used for refferals
b- non multi6 aware app running on a multi6 aware host: in this case 
the app will pass the 128 bit string that it is using to the other end. 
So the multi6 layer has to be capable to obtain the locator set form 
this 128 bit string i.e. we need an id to locator mapping mechanism
c- multi6 aware app running on a non multi6 aware host: the app could 
pass both the id and the locator set, We don't need nothing more than 
upgrading all the apps :-)
d- multi6 aware app running on a multi6 aware host: both solutions work 
fine

imho, an appealing approach would be one that uses valid locators as 
ids, in order to support a) and since we are using locaotrs, we can use 
the reverse DNs to provide the mapping system needed for b)

regards, marcelo

>    Erik
>