Subject: RE: Optimistic DAD draft ...

From: "Bound, Jim" <[email-masked]>
Date: Wed, 16 Oct 2002 11:15:10 -0400

Alper,

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.

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.

I am not comfortable changing DAD for anything here quite yet based on
the arguments on the "for" side at all.

/jim

-----Original Message-----
From: Alper E. YEGIN [mailto:[email-masked]] 
Sent: Tuesday, October 15, 2002 5:12 PM
To: [email-masked]; 'Pekka Savola'
Cc: 'Nick 'Sharkey' Moore'; [email-masked]
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-masked]]
> > Sent: Tuesday, October 15, 2002 1:32 PM
> > To: Tony Hain
> > Cc: 'Nick 'Sharkey' Moore'; [email-masked]
> > 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-masked] 
> > > > [mailto:[email-masked]] On Behalf Of Nick 
> > > > 'Sharkey' Moore
> > > > Sent: Monday, October 14, 2002 7:58 PM
> > > > To: [email-masked]
> > > > 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-masked]>
> > > > 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-masked]
> > > > 
> > --------------------------------------------------------------------
> > > > 
> > > 
> > > 
> > > ------------------------------------------------------------------
> > > --
> > > 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-masked]
--------------------------------------------------------------------
> > > 
> > 
> > -- 
> > 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-masked]
> --------------------------------------------------------------------
> 

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Wed, 16 Oct 2002 11:07:55 -0700

Hi Jim,

> I will ask our folks to test our handhelds for DAD timings.

That'd be useful.

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

> 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

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 17 Oct 2002 08:33:47 +1000

> to co-exist, no interference. 

That's exactly right, Alper.  My reason for using the 'Override'
bit rather than a dedicated 'Tentative' bit (like earlier 
Optimistic drafts) was because existing nodes (assuming they implement
2461/2462 correctly) will understand it already.

There's a couple of odd cases involving an address collision and
a new connection to that address within a very small time window,
but they're quite improbable and easily recoverable by standard NUD
without too much fuss.

I'm in the process of coding the draft up as a patch to Linux,
and crippling the random generator to induce collisions, so we'll
be able to get some real test results soon too.

If anyone has any questions about the draft details, ask away!

-----Nick