Re: an example of optimistic DAD in action, with MIPv6

Hi Ed,

Ed Remmell wrote:
> Greg -
> 
> 
>>There's been some discussion recently as to the applicability 
>>of the unsolicited NA, on non-predictive handovers.
>>
>>It seems that unless there's already a neighbor cache entry 
>>(there won't be, since we're non-predictive) no-one will 
>>listen to the NA (SHOULD NOT, in RFC2461).
> 
> 
> RFC-2461 says:
> "When a valid Neighbor Advertisement is received (either solicited or
>    unsolicited), the Neighbor Cache is searched for the target's entry.
>    If no entry exists, the advertisement SHOULD be silently discarded.
>    There is no need to create an entry if none exists, since the
>    recipient has apparently not initiated any communication with the
>    target."
> 
> The optimistic DAD draft says the following about router processing of
> such an unsolicited NA:
> 
> "  It may be desirable for a Neighbour, for example the router, to
>    rapidly establish communication with the newly configured ON. To do
>    so, it must learn of the ON's arrival as soon as possible.  To avoid
>    having to wait for Neighbour Discovery, the ON may wish to send
>    unsolicited Neighbour Advertisements (with Override set
>    appropriately), but for this to be effective the Neighbour must
>    either:
> 
>    * be expecting the ON to arrive (eg: due to predictive mechanisms),
>         and thus already have a NC entry for the peer, in state
>         INCOMPLETE.
> 
>    * be willing to cache unsolicited NAs (for a short period of time),
>         so that an entry will have been created with state STALE."
> 
> This seems like a reasonable router-specific extension to RFC-2461.

I agree that it seems reasonable, although there's no
way to determine if the RA is being processed.
(by today's standards, I guess it won't).

In order to make this secure though, we'd have to
use SEND.  Maybe it is reasonable to add unsolicited
NC entries when the source is verifiable (but once
again we're unlikely to see that implemented this year).

Should we send unsolicited NA?  Maybe it should be
sent always if prediction has been used, and
based on MN configuration otherwise.

> 
>>Maybe it is sufficient to respond to NS's with NA, without 
>>sending the unsolicited NAs (for non-predictive).
> 
> 
>>From the optimistic DAD draft:
> 
> "   * (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."
> 
> We implement the 1st requirement when we auto-configure CoAs (done
> immediatly upon receiving the RA with the prefix information), and the
> 2nd requirement when we auto-configure the link-local scope address
> (done after DAD has completed successfully). If for no other reason, it
> is useful to see these unsolicited NAs appear in the protocol capture
> for debugging purposes, but then also these unsolicited NAs could create
> STALE Neighbor Cache entries in the router. If another node on the same
> link is performing DAD on the exact same address(es) at the same time
> (highly unlikely), then these unsolicited NAs could also help it detect
> duplicates

I think that one of the main criticisms of optiDAD will be
that it sends unnecessary packets on the link (for the
common case).

While your implementation is good and consistent
with the specification of optimistic DAD.  It may be
worthwhile to revisit the draft and see if this
behaviour should be switched on and off for certain
interfaces or classes of addresses.

Personally, I can see that DIID (DAD only on LinkLocal)
is a valid optimization for rfc3041 and EUI addresses, but it
will not be valid for SEND addresses based on CGA.
If we have to do NAs for each of the global CoAs and the
LinkLocal Addresses (because they have different suffixes
in CGA) this may be a burden, rather than a benefit.

I'd guess that configuring the unsolicited NA would be
most easily done on a per-interface basis though because
we wouldn't like tie the requirements of OptiDAD to an
as-yet unspecified third document.

> 
>>Without the SLLAO, I think that the issues caused by using a 
>>tentative address for RS are minimal or recoverable (I think 
>>the new draft will cover this).
>>
>>I think there are significant advantages to using a 
>>link-local source address (since unicast RA responses 
>>(+FastRA??) are available).
> 
> 
> Yes, I agree with you, but currently it is unsafe to do so because you
> would have to include the SLLAO, correct?

Not actually, SLLAO is only MUST in NS.  It is SHOULD in
RS.  This means that those routers meaning to unicast a
response must do ND.

There are some minor (?) issues to do with the isRouter
flag in NC entries if there is a collision with a router.
These self-correct after the router sends a multicast RA.
(maybe in response to the RS?).

Apart from that, the RS may be used with LinkLocal addresses.

I'm not sure if unicast responses are better, but if we send
the packet from a LinkLocal address, at least the router may
choose.

Greg