Date: Tue, 20 Apr 2021 21:13:15 +0200 From: Joerg Sonnenberger <jo...@bec.de> Message-ID: <YH8ny/9emssid...@bec.de>
| 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