Re: Import dhcpcd(8) into FreeBSD base

Hi Roy,

I appreciate your answers. More inline below.

> On 8. Aug 2022, at 12:42, Roy Marples <roy@marples.name> wrote:
> 
> Both dhclient and rtsold are only activated manually.
> For dhclient there is an exponential backoff after each message is sent. If the messages go nowhere (ie LINK_STATE_DOWN) then this delays the configuration aquisition and can slow down the boot process.
> For rtsold this is actually quite tricky as it requires a working LL address before it can work.
> This leads to sleep commands in rc which results in a slower than optimal boot time.

While there are true they do pertain to RC integration in FreeBSD. I know because other
projects have improved the situation with the tools at hand.

> dhcpcd reacts to state changes - however FreeBSD does not announce all state changes needed for this. For example here is a changeset I made 6 years ago for FreeBSD which allows this IPv6 addresses to announce state transitions from TENTATIVE to non TENTATIVE/DUPLICATED here:
> https://reviews.freebsd.org/D5469

Yes, this would be nice to have user space access to. :)

> Any DHCPv6 client also needs either a sleep or the above state changes to be made available.

I agree there is no canonical way to watch for changes, especially for scripting duty around SLAAC.

> There is a swathe of DHCP related RFC's that dhclient does not support, although none are necessary to actually get a working configuration for most users.

That could be. 6RD through DHCP is tricky for example. But on the other hand we do have a lot of people using
routers and direct ISP connectivity and do encounter the most visible issues here which in my opinion you cannot
see from a home lab or traditional "network server" FreeBSD use case.

> rtsold (in FreeBSD-13 at least) has no mechanism to get RDNSS and DNSSL options from RA messages into the local nameserver.

I may be mistaken, but the -R option should take care of this and seems to be enabled by default invoking resolvconf(8).
I think this has been the case for a number of major iterations before FreeBSD 13.

> dhclient and FreeBSD kernel RA handling do not support a predictable configuration for multi-homed boxes. It operates on a first come, first served basis.

That's due to dhclient-script handling, sort of like the RC integration issue mentioned before.

> dhcpcd supports a predictable configuration allowing a "better" interface to take over the default route, preferred nameservers, etc.

That does sound nice for integration. Thanks for confirming. 

> There's no proposal to remove dhclient or rtsold yet.

To be fair, that was the original proposal. If dhclient and rtosold are not removed and
made second class citizens in FreeBSD that amounts to the same bitrot and neglect
that we would see if it would be taken out of the base system.

Just my concerns here. I'm sure people will find a way. :)


Cheers,
Franco