From owner-freebsd-net@freebsd.org Mon Oct 14 23:04:50 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 6B44C1430BB for ; Mon, 14 Oct 2019 23:04:50 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ua1-x941.google.com (mail-ua1-x941.google.com [IPv6:2607:f8b0:4864:20::941]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46sYzj4XQjz42rZ; Mon, 14 Oct 2019 23:04:49 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ua1-x941.google.com with SMTP id k24so5469093uag.10; Mon, 14 Oct 2019 16:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4eqHFaNKbzwXM0DGIxU1q8x5nFPvtsE5vhKhZ6GU0Rs=; b=XpNXYqh4JSSvpgyRz7ilFN4oyUaTE4tiRUG6llAe0snRFExBprFhtcd7rtyhrtCFmD 3IxIJX/BmdN0O5hCH1++nEBETzNoTUsF6ySCqhk7Fwvd7eF2cXeIk4CIwA/AKC2NOD+6 YJMd5hdl5VE+xqDCHTDhgFxtdtJ33ewTRFT0N+SkbtU8U3yvQPttO9SCZHmQa80Ld+3+ 6QHi+kez2Z2uR2XjS2gKwhc4U7ah1t2dLLS0f0Mu/b0B6A7JpDiym10JGsDYad+0AdeN yBXW26RklD7yhZaYfPhigPofzXVwKo9QnfU9MPI/e4prqqKwP2ypeSNEcJ+QcN3O54vD QD1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4eqHFaNKbzwXM0DGIxU1q8x5nFPvtsE5vhKhZ6GU0Rs=; b=rmOm/peZPE6farCtcFhBxydWBJKl9AkdMayk6JU/XlQEeifvKE2txIUbB6nod2/mUH meKNJid+FGO6uv++b7E37VXv+OiAmo9bCzCiqRwHHW6p6RvqTqLq2pRusfKHZkeT8AKX EQi8gt4dZVFK5j5Fo1AI/VYgVdtHutgqBhjFces9VzEdhqWiwrgbMGUxlQqJBfiu8+It KHdy6c9Gkbku52BuXpnOZM4bq14jqHlWNHl3D/4DCXhEnipySdoAYbkw4zkWKPK1qBTB SN1BYZieW+TgDK8HRLYl8AP4fhd28G4F1IW+WVdm+t/xXzyhkGoCUvEJQhatarUwQZZY eyWg== X-Gm-Message-State: APjAAAXRN4aXyfD00LpnnJQtc+OkHJolxrantCw8M7SgWSo6rx/r7BhZ NLyh6DRKiEtIfG7jQVQEcaVZTYRryn+MoCcq7D0= X-Google-Smtp-Source: APXvYqx2BIvvugqBuNKepwU4ATrLsrLKA/IF+L0sLiQVHrzRaDB/2f6fiE9961hvjMR8r5PADutksY8eLURKbEeSlHo= X-Received: by 2002:ab0:30f4:: with SMTP id d20mr11476268uam.71.1571094288421; Mon, 14 Oct 2019 16:04:48 -0700 (PDT) MIME-Version: 1.0 References: <001e01d50b49$176104d0$46230e70$@gmail.com> <20190516.032012.517661495892269813.hrs@allbsd.org> <20191012.044034.19725945241254130.hrs@allbsd.org> In-Reply-To: <20191012.044034.19725945241254130.hrs@allbsd.org> From: Ben Woods Date: Tue, 15 Oct 2019 07:04:37 +0800 Message-ID: Subject: Re: DHCPv6 client in base To: Hiroki Sato Cc: driesm.michiels@gmail.com, freebsd-net@freebsd.org, hrs@freebsd.org, roy@marples.name X-Rspamd-Queue-Id: 46sYzj4XQjz42rZ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=XpNXYqh4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of woodsb02@gmail.com designates 2607:f8b0:4864:20::941 as permitted sender) smtp.mailfrom=woodsb02@gmail.com X-Spamd-Result: default: False [-1.50 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; RCPT_COUNT_FIVE(0.00)[5]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (2.90), ipnet: 2607:f8b0::/32(-2.49), asn: 15169(-2.11), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[1.4.9.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SUSPICIOUS_RECIPS(1.50)[]; FREEMAIL_CC(0.00)[gmail.com] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Mon, 14 Oct 2019 23:04:50 -0000 On Sat, 12 Oct 2019 at 3:42 am, Hiroki Sato wrote: > I do not have a strong objection on dhcpcd (I am using it on some of > my FreeBSD boxes actually) but let me explain the reason why I chose > wide-dhcp as the candidate. That is because it is a small, > functional DHCPv6-only implementation. I am planning to rewrite it > to add the missing bits and adjust it for a tighter integration with > kernel, ifconfig, rtsold, rtadvd, and sandboxing with Capsicum. I > feel dhcpcd (or others) is too big for that purpose. One of the main attractions of dhcpcd is that it has been actively maintained for many years, and is already integrated into NetBSD and DragonFlyBSD, ensuring it will continue to be maintained. Whilst they don= =E2=80=99t get offered often, Roy appears quite open to accepting code contributions upstream. On NetBSD and DragonFlyBSD, Roy has also submitted changes to the kernel to introduce tighter integration with dhcpcd. Since receiving feedback from yourself and brooks, Roy has already begun the work to implement privilege separation in dhcpcd. Whilst Roy doesn=E2=80=99t currently plan on working on capsicum support, I= believe adding capsicum support will be easier once privilege separation is completed. I believe Roy would be very open to receiving these contributions upstream (with appropriate ifdefs for operating systems which don=E2=80=99t support capsicum). IMHO, the directions of further developments of IPv6 functionality on > FreeBSD, NetBSD (dhcpcd), OpenBSD (slaacd + others), and DragonFly > BSD (dhcpcd) have already been diverged. For RFC 7217 I already have > an in-kernel implementation (not committed yet), and I am also > working on SeND (RFC 3971, not directly related to DHCPv6 though). > My goal is to integrate these small implementations into the base > system and make them possible to work together. So for DHCPv6, I > think an implementation of only DHCPv6 is the best. > > If people want a more feature-rich implementation or the same one on > other systems, they can still use dhcpcd or ISC's dhclient even after > the import. > > Of course this assumes that wide-dhcp works to some degree. If it > does not, importing it to the base system does not make sense. I > have used it in various scenarios for a long time such as RA + O flag > on native IPv6 over Ethernet, DHCPv6-PD over PPPoE/L2TP, and others > which are complex enough, and understand what works and what is > missing (poor DUID format support, for example). The popular way to > use DHCPv6 is IA_PD, and wide-dhcp works well with it. > > So I have a question. What is missing feature in wide-dhcp which you > are concerned about? I know some, but it has most of the basic > functionality of DHCPv6 and I think it is enough as a minimal > implementation for the base system. My primary reason is that it is > just for DHCPv6 as mentioned earlier and I believe it is maintainable > in the base system. I would like to know other people's opinion if > there is something critical. > > -- Hiroki > Whilst I don=E2=80=99t have anything against wide-dhcp, I personally prefer integrated IPv4/IPv6 tools. ping vs ping6 for example would be better integrated in my opinion. The =E2=80=9Cfeature=E2=80=9D that I believe is missing from wide-dhcp is a= ctive maintenance. I believe that dhcpcd has the right license, adoption elsewhere, and active maintenance to make it successful for FreeBSD in the long run. Importing dhcpcd to the contrib/ tree means the maintenance to update it regularly is greatly simplified (simply import the newer upstream version and test). Anyone can submit any improvements / fixes upstream to Roy. 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 - add kernel support for tighter dhcpcd integration - switch defaults to dhcpcd, but leave dhclient and rtsold as available - remove dhclient and rtsold Regards, Ben --=20 -- From: Benjamin Woods woodsb02@gmail.com