F45 Change Proposal: IPv6-Mostly Support In Network Manager [SelfContained]

Project Discussion Change Proposals
, ,
1

IPv6-Mostly Support In Network Manager

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

Enable by default support for IPv6-mostly networks in NetworkManager.

Owner :open_book:

Detailed Description :open_book:

Dual-stack networks, where IPv4 and IPv6 run in parallel, are currently the most common transition mechanism to IPv6. However, they don’t solve the problem of the IPv4 address exhaustion; furthermore, the availability of IPv4 on every host masks problems with IPv6 and provides very little incentive to fully move to IPv6.

A new architecture is emerging as an alternative to dual stack: IPv6-mostly. RFC 8925 describes an IPv6-mostly network as:
A network that provides NAT64 (possibly with DNS64) service as well as IPv4 connectivity and allows the coexistence of IPv6-only, dual-stack, and IPv4-only hosts on the same segment. Such a deployment scenario allows operators to incrementally turn off IPv4 on end hosts, while still providing IPv4 to devices that require IPv4 to operate. But IPv6-only-capable devices need not be assigned IPv4 addresses.
The key components of a IPv6-mostly network are:

  • DHCPv4 option 108 (IPv6-only preferred - RFC 8925). An IPv6-mostly network advertises this option. If the client supports and receives this option, it will go IPv6-only, disabling IPv4 configuration. This option serves as the signal for supporting clients to transition to IPv6-only mode.
  • 464XLAT (RFC 6877). This architecture provides IPv4 connectivity to hosts in a IPv6-only network. It works by implementing a double translation: on the client a CLAT (Customer-side translator) converts IPv4 packets to IPv6; on the network side a PLAT (Provider-side translator) uses NAT64 to convert those packets back to IPv4 before they are delivered to the v4 Internet.
  • PREF64 option (RFC8781). The network includes this option in Router Advertisement messages to communicate the prefix used by the NAT64 gateway available in the network.
    With this change, NetworkManager will enable automatically the

handling of option 108, CLAT and PREF64. As a result, when operating

in a IPv6-mostly network, it will behave as a IPv6-only host without

getting a DHCPv4 lease. Applications that need to reach the v4 Internet will still continue to work because of DNS64 and/or NAT64.

On networks not advertising option 108 NetworkManager will continue to configure native IPv4 addressing.

Feedback :open_book:

N/A

Benefit to Fedora :open_book:

By enabling option 108 and CLAT, Fedora’s networking stack will be

compliant with modern Internet standards. This puts Fedora on par with

other major operating systems that already support and enable these

technologies such as Android, macOS and (recently) Windows.

Option 108 allows network administrators to conserve scarce IPv4

address pools, without the need of creating separate segments for IPv4

and IPv6 clients.

CLAT ensures that applications relying on AF_INET sockets or hardcoded

IPv4 literals continue to function transparently even when the host

only has IPv6 connectivity.

Scope :open_book:

  • Proposal owners: Set the default value for option ipv4.clat to auto, either at build time or via a configuration snippet in /usr. This enables the automatism that starts CLAT based on PREF64, and also enables the handling of option 108.
  • Other developers: N/A
  • Release engineering: N/A
  • Policies and guidelines: N/A
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact :open_book:

There is no manual configuration or data migration needed. The change will be transparent to users.

Early Testing (Optional) :open_book:

N/A

How To Test :open_book:

This change can only be tested on an IPv6-mostly network with DHCPv4 option 108, NAT64 and PREF64. Such a network can be set up using equipment that supports those technologies, but also by configuring a Linux router with radvd, dhcpd, and a NAT64 implementation such as jool or tayga.

