Post by Robert ElzDate: Wed, 8 Apr 2020 19:33:40 +0100
| 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.
Post by Robert ElzThey'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 ....
Post by Robert ElzNote: 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.
Post by Robert Elz| 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.
Post by Robert ElzBut 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.
Post by Robert Elz| 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.
Post by Robert ElzIt 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.
Post by Robert Elz| 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
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de