From nobody Mon Aug 8 20:40:39 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 4M1p955JKPz4Y5x5 for ; Mon, 8 Aug 2022 20:44:41 +0000 (UTC) (envelope-from hrs@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 4M1p954s9Wz3qQL; Mon, 8 Aug 2022 20:44:41 +0000 (UTC) (envelope-from hrs@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659991481; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gzgiY/iC9ZNeDF5HdzqmjUL4ocYOeYYDYbSUX5ZTQWA=; b=MyxQ6CiHIJYqpcwK1TL8EzgATXSg62oWyw3WQlxJtXj8DnOfMl09h6YUloX49rWNmHiMA7 ujzYvN8eDbCxXqtSOW6WR8W0OWbHA7k1ed0JP9n+xvPJW3wvRV5/ghpYbggvX1rvbx2Nvd AOTp8jQU2ChfnOcDtsWU+h/seOJK3vLx7JgrrnNAK3VozwP5Lg+dGlpHBuUqRTqp7DoiR4 duZQtp6dWKrfMLaptEh5QFMFXUj8IhZwWjLb2QxOzhiCUoj/6bM+M32uuYrmqOS8uP0akE 0ZqrkZfx6oqGIgOej2mm95IDHVR2ChDdUAAdMcxj4AeNBvKWlWVX/DZWZOd4ww== Received: from localhost (unknown [IPv6:2400:4051:a743:3c00:5a9c:fcff:fe10:ffc2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: hrs) by smtp.freebsd.org (Postfix) with ESMTPSA id 4M1p9354cTz134g; Mon, 8 Aug 2022 20:44:39 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Date: Tue, 09 Aug 2022 05:40:39 +0900 (JST) Message-Id: <20220809.054039.722614217650843004.hrs@FreeBSD.org> To: woodsb02@freebsd.org, roy@marples.name Cc: freebsd-net@freebsd.org, emaste@freebsd.org, brooks@freebsd.org, cy@freebsd.org, philip@freebsd.org, hrs@FreeBSD.org, bz@freebsd.org Subject: Re: Import dhcpcd(8) into FreeBSD base From: Hiroki Sato In-Reply-To: <4516f415-939e-6374-45ce-df19a2ac65cb@marples.name> References: <20220807.232337.383956020917382126.hrs@FreeBSD.org> <4516f415-939e-6374-45ce-df19a2ac65cb@marples.name> X-Old-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-PGPkey-fingerprint: 6C0D 2353 27CF 80C7 901E FDD2 DBB0 7DC6 6F1F 737F X-Mailer: Mew version 6.8 on Emacs 27.2 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: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="--Security_Multipart(Tue_Aug__9_05_40_39_2022_635)--" Content-Transfer-Encoding: 7bit ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659991481; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gzgiY/iC9ZNeDF5HdzqmjUL4ocYOeYYDYbSUX5ZTQWA=; b=Fp/O0SpF+u4jE/IcdaZL3X9lt9MZXqjzdmpN7zCBTy4vtI9bCfAJVPac4iNMODQPqDc0H7 8ZKv2IyHeNyxqH1XbOKGIV2FB4oDMLCLfBLJ2GfEp56t5TIAltj7LSFt8b0lJcBvWpNKW3 TPyc6kKm4sguI4+CDjeTDbLY1gQHx234BTdSXcTtJpWM1Yd1g9Ijp4TgALrRT4Mro3WWBu poMQCgkvpyKJuMjWjGv7X6S1BqMUxkYnVIs7rIIEMyYXHwhxhc+NayY0xNGpVmm94Hk81v Jj6hPDoMbVDHkGFR0UzjQXqk6W/vnbHuHC3OGbHHyjSKRUNtTiST1RNWvPsOYg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659991481; a=rsa-sha256; cv=none; b=MYcejB/2dFRhRCexZBHXREKQid4A0gzOD2Zzq5mVVXq+8dd3fCBGnsLz2sBBG0dRszc87D AP2kHNt50dSbCqi6fCPNg6fEhoUJexiUHgvQHulNG9srdyvceKgtcGEHeZFldsIAGqR6ev n4rxPeNuN5gC4uOffW0wlOMo5lskR790HAFDeVhk5lnbzseUIqx2NU3FHcIPSNHetZNKSA 7hQkZ+CHAYjZ+7V9pT0ckMYNL7UEyM1TCyEBg+Z5gWVErS9pDDNHp6m7jaCI7DT9myZqgE /x/4xFBjtVylvIkE2a8okDEj3gGUge2gnObajYTCb/h7QNjx/TZ9tFxfMUjedg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N ----Security_Multipart(Tue_Aug__9_05_40_39_2022_635)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Roy Marples wrote in <4516f415-939e-6374-45ce-df19a2ac65cb@marples.name>: 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 remains a ro> > consumer of RA messages, and the default value of the -O option 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 the ro> dhcpcd commandline or signals. 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 transition, but I still believe it should work for most DHCPv6-enabled networks. 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). The FreeBSD rtsold has supported them for >10 years. Resolvconf, one of your projects, was imported at the same time to solve the problem of multiple information source for /etc/resolv.conf. ro> Sure it works fine for the one interface wired system - which ro> admitedly is the most popular setup. But when more than one interface ro> comes into play or you have plugable interfaces it then becomes more ro> complicated and will consume more resources having many more daemon 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_IFACE ro> defined) to allow plugable interfaces just for this reason. 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: 1. Use dhcpcd or not as a replacement of dhclient and rtsold. This leads to a never-ending discussion. Some people like the existing ones because they have worked well and do not want to change. 2. Adopt a single process managing the multiple interfaces on the system or use per-interface processes. 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: - 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). - 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. - 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. 3. Add an implementation of the DHCPv6 client-side functionality or not. 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. 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 works well, but it has a lot of rough edges (and fixed locally by many people, as bz@ pointed out). 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. So we need a consensus about how to get started with the integration. An idea in my mind is: 1) import dhcpcd (or whatever supports per-interface mode), 2) add a per-interface helper script for it, and 3) set rtsold_enable="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. 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. 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. -- Hiroki ----Security_Multipart(Tue_Aug__9_05_40_39_2022_635)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iMkEABMKAC4WIQRsDSNTJ8+Ax5Ae/dLbsH3Gbx9zfwUCYvF0xxAcaHJzQGZyZWVi c2Qub3JnAAoJENuwfcZvH3N/yiACCQElD9U6RqczmuC20r4VA4sCGFhxibnQH6IB 4GC9/j1RPgjGewnNJy2CvZbFz6SzBlme9I2+Jg3A8re6/rI5coueOgIIh5BErLlX NmRjFjX8Lm03ggQlSmPnQ9Cs3sxnHwyQeFQhy4F58IydBLbxLy2JwpO7L65sOe9y E8y6p4yj65V3lfA= =hlur -----END PGP SIGNATURE----- ----Security_Multipart(Tue_Aug__9_05_40_39_2022_635)----