I am testing Steam over IPv6 only (using HE.NET tunnel), chat is working, no images or Steam news, updater does not work either

that means = there's some basic functionality within Steam for IPv6??

[0406/210657:WARNING:dns_config_service_posix.cc(292)] Failed to read DnsConfig.
nameserver 2001:4860:4860::8888
nameserver 2001:4860:4860::8844

Why is Steam dont updating to ipv6 ? -.-

I can confirm that the Steam client does not operate on an IPv6 only network, using NAT64/DNS64. This is on Mac OS 10.11.3 and Steam client built Feb 4 2016.

Please fix it. Steam still doesn't work on IPv6 only network (with NAT64/DNS64).

Strictly speaking, I'm not sure I'd consider this a Linux-specific issue, given that the Windows installer doesn't work behind NAT64, either: "Steam needs to be online to update. Please confirm your network connection and try again."

I'm also unable to connect on my NAT64 setup. Even in after selecting offline mode, Portal2 throws a "STEAM validation rejected" error even when attempting single player mode. The source engine probably needs to have its socket code inspected as well.

Also, this ticket appears to be a duplicate of #2912.

This also started affecting double-stack setting (e.g. Comcast, etc.) on Linux. The client loads sometimes, but the game fails to download.

I tried again now with all-updated steam on fully updated Win10 with yesterdays fall creators update. On an IPv6 only network (with NAT64+DNS64), Steam won't even start. After trying this, it won't even start if I go back to dual stacked network. I actually have to reboot Win10 on the dual stack network for Steam to start again.

Microsoft has fixed Win10 so multiple normal functions now work on an NAT64+DNS64 network, software updates work nowadays for instance. But, Steam is a complete blocker. It won't even start and give an error message on an IPv6 only network (again, with IPv4 reachability through NAT64+DNS64).

It has been four years ago, still no any actions?

Thus no solution to the high price of address blocks.

+1 ... 2019 is approaching!

IPV6 YEAH!!! :1st_place_medal:

Updated Steam Networking protobufs include a field for IPv6.

Steam Client Beta has received an update to support downloads over IPv6.
Another protobuf update has added support for an IPv6 address in one of the messages.

Nice but how can i enable ipv6? I've changed to Beta and clicked on Download on a game. But it was loaded only with ipv4. So i think there is some changing of option necessary.

I don't think the servers are IPv6-enabled yet, but I do see the beta client doing AAAA lookups now. For a normal dualstacked client this won't change anything (downloads still go through IPv4 as long as no IPv6-enabled steam content server is available), but for NAT64/DNS64 clients they finally stand a chance. Will test soon.

Ah ok, thank you :+1:

Actually two content servers now have IPv6 addresses – valve700.steamcontent.com and valve705.steamcontent.com. Although I'm unable to ping either of them over IPv6. They're of course just a few of very many and only used in select regions (cells).

Combined with 6 new IPv6 prefix announcements in the past week, I hope we'll be seeing more progress on this soon.

Another IPv6 related Steam Client Beta update:

Fixed issue "Servers content unreachable" related to some IPv6 configurations

Got around to testing current Steam client (Built Feb 2 2019, 09:29:56) on NAT64, no dice - according to log, the WebSocket is bound to 0.0.0.0 (V4-only). But hey, at least, the server is no longer an IPv4 literal, so that's something...

