Subject: Re: [mobile-ip] Optimistic DAD for Fast Handovers

From: Greg Daley <[email-masked]>
Date: Tue, 10 Sep 2002 16:41:43 +1000

Hi Erik,

I've half baked the idea myself with MLD
(which [currently] is a requirement to do DAD ...)

What's needed is to either snoop all the NA's to
the solicited nodes addresses (+ maybe the NS's for
a response), or for a router to watch the MLD
reports for every node on the link.

Since the router will receive the MLD reports anyway,
I thought it may be a good place to start.

There's a draft at:

http://www.ietf.org/internet-drafts/draft-daley-ipv6-mcast-dad-00.txt

MLD already implements the periodic retransmission
system, and only (MLDv1) requires the most recent
reporter out of a multicast group to send the update.

Only one additional message is sent, in the case
of a successful fastDAD.

It only works if people implement MLD on all nodes on the
link though...

In MIPv6/HMIPv6, this trick also works with the MAP or HA,
as well as the visited link. Once this response is received,
the address is DAD'ed and the MAP/HA can send the BAck
immediately after receiving the confirmation,
which is not possible in the optimistic scheme.

I think that using Nick's version of optimistic DAD can
be done without harming other nodes' neighbor caches or
TCP sessions, though.

Greg Daley

Erik wrote:
[alper's email snipped]
> From the half-baked idea department:
> 
> Perhaps it would be better to explore "router/agent assisted DAD"
> than optimistic DAD. In the assisted DAD case there would be an agent
> which would somehow reliably know the IP addresses and link-layer
> address of everybody on the link. Then it could send an "ok to use it"
> response to DAD queries if the address isn't in its table or
> if it is in the table with the same link-layer address.
> 
> The trick is how to reliably have the agent build the tables.
> One way would be to add a new RA option "please periodically send a packet
> to X" where X is the address of the agent, which would cause all hosts
> to send a packet with a given period.
> This requires changes in all hosts on the link, and it causes additional
> background traffic for the benefit of shortening the DAD query.
> 
>   Erik
> 
>

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 10 Sep 2002 10:38:29 +0200 (CEST)

> I thought it may be a good place to start.

I think the MLD report is the better of the two, since there is a mechanism
to make them reliable (the elected queries will send MLD queries to get groups
reported). Snooping all NAs might be expensive, and only looking at the
DAD probes is not robust. Also, the NAs have no associated lifetime for
the state, but the periodic MLD queries effectively provide a lifetime
for the reported information. Thus with MLD you know when you can remove
addresses from the table of the registered entities.

> It only works if people implement MLD on all nodes on the

Yep.

And the issue is whether you need to know the actual IPv6 address of the node,
or just the solicited node multicast address. I think MLD is only guaranteed
to provide the latter, since the source of the MLD can be the unspecified
address and since the reports for the same group are suppressed.
An example of the latter is a case when two nodes are manually configured
one with P1::0:1 and the other with P2::0:1.
Those addresses are not duplicates but they result in the same solicited node
multicast address being joined. Thus the router might not reliably know
about both of the node's addresses.

  Erik

---

From: Markku Savela <[email-masked]>
Date: Tue, 10 Sep 2002 12:57:45 +0300

> From: Greg Daley <[email-masked]>
> 

I'm not saying the proposed solution would not work, but I
just wish to point out few issues for consideration.

In this draft, chapter "2.0 Protocol Overview" has

      Secondly, the report asks the MLD querier router to respond if
      the group is previously unknown.  Limiting response to the
      querier router prevents multiple responses and allows for simple
      rate-limiting operation.

The key phrase is "group is previously unknown". How does MLD know a
group is unknown?

- it must send MLD query requesting report on all groups

- it must be sure to catch and store each reply, and only after it
  knows it has got them all, it can assume "some group is unknown".

- with high probability, there will be a reply from each node on the
  link (usually each node belongs to different solicited node group)

- if LLMNR is being used, with high probabily, each node is also a
  member of "solicited name" multicast group, with large probability
  that each node is alone in its group

- some other uses for highly unique link local multicast groups may be
  deviced, increasing the number of link local groups

Thus, the number of link local groups that MLD router must keep track
of, is always at least O(number of nodes on link). Whether this is bad
or not, I don't know.

Concerning Erik's mail

From: Erik Nordmark <[email-masked]>
> I think the MLD report is the better of the two, since there is a
> mechanism to make them reliable (the elected queries will send MLD
> queries to get groups reported). Snooping all NAs might be
> expensive, and only looking at the DAD probes is not robust.

There is no difference in listening DAD probes or MLD. The only place
where MLD for solicited node group would be sent, is just before DAD
probe. Thus, if you have possibility to lose DAD probe, the same
applies to MLD join.

> reporter out of a multicast group to send the update.

As each node is usually alone in solicited node group, above does not
apply in general. And, MLD making periodic queries for each known
solicited node or name group may be a lot of traffic too. (Or, even if
it makes periodic queries to ANY group).

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 10 Sep 2002 14:03:06 +0200 (CEST)

> probe. Thus, if you have possibility to lose DAD probe, the same

Yes, but my point is that for MLD the querier router will send
periodic MLD queries which in effect will make the hosts retransmit
their MLD reports. There is no mechanism which the router can use
to get all hosts to resend their DAD probes.

> it makes periodic queries to ANY group).

MLDv1 results in a single periodic query for all groups being sent
by the router, resulting in a (randomly delayed) MLD report for every
group that is joined on the link. (There is supression of duplicate
reports in MLDv1 when multiple nodes have joined the same group.)

This is just how MLDv1 works in order for multicast to work.
Thus using the information (which solicited node multicast addresses
are joined on the link) for some other purpose wouldn't cause extra
packets to be sent. But note that this doesn't indicate which IP addresses
are used, since there is a many-to-one mapping from IP address to solicited
node multicast address.

  Erik

---

From: Greg Daley <[email-masked]>
Date: Wed, 11 Sep 2002 09:32:49 +1000

Hi Markku,
replies are inline.

> - it must send MLD query requesting report on all groups

The router doesn't send reports, but may request all nodes on
the link to send a report with an MLD query.

>   knows it has got them all, it can assume "some group is unknown".

This is what is required. (although not explicitly mentioned
in this section )

After startup, the router would have to wait
the MLD Multicast Listener Interval to ensure that
periodically reporting nodes have given their status.

this is equivalent to the backoff mechanism defined
in Section 5.5 Exhaustion of Querier Router's Storage.

> of, is always at least O(number of nodes on link). Whether this is bad

I agree that the number of groups is proportional to
the number of nodes on the link, although there may
be some solicited nodes addresses which are in use by
multiple nodes (where the optimization won't work).

It is necessary only to provide this function for
solicited nodes multicast addresses, rather than other
sets of addresses such as LLMNR's solicited name address.
So this may cut down on the number of addresses to track.

Since the idea is an optimization with a robust fallback
case (full DAD), it may be OK to keep state for between
0 and MAX_MLD_DAD_GROUPS.  where MAX_MLD_DAD_GROUPS is
is proportional to the maximum number of addresses expected
on the link (depends on whether LLAddress and Global address
are formed from same suffixes on the link).

If we look an equivalent tracking system based only on
NA/NS then similar state must be kept.

Greg Daley