Note that 20080615-24 is comprised of two parts:

• 20080615: The version from upstream.
• 24: The Debian patch version. The change log is here.

The latest Debian patch was the 18th of March 2025, so the code does still see some limited updates. It does seem to be on the way out though. Of the clients Debian lists, systemd-networkd is probably out for VyOS, ISC is also unmaintained and Dibbler seems unmaintained too. The only remaining option is dhcpcd, which is quite actively developed.

I took a (heavily LLM-assisted) stab at updating VyOS to support it but there are some challenges. Many of the dhcpv6-options don't have a clear equivalent in dhcpcd so the interface would likely have to change.

I was working on something and got frustrated enough that you can't get info out of WIDE about its lease state, nor run custom hooks for anything beyond the DNS configurations, so I took a stab at replacing WIDE with dhcpcd:

• vyos-1x PR 5147
• vyos-build PR 1168

I focused on making this a drop-in replacement for the existing WIDE functionality and configuration syntax. Using this as a base, I've already been playing around with implementing some useful show commands (show dhcpv6 client leases), but that work will get pushed separately.

Two things I'd like to get Maintainer feedback on:

• [*never mind] DUID behavior. Out of the box, dhcpcd generates a per-interface DUID-LL (type 0003, derived from the interface MAC) rather than the single global DUID-LLT (type 0001) that wide-dhcpv6-client stored in /var/lib/dhcpv6/dhcp6c_duid. I think it's probably possible to come up with a migration here to keep operators' DUIDs stable, but I wasn't sure if it was worth it -- or if documenting the fact that auto DUIDs will churn is sufficient.
• Netlinkd. I saw there was some recent work here to ditch netplug. I may be missing some of the context, but it seemed like both solutions were there to workaround WIDE's incomplete handling of linkstate changes. dhcpcd seems to handle this quite well all on its own, directly subscribing to RTM_NEWLINK events via a netlink socket, and the netlinkd integration just sent them both mutually restarting each other. My proposed change is to let dhcpcd handle this directly, and I removed the touch points from netlinkd. If I missed some context here, I'd love to understand it better and address whatever gap may remain.
  
  *A smoke test pointed me in the right direction on the DUID generation.

[*never mind] DUID behavior. Out of the box, dhcpcd generates a per-interface DUID-LL (type 0003, derived from the interface MAC) rather than the single global DUID-LLT (type 0001) that wide-dhcpv6-client stored in /var/lib/dhcpv6/dhcp6c_duid. I think it's probably possible to come up with a migration here to keep operators' DUIDs stable, but I wasn't sure if it was worth it -- or if documenting the fact that auto DUIDs will churn is sufficient.

We have added a custom patch adding per interface duid support. https://github.com/vyos/vyos-build/blob/current/scripts/package-build/wide-dhcpv6/patches/wide-dhcpv6/0023-dhcpc6-support-per-interface-client-DUIDs.patch

Netlinkd. I saw there was some recent work here to ditch netplug. I may be missing some of the context, but it seemed like both solutions were there to workaround WIDE's incomplete handling of linkstate changes.

No, the main reason to re-implement a netlink listener daemon is to avoid context switches from a C daemon to exec() calling python3 calling shell commands. Also the old netlinkd was not as extensible, only via custom hook scripts. With vyos-netlinkd we now have full flexibility reading in the config on events. Also the old implementation was known of leaving zombies behind.

Copy from GH PR

@cpcowart thank you very much for the time and effort you put into this work - it is genuinely appreciated.

As you also outlined in Phorge, there are several DHCP client daemons that can cover similar functionality. In this specific case, the proposal would effectively replace one daemon with another that appears to be better maintained at this point in time.

From the maintainers’ perspective, and based on our current understanding, systemd-networkd currently looks like the most promising and actively maintained long-term direction. There is also interest in potentially using systemd-networkd to improve predictable interface naming (i.e., reducing the occasional interface name <->hw-id mapping issues).

That said, we currently do not have internal alignment to move forward with either dhcpcd or systemd-networkd right now, primarily due to time constraints. We have not yet had capacity to build and validate a full PoC for systemd-networkd against all VyOS requirements.

This may change once the Debian Trixie transition is underway in 2026, when we expect to revisit this area with clearer direction. I am closing this so we can later resurrect this PR if needed and not consume additional time on this topic.