[2019-02-16 14:13:20] [1,3] Connect() starting connection (eNetQOSLevelHigh, CM03-STO.cm.steampowered.com:443, WebSocket)
[2019-02-16 14:13:20] [1,0] ConnectFailed('Connection Failed':0) (0.0.0.0:0, WebSocket

Needless to say, HTTPS-pinging this server over v6 works without issue:

$ LANG=en wget -6 -H https://CM03-STO.cm.steampowered.com
--2019-02-16 14:31:49-- https://cm03-sto.cm.steampowered.com/
Resolving cm03-sto.cm.steampowered.com (cm03-sto.cm.steampowered.com)... 64:ff9b::9b85:f208
Connecting to cm03-sto.cm.steampowered.com (cm03-sto.cm.steampowered.com)|64:ff9b::9b85:f208|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2019-02-16 14:31:50 ERROR 404: Not Found.

Yep, still no IPv6, and of course also no NAT64. Can't log in. Didn't check which socket it uses.

Local content caches/proxies seem to now support IPv6.

5 years passed since this issue was reported, and still there is no way to login on IPv6-only network. Such a shame.

Disable IPv4 28.06.2019 no connection to Steam Network available. Fix your Internet connection they say... WTF!

Here I am at an APNIC conference trying to login to Steam via a v6 network. Nope, doesn't work. Incredible and appalling.

+1 ... 2020 is approaching!

So what about all those NAT64-enabled networks? Is there going to be a Christmas present from the Valve team?
In June 2020, this bug report will celebrate its 6th anniversary.

June ... 6th anniversary.

I see what you did there. Would be funny if support was rolled out on an IPv6 day!

I get this issue with the macOS client as well.

Same issue here ...
No login on mac osx ipv6 / nat64

So what about all those NAT64-enabled networks? Is there going to be a Christmas present from the Valve team?
In June 2020, this bug report will celebrate its 6th anniversary.

June 2020 has now come and gone. :(

I do not care that most games will not work without native IPv4 connectivity - that falls on the game developers, not on Valve. I accept that many online games will never work again after the IPv4 sunset. But that is no excuse for the Steam client on Linux and Windows to not work without IPv4. We should be able to log in and download games without IPv4. It is a little sad that this bug report is still open in 2020 when IPv6 can no longer be an after thought. Valve will have to invest the time to fix this sometime - it is inevitable. Why not do it now and get it over and done with? Please and thank you.

@Nicholas-Johnson-opensource The issue is Steam doesn't work in compatibility mode... Most software should just work, it's because Steam half implements IPv6 and that implementation is broken that we get this bug.

They don't care about any of these technical arguments, so allow me to put this in language they will understand:

Dear Valve,
I refused to participate in your most recent Summer Sale because of this issue. I will not be giving you any more money until this issue is fixed.

@Nicholas-Johnson-opensource The issue is Steam doesn't work in compatibility mode... Most software should just work, it's because Steam half implements IPv6 and that implementation is broken that we get this bug.

What do you mean by "compatibility mode"?

It is not about implementing IPv6 (aside from in protocols that embed IP literals). IPv6 will automatically work in software which is designed well, with no thought from the developers. Most of the issues are caused by:
a) pre-flight checks
b) hardcoded IPv4 literals
c) legacy API calls

Valve just needs to update their code to solve these things, and then it will happily work behind a NAT64 gateway, and then Valve can make their servers IPv6 in their own time. Although I would really urge them to make their servers IPv6 only. But unfortunately, enabling IPv6 in servers can be extremely problematic for businesses which are subject to fraud, because the fraud detection and monitoring software will have to be able to understand IPv6 addresses and analyse them for patterns. The Steam Store is likely subject to fraud monitoring. This would help explain why most banks are not enabling IPv6 on their public facing services.

They don't care about any of these technical arguments, so allow me to put this in language they will understand:

Dear Valve,
I refused to participate in your most recent Summer Sale because of this issue. I will not be giving you any more money until this issue is fixed.

Oh, that goes without saying. If I cannot log in on my own terms, then I am definitely not going to spend any money. I have left telcos and ISPs which did not have IPv6 and told them that is why I was leaving, and I signed up for ones which offer native IPv6. I also go on Facebook Messenger occasionally and contact ISPs without IPv6 as a prospective customer, asking them if they have IPv6, and when they say no, I tell them that is unacceptable. I even contact small to medium businesses which I deal with and ask for IPv6 access to their public websites, hoping that for small websites, it might just be a matter of flicking a switch on the hosting provider's portal. Do I have no life? The jury is still out on that one.

But unfortunately people like us who understand technology and care enough to take action are still in such a minority that the following argument is just as powerful:

That it has to be done eventually (inevitable), and that it is a good business case to eliminate the risk of getting caught out later when they will face backlash from normal customers when ISPs stop offering native IPv4.

What do you mean by "compatibility mode"?

That's where legacy applications operate using the IPv4 API as they always have, un-aware of IPv6. The reaserch I did back when I was first looking into this bug lead me to believe that, assuming IPv6 is configured correctly, even without any IPv4 interfaces or addresses it should "Just Work(tm)". Somewhere along the line a router with IPv4 addresses would NAT the packets and legacy applications continue to work, even though the host/client they are running on is configured with only IPv6 addresses.

Without this level of backwards comparability running an IPv6 only node would be like trying to do anything other than playing games on a computer without a Text Editor, there are some things that will simply always be part of using a computer and lagacy applications is certainly part of that.

