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

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 6 Dec 2005 19:53:54 -0500

Hi James, 

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. 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

---

From: Francis Dupont <[email-masked]>
Date: Wed, 07 Dec 2005 04:09:35 +0100

In your previous mail you wrote:

   address is allocated.

=> this is what I believe at the exception of the mobility case.
Why? Because in the mobility case the client/MN can move so can
come back to the home link, something which is bit hairy to handle.
So I prefer the whole proxy NDP service, including the proxy DAD
function, is provided by the mobility code.
   
Of course it is a matter of taste but option 1 keeps the code
in IKEv2 far simpler when we had already written it for the
mobility (I speak as a mobility and IKE programmer).

Thanks

[email-masked]