Wow :-))))
It was just a phone call to 1&1 and now everything seems to work fine.
Thank you so much :-)))))
Just one last question from a non-networking-crack: Could there be any security issue with this open port or is it now just “like before”?
1 Like
Hi @Abrahams_Bogere,
From my understanding of your home network setup, but if you connected your Core to the Wi-Fi of the ISP-provided router (skipping your own router), then you’d bypass the need for Prefix Delegation as explained by @ipeverywhere above.
That said, if you’re not using the ISP Wi-Fi to connect anything else, it’s worth verifying that you’re still behind your network security. Depending on how you’ve bridged the ISP modem/router to your mesh network, connecting directly to the ISP Wi-Fi might rearrange your firewall layers for the Core.
Another consideration is that connecting a Core via Wi-Fi introduces a higher risk of up- and downstream connectivity issues when connecting to ARC in variable conditions. I know that ethernet would be a pain in this case, but it might be worth performing a few tests on Roon Remote before even testing ARC on cellular data, to verify that a Wi-Fi-connected Core with your user flow can support Roon’s background operations.
1 Like
Hello everyone,
We’re reviewing the feedback from this week so far and will respond in further detail to those of you who have submitted individual questions.
Thank you to those of you who have tested and reported so far; this thread has already proven immensely helpful to the team, and I’m hoping it’s allowed some of you to more easily access ARC.
3 Likes
T-Mobile just seems weird with this. There are no settings where I can try to tweak anything. I did test it out and it still didn’t work. Yeah my modem is upstairs and I use mesh setup (Mac mini downstairs and my Auralic hardwired to another Satellite as well.
My ISP delivers IP4/IP6 dual stack. Is there something I can do to help? It looks like Roon only uses IP4.
We’re so used to everything being NATd a whole generation has grown-up before “real addressing” was a thing 
OK, I kid.
Some people believe NAT is a “security thing”. It’s not. The security comes from the fact the trusted network made a request to the untrusted side which then dynamically builds an “allow” for the thing on the untrusted side to respond to the thing on the trusted side. This has more to do with stateful firewall rules than NAT. However, NAT requires “state” to keep track of the active connections between trusted and untrusted just like a stateful firewall does. Your home NAT is working in conjunction with the stateful firewall to make Internet things work.
Now, in v6 there is no NAT. There is just the stateful firewall. Dynamic rules are still being put in place from trusted to untrusted. The open port, or allow, you installed in the firewall allows for untrusted to get to trusted at that port and address. This is needed for ARC because your network has no idea where ARC is coming from so you allow any to Core on that port. You just don’t need the port forward because there is no NAT involved. ARC connects to the address of the Core directly because your Core has a globally routable IPv6 address. It is using a “real address”.
That’s a very long-winded way to say… Yes it’s “like before” but without NAT.
4 Likes
@ipeverywhere ive seen some ISPs here in Singapore say they won’t offer ipV6 with PD because that means exposing your whole internal network to the internet.
I haven’t really looked much into IPv6 yet but the above statement sounds like nonsense to me? I thought the whole idea behind IPv6 is that each device would be able to get an IP address, both a public and local routable one. And with these local link addresses it would make routers pretty much redundant as each device would be able to route them on their own.
You could still have a firewall in place to block undesired traffic. So the router box as we know it today would be reduced to something that handles IPv6 PD plus a firewall. Is my understanding correct?
Thank‘s a lot for the „long-winded“ explanation 
Well, yes, but that also means your “whole internal network” won’t be v6 compatible. That’s not the point. We need everything to be v6.
yes, its trying to apply v4 understanding to v6. IPv6 is a new thing. With new things come new understanding.
The first part of your statement is correct but not this part. You still need routers. IPv6, Internet Protocol, is still a routed protocol. It has broadcast domains, subnets, etc. and between those things are routers.In fact, PD is what allows routers to obtain subnets to hand to router interfaces and other routers.
100% here. You still need a firewall. No one is proposing opening up unfiltered access to all these hosts. The firewall is still there. It’s only the NAT that goes away.
PD is only needed when you connect 2 routers together. People do this regularly without knowing it… example when connecting a mesh network to your ISP router. Often that mesh network starts with a “router” if you don’t put one of the devices in “bridge mode”. If you connect 2 routers together with v6 you need additional subnets to assign addresses to hosts. The way you get these additional subnets is via PD. If you just use the ISP router you’re good. Nothing else needed.
I meant for communication from one local device to another local device via link local ip addresses. It’s my understanding you don’t need a router for network communications on your “LAN” with ipv6. Because it can do discovery on it’s own.
For public networks, you would indeed still need some sort of router.
Or am I misunderstanding things?
Getting so far off topic I sent you a PM.
1 Like
Hi @Abrahams_Bogere,
We’re going to try to zero in on the peculiarities of T-Mobile’s implementation since this will continue to affect a large swathe of our North American user base. They are, unfortunately, quite restrictive in the customization they allow for their users. @ipeverywhere’s assessment reflects the team’s own testing results thus far, as well:
@Dennis_Mutsaers, are you able to describe your current router setup? If you’re connecting a Core directly to modem/router combo (without PreFix Delegation (PD) needed), then please do try defaulting to IPv6 in the router and posting any diagnostic results after attempting to autoconfigure port forwarding.
1 Like
@connor thanks for this. I wish there is some way to contact engineers there. I feel T-Mobile needs to loosen up on this. Even my menu app cannot do anything special (settings wise).
Is there perhaps a way Roon implements something like Tailscale within the product? So that we physically enable it and routes to our phone? Tailscale works at times but not as reliable.
Hi @connor ,
I don’t think I can default to IPv6 (or disable IPv4) on my Fritz!Box. I’m however able to enable ipv6 firewall settings.
UPnP however only opens the IPv4 port. I’m able to open the IPv6 port manually, but I don’t think Roon ARC uses it. The router shows its open and active. I haven’t been able to use Roon ARC for the last three weeks successfully.
Has anyone tested the new update yet?
Hi @Dennis_Mutsaers,
I’m certainly sorry to hear you’re stranded without ARC on-the-go. Please let us know if you’d like to default back to the production build in the meantime.
What happens if you try disabling UPnP entirely on the Fritz!Box? Part of what we’re probing and testing here is how Roon’s current interaction with the UPnP stack handles IPv6 in the context of different Core operating systems and network schemes.
Thank you, as always, for your precise contributions to the Community.
Hi @Abrahams_Bogere,
Unfortunately, the most recent EarlyAccess build contained some hotfixes for production, but not additional work on the IPv6 compatibility. That said, the T-Mobile situation has presented a smorgasbord of diagnostics throughout ARC testing since last year, so we’re always curious if anything changes concerning your ARC blockages on a new build.
Finding a way to play nice with T-Mobile’s network filtering is a huge priority, given the number of Roon users (and Team!) who rely on that network.
2 Likes
Is there a possibility you can sit down with the engineer at T-Mobile (not sure if this is possible) and have some sort of proposed changed. I would imagine this problem would also affect the gaming community as well. Which means less people will lean on this service (T-Mobile) if it can’t have ability to port forward.
Their bureaucracy is unfortunately opaque enough that even their major corporate partners aren’t afforded such a channel of communication. Roon has no existing relationship with T-Mobile; but it is true the chorus of lamenters includes the gaming and livestreaming communities. Roon is far from the only service affected here.
Hopefully, we can share more positive news regarding that particular ISP in the near future.
2 Likes
I understand! It’s ridiculous. I can only complain to customer service or support. But I do know T-Mobile business I think has the ability to have a public IP. Has that been tested yet? If so that could be an option they should add for us.