Re: IPv6 default route flapping

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Wed, Apr 21, 2021 at 02:21:51AM -0700, John Nemeth wrote:
> On Apr 20, 21:13, Joerg Sonnenberger wrote:
> } On Wed, Apr 21, 2021 at 12:54:36AM +0700, Robert Elz wrote:
> } > It seems as if what is happening, is that the router is sending RA's with
> } > the source-link addr option, which isn't being added to the neighbour
> } > cache.
> } > 
> } > Then NetBSD is doing a NS to discover the address it ignored from the RA,
> } > but instead of replying with a ND as would perhaps be expected, the router
> } > is simply sending another RA (containing the relevant addr info, which would
> } > answer the NS if processed).
> } 
> } I'm not entirely sure that the behavior of sending a RA as "answer" to a
> } NS is valid under RFC 4861, but I also don't understand why the existing
> } code (nd6_rtr_cache) doesn't cover this. That would be a good place to
> } debugging this.
> } 
> } > 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.
> 
>      RA processing is fundamental to the operation of IPv6.  Removing
> it was extremely stupid and not well thought out.  The decision
> should be reverted.  I didn't have a problem with a sysctl to
> disable it, but I have a huge problem with removing it completely.

RA processing is not time-sensitive. It doesn't require any special
interfaces. A correct and useful implementation requires non-trivial
policy decisions. There are a lot of reasons for why it should not be
part of the kernel and very few of why it should be. In fact, other
systems never implemented it in the kernel or have similary moved it for
pretty much the same reason.

> } > I have another reason for wanting that ... I run a reasonably current HEAD
> } > kernel (9.99.80 from mid Feb at the minute, though I can upgrade that as
> } > soon as there's a reason) but a fairly old userland (8.99.12 from late Jan, 
> } > 2018)
> } > 
> } > Upgrading the kernel without upgrading userland is supposed to be supported.
> } 
> } Are you really arguing that non-essential functionality should be kept
> 
>      It is essential functionality.  Arguing otherwise is just silly.

It is core functionality. It is not essential. It is not necessary for
link-local communication or when using static configuration. Again, that
doesn't say anything about whether it *has* to be in the kernel.

> } in the kernel just because it was once present? That doesn't strike me
> } as very useful at all...
> 
>      Also, we should not be forced to use one particular application
> to get basic IPv6 functionality.  dhcpcd started out as a simple
> DHCP client and then grew into being a full blown network manager
> as well as encompasing half the IPv6 stack.

Maybe because the problem domain is larger than "a DHCP(v4) client" and
IPv4 and IPv6 functionality are often coupled? Maybe because splitting
it artifically would result in duplicatation of code for little benefit?
Let's just ignore the silly exagerration...

>      If nothing else, consider the case of trying to rescue a broken
> system.  You shouldn't have to run an over complicated program just
> to enable basic network functionality (the day will come when you
> will be on a network that doesn't run IPv4, or have useful services
> on IPv4).

You can configure the local network by hand via ifconfig or route, just
like you would for IPv4. Or you know, use the same tool that you would
use for DHCP. 

Joerg