> -----Original Message-----
> From: owner-freebsd-...@freebsd.org <owner-freebsd-...@freebsd.org> On
> Behalf Of Bjoern A. Zeeb
> Sent: Monday, 8 August 2022 18:43
> To: Roy Marples <r...@marples.name>
> Cc: freebsd-net@freebsd.org
> Subject: Re: Import dhcpcd(8) into FreeBSD base
>
> 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
This is a sensible approach, importing and taking things step by step will
aid in moving things forward.
I do think that when dhcpcd is imported it should be built by default (but
not do anything out of the box, unless explicitly enabled)
Compiling it by default, instead of defining a WITH_DHCPCD, would result in
less resistance to try it out on RELEASES, even in CURRENT and STABLE.
dhcpcd has since gained capsicum and full privilege separation support, I
don't think there are any large concerns left to not include it by default.
> 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
