Roon on macOS does not work at all in networks where the IPv6-Only Preferred Option for DHCPv4 is set

Feedback
1

First of all, thank you very much for Roon. I am using it for over a year already and am very happy with it.

I would like to report a bug I have recently discovered due to some local network changes.

With DHCPv4 there is an option to signal that IPv6-only is preferred. For technical details, see https://datatracker.ietf.org/doc/html/rfc8925.

When the local network (or rather the respective DHCPv4 server) signals this option, Roon will not be usable. At least not on macOS. I do not have any Windows devices to do tests with them. Based on my tests with macOS I observe the following two problems:

  1. On the first start of Roon, one has to login with the Roon account. This procedure hangs after the browser redirects back to the Roon application, which will be stuck at the step “Logging in” forever. Setting up Roon is impossible without being able to login.
  2. The Roon App (not Roon ARC, I have not tested that) on iOS is stuck forever on trying to find the local Roon server.

Both of these issues can be resolved by either:

  1. Disable DHCPv4 on the involved clients and instead set static local IPv4 addresses.
  2. Turn off the IPv6-Only Preferred option on the local DHCPv4 server.

Which confirms to me that the IPv6-Only Preferred DHCPv4 option and Roon are incompatible.
Not a big deal, just turn the option off on the DHCPv4 server and everything is fine, but it shows to me that there is at least something within Roon that fundamentally requires a working local IPv4 network.

2

This is an excellent and very thorough report. Based on the behaviour you describe, your conclusion is correct, and your network configuration is not at fault.

What you are encountering is a limitation in Roon’s current networking model when used in an IPv6-only (or IPv6-preferred) environment.

  1. What DHCP Option 108 actually does
    RFC 8925 defines DHCPv4 Option 108, “IPv6-Only Preferred.” When this option is advertised and the client successfully configures IPv6, modern operating systems (including macOS and iOS) may intentionally stop assigning an IPv4 address to the interface.

In other words, this option does not merely “prefer” IPv6 routing; it explicitly allows the client to operate without IPv4 on that interface.

  1. Why Roon stops working
    Roon currently depends on a functioning local IPv4 stack for core functionality:

Local discovery: Roon Core, Remotes, and endpoints rely on IPv4-based discovery mechanisms (broadcast or multicast) to locate each other on the LAN.

Control and transport: Key internal services appear to bind to IPv4 sockets and expect a valid IPv4 interface to exist.

When Option 108 is enabled and the OS suppresses IPv4 configuration, these assumptions no longer hold. As a result:

The macOS client hangs indefinitely during login after the browser redirects back to the application.

iOS clients fail to discover the local Roon Core.

The login hang strongly suggests that part of the authentication or callback mechanism assumes IPv4 availability on the local host or LAN interface.

  1. Conclusion
    Your diagnosis is correct: Roon is not currently compatible with IPv6-only local networks.

This is not unusual—many media and discovery-based systems (including Sonos, Google Cast, and others) still require IPv4 on the local segment, even if IPv6 is available for internet connectivity.

Roon appears to require either:

A dual-stack environment (IPv4 + IPv6), or

An IPv4-only local network

An IPv6-only LAN, as enabled by DHCP Option 108, is currently unsupported.

  1. Workarounds
    Your proposed solutions are the correct ones:

Do not serve DHCP Option 108 to devices running Roon Core or Remotes, or

Ensure those devices retain a valid local IPv4 address (via DHCP or static configuration).

Final note
This is not a misconfiguration on your part, but a legitimate feature gap. Your report is valuable feedback for the Roon team, especially as IPv6-only deployments become more common.