Debating ifupdown replacements for Debian trixie

Debian does not have an official way to configure networking. Instead, it has four recommended ways to configure networking, one of which is the venerable ifupdown, which has been part of Debian since the turn of the century and is showing its age. A conversation about its maintainability and possible replacement with ifupdown‑ng has led to discussions about the default network-management tools for Debian "trixie" (Debian 13, which is expected in 2025) and beyond. No route to consensus has been found, yet.

Time to retire ifupdown?

The classic ifupdown is a set of custom scripts for configuring networking in Debian that became a project in its own right after the Debian "potato" release in 2000. Debian now has not one, but several implementations of ifupdown. In addition to ifupdown-ng, there is ifupdown2, which is an implementation in Python with a largely closed development model involving a private repository where changes are later pushed into a public repository. BusyBox has its own ifupdown implementation as well.

The network-tool debate had its genesis in an off-list discussion that included Martin-Éric Racine and Santiago Ruano Rincón, who is the current maintainer of ifupdown. Racine explained that the private discussion had been about "the plethora of unresolved issues with ifupdown and Santiago's limited time to devote to its maintenance". Racine said that Ruano Rincón had asked if he would be interested in maintaining ifupdown, and then had questioned the need for multiple implementations of it. The conclusion was that one implementation of ifupdown, maintained by a team, would be better than many implementations.

Racine had sent the conclusion to Daniel Gröber, one of the maintainers of ifupdown-ng. He forwarded snippets of the off-list conversation to debian-devel on July 7, saying that "I don't think we should be having this/these discussions in private". In the email, Gröber asked Ruano Rincón about the future maintenance of ifupdown and replacing it with ifupdown‑ng; he made the case that ifupdown-ng had a better core design, modern code, an active upstream, and a test suite. Overall, he said, ifupdown-ng has "the potential to fully replace ifupdown without breaking anyone's system doing it". He acknowledged that it was not fully compatible but he was working on it and was optimistic it could be.

Ruano Rincón replied that he had hit design issues with ifupdown and that it would make sense to focus efforts on ifupdown‑ng as a replacement, but only once it was a drop-in replacement for ifupdown, and it is not there yet. He ruled out ifupdown2 as the replacement due to its Python dependencies, lack of upstream community, and failure to support basics like DHCP for IPv6. He also asked for guidance on an unresolved discussion that began in June 2023 about changing the recommended DHCP client from ISC DHCP (which is no longer being developed) to dhcpcd.

On July 9, Racine followed up to say that he had looked at ifupdown-ng and that its syntax was not a drop-in replacement for ifupdown. Marco d'Itri agreed: "either it's drop-in compatible or we may as well switch the default to NM [NetworkManager] and/or systemd‑networkd".

Popping open Pandora's box

After the topic of replacing ifupdown had been broached by d'Itri, Matthias Urlichs said: "Well, here's a heretical thought: why don't we do that anyway, at least for new installations?" That sparked a lively discussion about the idea. Simon McVittie noted that Debian was already there to an extent. New laptop and desktop installs default to NetworkManager, and he argued that systemd‑networkd would be a better choice for server and embedded installations. The need for Debian to have its own network tools had passed, he said, "and we now have non‑distro‑specific network management components that can do just as good a job (if not better)". Even better, systemd‑networkd and NetworkManager were used "outside the Debian bubble", and that meant many more people were responsible for their maintenance.

A switch to NetworkManager or systemd‑networkd, Michael Biebl pointed out, would require modifying the Debian installer. Lukas Märdian made a pitch for adopting Netplan, a project sponsored by Canonical for generating network configurations for multiple tools, such as systemd‑networkd or NetworkManager, from a YAML description of the network interfaces. He said support for Netplan was "pretty close" to being merged into the Debian installer: "Netplan should be considered a unification layer on top of those networking daemons, which allows Debian as a project to use common language around networking."

Simon Richter complained that systemd's roadmap was unclear and that support for features they depend on "could be discontinued at any moment, and it would not be the first time a feature Debian relied on was removed". Debian is a volunteer project that cannot afford to be in "perpetual firefighting mode". He asked if it would be possible to put in place a process to deal with breaking changes, and suggested that "a long-term support commitment from upstream" would significantly reduce the effort needed to plan for those changes.

What's wrong with ifupdown?

Gröber later asked for specifics on problems with ifupdown's design or maintenance. Ruano Rincón pointed to design problems with ifupdown such as the one described in this bug report. The ifupdown utility refuses to configure IPv4 on an interface if there is a configuration error for IPv6. That did not convince Gröber, who said that he had only seen two technical arguments against ifupdown and wanted to know what problems ifupdown causes that require removing "all traces" of it from a minimal Debian install.

Josh Triplett responded that there was a simple answer: having multiple network tools "trying to poke at the same network devices, *or* network tools working around each other carefully" should not be the default. Installers should treat network-management tools as mutually exclusive, and allow users to install more than one later if the user desired.

