Date: Wed, 16 Oct 2019 09:23:45 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: "Ben Woods" <woodsb02@gmail.com> Cc: freebsd-net@freebsd.org, hrs@freebsd.org, roy@marples.name Subject: Re: DHCPv6 client in base Message-ID: <8016D7B2-5201-4D95-B61F-C949289BDAE6@lists.zabbadoz.net> In-Reply-To: <CAOc73CCNVdRjPf1EDfu9jhmvy20_E7FsA42QuMQNNAxCehDW5Q@mail.gmail.com> References: <001e01d50b49$176104d0$46230e70$@gmail.com> <20190516.032012.517661495892269813.hrs@allbsd.org> <CAOc73CCLPmB7m3yaDE7p4izJ8apaO5jcyRPyLkSJtopqsHxtSQ@mail.gmail.com> <20191012.044034.19725945241254130.hrs@allbsd.org> <CAOc73CCNVdRjPf1EDfu9jhmvy20_E7FsA42QuMQNNAxCehDW5Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8016D7B2-5201-4D95-B61F-C949289BDAE6>