Subject: RE: [Mip6] WG Last call: draft-ietf-mip6-ikev2-ipsec-06.txt

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 21 Apr 2006 12:16:11 -0700

> > 
 > > => And was never accepted in the spec. I know it was discussed
 > > numerous times.
 > 
 > it was accepted as part of the privacy solutions.
 > it is used when you want to hide the home address
 > from the access network. there is some progress
 > in the mobopts working group on this.

=> This is not relevant to my statement, I'm referring 
to the MIPv6 specs 3775/6. Transport mode in general is
needed for HOTI/HOT, it's useless when the sender is protecting
packets for the ultimate receiver with IPsec. This is what
transport mode is for! Mobopts is not part of IETF and has no bearing 
on this discussion. 

Finally, this draft should not be inventing new packet formats for
MIPv6.
The purpose is to make sure that IKEv2/new IPsec specs can work
with mipv6, not to introduce new features that we could have done with
the old specs anyway but chose not to. 

Hesham

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 21 Apr 2006 12:26:00 -0700

Soliman, Hesham wrote:
> needed for HOTI/HOT, 

I guess you meant tunnel mode.

> it's useless when the sender is protecting
> packets for the ultimate receiver with IPsec. 

its useful when you want to setup only one
tunnel IPsec SA with the home agent for sending
and receiving BU/BAck, MPS/MPA and HoTi/HoT.

> This is what
> transport mode is for!

disagree. many times the mobile node is unable
to setup transport mode SA with the CN.

> Mobopts is not part of IETF and has no bearing 
> on this discussion. 

the idea behind Mobopts is that the initial work
gets done there and then the solutions are
eventually standardized in the working groups in
the IETF. some examples.
draft-arkko-mipshop-cga-cba-03.txt,
draft-kempf-mobopts-handover-key-01.txt.

> the old specs anyway but chose not to. 

in previous discussions it was decided that this
draft can update RFC 3775 and RFC 3776 if required.
RFC 3775 especially assumes the use of IKEv1 and
RFC 2401. RFC 2401 is incompatible with IKEv2.
IKEv2 requires RFC 4301.

---

From: Francis Dupont <[email-masked]>
Date: Sat, 22 Apr 2006 12:27:39 +0200

In your previous mail you wrote:

=> I agree but the problem is the 3775bis will not be available soon,
so following the advice of the area director the chairs decided to
include this in the IKEv2 document. In exchange I asked and got
this WGLC about this specific point, so persons (as you) who don't
agree can explain why.

Regards
   
[email-masked]