From owner-freebsd-net@freebsd.org Wed Oct 16 09:23:53 2019 Return-Path: Delivered-To: freebsd-net@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 395E516046A for ; Wed, 16 Oct 2019 09:23:53 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) 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)) by mx1.freebsd.org (Postfix) with ESMTPS id 46tRgX13YJz4VZQ; Wed, 16 Oct 2019 09:23:51 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) 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 59C9D8D4A218; Wed, 16 Oct 2019 09:23:49 +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 CA725E707D3; Wed, 16 Oct 2019 09:23:48 +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 7FtmqMnsph8M; Wed, 16 Oct 2019 09:23:46 +0000 (UTC) Received: from [192.168.2.110] (unknown [IPv6:fde9:577b:c1a9:31:284a:89d7:f546:4d57]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 6F9AEE707CA; Wed, 16 Oct 2019 09:23:46 +0000 (UTC) From: "Bjoern A. Zeeb" To: "Ben Woods" Cc: freebsd-net@freebsd.org, hrs@freebsd.org, roy@marples.name Subject: Re: DHCPv6 client in base Date: Wed, 16 Oct 2019 09:23:45 +0000 X-Mailer: MailMate (2.0BETAr6142) Message-ID: <8016D7B2-5201-4D95-B61F-C949289BDAE6@lists.zabbadoz.net> In-Reply-To: References: <001e01d50b49$176104d0$46230e70$@gmail.com> <20190516.032012.517661495892269813.hrs@allbsd.org> <20191012.044034.19725945241254130.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 46tRgX13YJz4VZQ X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of bzeeb-lists@lists.zabbadoz.net designates 195.201.62.131 as permitted sender) smtp.mailfrom=bzeeb-lists@lists.zabbadoz.net X-Spamd-Result: default: False [-5.14 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:195.201.62.131]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[zabbadoz.net]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; IP_SCORE(-2.84)[ip: (-8.83), ipnet: 195.201.0.0/16(-3.56), asn: 24940(-1.81), country: DE(-0.01)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:195.201.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 09:23:53 -0000 On 14 Oct 2019, at 23:04, Ben Woods wrote: > Whilst I don’t have anything against wide-dhcp, I personally prefer > integrated IPv4/IPv6 tools. ping vs ping6 for example would be better > integrated in my opinion. I have a totally different opinion on this. I prefer to have a tool that does one job. K.I.S.S. In addition I consider IPv4 dead. Let it die. Stop thinking IPv4. Don’t screw the users over on the way out of the protocol by making changes to how things worked for a decade or two or three in the last minute. Never change a running system. If you want to touch IPv4 along, I am out on the IPv6 change. Further I really, very soon, want to get rid of more IPv4 code for a lot of systems I am building as less code less attack surface. We started compiling INET out in 2011 in addition to INET6. I have a way more eager hobby project at the moment which does remove IPv4 entirely from the tree. I do that by splattering more #ifdef code around all IPv4 code I can find and then remove it. (two step needed to be able to merge-track FreeBSD still). I can tell you even just doing that for libc is a pain. If it takes us another 6-8 years until the rest of the world gets there, I’ll be happy (very much like it took the world to get to the IPv6-only discussions we have everywhere actively these days). > The “feature” that I believe is missing from wide-dhcp is active > maintenance. I am not sure but I’d assume that’s a lot also to the fact of its current state as to where it is living. If it were in head with a bit of infrastructure and not as a “import from upstream” project I think some people might “commit to it” a lot more. > I do agree that we should minimise excess code in FreeBSD also, but I > believe that once dhcpcd has been proven to work, we could look at > removing > dhclient and rtsold. Agree with your comment that before this occurs, > we > should check what features / security improvements / tighter > integration > have been added along the way, and ensure they make their way into > dhcpcd. > > If dhcpcd was imported, I believe this would come with a phased > approach: > - import dhcpcd, but leave dhclient and rtsold as default - Make sure all the security concerns are rooted out. - Update documentation, handbook, samples, .. and educate our users. > - add kernel support for tighter dhcpcd integration > - switch defaults to dhcpcd, but leave dhclient and rtsold as > available > - remove dhclient and rtsold If you really want a proper smooth transition you probably need at least one major release overlap and that’s half a decade of maintaining two software sets. /bz