Roadmap: dhcpcd 11 removes process-per-interface — can our model survive the cutover?

[claymore666]

TL;DR

We depend on running one dhcpcd process per container interface. dhcpcd 11 removes that model in favour of a single long-lived manager daemon for all interfaces. We're safe today (we pin dhcpcd 10.x), and the cutover is entirely on our schedule — but we should figure out, deliberately and ahead of time, whether our design can survive on dhcpcd 11, and if so how. This thread collects everything we know, a candidate roadmap, a potential solution, and the one spike that would settle it.

---

Background — why we use dhcpcd at all

The plugin gives each container a real IP from the LAN's DHCP server. dhcpcd is the client that performs that DHCP/DHCPv6 exchange on the wire, in observe-only mode (--noconfigure): it negotiates the lease and reports it back, and the plugin applies the address to the container via netlink.

We migrated from busybox udhcpc/udhcpc6 to dhcpcd because busybox's DHCPv6 client derives its IAID from rand() with no override. That meant the one-shot acquisition client and the persistent renewal client drew different IAIDs → the server allocated two different IPv6 addresses → the address the container actually used was never renewed (a latent address-collision bug). dhcpcd lets us pin duid + iaid per interface so both clients share one identity association and one renewable address. busybox simply cannot do this, and the alternatives (odhcp6c, ISC dhclient) were worse, so dhcpcd was the right tool for the requirement.

How we use dhcpcd today (the dependency)

Our architecture is one independent dhcpcd process per container interface, per family:

• a one-shot client to acquire the first lease, plus a persistent client to renew it — and the same for IPv6;
• each launched with its own config file carrying the pinned duid/iaid;
• each in its own private mount namespace with a tmpfs over dhcpcd's state dir, so two containers using the same interface name can't collide on shared host state;
• the persistent client runs inside the container's network namespace.

"Spawn an isolated dhcpcd bound to exactly one interface, scoped to one netns" is the design — it's how we get per-container identity and isolation.

The problem — dhcpcd 11

dhcpcd 11 removes the process-per-interface model. The replacement is a single manager daemon that owns all interfaces and protocols, "started as a service in the same way as apache, postfix or dnsmasq." That is the opposite of our one-process-per-interface assumption.

