Dear Maintainer,

`dhcpcd.service` has `Before=networking.service`, which is basically exactly opposite what you want in most cases.

If you are using ifupdown to manage your statically-configured interfaces, such as LAN interfaces, and then using PD via dhcpcd to manage provider-delegated addresses to those interfaces, you want those interfaces configured and brought up *before* dhcpcd starts. In my case, that means creating VLAN interfaces with specific sysctls (e.g., `addr_gen_mode=1`) and bringing them up with static RFC 1918 IPv4 addresses, ULA IPv6 addresses, and chosen IPv6 link local addresses (e.g., `fe80::1`), all of which needs to happen before dhcpcd touches them.

Notably, my WAN connection doesn't have any static configuration outside of dhcpcd.conf and sysctl.d/*: it is not even referenced in /etc/network/interfaces.d/*, because dhcpcd entirely manages the lifecycle of that interface, overriding virtually every setting you might want specified in an interfaces stanza, so I cannot fathom why anyone would want to enforce dhcpcd starting before `ifup -a`.

`dhcpcd.service` should either have `After=networking.service`, or should not specify a dependency at all, letting the user set the right order via `override.conf` without having to shadow the entire service module and keep it in-sync with upstream perpetually. (That motivates another feature request for systemd that I am sure will never be accepted, that of syntax to remove individual entries from list variables via override; but I digress.)

See bug #1121016 for details.

Martin-Éric

On Sat, Sep 5, 2026 at 2:38 AM Martin-Éric Racine <martin-eric.racine@iki.fi> wrote:


Now I'm curious what ifupdown is planning for 0.9. It seems to me that it
should stick to simple behaviors and leave anything complex to something
with an interface more expressive than `ifup -a`. If they insist, I can see
two possible paths forward:

1. Have `dhcp` method interfaces brought up automatically only if dhcpcd is
already running in manager mode, and then have two oneshot services each
run `ifup -a`, once `Before=dhcpcd.service` and again
`After=dhcpcd.service`.

2. Replicate all of dhcpcd's configuration options in an interface stanza,
with `ifup -a` managing `dhcpcd@` service instances for each such
interface, doing some dependency ordering based on prefix delegation, etc.,
to ensure interfaces are configured in the proper order. This seems...
really complex for something like ifupdown to do without breaking some
decades-long reliance interest.

Either way, I think a unilateral `Before=networking.service` is wrong, with
your observation that "none of the interfaces that dhcpcd would delegate an
IPv6 prefix to would be up yet" right on the money.

la 5.9.2026 klo 15.51 Kyle Rose (krose@krose.org) kirjoitti:

Daniel exposed some of his ideas for the next ifupdown inside a
lenghty e-mail a while back. We disagreed on specific points. It's
been a while, so I don't remember the specifics. I don't think that
anything has moved since then.

Desipite this, dhcpcd is capable of waiting for interfaces to be up
before it delegates a prefix, so After or Before both work, which is
why I agreed to change it now, even though whatever changes Daniel has
in mind for the next ifupdown haven't materialized yet.

Anyhow, I suggest purging bin:dhcpcd and only keeping bin:dhcpcd-base.
Keeping bin:dhcpcd really doesn't make sense if you use ifupdown,
since it results in two instances of dhcpcd trying to control the
interfaces: one launched by the systemd unit and one by any instance
of the dhcp method in /etc/network/interface.

Martin-Éric

Ok, I'll have to test this. I ran into a problem at some point in the
recent past in which I found my `pre-up sysctl -q
something.addr_gen_mode=1` command to disable automatic LL address
generation wasn't being respected, and I presumed it was because dhcpcd was
touching that interface before ifupdown configured it. It could have been
something else. (There was a related issue about
ifupdown-wait-online.service by default delaying my boot by 5 minutes
because ifupdown was waiting for dhcpcd.service, which in turn was waiting
on network-online.target, resulting in a dependency cycle that couldn't be
broken except by timeout; but I fixed that by switching to the `ping`
method.)


I don't use the dhcp method at all. For context, this is what I've been
developing over the past few months:

https://github.com/squarooticus/uplinkmgr

I explicitly don't want ifupdown touching my WAN interfaces, because I need
dhcpcd to manage them according to a configuration written by uplinkmgr.
For about a decade, I have used ifupdown to manage *only* my
statically-configured internal interfaces because (a) pump and dhclient
both suck, and ifupdown basically only ever worked correctly with those
two, and (b) now that I need backup internet with automatic failover, I
wanted something that would reliably manage DHCP for multiple interfaces,
with dhcpcd fitting the bill (and additionally possessing the inertial
advantage that I was already using it).

la 5.9.2026 klo 16.30 Kyle Rose (krose@krose.org) kirjoitti:

