I changed my internet provider which currently only gives me DS-Lite with CGNAT. Since IPV6 is now supported by Roon I tried to configure IPV6 interface id on my routers web interface. When I’m using the interface id of the Mac-mini Roon server is running on, Roon ARC is not working. In the ifconfig output of the Mini I see the temporary IPV6 address of the Roon Server itself. If I provide this interface ID (not the ID of the Ethernet) I can configure ARC successfully. But unfortunately it’s not working in every situation. I think IPV6 is not available everywhere. But maybe somebody can explain to me which interface id for forwarding is the right one. If possible I’ll switch to full dual stack for some extra money.
Is there some documentation available how to setup port forwarding and how IPV6 fits into this picture?
To clarify, full IPv6 support is not yet implemented in the production version of Roon. For the time being, you will need to configure your network using standard IPv4.
Workarounds for Complex Networks:
If your network topology prevents standard port forwarding (for example, if your ISP uses CGNAT), we recommend using a VPN solution like Tailscale to bypass these restrictions.
While IPv6 support is currently enabled in our Early Access builds, please be aware that this is beta software. As such, we cannot guarantee stability or full functionality at this stage.
We wanted to add a little more context here, since we actually released some work around IPv6 last year to the public version of Roon you’re using.
ARC and Roon can support end-to-end IPv6 when both the server and client devices have stable IPv6 addresses and ISP infrastructure permits. Most ISPs have some sort of NAT or dual-stack on their residential tiers. Roon will default to IPv4 whenever available. The temporary MacOS IPv6 address likely won’t accept incoming packets, or the allocation changes faster than Roon will tolerate.
We don’t see a lot of networks that support IPv6 for ARC in reality, and we can’t offer a widely-documented, reliable set of steps or configurations that will work.
We usually recommend a separate NAT traversal strategy (Tailscale, etc) or inquiring directly with your ISP what they recommend for port forwarding solutions.
due to the fact that a lot f know how is necessary to navigate through all these possible opportunities, I don’t understand why Roon is not able to support a solution that works in all scenarios. I have a Homekit server behind the router, I have a fridge that I can control and I can access my router (it’s a Fritzbox) also from the internet using some build in technologies by these manufacturers. I know now (after many, many tries, which gave me a lot of headache) that Tailscale is working. But why isN’t that supported natively by Roon? You guys are calling a lot of money for your software, so as a music enthusiast I don’t want to stuck with these kind of things. Why is nothing stated in the ARC configuration, that a DS-Lite stack isn’t working? Where is the documentation about a correct setup? Why is IPv6 setup somehow implemented although it isn’ working? With these external solutions like Tailgate the use of ARC is highly depending on another company. If you guys know, that port forwarding is not a stable solution, why are you not offering a built in VPN solution which is maintained by yourself an not by another company that might get bankrupt? As I said, other companies are able to provide a great plug and play user experience even on complex network topics, why you don’t? I thought American companies were more service oriented, compared to European companies.
I understand the frustration. It seems illogical that a fridge or a HomeKit server works instantly while a high-end music server requires manual networking “gymnastics.” However, there is a significant technical reason for this.
1. Why your Fridge works (Relay Servers) Most IoT devices (fridges, smart plugs, HomeKit) use Relay Servers. Your device and your phone both connect outbound to a manufacturer’s cloud server. This “meets in the middle” to bypass NAT/DS-Lite. This works perfectly for small bursts of data (commands like “turn on” or “set temp”).
2. Why ARC is different (Peer-to-Peer Streaming) Roon ARC isn’t just sending commands; it’s streaming high-bandwidth, high-resolution audio.
Quality & Latency: To maintain bit-perfect quality and low latency, Roon aims for a Direct Peer-to-Peer connection between your phone and your Core.
The Cost of Relays: Maintaining a global network of relay servers capable of handling terabytes of lossless audio traffic for thousands of users behind CGNAT is a massive infrastructure cost that many high-end audio companies avoid to keep the software focused on local performance.
If you feel strongly that Roon should implement its own native NAT-traversal (like a built-in Tailscale), the best path forward is to post this in our Feedback > Feature Suggestions category. Our product team tracks these requests closely to prioritize future development.
In the meantime, using Tailscale remains the most robust solution for any high-bandwidth self-hosted service, not just Roon.
As far as I know the communication when using TailScale there is no server involved. It’s just about the exchange of credentials like cryptographic keys and IP adresses. This could be also done by Roon with small overhead, and thousands servers are not necessary. For the I think price this is absolutely mandatory.
