From nobody Mon Aug 8 17:48:07 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 4M1kFR2sDxz4Ydft for ; Mon, 8 Aug 2022 17:48:11 +0000 (UTC) (envelope-from driesm.michiels@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4M1kFQ3TvVz3T5B; Mon, 8 Aug 2022 17:48:10 +0000 (UTC) (envelope-from driesm.michiels@gmail.com) Received: by mail-ed1-x529.google.com with SMTP id a89so12287879edf.5; Mon, 08 Aug 2022 10:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:from:to:cc; bh=6h5lgPyOI2xQ9O+BLm7nNjrMQA0LEGWg9uSGE0eC5QE=; b=T74sKY8gVhhPtUok25Frg7Ndq/SS+EW7biG2SdELaBhyPQF7sDpiCUvaWfSBhphGNa L/LB3/IKNYBYrfc0o/7JPIg1gd2NrcRVIlACaExyQwn+mIcBdo5+t160poc2aIpDXinH I8NmMMnhvj4qonSq22CiZQixcsczZspwmre2zHVtXOv1UVTXrZiY1zyg1lsmGG8TP80k yJ/+w8mRbsFeSUS9SjhteqKGluEhxiQruvXSvJsgljPge9YYsAsrXnuEpLY7nrt8v+LP nYxzFuPcjPa0nngcnukJ6r1DmtzUxyjmDqD2aTyJv4j/6dLaPAOhcgPI6/MltNBt3N0p g5Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:cc:to :from:x-gm-message-state:from:to:cc; bh=6h5lgPyOI2xQ9O+BLm7nNjrMQA0LEGWg9uSGE0eC5QE=; b=2ynsclAUs3BlT7rDgMp40jFY12WqSW6wCxE6xeYRvoo5F4aPrQYQI61lIKOFYO+az7 MuFa9a/DQgzFgEvy+YHUVm+xcb0ctWhK8hwjpdG2nQYRXzerV25Fos4KNC1rakoYrZSI e+JHJZqnJX27RgT7FemqILLnPWqnr4C8O+soK55vdd2E3C4xhDC4kSb9/B3lAGVkEKB9 0tfT2N6wfuIhcpKaeGSJWpthJxQQzN3j+n37g+lKfHfJIpbiJzKAznYdcHd2nAcxhlGA F4AVkR8LWRDcbuAusIiPcjN6Qzp+35QEzeIcd3YrxK+wIpTVlMSKQ2dKDXBXodB+JtrP eXKQ== X-Gm-Message-State: ACgBeo1Z+M/ERf32rmtTbAxKxmg3nkcaUIcZ7l5JH7JkEDc4napO1w5f ABsHznJDtpoaEg1QXqy3eXB7zIihEunAIw== X-Google-Smtp-Source: AA6agR6M/CXwxTl//HYJNH8xZsmsgqDS8SNQaVujvRocKWgjVxPRDzwNdTArHbNvzqiivzlNE+rTsg== X-Received: by 2002:a05:6402:400b:b0:43d:b0a1:dee with SMTP id d11-20020a056402400b00b0043db0a10deemr18552746eda.223.1659980888872; Mon, 08 Aug 2022 10:48:08 -0700 (PDT) Received: from DRIESPC (ptr-8slu6ianpkbg3jalamm.18120a2.ip6.access.telenet.be. [2a02:1811:251a:d241:8148:a20f:3395:cf0e]) by smtp.gmail.com with ESMTPSA id f3-20020a17090631c300b007308812ce89sm92452ejf.168.2022.08.08.10.48.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Aug 2022 10:48:08 -0700 (PDT) From: To: "'Bjoern A. Zeeb'" , "'Roy Marples'" Cc: References: <20220807.232337.383956020917382126.hrs@FreeBSD.org> <64e22fba-3f34-a419-2e51-7dfa21199919@marples.name> In-Reply-To: Subject: RE: Import dhcpcd(8) into FreeBSD base Date: Mon, 8 Aug 2022 19:48:07 +0200 Message-ID: <004a01d8ab4f$04e12660$0ea37320$@gmail.com> 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: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIu8IMSSdiQqb1TovL1mBi5IZwMiQHmvAUkALViFWgB5NMcpazUtW0Q Content-Language: en-be X-Rspamd-Queue-Id: 4M1kFQ3TvVz3T5B X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=T74sKY8g; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of driesm.michiels@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=driesm.michiels@gmail.com X-Spamd-Result: default: False [-2.96 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.98)[-0.981]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.02)[0.021]; RCPT_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; ARC_NA(0.00)[]; FROM_NO_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from]; RCVD_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; TAGGED_FROM(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org] X-ThisMailContainsUnwantedMimeParts: N > -----Original Message----- > From: owner-freebsd-net@freebsd.org On > Behalf Of Bjoern A. Zeeb > Sent: Monday, 8 August 2022 18:43 > To: Roy Marples > Cc: freebsd-net@freebsd.org > Subject: Re: Import dhcpcd(8) into FreeBSD base > > On Mon, 8 Aug 2022, Roy Marples wrote: > > > 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. > > Yeah I think we had that for over a decade... (as it has been pointed out before > in older threads as well) > > commit db82af41db538fba5938d8585b2e2e2c206affb6 > Author: Hiroki Sato > AuthorDate: Mon Jun 6 03:06:43 2011 +0000 > Commit: Hiroki Sato > CommitDate: Mon Jun 6 03:06:43 2011 +0000 > > - Implement RDNSS and DNSSL options (RFC 6106, IPv6 Router > Advertisement > Options for DNS Configuration) into rtadvd(8) and rtsold(8). DNS > information received by rtsold(8) will go to resolv.conf(5) by > resolvconf(8) script. This is based on work by J.R. Oldroyd (kern/156259) > but revised extensively[1]. > > ... > > > > >> 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. > > *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. > > > I can tell on another note as it came up in this thread: > (a) wide-dhcpv6 is "maintained" by a lot of people (companies, Linux distros, ..) > and if the right people would have opened a new repo and collected (and > maintained) > bits (a few years ago) we'd likely not have this discussion but the problem > would be long solved for FreeBSD. > (b) I have trees with wide-dhcpv6 imported into base privately and know how > that > works as a default (I also know what doesn't work well but that's not specific > to the DHCPv6 client implementation) > (c) Like many I have patches to aid functionality and fix things (kind-of waiting > for (a) to happen to ridden my tree of them). I have so far resisted to make > FreeBSD that repo though I probably should have years ago. > > > >> 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. > > And the same goes for rtsol(d). > > > >> 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. > > I think that is a very sensible approach to do it incrementally. > > If people can agree on > (1) importing it and first closing the gap of the missing DHCPv6 client making > sure it does all people have accumultaed over the years, > (2) and then solving the "how do I disable dhclient and rtsold and per-IF configs > and just run the-one-thing as an alternative in rc" in the 2nd step This is a sensible approach, importing and taking things step by step will aid in moving things forward. I do think that when dhcpcd is imported it should be built by default (but not do anything out of the box, unless explicitly enabled) Compiling it by default, instead of defining a WITH_DHCPCD, would result in less resistance to try it out on RELEASES, even in CURRENT and STABLE. dhcpcd has since gained capsicum and full privilege separation support, I don't think there are any large concerns left to not include it by default. > I would think that will (a) reduce resistance and (b) give more time to test and > try for people, especially in 14 but it would (c) also be backward cmpatible with > 13 and thus smoothen (and possibly accelerate) any possible transition and > could possibly be MFCed even to provide (integrated) DHCPv6 there as well. > > And I am not saying that (2) couldn't follow within days or weeks of (1). I am > just saying that I'd prefer it to be seen as a distinct problem. > > Then the next questions would be if or when to flip the default and as indecated > before and above if/when to remove the current state of art but if we take a > step at a time we'll probably save ourselves a lot of discussion and can move > forward? > > My 0.001ct > /bz > > -- > Bjoern A. Zeeb r15:7