What we know about dhcpcd 11 (from the maintainer's discussion)

Source: NetworkConfiguration/dhcpcd discussion #271

• Single manager daemon — "one instance for all interfaces and protocols"; must run as a service.
• dhcpcd.conf stays unchanged — so our per-interface duid/iaid config is likely still expressible (maintainer's wording).
• --noconfigure (observe-only) survives — explicitly preserved. This is the mode our whole mediator model depends on, so it's the key green light.
• Dynamic interface management — the daemon can be told about interfaces at runtime; it'll spawn the manager if not already running.
• Network-namespace scoping — not addressed by the maintainer. This is the open unknown for us.
• Reason for the change — privilege-separation complexity and per-process resource overhead.
• Status — still in development (work on a manager_only branch); no announced GA date. The CLI surface is being reduced and is not final.

Who controls the cutover / timeline

We pin the exact package (dhcpcd=10.3.2-r0), guarded by the weekly apk-pin check. Therefore:

• Upstream releasing dhcpcd 11 changes nothing for us automatically.
• The only external trigger is the base image's package repo eventually dropping the 10.x package, and even that only bites when we bump the base image — also our decision.
• So this is scheduled debt we choose when to pay, not a forced migration. Realistic horizon: years, and we'll see it coming.

Potential solution / candidate roadmap

Shift from "one process per interface" to "one dhcpcd-11 manager per container (per network namespace)." This works with dhcpcd 11's grain:

• A process only sees the interfaces in its own netns, so a manager scoped to a container's netns naturally manages just that container — handling IPv4 + IPv6 in a single process (fewer processes than today, not more).
• Per-container identity still rides dhcpcd.conf (duid/iaid unchanged).
• --noconfigure still gives us observe-only.
• Our mount-namespace + tmpfs isolation still applies, since we'd still run one process per container.

Open risks & the spike we need

The design above hinges on unknowns that a small spike would settle before we commit:

1. Netns scoping (gating unknown). Can a single dhcpcd-11 manager be run cleanly scoped to one container's network namespace, managing only that netns's interface? The maintainer didn't address namespaces. This is the make-or-break question.
2. Lifecycle. dhcpcd 11 assumes a long-lived system service ("spawn the manager if not running"). We need a manager bound to one container's lifetime, started/stopped per container — not a host-wide singleton. Confirm we can run it that way.
3. Per-interface identity in the manager model. Verify duid/iaid pinning still produces one binding per container when expressed in dhcpcd.conf under the single-daemon model.
4. Observe-only completeness. Confirm --noconfigure under dhcpcd 11 still leaves all link configuration to us (it's documented as preserved, but it's also undocumented/test-equivalent today).
5. Moving target. The CLI is being reduced and isn't final — we can prototype against the manager_only branch but cannot finalize until it stabilizes.

Proposed spike: stand up the manager_only branch in a throwaway Alpine container, create a veth in a dedicated network namespace, and try to drive a single dhcpcd-11 manager — scoped to that netns, observe-only, with a pinned duid/iaid — through an acquire + renew, reading results via the hook. Success criterion: one process, one netns, one pinned identity, one renewable lease, link untouched. That single experiment answers risks 1–4.

Adjacent (orthogonal) note

Separately, dhcpcd's habit of writing kernel sysctls on interface setup (promote_secondaries, IPv6 autoconf/accept_ra) fails on hosts where /proc/sys is mounted read-only — which breaks DHCP entirely there. That's a dhcpcd 10.x bug we should fix now, independent of the v11 question, but it's the same underlying theme: dhcpcd is an opinionated interface-manager and we use it as a passive mediator. Tracked separately.

What we want to clarify here

• Is the per-netns manager approach sound, or is there a fundamental blocker (esp. risk DHCP: send hostname in initial DISCOVER + set client identifier (option 61) #1)?
• Any prior art for running dhcpcd 11 scoped to a network namespace / per-container?
• Is there appetite to run the spike now (de-risk early) vs. defer until v11 nears GA?

[claymore666]

Status check, 2026-08-01: dhcpcd 11 has gone quiet — the risk has receded

Re-checked upstream against the open questions above. Short version: nothing
has moved toward dhcpcd 11 in two years, and our forced trigger is nowhere in
sight. The spike proposed in this thread should be deferred, not run now.

What upstream actually looks like today

Signal	State
Latest release	10.3.2, 2026-04-30 — exactly what we pin
11.x tag or release branch	none
manager_only branch	last commit 2024-06-15; now 303 commits behind master, 2 ahead
master activity (to 2026-06-30)	10.x maintenance — crash fixes, IPv6 temporary-address fixes, privsep hardening. No manager-mode or service-model work.
Upstream discussion #271	last comment 2026-05-01

The manager_only branch is the load-bearing fact. That branch was the v11
effort — the maintainer's "first pass at this" from 2023-12. It has not been
rebased once in two years and has drifted 303 commits behind. Whatever v11
eventually looks like, it will not look like what is on that branch.

The upstream thread's own trajectory points the same way: the last several
years of comments are sustained pushback on the design from multiple
downstreams (the per-interface model is what makes dhcpcd usable as a
dhclient drop-in under ifupdown), not progress toward it.

Effect on this roadmap

• Risk DHCP: send hostname in initial DISCOVER + set client identifier (option 61) #1 (netns scoping) — still the make-or-break unknown, still
  unaddressed upstream. Unchanged.
• Risk [C-1] udhcpc event-pipe goroutine leaks on Finish #5 (moving target) — this is now the dominant consideration.
  Prototyping against manager_only today means prototyping against a
  two-year-old snapshot that has already diverged past usefulness. The spike
  as written would produce an answer about code that will not ship.
• Timeline — the packaging picture confirms the "years, and we'll see it
  coming" read. Our base image's Alpine branch ships dhcpcd 10.3.2-r0, and
  so does edge. No Alpine branch carries 11. The only external trigger
  named in the opening post — the package repo dropping 10.x — has no line of
  sight at all.

One upstream change that is worth our attention

options: Introduce policy groups (2026-06-29) replaces the old bitmask array
that stored which options to request / remove / require with a generic policy
group structure, and edits dhcpcd.conf.5 accordingly. That is the config
surface our per-interface duid/iaid pinning rides on, and it will land in
whichever release cuts next.

This is a read-before-bump item, not a v11 item: review it when we next
move the pin, verify our generated dhcpcd.conf still expresses identity
pinning the same way, and confirm the apk-pin check catches the version move.

Disposition

Defer the spike. Re-check upstream at each base-image bump — that is the
only path by which this reaches us, and it is a path we control. The two
things that would change this answer:

1. an 11.x release or a rebased/active manager-mode branch appearing, or
2. our base image's Alpine branch dropping the 10.x package.

Neither is close. Leaving this thread open as the standing record.

[claymore666]

Closed: obsolete since v2.0.0

The question this thread asked, whether our process-per-interface model survives dhcpcd 11, no longer applies. Since v2.0.0 (2026-09-11) the plugin runs its own DHCP client library, dhcp-golib, in-process: one Go client per container interface for IPv4 and IPv6, with the DUID and IAID pinned per endpoint by the plugin itself. There is no dhcpcd in the 2.x image, so neither the dhcpcd 11 manager model nor the dhcpcd 10.x sysctl writes on read-only /proc/sys can reach us.

The 1.x line, which still ships dhcpcd 10.3.2, is maintenance only and ends at v1.9.0; it gets no base image bump that could pull in dhcpcd 11.

Roadmap for the 2.x line: Discussion #906.