What about Netplan?

In early August, Märdian led a birds-of-a-feather (BoF) session at DebConf 2024 about how to "improve and homogenize" the networking landscape in Debian. He presented three scenarios, found in his slides, dubbed "Status Quo++", "Minimized", and "Universal", along with his summary of the work that would still need to be done to make them possible. The status quo scenario he proposed involved transitioning to ifupdown‑ng, which would require switching to dhcpcd-base and making ifupdown‑ng a drop-in replacement for ifupdown. The minimized scenario involved switching to systemd‑networkd for base and server images, or NetworkManager for desktop images. That would require work on the Debian installer, migrating the existing ifupdown configurations, dropping ifupdown, and enabling autopkgtest support for those packages.

Finally, the universal scenario would keep ifupdown[-ng] in the base installation, NetworkManager for desktop installs, and enable systemd‑networkd on server installs. On top of those, it would add Netplan as "a common configuration interface across variants". Users could fall back to any of the underlying tools without fussing with Netplan configuration if desired. The only remaining work for this, according to the slides, would be for ftpmasters to raise the priority of the netplan-generator package so that it is installed by default.

Private to public

During the BoF, Märdian suggested setting a deadline for a decision of "six to eight weeks". He also committed to writing an email to debian-devel that summarized the BoF discussion for those not at DebConf. That did not quite go as planned. Before starting a public discussion on debian-devel, he had privately emailed networking maintainers to gauge their opinions. On August 20, Gröber forwarded parts of Märdian's email to debian-devel before Märdian took the discussion public.

In the email, Märdian had proposed a compromise that would make systemd-networkd the recommended networking tool for minimal installations. Either ifupdown, or ifupdown-ng if it could be made drop-in compatible, would be a fallback and remain available for existing installations that were upgrading to trixie. Then ifupdown[-ng] would be dropped in "forky", the release following trixie. Märdian had added, "I'd like to avoid drama and calling the CTTE [Debian's technical committee] to make a decision on our behalf, but rather find a compromise between us networking maintainers."

Gröber, reasonably, said that he was not interested in doing the work of getting ifupdown-ng ready to be the default in trixie if it would be removed in forky. He also said that the choice of network-configuration tools should be based on the wants of the majority of Debian users, and not a technical decision among maintainers. He suggested an informal vote to gauge the preference of Debian developers and the wider community, and asked the list how similar decisions had been made in the past. If a vote showed that he was "alone in wanting Debian to retain [its] identity as Debian" he would step aside on the matter.

Märdian followed up and said that it was fine for his points to be made public, but he wanted to add the parts that Gröber had dropped from the original mail. In his reply, he mentioned that he had formed a new Debian networking team after discussions at the BoF at DebConf that would "bundle resources and help each other out with critical maintenance & have a common channel for communications". However, no further details about that team and its membership were shared.

He said that the decision about networking tools needed to be made by developers, "because someone needs to do the work":

Otherwise, we would be suffering the same way we did with classic ifupdown in the past years, as it's becoming harder and harder to maintain. We need a healthy upstream project and people willing to do the actual maintenance work in Debian.

To decide or not to decide

Gröber replied that building a community around networking in Debian should happen in public. "Who knows the publicity might just spawn some (much needed) new contributors." He was "a bit peeved" that the Pandora's Box of removing ifupdown had been opened because it impacted his ability to find people willing to work on preserving it. It was also wrong to put time pressure on deciding, he said, when release dates for trixie were not even announced. "Remember: it's done when it's done. This is a big decision let's do it right."

The discussion continued with a number of people chiming in with support for their favored networking tools. It also featured a fair amount of lobbying for Netplan by Märdian, though some were not convinced. For that matter, no consensus or plan of action was reached—nor even an agreement that one was actually needed. Thomas Goirand strongly opposed the idea that it should be decided by a vote, though. "We do not need another systemd vote". He recommended involving Debian's technical committee "if we can't agree reasonably, rather than yet-another-GR".

Ruano Rincón came back to the conversation on September 8, and thanked Märdian for taking care of the topic. He reiterated his interest in replacing ifupdown with ifupdown-ng as soon as possible. The choice of a default network-configuration tool was a secondary question, but he suggested that Debian would benefit from "moving to something shared with other distros". He said that providing users with a more modern, better-maintained tool was more important than retaining Debian's identity through its choice of networking tool.

But he was unprepared to give a recommendation about the right tool to choose. He had not had time to do a thorough review and comparison of the tools, so he was not ready to give his opinion on how to move forward yet. "Just please, let's make this the last thread about the default network stack in future Debian releases."

Thus far, there is no further discussion on the topic and the only consensus seems to be that "classic" ifupdown's days are numbered. Just how numbered, and what will replace it, seem no clearer today than when the discussions began in July. One hopes that the final outcome will be a clear consensus on Debian's default networking configuration tool or tools, as well as who makes that choice in the future.