Re: identity persistence and comparison issues

El 04/07/2004, a las 10:27, Brian E Carpenter escribió:
>>> NAT breaks this assumption of course. But we are trying to repair the
>>> damage done by NAT. So I suggest that a multi6 goal should be that 
>>> the
>>> thing an application gets back from an AAAA query, or any other 
>>> source
>>> including manual config,
>> including a referral?
>
> That is my meaning, yes.
>

ok.

I wonder if this goal doesn't imposes ULP identifiers to be routable IP 
addresses

I mean, when we consider backward compatibility in a communication 
between to hosts, we can assume that if the two hosts are multi6 
capable they will recognize each other and they will start using the 
new identifier name space and that when a multi6 capable host 
communicates with a non multi6 capable host, the multi6 capable one 
will find out that the other host don't support the multi6 solution and 
will fall back to  legacy IPv6 and will use IPv6 addresses as 
identifiers. so far everything is ok

however, if you add referrals support, the problem is that the multi6 
capable host doesn't know in which host the identifier will end up, as 
Erik has mentioned. So even if the identifier has been initially used 
between two multi6 capable hosts, in a future communication, one of 
them can use this new identifier in a referral to a non multi6 capable 
host, which will fail, since it will unable to use it as a valid 
locator.

So, coming back to the goal as you stated it:

    a multi6 goal should be that the thing an application
    gets back from an AAAA query, or any other source
    including manual config, must be a permanent identifier with the
    nice property that something below the socket API can transform it
    into a locator.

So as we don't know if the host that receives the referral is multi6 
capable, we don't know if there will be something below the socket api 
to make the transformation.
So i guess that in order to fulfill this goal and to be fully backward 
compatible, the ULP identifier adopted by the multi6 solution has to be 
a routable IP address.
The other option would be decide not to support this kind of scenario.

Regards, marcelo


>    Brian
>
>>>  must be a permanent identifier with the
>>> nice property that something below the socket API can transform it
>>> into a locator.
>>>
>> i agree with this
>> regards, marcelo
>>> Which leads me to wonder whether session survival for sessions using
>>> temporary things such as RFC 3041 addresses is a reasonable goal for
>>> multi6.
>>>
>>>    Brian
>>>
>