Hi Raj > 3. Also, why its a VID payload, Notify suits better. Because a third > party client will want to connect to some other server. Please give > justification for IKE_AUTH_NO_CHILD to be a VID.
Section 3.12 of -bis document says "A Vendor ID payload MAY announce that the sender is capable of accepting certain extensions to this protcol..." Using a VID has one advantage over a Notify, in that you don't need IANA to allocate a value. With a Notify, I would not be able to get a number from IANA until the document was ready for publication which can take over a year. Implementations that want to support this would need to use a temporary private use notify type, and then protect it with a VID payload (which would not be interoperable, because every vendor would choose a different value and VID). After the document is published, a new version of the product can use a IANA-assigned notify type, but because different products are out there, you need to support for a long time the old private-use type with its VID. Doing it all with VID is simpler and allows continuity between draft and RFC implementations. In IKEv1 it was common to use VIDs to indicate support for an externsion. See for example, RFC 3947. Email secured by Check Point If we think we are going to allow IKE_AUTH without CHILD SA, i feel notification of IKE_AUTH_NO_CHILD_SA type will be better because VIDs are limited to proprietary use and if any implementation want to support this extension for their products, it can choose a VALUE value for this notification and can update to a new value when IANA assigns it. http://tools.ietf.org/html/draft-ietf-ipsecme-ikev2-redirect-10 is good example of it. Thanks, Raj I don't see why VIDs are limited to proprietary use, and implementations don't get updated fast enough to allow them to just "switch" to the new IANA-assigned value. The example of RFC 3947 is illuminating. The drafts had a different VID value then the RFC. Microsoft implemented the draft version (from draft-02 IIRC) and all gateways that support L2TP clients still must support both the draft VID and the RFC VID. While we might rely on vendors updating their implementations, we can't rely on customers to do so. Email secured by Check Point
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
