Re: about Wedgelayer 3.5 / Fat IP approaches

El 28/06/2004, a las 10:09, Jukka Ylitalo escribió:
>>
> Thanks for bringing this out. Yes, the initiator would use, WIMP kind 
> of,
> ephemeral identifiers (random numbers), and the responder,
> NOID kind of, routable IP-addresses at the application layer.
>

The problem is that some apps may need to make a refferal of the 
initiator, which AFAIU is using an ephemeral id.
I mean, by using a stable id for the receiver you solve the problem of 
the initial cntact, but imho not the refferal problem, since the 
initiator can also be reffered. I mean, apps that are not client/server 
wouldn't be properly supported by this model, afaics

>> 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.
>>
> I feel that we should use routable identifiers with the connect()
> and sento() kind of function calls in any case. This makes it possible 
> to be
> backward compatible with existing applications. However, the client
> side may use non-routable application identifiers. (Thus, the context
> establishment is asymmetric process, and two host may finally have two
> diferent context-pairs with them.)
>
> It would be also possible to change HIP in a way that the applications
> were to see routable IP-addresses, instead of HITs.  Basically, the 
> Multi6
> enhanced HIP would implement a NOID kind of AID-locator split. In this 
> way,
> it would be possible to use HIP in an opportunistic mode, like SSH.
> I believ that the application layer will be the key element when 
> combining different
> wedge3.5 proposals.
>
> Finally, the application identifier type is related to security 
> properties of
> any Multi6 protocol. As Marcelo wrote, we should  analyze those
> properties of different AIDs better and apply them with context
> ownership properties.
>

what about cgas?
They are locators, so you can use them for refferals to non multi6 apps 
and hosts, they allow to map from id to locators using reverse dns, and 
they are crypto in nature
seems a good candidate to me :-)

regards, marcelo

PS: i will reread the CB64 draft


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