DHCPv6 client in base

[Ben Woods]

On Mon, 14 Oct 2019 at 3:34 am, Hiroki Sato <hrs at allbsd.org> 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="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=“DHCP” do you think
ifconfig_IF_ipv6=“accept_rtadv” 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’t mean they 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 at gmail.com