Re: KINK should referenece to IKEv2?

On Wed, 2005-01-19 at 19:20, Shoichi Sakane wrote:
> > > In my opinion from reading the minutes at the IETF50 minneapolis,
> > > there is no strict reason to change the referenece from IKEv1 to IKEv2
> > > because the ISAKMP payload in the KINK is just used to carry a set of
> > > IPsec parameters, and Notification Payloads.
> 
> > We should have a consensus whether we will discuss KINK based on rfc2401bis
> > or rfc2401.
> 
> Well I put on a KINK hat, if the KINK specification will conform to
> rfc2401bis and if the KINK won't work on the stack based on *RFC2401*,
> we won't be happy because it will take long time to deploy the stack
> based on rfc2401bis.  so we need to implement a stack based on rfc2401bis
> first before we will run a KINK function.
> 
> so we can have four choices while researching the difference between
> 2401bis and RFC2401 from KINK requirement of view:
> 
> 	1. make a standard base on both rfc2401 and IKEv1.
> 	2. make a standard base on both rfc2401 and IKEv2.
> 	3. make a standard base on both 2401bis and IKEv1.
> 	4. make a standard base on both 2401bis and IKEv2.
> 
> I would like #1 then we proceed to #4.

Somebody will need to help me (us) here: can
IKEv1 successfully establish 2401bis SA's? Can
IKEv2 successfully establish 2401 SA's? I'm _guessing_
that the answer to both is "yes", but the big question
is whether there's anything in IKEv2 what is exchanged
across the wire to inform the other side whether it's
2401 or 2401bis. If so, we may need a similar mechanism.

		Mike

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iQCVAwUAQe/dQ7MsDAj/Eq++AQJTNgP7BmifzxPdu4DYq/UQhaWSf6tV4jb8ier6
OVAWJ1/y1CZgBRuf+toHKZczuG32XTHQu89zKNgNm0slQtYDp1TTlqvnPe2fcBf3
BJ9+q0GtdcUQ5fQlqZtxW0WeU3zofP+FrO+2ZxnCsL+cyXYLcSCbS2Biuump/wVg
/FtzaNlyDp8=
=FgzP
-----END PGP SIGNATURE-----