Add IPv6 support

[jeremyvisser]

Describe the Bug

Currently, IPv6 is not used by any of the network sockets.

If you run netstat -lnp | grep sunshine, you can see all of the sockets bound to 0.0.0.0, not [::]. Also, if you look at https://github.com/SunshineStream/Sunshine/blob/master/sunshine/network.cpp, you can see it explicitly only binds with AF_INET.

On the server side, my ISP at puts me behind an IPv4 CGNAT, but has full end-to-end IPv6 connectivity.

And on the client side, both locations where I'd use it (either at work, or via my mobile) are also IPv6–only. (VPNs are not always feasible due to corp policy reasons.)

Expected Behavior

The Moonlight client supports IPv6. I expected to be able to connect to Sunshine using IPv6, but wasn't able to due to its lack of support.

Additional Context

No response

Sunshine Host Operating System and Version

Fedora 36

Architecture

x86_64

Sunshine Version

0.14.0

GPU Type

AMD

GPU Model

RX 6900XT

GPU Driver/Mesa Version

22.0.1

Capture Method (Linux Only)

Wayland

[perroboc]

Just adding the same test on powershell:

Get-NetTCPConnection -State 'Listen' -OwningProcess (Get-Process -ProcessName 'sunshine').Id

LocalAddress                        LocalPort RemoteAddress                       RemotePort State       AppliedSetting
------------                        --------- -------------                       ---------- -----       --------------
0.0.0.0                             48010     0.0.0.0                             0          Listen
0.0.0.0                             47990     0.0.0.0                             0          Listen
0.0.0.0                             47989     0.0.0.0                             0          Listen
0.0.0.0                             47984     0.0.0.0                             0          Listen

[lengyefenghan]

I need ipv6 too

[FallingSnow]

@ReenigneArcher Any love for IPv6?

[ReenigneArcher]

I don't have IPv6 so no way to test

[cgutman]

It should be possible to test streaming from IPv6 localhost (::1) if your network doesn’t have real IPv6 connectivity.

[MayeulC]

Yes, it should be possible to connect to localhost for testing. On Linux, listening on ::0 also listens on 0.0.0.0 AFAIK.

