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

From: "Soliman, Hesham" <[email-masked]>
Date: Sun, 23 Apr 2006 15:41:52 -0700

> >  - BU sent to the HA
 > >  - BU sent to the CN
 > > 
 > > The draft in the subject of this email deals with the 
 > > former, there is *no* CN involvement here. 
 > 
 > for using temporary HoA instead of actual HoA in
 > payload traffic, there is a need to modify the CN.

=> This is an issue you created, that's not the issue I'm
raising. In this draft the only thing you're doing is hiding 
the HoA in the BU from the access network. So if you want 
to compare apples and apples one would have to say that
you can do the same thing by using a pseudo HoA in the BU. 
You're not hiding anything from the CN in this draft so I don't
know why you're comparing it with another proposal that tries
to hide the HoA from the CN.

 > If you want
 > > to create a pseudo HoA between the MN and HA you can 
 > > do that without involving the CN. 
 > 
 > why would I? if I am sending a BU to the HA and
 > do not want the access network to see the HoA, I
 > just tunnel it and put ESP with non-null
 > encryption between the two IP headers. simple.
 > no pseudo HoA stuff.

=> That's you preferred solution, clearly, but it's not
the only way to do it. If you want to discuss pros and cons
for privacy then we can do that, but we can't be forced to
use this solution for privacy when there are others, and it's
out of scope of this draft.

Hesham

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

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 23 Apr 2006 15:44:40 -0700

> you can do the same thing by using a pseudo HoA in the BU. 

that requires additional specification.

> to hide the HoA from the CN.

duh? both solutions are complementary in case
you weren't following the discussion.

> out of scope of this draft.

sure. nobody is forcing anything. its an optional
feature.

Vijay