RE: Import dhcpcd(8) into FreeBSD base

> -----Original Message-----
> From: owner-freebsd-net@freebsd.org <owner-freebsd-net@freebsd.org> On
> Behalf Of Bjoern A. Zeeb
> Sent: Monday, 8 August 2022 18:43
> To: Roy Marples <roy@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 <hrs@FreeBSD.org>
> AuthorDate: Mon Jun 6 03:06:43 2011 +0000
> Commit:     Hiroki Sato <hrs@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