From nobody Sun Aug 7 16:08:59 2022 X-Original-To: freebsd-net@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4M145W4n6Nz4YJ6C for ; Sun, 7 Aug 2022 16:09:03 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta002.cacentral1.a.cloudfilter.net (omta002.cacentral1.a.cloudfilter.net [3.97.99.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M145W0QF1z3k9r; Sun, 7 Aug 2022 16:09:03 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from shw-obgw-4003a.ext.cloudfilter.net ([10.228.9.183]) by cmsmtp with ESMTP id Kbk0oa5B3Sp39KipqoPb7Q; Sun, 07 Aug 2022 16:09:02 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id KipooEvsmvn7BKippo1cv0; Sun, 07 Aug 2022 16:09:02 +0000 X-Authority-Analysis: v=2.4 cv=a/cjSGeF c=1 sm=1 tr=0 ts=62efe39e a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=xqWC_Br6kY4A:10 a=E_FQspuQcigA:10 a=biHskzXt2R4A:10 a=6I5d2MoRAAAA:8 a=ZLGELXoPAAAA:8 a=NEAV23lmAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=27jjQm8SoLBCsT-nYhEA:9 a=o3X3QV6JOaEA:10 a=IjZwj45LgO3ly-622nXo:22 a=CFiPc5v16LZhaT-MVE1c:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 0E6FF158; Sun, 7 Aug 2022 09:09:00 -0700 (PDT) Received: from slippy (localhost [IPv6:::1]) by slippy.cwsent.com (Postfix) with ESMTP id D7F80117; Sun, 7 Aug 2022 09:08:59 -0700 (PDT) Date: Sun, 7 Aug 2022 09:08:59 -0700 From: Cy Schubert To: Hiroki Sato 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: <20220807.232337.383956020917382126.hrs@FreeBSD.org> Organization: KOMQUATS X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) List-Id: Networking and TCP/IP with FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-net List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfPaPZcsqSj1164MuE1FXVRAavp0n3Bo7DuvsDG2KF7Hx9SyHuWEpC/4qDjWhSZYESKE9wu+LZZTfaF2NqojNbhyop0YqcN6o6i0x+tLJvxX5t/HP1Nxx CGZLL3cHulEx0TVmWmMRps9xjnnyvY8OQVA3oDwoxacNbuTEXmdNhuyyqUGsApBUmWiMyJP9/TSpHIMG/SJtSR7BwkRDGsIQXbSez+30o1kHm9qETv9NH7/2 /QsJEudMGjmvQj1Ve3r8RLNNqaxas5WwR6fgZbCg3NwPZ4aXRALuV5jREA7E/IYR08uaDDiShqwXJEHI8FPRVqMwJi5NECvaeRg4XDKrYB5qUfPASaEEupte uZfd/+/OpipJKweZ80VbW14jclJbf6902fbUoPBJmq14RJ9k0Wc= X-Rspamd-Queue-Id: 4M145W0QF1z3k9r X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of cy.schubert@cschubert.com has no SPF policy when checking 3.97.99.33) smtp.mailfrom=cy.schubert@cschubert.com X-Spamd-Result: default: False [-1.79 / 15.00]; AUTH_NA(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.997]; NEURAL_HAM_SHORT(-1.00)[-0.996]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_IN_DNSWL_MED(-0.20)[3.97.99.33:from]; MIME_GOOD(-0.10)[text/plain]; RCPT_COUNT_SEVEN(0.00)[8]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; R_DKIM_NA(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ORG_HEADER(0.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US]; RCVD_COUNT_FIVE(0.00)[5]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_HAS_DN(0.00)[]; DMARC_NA(0.00)[cschubert.com: no valid DMARC record]; TO_DN_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, 07 Aug 2022 23:23:37 +0900 (JST) Hiroki Sato wrote: > "Ben Woods" wrote > in : >=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 FreeBSD UNIX: Web: http://www.FreeBSD.org NTP: Web: https://nwtime.org e**(i*pi)+1=3D0