464XLAT support

[SoniEx2]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Linux-based OSes don't come with 464XLAT support out of the box, meanwhile Windows does. Mobile phones support it out of the box because mobile networks told them to. While it is unlikely anyone uses systemd-networkd in their CPE/router, it would also be nice to be able to have an entirely IPv6-only LAN. This would help prepare systemd-networkd for the eventual deprecation of RFC 1918 and global routing of the 10/8, 172.16/12 and 192.168/16 subnets. It also has some minor advantages when merging multiple LANs, as the risk of ULA conflicts is significantly lower than the risk of 1918 conflicts.

Describe the solution you'd like
A clear and concise description of what you want to happen.

464XLAT CLAT support, out of the box.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

N/A

The systemd version you checked that didn't have the feature you are asking for

systemd 251, and also systemd-git

[yuwata]

Could you elaborate more? I am not familiar with 464XLAT.
Could you suggest a setting format to support the feature?
Also, could you provide a way to support that feature with another tools, e.g. ip command?

[SoniEx2]

464XLAT is an IPv4 tunnel over IPv6-only NAT64. This does require setting up a tunnel, so it's not possible with just ip commands.

See RFC 8683.

It is currently not possible to deploy 464XLAT on an enterprise network, mainly due to lack of support on desktop/server Linux.

[pemensik]

I think this is related to #24624 and ipv6-mostly RIPE presentation.

[pemensik]

A link to video of the presentation: https://ripe85.ripe.net/programme/meeting-plan/ipv6-wg/

[alexhaydock]

Some useful context:

464XLAT/CLAT (RFC 6877) should be deployed by clients either:

1. When they receive a DHCP Option 108 v6-only-preferred reply from a DHCPv4 server (RFC 8925).
2. When no DHCPv4 reply is received at all, but v6 connectivity is enabled.

When either of the above conditions is true, the client should look to discover a NAT64 prefix to configure itself with 464XLAT either via the pref64 header in IPv6 Router Advertisements (RFC 8781) or by discovering it via DNS64 using RFC 7050.

macOS, and indeed Apple's entire product stack, are already capable of doing this today using the exact structure demonstrated above. Windows is capable of the same, though subject to an unfortunate limitation of this only being on WWAN connections.

On Linux, this can currently be done by setting up a CLAT daemon and configuring it, such as clatd, but adoption in distribution repositories is poor, and doesn't offer a hands-off user experience for anyone connecting to a v6-mostly network of the kind which will only become more common.

I'd like to see systemd-enabled hosts capable of the same level of polished user experience as Apple provides when connecting to v6-mostly and v6-only networks.

[zajdee]

Now that #29472 is merged, CLAT is the last part missing in supporting of the IPv6-mostly networks.

[Leseratte10]

Just updated my Arch Linux box to the latest systemd (v255) with #29472 (RFC8925 support) included, I noticed a small issue related to the missing 464XLAT support.

I'm not sure if I'm misunderstanding something (which may well be the case) or if my issue is caused by an Arch Linux oddity, in that case I apologize for wasting your time.

RFC 8925, which defines the new "IPv6 only" parameter, describes a "host [that is] capable of operating in IPv6 only mode" (which is signalled by this new parameter) to be a host that either only has IPv6-only-capable applications, or a host that's running a 464XLAT.

Quote from RFC:

IPv6-only-capable host: A host that does not require an IPv4 address and can operate on IPv6-only networks. More precisely, IPv6-only capability is specific to a given interface of the host: if some applications on a host require IPv4 and the 464XLAT CLAT (customer-side translator) [RFC6877] is only enabled on one interface, the host is IPv6-only capable if connected to a NAT64 network via that interface.

