Feature Request: IPv6-only Network Support for Steam Client

[PenguinPower 🐧]

Hi,

There was a previous thread about this which got closed without resolution, but this is *still* a problem in 2023.

IPv6 is the current version of the IP protocol. There are real IPv6-only networks that do exist and are beginning to be deployed, without any IPv4 connectivity. There are also real IPv6-only networks which *could* be deployed if it wasn't for software such as the Steam Client requiring a working IPv4 layer in order to operate.

The Steam Client should be able to support these networks but as of 2023, such networks are still not supported by the Steam Client even on a fully-updated Windows 11 host, or on the Steam Deck due to what seems to be hard-coded dependencies on IPv4-only network endpoints. Whatever is happening in the Steam Client means this also fails when the IPv6-only network has NAT64 enabled via DNS64.

I'm not expecting all games to suddenly work on an IPv6-Only network if the client gets updated, but the fact that the client can't even log in and get to the point of downloading any games at all is a poor experience.

[aiusepsi]

It is pretty bad that Steam doesn't work on IPv6 only networks. We're deep into the era of IPv4 address exhaustion, and the situation is not going to get better.

Providing support for logging in and downloading games is really the least they could do. Fixing up things like matchmaking APIs so IP addresses aren't hardcoded to be uint32 (i.e. a 32-bit IPv4 address) is a thing which also has to be tackled at some point too, but just getting the client working at all is good enough for a lot of single-player games and even multiplayer games which don't use Steam's APIs.

[Supafly]

There are more devices out there that do NOT have IPv6 capabilities than do. This would essentially prevent more than 50% of connected devices being able to use Steam. Have you not seen all the threads complaining that Steam will be ending windows 7 support? There are more people without IPv6 than there are that use windows 7

Edit see posts #3/4 for why I striked comment out

[aiusepsi]

โพสต์ดั้งเดิมโดย Supafly:

There are more devices out there that do NOT have IPv6 capabilities than do. This would essentially prevent more than 50% of connected devices being able to use Steam.

I think you have the wrong end of the stick. The suggestion is that if you have a network which only has IPv6 connectivity, that Steam will work on that network, as well as working on networks which have both IPv4 and IPv6 connectivity, and networks with only IPv4 connectivity.

[Supafly]

โพสต์ดั้งเดิมโดย aiusepsi:

โพสต์ดั้งเดิมโดย Supafly:

There are more devices out there that do NOT have IPv6 capabilities than do. This would essentially prevent more than 50% of connected devices being able to use Steam.

I think you have the wrong end of the stick. The suggestion is that if you have a network which only has IPv6 connectivity, that Steam will work on that network, as well as working on networks which have both IPv4 and IPv6 connectivity, and networks with only IPv4 connectivity.

So I did, my bad, seem to have got stuck on the wording of the topic.

โพสต์ดั้งเดิมโดย PenguinPower 🐧:

Feature Request: IPv6-only Network Support for Steam Client

Read that as only for IPv6 networks not so much as prioritise only IPv6 over IPv4 when IPv6 is available.

As I clearly got the topic wrong I've striked it out

[tutosfaciles48]

Any news on this ? For some testing purpuses, I am on a network which only support ipv6 (and ipv4 via nat64), but Steam tell me that he don't have any connection ...

Comon', it's 2023, put a public dns with A record will not lead to security issue, especially if we talking about ipv4, which is public, and should be already scanned millions times a day...

[Lu5ck]

2024, steam still does not support IPv6 for their game servers browser api which therefore steam game which use steam browser to list servers have no reason to support ipv6.

[Rix]

As of July 20th 2024 Google regards IPv6 adoption in the United States to be roughly 53%[1].

As of July 2024 IPv4 is the minority protocol used for Internet traffic. It would be in Steam/Valve's best interest to support the majority protocol.

This 50% margin is critical as this means half the traffic served on the Internet is now over IPv6 rather than IPv4. If Valve wants to keep ahead of the curve and prevent unnecessary disruptions to their user base they should strongly consider rolling out IPv6-only support so that as more ISPs turn to CGNAT the Steam userbase that HAS enabled IPv6 can continue to enjoy online video games.

Additionally, Akamai is showing just under 50% [2] for the US. So major CDNs are also backing this data up. Google sees the majority of Internet traffic by far so I am willing to wager that their tracking is much more accurate given their breadth and ties into almost every web property.

Valve can easily promote IPv6 and be a forerunner by allowing the Steam clients to use 464XLAT through Steam servers. This would allow users to be on networks where only IPv6 is available to still play online games but the connection would be tunneled over their existing IPv6 connection to a translated IPv4 destination on Valve servers.


[1] https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption
[2] https://www.akamai.com/internet-station/cyber-attacks/state-of-the-internet-report/ipv6-adoption-visualization

[aiusepsi]

โพสต์ดั้งเดิมโดย Rix:

If Valve wants to keep ahead of the curve

Valve has a bad habit of very much tending to be very much behind the curve, unfortunately.

allowing the Steam clients to use 464XLAT through Steam servers. This would allow users to be on networks where only IPv6 is available to still play online games but the connection would be tunneled over their existing IPv6 connection to a translated IPv4 destination on Valve servers

