From nobody Mon Aug 8 22:27:14 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 4M1rRg5sm6z4YM6T for ; Mon, 8 Aug 2022 22:27:27 +0000 (UTC) (envelope-from ggm@algebras.org) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 4M1rRg1NBMz487s for ; Mon, 8 Aug 2022 22:27:26 +0000 (UTC) (envelope-from ggm@algebras.org) Received: by mail-yb1-xb2b.google.com with SMTP id y127so15783353yby.8 for ; Mon, 08 Aug 2022 15:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=grH6wamAoE7IhhvhWQdO3aSMP2ai/+9fB/3u4+VGhDE=; b=XntJWOS0TGT/xwmAte2GGCiYCdJOvs6zRI99bQ0J9Zp8EHO24sqCrMWXunn4sZ4eDp ukop06STBpSz2J/j4YoE0Lhr3Ul4wbu3iADo8LmtMhUscr3YuWmJ6E3m0xxg6nxo0PPB GsoeV31aPzuGllpMFK2JQXSbpjcpUjAoJKhDQhDE8jmdGkAR0auTcwJfxsNOCmZ42Yfk TRsCQq2E+9YEW3NGb3qgXIGwO6NNxA8dMETQtpk9pDJJPwxx58BIZ/b1zgYeI9+yM137 6zYH/yLV5I3KagXLOoN9egJmsCddgy/bIOzYj0TM8FRBtkneDkiL5srMvRpLyK+RWQYU n9tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=grH6wamAoE7IhhvhWQdO3aSMP2ai/+9fB/3u4+VGhDE=; b=7CN2kaNAt70nWGsOI4DIoF00/Yuc7+JYvPM2/+Lba7eAWDDCtC0BDIZ03/qa34IZF9 q5e0Zln/VdH4/2YSghaV8X2QHNFRy8UUHzX3gA7QwB2/IG0mWt5kz4nJqpQ16CO9/6I6 OPftQEfNwKa7deLqSuQKsOccmLCsM5NbTsqmOsVmBpgXGLMdSjoum7HwRVd9M5h6xszr A9E92t566jB0X11pTMnjoCx1DHCSESZQmmBDdzcXM+4ruKjotx2bAI9WN3joVDOJDeys 2bpbFJRcf3n2VC5LWxUZbDPfrhlWaNfXuCPW7bmqV8RC17nHkJL13oX0iOJwRde0Lani JWbQ== X-Gm-Message-State: ACgBeo1Z9rN3CSSpwnD3Vk6KMc0gdY8cQMZj0FAMbF4zCj76/ww6Vr/y AciyBowXBmH/9c07l+p6hvf4y26uGofdzZcXzesNuw== X-Google-Smtp-Source: AA6agR4L/2JAaP4Yd3XF5YywUyB6pVbSGp8S2OINzzoybUcTzHui6lJV0ptWa2ydJALc9WuK1Ex5hh2PoOJhr0Jffvg= X-Received: by 2002:a25:bb86:0:b0:670:ef2:7f9a with SMTP id y6-20020a25bb86000000b006700ef27f9amr18450418ybg.318.1659997645309; Mon, 08 Aug 2022 15:27:25 -0700 (PDT) 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 References: <20220807.232337.383956020917382126.hrs@FreeBSD.org> <4516f415-939e-6374-45ce-df19a2ac65cb@marples.name> <20220809.054039.722614217650843004.hrs@FreeBSD.org> <74a1d9c2-6eab-b685-e71e-7d69a6fe6a9f@marples.name> In-Reply-To: <74a1d9c2-6eab-b685-e71e-7d69a6fe6a9f@marples.name> From: George Michaelson Date: Tue, 9 Aug 2022 08:27:14 +1000 Message-ID: Subject: Re: Import dhcpcd(8) into FreeBSD base To: Roy Marples Cc: Hiroki Sato , freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4M1rRg1NBMz487s X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=algebras-org.20210112.gappssmtp.com header.s=20210112 header.b=XntJWOS0; dmarc=none; spf=pass (mx1.freebsd.org: domain of ggm@algebras.org designates 2607:f8b0:4864:20::b2b as permitted sender) smtp.mailfrom=ggm@algebras.org X-Spamd-Result: default: False [-3.50 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[algebras-org.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[text/plain]; MLMMJ_DEST(0.00)[freebsd-net@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2b:from]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; DKIM_TRACE(0.00)[algebras-org.20210112.gappssmtp.com:+]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCPT_COUNT_THREE(0.00)[3]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[algebras.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-net@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N Yes. and I was trying to say, the rc.d system should alllow this to say "It wont work, you had rtsold_enabled=YES set" because these have to be either/or in my understanding of things. You can't both do SLAAC and DHCPv6. Its either/or. On Tue, Aug 9, 2022 at 8:22 AM Roy Marples wrote: > > On 08/08/2022 21:40, Hiroki Sato wrote: > > Roy Marples wrote > > in <4516f415-939e-6374-45ce-df19a2ac65cb@marples.name>: > > > > ro> On 07/08/2022 15:23, Hiroki Sato wrote: > > ro> > 1) Import dhcpcd and make it invoked via Other Configuration flag > > ro> > in RA for DHCPv6. This means that the rtsold daemon remains a > > ro> > consumer of RA messages, and the default value of the -O option is > > ro> > set to run dhcpcd. > > ro> > > ro> I don't think this is a viable option as there is no easy way to > > ro> transition from Other to Managed (or the other way around) from the > > ro> dhcpcd commandline or signals. > > > > The rtsold daemon just invokes a corresponding helper script when > > receiving RAs with these flags. A transition from O to M or vice > > versa is supposed to be handled by them. I think it is possible to > > stop the running dhcpcd and/or restart it with another configuration > > via the scripts. Is there a critical problem with it? I do not > > insist that it is the best way since it is not a graceful transition, > > but I still believe it should work for most DHCPv6-enabled networks. > > > > ro> Also, please consider than dhcpcd supports DNSSL and RDNSS options > > ro> from RA messages whereas FreeBSD rtsold/kernel RA do not (please > > ro> correct me if I'm wrong). > > > > The FreeBSD rtsold has supported them for >10 years. Resolvconf, one > > of your projects, was imported at the same time to solve the problem > > of multiple information source for /etc/resolv.conf. > > > > ro> Sure it works fine for the one interface wired system - which > > ro> admitedly is the most popular setup. But when more than one interface > > ro> comes into play or you have plugable interfaces it then becomes more > > ro> complicated and will consume more resources having many more daemon > > ro> runing to allow capsicum and makes dhcpcd just as predictable as > > ro> dhclient on a multi-homed system (ie it's not predictable). > > ro> > > ro> I modified wpa_supplicant upstream to support the -M directive (I > > ro> don't know if FreeBSD compiles wpa_supplicant with CONFIG_MATCH_IFACE > > ro> defined) to allow plugable interfaces just for this reason. > > > > I agree that running processes for each interface independently is > > sub-optimal. However, I think it is a separate topic from whether > > importing a DHCPv6 client into the base system or not. More > > specifically, the following three are orthogonal: > > > > 1. Use dhcpcd or not as a replacement of dhclient and rtsold. > > > > This leads to a never-ending discussion. Some people like the > > existing ones because they have worked well and do not want to > > change. > > > > 2. Adopt a single process managing the multiple interfaces on the > > system or use per-interface processes. > > > > Changing this requires a lot of work and breaks the existing > > configurations. A side node of the design and behavior of the > > current rc.d/netif is as follows: > > > > - The current rc.d/netif (and other network-related rc.d scripts > > such as rc.d/wpa_supplicant) are based on the per-interface > > model. The rc.d/netif script is invoked asynchronously while it > > also runs at boot time sequentially. This asynchronous > > invocation is specific to FreeBSD, and not seen in other BSDs > > (correct me if I am wrong). > > > > - The devd(8) daemon is the main process receiving events of the > > interfaces such as arrival/departure/link-state changes, and > > invokes a process upon an event if necessary. > > > > - The rtsold(8) daemon is the main process receiving RAs in > > userland and invokes a process upon an event if necessary. > > Currently, it handles O/M flags and RDNSS/DNSSL options. > > > > 3. Add an implementation of the DHCPv6 client-side functionality or > > not. > > > > I believe no one objects for adding one because we have no > > implementation in the base system. Some people like another one, > > such as ISC dhclient or WIDE dhcp6. > > > > My opinion is: 1) "no need", 2) "keep the current model for a while", > > and 3) "go for it". I tend to prefer WIDE dhcp6 because I have used > > it for >15 years with accumulated local patchset, but I do not stick > > to it as long as there is a good working implementation supporting > > IA_NA and IA_PD, and someone actively maintains it. WIDE dhcp6 works > > well, but it has a lot of rough edges (and fixed locally by many > > people, as bz@ pointed out). > > > > As mentioned in my previous email, avoiding POLA violations is the top > > priority. Regardless of which implementation we import, I still > > believe keeping the current per-interface model is the least > > intrusive for the existing configurations. > > > > So we need a consensus about how to get started with the integration. > > An idea in my mind is: 1) import dhcpcd (or whatever supports > > per-interface mode), 2) add a per-interface helper script for it, and > > 3) set rtsold_enable="YES" effectively by default for all > > RA-accepting interfaces so that people do not need to manually > > configure it at least on an IPv6 network with M/O bit enabled. This > > should be enough for IA_NA. More complicated configurations can be > > supported incrementally. > > > > And I hope this discussion focuses on how to integrate DHCPv6 > > functionality, not changing the current rc.d/netif drastically or > > replacing the existing components unrelated to DHCPv6 such as > > dhclient or rtsold. If the import involves an immediate change of > > the current model due to the nature of the implementation, I cannot > > entirely agree with it. > > > > Technical discussions about improving the current model are always > > welcome. I am also interested in them because I have recognized the > > downsides since I am one of the contributors who have added > > substantial changes to network.subr over the years. However, > > thinking about the import and the improvement of boot-time > > configuration together does not make good sense to me to judge the > > reasonableness of the import. > > I agree with all of this. > > I would only ask that there is the ability to just enable dhcpcd as a generic > service in rc.conf as dhcpcd_enabled=YES so that people can play with it as > intended and not affect any existing configuration. > > Roy >