Supporting Thread in particular is an interesting choice, because as far as I'm aware Thread is one of the most open-source IoT stacks[0]. Thread isn't really used in consumer hardware, which is probably the reason it's so obscure within the hacker community, but there's a lot of buzz around it within industry groups. Companies like Google, ARM, Amazon, LG, NXP, Samsung and many others are supporting the development of Thread.
What's interesting about Thread is that it takes advantage of IPv6 to allow any device on a network to talk to the World Wide Web. Usually, you can only talk to your IoT gateway over the web, and then tell it to control its children. Thread simplifies all of that and lets you directly talk to any child via its IPv6 address[1].
Compared to some other IoT protocols, Thread also takes a strong stance on security: unlike other protocols such as Bluetooth Low Energy, you cannot create an unsecure Thread network[2], you must have the correct credentials to talk to any Thread network, and all communications are encrypted.
I believe that Thread is going to be a very important part of the future of IoT, and I'm excited to see what comes next.
> Usually, you can only talk to your IoT gateway over the web, and then tell it to control its children. Thread simplifies all of that and lets you directly talk to any child via its IPv6 address[1].
But I don’t want every one of my potentially buggy IoT devices to be directly addressable on the Internet.
Ideally they’d each be isolated, with the minimum connectivity needed to the hub.
Yes, you can isolate individual devices the same way you'd isolate any IPv6 device on your home network - using a firewall. Normally you would firewall away your entire home network and only open up connectivity to the devices you want.
Additionally, you can configure the firewall on the Border Router as well, which is the device that actually interfaces between Thread and other networks.
That's a shot in the dark, but I may ask it here: Do you have a simple documentation that would tell someone who knows how to route an IPV4 network and avoid the pitfalls, what is the correct way to do it in IPv6? I struggle to find a good summary of the things one needs to know
IPv6 is weird for someone coming from IPv4. Basically every IPv6 address is a public IP address. Your firewall is responsible for blocking inbound traffic from actually getting to the devices at these addresses. This replaces NAT.
So, what I do is have a default rule that blocks all IPv6 traffic inbound. Then, instead of a NAT rule, port forwarding, etc., I just allow inbound traffic on certain ports to certain addresses.
Thread uses something called a Border Router to handle the Thread Network / Home Network communication. The end devices can only communicate with the router, which then could make a potential http request or whatever. Giving an end device direct web access would have to be a deliberate move.
What's interesting about Thread is that it takes advantage of IPv6 to allow any device on a network to talk to the World Wide Web. Usually, you can only talk to your IoT gateway over the web, and then tell it to control its children. Thread simplifies all of that and lets you directly talk to any child via its IPv6 address[1].
Compared to some other IoT protocols, Thread also takes a strong stance on security: unlike other protocols such as Bluetooth Low Energy, you cannot create an unsecure Thread network[2], you must have the correct credentials to talk to any Thread network, and all communications are encrypted.
I believe that Thread is going to be a very important part of the future of IoT, and I'm excited to see what comes next.
[0] https://openthread.io/
[1] https://www.threadgroup.org/What-is-Thread
[2] https://www.threadgroup.org/Portals/0/documents/support/Thre...