Re: Question about NetBSD implementation of IPv6 SLAAC and RFC4941

[Roy Marples <roy%marples.name@localhost>]

On 08/04/2020 20:09, Robert Elz wrote:
>      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.

Because the source address has not yet been validated .....
Go read RFC 4862 5.4 - you have to send the RS from a unicast source address.

> 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.

The RS does. Modern RFC's will give you a different LL address per SSID you 
connect to. Not that the kernel supports this ....

> 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.

And this is the reason why it should be removed.
It's easier in userland.

>    | 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.

No-one is maintaining this other than going through the motions of keeping it 
working.

It's behind the times in current RFCs.

It doesn't work with my basic use case of the same prefix on wired and wireless 
because the kernel cannot manage this.

There is no mechanism to extract RDNSS and DNSSL from the RA and more 
importantly use it.

Ignores (last I checked) MTU.

No way of preffering RA's from different interfaces.
It's first come, first served which is not deterministic.

Does not failover to another router when the current one becomes unreachable.

> 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.

How do you envisage DNS working in this IPV6 only world?

Anyway, I can easily argue that tiny applications benefit from using dhcpcd:
$ ls -l nd6_rtr.o ~/src/dhcpcd/src/ipv6.o ~/src/dhcpcd/src/ipv6nd.o
-rw-r--r--  1 roy  users   99608 Apr  8 20:50 /home/roy/src/dhcpcd/src/ipv6.o
-rw-r--r--  1 roy  users   83016 Apr  8 20:50 /home/roy/src/dhcpcd/src/ipv6nd.o
-rw-r--r--  1 roy  users  243280 Apr  8 20:59 nd6_rtr.o

So dhcpcd handling RA will take less disk space and presumably less memory than 
the kernel. Which frankly is pretty damned amazing when you consider what dhcpcd 
does support with RA's and what NetBSD's in kernel RA does not. I'll note that a 
lot of ipv6.o is shared with the DHCPv6 part as well.

I know a few companies that use dhcpcd in ramdisks in very tiny embedded systems 
with great success.

>    | 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?

Set the home directory of _dhcpcd to /var/empty and it will refuse chroot.
You could also remove the _dhcpcd user but that might lead to postinstall 
bitching or potential upgrade issues.

Another option is to compile it out of dhcpcd - the Makefile for it should be 
pretty self explanatory on now to do this.

You could even get ultra pedantic and not compile IPv6 entirely in dhcpcd so 
it's just an IPv4 client. How could even go the other way and compile it as IPv6 
only. And before the foolish asks, yes could could even disable IPv4 and IPv6 at 
which point it becomes an ifwatchd(8) clone, but with more bells an whistles.

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

Of course, bugs never exit in old software which has had many eyes.
But you and I both know this is a fallacy.
Reducing the attack surface is always a win.

>    | 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).

I've already listed other reasons above.

Roy