That is extremely unlikely caused by dhcpcd. The only aspect of LL6
that dhcpcd touches is that upstream implements his own homebrewed
code to generate stable-security LL6 addresses instead of letting the
kernel handle it via "net.ipv6.conf.*.addr_gen_mode=3". Nonetheless,
even that can be disabled using the "slaac hwaddr" configuration
option.

That would still be doable via a pre-up command in
/etc/network/interface on whichever interface calls the dhcp method.

In any case, you're not the first one who runs into problems with
dhcpcd in manager mode AND ifupdown both installed. Given this, I'll
probably make bin:dhcpcd explicitly Conflicts with ifupdown.

Martin-Éric

Fair. I'll probably then have uplinkmgr provide its own service file for
dhcpcd which will allow me to order it relative to ifupdown however I need
to.

If you do this, though, I am curious how someone would use dhcpcd in
manager mode for any kind of non-trivial topology. E.g., how would a router
configure internal interfaces to prepare them for dhcpcd-mediated PD? Aside
from a flat custom script one-shot at boot time, are there recommended ways
of configuring interfaces other than ifupdown that won't then conflict with
dhcpcd's management of the WAN interfaces? I have a hard time believing
that, for example, NetworkManager or systemd-networkd will play nicely with
dhcpcd's manager mode: they also seem to want to control everything.

la 5.9.2026 klo 17.17 Kyle Rose (krose@krose.org) kirjoitti:

For now, I'll at least remove all references to networking.service in
both systemd units that we ship. From my perspective, the only
important part is that we need to be have succesfully configured the
network before reaching the global network.target that we declare as
want/before. Whether networking.service or anything else also expects
to have succeeded before network.target should not be our concern.
Daniel/others are welcome to prove me wrong.
network-manager all try to control everything. However, calling dhcpcd
via ifupdown's dhcp method keeps things inside a narrow manageable
scope.

Martin-Éric

la 5.9.2026 klo 17.17 Kyle Rose (krose@krose.org) kirjoitti:

I would never use dhcpcd in manager mode if there's non-physical
interfaces involved because dhcpcd lacks the ability to setup bridges
and vlans, while ifupdown can do vlans out of the box and bridges with
a simple plugin.

Here's what I use with ifupdown:

$ cat /etc/dhcpcd.conf
require dhcp_server_identifier
option domain_name_servers, domain_name, domain_search, interface_mtu
option classless_static_routes, routers, sixrd, ntp_servers
duid
slaac private
noipv4ll
release
timeout 0
vendorclassid
interface enp3s0
 ia_pd 1 br0