One use-case is to stream over a WireGuard or other VPN connection that uses IPv6 address to identify endpoints (IPv4 are possible too, but IPv6 provides much more freedom for addressing.

Here's a simple wireguard example with wg-quick. Put it in /etc/wireguard/connect.conf, then activate with systemctl start wg-quick@connect on both machines.
Server (note that wireguard doesn't have the concept of server or client, but here we take server as a computer whose endpoint we can specify with a static IP address):

I picked addresses from the fd00::/8, which are for private use

[Interface]
Address = fd42:1234:5678::1/128
Privatekey = xxxx # output of wg genkey
ListenPort = 54321

[Peer]
AllowedIPs = fd42:1234:5678::2/128
PublicKey = yyyyPUB # output of echo yyyy | wg pubkey

Client:

[Interface]
Address = fd42:1234:5678::2/128
Privatekey = yyyy # output of another wg genkey
ListenPort = 11188

[Peer]
AllowedIPs = fd42:1234:5678::1/128
PublicKey = xxxxPUB # output of echo xxxx | wg pubkey

[jeremyvisser]

You don’t even need WireGuard. Just use IPv6 on your local network. Pick a /64 subnet under fc00::/7, and give addresses out of that subnet to your computers. You won’t get internet access, but it’s more than sufficient for testing and development.

[MayeulC]

Or just use link-local addresses, I agree. I was pointing out an easy way to test over the net.

As an aside, Wikipedia says that fc00::/8 has been reserved for future use, so I wouldn't use that, even though it's effectively unused.

[8373907]

You don’t even need WireGuard. Just use IPv6 on your local network. Pick a /64 subnet under fc00::/7, and give addresses out of that subnet to your computers. You won’t get internet access, but it’s more than sufficient for testing and development.

I also have this problem. Have you solved this problem

[xiaohaoxiang]

I need IPv6 too. I would be very grateful if Sunshine could support IPv6.

[TeamLinux01]

I agree with just using a local-link address. The machines will figure out how to communicate with each other without needing a DHCP server.

I recommend checking out the IPv6 Buzz podcast for anyone who is interested in learning more about IPv6.

[cgutman]

Once #517 is merged, I should be able to take a stab at this. That will give us direct access to the local and remote addresses for HTTP(S) requests, which is critical for determining which address family we should use when creating the sockets for streaming.

[cgutman]

PR LizardByte/Sunshine#571 is up to add IPv6 support.

[dfn8979]

I've just discovered Sunshine and I'm disappointed to see this stance on IPv6 support from an open-source, self-hosted project. The lack of IPv6 support in software actively threatens self-hosting and the openness of the internet in general due to the exhaustion of IPv4 addresses and the prevalence of IPv4 address sharing (CGNAT). As the issue worsens, more and more residential ISPs will start to use CGNAT for IPv4, and software like this will completely stop working over the internet. For instance, like many other people, I can't use this at all over the internet because my IPv4 is behind a CGNAT and I can only accept incoming connections over IPv6. I respect open-source developers that write software pretty much for free, but the PR for IPv6 support is one of the first to have been opened on the roadmap, and yet it's evidently very low priority. The issue has also been converted to a "feature request" when in reality, it's an issue - it completely prevents many people from streaming over the internet.

[ReenigneArcher]

No reason to tag/mention me, I read every comment in this repo and org... Anyway...

Running IPv6 on a home LAN is not really common, which is probably why no one has prioritized this. I'm not a networking expert but you should still be able to forward external (internet) traffic to your internal IPv4 address.

There are currently 2 draft PRs to attempt to add this.

• PS4 Dualshock not recognized in Red Dead Redemption PC Remastered #571
• #887

[dfn8979]

This actually strongly depends on the country and the particular region of the world, but running IPv6+IPv4 dual stack on home networks is what I would call extremely common. IPv6-only is indeed very rare on home networks (although I do run an IPv6-only VLAN at home, but you could call me an IPv6 enthusiast), but it's necessary to have IPv6 on the LAN in order to use it to access internet endpoints. According to Google IPv6 adoption statistics, as an example, 67% of German internet traffic to Google is over IPv6. So around 67% of users in Germany have IPv6 internet connectivity and thus have IPv6 on the LAN.

As for forwarding external traffic to my internal IPv4 address, I simply can't do it. As I said earlier, my ISP uses CGNAT for IPv4. The WAN interface on my router has a private RFC6598 IPv4 address (100.64.x.x, similar to 10.x.x.x or 192.168.x.x, but it's used for IPv4 CGNAT). My router is basically behind another, really powerful ISP NAT router. My ISP does this because they ran out of IPv4 addresses, and it's very difficult to obtain new ones since IPv4 addressing was exhausted. I can't forward ports on that ISP router, so I can't accept incoming connections over IPv4 at all.

In addition to CGNATed IPv4 access, I have a full IPv6 /56 subnet which I can use for incoming connections without an issue. IPv4 CGNAT + full IPv6 is actually very common because of IPv4 address exhaustion - just Googling "CGNAT self hosting" shows that many people have issues with self-hosting because of IPv4 CGNAT.

[cgutman]

@dfn8979 The problem definitely isn't lack of enthusiasm for IPv6. I was the one that wrote the tool that allowed access to GameStream over IPv6, since GFE only listens on IPv4. I also wrote and maintain custom patches to ENet to support IPv6 for Moonlight when upstream ENet doesn't support IPv6 yet. I have an IPv6 environment at home and used it regularly to access multiple GameStream hosts behind a single WAN connection. I'm one of those same folks who complains loudy when software doesn't support IPv6 😉

The fact of the matter is it's not just converting some sockaddr_in to sockaddr_in6 and then we're done. There are a number of protocol-level challenges related to the fact that Sunshine supports multiple concurrent clients (which GFE didn't) and uniquely identifies clients by their <peer address, peer port> tuple. This works (usually) works fine with IPv4 where a single address is used, however it breaks with IPv6 temporary addresses. Fixing this requires updates to both Moonlight and Sunshine.

Because streaming traffic is sent over UDP, the source address can change depending on the preferred IPv6 address of the host at the time the packet is sent. This means that control traffic from the client could be mistakenly rejected by the host as not matching an active client connection due to the change in source address. I wrote a patch to address this issue for ENet which has rolled out in official Moonlight releases for most clients.

However, a similar problem also happens with the return path from Sunshine to the client due to firewalls between the client and server. If the host's preferred IPv6 address changes, the outgoing A/V data may be rejected by a firewall between them (because it looks unsolicited). The Boost basic_datagram_socket class that we use to send data doesn't provide access to the sendmsg() and recvmsg() APIs and required IPV6_PKTINFO data we need to control the local address, so we'll need to implement this in platform-specific code, which means more testing and development time.

In addition to IPv6 compatibility concerns for streaming itself, there are also other areas that need attention to reach feature parity with IPv4. For example, we need to support PCP and UPnP WANIPv6FirewallControl to reach parity with the automatic port forwarding for WAN streaming that we have for IPv4.

It's not that we don't care. It's just a lot of work to do.

[dfn8979]

Thank you for working on Moonlight's and Sunshine's IPv6 support, I understand how difficult it can be to adapt software to support IPv6 properly. The issue with UDP and temporary addresses was something I didn't think about before. Writing separate code for all supported platforms to fix that issue is definitely a lot of work. PCP and UPnP for IPv6 also take a lot of work to implement.

I don't want to act like I'm entitled to get an open-source developer to update anything for me, but it was worrying to see software designed for self-hosting not support IPv6 and I got the impression that the project's maintainer wasn't aware of the importance of IPv6 support for self-hosted stuff.

I'll try to work around the CGNAT issue by setting up a Wireguard server on the host PC, connecting to the server over IPv6 and internally using a /30 IPv4 subnet for Sunshine.

[fatinghenji]

The same needs. In China, getting an ipv4 address for a public network is almost impossible. But getting an ipv6 on a public network is very simple. I tried using zerotier to set up a virtual local area network, but the results were poor.

[MayeulC]

Well, that's a workaround, but what about tailscale? I've started using it recently (I personally self-host it with headscale, but the hosted service has a free "3 devices" tier). There are a few other VPN/overlay network options, but that one was easy to set up.

[fatinghenji]

I'm using zerotier as a temporary solution. So far it's working fine.

[Prurite]

Ran into the problem today. Hope ipv6 could be supported soon as it's the only way for me to stream over the internet behind a CGNAT ipv4 network.

[mateusmedeiros]

@dfn8979 The problem definitely isn't lack of enthusiasm for IPv6. I was the one that wrote the tool that allowed access to GameStream over IPv6, since GFE only listens on IPv4. I also wrote and maintain custom patches to ENet to support IPv6 for Moonlight when upstream ENet doesn't support IPv6 yet. I have an IPv6 environment at home and used it regularly to access multiple GameStream hosts behind a single WAN connection. I'm one of those same folks who complains loudy when software doesn't support IPv6 😉

The fact of the matter is it's not just converting some sockaddr_in to sockaddr_in6 and then we're done. There are a number of protocol-level challenges related to the fact that Sunshine supports multiple concurrent clients (which GFE didn't) and uniquely identifies clients by their <peer address, peer port> tuple. This works (usually) works fine with IPv4 where a single address is used, however it breaks with IPv6 temporary addresses. Fixing this requires updates to both Moonlight and Sunshine.

Because streaming traffic is sent over UDP, the source address can change depending on the preferred IPv6 address of the host at the time the packet is sent. This means that control traffic from the client could be mistakenly rejected by the host as not matching an active client connection due to the change in source address. I wrote a patch to address this issue for ENet which has rolled out in official Moonlight releases for most clients.

However, a similar problem also happens with the return path from Sunshine to the client due to firewalls between the client and server. If the host's preferred IPv6 address changes, the outgoing A/V data may be rejected by a firewall between them (because it looks unsolicited). The Boost basic_datagram_socket class that we use to send data doesn't provide access to the sendmsg() and recvmsg() APIs and required IPV6_PKTINFO data we need to control the local address, so we'll need to implement this in platform-specific code, which means more testing and development time.

In addition to IPv6 compatibility concerns for streaming itself, there are also other areas that need attention to reach feature parity with IPv4. For example, we need to support PCP and UPnP WANIPv6FirewallControl to reach parity with the automatic port forwarding for WAN streaming that we have for IPv4.

It's not that we don't care. It's just a lot of work to do.

So if I understood correctly, even if we got from the user configuration or otherwise a stable ip address that wouldn't help. Sunshine simply isn't able to set it as the source with the current exposed APIs, that will instead use whatever the host's preferred ip is at that moment, Sunshine be damned?

[cgutman]

#571 is merged and IPv6 streaming is now supported in Sunshine nightly builds.

Enable IPv4+IPv6 mode using the new Address Family option on the Advanced settings tab in the Web UI, then you should be able to stream normally over both IPv4 and IPv6. If the UPnP option is enabled, Sunshine will try to use UPnP WANIPv6FirewallControl to create IPv6 firewall pinholes if the internet gateway supports it, similar to our UPnP port mapping support for IPv4. Opening pinholes via PCP is not yet supported.

If you have Moonlight Internet Hosting Tool or GameStream IPv6 Forwarder installed on your host, you will need to update them to the latest version to avoid interference with Sunshine's native IPv6 support.

As I mentioned previously, there is a client-side fix required to handle cases where the client's IPv6 temporary address changes while streaming. The latest releases of Moonlight for Android and iOS contain this fix, but the fix hasn't been shipped officially for the PC client yet. You can use one of the nightly builds until the official clients ship.

[LizardByte-bot]

This feature has been added and will be available in the next release.