Matter and Thread offer many benefits, with standardised interoperability, local-only control, built-in security, multi-admin, and IPv6 support — helping drive IPv6 adoption and development skills.
Several devices have now launched, and I have tried out a few of the available devices with Google Home and Home Assistant, however these are early days, and feature implementation still lags behind native integrations in some significant areas.
- Nanoleaf Essentials light bulb and LED light strip
- Eve Home smart plug
- Sonoff MINIR4M inline switch
- Zemismart ZME2 dual inline switch
- Wiz light bulbs
- Tapo P110m smart plug
Most devices initially required their native app for firmware upgrades (although the new Eve device updated without it), and there were many features only accessible via native apps (even where the features are in the Matter standard).
In particular none of the switches had separate switch and relay parts for detached operation via Matter bindings, although the Sonoff does support detached mode via the native app, and the Zemismart had the Binding cluster but I couldn't get it working.
Continue reading Hands on with Matter and Thread(11 min read)
Security is an important topic for the Internet of Things, and there are several considerations to secure device identity. A good practice is to use secure protocols (such as TLS or DTLS) for transmitting any sensitive information over the network and to ensure that passwords and other sensitive information are securely stored.
This article will provide an example of using X.509 client certificates for connecting to Azure IoT, using the Nordic Thingy:91 platform. The certificates are securely loaded directly to the device, so they are not exposed in the device firmware.
Using certificates allows a hierarchy of trust to be established, allowing system owners to delegate certificate management to third parties while retaining control of the root trust.
The article also covers the usage of IPv6, and accessing IPv4 servers from the Telstra IoT network, running in IPv6-only mode and using NAT64.
Continue reading Device Authentication with Nordic Thingy:91 and Azure IoT Hub(22 min read)
Network address translation 6-to-4 (NAT64, RFC 6146) is a transition technology that can be used, in conjunction with DNS64 (domain name system 6-to-4, RFC 6147), to replace NAT44 in dual-stack networks, and allowing support of IPv6 only devices.
Dual stack is a common deployment solution for adding IPv6 for both consumer and corporate networks, although IPv6-only is becoming more common, with the typical guidance being "IPv6-Only Where You Can, Dual-Stack Where You Must"
Even if you are still stuck in dual stack, it still makes sense to use some of the IPv4 as a Service technologies, such as NAT64 and DNS64, which have the upside of allowing you to support IPv6 only devices, and no downside. As an additional benefit, you also get valuable experience in IPv6 systems.
The cost is that you need to have infrastructure that supports NAT64, either provided by your ISP, or from your own networking equipment/router. This is not as much an issue for DNS64, as public DNS64 is available, e.g. Google.
If your network supports it, look at implementing NAT64 + DNS64 today; if it does not, contact your equipment provider to find out when they will support this important technology for IPv6.
Continue reading Running NAT64 in a dual stack network(5 min read)
Thread is a mesh networking stack running on 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) over IEEE 802.15.4 radios. To connect to the broader network, a Thread Border Router is required, which acts as a gateway between the Thread mesh radio network and upstream networks.
Thread, especially when used with Matter, is an important development for home automation, however the technologies also have commercial applications. The initial commercial focus of Thread is for smart buildings.
The networking layer sits between the underlying physical network, and the application layers on top.
Matter is an application protocol for device automation that runs on top of Thread (and also WiFi), with Bluetooth used for device commissioning. Matter 1.0 was also released in October 2022 and is supported by major home automation vendors (Google, Amazon, Apple, and Samsung), but can also be used in commerical deployments.
When provisioning a Matter device to a Thread mesh, Bluetooth is used for the initial provisioning and sets up both the connection the the Thread mesh and registration in the Matter Hub. One important aspect of Matter is multi-admin, allowing one device to be controlled by multiple hubs.
The layered approach means Thread can be used by itself, providing mesh networking for smart buildings using other protocols, or in conjunction with Matter.
The article also looks at setting up a OpenThread Border Router for testing, and shows provisions a Matter test device to the Thread mesh.
Continue reading Smart Buildings — Running an OpenThread Border Router(18 min read)
M5Stack produce a suite of pilot-suitable modular IoT devices, including the Atom DTU NB-IoT. The NB-IoT DTU (Narrow Band Internet of Things - data transmission unit) comes in a small 64 24 29mm case with a DIN rail clip on mounting and support for RS-485 including 9-24V power (or USB-C power).
The kit base has a SIM7020G modem and the ESP32-based Atom Lite (which also supports WiFi) is included with a very resonable price. The device has built in MQTT, supports secure public certificate TLS connections, and supports IPv6.
While the physical unit is ready for pilot deployment (and the M5Stack website has several commerical deployment case studies), there is no pre-written firmware for the device, so some up front development is needed.
As well as reviewing the strengths and weaknesses of the device, I will also provide some sample code for a proof-of-concept using an Env III environment sensor to transmit temperature, humidity, and air pressure to an MQTT test server using MQTTS (with server certificates), over IPv6, over NB-IoT.
Continue reading M5Stack Atom NB-IoT device with secure MQTT over IPv6(20 min read)
MQTT (originally Message Queuing Telemetry Transport) is an important protocol for IoT that has been widely adopted. Devices deployed to the field may be connecting to existing MQTT endpoints, however you may also want to deploy your own MQTT server for testing purposes.
This article shows you how to deploy an Eclipse Mosquitto MQTT server onto Azure, configured for secure connections (MQTTS, which is MQTT over TLS), accessible over the internet, and including support for both IPv6 and legacy IPv4.
First we will configure a network in Azure, then deploy the server, and then test the deployment.
The instructions below show the individual commands, but if you want a quick start then full scripts, with automatic parameters, are available on Github https://github.com/sgryphon/iot-demo-build/blob/main/azure-mosquitto/README-mosquitto.md
To deploy the network and then server components via the scripts:
az account set --subscription <subscription id>
$VerbosePreference = 'Continue'
Read on for the full details.
Continue reading Deploying a secure MQTT test server on Azure with IPv6(15 min read)
It is important to ensure your IPv6-only docker server is secure.
First configure your firewall to allow secure shell (SSH), port 22, so that you can maintain your remote connection.
Then turn on your firewall with default deny incoming and default deny routing rules.
This ensures your server is secure-by-default, and only then should you allow routing to the specific containers and ports that you want to expose.
My server runs Ubuntu, so these instructions are based on the Uncompliciated Firewall (UFW), but similar considerations apply to other platforms
Continue reading Securing your IPv6-only docker server(8 min read)
I have previously blogged about why you should consider IPv6 only hosting and setting up Apps on Kubernetes IPv6 to run my WordPress blog.
Kubernetes is not really designed for a single server (but is great for scaling and enterprise system), and although it was good experience learning how to set it up on IPv6, the overhead was too much and I eventually ended up with a crashed blog.
I'm still running IPv6 only, but with a much simpler set up.
This consists of docker, configured to run with IPv6, with docker-compose to run the different components and systems.
If you are planning on setting up your own server, read my notes on Securing your IPv6-only docker server before starting.
On my server there are currently three instances of WordPress for different websites, and 3 corresponding databases, as well as a Matrix Synapse server and plugins.
Read on for my notes on initial setup of the server with IPv6 and connectivity testing, including addressing schemes, docker configuration, IPv6 network address translation, and the Network Discovery Protocol Proxy Daemon.
Continue reading Running an IPv6-only host — redux(11 min read)
Once you have Kubernetes running on IPv6 only the next step is to install some apps.
This is my first post written on my new WordPress instance, hosted on Kubernetes IPv6 only. If you are reading it, then it is working 🙂
Of course apps have their own issues not being configured by default to work with IPv6, so for each app you need to test and work out what configuration details need to be tweaked (assuming the app supports IPv6 in the first place).
To start off with, I installed Kubeapps, to get an application management dashboard, and then used that to install WordPress.
With WordPress installed, I exported the content from my old blog and then imported it into the new instance, and tweaked a few WordPress settings.
The final step was to configure the Mythic Beasts reverse proxy, to make my blog available for legacy IPv4 users.
Continue reading Apps on Kubernetes IPv6 – Kubeapps, WordPress(8 min read)
Kubernetes is an open source platform for managing containerised applications.
IPv6 is the next generation Internet protocol, and running on IPv6 only simplifies configuration and administration, and avoids the performance issues and complexities of IPv4 encapsulation, NAT, and conflicting private address ranges.
The default configuration of Kubernetes is IPv4, and there are few, and scattered, examples and guidance for setting up IPv6 dual stack, let alone single stack.
I have collected instructions from the different sources into a single guide to successfully deploy Kubernetes with IPv6 only.
See the guide for full instructions:
The blog post contains some additional background on what I did to gett the deployment working. The deployment was tested on Ubuntu 20.04 running on an IPv6 only virtual server from Mythic Beasts.
Continue reading Kubernetes on IPv6 only(9 min read)