What's kind of interesting is Steam runs a relay network, Steam Datagram Relay, the function of which is to allow connections to be tunnelled via Valve's network. The "Fake IP" system which SDR has is actually kind of similar in purpose to translation mechanisms like 464XLAT because it allows software which can't be updated to use SteamNetworkingIdentity for addressing to use fake IPv4 addresses which are then translated by the system.

So, it would be possible for games which use Steam's networking APIs to transparently connect to servers which are IPv4 only from clients which are IPv6 only, except that none of Valve's relays have an IPv6 address. So close, yet so far.

Also baffling: Valve hasn't updated their own matchmaking APIs to support SteamNetworkingIdentity, so the use of SDR Fake IPs is necessary to use Steam's networking APIs and Steam's matchmaking APIs together. See previous comment about Valve generally being behind the curve; they're not even keeping their own stuff up to date with themselves.

[Ben Lubar]

โพสต์ดั้งเดิมโดย aiusepsi:

Also baffling: Valve hasn't updated their own matchmaking APIs to support SteamNetworkingIdentity, so the use of SDR Fake IPs is necessary to use Steam's networking APIs and Steam's matchmaking APIs together. See previous comment about Valve generally being behind the curve; they're not even keeping their own stuff up to date with themselves.

What do you mean by this? The entire point of SDR is to avoid having to share the IP address of the server you're on with anyone, including you. If I had to guess, you're talking about the method in ISteamMatchmaking that puts an IP address in the lobby's public data. No Valve game has ever used that function.

[aiusepsi]

โพสต์ดั้งเดิมโดย Ben Lubar:

What do you mean by this?

โพสต์ดั้งเดิมโดย SDR Documentation:

Here are some general things to be aware of that apply to both P2P and dedicated server connectivity.

First, any place where network hosts are identified by a public IP (almost always the case for gameservers) will need to be changed to use a different identifier instead. There are several options for this:
* For clients and gameservers that signin into Steam, you will usually the SteamID.
* If your gameserver does not signin to Steam, and you are using the ticket-based authentication flow, you can use any other identifier that is meaningful to you. See SteamNetworkingIdentity.
* In some codebases, the assumption that network hosts and gameservers are identified using an IPv4 address is ubiquitous, and changing this assumption is a significant amount of work. Indeed, the Steamworks ISteamMatchmaking and ISteamMatchmakingServers APIs have this property, as do some of our own games, such as Team Fortress 2. In this case, you can use the Steamworks "Fake IP" system.

https://partner.steamgames.com/doc/features/multiplayer/steamdatagramrelay

Ideally, ISteamMatchmaking and ISteamMatchmakingServers would be updated so that anywhere they currently use a uint32 IP address, they'd have a SteamNetworkingIdentity instead, because then the same matchmaking APIs would work for SDR with SteamIDs for identifiers, as well as IPv6 and IPv4.

[Ben Lubar]

โพสต์ดั้งเดิมโดย aiusepsi:

โพสต์ดั้งเดิมโดย Ben Lubar:

What do you mean by this?

โพสต์ดั้งเดิมโดย SDR Documentation:

Here are some general things to be aware of that apply to both P2P and dedicated server connectivity.

First, any place where network hosts are identified by a public IP (almost always the case for gameservers) will need to be changed to use a different identifier instead. There are several options for this:
* For clients and gameservers that signin into Steam, you will usually the SteamID.
* If your gameserver does not signin to Steam, and you are using the ticket-based authentication flow, you can use any other identifier that is meaningful to you. See SteamNetworkingIdentity.
* In some codebases, the assumption that network hosts and gameservers are identified using an IPv4 address is ubiquitous, and changing this assumption is a significant amount of work. Indeed, the Steamworks ISteamMatchmaking and ISteamMatchmakingServers APIs have this property, as do some of our own games, such as Team Fortress 2. In this case, you can use the Steamworks "Fake IP" system.

https://partner.steamgames.com/doc/features/multiplayer/steamdatagramrelay

Ideally, ISteamMatchmaking and ISteamMatchmakingServers would be updated so that anywhere they currently use a uint32 IP address, they'd have a SteamNetworkingIdentity instead, because then the same matchmaking APIs would work for SDR with SteamIDs for identifiers, as well as IPv6 and IPv4.

The only place ISteamMatchmaking uses IP addresses is the method that puts the game server IP address in the public lobby information. Something that defeats the entire purpose of SDR. The same method also allows you to specify a SteamID if you really want to put that in your public lobby information rather than using the internal message sending functions like every Valve game with lobbies does.

And the legacy ISteamMatchmakingServers interface doesn't work at all with the concept of SDR. You can't protect a server from denial of service attacks if anyone is allowed to contact it at any time without even joining. If you want to have publicly accessible dedicated servers with SDR, you use the lobby-based matchmaking API and put the information that would require server queries in the lobby data. Or write your own API for the servers you run. Using the Steam API doesn't prevent you from using other APIs.

There not being any SDR entry points that are available to someone with no IPv4 connectivity is a problem, but the lobby-based ISteamMatchmaking and legacy ISteamMatchmakingServers APIs are not broken.

[Phragcyte]

I would also like to see IPv6-only support for the Steam client. Starlink satellite internet from SpaceX supports IPv6, and there's little reason to keep IPv4 around. NAT adds unnecessary complication to the internet, and has probably cost billions of hours of wasted human effort, over the years.

Please consider supporting IPv6-only in Steam. Thanks

[Connie]

This thread was quite old before the recent post, so we're locking it to prevent confusion.