Subject: RE: [Mip6] Concensus Call: Proxy DAD on HoA

From: Gerardo Giaretta <[email-masked]>
Date: Wed, 07 Dec 2005 11:17:36 +0100

Hi Hesham, 

please see one comment/question below..

> I think you're raising an important issue that is still not
> fully appreciated by many. 
> 
> We need to differentiate between two important and completely
> different ways of allocating the HoA:
> 
> A. An operator permanently associates a HoA with a particular 
> identity. 
> 
> B. An operator dynamically assigns a HoA to a MN when the MN boots.
> 
> RFC 3775 assumes A) above. In this case, it is fine to run DAD
> upon reception of the BU. If dynamic keying is used, it's easy
> to check the identity provided by the MN against the configured
> association between the HoA and the MN's id. 
> 
> In case B, running DAD upon reception of the BU doesn't make
> sense. If the address is allocated dynamically, then the HA
> needs to make sure that there is no collision at the time the 
> address is allocated. 

In order to understand better the rationale here, are you stating this
because it is the cleanest approach or just to avoid a recovery
mechanism in case the HoA is no more available when the HA performs
proxy-DAD?

--Gerardo

> For this reason, HMIPv6 requires that
> the IKE implementation checks that no one else has already been
> allocated that address. 
> 
> So I think we have to do the "DAD" check during the IKE negotiation.
> This is essentially the IKE policy check for MIPv6. I don't think
> this needs text changes in IKEv2 since the policy check is whatever
> you want it to be. 
> 
> In any case, I think option 2 below is the way to handle this.
> 
> Hesham
> 
> 
> 
>  > James Kempf wrote:
>  > > This issue has been the object of discussion and the 
>  > authors of the 
>  > > bootstrapping draft would like to hear from other WG 
>  > members to judge WG 
>  > > concensus. The issue is when Proxy DAD should be done on an HoA 
>  > > allocated through the Home Agent: during the MIP6 
>  > transaction as stated 
>  > > in RFC 3775 or during the IKEv2 transaction when the address is 
>  > > allocated.The following two options have been discussed on 
>  > the list:
>  > > 
>  > > 1) As specified in RFC 3775, the HoA should be Proxy-DADed 
>  > when the MN 
>  > > bootstraps MIP6 with the HA.
>  > > 
>  > > 2) The HoA should be Proxy-DADed when the MN allocates the 
>  > HoA through 
>  > > IKEv2. The relevant changes should be made in the IKEv2 
>  > specification 
>  > > through text proposed by the MIP6 WG in 
>  > > draft-eronen-ipsec-ikev2-clarifications-XX.txt. Text 
>  > should be put into 
>  > > the bootstrapping draft indicating that the HA should use 
>  > DAD during 
>  > > IKEv2 to confirm the address and not DAD the address 
>  > during the initial 
>  > > MIP6 registration if bootstrapping is used.
>  > > 
>  > > When you send a reply to the list, please indicate which 
>  > solution you 
>  > > prefer. We will run the concensus call for about 2 weeks, 
>  > until around 
>  > > Dec. 20.
>  > > 
>  > >                        jak
>  > > 
>  > > _______________________________________________
>  > > Mip6 mailing list
>  > > [email-masked]
>  > > https://www1.ietf.org/mailman/listinfo/mip6
>  > > 
>  > 
>  > _______________________________________________
>  > Mip6 mailing list
>  > [email-masked]
>  > https://www1.ietf.org/mailman/listinfo/mip6
>  > 
> 
> ===========================================================
> This email may contain confidential and privileged material 
> for the sole use
>  of the intended recipient.  Any review or distribution by 
> others is strictly
>  prohibited.  If you are not the intended recipient please 
> contact the sender
>  and delete all copies.
> ===========================================================
> 
> 
> _______________________________________________
> Mip6 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mip6
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================

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

---

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 8 Dec 2005 10:10:39 -0500

> So we seem to agree. The initial message IMHO is clear enough
 > about what it means by proxy-DAD to ask you to reply again
 > (I believe you mean option 1).
 > If you believe there should be a statement about the unique-at-a-time
 > (wording?) allocation I'll support you.

=> I think we agree. I can only choose option 1 if there is a statement
about the uniquness of the address at the time of allocation. Otherwise 
option 1 doesn't make sense. 

Hesham

 > 
 > Thanks
 > 
 > [email-masked]
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

---

From: "Soliman, Hesham" <[email-masked]>
Date: Sat, 10 Dec 2005 01:54:48 -0500

> so what does this actually mean? check the list of
 > already allocated HoAs?

=> Yes. 

Hesham

 > 
 > > James, Vijay: does it work for you?
 > 
 > if it is just checking a list of allocated HoAs and
 > not running proxy DAD, then I am fine.
 > 
 > Vijay
 > 
 > > 
 > > --Gerardo 
 > >  
 > > 
 > >>Hesham
 > >>
 > >> > 
 > >> > Thanks
 > >> >

---

From: Gerardo Giaretta <[email-masked]>
Date: Mon, 12 Dec 2005 14:58:29 +0100

>  In your previous mail you wrote:
> 
>    > This seems reasonable to me: option 1 with a statement 
> that somehow
>    > (e.g. virtual home link) the uniqueness of the address 
> is guaranteed at
>    > the time of allocation.
>    
> => IMHO it is this.
> => OK too.

OK, I think we can close the issue. I'll update the draft accordingly.
I'll post proposed text soon.

--Gerardo

> PS: it seems this point should be closed soon.
>