Re: Question about NetBSD implementation of IPv6 SLAAC and RFC4941

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

    Date:        Wed, 8 Apr 2020 19:33:40 +0100
    From:        Roy Marples <roy%marples.name@localhost>
    Message-ID:  <bc6d280c-912d-750c-4a30-1428166d17a9%marples.name@localhost>

  | You would need DaD to finish on the LL address,

Why?   If I can send a DaD packet (NS), I can send an RS packet.   They're
not materially different.   If I can receive a reply to a DaD packet (on
the off chance that there is a conflict) I can receive an RA.   The RA
doesn't change based upon what address I end up using, so there is absolutely
no reason to wait until my address is fixed to request and process it.

  | which means the carrier needs to be up too.

Of course.   It has to be possible to send & receive packets.

  | Random delay are a RFC requirement.

I know, and I know why, I was in the room when all this was
initially decided, and in general I support that.

But because I know why, I also know it doesn't matter to me.

Note: I am not proposing that the code I use be incorporated
into NetBSD (or even shared with anyone), it would need a bunch
of work (including random delays, and retries, and someone who knows
how to check its SMP worthiness properly) before that could
happen.

  | When I code on the sofa on my pinebook, my urtwn

Wireless?  Yes, for that you would probably want retries, for me
all this is on wired links.   Unless something is broken (in which
case none of this really matters, as nothing is going to work anyway)
when the link is attached, carrier appears, and packets get sent
and delivered (and no, the relevant links do not have spanning tree
enabled, they're not connected to bridges).

  | Still, no-one has actually come up with a technical reason why the
  | kernel should handle RA's.

No-one has come up with a technical reason why it shouldn't.

But if you want a reason, consider tiny embedded systems, where the (much
cut down) kernel, and perhaps one application (replacing init), is all that
exists.

  | From a security perspective, handling it in a chrooted environment 
  | with an unpriviledged user would be a lot better yes?

No.  chroot doesn't have nearly the benefits that are sometimes attributed
to it (and sometimes desired of it).   Other systems have tried to improve
it (fortunately, we haven't fallen into that rabbit hole) with poor success.

Which reminds me - I have yet to install a system with the latest dhcpcd
that has the chroot ability - but from a quick glance, I didn't see how to
turn it off, and continue the old way.   I don't run any of the daemons
that support chroot chroot'd - not even the ones which arguably could
benefit a little (because of their complexity, and hence probably bugs).

What is the method to run the new dhcpcd as root, in the original directories?

It is also really hard to see how processing RA packets can possibly be
done so badly as to require that kind of protection.

  | That's just one of many 
  | technical reasons why RA should be removed from the kernel.

Except it isn't.  The only other one (I suppose 2 is "many") seems to
have been "it is a lot of code" (which by comparison with many other
things, it really isn't).

kre