Good evening. Did any progress happen on this?

It has been 6 Years and still no progress on this issue .
They are really following Valve Time .

6 years for no IPV6 :1st_place_medal:

It's probably on the roadmap for IPv6 support to be added with Half-Life 3.

Wireshark shows Steam updater only making DNS A queries, and no AAAA queries. It seems like Steam is using DNS (as opposed to hardcoded IPv4 literals). How hard is it to change from AF_INET to AF_UNSPEC in the source code?

Wireshark shows Steam updater only making DNS A queries, and no AAAA queries. It seems like Steam is using DNS (as opposed to hardcoded IPv4 literals). How hard is it to change from AF_INET to AF_UNSPEC in the source code?

It's likely they're using the old gethostbyname() method. Nowadays one should use getaddrinfo() and iterate through the returned list of structs to call connect() on. This will handle all the AF_* issues for you.

+1 ... 2021 is approaching!

any ETA?
Please?

I just opened a support ticket with Valve for this issue, after the previous support ticket for general IPv6 support stalled.
If this feature is important to you, I suggest you open a support ticket, because employees working on things directly cost Valve money, therefore giving them incentive to fix their networking underlay.

Edit: yes, I am taken aback by how little Valve does to fix this relatively severe issue, considering that the IPv6 RFC was released in 1998.

It's also not like NAT64/DNS64 networks are a new thing. I had one set up eight years ago: http://blog.flyingpenguintech.org/2013/11/cookienet.html

No cookie for Valve!

It's also not like NAT64/DNS64 networks are a new thing.

Nivex is right; it's been 10 or more years since I started setting up IPv6-only networks with NAT64.

Edit: yes, I am taken aback by how little Valve does to fix this relatively severe issue, considering that the IPv6 RFC was released in 1998.

Only if you consider RFC2460 to be the start of it; there's also RFC1883 from December 1995.

(It should probably be vaguely concerning that I cited all of the above without looking them up. 😬)

This "Valve" is clearly defective; no action in seven years. Get onto modern software engineering practices and stop using legacy APIs. Please.

Gonna have a bad time if starlink ends up going huge and still has to use CGNAT for IPV4...

Gonna have a bad time if starlink ends up going huge and still has to use CGNAT for IPV4...

I laughed when reading this. I am using Starlink and have been bummed I can't get my dedicated server going behind the cgnat. They just allowed ipv6 but everything is so outdated you can't host a dedicated server on ipv6. Frustrating...

Good god man, my new FTTH ISP is IPv6 only, please get IPv6 going, it's mid 2021!

China comes to rescue: https://www.theregister.com/2021/07/26/china_single_stack_ipv6_notice/

By the end of 2023, new networks won't be allowed to use IPv4 – a change that signals progress in China's vision of a single IPv6 networking stack for the nation.

Hard to tell what new networks they actually mean here - if residential networks are included, this may become Valve's deadline.

9/25/21 - NAT64/DNS64 - Steam Client cannot connect

Valve, it's very simple to fix. Please update the Steam client to not use hardcoded IPv4 addresses. This is not hard. All somebody needs to do is change the Steam Logon IPs to hostnames and point them to A records in DNS. There is no need to supply your own AAAA records unless you actually support native IPv6 connectvity. All we are asking is for basic DNS64/NAT64 support on networks that are IPv6-only.

I have a very small list of services that aren't reachable via the NAT64/DNS64 method and Steam is right there at the top of my list.

This is very likely not a DNS issue.

I'd very much like to get this out of the way, since most people complain about it being a matter of hardcoded IP addresses, which in all likelihood isn't the real issue.
Complaining in this issue does pretty much nothing to solve the problem, as Valve almost certainly doesn't get constant notifications for this thread.
If you want things to change then please bother them directly as I've mentioned before, or provide constructive feedback, in terms of debugging results.

What We Know

Here I'd like to point out the excellent responses from karatekid430 and nivex, as they provide further insight into what it actually takes to fix the issue; which is rewriting code that is either using quite old libraries, or which uses a different programming pattern than should be used nowadays.

What does this mean?

If this originates from a library (go ahead, turn on gdb, or maybe try using ltrace, whatever works), then chances are Steam is either using an old library that can't be simply updated due to breaking changes, or which is not maintained anymore (also, off chance it could be a library they lost the source code for, or maybe licensing issues).
Otherwise they would have to touch some code that may be used by a wide variety of other moving parts in the Steam codebase; fixing the issue there might break seemlingy unrelated parts as well.

