From nobody Mon Aug 8 11:16:32 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 4M1YYd6W1Lz4Ysdk for ; Mon, 8 Aug 2022 11:16:37 +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 4M1YYd0mVPz3cjT for ; Mon, 8 Aug 2022 11:16:37 +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:References:Cc:Subject:From:MIME-Version:Date:Message-ID:Sender: Reply-To: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=f2Cws/vzjLER4i4QqtmE2zs4ifK+q/z+Rii1njXQhyU=; b=eeAXz50tE0KhZvIQvyBxQlySJj bQmTxQaJynY8rCAhhxTLxM+lr9YzAhQyVh7mdpDhOzr85b6LJl1JSR3uba42bw3vAx1E8nLMFUo96 pXKKjaXIshTVGJ+i44Pa9fQbJd0TfISpMs60+4b/vnDQxN5zP70ecez9tX/+CGxs7+/H0+wre5LLY H5rE+d85kQilAK45IMnZxL0FyAmoTjxkVHjEhLkrDQhfn5nGQ1ePZS9s/KfK4j3NUO9yvFm41EhH3 ytPLPD3oBqksy7uN7YkBum91U+Bnu/09LKOJrX22482GgcBWGBYZJWTaVB189xka6hy6zDo6EkONT t8Bvg3sQ==; Received: from cpc115020-bour7-2-0-cust1507.15-1.cable.virginm.net ([82.3.253.228]:1029 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 1oL0kJ-007W1m-Ep for freebsd-net@freebsd.org; Mon, 08 Aug 2022 07:16:36 -0400 Message-ID: <64e22fba-3f34-a419-2e51-7dfa21199919@marples.name> Date: Mon, 8 Aug 2022 12:16:32 +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 From: Roy Marples Subject: Re: Import dhcpcd(8) into FreeBSD base Cc: freebsd-net@freebsd.org References: <20220807.232337.383956020917382126.hrs@FreeBSD.org> In-Reply-To: <20220807.232337.383956020917382126.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: 4M1YYd0mVPz3cjT X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=marples.name header.s=default header.b=eeAXz50t; 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 [-1.80 / 15.00]; MISSING_TO(2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW_WITH_FAILURES(-0.50)[]; R_DKIM_ALLOW(-0.20)[marples.name:s=default]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; HAS_X_GMSV(0.00)[roy@marples.name]; HAS_X_AS(0.00)[roy@marples.name]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:22612, ipnet:198.54.115.0/24, country:US]; R_SPF_SOFTFAIL(0.00)[~all:c]; TO_DN_NONE(0.00)[]; HAS_X_SOURCE(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; DKIM_TRACE(0.00)[marples.name:+]; HAS_X_ANTIABUSE(0.00)[]; DMARC_POLICY_ALLOW(0.00)[marples.name,quarantine]; MIME_TRACE(0.00)[0:+]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On 07/08/2022 15:23, Hiroki Sato wrote: > 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. I don't think this is a viable option as there is no easy way to transition from Other to Managed (or the other way around) from the dhcpcd commandline or signals. Also, please consider than dhcpcd supports DNSSL and RDNSS options from RA messages whereas FreeBSD rtsold/kernel RA do not (please correct me if I'm wrong). This allows for a fully working IPv6 only setup without DHCPv6. > > 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. I would argue that having knobs to control dhcpcd (or any other similar network tool for that matter) in rc.conf per interface is a bad idea because this discourages running dhcpcd in manager mode. You even note this below, but here are some more comments. Sure it works fine for the one interface wired system - which admitedly is the most popular setup. But when more than one interface comes into play or you have plugable interfaces it then becomes more complicated and will consume more resources having many more daemon runing to allow capsicum and makes dhcpcd just as predictable as dhclient on a multi-homed system (ie it's not predictable). I modified wpa_supplicant upstream to support the -M directive (I don't know if FreeBSD compiles wpa_supplicant with CONFIG_MATCH_IFACE defined) to allow plugable interfaces just for this reason. I suggest just running dhcpcd as you would any other service in rc.conf > 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. We can leave current dhclient/rtsold configuration intact and suggest people move to dhcpcd by themselves. People that want DHCPv6 or a better DHCP or RA expierience already have some solution in place which might even be dhcpcd from ports. I don't see any reason to stamp on their toes. If FreeBSD does import dhcpcd, then I would suggest any talk of removal of dhclient can happen after a version of two. > > 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. > > 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. Agreed. I noted my concerns above and would favour a full blown dhcpcd configuration for new installs and leave the current dhclient/rtsold for exising installs. No need to force people to move. Roy