On Mon, 8 Aug 2022, Roy Marples wrote:
Also, please consider than dhcpcd supports DNSSL and RDNSS options from RA
messages whereas FreeBSD rtsold/kernel RA do not (please correct me if I'm
wrong).
This allows for a fully working IPv6 only setup without DHCPv6.
Yeah I think we had that for over a decade... (as it has been pointed out
before in older threads as well)
commit db82af41db538fba5938d8585b2e2e2c206affb6
Author: Hiroki Sato <h...@freebsd.org>
AuthorDate: Mon Jun 6 03:06:43 2011 +0000
Commit: Hiroki Sato <h...@freebsd.org>
CommitDate: Mon Jun 6 03:06:43 2011 +0000
- Implement RDNSS and DNSSL options (RFC 6106, IPv6 Router Advertisement
Options for DNS Configuration) into rtadvd(8) and rtsold(8). DNS
information received by rtsold(8) will go to resolv.conf(5) by
resolvconf(8) script. This is based on work by J.R. Oldroyd (kern/156259)
but revised extensively[1].
...
2) Keep the dhclient utility intact and add a knob to choose dhclient
or dhcpcd (or something else) for DHCPv4. The current rc.d
scripts for DHCPv4 can be adjusted to use another client
supporting a per-interface mode.
I would argue that having knobs to control dhcpcd (or any other similar
network tool for that matter) in rc.conf per interface is a bad idea because
this discourages running dhcpcd in manager mode. You even note this below,
but here are some more comments.
FreeBSD since we last time changed dhclient have had a very liberal way of
allowing users to choose while still providing a default. These things never
go without hiccups.
I believe what some of us actually have a problem with is (a) the actual
way this is integrated into the rc framework and (b) to some extend that
the original proposal indicates to possibly remove the current defaults
(soon). We've lived with these things for 2 decades and throwing everything
out over night and replacing it doesn't work for (some of) us.
I see some benefits of it but I also see a lot of drawback in the
one-thing-fits-all approach. It's not the UNIX philosophy.
*Personally* for a decade++ I've been running IPv6-only systems, I have a branch
somewhere where I started to work through the entire base system to make things
compile if they lack IPv4 header(s) or bits thereof. I *personally* see very
little gain from importing new IPv4 code which replaces something which worked
well for a looong time providing close to no new benefits (and I emphasize the
personally as I do understand and accept that IPv4 is very important thing to
a lot of people and business still and that it needs to be maintained and
supported for those in need).
At the same time I agree that integration on the IPv6 side of FreeBSD lacks
behind and I do see the advantages of an intertwined RS/RA/DHCPv6 solution
though for a lot of situations the split solution will be "just fine" as the
real challanges come with the integration of other services or other missing
bits we simply haven't done.
I was hoping this proposal would help solve two problems not just replacing
X and Y for Z.
I can tell on another note as it came up in this thread:
(a) wide-dhcpv6 is "maintained" by a lot of people (companies, Linux distros,
..)
and if the right people would have opened a new repo and collected (and
maintained)
bits (a few years ago) we'd likely not have this discussion but the problem
would be long solved for FreeBSD.
(b) I have trees with wide-dhcpv6 imported into base privately and know how that
works as a default (I also know what doesn't work well but that's not
specific
to the DHCPv6 client implementation)
(c) Like many I have patches to aid functionality and fix things (kind-of
waiting
for (a) to happen to ridden my tree of them). I have so far resisted to
make
FreeBSD that repo though I probably should have years ago.
The dhcpcd daemon can handle various protocols of IPv4/IPv6 and watch
multiple interfaces, so the suggestions above might sound like an
underestimation of the capability. I am concerned that changes to
replacing dhclient/rtsold will break the existing configurations.
Especially for IPv4, dhclient is mature, and many people have used
custom dhclient.conf and dhclient-script for years. I believe we
will get little gain from such change.
We can leave current dhclient/rtsold configuration intact and suggest people
move to dhcpcd by themselves.
People that want DHCPv6 or a better DHCP or RA expierience already have some
solution in place which might even be dhcpcd from ports. I don't see any
reason to stamp on their toes.
If FreeBSD does import dhcpcd, then I would suggest any talk of removal of
dhclient can happen after a version of two.
And the same goes for rtsol(d).
In 1)+2), there is no POLA for users of other DHCPv6 clients such as
dhcp6c or ISC's dhclient -6. A full-blown dhcpcd configuration,
which replaces dhclient/rtsold, is still possible. The cons are that
this is a partial integration of dhcpcd, which prevents some useful
feature available in the master mode, and some complexity remains in
the rc.d scripts. I think these are a trade-off. I am interested in
whether this integration has a big problem when people use the
imported dhcpcd.
And probably we have to revisit this integration when we want to
support DHCP 4o6 or something that involves IPv4 and IPv6 at the same
time. The flexibility of the "toolbox" approach would be helpful in
minimizing the impact on the existing configurations when more future
integration change occurs.
Agreed. I noted my concerns above and would favour a full blown dhcpcd
configuration for new installs and leave the current dhclient/rtsold for
exising installs. No need to force people to move.
I think that is a very sensible approach to do it incrementally.
If people can agree on
(1) importing it and first closing the gap of the missing DHCPv6 client making
sure it does all people have accumultaed over the years,
(2) and then solving the "how do I disable dhclient and rtsold and per-IF
configs
and just run the-one-thing as an alternative in rc" in the 2nd step
I would think that will (a) reduce resistance and (b) give more time to test
and try for people, especially in 14 but it would (c) also be backward cmpatible
with 13 and thus smoothen (and possibly accelerate) any possible transition
and could possibly be MFCed even to provide (integrated) DHCPv6 there as well.
And I am not saying that (2) couldn't follow within days or weeks of (1). I am
just
saying that I'd prefer it to be seen as a distinct problem.
Then the next questions would be if or when to flip the default and as indecated
before and above if/when to remove the current state of art but if we take a
step
at a time we'll probably save ourselves a lot of discussion and can move
forward?
My 0.001ct
/bz
--
Bjoern A. Zeeb r15:7
