IPv4 address exhaustion is a key driver of the 1.58 release of NetworkManager, the open-source Linux network configuration tool suite.
Networking is core to any operating system, and when it comes to Linux, it’s actually a combination of several key components. The Linux kernel handles the data plane, moving packets, and holding live device state. NetworkManager is the network configuration service, operating as the control plane, deciding what a device’s configuration should be.
NetworkManager 1.58 was released this week, following more than five months of development and 407 commits since version 1.56. The release covers three areas: expanded support for IPv6-only networks, a set of Wi-Fi management updates, and a round of security hardening.
IPv4 address exhaustion remains the pressure behind the first of those areas, pushing more networks toward IPv6-only operation every year.
“More networks, mobile carriers, cloud providers, and anyone squeezed by IPv4 exhaustion are running IPv6-only by default,” Chris Van Hoof, director of Linux engineering, platform enablement at Red Hat, told Network World.
Advancing IPv6-only support
Dual stack networking, running IPv4 and IPv6 in parallel, has been the default IPv6 transition strategy for years. Dual stack networking, however, has a structural problem in that it still requires an IPv4 address on every device, so it does nothing to relieve address exhaustion pressure.
An alternative model called IPv6-mostly addresses that gap. It is defined in RFC 8925, “IPv6-Only-Preferred Option for DHCPv4,” and lets capable clients drop IPv4 entirely while legacy hosts that still need it keep receiving it on the same network segment.
“NetworkManager can also now auto-signal RFC 8925’s IPv6-only-preferred option, telling the network a host is fine skipping an IPv4 lease entirely,” Van Hoof said.
For the traffic that still needs IPv4, NetworkManager 1.58 adds support for CLAT, short for customer-side translator. CLAT is the client-side half of 464XLAT, a mechanism defined in RFC 6877, “464XLAT: Combination of Stateful and Stateless Translation.”
464XLAT pairs CLAT on the endpoint, which performs stateless header translation, with a stateful NAT64 translator on the provider side, letting IPv4-only apps keep functioning on a network that has no IPv4 of its own.
“CLAT is the translation layer that lets legacy IPv4-only apps and services keep working on those networks without bolt-on middleware,” Van Hoof said.
Wi-Fi management updates
NetworkManager 1.58 also brings a set of changes to how the daemon handles Wi-Fi connections and configuration.
- Band selection: The band property of Wi-Fi connections now accepts a 6GHz value, and a Wi-Fi scan run through nmcli, NetworkManager’s command line tool, now shows each access point’s band as well.
- Credential handling: WPS credentials with a 64 character hex PSK are now accepted, matching what some access points return.
- Text interface improvements: nmtui, NetworkManager’s menu driven text interface, picked up several usability additions. A new device select button lets you choose a physical interface from a list instead of typing its name. The activation screen gained a rescan Wi-Fi button, and secret prompts now include a show password checkbox. There is also a share QR code option, mirroring the existing nmcli device wifi show-password command.
Security hardening
The release fixes vulnerabilities and tightens several defaults tied to DHCP handling and connection permissions.
- CVE-2026-10805: Hostnames and MUD URLs are now validated before being written to the dhclient configuration file, rejecting characters that could alter the config syntax.
- DHCPv4 client fix: An out-of-bounds read in the internal DHCPv4 client, triggerable by an on-link attacker with a malformed UDP packet, has been fixed.
- Router option validation: The internal DHCPv4 client now ignores DHCP option 3, the Router option, when a lease also contains option 121, the Classless Static Route option, following the recommendation in RFC 3442.
- Permission checks and deprecations: For private connections that restrict access to specific users, NetworkManager now verifies that the user can access the referenced 802.1X certificates and keys.
Tunneling and automation updates
Two smaller but practical additions round out this release: a new tunnel type for virtualized networks, and a fix that closes a gap in how NetworkManager’s state survives a reboot.
NetworkManager 1.58 also adds support for creating and managing GENEVE tunnel interfaces. GENEVE, short for Generic Network Virtualization Encapsulation, is a tunneling protocol that wraps Ethernet frames inside UDP packets, letting virtualized or overlay networks run on top of physical Layer 3 infrastructure. It shows up mainly in virtualization and cloud environments, where a hypervisor or container networking layer needs to build a virtual network segment across physical hosts. Previously, NetworkManager could not create or manage these interfaces directly.
The release also adds persisted managed state. NetworkManager tracks whether it is responsible for a given network device, a setting called its managed state. Until now, that setting reset on every reboot, so provisioning tools had to reapply it each time a system restarted. NetworkManager 1.58 lets the managed state survive a reboot when it is set through nmcli or the D-Bus API.
“It’s a small change but closes a real automation gap: Provisioning tools and cloud-init style workflows can set a device’s state once via D-Bus or nmcli and trust it survives a reboot, instead of reapplying config every time,” Van Hoof said.
