From nobody Mon Aug 08 22:21:35 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 4M1rK74bl8z4YLpP for ; Mon, 8 Aug 2022 22:21:47 +0000 (UTC) (envelope-from roy@marples.name) Received: from server111-2.web-hosting.com (server111-2.web-hosting.com [198.54.115.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4M1rK645Psz46Y4; Mon, 8 Aug 2022 22:21:46 +0000 (UTC) (envelope-from roy@marples.name) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=marples.name; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:From:References:Cc:To:Subject:MIME-Version:Date:Message-ID:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ta1L4AGFFKQJ8abKIDc4SVn1d+9j1wrpgkAg38w6Yys=; b=UHsK6u+XNjMXLnpYFP/qJFi/lC BcNNWK+yU7L4NEz43BNX5+ZU8KpWx4hFx19sGbYwZtmHXcH1zH4pBDtYGV19Eb/RqBaF2ZL8Kw55J 0ohz7FXPzriaTgNNIOBHivlvepQ2s2+UehpHhsSh49X2RlQV1MrfzrajBFwRjVIY53MMHzstPdk4g XzN0J1B4/DFWc1UDrqRnyaqcg82zWzT31Fbv7XeEJ2rfPmzR0qeWsk1EpIc5FKSARRYZpwbCHqc5e 8fbDhEcgWJUoTjTk96a9P3nCQh4Vx5KsNcGTQD50t451rr077oZhReiXztMad6rKx78ahSpGj9D5P jik5ybhQ==; Received: from cpc115020-bour7-2-0-cust1507.15-1.cable.virginm.net ([82.3.253.228]:13452 helo=[192.168.1.13]) by server111.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.95) (envelope-from ) id 1oLB80-0031aP-9K; Mon, 08 Aug 2022 18:21:45 -0400 Message-ID: <74a1d9c2-6eab-b685-e71e-7d69a6fe6a9f@marples.name> Date: Mon, 8 Aug 2022 23:21:35 +0100 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 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.12.0 Subject: Re: Import dhcpcd(8) into FreeBSD base To: Hiroki Sato Cc: freebsd-net@freebsd.org References: <20220807.232337.383956020917382126.hrs@FreeBSD.org> <4516f415-939e-6374-45ce-df19a2ac65cb@marples.name> <20220809.054039.722614217650843004.hrs@FreeBSD.org> From: Roy Marples In-Reply-To: <20220809.054039.722614217650843004.hrs@FreeBSD.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server111.web-hosting.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - marples.name X-Get-Message-Sender-Via: server111.web-hosting.com: authenticated_id: roy@marples.name X-Authenticated-Sender: server111.web-hosting.com: roy@marples.name X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Rspamd-Queue-Id: 4M1rK645Psz46Y4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=marples.name header.s=default header.b=UHsK6u+X; dmarc=pass (policy=quarantine) header.from=marples.name; spf=softfail (mx1.freebsd.org: 198.54.115.96 is neither permitted nor denied by domain of roy@marples.name) smtp.mailfrom=roy@marples.name X-Spamd-Result: default: False [-3.80 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; R_DKIM_ALLOW(-0.20)[marples.name:s=default]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; HAS_X_AS(0.00)[roy@marples.name]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; HAS_X_GMSV(0.00)[roy@marples.name]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:22612, ipnet:198.54.115.0/24, country:US]; MIME_TRACE(0.00)[0:+]; R_SPF_SOFTFAIL(0.00)[~all]; HAS_X_SOURCE(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[marples.name:+]; DMARC_POLICY_ALLOW(0.00)[marples.name,quarantine]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; HAS_X_ANTIABUSE(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 08/08/2022 21:40, Hiroki Sato wrote: > 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. I agree with all of this. I would only ask that there is the ability to just enable dhcpcd as a generic service in rc.conf as dhcpcd_enabled=YES so that people can play with it as intended and not affect any existing configuration. Roy