Steam doesn't work on IPv6-only (NAT64/DNS64) networks

[oerdnj]

I understand that my request might look like coming from Mars :), but there's an issue in the official steam client using a way to connect to steam servers the is not Internet Protocol compatible. (Yeah, I am not speaking about legacy IP ;)).

I am running on IPv6-only + NAT64/DNS64 network and Steam fails to connect to the servers although the connectivity works as expected - the IPv4 gets remapped to IPv6 addresses, so every application should not notice the difference unless:

a) you use some strange/ancient API to connect to TCP sockets b) you use IP addresses instead of domain names to connect to steam servers

The fix is obvious:

a) add native support for IPv6 into steam and prefer IPv6 if found b) use DNS to resolve the names of steam servers or have IPv6 address that gets used when IPv6 is detected.

I do not expect this to be solved quickly, but a record in internal tracker with some future fix would be nice.

DNS64 example:

$ dig IN AAAA store.steampowered.com @2001:1488:fffe:20::34

; <<>> DiG 9.9.5-4-Ubuntu <<>> IN AAAA store.steampowered.com @2001:1488:fffe:20::34
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64038
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;store.steampowered.com.        IN  AAAA

;; ANSWER SECTION:
store.steampowered.com. 5   IN  AAAA    2001:1488:fffe:30:ffff:ffff:173f:40c0

;; AUTHORITY SECTION:
steampowered.com.   9320    IN  NS  a8-66.akam.net.
steampowered.com.   9320    IN  NS  a24-64.akam.net.
steampowered.com.   9320    IN  NS  a1-164.akam.net.
steampowered.com.   9320    IN  NS  a11-67.akam.net.
steampowered.com.   9320    IN  NS  a26-65.akam.net.
steampowered.com.   9320    IN  NS  a9-67.akam.net.

;; Query time: 1 msec
;; SERVER: 2001:1488:fffe:20::34#53(2001:1488:fffe:20::34)
;; WHEN: Mon Jun 23 10:08:09 CEST 2014
;; MSG SIZE  rcvd: 211

[mxdpeep]

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??

[cheako]

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

[gangsta2oo9]

Why is Steam dont updating to ipv6 ? -.-

[fiveghz]

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.

[vician]

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

[jima-v6]

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."

[pHr34kY]

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.

[hsaito]

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

[mikaabra]

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).

[GroverChouT]

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

[cheako]

Thus no solution to the high price of address blocks.

[No0ne]

+1 ... 2019 is approaching!

[boospy]

IPV6 YEAH!!! :1st_place_medal:

[tambry]

Updated Steam Networking protobufs include a field for IPv6.

[tambry]

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.

[boospy]

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.

[bernhardschmidt]

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.

[boospy]

Ah ok, thank you :+1:

[tambry]

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.

[tambry]

Another IPv6 related Steam Client Beta update:

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

[myxal]

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.

[treysis]

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

[tambry]

Local content caches/proxies seem to now support IPv6.

[RomanTruba]

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

[0xE232FE]

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

[wuodland]

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

[No0ne]

+1 ... 2020 is approaching!

[zajdee]

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.

[myxal]

June ... 6th anniversary.

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

[DrJosh9000]

I get this issue with the macOS client as well.

[t0k4rt]

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

[nivex]

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. :(

[Nicholas-Johnson-opensource]

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.

[cheako]

@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.

[nivex]

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]

@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.

[Nicholas-Johnson-opensource]

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.

[cheako]

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.

[nivex]

Raise your hand if you're still gaming over IPX/SPX.

[cheako]

Raise your hand if you're still gaming over IPX/SPX.

Looking into this it looks like most of the games I can think of have been forward ported, but that wasn't always the case. What's happened is these titles have been reverse engendered. That takes time an energy and obviously is only ever done for video games... Nobody is going to reverse engineer that 30year old DB software.

So I think having something like https://en.wikipedia.org/wiki/Kali_(software) will be necessary to bridge the gap in the meantime.

[telmich]

Good evening. Did any progress happen on this?

[rKill3r]

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

[boospy]

6 years for no IPV6 :1st_place_medal:

[pHr34kY]

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

[karatekid430]

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?

[nivex]

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.

[No0ne]

+1 ... 2021 is approaching!

[koutsie]

any ETA? Please?

[benaryorg]

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.

[nivex]

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!