Re: Import dhcpcd(8) into FreeBSD base

On Tue, 9 Aug 2022, at 6:21 AM, Roy Marples wrote:
> On 08/08/2022 21:40, Hiroki Sato wrote:
>> Roy Marples <roy@marples.name> wrote
>>    in <4516f415-939e-6374-45ce-df19a2ac65cb@marples.name>:
>> 
>> ro> On 07/08/2022 15:23, Hiroki Sato wrote:
>> ro> >   1) Import dhcpcd and make it invoked via Other Configuration flag
>> ro> >      in RA for DHCPv6.  This means that the rtsold daemon remains a
>> ro> >      consumer of RA messages, and the default value of the -O option is
>> ro> >      set to run dhcpcd.
>> ro>
>> ro> I don't think this is a viable option as there is no easy way to
>> ro> transition from Other to Managed (or the other way around) from the
>> ro> dhcpcd commandline or signals.
>> 
>>   The rtsold daemon just invokes a corresponding helper script when
>>   receiving RAs with these flags.  A transition from O to M or vice
>>   versa is supposed to be handled by them.  I think it is possible to
>>   stop the running dhcpcd and/or restart it with another configuration
>>   via the scripts.  Is there a critical problem with it?  I do not
>>   insist that it is the best way since it is not a graceful transition,
>>   but I still believe it should work for most DHCPv6-enabled networks.
>> 
>> ro> Also, please consider than dhcpcd supports DNSSL and RDNSS options
>> ro> from RA messages whereas FreeBSD rtsold/kernel RA do not (please
>> ro> correct me if I'm wrong).
>> 
>>   The FreeBSD rtsold has supported them for >10 years.  Resolvconf, one
>>   of your projects, was imported at the same time to solve the problem
>>   of multiple information source for /etc/resolv.conf.
>> 
>> ro> Sure it works fine for the one interface wired system - which
>> ro> admitedly is the most popular setup. But when more than one interface
>> ro> comes into play or you have plugable interfaces it then becomes more
>> ro> complicated and will consume more resources having many more daemon
>> ro> runing to allow capsicum and makes dhcpcd just as predictable as
>> ro> dhclient on a multi-homed system (ie it's not predictable).
>> ro>
>> ro> I modified wpa_supplicant upstream to support the -M directive (I
>> ro> don't know if FreeBSD compiles wpa_supplicant with CONFIG_MATCH_IFACE
>> ro> defined) to allow plugable interfaces just for this reason.
>> 
>>   I agree that running processes for each interface independently is
>>   sub-optimal.  However, I think it is a separate topic from whether
>>   importing a DHCPv6 client into the base system or not.  More
>>   specifically, the following three are orthogonal:
>> 
>>   1. Use dhcpcd or not as a replacement of dhclient and rtsold.
>> 
>>     This leads to a never-ending discussion.  Some people like the
>>     existing ones because they have worked well and do not want to
>>     change.
>> 
>>   2. Adopt a single process managing the multiple interfaces on the
>>      system or use per-interface processes.
>> 
>>     Changing this requires a lot of work and breaks the existing
>>     configurations.  A side node of the design and behavior of the
>>     current rc.d/netif is as follows:
>> 
>>     - The current rc.d/netif (and other network-related rc.d scripts
>>       such as rc.d/wpa_supplicant) are based on the per-interface
>>       model.  The rc.d/netif script is invoked asynchronously while it
>>       also runs at boot time sequentially.  This asynchronous
>>       invocation is specific to FreeBSD, and not seen in other BSDs
>>       (correct me if I am wrong).
>> 
>>     - The devd(8) daemon is the main process receiving events of the
>>       interfaces such as arrival/departure/link-state changes, and
>>       invokes a process upon an event if necessary.
>> 
>>     - The rtsold(8) daemon is the main process receiving RAs in
>>       userland and invokes a process upon an event if necessary.
>>       Currently, it handles O/M flags and RDNSS/DNSSL options.
>> 
>>   3. Add an implementation of the DHCPv6 client-side functionality or
>>      not.
>> 
>>     I believe no one objects for adding one because we have no
>>     implementation in the base system.  Some people like another one,
>>     such as ISC dhclient or WIDE dhcp6.
>> 
>>   My opinion is: 1) "no need", 2) "keep the current model for a while",
>>   and 3) "go for it".  I tend to prefer WIDE dhcp6 because I have used
>>   it for >15 years with accumulated local patchset, but I do not stick
>>   to it as long as there is a good working implementation supporting
>>   IA_NA and IA_PD, and someone actively maintains it.  WIDE dhcp6 works
>>   well, but it has a lot of rough edges (and fixed locally by many
>>   people, as bz@ pointed out).
>> 
>>   As mentioned in my previous email, avoiding POLA violations is the top
>>   priority.  Regardless of which implementation we import, I still
>>   believe keeping the current per-interface model is the least
>>   intrusive for the existing configurations.
>> 
>>   So we need a consensus about how to get started with the integration.
>>   An idea in my mind is: 1) import dhcpcd (or whatever supports
>>   per-interface mode), 2) add a per-interface helper script for it, and
>>   3) set rtsold_enable="YES" effectively by default for all
>>   RA-accepting interfaces so that people do not need to manually
>>   configure it at least on an IPv6 network with M/O bit enabled.  This
>>   should be enough for IA_NA.  More complicated configurations can be
>>   supported incrementally.
>> 
>>   And I hope this discussion focuses on how to integrate DHCPv6
>>   functionality, not changing the current rc.d/netif drastically or
>>   replacing the existing components unrelated to DHCPv6 such as
>>   dhclient or rtsold.  If the import involves an immediate change of
>>   the current model due to the nature of the implementation, I cannot
>>   entirely agree with it.
>> 
>>   Technical discussions about improving the current model are always
>>   welcome.  I am also interested in them because I have recognized the
>>   downsides since I am one of the contributors who have added
>>   substantial changes to network.subr over the years.  However,
>>   thinking about the import and the improvement of boot-time
>>   configuration together does not make good sense to me to judge the
>>   reasonableness of the import.
>
> I agree with all of this.
>
> I would only ask that there is the ability to just enable dhcpcd as a generic 
> service in rc.conf as dhcpcd_enabled=YES so that people can play with it as 
> intended and not affect any existing configuration.
>
> Roy

I agree with the plan also - Import dhcpcd with its dedicated rc.d script (build enabled with runtime off by default, but manually enabled by dhcpcd_enable=“YES”).

No need to change the rc or network.subr system for now, as dhclient and rtsold are already off by default (or if enabled by default will be possible to disable in rc.conf).

No need to have plans to remove dhclient/rtsold now - let’s give people the option for now, with no plan to necessarily remove dhclient/rtsold.

Hiroki - I’ll update my phabricator review to align with the above.

Regards,
Ben

-- 
From: Ben Woods
woodsb02@freebsd.org