From nobody Tue Aug 9 08:46:36 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 4M26BG4v34z4Y6b6 for ; Tue, 9 Aug 2022 08:46:46 +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 4M26BF5HyBz3MNG; Tue, 9 Aug 2022 08:46:45 +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=ypDsR2+83iUKyVKXuaNorVBFx+fCis3GjGT4IGEtl5o=; b=I06QJn2K16VJcxEDTT5vD8AcUt 2zdBQJEPwU9uLmyVNqT15IzDwgOjoyIxSgUKEMKme8smB/MGoqx5SzuvE5edIZDs2cqCfFwBe1ncO S3Xaq/sQlZ3Ecvnmo/k/R9GWQraOyun5gTV9dUmIwSpNVLEwat9kQ3KeNe3EXGEK5X1zdGPXQchLB ap5Z7vU4bGQEAR7fKmcSB8aZfdXdEU12wNqssmKFW7NYdpKhFy/N3OXnGahKGYvT+tn5Jm+uedBA+ 6m6WaJi24ufiior0yc3iyUu7fah8gySOrst1pCjMNU3PSav/13/qSLlFTPWW4ys8AYUK+cvHc5iOA icW4Y4zQ==; Received: from cpc115020-bour7-2-0-cust1507.15-1.cable.virginm.net ([82.3.253.228]:50160 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 1oLKsp-00FsvH-Cy; Tue, 09 Aug 2022 04:46:44 -0400 Message-ID: <42806dc8-e030-b4fb-73f2-f978ae8cd21c@marples.name> Date: Tue, 9 Aug 2022 09:46:36 +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: "Bjoern A. Zeeb" Cc: freebsd-net@freebsd.org References: <20220807.232337.383956020917382126.hrs@FreeBSD.org> <64e22fba-3f34-a419-2e51-7dfa21199919@marples.name> From: Roy Marples In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: 4M26BF5HyBz3MNG X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=marples.name header.s=default header.b=I06QJn2K; 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 17:43, Bjoern A. Zeeb wrote: >>>   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. > > FreeBSD since we last time changed dhclient have had a very liberal way of > allowing users to choose while still providing a default.  These things never > go without hiccups. > > I believe what some of us actually have a problem with is (a) the actual > way this is integrated into the rc framework and (b) to some extend that > the original proposal indicates to possibly remove the current defaults > (soon).  We've lived with these things for 2 decades and throwing everything > out over night and replacing it doesn't work for (some of) us. > > I see some benefits of it but I also see a lot of drawback in the > one-thing-fits-all approach.  It's not the UNIX philosophy. So you're arguing that ifconfig(8) does not follow UNIX philosohy? The scope of dhcpcd is automated network configuration. The scope if ifconfig is manual (or static) link setup AND network configuration. dhcpcd handles DHCP and DHCPv6 (also handles ND/RA). ifconfig handles INET and INET6 (also handles link creation and such as bridge). I think that dhcpcd does follow the UNIX philosophy of having a best in class tool to do a specific job. But this is course is a matter of personal opinion where there is no good answer. See FreeBSD's ping6(8) BUGS for mor debate about this. dhcpcd's rationale is that DHCP and DHCPv6 actually share quite a chunk of common code. > > *Personally* for a decade++ I've been running IPv6-only systems, I have a branch > somewhere where I started to work through the entire base system to make things > compile if they lack IPv4 header(s) or bits thereof.  I *personally* see very > little gain from importing new IPv4 code which replaces something which worked > well for a looong time providing close to no new benefits (and I emphasize the > personally as I do understand and accept that IPv4 is very important thing to > a lot of people and business still and that it needs to be maintained and > supported for those in need). > > At the same time I agree that integration on the IPv6 side of FreeBSD lacks > behind and I do see the advantages of an intertwined RS/RA/DHCPv6 solution > though for a lot of situations the split solution will be "just fine" as the > real challanges come with the integration of other services or other missing > bits we simply haven't done. > > I was hoping this proposal would help solve two problems not just replacing > X and Y for Z. It is possible compile dhcpcd for INET6 and DHCPv6 only. You can even go the other way and do DHCP only. There are a few other compile knobs to save on size so dhcpcd can fit on boot floppies. Roy