Date: Sun, 7 Aug 2022 09:08:59 -0700 From: Cy Schubert <Cy.Schubert@cschubert.com> To: Hiroki Sato <hrs@FreeBSD.org> Cc: woodsb02@freebsd.org, freebsd-net@freebsd.org, emaste@freebsd.org, roy@marples.name, brooks@freebsd.org, cy@freebsd.org, philip@freebsd.org Subject: Re: Import dhcpcd(8) into FreeBSD base Message-ID: <20220807090859.3b8da2e5@slippy> In-Reply-To: <20220807.232337.383956020917382126.hrs@FreeBSD.org> References: <e401671f-6a67-49ed-bc41-e8fbb9de27cb@www.fastmail.com> <20220807.232337.383956020917382126.hrs@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 07 Aug 2022 23:23:37 +0900 (JST) Hiroki Sato <hrs@FreeBSD.org> wrote: > "Ben Woods" <woodsb02@freebsd.org> wrote > in <e401671f-6a67-49ed-bc41-e8fbb9de27cb@www.fastmail.com>: >=20 > wo> If accepted, I would recommend a phased implementation such as that > wo> suggested below - open to ideas. > wo>=20 > wo> - 14.0 (and perhaps 13.2) - dhcpcd included but off by default > wo> - (WITH_DHCPCD=3Don, but rc.conf/network.subr continue to use > wo> - dhclient/rtsold). Release notes list forward plan. =20 >=20 > While I have no objection (or rather agree with) importing a client, > replacing the existing dhclient and rtsold would be a destructive > change from the user's perspective. I would suggest the following: >=20 > 1) Import dhcpcd and make it invoked via Other Configuration flag > in RA for DHCPv6. This means that the rtsold daemon remains a > consumer of RA messages, and the default value of the -O option is > set to run dhcpcd. >=20 > 2) Keep the dhclient utility intact and add a knob to choose dhclient > or dhcpcd (or something else) for DHCPv4. The current rc.d > scripts for DHCPv4 can be adjusted to use another client > supporting a per-interface mode. Both of these suggestions are reasonable. >=20 > The dhcpcd daemon can handle various protocols of IPv4/IPv6 and watch > multiple interfaces, so the suggestions above might sound like an > underestimation of the capability. I am concerned that changes to > replacing dhclient/rtsold will break the existing configurations. > Especially for IPv4, dhclient is mature, and many people have used > custom dhclient.conf and dhclient-script for years. I believe we > will get little gain from such change. Agreed. >=20 > In 1)+2), there is no POLA for users of other DHCPv6 clients such as > dhcp6c or ISC's dhclient -6. A full-blown dhcpcd configuration, > which replaces dhclient/rtsold, is still possible. The cons are that > this is a partial integration of dhcpcd, which prevents some useful > feature available in the master mode, and some complexity remains in > the rc.d scripts. I think these are a trade-off. I am interested in > whether this integration has a big problem when people use the > imported dhcpcd. >=20 > And probably we have to revisit this integration when we want to > support DHCP 4o6 or something that involves IPv4 and IPv6 at the same > time. The flexibility of the "toolbox" approach would be helpful in > minimizing the impact on the existing configurations when more future > integration change occurs. The flexibility of the "toolbox" should only be limited to services that facilitate booting, connection to the network, and use of services provided by servers on the network. Adding the dhcpcd client without causing POLA violations is IMO acceptable. What I believe unacceptable is adding new server services when there are many to choose from. For example there are many dhcpd server daemons to choose from. There are many DNS server daemons to choose from. There are two Kerberos KDCs to choose from (which BTW, the fact that we're "married" to one is a cause of concern to some users and the primary issue that has caused me concern over the years). There may be an argument for this service because we're talking about facilitating connecting to the network immediately after install. But I think we need to be cognizant of other options that exist for server services, like a dhcpd that serves out IP addresses, a DNS server that resolves names, a time sync daemon, or a kdc that serves out TGTs should be avoided to allow users to choose (through ports/pkgs) whatever they see will work for them. At the same time we need to keep the POLA lion at bay as much as possible. >=20 > wo> I should point out that I have a ports commit bit - not src. If > wo> accepted, I=A2d either need a src committer to land it, or approve me > wo> committing (via phabricator). > wo>=20 > wo> https://reviews.freebsd.org/D22012 > wo> https://github.com/NetworkConfiguration/dhcpcd =20 >=20 > I am happy to help in this regard. >=20 > -- Hiroki --=20 Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org e**(i*pi)+1=3D0
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220807090859.3b8da2e5>