Subject: RE: [Mipshop] Possible Solution to Duplicate Problem?

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 26 Aug 2005 13:49:21 -0400

> oDAD does not solve this problem. The applicability statement in the 
 > section on Collision Case clearly says oDAD should only be 
 > used where 
 > the probability of collision is small, which is usually the 
 > case with 
 > uniformly distributed IIDs.
 > 
 > I am having a hard time understanding where we interface 
 > with oDAD. It 
 > does not guarantee that an address is collision-free. Only DAD can 
 > assure you that. 

=> Wrong. DAD doesn't assure that. oDAD and DAD do the same
thing, the only difference is that *if* there is a collision, 
oDAD will cause traffic to be routed to the wrong node for 
a very short period of time (0.5 RTT on the link itself). 

Hesham

So, we can pick an address using NAR's 
 > prefix and get 
 > NAR to lookup its NCE when processing HI. If there is 
 > already an entry 
 > in NAR's NCE, you know there is a conflict. If not, there _can_ be 
 > collision, whose probability is the same as it is for oDAD. 
 > In such a 
 > case, FMIP would have initiated a tunnel. With oDAD, you can 
 > initiate a 
 > tunnel by sending BU before DAD completes. So, what is the 
 > problem for 
 > which oDAD is needed here?
 > 
 > About intentional collisions: a MN may visit NAR's link, 
 > come back to 
 > PAR's link, send FBU to PAR binding PCoA to an address on 
 > NAR's link and 
 > never move. It's traffic is redirected to a victim on NAR's link.
 > 
 > -Rajeev
 > 
 > 
 > 
 > 
 > 
 > 
 > 
 > >            jak
 > > 
 > > ----- Original Message ----- From: "Greg Daley" 
 > > <[email-masked]>
 > > To: "James Kempf" <[email-masked]>
 > > Cc: <[email-masked]>
 > > Sent: Thursday, August 25, 2005 5:20 PM
 > > Subject: Re: [Mipshop] Possible Solution to Duplicate Problem?
 > > 
 > > 
 > >> Hi James,
 > >>
 > >> oDAD works fine, you just can't confirm the address until
 > >> you  arrive. :)
 > >>
 > >> 3) is a valid way to go, but won't always be applicable.
 > >>
 > >> If there's stateful allocation (or reservation) of
 > >> addresses using DHCPv6 (or something like), then it
 > >> makes sense to have an exchange using HI/HAck (or FBU/FBack)
 > >> to propose an address, or to have one doled out to the host.
 > >> This is regardless of whether the address can be guaranteed
 > >> unique on the link.
 > >>
 > >> In this case though, it would be good to distinguish
 > >> between "perfect" allocation, and standard allocation
 > >> which must be confirmed using oDAD, in the returned
 > >> FBAck or HAck.
 > >>
 > >> Greg
 > >>
 > >> James Kempf wrote:
 > >>
 > >>>> 3) Pre test addresses (like AdvanceDAD).
 > >>>>
 > >>>> 4) Test the address upon arrival on-link (using opti-DAD).
 > >>>>
 > >>>> Of these, only opti-DAD is generally applicable.
 > >>>> It's quick to give a usable address to the host, and it
 > >>>> doesn't require additional modifications to routers.
 > >>>>
 > >>>
 > >>> Right but oDAD won't work for predictive handover.
 > >>>
 > >>> Maybe 3) is the right way to go then.
 > >>>
 > >>>            jak
 > >>>
 > >>
 > > 
 > > 
 > > 
 > > _______________________________________________
 > > Mipshop mailing list
 > > [email-masked]
 > > https://www1.ietf.org/mailman/listinfo/mipshop
 > 
 > 
 > _______________________________________________
 > Mipshop mailing list
 > [email-masked]
 > https://www1.ietf.org/mailman/listinfo/mipshop
 > 

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

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

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 26 Aug 2005 14:02:27 -0700

> a very short period of time (0.5 RTT on the link itself). 

Wrong is strong :-) oDAD has to do DAD to assure an address is 
collision-free, which it does.

So, did you have any input on the rest of the text below?

Thanks,

-Rajeev