Re: [v6ops] draft-linkova-v6ops-nd-cache-init to working group draft

[David Lamparter <[e-mail]>]

On Wed, Jul 24, 2019 at 11:05:38AM +0000, Pascal Thubert (pthubert) wrote:
> I’ve participated to multiple corridor discussions on that topic and
> seen agreement that NA(O) to ff02::2 that proactively sets the cache
> in the routers is better than the current state of affairs which is a
> NS from the router that is broadcasted to all hosts at L2.

I would like to argue that our approach to this issue should be
"additive", and if we can easily run fixes from multiple angles it might
be worth doing so.

In particular:
- DAD gleaning is a router-only fix for this issue that requires no host
  changes
- sending any kind of unicast probe that triggers a response is a
  host-only fix for this issue that requires no router changes
- sending NA(O) to ff02::2 is a router and host change

The fact that any of these may not work in some particular setup (e.g.
wifi controller crapping on ND, shitty multicast snooping) is all the
more reason to do more than one.

>From a privacy perspective I'm fine with sending NA(O) to ff02::2 since
that is theoretically "only routers" in a network that were to limit
multicast propagation.  It's not ff02::1, which is all I ask.

I'm also happy if we document NA(O) to ff02::2 as the "long-term" fix
while doing DAD gleaning and/or unicast probes as "short-term" fixes.

Lastly, NA(O) to ff02::2 should go through 6man IMHO.  Whether either of
the other 2 options I listed above needs that I don't know.

Cheers,


-David