The IPv6 requirements for Matter and Thread are simpler than the forum threads suggest and stricter than most home routers assume. Matter runs on IPv6 and nothing else. Thread is IPv6 all the way down to the radio. Neither cares whether your ISP hands you an IPv6 prefix, and both fall over the moment something on your LAN filters the IPv6 traffic they use to find each other. Most “just enable IPv6 on the router” advice muddles those two facts together, which is why so many setups pair cleanly and then rot.
What the specifications actually require
The Matter 1.4 core specification is unusually plain about this. Section 2.3 says “any IPv6-bearing network is suitable for Matter deployment” and that the protocol “may operate in the absence of globally routable IPv6 infrastructure,” a clause written for homes where the ISP “does not support IPv6 on consumer premises.” Devices “SHALL be tolerant of IPv4 addresses and MAY ignore those addresses,” and the discovery chapter states outright that “Matter does not use IPv4.”
Section 4.2, IPv6 Reachability, splits the requirement into two cases. If every node sits on one bridged Wi-Fi and Ethernet network, “link-local IPv6 addressing is sufficient - no additional IPv6 network infrastructure is required.” Add a Thread mesh and you have two IPv6 networks, so both sides need routable addresses of global scope, “GUA or ULA,” built from a prefix advertised as on-link. “If there is no routable prefix on a given network, the stub router SHALL provide its own,” and the stub router is the border router. Nodes must hold at least three routable addresses and process Route Information Options.
On the Thread side, the Thread Group’s Network Fundamentals paper has devices carrying IPv6 over IEEE 802.15.4 with 6LoWPAN as defined in RFC 4944 and RFC 6282, mesh-local addresses that are ULAs, and link-local addresses under fe80::/64. Home Assistant’s docs put it in four words: Thread is an IPv6-only protocol. There is no IPv4 fallback anywhere in this stack, which is the whole point of it and the whole problem with it.
The addresses you will actually see
| Address | Prefix | Who assigns it | What it is for |
|---|---|---|---|
| Link-local | fe80::/64 | every interface, by itself | one-hop traffic, mDNS, router advertisements |
| Mesh-local | a ULA under fd00::/8 from the Thread dataset | the Thread network data | traffic that stays inside the mesh |
| Off-mesh routable (OMR) | usually a ULA /64, a GUA if one is delegated | the border router | reaching Thread devices from the LAN |
| LAN on-link | your router’s advertised prefix, or one the border router invents | your router, or the border router | controllers reaching Thread devices and being reached back |
The OpenThread addressing primer covers the Thread-internal types, but only the last two rows touch your LAN. The OMR prefix makes a battery sensor addressable from a controller on Wi-Fi, and the on-link prefix gives that controller an address the sensor can answer.
For the border router’s role and hardware setup, use the Thread border router guide. The checks below focus on whether the controller receives usable addresses, routes and discovery traffic.
Where it breaks in practice
Routers and access points. Google’s Nest support page describes the failure shape: without IPv6 on the home wireless network “the setup process may initially appear to succeed at times. However, control and other functionalities eventually fail” (Google Nest Help). Commissioning gets by on Bluetooth and link-local traffic. Steady-state control needs the routable addresses and the multicast discovery. Home Assistant adds that any router or access point setting to “optimize” multicast “can harm the (discovery) traffic from Matter devices” (Home Assistant). On UniFi, the Multicast and Broadcast Control toggle blocks exactly this traffic unless you allow each device, which the UniFi advanced wireless settings guide covers. The Matter Server docs go further and say not to enable UniFi’s mDNS forwarder at all, since forwarders “tend to corrupt or severely hinder the Matter packets” (Matter Server OS requirements).
VLANs. The same document says Matter “uses link-local multicast protocols which do not work across different LANs or VLANs,” and Home Assistant asks that Wi-Fi Matter devices, border routers and the Home Assistant host share a VLAN. An IoT VLAN is fine. Put the controller and every border router inside it, or accept that mDNS reflection is a workaround the Matter server maintainers tell you not to use.
The host. On Home Assistant OS, IPv6 has to be on under Settings, System, Network, and the Thread docs note that Docker’s IPv6 may need enabling separately with ha docker options --enable-ipv6=true and a reboot. A container on a NAS is the worst case: “the host kernel may be missing the IPv6 routing support that Thread requires,” so devices pair and then sit unreachable, and the Matter Server docs advise against a NAS operating system entirely. They also want NetworkManager 1.42 or newer, because older releases lose the routes learned from advertisements. If that pushes you toward a different install, the Home Assistant OS versus container comparison lays out the trade.
Discovery configuration. The 1Home network diagnostic guide also identifies multicast-to-unicast behavior, snooping settings and a DHCP domain ending in .local as possible discovery problems. The .local suffix is reserved for mDNS. Do not disable all multicast controls indiscriminately: compare behavior on a simple shared LAN, change one relevant setting at a time, and restore unrelated settings when they make no difference.
Router advertisements on the host. The OpenThread codelab documents accepting router advertisements and their route information. Its Linux example uses accept_ra of at least 1, or 2 when forwarding is enabled, and accept_ra_rt_info_max_plen of at least 64. Confirm what your network manager applies; a setting that is overwritten after a reboot does not establish a persistent route.
The ISP. This requirement does not exist. Home Assistant states it directly: “There is no requirement to have an IPv6-enabled internet connection or DHCPv6 server.” If your router has a single IPv6 switch, leave it on anyway. You are keeping it for the LAN behaviour, not for the internet.
A five-minute check
- Confirm IPv6 is enabled on the controller host and on the Wi-Fi network the border routers use, with client isolation off on that SSID.
- Check the discovery controls described above. Begin with controller, border router and devices on the same LAN, then change only settings implicated in that path.
- On a Linux controller host, confirm advertisements are accepted and a route for the Thread OMR prefix exists via the border router’s link-local address:
ip -6 addr show
ip -6 route show
sysctl net.ipv6.conf.eth0.accept_ra net.ipv6.conf.eth0.accept_ra_rt_info_max_plenReplace eth0 with your interface. A typical ULA setup shows the Thread OMR /64 route via the border router’s link-local next hop, learned from a router advertisement. Match it to the actual advertised prefix; an fd prefix alone does not identify the correct mesh. If it is missing, the advertisements are not arriving or the host is discarding them, and no amount of re-pairing will fix that.
- Check that the host has a routable address of its own, a ULA from the border router’s prefix or one from your router. Link-local alone is enough to commission and not enough to keep talking to Thread devices.
If the check passes and devices still vanish, the fault is above this layer. The pairing failure fix list and why Matter devices keep going offline pick up from there.