How to proceed?

What I'm saying is, this is not a simple "fix DNS lul" issue, and it's also not just "use DNS instead".
In effect this means that as long as Steam isn't fixing this we have two choices; bother them where it hurts until they fix it (see my earlier comment), or find ways to fix it ourselves.
I'm asking you to either do the former, or the latter, but stop triggering my GitHub notifications unless you have something meaningful to bring to the table.

Why is this fix hard?

Static/Dynamic Resources vs. Behaviour

Now on to why "fix DNS lul" and "use DNS instead" would be easier fixes.
The former could be circumvented by proxying DNS and rewriting the problematic parts (hello unbound).
The latter could be circumvented by finding the hardcoded IP and replacing it.
The issue we most likely have is that we'd have to change behaviour of some of the code.
I'm not saying this is impossible, I'm saying you have to understand the problem first which might be harder than just looking for an IP.

Possible API Parameters

Another issue here that I'm vaguely aware of but which I cannot 100% confirm is that one of Steam's APIs requires an IPv4 address as a parameter, otherwise it will invalidate your session just about every other time you start up Steam.
If this assumption of mine is correct then we'd either have to patch that too, or find some other way around it.

An Apology

I'm sorry for being so bold any wordy about this, this is a lot to read for people who already read the thread and I'm sorry for bother you good souls out there.
However I'm not apologizing for saying any of this to those who haven't read the thread, because you are wasting my time and nerves.
It is really annoying to see a response in this thread and it's just the same thing we had a dozen times over already, without any further input.

Is this still, after 8 years? not resolved?

Is this still, after 8 years? not resolved?

I'm starting to believe this is called "Valve Time".

This needed to be actioned 8 years ago, before IPv6 only makes this a major problem for users

This issue is legitimately incredible, it's almost like a time capsule signifying Valve's total apathy

This issue should at least be merged with https://github.com/ValveSoftware/steam-for-linux/issues/2912

This issue plagues the Steam Deck too. By default it's not even able to connect to an IPv6-only network. I was able to change some network settings in desktop mode and connect, and then everything in desktop mode works (except Steam client), but the regular non-desktop view shows that there's no Internet access...

also having this issue. my iphone hotspot produces a NAT64 network, making it impossible to bring the steam deck's gaming mode online while on the go. that's quite an inconvenience on you know.. a portable device

my home internet recently went out for a bit, and I had to rely on a mobile hotspot with spotty ipv4 connectivity... shocked at how many sites still don't have ipv6 support. particularly ones that sell products. ebay, amazon, craigslist, indeed, reddit... GITHUB. there's non-zero customers out there, even in the US, who only have internet access through hotspots that are ipv6 only or have CGNAT strained by port exhaustion...

Now MacOS Ventura automatically setups an integrated CLAT if it detects a NAT64/DNS64 network an Steam works!
(see https://www.youtube.com/watch?v=zQk6YMO-7fw)

Now MacOS Ventura automatically setups an integrated CLAT if it detects a NAT64/DNS64 network

A small correction: macOS CLAT is only set-up by the operating system if you provide a DHCPv4 option 108 ("IPv6-only preferred") and a pref64 ("NAT64 prefix") option in IPv6 router advertisements. DNS64 is not necessary for the CLAT to work, but you do want it for the other apps running on your system. (I am the author of the radvd patch Ondrej mentions in his talk and am currently running an IPv6-mostly network at home. I need to give Steam a try on it!)

@zajdee 🤔 I don't have dhcp-opt 108 (actually no dhcp at all) nor pref64 enabled and it still works. I think macos and ios resolv ipv4only.arpa for checking dns64? Its same on ios since version 16.

@zajdee 🤔 I don't have dhcp-opt 108 (actually no dhcp at all) nor pref64 enabled and it still works. I think macos and ios resolv ipv4only.arpa for checking dns64? Its same on ios since version 16.

CLAT is available if you see 192.0.0.2 in the output of ifconfig and can e.g. ping 1.1.1.1 (I have double checked this right now). If you can't, then there's something else in Steam that makes it work on the NAT64/DNS64 networks, and that's exciting!

noone@imac20 ~ % ifconfig | grep clat
	inet6 fdee::1439:bc88:d58d:59de prefixlen 64 clat46
noone@imac20 ~ % ifconfig | grep 192
	inet 192.0.0.2 netmask 0xffffffff broadcast 192.0.0.2
noone@imac20 ~ % ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=57 time=24.911 ms

@No0ne: oh, thanks. It looks like the behaviour I have described was active on macOS 12, but on macOS 13 the CLAT activates even when there's neither DHCPv4 Option 108 not pref64 in the router advertisements. (That's good news.)

