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

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Erik,

This is getting interesting, but will probably settle
down soon.

Erik Nordmark wrote:
> 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.

As you say, SHOULD, not MUST include the SLLAO.

We certainly don't want to include SLLAO, but an optimistic
neighbour advertisement or a TSLLAO won't override existing
neighbour cache entries (and any DAD defending NA will).

So there's really change in having RS's not include the
SLLAO, since routers have already had to deal with the case
(albeit it maybe not optimally).

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

* It is useful if the router performs neighbour discovery on
   the address, and then sends unicast (which is what at least
   RADVD on Linux does, if it isn't sending an immediate Multicast RA).

* It is useful also if the router has an existing neighbour cache entry
   for the address (likely in the non-movement case for DNA).

* It's useful if there's TSLLAO in the RS.

* It doesn't hurt if there's no way to make a unicast response,
   since a multicast will be scheduled.

Rate-limitation of multicast RAs is likely to induce delays
in some cases.  This (the chance multicast delay) is calculated
for various advertisement intervals in draft-narayanan-dna-routers-bcp-00.

Sending a specified source address and allowing the router to
choose whether it delays with a multicast or solicits and
sends an NS (or if it has TSLLAO sends a unicast) makes sense
if you want a (even moderately) fast response.

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

I'm not sure that Optimistic DAD specifically wanted to allow this,
but it's a good feature to keep if it's supported, since routers
modified to support TSLLAO are likely to be the ones optimized for DNA.

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

Indeed.
It's not optimized for the 4 packet exchange.

It's optimized for the two packet exchange, when TSLLAO is present.

I'm not encouraging people to leave out TSLLAO, I'm encouraging
the optimization to not rely on TSLLAO.

As I said earlier, an RS won't perform worse by having a specified
source address (with SLLAO, TSLLAO or no LLAO).  Router discovery
can perform worse if there's an unspecified source address,
if TSLLAO isn't supported by the router.


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

I actually mean anyone not running optimistic DAD. :)
This includes a lot of RFC3775 implementations today.

The legacy unspecified source address devices won't get
a fast response if you use the source address for fast
responses.

Even with TSLLAO though, it's not possible in every
implementation to send unicast MAC responses when
there's an RS from the unspecified source address.
Any responses would then have to be treated as multicast.

Specified source addresses get around this issue.
They also create neighbour cache entries on the router,
which an unspecified address RS cannot.

It's worth considering that unspecified source address RS
cannot be secured with SEND.  We may not want to give
fast responses to devices which don't have to do any work
in generating solicitations.

What I'm saying is not that RS's should be sent without
SLLAOs or TSLLAOs, but that on optimized transmissions the
hosts are likely to have specified source addresses AND TSLLAOs.

So an unspecified source addresses really shouldn't be
the focus of optimization.

One of the purposes of optimistic DAD is to allow use
of addresses while optimistic.  It would be a shame to
waste the opportunity of using this feature, when there
are so many problems with RS's from unspecified source
addresses.

Greg