Date: Sat, 12 Oct 2019 11:04:55 +0900 (JST) From: Hiroki Sato <hrs@allbsd.org> To: roy@marples.name Cc: woodsb02@gmail.com, hrs@freebsd.org, freebsd-net@freebsd.org, driesm.michiels@gmail.com Subject: Re: DHCPv6 client in base Message-ID: <20191012.110455.1650077722278454495.hrs@allbsd.org> In-Reply-To: <b5e0e1e1-d29c-3e47-5579-353c9d873924@marples.name> References: <CAOc73CCLPmB7m3yaDE7p4izJ8apaO5jcyRPyLkSJtopqsHxtSQ@mail.gmail.com> <20191012.044034.19725945241254130.hrs@allbsd.org> <b5e0e1e1-d29c-3e47-5579-353c9d873924@marples.name>
next in thread | previous in thread | raw e-mail | index | archive | help
----Security_Multipart(Sat_Oct_12_11_04_55_2019_447)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Roy Marples <roy@marples.name> wrote in <b5e0e1e1-d29c-3e47-5579-353c9d873924@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 ----Security_Multipart(Sat_Oct_12_11_04_55_2019_447)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iMkEABMKAC0WIQRsDSNTJ8+Ax5Ae/dLbsH3Gbx9zfwUCXaE0xw8caHJzQGFsbGJz ZC5vcmcACgkQ27B9xm8fc38x3QIJARU8HKxCZ7gpDxrinoHO5HzqH9c/pCuB19cx 7tlP/ivsPyKWvqY9w0IhuHz8QygfovO2pLBhkk+sNxI3EUgT/ubNAgkB5aJNTjjY Jk7INxabwZK6CYYl4/XSGljkW/nj1GSfCNrZ3ZrOnUVAW3W91GmipU/qzSCM5txX JloK76OaZOEVeio= =dLho -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Oct_12_11_04_55_2019_447)----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20191012.110455.1650077722278454495.hrs>