From owner-freebsd-net@freebsd.org Sat Oct 12 02:06:44 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 0C11513EFE6 for ; Sat, 12 Oct 2019 02:06:44 +0000 (UTC) (envelope-from hrs@allbsd.org) Received: from mail.allbsd.org (mx.allbsd.org [IPv6:2001:2f0:104:e001::41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail.allbsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46qp8x44Ztz4LGG; Sat, 12 Oct 2019 02:06:40 +0000 (UTC) (envelope-from hrs@allbsd.org) Received: from mail-d.allbsd.org ([IPv6:2409:11:a740:4700:58:65ff:fe00:b0b]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id x9C26DeM064489 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=OK) (Client CN "/CN=mail-d.allbsd.org", Issuer "/C=US/O=Let's+20Encrypt/CN=Let's+20Encrypt+20Authority+20X3"); Sat, 12 Oct 2019 11:06:24 +0900 (JST) (envelope-from hrs@allbsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=allbsd.org; s=20190220; t=1570845994; bh=+Mp2yaVl9lp794JiKUuDoNBP+ZQUlAyKAFUN+Bmf2tE=; h=Date:To:Cc:From:In-Reply-To:References; b=baH5qGpxOypfo9VMgboEfw+djAYJ9xMbwFCEPamwAWiluwBuZzzSuGjxyTf8kI60O TVCbWGUyVFyVyinrSsZGv/ZEqyaR2mbU6fcmtg0rEnPvItRoYb+cGCKe05C54j18Ok YA/JzDccs9qXrm97uhRaI9dOD6k39aVYwuaeC95o= Received: from alph.d.allbsd.org ([IPv6:2409:11:a740:4700:16:ceff:fe34:2700]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id x9C2680r084622 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 12 Oct 2019 11:06:08 +0900 (JST) (envelope-from hrs@allbsd.org) Received: from localhost (localhost [[UNIX: localhost]]) (authenticated bits=0) by alph.d.allbsd.org (8.15.2/8.15.2) with ESMTPA id x9C265JV084618; Sat, 12 Oct 2019 11:06:07 +0900 (JST) (envelope-from hrs@allbsd.org) Date: Sat, 12 Oct 2019 11:04:55 +0900 (JST) Message-Id: <20191012.110455.1650077722278454495.hrs@allbsd.org> To: roy@marples.name Cc: woodsb02@gmail.com, hrs@freebsd.org, freebsd-net@freebsd.org, driesm.michiels@gmail.com Subject: Re: DHCPv6 client in base From: Hiroki Sato In-Reply-To: References: <20191012.044034.19725945241254130.hrs@allbsd.org> X-Old-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-PGPkey-fingerprint: 6C0D 2353 27CF 80C7 901E FDD2 DBB0 7DC6 6F1F 737F X-Mailer: Mew version 6.8 on Emacs 26.2 Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="--Security_Multipart(Sat_Oct_12_11_04_55_2019_447)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (mail.allbsd.org [IPv6:2001:2f0:104:e001:0:0:0:41]); Sat, 12 Oct 2019 11:06:34 +0900 (JST) X-Rspamd-Queue-Id: 46qp8x44Ztz4LGG X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=allbsd.org header.s=20190220 header.b=baH5qGpx; dmarc=none; spf=pass (mx1.freebsd.org: domain of hrs@allbsd.org designates 2001:2f0:104:e001::41 as permitted sender) smtp.mailfrom=hrs@allbsd.org X-Spamd-Result: default: False [-5.41 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[allbsd.org:s=20190220]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MV_CASE(0.50)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[allbsd.org:+]; MID_CONTAINS_FROM(1.00)[]; SIGNED_PGP(-2.00)[]; DMARC_NA(0.00)[allbsd.org]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:7514, ipnet:2001:2f0::/32, country:JP]; FREEMAIL_CC(0.00)[gmail.com]; IP_SCORE(-2.31)[ip: (-9.12), ipnet: 2001:2f0::/32(-4.34), asn: 7514(1.92), country: JP(-0.01)] 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: Sat, 12 Oct 2019 02:06:44 -0000 ----Security_Multipart(Sat_Oct_12_11_04_55_2019_447)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Roy Marples wrote in : ro> On 11/10/2019 20:40, Hiroki Sato wrote: ro> > I do not have a strong objection on dhcpcd (I am using it on some of ro> > my FreeBSD boxes actually) but let me explain the reason why I chose ro> > wide-dhcp as the candidate. That is because it is a small, ro> > functional DHCPv6-only implementation. I am planning to rewrite it ro> > to add the missing bits and adjust it for a tighter integration with ro> > kernel, ifconfig, rtsold, rtadvd, and sandboxing with Capsicum. I ro> > feel dhcpcd (or others) is too big for that purpose. ro> ro> How are you measuring that dhcpcd is too big? .. ro> I don't consider dhcpcd to be big at all, and would love to know your ro> rationale for calling it so. I did not mean the binary size. Again, what I need for the base system import is source code just for core DHCPv6 procotol for further FreeBSD-specific changes. dhcpcd contains source code for the other protocols than DHCPv6 and non-FreeBSD platforms though it is possible to compile a part of them, and applying changes to it would not be FreeBSD-only thing because you are maintaining it in a portable manner actively. Importing involves those kind of aspects. I expressed them as "big" than importing wide-dhcp, which is no longer maintained by the original authors. Yes, FreeBSD can have a DHCPv6-only version of dhcpcd even at the source code level, which will be much smaller. But if doing so and applying FreeBSD-specific changes which cannot be upstreamed to it, we need additional steps to adjust a partial set of the dhcpcd source code and the contents will be diverged from the origial distribution. Although it is still possible, I think it is not good for both FreeBSD and dhcpcd. That is because if one uses dhcpcd, rtsold in the base system should not be used and relying solely on dhcpcd for handling incoming RAs would be much better. And probably IPv4 DHCP should also be handled by dhcpcd for consistency on the system. Thus, the question is: which is worth doing, maintaining a stripped version of dhcpcd or a client part of wide-dhcp, both with FreeBSD-specific changes applied? Adding IPC between rtsold, ifconfig, and DHCPv6 client is planned for better control and user experience, for example. I simply thought a no-longer-actively-maintained one with smaller code base is easier for that purpose, assuming there is no big difference in the core protocol coverage. I do not insist that this is based on inferiority of dhcpcd in terms of quality or absolute size. My apologies if my previous (and/or this) email sounds offending. How easier we can chop and cook it matters. I emphasize again here that people who want to use dhcpcd are still able to install net/dhcpcd and override a combination of utilities such as rtsold. Ditto for ISC's IPv6-capable dhclient. My opinion about the import is that if we adopt dhcpcd in the base system, we should replace all of the current dhclient for IPv4 and rtsold together. Of course we should consider it will need Capsicum or privsep for sandboxing and involve a bigger impact for IPv4 users at least. If there is no option except for dhcpcd I will go ahead with it regarless of my ealier mentioned concerns. So that is why I would like to know if wide-dhcp has a critical issue which cannot be fixed easily or missing feature at this moment. ro> This isn't a question about wide-dhcp specifically, but I feel it's a ro> good question. ro> ro> Do you plan on supporting a multihomed system with hotpluggable ro> interfaces all auto configured? ro> I'm looking at the BUGS section for rtsold and these bugs ro> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=138547 For multiple sources of RDNSS information, FreeBSD currently handles them by resolvconf(8) (yes, one of your works has been already imported) in the base system. The default configuration does not behave very well, so for a good user experience, one needs to configure resolvconf.conf to control ordering and overrides. The dhclient processes do not work collaboratively across multiple interfaces because they are just invoked independently, on a per-interface basis. rtsold does not, either. That is one of the reasons why I would like to add IPC between rtsold and DHCPv6 client. If they work, it can be implemented in dhclient in a similar way. ro> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218191 I could not understand what prevented dhclient from working at the first glance of this PR, but the cause may also be the fact that multiple dhcients work independently and override the default router, RDNSS, and/or etc. These scenarios are in my goals because IPv6 multihoming is more likey to happen than IPv4 while I am still not sure it will be a complete solution. If IPC between the per-interface daemons is not sufficient, we should have another "parent" daemon which monitors the per-IF worker processes or handling everything by a single daemon, which is much like things dhcpcd does. ro> This is one of dhcpcd's killer features and allows me to use my ro> pinebook on the sofa, but hotplug in ethernet to take over so I can ro> compile my sources from NFS over distcc much faster. Yes, that is one of things which cannot be handled. I think some FreeBSD use lagg(4) failover to handle that situation. It basically chooses the preferred interface (Ethernet) if it is up and running, and falls back to another (wlan) if the preferred one is link-down. A dhclient process runs on lagg(4), so it can be seen from userland as a single interface system. It has some drawbacks which you can probably point out, though. -- Hiroki ----Security_Multipart(Sat_Oct_12_11_04_55_2019_447)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iMkEABMKAC0WIQRsDSNTJ8+Ax5Ae/dLbsH3Gbx9zfwUCXaE0xw8caHJzQGFsbGJz ZC5vcmcACgkQ27B9xm8fc38x3QIJARU8HKxCZ7gpDxrinoHO5HzqH9c/pCuB19cx 7tlP/ivsPyKWvqY9w0IhuHz8QygfovO2pLBhkk+sNxI3EUgT/ubNAgkB5aJNTjjY Jk7INxabwZK6CYYl4/XSGljkW/nj1GSfCNrZ3ZrOnUVAW3W91GmipU/qzSCM5txX JloK76OaZOEVeio= =dLho -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Oct_12_11_04_55_2019_447)----