Re: Import dhcpcd(8) into FreeBSD base

Hi Franco

On 07/08/2022 08:08, Franco Fichtner wrote:
> The basic question is: what's not working in dhclident? How is rtsold inferior?

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.

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

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

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.

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

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.
dhcpcd supports a predictable configuration allowing a "better" interface to 
take over the default route, preferred nameservers, etc.

> 
> It seems like "It’s well supported, full featured, included in NetBSD and
> DragonflyBSD base" incorporates none of the real world concerns for migratory
> work so for the time being I don't think it's a solid proposal, also because
> it will cause heavy downstream disruption in OPNsense/pfSense in a few years
> as well.

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

Roy