Re: [DNA] Question to DT about TSLLAO and Negotiation-freeDeterministic Fast RA

[Erik Nordmark <erik.nordmark@sun.com>]

Greg Daley wrote:

> Optimistic DAD doesn't require unspecified source addresses on RSs.

That's a bit odd, since RFC 2461 has a SHOULD include SLLAO when the 
source address isn't unspecified. And when using optimistic dad the 
source address would presumably need to be unspecified to avoid 
polluting the caches with optimistic information.

> It requires that (non-tentative) SLLAOs aren't included in RSs while
> optimistic.
> 
> (section 2.2 of draft-ietf-ipv6-optimistic-dad-05:
> 
> "...
>       * Never using an Optimistic Address as the source address of a Router
>         Solicitation with a SLLAO.  Another address, or the unspecified
>         address, may be used, or the RS may be sent without a SLLAO.

Hmm - sending a RS with the optimistic address as a source and without 
SLLAO doesn't seem any more useful then sending with with an unspecified 
source address.

Can you recall why optimistic DAD explicitly wants to allow this?

> In most cases, I guess that the host will have to choose between sending
> RS with Unspecified Source or Optimistic Address.  There's no protocol
> impediment to using the Optimistic Address though.
> 
> I'd guess that really we'll see people using the Optimistic Address
> in most cases, in order to allow for a unicast response (at L3).
> If that's the case, source addresses are sufficient.

But you wouldn't get a single unicast response unless the router has a 
neighbor cache entries which requires either a NS/NA exchange triggered 
by the router before the RA can be unicast, or TSLLAO.
Optimizing for the former 4 packet exchange doesn't seem useful, since 
the multicast RA is actually as efficient if not more efficient.

> Relying on TSLLAO excludes legacy devices which are more likely to use
> unspecified source addresses anyway.   In the case that an RS arrives
> with an address and no TSLLAO (or even with an SLLAO one), it may be 
> valuable to send an RS fast anyway.

I assume that by "legacy devices" you mean devices that implement RFC 
2461/62. Such devices, after moving from one link to another, will 
retain the old information for an extremely long time. For instance, 
addresses autoconfigured from the prefix of the old link will remain 
preferred for new communication for *7 days* when the default lifetimes 
are used. And as long as these are retained some communication (the ones 
that pick that preferred source address based on the default address 
selection algorithm) will just. So given that legacy host will be hosed 
for 7 days by default, I'm not concerned about being able to give them a 
RA a few seconds faster.

    Erik