Roon Network Changes IPv6

Roon Software Discussion
21

Wait. Does this mean if my home network is IPv6 and my wireless carrier is also IPv6 I can use the normal Roon app and not ARC while not at home?

22

I don’t think that is likely.

Whilst IPv6 does not employ NAT (at least not usually) and all IPv6 connected devices (usually) have a public IP address, IPv6 does still embody the idea of subnetting which means that multi-cast packets will still normally be restricted to the local subnet.

Thus device discovery is still likely to be limited to the local subnet.

2 Likes
23

If that was the case, they would have mentioned it. As @Wade_Oram wrote above

1 Like
24

Yeah, I know how roon discovery works for the normal Roon App (not ARC)… If this is just about IPv6 and ARC then why mention “Roon Remotes”? Or is this really just about the CG-NAT problem with ARC?

Also: "Additionally, Roon Remotes first look for your Roon Server on your local network. If they can’t find it, they try an internet-based method. "

I honestly can’t tell if they’re just talking about ARC or the normal Roon app. I mean, don’t get me started why we have two apps and the terminology that goes along with it.

1 Like
25

They explained it in the note. They had a fallback via the Internet and Roon cloud servers, which regular remotes would use if server discovery failed locally, which only applied in networks with subnets etc

26

I’ve never seen regular Roon client (not ARC) be able to discover a server across subnets without the user doing some serious tinkering. The normal Roon client & server as of a few weeks ago as best as I can determine relys solely on broadcast/multicast packets on UDP/9003 to discover each other. I mean it definitely didn’t work across subnets two weeks ago when I was testing. ARC client is different and uses an internet server to discover the Roon server behind your home router/firewall. Of course you can also use ARC at home, which is why it seems this IPv6 thing is really about ARC only.

I mean, I’m not a Roon employee so I’m not the actual expert on this. But as the person who wrote GitHub - synfinatic/udp-proxy-2020: A crappy UDP router for the year 2020 and beyond to deal with this specific issue for the traditional Roon client (before ARC existed) and also the Wireshark dissector for the Roon Discovery protocol I’m fairly well educated on this matter. Of course things change and it would be great if all these hacks weren’t neccessary anymore.

27

I don’t expect this to change. If it did then Roon would have made a big and much more explicit issue of it in the announcement. As it stands, Roon have always been very clear that, ARC aside, Roon is architected to operate only on the local subnet.

This is not quite correct. It is correct for IPv6 where the Roon Server registers it’s public ip address on the Roon Cloud servers and from where it is retrieved by ARC and used to connect directly to the server (assuming an appropriate IPv6 firewall exception/pinhole has been configured).

However, for IPv4, only the public ip address of your router (the one handling the internet connection if you have more than one) is made known to the Roon Cloud servers. In fact, in the absense of VPNs, this is the only ip address that any application outside of your network can use. This router ip address is then retrieved by the ARC app and used to connect to the router as if it was the ip address of the Roon Server. It is then up to the port forwarding rule on your router to pass (or forward) that connection to the Roon Server. The router port forwarding is configured either automatically (by uPNP/natPMP) or manually via an explicit port forwarding rule. If the router does not have the appropriate port forwarding rule in place, then the connection will be refused by the router itself.

28

And maybe that’s the reason for why they are removing this code now.

Nevertheless, this was the reason for why the note spoke about Roon Remote, which was your question

29

Yes, that is my understanding. And maybe my source of confusion is what is “Roon Remote”? I have a Roon Server and multiple Roon Clients on my home network (and other places, but again “tinkering”). Is the “Roon ARC” another name for “Roon Remote”? Naming… how does it work?

You are of course technically correct. I was too lazy to explain the difference in detail, because it wasn’t relevant to my question about the Roon app. :smiley:

Honestly, at the end of the day I find ARC to be a worse experience than using udp-proxy-2020 w/ VPN most of the time… ARC is great if on a plane, but other than that :face_vomiting:. I Sounds like nothing in this announcement changes any of that.

30

Roon Remote is a term often used to indicate the standard Roon Client on mobile devices (iPhone, iPads, Android phones and tablets). Going back a while the Android and IOS apps were actually called ‘Roon Remote’ in the respective app stores. These days the are just called ‘Roon’.

1 Like
31

