From owner-freebsd-net@freebsd.org Mon Oct 14 23:52:32 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 0E054143A94 for ; Mon, 14 Oct 2019 23:52:32 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 46sb2l211mz44L7; Mon, 14 Oct 2019 23:52:31 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-vs1-xe2e.google.com with SMTP id p13so11940412vsr.4; Mon, 14 Oct 2019 16:52:31 -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=DXLZ7Btm5o6xAoc6DXMSIjbREvF6usjuu8w3n0ki3/8=; b=g7nbz+Yjgcf98CbKSW5SZ0joqfPIPbfAjmwDiL+8jBcrTAQ2MoL8HMCTCFNgbc2Xdd G4sL3Q9bvY2vE+XLL43BDxdFJgpG25D9FziBL+0sE+7stry1mc0wWONyyaZzJ/sg8/dG zqi8C2cv0BzU8yVG1Z6FbcEPKDFLWsQVqogHS2g2/VnmoE5HF8v3Ms8rkTZrnBZFxTP/ i90Z5/ikVT+JoJBYS2TzYI5sitcMBA04TrDGurOtaiC23W0M0S1TGThO+b3ZYUHzakSu eN9eTowNw75mSsI6s8KWg8inQ+x7kIFear+57Q7DfzO20T38AAzn2U1Lz5GuGphVPnhG PmXw== 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=DXLZ7Btm5o6xAoc6DXMSIjbREvF6usjuu8w3n0ki3/8=; b=M9dDVKG9ao68WVBSPF4LpaaALZPX1y4yZPwdq5s3J7UaKPcYdCBX5xEFS8fIGWG2R+ ewPKBQYak5fCkc0NR/TlhVZe0FMCYJpDdq8oaJ3zrSR69byg7UbGnEAQBigHRd8VAVt+ Cf9Q9rdQYS3H2CbA8QwgiHjejg65odAkAmGKoBuZx+HyavatFLx6RuYs+zHLC1ciIeV4 m0XlsROzuu0rUS35HKIlpNuVpXZVbk4th1Ea0pM4QWnZ51XNVRsR7IxfLgdLVXnVBE2K AKOdBfOGnusdsvlEGvjvSxvG/smIJrY2vUIfIaVgeCZuZtCVhwA+0uiK5bx7ASo0W/8j woXA== X-Gm-Message-State: APjAAAWiPmr/eyl3DUhOiBNR0BTYkeU49d+esrzzmwPJ9iUOS6sxvU5Z PYhnmUCOU4EDzx8HHq3bAAleiuVwsvyermiIpp8= X-Google-Smtp-Source: APXvYqzkB6eEFyLKpY9HrDg2ewBX5nU7yfX4Ae4XYbwBCUyV4RxngtMazWBdwrjlubrycjQ9kMLxXHt/3PzT9PNITRY= X-Received: by 2002:a67:fe53:: with SMTP id m19mr8121759vsr.98.1571097149523; Mon, 14 Oct 2019 16:52:29 -0700 (PDT) MIME-Version: 1.0 References: <20191014.043209.919156653743886519.hrs@allbsd.org> In-Reply-To: <20191014.043209.919156653743886519.hrs@allbsd.org> From: Ben Woods Date: Tue, 15 Oct 2019 07:52:17 +0800 Message-ID: Subject: Re: DHCPv6 client in base To: Hiroki Sato Cc: brooks@freebsd.org, driesm.michiels@gmail.com, freebsd-net@freebsd.org, hrs@freebsd.org, julian@freebsd.org, roy@marples.name X-Rspamd-Queue-Id: 46sb2l211mz44L7 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=g7nbz+Yj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of woodsb02@gmail.com designates 2607:f8b0:4864:20::e2e as permitted sender) smtp.mailfrom=woodsb02@gmail.com X-Spamd-Result: default: False [-1.50 / 15.00]; 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)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; IP_SCORE_FREEMAIL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_IN_DNSWL_NONE(0.00)[e.2.e.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]; IP_SCORE(0.00)[ip: (-9.54), ipnet: 2607:f8b0::/32(-2.49), asn: 15169(-2.11), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SUSPICIOUS_RECIPS(1.50)[] 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:52:32 -0000 On Mon, 14 Oct 2019 at 3:34 am, Hiroki Sato wrote: > How do you want to proceed the discussion? I sent my view and made > myself clear that importing dhcpcd into the base system as-is is not > a good idea. What is your answer to my concerns? I also agree with > Brooks about a need for sandboxing before the import if it will > happen. Do you have any plan to add changes to the imported dhcpcd? To address your comments about duplicate functionality, and FreeBSD only lacking DHCPv6 functionality at the moment - my thoughts are we should import dhcpcd as a whole, with the plan to ultimately remove dhclient and rtsold to remove duplication of code/functionality. This would likely follow 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 Roy Marples (upstream dhcpcd maintainer) is already working on privilege separation for dhcpcd, following feedback from yourself and brooks. Whilst he is not planning on working on capsicum support at this point, I believe this would be easier to add after the privilege separation work is done. What are your thoughts whether the import could occur before privilege separation, or after privilege separation but before capsicum, or only after both? My thoughts were that if it off by default then users are not affected unless they make the conscious decision to enable dhcpcd. This would provide the DHCPv6 functionality in base (with network.subr integration) for users who decide they need it (myself for example). Suggest the switch to default would require one or both of these security mitigations. We could include commentary about the current state of security mitigations in the handbook / rc.conf manpage updates to assist users in making a decision? And, I think there is common mistake about how to invoke dhcpcd in > D22012. DHCPv6 client should be invoke upon RA with O-flag received, > not invoked independently or by devd(8) upon a link-up event. I do > not want people to configure ifconfig_IF_ipv6=3D"DHCP". What people > should be aware is if they want to allow receving RA. Whether DHCPv6 > is required or not should be controlled by RA, not configuration on > the host side. Also, DHCP-PD shuold be handled in rc.d script > framework in some way. Doing something similar to IPv4 DHCP client > is not enough, and having both rtsold and dhcpcd is just confusing. One of the reasons I worked on this change and submitted it for review was for exactly this feedback - what would the rc.conf and network.subr integration look like? So thank you for this feedback. Given that dhcpcd replaces both rtsold and dhclient, I believe network.subr and devd are the right place to initiate dhcpcd. If enabled, it needs to start once the interface comes up to perform both router solicitation and then subsequently DHCPv6 if instructed by the router. Regarding rc.conf, I believe we need to develop an rc.conf user interface that makes this clear that all of the above behaviour will be performed. Rather than ifconfig_IF_ipv6=3D=E2=80=9CDHCP=E2=80=9D do you think ifconfig_IF_ipv6=3D=E2=80=9Caccept_rtadv=E2=80=9D is more clear? The network.subr and rc.conf options I proposed were pulled from DragonFlyBSD, with the options for background_dhclient and synchronous_dhclient added to also support dhcpcd. Doesn=E2=80=99t mean the= y are right, or that we have to accept them, just giving context. I am very open to changing this if it makes sense. I want to continue discussion about what is the best or better > direction instead of going ahead with D22012. > > -- Hiroki I think there is value in discussing what it would look like to import dhcpcd as a whole (with the above migration phases in mind), mainly focusing on the libexec/rc/ elements such as network.subr, devd, and rc.conf. Would you be willing to further the discussion of this? Suggest that if so, D22012 would be a good place to have it. Regards, Ben > -- -- From: Benjamin Woods woodsb02@gmail.com