Re: 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
>