That definition makes it pretty clear that a host that has applications that require IPv4 (which isn't that uncommon even in 2023, sadly) but without a working and enabled 464XLAT with a NAT64 prefix either manually configured or automatically learned through RFC 7050 (DNS), RFC 7225 (PCP) or RFC 8781 (RA/PREF64) is not to be considered an "IPv6-only capable host".

The IPv6-only parameter is intended for a network where there's both clients like Android and iOS (that auto-deploy their own 464XLAT when on an IPv6-only network) and clients like Windows, OSX, Linux, whatever that don't auto-deploy a 464XLAT and thus need native IPv4 connectivity, so that only clients in that 2nd group will receive an IPv4 address over DHCP.

My network's DHCPv4 server has been running with the "IPv6-only" flag for a long time (including a NAT64 gateway) - to ensure that smartphones and tablets don't waste IPv4s they don't need. This means, that my Arch Linux box with a pretty standard network config (IPv4 enabled, IPv6 enabled, done) did no longer receive an IPv4 address using DHCP after this systemd update was installed. However, there's no code in systemd (yet) to automatically trigger and setup a 464XLAT in this case (as evidenced by this particular issue #23674 still being open).

This means that while my IPv6-capable applications on the box were able to access the internet as usual (either using native IPv6 or using DNS64/NAT64), any applications that require IPv4 stopped working after this update until I manually set IPv6OnlyMode=no in the network config.

Is there anything I could be missing or anything I did wrong? To me, this looks like systemd isn't implementing RFC8925 correctly since there's no automatic 464XLAT as required by the RFC, and this issue about the missing 464XLAT should have been solved / implemented before the IPv6-only flag was enabled / handled by default.

In my opinion (but this could be wrong, I'm not an expert), the default value of IPv6OnlyMode should be set to False (so the admin has to explicitly enable it), and only have the default changed to True once systemd has support for 464XLAT, because there's no way for systemd to know (other than explicit user configuration) if there's any IPv4-only applications on the machine.

[silkeh]

@Leseratte10:

That definition makes it pretty clear that a host that has applications that require IPv4 (which isn't that uncommon even in 2023, sadly) but without a working and enabled 464XLAT with a NAT64 prefix either manually configured or automatically learned through RFC 7050 (DNS), RFC 7225 (PCP) or RFC 8781 (RA/PREF64) is not to be considered an "IPv6-only capable host".

This honestly seems like an issue for your distribution. They manage the packages in the repository and can change the systemd defaults based on the software in the repository. The distro is also in charge of software integration, which seems to be your issue. How would the systemd project know that you have or can install applications that rely on IPv4 connectivity?

clients like Windows, OSX, Linux, whatever that don't auto-deploy a 464XLAT and thus need native IPv4 connectivity

Most of my deployments definitely don't need native IPv4 connectivity. Applications that actually require native IPv4 connectivity (and don't work with DNS64/NAT64) are fairly rare in my experience. Additionally, I don't know of any case where the application actually needs native IPv4 connectivity, instead of it being a bug in the software. This is especially the case for servers, where it is even relatively easy to run systems without connectivity to the IPv4 internet entirely (so no DNS64/NAT64).

[Leseratte10]

Okay, that does kinda make sense. On Desktop Linux it's more likely for software to be installed outside of the repositories, including IPv4-only software (Discord or something) while on server Linux it's more likely that a server would be fine with IPv6-only operation. I'll keep a look at a couple distros about what they'll do with that parameter once they update to 255.

Nevertheless, I'm hoping that 464XLAT will get a higher priority for systemd and will be implemented soon-ish, if possible. Once that's the case this whole issue will solve itself, no matter which distributions enable or disable that default setting.

[patrakov]

No out-of-repositories software is required to trigger the failure. Firefox is enough.

I know of one case where native IPv4 connectivity is required: SIP and WebRTC with peers that don't support IPv6. For example, in Firefox, on an IPv6-only connection with DNS64, visit https://janus.conf.meetecho.com/echotest.html - the echo test fails. Start clatd (a Linux 464XLAT implementation), and it succeeds.

I think that at this stage video conferencing over the Internet is important enough that we should not force a configuration that breaks it. In other words, @Leseratte10 's network configuration is valid and should result in working IPv4 and IPv6 connectivity, including with IPv4 literals.

---

The error in the browser console is: WebRTC: ICE failed, add a TURN server and see about:webrtc for more details

One of the complicating factors is that I have a Tailscale VPN to a corporate network and some IPv4-only bridges for virtual machines, so I do have an IPv4 address, but no default IPv4 route unless I start clatd.

Without clatd:

With clatd:

[Leseratte10]

That's what I mean, yeah.

Given the huge amount of IPv6-incompatible software out there, it doesn't seem like a good idea to open bug reports for all of them in my distribution. As much as we'd all like to have IPv6 support, that's for the software devs to add, not the distribution maintainers.

Yes, Firefox isn't usually used on servers and thus for servers it might make sense to honor the IPv6-only flag from DHCPv4 even when there is no supported 464XLAT, even though RFC 8925 says there should be one. But this is going to break every default installation on any Linux client (in networks that have that flag set).

Are you saying that every single Linux distribution that's not only intended for just servers but either for both servers and clients or just for clients is supposed to alter systemd's default config to explicitly set IPv6OnlyMode=false? If so, this should have been mentioned in the Changelog's "Incompatible changes" section, imo, because it will break existing, perfectly sensible configurations.

Looking at the changelog right now, this change doesn't even seem to be mentioned in the changelog on the Github release for version 255 at all? How are distributions supposed to know / figure out they need to change this default config if it's not even in the changelog?

The only thing I can find when searching for "DHCP" or "IPv6" is this one, and that's something completely unrelated:

• The "ip=off" and "ip=none" kernel command line options interpreted by
  systemd-network-generator will now result in IPv6RA + link-local
  addressing being disabled, too. Previously DHCP was turned off, but
  IPv6RA and IPv6 link-local addressing was left enabled.

Wouldn't it be more sensible to change systemd's default to IPv6OnlyMode=false as a short-term solution and then set it back to true when a working 464XLAT is implemented eventually?

---

EDIT: Okay, it is mentioned in the NEWS file, but without any indication that distributions would probably want to add a new default parameter:

• The DHCPv4 server and client gained support for IPv6-only mode (RFC8925).

"XXX client gained support for YYY", at least to me, doesn't sound like a typical phrase that would break stuff. And it's not like it will get caught in the distro's internal testing since I doubt these are run with the IPv6-only flag set in their DHCPv4 server.

[SoniEx2]

what about implementing the CLAT (without the use of a daemon) in glibc instead?

[Leseratte10]

In glibc? I'm not that well versed in linux networking so maybe I'm talking crap here, but I don't think that that's a good idea. Then you'd need a whole bunch of NAT64 prefix discovery code in glibc (RFC 7050, 7225, 8781 and probably more), or a way to do prefix discovery in systemd and somehow let the glibc know about the prefix.

[SoniEx2]

it would be a great idea. don't bother with DNS64-based prefix discovery tho, DNS64 is a defective standard, since it breaks DNSSEC, but you don't need to worry about that if you have a CLAT.

[patrakov]

what about implementing the CLAT (without the use of a daemon) in glibc instead?

This would not help, due to containers, Flatpaks, and whatnot.

[SoniEx2]

what about them? do those use NAT for networking?

[patrakov]

It depends. Docker containers can use either NAT or stay in the host network namespace. Flatpak uses the host network namespace.

[Leseratte10]

I don't think Flatpaks use NAT, they just use the host's network interfaces. So if systemd sets up a proper clat interface like clatd on Linux does (which, by the way, also uses DNS64 to discover the prefix) with proper routes then it will work both with Flatpak and with NATed Docker containers.

If you'd modify the host's glibc to make a fake CLAT then this will fail for basically all Docker containers that use the host's networking but come with their own base image's glibc.

[SoniEx2]

oh, right, you'd want to make sure the flatpak/container glibc is up-to-date with the latest CLAT changes.

(DNS64 is no longer appropriate for discovering the prefix. use the RAs. PREF64 or whatever.)

[Leseratte10]

you'd want to make sure the flatpak/container glibc is up-to-date with the latest CLAT changes

Which can take a looong time, given that quite a few people are using containers as like "I have this ancient application that needs an ancient OS that I want to run on a modern OS" and stuff it into a container with an old base image.

[pmarks-net]

I agree with @Leseratte10. IPv6OnlyMode=yes violates RFC 8925 and should be changed.

Android and iOS were the pioneers in this space. Android has 464XLAT and iOS tests applications for NAT64 compatibility as part of a manual review process.

Generic Linux doesn't have a curated app store, so the only RFC-compliant solution is to set IPv6OnlyMode=no until 464XLAT is available. People have enough reasons to blame IPv6 for breaking their stuff. Please don't give them more.

[momoka0122y]

Could you elaborate more? I am not familiar with 464XLAT. Could you suggest a setting format to support the feature? Also, could you provide a way to support that feature with another tools, e.g. ip command?

I don't know the systemd development method so I'm curious.
When systemd implements 464XLAT can it use a translation software (tayga or jool_siit) or would it need to build the CLAT from scrach?

I've been running a CLAT on my Ubuntu with jool_siit and it's working pretty nice so far.
Thanks to @oskar456 https://gist.github.com/oskar456/d898bf2e11b642757800a5ccdc2415aa

ip netns add clat-netns

ip link add name HOST_TO_CLAT4 type veth peer CLAT_IPv4_LINK
ip link set dev CLAT_IPv4_LINK netns clat-netns
ip link set up dev HOST_TO_CLAT4

ip link add name CLAT_IPv6_LINK link <interface> type ipvlan
ip link set dev CLAT_IPv6_LINK netns clat-netns

ip -6 neigh add proxy 2001:db8::c1a7 dev <interface>
sysctl net.ipv6.conf.<interface>.proxy_ndp=1

ip -4 address add 192.0.0.1/30 dev HOST_TO_CLAT4
ip -4 route add default via 192.0.0.2 dev HOST_TO_CLAT4

ip netns exec clat-netns ip link set up dev CLAT_IPv4_LINK
ip netns exec clat-netns ip link set up dev CLAT_IPv6_LINK
ip netns exec clat-netns ip -4 address add 192.0.0.2/30 dev CLAT_IPv4_LINK
ip netns exec clat-netns ip -6 address add 2001:db8::c1a7 dev CLAT_IPv6_LINK
ip netns exec clat-netns ip -6 route add default dev CLAT_IPv6_LINK
ip netns exec clat-netns jool_siit instance add --netfilter --pool6 64:ff9b::/96
ip netns exec clat-netns jool_siit eamt add 2001:db8::c1a7 192.0.0.1

Maybe not the most optimal way to do this but this works for me.
But this is configuring the NAT64 prefix and it would be nice if systemd could get that information from the Router Advertisements.

So I don't know what everyone else wants but a configuration I would like might look something like

[464XLAT]
# Enables the 464XLAT feature when a PREF64 is detected in Router Advertisements (RA).
EnableOnPREF64=yes

# Specifies the CLAT IPv4 address to use.
CLATAddress=192.0.0.1/30

# Forces the 464XLAT feature to be enabled, even if no PREF64 is received from RA.
ForceEnable=yes

# Specifies the NAT64 prefix to be used when ForceEnable is set to 'yes'.
ForceEnableNAT64Prefix=64:ff9b::/96

[Leseratte10]

I don't know, and I don't think I'm qualified enough to answer that question. In the end, for most users, it won't matter. Either systemd implements its own CLAT functionality, or it just includes the code from Tayga or Jool or clatd.

It just should do something, because the current version breaks RFC and breaks people's networks. Whether that "something" is "adding a CLAT" or "disabling IPv6OnlyMode" is up to the systemd developers.

[oskar456]

Hey, I couldn't agree more with @Leseratte10 that IPv6OnlyMode should default to disabled, until CLAT is implemented and enabled in systemd. The whole point of RFC 8925 is to have just one network, which is used as IPv6-only for devices featuring CLAT (so that the IPv4 connectivity is established via CLAT) and as IPv4/IPv6 dual-stack for devices without CLAT. If systemd by default opt out from native IPv4 while not providing CLAT feature, this leads to breakage of IPv4-only dependent applications which is exactly what the authors of RFC 8925 wanted to avoid.

If such breakage was acceptable, then the network could have been run as IPv6-only without any IPv4 support. The whole point of running IPv4 DHCP with option 108 support is to provide IPv4 connectivity for devices without CLAT. Such devices should not opt out from IPv4.

It would be nice to see a support for configuring CLAT but since the SIIT translation between IPv4 and IPv6 is not part of Linux, this brings a dependency on a third party code like jool or TAYGA. Therefore, even if systemd supports setting up CLAT (which I would really like to see), that feature will probably be off by default and only enabled if particular 3rd party software is installed.

[Leseratte10]

@yuwata Sorry for the ping, but since you were the one who first triaged this report as a feature request (and you were the one who implemented the IPv6-only support) and none of the systemd developers seem to have commented on this issue since I reported it two weeks ago - with PR #29472 merged, this has effectively turned from a feature request into an actual bug that breaks people's setups - can this report be reclassified as a bug instead of a feature request to hopefully give it a bit more priority?

A clear violation of an RFC should, in my opinion, no longer be classified as a "request for enhancement". Instead it deserves the label "bug" and possibly even "regression" since the bug was just introduced in the last release and it breaks on networks where it worked before without any issue.

[silkeh]

@Leseratte10: Maybe it would be more useful to create a new issue for the specific problem instead of hijacking this one?

This issue is about 464XLAT support an (imho) does not really have much to do with the default value of IPv6OnlyMode, except for that the default could be switched after a CLAT has been implemented.

[Leseratte10]

Okay, will do.
EDIT: done - #30891

[certuna]

(DNS64 is no longer appropriate for discovering the prefix. use the RAs. PREF64 or whatever.)

RFC 7050 is still valid, discovering the prefix through DNS (ipv4only.arpa) is allowed.

I do agree it's not ideal, since IPv4 connectivity will break as soon as a client machine (or application) uses a custom DNS server, but it's not deprecated.

[SoniEx2]

yes and more importantly we're personally trying to get ppl to stop breaking DNSSEC. :)

DNS64 is acceptable IFF you don't/can't have a CLAT. if you're stuck in a system of such legacy then it would be appropriate to use a DNS64 dongle on the appropriate node. but otherwise things should move to PREF64 altogether.

[certuna]

RFC 7050 doesn't break DNSSEC, it's only for discovering the prefix. What you're thinking of is RFC 6147: DNS64 where the synthesized AAAA records are generated by the DNS server so they cannot be validated by the client.

A DNS server with the ipv4only.arpa record does not need to synthesize any AAAA records, this can be done by the client after validating DNSSEC. Just like with PREF64.

[ogelpre]

Microsoft plans to bring general CLAT support for Windows. Linux is falling behind.

[ogelpre]

Besides the already mentioned CLAT implementations there is a kernel module implementation which is used by OpenWRT.