Date: Mon, 8 Aug 2022 19:48:07 +0200 From: <driesm.michiels@gmail.com> To: "'Bjoern A. Zeeb'" <bz@FreeBSD.org>, "'Roy Marples'" <roy@marples.name> Cc: <freebsd-net@freebsd.org> Subject: RE: Import dhcpcd(8) into FreeBSD base Message-ID: <004a01d8ab4f$04e12660$0ea37320$@gmail.com> In-Reply-To: <alpine.BSF.2.00.2208081552160.68830@ai.fobar.qr> References: <e401671f-6a67-49ed-bc41-e8fbb9de27cb@www.fastmail.com> <20220807.232337.383956020917382126.hrs@FreeBSD.org> <64e22fba-3f34-a419-2e51-7dfa21199919@marples.name> <alpine.BSF.2.00.2208081552160.68830@ai.fobar.qr>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?004a01d8ab4f$04e12660$0ea37320$>