Subject: comments on draft-moore-ipv6-optimistic-dad-04.txt

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 23 Feb 2004 19:27:18 +0900

Here are comments on draft-moore-ipv6-optimistic-dad-04.txt.  I have
one relatively-substantial comment and several editorial ones.

The relatively-substantial comment is:

I don't see the strong need for the unsolicited neighbor
advertisements described in Section 3.1:

   * (adds to 7.2.6)  The Optimistic node MAY send an unsolicited
        Neighbour Advertisement to All Nodes when it first configures an
        address. The Override flag on this advertisement MUST be set to
        0.

   * (adds to 7.2.6)  The Optimistic node SHOULD send an unsolicited NA
        to All Nodes when it completes DAD. The Override flag on this
        advertisement SHOULD be set to 1.

In particular, I don't understand why we SHOULD send the unsolicited
NA in the latter case.

Other (mostly) editorial comments.

1. the draft contain many acronyms without or before (clearly) showing
   the original term.  those include: DAD, ND, SAA, SLLAO, RS, RA, ON,
   NC, NS, NA, MN, and LLAO.

2. The second paragraph of Introduction contains an incomplete
   sentence.

   ...  Disruption is minimized by limiting nodes' participation in
   Neighbour Discovery while their addresses are still Tentative,

   (or perhaps the comma should actually be a period)

3. One definition in Section 1.3 is not well defined (IMO):

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

3. In section 2,

   * Never using a Tentative address ...
        ....  Another address, or the unspecified
        address, may be used, or the RS may be send without an SLLAO.

s/may be send/may be sent/

4. In section 2.

   When the MN wants to contact another neighbour, but it cannot because
   ...

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.

5. In the same paragraph,

   ...The
   router should then provide the MN with a ICMP redirect, which may
   ...

s/a ICMP/an ICMP/

6. In Section 3.2

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

7. In Section 3.2

   * (modifies 5.4.5) ...  If the address is a
        link-local address formed from a fixed interface identifier, the
        interface SHOULD be disabled.  Otherwise, if the address was

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.

8. In Section 3.3

   * If the interface offers a method to create a supposedly globally
        unique IPv6 address, this address MAY be used for the initial
        attempt.

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?

9. In Section 3.3

   * In order to minimize the effect of DoS attacks, a delay of at least
        RETRANS_TIMER (as used in [RFC2461]) milliseconds MUST be
        introduced between attempts if DAD has already failed more than
        once.  An exponential backoff SHOULD be used.

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?

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"?

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)?

					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: "S. Daniel Park" <[email-masked]>
Date: Mon, 23 Feb 2004 21:36:19 +0900

>One fundamental question that I remember is whether optimizing DAD
>really makes much sense while there are other kinds of delays such as
>random delay (up to 1 second) for the first RS and random delay at
>routers before responding to an RS.  Without addressing the
>fundamental question(s), we'd simply restart similar divergent
>discussions, waisting lots of energy and time without seeing progress.

So, one draft was proposed to clarify what you indicate and I posted it
on the IPv6 mailing list.
http://www.ietf.org/internet-drafts/draft-park-dna-ipv6dadopt-
requirement-02.txt 

Regards

- Daniel (Soohong Daniel Park)
- Mobile Platform Laboratory, SAMSUNG Electronics.

---

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

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

-----

> advertisements described in Section 3.1: [...]

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

>    definition, but this is probably a minor issue (I can live with the

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.

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

> What does "initial suffix" mean?  RFC2462 (or its bis) doesn't use

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

>    (e.g., EUI-64), the interface SHOULD be disabled.

I'll adopt that wording.  

> supposedly globally unique?

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

> 9. In Section 3.3 [...]

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

> I'm not really sure what "the actual address" means.  Do you mean "non

Yeah.  I should be clearer there.  

> 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

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Sun, 29 Feb 2004 15:21:33 +0900

>>>>> On Mon, 23 Feb 2004 21:36:19 +0900, 
>>>>> "S. Daniel Park" <[email-masked]> said:

> http://www.ietf.org/internet-drafts/draft-park-dna-ipv6dadopt-requirement-02.txt 

Thanks for the pointer, I've read the draft.  Unfortunately, it only
covers the delay for the first RS, and not others (e.g., the delay at
routers before responding to RSs).  I respect the effort of you guys,
but I'd rather want to see a comprehensive scenario before introducing
additional mechanism to solve a part of the entire issues.

					JINMEI, Tatuya

---

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

> additional mechanism to solve a part of the entire issues.

Overall handover delay consists of, among other factors, link layer
search and attachment times, access authentication and access link
security setup, router discovery, address assignment and duplicate
testing, and mobility signaling.

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

- Link layer search and attachment times are being improved in
   IEEE, to give one example.

- Significant efforts are being put in IEEE and elsewhere
   to reduce the time needed to perform access authentication
   and set up link layer security. For instance, pre-authentication
   and fast handoff mechanisms are discussed and specified in 802.11.

- As Greg already mentioned, there is ongoing work in DNA WG to
   improve the RS situation. This relates to the movement detection
   delays. Is the work finished? I don't know, but is that required?

- We have optimistic DAD which is addressing the DAD delay.

- We have mobility optimisations such as HMIP in MIPSHOP WG (and bunch
   of others in research stage) that address delays caused by mobility
   signaling.

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

--Jari