The following is a transcription of the Networking BoF session held at DebConf 2025, featuring speakers Lukas Märdian and Daniel Gröber (dxld), along with participation from other attendees.

Hallucinations-Reviewed-By: dxld

Lukas: Welcome to the Networking BoF. Hi everyone. I'm Lukas and I co-organized the BoF with Daniel. It's our inaugural BoF for the networking team that we're forming. We discussed it briefly last year, but this time we want to really invite people to join the team with their packages and ideas. I maintain the network stack in Ubuntu and the netplan.io package in Debian.

Daniel: I have a project to bring IPv6-only support into Linux upstream and I'm trying to bring that to Debian. I've been a DD for about a year or two and I'm trying to get things more organized. You might have seen my discussions with Lukas on the mailing list regarding ifupdown and changing defaults. I'm also involved with ifupdown-ng, a rewrite of the traditional tool.

Lukas: We have a few bullet points. The first is team building. Our current idea is to have IRC and a mailing list. Does anyone have thoughts on the status or which packages we are talking about?

Attendee: Can you describe the current status? Which packages, and have you contacted the maintainers? How many people do we need for a viable team?

Daniel: We don't necessarily need a specific set of packages yet, just people who care about networking. On our wiki, we have Andre, Lukas, myself, and Santiago Ruano Rincón (who is here). Santiago is the maintainer for the traditional ifupdown.

Lukas: If you want to be involved, please add yourself to the Wiki or the Package Tracker. There is a team page on tracker.debian.org/teams/networking. Regarding tools, NetworkManager is in the Utopia team and systemd-networkd is part of the systemd team. We work closely with them, but they have their own maintainers.

Daniel: It's important for Trixie to tackle critical bugs. I've been looking at ifupdown-ng compatibility. The last upstream release was a while ago, but there was a commit in May.

Attendee: I haven't used ifupdown since 2015. Has much changed?

Daniel: There are quality-of-life improvements, but nothing you can't live without. The problem is manpower. We have to balance fixing important things without overwhelming ourselves.

Attendee: Is there a valid assumption that ifupdown will continue?

Daniel: People happy with ifupdown are the ones we don't hear from. It works and leaves the system alone. It would be a mistake to just rip it out. My vision for ifupdown-ng is to implement the missing features from the original and eventually migrate.

Lukas: The landscape is scattered. Desktop uses NetworkManager, cloud uses systemd-networkd with Netplan. We have three different ways of doing things. Last year there was no consensus on unifying them.

Attendee: If people want to maintain the "Debian way," they should. But it sounds like there is a reluctance to maintain the classic ifupdown.

Daniel: I use it and think it's a good design for certain use cases, like routers. I'm willing to handle bugs, but the pile is huge.

Lukas: On the mailing list, many said they just purge ifupdown and use systemd-networkd because it's already there. For new installations, enabling networkd by default might be better as we get upstream maintenance "for free."

Attendee: What about ifupdown2?

Lukas: It's written in Python. The Debian community is reluctant to pull Python into the base system because of the size. ifupdown-ng is in C, which is a better argument for the base system.

Daniel: I've reviewed ifupdown-ng code. It's a cleaner codebase with a library for parsing config, but it still has that "shell script" architecture where it's hard to have a data model of what's happening. One major issue with the original ifupdown is you can't change a setting without deconfiguring and reconfiguring the whole interface, which drops SSH connections.

Lukas: We discussed a "generational conflict" during a hike. A problem is systemd-networkd wants to manage all routes. If another tool like PPP or Pacemaker adds a route, networkd might kick it out on restart.

Daniel: We want to coordinate with networkd to provide override configurations. If a system has the classic stack, we should set toggles like ManageForeignRoutes=false.

Attendee: Pacemaker has this issue. It manages a virtual IP and networkd might remove it. We need a generic solution for multiple things touching the network.

Lukas: We could have a package that provides a drop-in config for networkd to disable that behavior, which packages like ifupdown or pacemaker could depend on.

Lukas: Another point: Debian Installer (DI) still writes ifupdown config for the loopback interface even on desktop installs. NetworkManager can handle loopback fine. I created a merge request against DI to drop that.

Lukas: We are out of time. Action items: we need to file a bug to create a proper debian-networking mailing list. Please join the IRC channel #debian-networking on OFTC.

Daniel: Everyone, please sign up for the tracker so we can reach you once the list is created.

Lukas: Thanks everyone. I hope we did some bonding here—maybe we can bond those interfaces in the future. [^1]