Thread is a fast growing wireless protocol for low power IoT networks. It’s a feature of Matter, which can also use BLE and Wi-Fi. Similar to Zigbee, Thread uses 802.15.4 for its PHY and MAC, but an important difference is that it uses 6LoWPAN for the network layer, so IPv6 addressing is used for all Thread devices. That’s IPv6-only, but more on that later.
Having recently deployed a home Thread network managed by Apple HomeKit, I wanted to see what I could discover about its operation. Below are some tips and interesting findings. Maybe this isn’t particularly useful information, because Apple’s implementation requires very little from the end-user and couldn’t be simpler to use. It really is as close to “It just works” as I’ve experienced with a wireless network, but if you want to peek behind the protocol operation curtain a bit, you might find this interesting.

Network Discovery
An easy way to start discovering a HomeKit Thread network is with the Eve iOS app. The Thread Network option in Settings shows each device in the Thread Network, their role, capabilities, how their traffic is routed, and their 802.15.4 short address. You can get a good idea of the network topology here. Perhaps in the future Eve will build a visualization of it.


mDNS is used for network layer device discovery in a home Thread network, so you don’t need to use a Thread device to find other Thread devices. On a Mac, I use Discovery.app on the same network as the Thread Border Router to inspect the openthread.thread.home.arpa domain.
There is a lot to learn from this! The _hap._udp. service shows all the Thread endpoint devices. The hostname and MAC address of each device is there, along with its IPv6 address(es).
_meshcop._udp. will show the Border Router(s). MeshCoP is the Thread Mesh Commissioning Protocol, and the information shared here is a little like a Wi-Fi AP sharing network information in beacon and probe response frames, but this is much simpler. Here’s a look at everything advertised by an Apple TV 4K acting as a Thread Border Router.
The Border Router has internal Thread addresses and external LAN addresses. It also shares its extended 802.15.4 address, perhaps for OTA commissioning?
According to the Thread 1.1.1 Specification, The State Bitmap value 1 means:
1: DTLS connection to Border Agent allowed with a user chosen network Commissioner Credential and shared PSKc for the active Thread Network Partition
So somewhere a passphrase and PSK has been generated and delivered to each device, then it is used to authenticate and encrypt the commissioning session. Apple has handled this all behind the scenes and doesn’t expose any of it to end-users. This bit also has many other uses and I encourage you to download the spec and learn more about what it can signal.
Unlike Wi-Fi, there is no need for end-users to be aware of any of this information, which makes it so much more usable for non-IT people. End-users onboard new endpoints through scanning QR codes with an app, then everything else happens behind the scenes. Even the network name is hidden away. And really, why bother them with it? It makes me wonder how much of consumer Wi-Fi network management could be automated, removing the burden from end-users to understand it and make good decisions in using it. I bet if Apple ever makes Wi-Fi AP’s again, the user-experience will be more like Thread than what we have come to expect from consumer Wi-Fi.
IPv6 Addressing
In this network, all of the endpoint devices have a single ULA address, which is not internet-routable. The prefix was automatically generated, I assume by the Border Router? The LAN this Thread network is connected to is dual-stack IPv4/IPv6 with GUA and ULA addressing, so I assume the selection of a unique ULA prefix for the Thread network was by design.
All Thread devices appear to be reachable from outside the Thread network via the Border Router. “Router” is definitely the best name for this device, because it happily forwards packets to and from the Thread network without applying any security policy. Want to send thousands of packets to a low-power, low-capability Sleepy End Device (SED)? Sure, no problem.

While ULA-only addressing keeps traffic from the Internet away, it does mean that LAN traffic directed at Thread devices is possible. This accessibility is something to consider in future enterprise deployments. Just sending a lot of packets to a tiny battery-powered SED might disable it like a small-scale DoS, or eventually, through excessive battery drain. Any enterprise Border Router will need to have firewall functionality built-in.
So how are IPv6 packets getting into the Thread IPv6 network anyway? The Thread Border Router is sending IPv6 Router Advertisement packets to the outside LAN. Any modern device that receives that will update it’s IPv6 routing table with the new prefix, no matter how your LAN is configured. Think you don’t have IPv6 on your network? You do now. Thread requires IPv6.

The Border Router maintains IPv4 and IPv6 interfaces on the outside LAN. Other Thread devices that need Internet connectivity or have other non-Thread services can do this as well, but all Thread network traffic uses IPv6-only.
Without decrypting traffic over-the-air, I can’t tell if the Thread network is using SLAAC, DHCPv6, or both.
Capturing Thread Traffic OTA
Using a Nordic Semiconductor nRF52840 Dongle and their free nRF Sniffer for 802.15.4 software, I was able to capture encrypted 802.15.4 frames from this network. Getting the keys from HomeKit to decrypt this traffic is probably not possible, but there are some good use-cases for OTA packet capturing:
- Measuring RSS and LQI at a location to determine mesh coverage
- Determining the network’s operating channel
- Discovering the chattiest Thread devices on the network, which may be useful when planning network capacity
- Measuring packet counts, looking at the “busyness” of the network
- Validating any security policy that is applied to the Thread IPv6 network. You can try sending traffic to a device from outside the Thread network and see if it gets there. The packet rate is so low that its easy to identify new flows coming to a end device’s short address in real-time as traffic is generated.
- Diagnosing high retry rates (What is a high retry rate in 802.15.4?)

A few miscellaneous findings from capturing routine HomeKit Thread traffic:
- The battery-powered SED’s I observed were chattier than I expected, each sending a Data Request frame to its parent router every 5 seconds.
- Mesh Link Establishment (MLE) frames make up 20% of the frames, and the 6LoWPAN header of these frames is unencrypted
- So much in Thread is hidden behind encryption, don’t expect to learn as much about the network with OTA capturing as you might be used to with Wi-Fi