IPv6 global unicast is broken in ZeroTier 1.8.x (at least under macOS)

I have a ZeroTier network used for remote management of several Macs running a mix of macOS Catalina, Big Sur and Monterey. The network is configured for RFC1918 IPv4 addressing, RFC4193 (one /128 ULA per device) as well as 6PLANE (/80 ULA per device). That part works as expected. As of a few days ago the additional global IPv6 unicast addresses (a /64 allocated out of PA space) stopped working. I did configure all nodes to allow global addresses on this network and added the /64 as route to the network. The nodes do configure all expected local addresses on the feth interface (1 x IPv4 RFC1918, 1 x IPv6 link local, 2 x IPv6 ULA addresses (/40 and /88), 1 x IPv6 global unicast). The IPv6 network route for the global unicast /64 gets installed on correct feth interface as well.

Despite all of the above NDP lookups for the global unicast addresses fail. I still access the nodes via ULA to capture pcap files to help with further debugging. Global unicast used to work a few days ago. I changed the following things:

  • Updated most ZeroTier nodes from 1.8.6 to 1.8.8 and two nodes to 1.8.9.
  • Added more nodes to the network.

From the packet captures it looks like the multicasted NDP neighbour advertisements get lost. Going forward I need IPv6 unicast to work. Can you recommend further debugging steps? Is there a limit to how many multicast groups are tracked per network? Did I just run into a bug?

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.