I’d like to provide feedback on your ARC Port Forwarding article, which currently emphasizes UPnP and NAT-PMP as automatic configuration methods for Roon ARC. While this guidance may have been accurate for IPv4 setups, it no longer reflects the realities of IPv6-based deployments, especially since Roon ARC now defaults to IPv6 as its primary IP stack.
Here are the key concerns:
Most consumer-grade routers do not support UPnP over IPv6. UPnP IGD (Internet Gateway Device) was designed for IPv4 NAT environments. IPv6 does not use NAT, and UPnP support for IPv6 (via IGD v2 or PCP) is rare or disabled by default.
The article does not clarify that UPnP/NAT-PMP only apply to IPv4. This may mislead users into troubleshooting IPv6 setups using incompatible methods.
Roon ARC now prefers IPv6 for external connectivity, which means firewall rules, not port forwarding, are the correct approach. Users need to create IPv6 pinholes (inbound firewall rules) to allow traffic to reach their Roon server.
The fallback to Tailscale is useful, but the article should better distinguish between IPv4 and IPv6 paths and clarify when Tailscale is necessary.
I recommend updating the article to:
Clearly state that UPnP/NAT-PMP are IPv4-only and not applicable to IPv6.
Provide guidance on creating IPv6 firewall rules (pinhole access) for users with delegated prefixes.
Clarify how Roon ARC determines which IP stack to use and how users can verify or override it.
Include a note about router limitations and the lack of UPnP over IPv6 support in most consumer hardware.
Thanks for your continued work on improving Roon ARC. IPv6 support is a great step forward, but documentation needs to reflect the technical realities users face.
Whilst I agree with most of what you say - including the need to update the port forwarding article, the above statement is incomplete. Roon ARC now prefers IPv6 for external connectivity when both IPv6 and IPv4 are available at both ends of the connection.
In the UK many cellular service providers and publuc WiFi access points only provide an IPv4 connection. In these circumstances Roon ARC will continue to use the IPv4 connection even when ipv6 is avaliable on the Roon Server.
With regard to your recommendations, I would just like to add one thing more:
With IPv6, it is possible for devices to be allocated multiple global ipv6 addresses (e.g. One via DHCPv6 and one via SLAAC). In these circumstances, I have always err’d on the safe side and opened ipv6 firewall exceptions for all public ip addresses on the basis that I dont know which one will be used.
Is this necessary? And if it is not, how do I know which ipv6 address is going to be used? Does the Roon ARC settings page just show the one ip address that will be used by ARC (I can’t tell at present because my Roon Server only has one IPv6 address) or does it show all IPv6 addresses.
Finally, if ipv6 is now the preferred transport, is it still appropriate to bury the ipv6 address in the ‘advanced’ section of the Roon ARC settings page.
Edit: if ipv6 is now going to be preferred, I also think that making the diagnostics in the Roon ARC settings page needs to be reworked as I suggested a while back in my feature suggestion post at:
At present, if I disable my ipv4 port forwarding rule, then I cannot use ARC from my ipv4 only cellular phone service but the Roon ARC settings page still reports ‘Ready’ because the ipv6 connectivity is working even though I can’t use it when using ARC on cellular. I presume the converse is also true but since it is rare to be without an IPv4 connection, this does not matter.
I figured that was implied. You can’t really prefer IPv6 if one end doesn’t support it. (But Roon ARC did, until the latest Early Access release yesterday [RoonServer 2.56 Build 1583])
I’d guess the IPv6 address listed there is exactly what you’d use to create the pinhole rule. But some guidance would be welcome.
Funny enough, I had a similar issue. Roon ARC wouldn’t work when IPv6 was down (IPv6 active, missing pinhole rule), even though IPv4 was fine. My cellular phone is also dual stack, but couldn’t connect to Roon ARC. The latest Early Access build resolved that for me.
Not in my experience. My pinhole is merely associated with a named device. This device has an IPv6 address that is statically assigned on my NAS that hosts Roon server. FWIW, I use SLAAC rather than DHCPv6.
The pinhole setup depends very much on the router. On my Asus routers, the pinhole was specified with a destination ip address.
These days, I an using opnsense. On opensense I set up a named alias for a device associated with the mac address (in this case - other options are available) and then whenever I use that alias in a firewall rule, it expands into as many firewall rules as necessary to accept/deny traffic for each allocated ip address - so effectively the same as using your named device.
However, the opnsense ‘alias’ approach has an advantage in that I can create an alias for a group of devices. This might not be particularly useful for Roon ARC - if you did have multiple Roon Servers, you would presumably configure them with different Roon ARC port numbers (to support ipv4 access) and thus would need separate rules anyway - but in other situations it can be very powerful indeed.
Incidentally, I also set up a named alias for the Roon ARC port number - so if ever I have to change the port number used for any reason, I only have to change the port number associated with the alias. The multiple firewall rules and port forwarding rules do not change.