From nobody Wed Aug 10 00:46:21 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 4M2WTv59lpz4YB1B for ; Wed, 10 Aug 2022 00:46:43 +0000 (UTC) (envelope-from woodsb02@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M2WTv4gHYz3vmV for ; Wed, 10 Aug 2022 00:46:43 +0000 (UTC) (envelope-from woodsb02@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660092403; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=j7BrQICMfpsq9kRbIAwonmgsxSLjroZ0+h8rpeEMm4M=; b=SkGfULwlpJzJ+1HCRj6SP/8poLH97SaUAOgQE95AetYWaEv44bUIJbSZtuGDdVoLSGD2fY q+maEK0MEwLL7IM8BDpaCh9A1n3m2CzS+G8ziBQq2MohFIfCzlT2LYHaOa43MGREwbmmMG hsV/gKbTnRMHRM1Tj3dwXeF4ElVpgweKUtSH7BYAdRUbgp+xxz5/qeXqGERZJ0zVJOJPOF ZyRSsHq0ai2tmvVwJZI+gJnP99iLlrSMPFhroGbPDIVs8GC4d8Gf4K+fC8nsIa1p2rswMw kaq4+KSwtxKL0DnXHKLjoogKeDvqitrYm1In8y0M/3GMQ018fObvzrHHHsHkug== Received: from auth2-smtp.messagingengine.com (auth2-smtp.messagingengine.com [66.111.4.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: woodsb02) by smtp.freebsd.org (Postfix) with ESMTPSA id 4M2WTv3Zb2z1WFg for ; Wed, 10 Aug 2022 00:46:43 +0000 (UTC) (envelope-from woodsb02@freebsd.org) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id 2919E27C0054 for ; Tue, 9 Aug 2022 20:46:43 -0400 (EDT) Received: from imap46 ([10.202.2.96]) by compute2.internal (MEProxy); Tue, 09 Aug 2022 20:46:43 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdeguddgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdeuvghnucghohhoughsfdcuoeifohhoughssgdtvdes fhhrvggvsghsugdrohhrgheqnecuggftrfgrthhtvghrnhepudevuefhgfekkeejleetvd egffeggfejtdelvdfgfeejhffhueegiedvgfduiefhnecuffhomhgrihhnpegtohhnfhdr rhhopdgtohhnfhdrnhhonecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepsggvnhdomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidquddt leefieeivdekkedqvdegjeekvddvkedtqdifohhoughssgdtvdeppehfrhgvvggsshgurd horhhgseifohhoughsrdgrmh X-ME-Proxy: Feedback-ID: if9c9472a:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id E75532A20075; Tue, 9 Aug 2022 20:46:42 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-811-gb808317eab-fm-20220801.001-gb808317e 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 Message-Id: <03de2ce0-b3ca-4dcb-a40b-1962fe740b44@www.fastmail.com> In-Reply-To: <74a1d9c2-6eab-b685-e71e-7d69a6fe6a9f@marples.name> References: <20220807.232337.383956020917382126.hrs@FreeBSD.org> <4516f415-939e-6374-45ce-df19a2ac65cb@marples.name> <20220809.054039.722614217650843004.hrs@FreeBSD.org> <74a1d9c2-6eab-b685-e71e-7d69a6fe6a9f@marples.name> Date: Wed, 10 Aug 2022 08:46:21 +0800 From: "Ben Woods" To: freebsd-net@freebsd.org Subject: Re: Import dhcpcd(8) into FreeBSD base Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1660092403; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=j7BrQICMfpsq9kRbIAwonmgsxSLjroZ0+h8rpeEMm4M=; b=ACTBIJhqrSsSk0GTEhhunbhF0eBZltfaqxIQRxLBVq8xzHLljUISpgTnM3cJe89lYwLZOe AedOLqfc3y+/yNfwGCxtjkQGazUtfXO1iXJSmNAo8BO6yVm0+kVg/Ae6Ht1n5w/9EQsrH/ uXqaXpReBvahv+TN7LkJljUPwF+qcynN25HLAEnznP5V0H1GVzFgF3VNi8vXlesXtIptju JvMh/6tH61IK9v2KuFU1pfeYXr2M5N+XOPuByoWE7YcjiliIclVylI6bhvsRxXZpNkdNGc XTFGZIXcTKQRYeRZN9cG7FgVLdQFX3R05cBoYpw+g2tFxuPWX7ImoBXlhHYo1Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1660092403; a=rsa-sha256; cv=none; b=cmjCQL6fHLdZ9KjyFpb5VICiIleqJAHyTTRTLFT4lWG3lLPIo2vvYxq0/GECqNjb7zDH4K okQ4e3T2JLAsoxP7KduBweIHg+Xrdb52MpdFqL82UEK0rS8SgwR4geDvVlZ50iRxQTTU8A urqptCdzCan87Xj46aQUMRnHWLa2yOpUKc6VwFTVUEzsuk85zK1IQDJAhKxDotWPNtQ1B8 niP5xMmLxEjfUPNjcPVm4SvcyXfJU1KtagmOA4Wom/vEOvB8ebaZ3Z2aLvP0K/k6ACNIQX Xd7OBvrLROg5bzc6S9e2om4+QF7m/5H8avjPAXdsW7BVbFlRuRyugp5reKPwRw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Tue, 9 Aug 2022, at 6:21 AM, Roy Marples wrote: > On 08/08/2022 21:40, Hiroki Sato wrote: >> Roy Marples wrote >> in <4516f415-939e-6374-45ce-df19a2ac65cb@marples.name>: >>=20 >> 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 remai= ns a >> ro> > consumer of RA messages, and the default value of the -O o= ption 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 t= he >> ro> dhcpcd commandline or signals. >>=20 >> 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 transitio= n, >> but I still believe it should work for most DHCPv6-enabled networks. >>=20 >> 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). >>=20 >> The FreeBSD rtsold has supported them for >10 years. Resolvconf, o= ne >> of your projects, was imported at the same time to solve the problem >> of multiple information source for /etc/resolv.conf. >>=20 >> ro> Sure it works fine for the one interface wired system - which >> ro> admitedly is the most popular setup. But when more than one inter= face >> ro> comes into play or you have plugable interfaces it then becomes m= ore >> ro> complicated and will consume more resources having many more daem= on >> 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_I= FACE >> ro> defined) to allow plugable interfaces just for this reason. >>=20 >> 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: >>=20 >> 1. Use dhcpcd or not as a replacement of dhclient and rtsold. >>=20 >> This leads to a never-ending discussion. Some people like the >> existing ones because they have worked well and do not want to >> change. >>=20 >> 2. Adopt a single process managing the multiple interfaces on the >> system or use per-interface processes. >>=20 >> 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: >>=20 >> - 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). >>=20 >> - 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. >>=20 >> - 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. >>=20 >> 3. Add an implementation of the DHCPv6 client-side functionality or >> not. >>=20 >> 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. >>=20 >> 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 wor= ks >> well, but it has a lot of rough edges (and fixed locally by many >> people, as bz@ pointed out). >>=20 >> 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. >>=20 >> So we need a consensus about how to get started with the integratio= n. >> An idea in my mind is: 1) import dhcpcd (or whatever supports >> per-interface mode), 2) add a per-interface helper script for it, a= nd >> 3) set rtsold_enable=3D"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. >>=20 >> 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. >>=20 >> 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. > > I agree with all of this. > > I would only ask that there is the ability to just enable dhcpcd as a = generic=20 > service in rc.conf as dhcpcd_enabled=3DYES so that people can play wit= h it as=20 > intended and not affect any existing configuration. > > Roy I agree with the plan also - Import dhcpcd with its dedicated rc.d scrip= t (build enabled with runtime off by default, but manually enabled by dh= cpcd_enable=3D=E2=80=9CYES=E2=80=9D). No need to change the rc or network.subr system for now, as dhclient and= rtsold are already off by default (or if enabled by default will be pos= sible to disable in rc.conf). No need to have plans to remove dhclient/rtsold now - let=E2=80=99s give= people the option for now, with no plan to necessarily remove dhclient/= rtsold. Hiroki - I=E2=80=99ll update my phabricator review to align with the abo= ve. Regards, Ben --=20 From: Ben Woods woodsb02@freebsd.org