Re: Import dhcpcd(8) into FreeBSD base

----Security_Multipart(Tue_Aug__9_05_40_39_2022_635)--
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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.

-- Hiroki

----Security_Multipart(Tue_Aug__9_05_40_39_2022_635)--
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iMkEABMKAC4WIQRsDSNTJ8+Ax5Ae/dLbsH3Gbx9zfwUCYvF0xxAcaHJzQGZyZWVi
c2Qub3JnAAoJENuwfcZvH3N/yiACCQElD9U6RqczmuC20r4VA4sCGFhxibnQH6IB
4GC9/j1RPgjGewnNJy2CvZbFz6SzBlme9I2+Jg3A8re6/rI5coueOgIIh5BErLlX
NmRjFjX8Lm03ggQlSmPnQ9Cs3sxnHwyQeFQhy4F58IydBLbxLy2JwpO7L65sOe9y
E8y6p4yj65V3lfA=
=hlur
-----END PGP SIGNATURE-----

----Security_Multipart(Tue_Aug__9_05_40_39_2022_635)----