Subject: [DNA] Question to DT about TSLLAO and Negotiation-free Deterministic Fast RA

From: Greg Daley <[email-masked]>
Date: Wed, 16 Feb 2005 12:31:36 +1100

Dear DT,

Was there a reason that Tentative Source Link-Layer Address
options were recommended for acting as the sequence
ordering mechanism in unnegotiated detfastra?

I would have thought that the inbound Router Solicitation's
source address would work just as well to xor against the hash
(probably in reverse or reverse byte order, to be less
predictable) to get the ordering.

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 Feb 2005 18:30:53 -0800

> Dear DT,

Did you intend to send this on the DT list or the WG list?

> predictable) to get the ordering.

Since you can't assume that your link-local address is unique should you 
have moved, you need to run the optimistic DAD procedure.
While doing so, the RS must have the unspecified source address.
Hence all RSes from different hosts will all look identical, except for 
a TSLLAO.

    Erik

---

From: Greg Daley <[email-masked]>
Date: Wed, 16 Feb 2005 15:18:00 +1100

Hi Erik,

> Did you intend to send this on the DT list or the WG list?

I intended it to the WG mailing list.

Since the document is out there (DNA list), I guess it's OK to
discuss components on-list.

I wasn't sure if my email to DNA-DT would bounce anyway.

> Hence all RSes from different hosts will all look identical, except for 

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

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.

         An address collision with a router may cause neighboring
         router's IsRouter flags for that address to be cleared.
         However, routers do not appear to use the IsRouter flag for
         anything, and the NA sent in response to the collision will
         reassert the IsRouter flag.
..."
)

section 3.2:
"...
    * (modifies 6.3.7)  A node MUST NOT send a Router Solicitation with a
         SLLAO from an Optimistic Address.  Router Solicitations SHOULD
         be sent from a non-Optimistic or the Unspecified Address,
         however they MAY be sent from an Optimistic Address as long as
         the SLLAO is not included.
..."
)

There was previously some concern over the use of RS, since it clears
the IsRouter flag in the case of colliding with a router (V.low
probability). It was found that the DAD defence from the collided
address would reset it less than 1 second later, though.

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.

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.

Just an idea.

Greg

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 15 Feb 2005 21:37:28 -0800

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

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

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

> 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

---

From: Greg Daley <[email-masked]>
Date: Wed, 16 Feb 2005 17:43:37 +1100

Hi Erik,

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

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

> SLLAO doesn't seem any more useful then sending with with an unspecified 

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

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

> for 7 days by default, I'm not concerned about being able to give them a 

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