DHCPv6 client in base

[Hiroki Sato]

Roy Marples <roy at marples.name> wrote
  in <b5e0e1e1-d29c-3e47-5579-353c9d873924 at marples.name>:

ro> On 11/10/2019 20:40, Hiroki Sato wrote:
ro> >   I do not have a strong objection on dhcpcd (I am using it on some of
ro> >   my FreeBSD boxes actually) but let me explain the reason why I chose
ro> >   wide-dhcp as the candidate.  That is because it is a small,
ro> >   functional DHCPv6-only implementation.  I am planning to rewrite it
ro> >   to add the missing bits and adjust it for a tighter integration with
ro> >   kernel, ifconfig, rtsold, rtadvd, and sandboxing with Capsicum.  I
ro> >   feel dhcpcd (or others) is too big for that purpose.
ro>
ro> How are you measuring that dhcpcd is too big?
..
ro> I don't consider dhcpcd to be big at all, and would love to know your
ro> rationale for calling it so.

 I did not mean the binary size.  Again, what I need for the base
 system import is source code just for core DHCPv6 procotol for
 further FreeBSD-specific changes.  dhcpcd contains source code for
 the other protocols than DHCPv6 and non-FreeBSD platforms though it
 is possible to compile a part of them, and applying changes to it
 would not be FreeBSD-only thing because you are maintaining it in a
 portable manner actively.  Importing involves those kind of aspects.
 I expressed them as "big" than importing wide-dhcp, which is no
 longer maintained by the original authors.

 Yes, FreeBSD can have a DHCPv6-only version of dhcpcd even at the
 source code level, which will be much smaller.  But if doing so and
 applying FreeBSD-specific changes which cannot be upstreamed to it,
 we need additional steps to adjust a partial set of the dhcpcd source
 code and the contents will be diverged from the origial distribution.
 Although it is still possible, I think it is not good for both
 FreeBSD and dhcpcd.  That is because if one uses dhcpcd, rtsold in
 the base system should not be used and relying solely on dhcpcd for
 handling incoming RAs would be much better.  And probably IPv4 DHCP
 should also be handled by dhcpcd for consistency on the system.
 Thus, the question is: which is worth doing, maintaining a stripped
 version of dhcpcd or a client part of wide-dhcp, both with
 FreeBSD-specific changes applied?  Adding IPC between rtsold,
 ifconfig, and DHCPv6 client is planned for better control and user
 experience, for example.  I simply thought a
 no-longer-actively-maintained one with smaller code base is easier
 for that purpose, assuming there is no big difference in the core
 protocol coverage.  I do not insist that this is based on inferiority
 of dhcpcd in terms of quality or absolute size.  My apologies if my
 previous (and/or this) email sounds offending.  How easier we can
 chop and cook it matters.

 I emphasize again here that people who want to use dhcpcd are still
 able to install net/dhcpcd and override a combination of utilities
 such as rtsold.  Ditto for ISC's IPv6-capable dhclient.  My opinion
 about the import is that if we adopt dhcpcd in the base system, we
 should replace all of the current dhclient for IPv4 and rtsold
 together.  Of course we should consider it will need Capsicum or
 privsep for sandboxing and involve a bigger impact for IPv4 users at
 least.

 If there is no option except for dhcpcd I will go ahead with it
 regarless of my ealier mentioned concerns.  So that is why I would
 like to know if wide-dhcp has a critical issue which cannot be fixed
 easily or missing feature at this moment.

ro> This isn't a question about wide-dhcp specifically, but I feel it's a
ro> good question.
ro>
ro> Do you plan on supporting a multihomed system with hotpluggable
ro> interfaces all auto configured?
ro> I'm looking at the BUGS section for rtsold and these bugs
ro> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138547

 For multiple sources of RDNSS information, FreeBSD currently handles
 them by resolvconf(8) (yes, one of your works has been already
 imported) in the base system.  The default configuration does not
 behave very well, so for a good user experience, one needs to
 configure resolvconf.conf to control ordering and overrides.  The
 dhclient processes do not work collaboratively across multiple
 interfaces because they are just invoked independently, on a
 per-interface basis.  rtsold does not, either.  That is one of the
 reasons why I would like to add IPC between rtsold and DHCPv6 client.
 If they work, it can be implemented in dhclient in a similar way.

ro> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218191

 I could not understand what prevented dhclient from working at the
 first glance of this PR, but the cause may also be the fact that
 multiple dhcients work independently and override the default router,
 RDNSS, and/or etc.

 These scenarios are in my goals because IPv6 multihoming is more
 likey to happen than IPv4 while I am still not sure it will be a
 complete solution.  If IPC between the per-interface daemons is not
 sufficient, we should have another "parent" daemon which monitors the
 per-IF worker processes or handling everything by a single daemon,
 which is much like things dhcpcd does.

ro> This is one of dhcpcd's killer features and allows me to use my
ro> pinebook on the sofa, but hotplug in ethernet to take over so I can
ro> compile my sources from NFS over distcc much faster.

 Yes, that is one of things which cannot be handled.  I think some
 FreeBSD use lagg(4) failover to handle that situation.  It basically
 chooses the preferred interface (Ethernet) if it is up and running,
 and falls back to another (wlan) if the preferred one is link-down.
 A dhclient process runs on lagg(4), so it can be seen from userland
 as a single interface system.  It has some drawbacks which you can
 probably point out, though.

-- Hiroki
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 342 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-net/attachments/20191012/24810b96/attachment-0001.sig>