Hi Jim, > Simply because of address spoof DOS we must at least permit DAD. The > cost is only at node-on. Now the timers and lifetimes administration > for a mobile network could be a problem but that is tunable. I believe > we are talking miliseconds. What we need are some tests. > I will ask our folks to test our handhelds for DAD timings.
That'd be useful. > > But any implementation can turn anything it wants off for v6. We can > say MUST or SHOULD but users may or may not use it. > Yes. If the cost of DAD is too high (compared to the risk), and solutions to remedy the situation is also not as attractive, networks/architectures might choose to skip DAD, I'm afraid. > I am not comfortable changing DAD for anything here quite yet based on > the arguments on the "for" side at all. As far as I understand, people are not suggesting changing DAD, but instead developing an optimized version of it. Both versions should be able to co-exist, no interference. alper > > /jim > > -----Original Message----- > From: Alper E. YEGIN [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 15, 2002 5:12 PM > To: [EMAIL PROTECTED]; 'Pekka Savola' > Cc: 'Nick 'Sharkey' Moore'; [EMAIL PROTECTED] > Subject: Re: Optimistic DAD draft ... > > > > > Hi Tony, > > > True, but the term 'hand-off' implies a make-before-break process, > > else the MN is just establishing itself on a new link. Given it has > > the opportunity to be aware of multiple links, it can decide when to > > switch. I am arguing that it complete DAD 'before' it makes that > > decision, not after. > > I don't think we can consider all "handoffs" as 'make-before-break'. > There exists some link-layer technologies that allow this, but not all > have such capability. > > Completing DAD before handover requires either movement anticipation or > make-before-break, both of which are not widely applicable. Therefore > solving DAD latency for general case is a valid approach, imo. > > alper > > > > > > > > Tony > > > > > -----Original Message----- > > > From: Pekka Savola [mailto:[EMAIL PROTECTED]] > > > Sent: Tuesday, October 15, 2002 1:32 PM > > > To: Tony Hain > > > Cc: 'Nick 'Sharkey' Moore'; [EMAIL PROTECTED] > > > Subject: RE: Optimistic DAD draft ... > > > > > > > > > On Tue, 15 Oct 2002, Tony Hain wrote: > > > > [...] it would seem the prudent thing for a MN to do is > > > establish DAD > > > > for all candidate prefixes well before it is ready to start using > > > > them. [...] > > > > > > Isn't there a problem with how this could be done, as > > > currently specified? > > > > > > One can't perform DAD before being on the link. > > > > > > > > -----Original Message----- > > > > > From: [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED]] On Behalf Of Nick > > > > > 'Sharkey' Moore > > > > > Sent: Monday, October 14, 2002 7:58 PM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Optimistic DAD draft ... > > > > > > > > > > > > > > > G'day IPng-ers, > > > > > > > > > > One of the big issues in getting low-latency > > > > > handovers working for IPv6 mobility is the long delay involved > > > > > in > > > > > completing DAD. > > > > > > > > > > One option is to allow the Mobile Node to communicate while the > > > > > address is still Tentative (optimistically assuming that DAD > > > > > will succeed), but to adjust its ND / SAA behaviour in order to > > > > > minimize disruption in case of an address conflict (and maintain > > > > > > correct interoperation with > > > unmodified nodes). > > > > > > > > > > We've kicked the idea around a little on mobile-ip, > > > > > and I've formalized my thoughts into an internet draft, > > > which should > > > > > get published soon. In the meantime, you can find it at > > > > > <http://www.ctie.monash.edu.au/ipv6/fastho.htm> > > > > > (tentatively titled draft-moore-ipv6-optimistic-dad-00). > > > > > > > > > > I'd be interested in your opinions on the draft, and its > > > > > potential suitability for standards track. > > > > > > > > > > > > > > > cheers, > > > > > Nick > > > > > -- > > > > > Nick 'Sharkey' Moore <[EMAIL PROTECTED]> > > > > > Research Fellow, CTIE Tel: +61 3 9905 3707 > > > > > Monash University, Australia Fax: +61 3 9905 5358 > > > > > > > > -------------------------------------------------------------------- > > > > > IETF IPng Working Group Mailing List > > > > > IPng Home Page: > > > http://playground.sun.com/ipng > > > > > FTP archive: > > > ftp://playground.sun.com/pub/ipng > > > > > Direct all administrative requests to > > > [EMAIL PROTECTED] > > > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > > > > > > > ------------------------------------------------------------------ > > > > -- > > > > IETF IPng Working Group Mailing List > > > > IPng Home Page: > http://playground.sun.com/ipng > > > > FTP archive: > ftp://playground.sun.com/pub/ipng > > > > Direct all administrative requests to > [EMAIL PROTECTED] > > > > > -------------------------------------------------------------------- > > > > > > > > > > -- > > > Pekka Savola "Tell me of difficulties surmounted, > > > Netcore Oy not those you stumble over and fall" > > > Systems. Networks. Security. -- Robert Jordan: A Crown of Swords > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to [EMAIL PROTECTED] > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
