The old promise of IPv6 migration was supposed to be temporary inconvenience followed by cleaner addressing. The real world chose something messier. Dual stack worked well enough, so many networks kept both IPv4 and IPv6 alive, handed every host an IPv4 address anyway, and let broken IPv6 paths hide behind fallback behavior.

Red Hat Developer published a useful piece by Beniamino Galvani on July 8 showing how NetworkManager 1.58, shipping with Red Hat Enterprise Linux 10.3, supports an IPv6-mostly architecture with client-side translation and eBPF. The interesting part is not a new slogan for IPv6. It is the client plumbing that makes the migration less theoretical.

IPv6-mostly is compelling because it does not ask every device to become modern on the same day. It lets capable clients stop consuming IPv4 while legacy devices keep breathing.

Dual Stack Became the Parking Lot

Dual stack is useful as a transition mechanism, but it has a habit of becoming the destination. If every endpoint keeps IPv4, the address-pressure problem remains. If every application can fall back to IPv4, IPv6 failures can go unnoticed. The network looks healthy because users keep connecting, while the IPv6 path quietly avoids accountability.

IPv6-mostly changes the incentive. A modern client can receive a signal that says IPv6-only is preferred on this interface, stop requesting ordinary IPv4 service, and still reach IPv4-only destinations through translation. Older clients that do not understand the signal can continue using IPv4 on the same segment. That creates a practical slope from dual stack toward IPv6-only, instead of a cliff.

old shape: every host keeps IPv4 + IPv6
better shape: capable hosts prefer IPv6-only
compatibility: legacy hosts keep IPv4
escape hatch: CLAT reaches IPv4-only endpoints
The migration gets interesting when IPv4 becomes compatibility plumbing instead of the default contract.

The Signals Matter

The Red Hat article walks through the standards pieces behind the model. DHCPv4 Option 108, defined by RFC 8925, lets a network advertise IPv6-only preferred behavior. DNS64 and NAT64 handle the common case where a client asks for a name and the network synthesizes an IPv6 route to an IPv4 service. RFC 6877's 464XLAT covers the awkward cases: applications that use literal IPv4 addresses or older socket assumptions.

That last part is why CLAT matters. The customer-side translator runs on the endpoint and turns the application's IPv4 packets into IPv6 packets before they cross the IPv6-only side of the network. A provider-side NAT64 translator can then finish the trip to the IPv4 internet. From the application's point of view, the old IPv4 habit still works. From the network's point of view, the client no longer needs to consume a normal IPv4 address.

Why eBPF Is the Sharp Part

NetworkManager's implementation is notable because the translation work is pushed into the kernel with eBPF. That avoids a userspace packet translation loop and the context switching that would come with it. For a feature that sits on the data path, that detail matters. Migration features fail when they feel slower, fragile, or too special to operate.

The mechanics are not just a simple header swap. The CLAT path has to translate IPv4 and IPv6 headers, adjust transport checksums, handle fragmentation, and deal with ICMP error messages so ordinary tools such as ping and traceroute remain useful. Red Hat's write-up notes that the eBPF program performs incremental checksum updates instead of recalculating entire payloads, and it keeps counters for traffic types and dropped packets so debugging is not completely blind.

Operational note: a transparent translation layer still needs observability. If packets disappear inside the kernel, operators need counters and logs that explain where the compatibility path failed.

This Is Really About Shrinking Default IPv4

The easy way to misunderstand IPv6-mostly is to treat it as another translation trick. The better reading is that it changes which protocol gets to be ordinary. IPv4 is still there, but it becomes a compatibility service for devices and applications that need it. IPv6 becomes the normal path for capable clients.

That distinction matters for fleet operators. Every address family that remains mandatory is another surface for configuration, policy, troubleshooting, firewalling, asset inventory, and incident response. Keeping IPv4 everywhere because a few things still need it is expensive in a quiet way. IPv6-mostly tries to localize that expense.

  • For network teams: it creates an incremental path instead of an all-at-once cutover.
  • For Linux clients: NetworkManager can own more of the transition behavior at the connection level.
  • For application compatibility: CLAT gives old IPv4 assumptions a controlled bridge.
  • For operators: eBPF keeps the translation close to the packet path while still exposing counters for debugging.

The Takeaway

NetworkManager's IPv6-mostly work is the kind of systems feature that will not look dramatic in a product screenshot. Good. The point is to make the network less dramatic. A host joins a segment, learns that IPv6-only is preferred, uses CLAT when old IPv4 behavior leaks through, and lets the network reserve IPv4 addresses for the clients that genuinely still need them.

That is a more honest migration model than pretending dual stack automatically ages into IPv6-only. It does not. Someone has to remove IPv4 from the default path one client at a time, without breaking the applications that still assume the old world.

Putting CLAT into NetworkManager with eBPF is a small but important move in that direction. It turns IPv6-mostly from an operator diagram into client behavior Linux can actually run.

Sources