This feature is tested as part of the [Making sure you're not a bot! NetworkManager-ci] project using network namespaces with radvd, dhcpd and tayga.

User Experience :open_book:

When connected to a IPv6-mostly network (with option 108, NAT64 and PREF64), the host will get a public IPv6 and a private CLAT IPv4 address in the 192.0.0.0-192.0.0.7 range.

Native IPv6 connectivity will be used for most of the traffic. If there are applications connecting by name to an IPv4-only server, the DNS64 server will return a synthetic AAAA entry that directs the communication to the NAT64 gateway. The CLAT instance started by NetworkManager will be used to convert the remaining IPv4 traffic to IPv6, for example traffic generated by applications using IPv4 literals.

All of this will be transparent to the user.

Dependencies :open_book:

None

Contingency Plan :open_book:

  • Contingency mechanism: Revert the configuration and disable CLAT and option 108
  • Contingency deadline: Beta freeze
  • Blocks release? No

Documentation :open_book:

The configuration options involved are described in the upstream documentation:

Release Notes :open_book:

This change should be mentioned in the Releases Notes.

Last edited by @zbyszek 2026-04-04T09:48:07Z

Last edited by @zbyszek 2026-04-04T09:48:07Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

That seems optimistic at best, to me, and potentially out-and-out false for any users who don’t fit the narrow “strictly client-mode internet access” model that’s (unless I’m misinterpreting) being assumed for the endusers discussed here.

RFC 6877 (464XLAT) is careful to point out:

464XLAT is not a one-for-one replacement of full IPv4 functionality. The 464XLAT architecture only supports IPv4 in the client-server model, where the server has a global IPv4 address. This means it is not fit for IPv4 peer-to-peer communication or inbound IPv4 connections. 464XLAT builds on IPv6 transport and includes full any-to-any IPv6 communication.

Which means that any users running any sort of services on their local machines, either for local-subnet connectivity or exposed to the internet via IPv4 port-forwarding in their gateway router, will find the IPv4 reachability of their local servers suddenly cut off if their system decides to activate IPv6-Mostly mode and limit IPv4 connectivity to translated outbound connections… correct?

What I mean is:

  1. I currently have a home network built around a non-routable IPv4 subnet (192.168.x/24), managed by the DHCP server in my broadband gateway router.

  2. I can currently mount the network shares from my fileserver (192.168.x.100) on my desktop (192.168.x.103) by making an SFTP request to sftp://192.168.x.100/; in the new 464XLAT / IPv6-Mostly world, are local systems still assigned IPv4 non-routable addresses, or are those replaced with CLAT addresses which can’t be connected to remotely?

  3. I currently have a selection of ports (80, 443, some other protocols) port-forwarded through my gateway router to that fileserver I mentioned, so that the fileserver’s webserver is accessible from the public internet via the gateway router’s single public IPv4 address. The gateway forwards the requests to the local IPv4 address of the fileserver (192.168.x.100), and I have a no-ip dynamic DNS hostname tracking that public IPv4 address so that I can visit https://whatever-my-hostname-is.ddns.net/ to reach my fileserver’s web interface from anywhere. If that local IPv4 address goes away, presumably the port-forwards go away with it, meaning I lose connectivity to my home services via the DDNS hostname, correct?

Don’t get me wrong, these are all solvable problems. Configuring Avahi to advertise services on the local network as IPv6 addresses means I can replace sftp://192.168.x.100/ with sftp://my-fileserver.local/ for internal SSH connections. Creating a no-ip DDNS hostname with an AAAA record means I can track my local IPv6 address instead of the IPv4 address, and have https://whatever-my-ipv6-hostname-is.ddns.net/ still connect to the webserver via IPv6.

But,

  • configuring Avahi
  • and eliminating all instances of 192.168.x.x addresses in my local scripts/configurations,
  • and replacing IPv4 DDNS hostnames with IPv6 DDNS hostnames (no-ip doesn’t support having AA and AAAA records for the same hostname, so either a new one has to be created for the IPv6 address, or the AA record has to be deleted when migrating a hostname to IPv6)
  • and updating the fileserver’s Let’s Encrypt configs to obtain SSL certificates for the new hostname, if it does change
  • and updating the forwarding rules on my gateway router

…none of that sounds especially “transparent to users [whose networking needs go beyond strictly client-only, outbound connectivity]”, does it?

4

Is this what is called carrier-grade-ipv6-NAT?
I thought this was known to be unusable in practice for normal users.

5

That seems optimistic at best, to me, and potentially out-and-out false for any users who don’t fit the narrow “strictly client-mode internet access” model that’s (unless I’m misinterpreting) being assumed for the endusers discussed here.

If a network like yours is based on IPv4 and has IPv4-only services that would fail when running IPv6-only, it is not suitable for IPv6-mostly, and it should not advertise option 108. Without receiving option 108, clients will not do CLAT and will continue to get native IPv4 connectivity as before.

In other words, the “transparent to users” statement assumes that the network is properly configured and only sends option 108 when the it is really IPv6-only capable. It is up to the network administrator to decide when this is the case; DHCPv4 servers do not send option 108 unless it is explicitly configured.

Therefore, unless you plan to change your broadband gateway configuration to enable option 108, this change doesn’t affect you.

6

I think you are referring to NAT66, which is the IPv6 equivalent of IPv4 NAT and is implemented by some vendors, but is not a IETF standard (there is also a standardized NPTv6, a stateless translator between IPv6 prefixes, but it is not always usable because it requires that the two prefixes have the same length).

It is different from NAT64, which translates between IPv6 and IPv4, and has been used by many mobile network operators for at least 10 years.

7

Indeed, T-Mobile US was one of the first to do this. They rolled out 464XLAT over 12 years ago and converted their network to be a “mostly IPv6” network by 2016.

Exciting to see NetworkManager enable automatic handling for these kinds of networks.

8

This change proposal has now been submitted to FESCo with ticket #3578 for voting.

To find out more, please visit our Changes Policy documentation.

9

I think the proposal makes sense.

FWIW, I checked if systemd-networkd supports this, and it seems support was added back in 2023 (server side network/dhcp-server: allow to configure IPv6 only preferred option ¡ systemd/systemd@34bea0a ¡ GitHub + sd-dhcp-server: support IPv6 only mode ¡ systemd/systemd@14bd102 ¡ GitHub, client side sd-dhcp-client: support IPv6 only mode ¡ systemd/systemd@a91b888 ¡ GitHub). I never tested this, but it seems that the client will prefer IPv6 if configured on the network.

10

sytstemd supports option 108 but doesn’t support CLAT. Without CLAT, the IPv6-only mode can’t be enabled by default because it would break IPv4-only applications:

NetworkManager uses a BPF program to implement the CLAT, however there are some recent patches to add support directly in the kernel; when they are merged it will be easier to add support to systemd-networkd:

[RFC net-next 00/15] Introducing ipxlat: a stateless IPv4/IPv6 translation device

2 Likes
11

This change has been approved by FESCo and will be included in Fedora Linux 45.
To find out more about how our changes policy works, please visit our docs site.

FESCo Issue: Making sure you're not a bot!