IPv6 Requirements for Matter and Thread, Explained

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.

What a border router does to your LAN

Thread 1.3.0 made bidirectional IPv6 connectivity a certified border router feature, and the Thread 1.3.0 white paper spells out the sequence. The border router first asks your LAN router for a prefix through DHCPv6 prefix delegation. If it gets nothing, it “will generate a /64 ULA prefix” derived from the Thread network’s Extended PAN ID. It then listens for router advertisements on the LAN. If a router already advertises a usable prefix, meaning a Prefix Information Option with the on-link and autonomous flags set, the border router “refrains from providing routable unicast IPv6 addresses” to LAN hosts. If nothing does, it emits its own PIO so every host can SLAAC itself a ULA. In all cases it sends router advertisements carrying a Route Information Option, the RFC 4191 mechanism, telling every host that the OMR prefix is reachable through the border router rather than the default gateway.

The upshot is that a border router on a LAN with no IPv6 at all will manufacture the IPv6 it needs. What it cannot do is push those advertisements through an access point that drops them, a switch running RA guard, or a host that ignores them. The OpenThread codelab states what a Linux host needs: accept_ra of at least 1, or 2 if forwarding is enabled, and accept_ra_rt_info_max_plen no smaller than 64, with a warning that dhcpcd can silently override both. The border router guide covers the hardware side.

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.

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

1. 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.
2. Turn off multicast filtering, multicast optimisation, and any mDNS forwarder on the path between controller, border router and devices.
3. 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_plen

Replace eth0 with your interface. The route you want is an fd prefix with a /64, next hop fe80::something, marked proto ra. If it is missing, the advertisements are not arriving or the host is discarding them, and no amount of re-pairing will fix that.

4. 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.