Re: issue 4: how to signal support for MOBIKE

My interpretation of this thread is that most people
prefer the Notify approach, and it is sufficient for
our needs. Based on the question from Tarique, I would
add that we need to allow MOBIKE support to be notified
at any time (but never turned off, it does not seem
to make sense).

Pasi, I think you can mark this issue closed on the issues
page.

Hannes, I think you can use the text that you posted
a while ago, updated with the decision to use Notify
and a discussion of the timing of this Notify.

--Jari

Jari Arkko wrote:
> Yes. We shall only have one. Based on Hannes' analysis,
> both options seem to provide the same functionality.
> I am personally fine with either approach. Given that
> we are writing a design draft, perhaps we should make
> a design decision and pick one? It seems that a few people
> preferred the Notify. I'm not sure I understood Tero's
> objection to Vendor ID, but at least Notify sounds nicer.
> Pick that and move one to the next issue?
> 
> --Jari
> 
> James Kempf wrote:
> 
>> I think we ought to choose either Vendor ID or Notify. While I support
>> Notify (since this is a standardized, and not a vendor specific, 
>> option), I
>> would rather go with Vendor ID if that's what a majority of the WG wants
>> rather than have both.
>>
>>             jak
>>
>> ----- Original Message ----- From: "Dondeti, Lakshminath" 
>> <[email protected]>
>> To: "Tschofenig Hannes" <[email protected]>
>> Cc: "MOBIKE Mailing List" <[email protected]>; <[email protected]>;
>> "Tero Kivinen" <[email protected]>
>> Sent: Monday, December 06, 2004 10:23 AM
>> Subject: Re: [Mobike] issue 4: how to signal support for MOBIKE
>>
>>
>>
>>> This sounds good.  I was initially leaning toward Notify only, but there
>>> is no harm in allowing Vendor ID.  I wouldn't necessarily suggest the
>>> use of "critical bit" here.  Clearly, an implementation may choose to
>>> use that feature, but there is no need to make that suggestion in each
>>> context. Thanks.
>>>
>>> regards,
>>> Lakshminath
>>>
>>> Tschofenig Hannes wrote:
>>>
>>>
>>>> hi all,
>>>>
>>>> i went thought about the two most important options: notify and vendor
>>
>>
>> id
>>
>>>> they both seem to provide the same capability. notify is used for
>>>> errors but
>>>> also for indicating sender capabilities. the same is true for the
>>>> vendor id.
>>>>
>>>>
>>>> as a text proposal i suggest to enhance the text offered by jari as
>>>> follows:
>>>>
>>>> -----------------------
>>>>
>>>> X. Indicating Support for MOBIKE
>>>>
>>>> A node needs to be able to guarantee that its address change messages
>>
>>
>> are
>>
>>>> understood by the peer. Otherwise an address change may render the
>>>> connection useless, and it is important that both sides realize this as
>>>> early as possible.
>>>>
>>>> Ensuring that the messages are understood can in be arranged either by
>>>> marking some IKEv2 payloads critical so that they are either processed
>>>> or an
>>>> error message is returned, by using Vendor ID payloads or via a Notify.
>>>>
>>>> The first solution approach is to use Vendor ID payloads during the
>>>> initial
>>>> IKEv2 exchange using a specific string denoting MOBIKE to signal the
>>>> support
>>>> of the MOBIKE protocol. This ensures that in all cases a MOBIKE
>>>> capable node
>>>> knows whether its peer supports MOBIKE or not.
>>>>
>>>> The second solution approach uses the Notify payload which is also
>>>> used for
>>>> NAT detection (via NAT_DETECTION_SOURCE_IP and
>>>> NAT_DETECTION_DESTINATION_IP), .
>>>>
>>>> Both, a Vendor ID and a Notify payload, might be used to indicate the
>>>> support of certain extensions.
>>>>
>>>> Note that the node could also attempt MOBIKE optimistically with the
>>>> critical bit set to one when a movement has occurred. The drawback of
>>>> this
>>>> approach is, however, that the an unnecessary MOBIKE message round is
>>>> introduced on the first movement.
>>>>
>>>> -----------------------
>>>>
>>>> ciao
>>>> hannes
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Tero Kivinen [mailto:[email protected]]
>>>>> Sent: Dienstag, 30. November 2004 11:41
>>>>> To: [email protected]
>>>>> Cc: MOBIKE Mailing List
>>>>> Subject: [Mobike] issue 4: how to signal support for MOBIKE
>>>>>
>>>>> Jari Arkko writes:
>>>>>
>>>>>> So I would suggest that we use the Vendor ID approach.
>>>>>
>>>>>
>>>>> I would suggest NOTIFY approach. I.e we send notify saying
>>>>> MOBIKE_SUPPORTED and thats it. Similar thatn what is done for
>>>>> the NAT-T or the IPCOMP_SUPPORTED or USE_TRANSPORT_MODE etc.
>>>>>
>>>>> In most cases we do not want to fail the negotiation even if
>>>>> the other end does not support MOBIKE, we simply revert back
>>>>> to redoing the authentication every time IP-addresses changes.
>>>>>
>>>>> If our final protocol is going to use notifies to send the
>>>>> IP-addresses, then we can use those notifies to signal the
>>>>> use of MOBIKE instead of separate MOBIKE_SUPPORTED notify.
>>>>> -- 
>>>>> [email protected]
>>>>> _______________________________________________
>>>>> Mobike mailing list
>>>>> [email protected]
>>>>> https://www.machshav.com/mailman/listinfo.cgi/mobike
>>>>>
>>>>
>>>> _______________________________________________
>>>> Mobike mailing list
>>>> [email protected]
>>>> https://www.machshav.com/mailman/listinfo.cgi/mobike
>>>>
>>>
>>> _______________________________________________
>>> Mobike mailing list
>>> [email protected]
>>> https://www.machshav.com/mailman/listinfo.cgi/mobike
>>>
>>
>>
>>
>> _______________________________________________
>> Mobike mailing list
>> [email protected]
>> https://www.machshav.com/mailman/listinfo.cgi/mobike
>>
>>
> 
> _______________________________________________
> Mobike mailing list
> [email protected]
> https://www.machshav.com/mailman/listinfo.cgi/mobike
> 
>