It would be nice for Valve to support IPv6 gaming. I have multiple Steam gaming devices and I can open the firewall ports easily for each device via IPv6.

The limitation of IPv4 NAT would only allow me one device at a time to use those ports.

Please Valve, run a dual stack for your servers and ask game developers to support a dual stack; IPv6 preferred when both are available.

The servers don't need to be dual-stacked for clients to p2p over v6. It's up to the app/game developers to implement this.

It's up to the app/game developers to implement this.

Hard to do when many of Valve's APIs for game devs still assume an IP fits into a 32-bit integer, like in the ISteamGameServer interface and probably many others.

Some newer Steam APIs like this one are finally beginning to support IPv6, but definitely not all of them.

And the Steam Client is still either connecting to hardcoded IPv4 addresses or ancient library calls like gethostbyname instead of getaddrinfo. This is a far bigger issue than the servers not having IPv6.

If the client were implemented correctly, with no hardcoded IPs and using getaddrinfo everywhere, all you'd need would be a NAT64 to use Steam on an IPv6-only connection, even if Valve's servers don't support that yet.

This is definitely something that Valve needs to fix by A) making the Steam Client work behind an IPv6-only connection with NAT64, without CLAT; then B) providing IPv6-capable versions of all their developer APIs. Only once that has happened, is it useful that C) Valve servers get working IPv6 and D) game devs using Valve APIs finally start supporting IPv6 (and IPv6-only).

Also, independant from the client, Valve has a lot to do regarding IPv6 on the Steam Deck, too, ...

I don't think games are stuck using the steam client for things like getaddrinfo, plus I doubt any p2p code is doing address lookups... I'm sure game devs have all the tools they need to use the full network stack regardless of what valve does.

I don't think games are stuck using the steam client for things like getaddrinfo, plus I doubt any p2p code is doing address lookups... I'm sure game devs have all the tools they need to use the full network stack regardless of what valve does.

The Steam client don't work in in an NAT64 environment due to this bug, which is a oneline piece of code to change in the client. (Testing added on top of that might make the fix non trivial, but the code change itself should be)

Sure, if the game devs wanted, they could ignore all the features the Steam API offers, and just implement all of the p2p network logic themselves,, and also develop and host their own servers for matchmaking, then the game(s) would work over NAT64 / IPv6 just fine. But I don't think many devs are going to do that when Valve offers APIs that make that a whole lot easier.

This is the issue with every framework, they swallow innovation making applications a clone with only the skin to differentiate them. I don't think you'll win any awards that way.

It’s 2023 and still no support. I can’t use my steam deck because of this. Next time I’ll buy literally any other device. 8 years and still no fix?!

@tiiiko Can't you deploy a router? I didn't think this was anything more than a nuisance, if there are unsurmountable effects those should be well documented in detail.

@tiiiko Can't you deploy a router? I didn't think this was anything more than a nuisance, if there are unsurmountable effects those should be well documented in detail.

Thank you for your reply. It’s a bit different for me. I have a nice PC and screen at home so I’d virtually never use my steam deck there. I’d like to play on the go, but my phone’s hotspot is IPv6 and cannot be changed. This means I have to hope there’s a good public WiFi somewhere, which in my experience unfortunately is something of a rare find in Germany.

March 12, 2024: Not working yet

Steam can't even merge duplicate issues for this same problem; one since 2013, one 2014 -- that's over 10 years!

https://github.com/ValveSoftware/steam-for-linux/issues/2912
https://github.com/ValveSoftware/steam-for-linux/issues/3372

In that time IPv6 usage has grown from 2% to 45% (varies by country, some at 80-90%). There are now many IPv6-only networks -- several major mobile carriers, several ISPs, and IPv6-only is also common on guest networks (as phones and tablets support it well).

Steam is one of the major reasons why I haven't been able to switch my network over to IPv6-only, for easier single-stack management.

