isc-dhcp: should we start phasing it out?

Dan Streetman ddstreet at
Mon May 16 19:21:38 UTC 2022

On Mon, May 16, 2022 at 3:06 PM Steve Langasek
<steve.langasek at> wrote:
> Hi Andreas,
> On Mon, May 16, 2022 at 02:34:30PM -0300, Andreas Hasenack wrote:
> > Alternatives that come to mind are:
> > - kea, of course (from ISC). dhcp server only.
> > - dnsmasq (for small installations?), also server
> > - systemd-networkd itself obviously does the client part
> > - others?
> > isc-dhcp is such a classic that it is undoubtedly referenced in many
> > places, so phasing it out might be difficult. On the server, Kea is
> > not a drop-in replacement.
> As I mentioned at
> <>, isc-dhcp is
> no longer used out of the box as the DHCP client in Ubuntu, on either
> desktop or server; server uses systemd-networkd's internal dhcp client
> implementation, and desktop uses NetworkManager's.

There are still users of 'dhclient', especially in some cloud environments.

I suspect there will be a demand for it until someone updates systemd
to be able to replace its functionality, with something like:

$ networkctl dhclient eth0

That would require an upstream discussion to figure out the exact
usage and implement it, of course.

> The only reason that
> isc-dhcp is still installed by default is for the initramfs: because we
> support nfsroot, iscsi, remote disk unlock via dropbear, etc.
> Several suggestions of path forward on support for dhcp in the initramfs, in
> no particular order:
>  - work with klibc upstream to extend ipconfig to be a suitable DHCP client
>    for the initramfs (requires DHCP support)
>  - migrate to a systemd-based initramfs everywhere, and use systemd-networkd
>  - Repackage isc-dhcp to provide an 'isc-dhcp-initramfs' package that no
>    longer provides integration with the main system, so that it can continue
>    to be used for initramfs without having a large ongoing support surface
>    (but, this doesn't remove the need for security support)
> > We also have the udebs, but with subiquity being the installer now we
> > probably don't need to worry about these anymore?
> We definitely don't need to worry about udebs in future Ubuntu releases;
> they aren't even built in Launchpad in the current series.
> > rdeps at
> > Removing isc-dhcp would also allow us to reduce the need of old compat
> > src:bind9-libs package, probably even drop it.
> Ugh
> > Could we perhaps start with phasing out the client, get its rdeps to
> > use alternatives, and then stop building it, and eventually get to the
> > server? This could be a lot of work, as I said, isc-dhcp is a classic,
> > but if upstream is shifting its focus elsewhere, soon we will be
> > alone.
> I think you'll find that phasing out the client is much more work than
> phasing out the server, given the ways the client is integrated in other
> packages.
> > Reverse-Depends
> > * cloud-init
> Another example of client integration that's going to require attention;
> cloud-init uses isc-dhcp-client to be able to query specific dhcp attributes
> in early boot used to identify the cloud metadata service.
> > * dracut-network
> > * isc-dhcp-client-ddns [amd64 arm64 armhf ppc64el s390x]
> > * libguestfs0 [amd64 arm64 armhf ppc64el s390x]
> > * netscript-2.4
> > * network-manager [amd64 arm64 armhf ppc64el s390x]
> I think network-manager's dependency on isc-dhcp-client is vestigial.  You
> will not find any instances of isc-dhcp-client running on an Ubuntu 22.04
> desktop system.
> Cheers,
> --
> Steve Langasek                   Give me a lever long enough and a Free OS
> Debian Developer                   to set it on, and I can move the world.
> Ubuntu Developer                         
> slangasek at                                     vorlon at
> --
> ubuntu-devel mailing list
> ubuntu-devel at
> Modify settings or unsubscribe at:

More information about the ubuntu-devel mailing list