And Roon Labs themselves are very sloppy with their own terminology, so users and Roon staff alike will also call any PC client a remote. Essentially, every Roon app that is not a Roon server and is used to control Roon.

1 Like
32

You’re hoping that this change makes your life easier? I wish I was optimistic like you. I think it’s more likely to break your setup than to make it work better.

I get that since Roon is dead set on not deploying a proxy for ARC, it doesn’t work for users on CGNAT or who can’t, for whatever reason, just forward an IPv4 port. I think it’s a big stretch to believe that making Roon run dual stack will significantly increase the number of users who can get it to work without something like Tailscale. I can’t imagine it’s going to be trivial to get those struggling users set up with routable IPv6 and the right firewall rules.

What I don’t get is what other changes they’re making. I’m with @Aaron_Turner in being surprised about the assertion that Roon remotes use an internet discovery service to find Roon servers on different LAN segments. I’ve never been able to get Roon and remotes to work across vlans without deploy Aaron’s excellent proxy. So I have no idea what they’re referring to when they hint at some sort of discovery service and they seem to be implying that these changes are going to break people with non-standard setups. That has me worried.

33

Right? So when they say:

Additionally, Roon Remotes first look for your Roon Server on your local network. If they can’t find it, they try an internet-based method.

They seem to be saying the “Roon” app (not “Roon ARC”) will use this “internet-based method” which we all seem to agree isn’t a thing? ¯\_(ツ)_/¯

Anyways… I’m kinda bummed, but not surprised that I still have to run my proxy to get Roon to work across subnets.

34

It did surprise me, too. Maybe it worked for a small number of people with certain segmented setup types even though their configuration wasn’t quite up to par, and we never heard from them because, well, it worked.

35

What kills me is you can type in the IP address of your Roon server in the app and it still can’t “connect” properly. They could use that IP address to send a unicast UDP packet to the server and that would be enough to bootstrap the Roon client on another subnet. But they choose not to do that.

2 Likes
36

You left off the rest of that…“This method is the one we are changing.” Meaning that is the current methodology and they are closing it. At least that is how I read it.

1 Like
37

I have no idea what you’re trying to suggest. Nobody is suggesting that this change makes any modifications to local discovery over UDP/9003.

Honestly, I don’t understand why Roon’s communication on this is so unclear. Most people have no idea how IPv6 works and using terms like “Roon Remotes” and “internet discovery” which are poorly defined is not helping.

Why they couldn’t just say:

We’re changing how Roon ARC discovers your server to support IPv6. This is to help those who have their Roon Server behind double-NAT/CG-NAT. This change will have no impact on those of you using the normal Roon client on your phone, laptop or other Roon client endpoints. If you are using Roon ARC and your ISP supports IPv6 please continue reading…

4 Likes
38

So this change is just about Roon ARC usability? I don’t use ARC, so perhaps this change doesn’t apply to me.

The announcement seems aimed at those with IT/Network knowledge, certainly much more than the average user (like me). There was mention of users being “prepared”, but I have no clue how that applies to me and my simple setup. I guess I’ll find out if I’m affected when the switch occurs.

4 Likes
39

uPNP/natPMP
double-NAT/CG-NAT
IPv6
IPv4
UDP/9003
GUA
pv6 prefix, dns + ipv6 prefix + ipv6 adress
dhcpv6
OMG

Us mere mortals have no idea what all this means ???:grimacing:???

This just confirms why my favourite topic in the community is:

11 Likes
40

They might have said exactly that if it represented the full extent of the changes.

They are changing something about how Roon remotes discover servers. The reason we’re confused is that they have implied that a discovery mechanism exists: the use of a cloud-discovery service to help a remote find a server on a LAN. You, @Aaron_Turner, me, and others have empirical evidence that this mechanism doesn’t exist.

At best, that’s weird. But the concerning thing is the sense that this post is some combination of a warning or a call to action for some of us, but there’s no way to understand it without more information.

I hope that whatever they’re actually doing is a net improvement of the product. Unfortunately, it seems that it’s just taking them further down the road of requiring users to do complicated things to solve Roon’s network code choices. Your proxy for those of us with vlans. Tailscale for ROCK users with CGNAT. Now, IPv6 firewalls for non-ROCK users with CGNAT.

I understand they probably don’t like the cost and/or complexity of running a proxy for ARC users but come on. Seriously.

5 Likes