How can mobile IPv6 in the market without at least PS and LMM is still a discussion which I believe is required and as you know I say use AAAv6 instead of overhead of Ipsec.
Now if you mean we can move in the market as vendors without the IETF I agree but that has not happened yet. /jim -----Original Message----- From: Alper E. YEGIN [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:10 PM To: Bound, Jim; [EMAIL PROTECTED]; Pekka Savola Cc: Nick 'Sharkey' Moore; [EMAIL PROTECTED] Subject: Re: Optimistic DAD draft ... Jim, > None of us working on this are even clear layer 3 handover will ever > work? Not sure if that matters does it? Are we talking about the > future? You mean Mobile IPv6? It works. alper > > Thanks > /jim > > -----Original Message----- > From: Alper E. YEGIN [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 15, 2002 5:43 PM > To: [EMAIL PROTECTED]; 'Pekka Savola' > Cc: 'Nick 'Sharkey' Moore'; [EMAIL PROTECTED] > Subject: Re: Optimistic DAD draft ... > > > > > > 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. > > > > Then DAD latency should be the least of the concerns. > > Not really. For example 802.11b (link-layer) handover can take > something like 200ms, and DAD would take 1sec on that link. People are > already working on shrinking link-layer handover latency, and some > should do the same for DAD as well. > > > > > > > > > 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. > > > > My argument is that all MNs anticipate movement, and establish DAD > > before they really make the move. Yes this will generate some overhead > > > if the node doesn't move, but that is a minor cost in the grand > > scheme > > > of things. > > We cannot assume all MNs can "anticipate movement". Not all > link-layers > have this capability. > > alper > > > > > > > Tony > > > > > > > > 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] --------------------------------------------------------------------