Don't we need to steal the valve from the office or something?

No-ipv6-2025 is open. 13 years.

Considering Valve has over 12,000 IPv4 addresses on their ASN, I doubt we'll see IPv6 support before 2030.

Considering Valve has over 12,000 IPv4 addresses on their ASN, I doubt we'll see IPv6 support before 2030.

They can be IPv6 less for a while, but without NAT64/DNS64 working (which, if you didn't know, don't require Valve themselves to have any IPv6 enabled services) some users won't be able to reach their services.

The big issue is about their client using hard coded IPv4, or have sockets that is IPv4 only, these are obsolete practices for over 20 years.

Windows 11 might get CLAT support which could workaround this issue, not impossible to do on Linux either. At the same time, the old calls should just be obsoleted. PSN, XBox, iOS all require games/apps to work over a IPv6, at least thru NAT64, so it's not that anyone would have any issue fixing this bug.

This is very sad 😔
I can't even update my Steam client after a fresh install, nor sign in, which makes Steam completely useless. I physically cannot switch to a network with IPv4 in my situation, so I'm stuck with a gaming PC without a steam client. This also means the games I previously purchased cannot be installed. I might just have to find other sources for my games.

Windows CLAT is now there; Still, I would expect steam to work with DNS64 alone. But,... it doesn't. Guess I will have to roll out CLAT on my workstation after all...

Would be a lot nicer if steam would 'just work', though. Only application that does not atm.

There is now a DEADLINE on this issue: https://konecipv4.cz/en/
6 June 2032
Otherwise, the Czech Republic government employees lose Steam access at work.

There is now a DEADLINE on this issue: https://konecipv4.cz/en/ 6 June 2032 Otherwise, the Czech Republic loses Steam.

false! the services of the government will not be offered via IPv4 anymore, which does not even mean that the government doesn't use ipv4 as a client anymore.

which is not to say, Steam (and github and others) should finally activate AAAA records for all their domains.

It would already help if they would not hardcode IPv4 addresses, but use DNS names instead.

Edit: FWIW, i just enabled CLATd on my host, and with that it works. I would rather not have to do so, though.

It is 17.03.2026 still no IPv6 supoort(

The source engine needs updated across all their games to use IPv6 as well.
IPv6 needs to be a priority now.

Something that works for me (although it's not a proper fix) is to run a simple HTTP proxy (such as tinyproxy) on lo (which often has a v4 address at 127.0.0.1). Running steam with http_proxy=http://127.0.0.1:8888 then seems to allow it to work.

Something that works for me (although it's not a proper fix) is to run a simple HTTP proxy (such as tinyproxy) on lo (which often has a v4 address at 127.0.0.1). Running steam with http_proxy=http://127.0.0.1:8888 then seems to allow it to work.

This basically achieves the same thing as a CLAT (client side translator), they translate the IPv4 header to an IPv6 header (addressed to the NAT64 server).

MacOS, iOS and Android have shipped with a working one for years. On Linux you could use something like CLATD, or a recent release of the standard NetworkManager. Windows is a bit late to the party, but they will also start enabling a CLAT on V6 only networks in the coming months.

Still, using a CLAT has downsides over native v4/v6 addressing:

• Less effective route as all traffic needs hop over NAT64 server
• Single point of failure (if your NAT64 goes down you will have a bad time)
• Increased latency
• Potentially decreased performance
• Potential MTU issues as v6 headers are larger than v4 header
• ...

Something that works for me (although it's not a proper fix) is to run a simple HTTP proxy (such as tinyproxy) on lo (which often has a v4 address at 127.0.0.1). Running steam with http_proxy=http://127.0.0.1:8888 then seems to allow it to work.

Note that using an http proxy won't solve the problem for games that use steamworks for non-http communication (like multiplayer). I believe steamworks still only has partial ipv6 support. If you find a game where net code doesn't work right, it might be this. That's why a CLAT is a better workaround. Unfortunately Linux doesn't have a good, stable clat yet. clatd works but isn't as performant of a solution as it could be.

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/3372#issuecomment-4752964521

Good news, NetworkManager will include a CLAT starting from version 1.58! This should enable Steam multiplayer to work on V6 only networks.

Also, there's some work in getting a module into the Linux kernel that does the same thing: https://lore.kernel.org/netdev/[email protected]/ and https://ipv6.monostack.org/TODO.html#Upstream-Linux-SIIT