Re: IPv6 default route flapping

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Tue, 20 Apr 2021 21:13:15 +0200
    From:        Joerg Sonnenberger <joerg%bec.de@localhost>
    Message-ID:  <YH8ny/9emssIdC+j%bec.de@localhost>

  | I'm not entirely sure that the behavior of sending a RA as "answer" to a
  | NS is valid under RFC 4861,

Nor am I, but it appears that is what is happening, and that other clients
don't mind (and probably old NetBSD wouldn't either) so may end up being
something we need to support, just because otherwise it all looks like our
fault, even if whatever router is doing that is technically broken.

(That part of this reply also applies to Greg's message).

  | but I also don't understand why the existing
  | code (nd6_rtr_cache) doesn't cover this.

I didn't look yet, but I will look at it when I get a chance.

  | > I'd suggest putting RA processing back into the kernel to avoid this kind
  | > of issue.
  |
  | Except of course that it introduces back all the reasons for why it was
  | removed in first place and ignores that it shouldn't happen.

I'm not sure which "it" you're meaning here (the second one, the first
is obvious, but I doubt that the two are referring to the same thing).
Is the second "it" the RA in response to a NS?

Perhaps that's true, but this might become a de-facto thing to do by
(at least some subset of) the router community - the RA conveys all the
same info an ND would, plus more, potentially reducing traffic, so strictly
valid or not, I can see how someone might decide that's a good approach to
take.

As for "all the reasons for why it was removed in first place" - I never
believed any of those to be valid.  I can believe that some fairly minor
work was required on the implementation, but nothing so difficult as to
require its removal.

Note that I'm not suggesting that processing using dhcpcd might not generally
be the better approach to use, but the kernel ought to be able to cope when
(for whatever reason) that's not running, or not doing its job.

  | Are you really arguing that non-essential functionality should be kept
  | in the kernel just because it was once present? That doesn't strike me
  | as very useful at all...

Of course, in many cases, yes.  There is tons of that already, much of it
controlled by COMPAT_xxx options - and this could be as well if anyone really
believes that an extra kernel option to eliminate this small piece of code
is really worth the effort.   But we have lots of support for ancient code
(we still support all the old sys calls and interfaces that think a time_t
is 32 bits for example, and the last NetBSD that had 32 bit time_t was eons
ago).

When something truly is useless (drivers for hardware no-one has and no-one
would want, even if still available to be obtained for example) then sure,
it can simply be removed, similarly support for protocol stacks that no-one
uses.   But keeping old (particularly versions that are still support, but
really, all) userland running correctly with current kernels should be
considered mandatory.   No exceptions.

kre