Subject: RE: Proposal: DAD Optimization using Multicast Listener Discovery

From: "Dave Thaler" <[email-masked]>
Date: Tue, 27 Aug 2002 11:12:41 -0700

> From: Greg Daley [mailto:[email-masked]]
>
> I've been thinking about how we can use MLD to
> determine if anyone else is defending an address using DAD.
> 
> The MLD RFC indicates that a node's link-scope multicast
> addresses except all-nodes link-scope must be joined
> using MLD.
> 
> Since the router receives MLD reports from all devices it
> knows whether a multicast group is active on the subnet
> (or should that be link(s)?) for which it is the Querier.

There is no requirement today that a router keep any state 
on link-scoped groups.  Hence, in general the router does
not know the information you're assuming.

Furthermore, there is a proposal under discussion to
not do DAD, except on manually assigned addresses.
If this proposal is accepted, there's little benefit to
trying to optimize DAD any further (certainly not worth
asking routers to start keeping extra state).

-Dave

--------------------------------------------------------------------
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: Greg Daley <[email-masked]>
Date: Wed, 28 Aug 2002 08:45:02 +1000

Hi Dave,

> not know the information you're assuming.

What's being proposed is an optimization.
If the router does not understand the request, or does
not want to process such messages, then DAD continues
as normal.

Since the nodes are forced to perform MLD for the
solicited-node address, the issue of whether the Querier
Router actually keeps state is implementation dependent,
IMHO.

> asking routers to start keeping extra state).

Until there's consensus in the WG, I suggest that there's
a great deal of benefit in assessing ways to remove the
delay issues in DAD, without killing it.

I'll send out the draft soon so you can have a look at
it before you make a final decision ;-)

Greg Daley

---

From: Robert Elz <[email-masked]>
Date: Wed, 28 Aug 2002 09:26:57 +0700

Date:        Tue, 27 Aug 2002 11:12:41 -0700
    From:        "Dave Thaler" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Furthermore, there is a proposal under discussion to
  | not do DAD, except on manually assigned addresses.

I think "under discussion" is a little much for that.   There was
such a proposal, but it really only existed (I believe) because it
was the only practical way to make DIID work.  When there was almost
no support for DIID, that proposal became unnecessary, and since then
(during the WG meeting at Yokohama, where this was raised, and then
forgotten) there has been no discussion at all that I'm aware of.

kre

---

From: Brett Pentland <[email-masked]>
Date: Wed, 28 Aug 2002 17:58:33 +1000

> forgotten) there has been no discussion at all that I'm aware of.
I don't understand how not doing DAD relates to DIID.  I thought
(possibly mistakenly) that the proposal that Steve Deering presented was
to do with eliminating the delay introduced DAD for addresses that are
unlikely to conflict with others, allowing faster aquisition of new
addresses (helpful for mobile nodes).

Brett.

---

From: Robert Elz <[email-masked]>
Date: Wed, 28 Aug 2002 15:56:51 +0700

Date:        Wed, 28 Aug 2002 17:58:33 +1000
    From:        Brett Pentland <[email-masked]>
    Message-ID:  <[email-masked]>

  | I don't understand how not doing DAD relates to DIID.  I thought
  | (possibly mistakenly) that the proposal that Steve Deering presented was
  | to do with eliminating the delay introduced DAD for addresses that are
  | unlikely to conflict with others, allowing faster aquisition of new
  | addresses (helpful for mobile nodes).

Yes, it did all that.   But it turns out that to make DIID really work,
it would be close to essential to do this.   Just why is no longer really
relevant (Steve can explain if he feels inclined).

kre