$ cat /etc/network/interfaces
source /etc/network/interfaces.d/*
allow-hotplug /en*
iface enp3s0 inet dhcp
post-up /usr/libexec/IPv4-MASQ_IPv6-Bridge $IFACE
iface enp2s0 inet manual
iface enp4s0 inet manual
iface enp5s0 inet manual
iface enp6s0 inet manual
auto br0
iface br0 inet static
bridge_ports regex (wl|enp6s|enp5s|enp4s|enp2s).*
address 172.16.1.1

Another method, on a really complex host, would be to use dhcpcd as a
backend for Netplan, instead of ifupdown. I personally have no
experience of this, but it apparently works well.

Martin-Éric

The reason I went with manager mode is that the dhcpcd owners at some point
announced that they were going to stop supporting multiple instances of
dhcpcd on the same machine, so if you want multiple WANs managed by dhcpcd
you'd need to use manager mode going forward. And I found it worked well,
assuming I set up the virtual interfaces beforehand, which I did via
ifupdown because that's what I had experience with.

It's possible I want to just jettison ifupdown entirely and use a custom
script to handle it at boot time: I don't love that, but the cross-purposes
between all of these packages might make the result too fragile to rely on,
especially across upgrades that might make a machine suddenly unreachable
on boot.

la 5.9.2026 klo 18.05 Kyle Rose (krose@krose.org) kirjoitti:

Upstream is still toying with eventually deprecating the possibility
of running multiple instances of dhcpcd on the same host, but it
hasn't happened yet. Even then, calling dhcpcd with the interface as a
command argument e.g. via ifupdown would still work.

That's why I'd really love for dhcpcd to eventually become capable of
setting up bridges and vlans. Once it can do that, ditching ifupdown
and using dhcpcd.conf instead of /etc/network/interfaces would make
sense. Even better would be to teach dhcpcd to read and use
/etc/network/interfaces as-is to configure multiple interfaces. Since
the file is generated by ifupdown at install time, it's never deleted,
even after purging ifupdown. This would provide the smoothest
transition from ifupdown+dhcpd to dhcpcd in manager mode. Debian could
just deprecate ifupdown and install dhcpcd in manager mode from that
point on.

Martin-Éric

At that point, you may as well rename it systemd-dhcpcd. ;-)

In all seriousness, monolithic consolidation is not the ideal end state.
IMO, the right approach is to have black-box interfaces around discrete
functions that can be implemented differently while enabling predictable
behaviors across those functions. For example, router advertisements don't
necessarily need to be multicast by the DHCP client, but the DHCP client
*does* need to be able to inform the RA daemon about the prefixes it has
delegated to each interface and which in turn need to be advertised to
clients on those segments.

This is an inherently more difficult pattern to implement, but the end
state is one that is a lot more resilient, as well as more customizable
where users need greater control.

But now we're into philosophy, so probably best to relegate this one to bar
talk. ;-)

Kyle

We believe that the bug you reported is fixed in the latest version of
dhcpcd, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 1146692@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Martin-Éric Racine <martin-eric.racine@iki.fi> (supplier of updated dhcpcd package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)
Format: 1.8
Date: Sun, 06 Sep 2026 12:05:01 +0300
Source: dhcpcd
Architecture: source
Version: 1:10.5.2-2
Distribution: unstable
Urgency: medium
Maintainer: Martin-Éric Racine <martin-eric.racine@iki.fi>
Changed-By: Martin-Éric Racine <martin-eric.racine@iki.fi>
Closes: 1146692 1146835
Changes:
 dhcpcd (1:10.5.2-2) unstable; urgency=medium
 .
   * [systemd]
     - Remove After/Before references to networking.service (Closes: #1146692).
   * [rules]
     - Ensure that monitor mode restarts after an upgrade (Closes: #1146835).
Checksums-Sha1:
 912bebde8030a9d3736d266fffe86bfab4a72328 2449 dhcpcd_10.5.2-2.dsc
 6d72d7ffa1dc6c08cd92978f92863402d44f6fd7 21476 dhcpcd_10.5.2-2.debian.tar.xz
 7efa99b3fba75c4955577ef9515f5893b8f9269d 5322 dhcpcd_10.5.2-2_source.buildinfo
Checksums-Sha256:
 84bd570b5a0485bcd575fb3ab5b077f053351ca2d15a735fb729827908e5ee8e 2449 dhcpcd_10.5.2-2.dsc
 02354d8184fad966abfc062ded35c63004339d7c80f527671f18ba3beff63634 21476 dhcpcd_10.5.2-2.debian.tar.xz
 2c64cb9c4f370865c0e6e2e576f6b9105b82bf46942ca01da01b6edb3e4d4872 5322 dhcpcd_10.5.2-2_source.buildinfo
Files:
 f32ae8834f2057fc6aba851eaf9ea94c 2449 net optional dhcpcd_10.5.2-2.dsc
 57e6028a2d0f7523dd2af2fc0e5c2653 21476 net optional dhcpcd_10.5.2-2.debian.tar.xz
 69fe6b28a58e86c2a4e845671fafceff 5322 net optional dhcpcd_10.5.2-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmqdLzkACgkQrh+Cd8S0
17YBIg//fxxCnOFHzXmkTBacL3fnnP//79oPn++ToT5rGTBh3QdpE23O3wflhAu8
JuzNEdhB4MzPluZpDyvk17zQ22XXF62EmSYGbWo5U0A5MSJ+0LfrgJHCacCl/JJu
WvrRFi1wVcsdej1RkkmeXyY6UDT1LyNAngtGhKrXg5g5u1pk/2WFvmVJvQPQYDzh
Gj9wE5c57FbnQ6TFgLDEy31CeESM4YtVFeAKLvuveJ0FqNVLIm3W3W5Uj2uD3nPs
If+mCDWxlb/V8oaEtwyjmcCzUBkysucQrp9BQpKOwIWcYk4ITSCVej1e16ty12bA
x3uEvRm0wTkrHNTtgGc7MHXzsP7DkcUQkMoEQFvPnhO6aU1Nnnhi8moLV3Sho4o7
2HUTSVXfKMSp6Vnh7cEEhCZ3VOii3NayGtWvkzoqH1kQurALmqcYu9UzcXoPZU57
LbVxTVGcxnMJJV+VdbYalq9ZlInFDSBvuwadY39+9PlmLjK+jBbdTCEP1FdX+bIb
YAvvrxG+D6BB/uwItIac1uFYRrQHoopT5emBlzobGbgVJN9kWki0+b+gFOqOn8os
T+AYPfPQSrxd4X4QyUdSTz7QO7n52xfLv3erruaR4ZGlX4OMScayQ0NjDxCRIadZ
royhpqZWYOW5snhgG3tCmDNgfPQlPw5bQA1feAk3jPjXLDWzTVg=
=qd/6
-----END PGP SIGNATURE-----