Re: Import dhcpcd(8) into FreeBSD base

From: Roy Marples <roy_at_marples.name>
Date: Mon, 08 Aug 2022 22:21:35 UTC
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