Subject: Re: Optimistic DAD _again!_

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Tue, 02 Mar 2004 00:45:16 +0900

>>>>> On Sun, 29 Feb 2004 15:03:15 +0200, 
>>>>> Jari Arkko <[email-masked]> said:

> Most or maybe even all of these aspects are being worked by different
> groups. For instance,

(snip)

> Does this count as a "comprehensive scenario" you were looking
> for?

I think so, thanks for the list.

In the optimistic DAD slot on Tuesday, I want to see this kind of big
picture, and how each of them is going to be addressed with
consideration for effects to existing/future non-mobility nodes.

BTW: to make my position clear, I do not object to the proposed
optimistic DAD per se.  I'm personally not so interested in
eliminating the handoff delay, but my impression on the optimistic DAD
draft (after reading it) is that it is very carefully trying to
minimize the effect to non-mobility nodes.  So, I agree that this can
be a reasonable compromise.

My point is that if we need to introduce an optimization on this I'd
like to be sure this is a part of a reasonable big picture.  This is
because otherwise we'd just introduce additional complexity, even if
it is only implemented in mobile nodes, as an incomplete solution (wrt
"the big picture").

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Tue, 24 Feb 2004 09:27:08 +1100

On 2004-02-23, JINMEI Tatuya / ?$B?@L@C#:H wrote:
> Here are comments on draft-moore-ipv6-optimistic-dad-04.txt.  I have
> one relatively-substantial comment and several editorial ones.

Thanks heaps for your careful reading ... I won't comment on
_all_ the editorial stuff here, but it's appreciated and I'll
make sure the changes end up in the next draft.  

-----

> The relatively-substantial comment is:
> I don't see the strong need for the unsolicited neighbor
> advertisements described in Section 3.1: [...]
> In particular, I don't understand why we SHOULD send the unsolicited
> NA in the latter case.

Yep.  They're there to bootstrap the neighbour cache of the
access router in the case of a predictive handover.  But you're
right, they should be MAYs and I need to add some text to explain
why the mobile node would bother with the extra signalling.
They could also be unicast to the AR or multicast to All-Routers
rather than LL broadcast, I guess.

Actually, since they're not generally applicable, maybe they
shouldn't be in Opti-DAD at all, and I should leave it to those
doing predictive handovers to say 'send an NA as soon as you can'.
(Opti-DAD clause 3.2 (iii) still says O MUST= 0 though).

>    Well-Distributed Address - Address suffixes used for Optimistic DAD
>         should be well distributed, eg: there should be an equal
>         probability of any given suffix occuring.  This minimizes the
>         probability of an address collision.
> 
>    I would say this is a requirement, not a definition.  I'd also like
>    to point out "well distributed" is not really clear in a
>    definition, but this is probably a minor issue (I can live with the
>    wording).

Yep, down in 3.3 (iii) the draft requires:
|
|	* Otherwise, or when creating a new address in the case of a
|	collision, a well-distributed suffix MUST be chosen.

... and I was seeking to define "well-distributed" for those who
hadn't heard the term.  I've noted that I need to improve that
definition.  A lot :-).

Earlier versions of the draft spoke of 'strongly random' generators,
but I changed it in order to be explicitly compatible with SEND CGA,
whose hash-generated suffixes are well-distributed but not at all
random.

> I guess MN stands for "mobile node" (see my first comment BTW), but I
> don't see why we need to use this word here.  As far as I can see,
> there is nothing specific to a mobile node in this context.

Yep, that's another artifact of my work with MobileIP, the terminology
has crawled into my ear.  I'll make sure I get rid of it all.

>    * (modifies 5.5)  If an initial suffix is not supplied, a new suffix
>         SHOULD be generated as per "Address Generation" below.
> 
> What does "initial suffix" mean?  RFC2462 (or its bis) doesn't use
> this wording.

Ah, I need to reorder some bits of 3.  It's a reference to 3.3 (ii).

> What does "a fixed interface identifier" mean?  (e.g.) An interface
> identifier derived from a hardware address like EUI-64?  FYI,
> the latest rfc2462bis draft contains the following sentence in Section
> 5.4.5:
> 
>    If the address is a link-local address
>    formed from an interface identifier based on the hardware address
>    (e.g., EUI-64), the interface SHOULD be disabled.

I'll adopt that wording.  

> This is not very clear to me.  What exactly does "a supposedly
> globally unique" mean?  For instance, is an EUI-64 based IPv6 address
> supposedly globally unique?

Yep, that's what I meant.  I'll clarify it.

> 9. In Section 3.3 [...]
> Does more than once mean "two times or more" (the answer should be yes
> in the literal sense)?  If so, why don't we need a delay after the
> first failure?

It was my intention that if it failed once, it should be allowed
to retry immediately, but if it fails again it should fall back
to only trying every RETRANS_TIMER (since multiple failures are
so astronomically unlikely that it's almost certainly DoS.)

> 10. In Section 3.4
> 
>    ...  In order to minimize the probability of an undetected
>    address collision, it would seem prudent to always configure and
>    check the link-local address for any given suffix as well as checking
>    the actual address being configured.
> 
> I'm not really sure what "the actual address" means.  Do you mean "non
> link-local address"?

Yeah.  I should be clearer there.  

> 11. In Section 4.2
> 
>    ...  An NA with O=0,S=0 and no LLAO may [Note 1],
>    however cause the NC entry to be set to STALE, causing NUD to be
>    performed on the address.
> 
> Shouldn't the "no LLAO" really be "with LLAO"?  If not, what is the
> purpose of this NA (O=0,S=0, no LLAO)?

Yes, you are right :-)  NA(O=0,S=0,no LLAO) will do nothing!
I've updated that.

-----

Thanks again for all this input, I will followup soon with 
my proposed changes.  This kind of debugging is exactly
why I want Optimistic DAD to be looked at in this WG!

-----Nick