From nobody Mon Aug 8 16:43:17 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 4M1hpk6K70z4YTxn for ; Mon, 8 Aug 2022 16:43:26 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 4M1hpk5mcSz3L4d; Mon, 8 Aug 2022 16:43:26 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659977006; 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: in-reply-to:in-reply-to:references:references; bh=nsDI9edBehYOIHVhvxJR+2O22wO/hmr0VuhhjmDL4i0=; b=nOmw/z0l7/4JfyzpKrzdNd9tQIHKvvHHE7Eldpf/LoBlIxyGqvEWnsy4rxM7vWCki79V6R JGxz0Kqhw0rjqcHCv9SwZDDHVmPvAcZ6n+6sisALOmK0FTfrnam9hoptTy4nabuWKxdOP8 V/TKFXuHJmcprj2LZtmkDTMEBJhUtyFJZKceHhvfkK7bKGBtsTfE2WbFS9aLv15/pRn6Y2 JRL5b6HTRmXpPVwFJnbPRGjG1SlVvu44BiIwjHkMqDhLF/sxUUOpcMjPQ0qT4g3hwoX8WK F66EITTYaYrGCSwxxDfL2hIIAWsDgpGnPwG7qxuWrmAMdtiqAaJrf+7czx8s/Q== Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4M1hpk3Q3SzyN0; Mon, 8 Aug 2022 16:43:26 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D084E8D4A178; Mon, 8 Aug 2022 16:43:24 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C396EBD4CBD; Mon, 8 Aug 2022 16:43:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id dsGh3W7CNqCX; Mon, 8 Aug 2022 16:43:20 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0426ABD4C13; Mon, 8 Aug 2022 16:43:19 +0000 (UTC) Date: Mon, 8 Aug 2022 16:43:17 +0000 (UTC) From: "Bjoern A. Zeeb" To: Roy Marples cc: freebsd-net@freebsd.org Subject: Re: Import dhcpcd(8) into FreeBSD base In-Reply-To: <64e22fba-3f34-a419-2e51-7dfa21199919@marples.name> Message-ID: References: <20220807.232337.383956020917382126.hrs@FreeBSD.org> <64e22fba-3f34-a419-2e51-7dfa21199919@marples.name> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 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; format=flowed ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1659977006; 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: in-reply-to:in-reply-to:references:references; bh=nsDI9edBehYOIHVhvxJR+2O22wO/hmr0VuhhjmDL4i0=; b=AmZIOPyQZmhEXcgThNKvlrkGYRqa/CVHhsAhL+kp28pyNGUpoOUONA2KYFsOiwLVB255c0 I7ligS6tkUy5Oy3pebX1cKcAatRlGko5Xx8IBVH4s2Iv2xBoUs0BHjAoi/KO1L22gpy0iP 2FP72cqr5O1l6eR9Ur+kbc/eO/gZWlaOgWt1j/8KH3kbsOPfak9OS/wf+LVXjTVWtTK1iO tXbvUZWb2fWG1bfsSnBORDhlg+iUSW6EtDwW73o3nkNgaulPFuNVCKv6EaTY2UIZHLpxPl 13ELU2yOL+/85zMuUnzYdpq5pWkLB2Pl+X2Og/7hEWq+UIcQK7Nulm5oZ050hA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1659977006; a=rsa-sha256; cv=none; b=F5n+ntxnpwpGelMpEch606PaneG8fyPCPhyAWa9ryMxTTjMZx0lFkzGiUmjCvMyic1N09w HOv3iVjN0j08psQGiEQLt8FUHfQ9PPDO8DCk8CfQE/PirY4zba/6c/RwHPvlX5I/z5by+B zPWZ50MyjGvLfqDq7DymnwWTqtsN75uBlIKCkCX81AT2UAY3gCt0CcKpwkcU3fNdAA3TKd 3lI5oIgnjp7+MM9P2hYXbMkIT2roKuyRg/aGHdI0ASExFRU7V41SshD0/gV7M2I9l9RgHM xc7KuWSyoz6+UJxTEdj0uNX+rMBSsjbxRNkrVoLioy3Bo/BOJnXZzQiEyfKygg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N 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 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