Running NAT64 in a dual stack network(5 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.

Network with IPv6 and dual stack devices using NAT64 to access an IPv4 server, with IPv4 devices using NAT44

Continue reading Running NAT64 in a dual stack network(5 min read)

Smart Buildings — Running an OpenThread Border Router(18 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.

Thread layers: UDP, IP Routing, 6LowPAN, and cross-cutting Security/Commissioning, with non-Thread layers beow IEEE 802.15.4 MAC and IEEE 802.15.4 PHY, and non-Thread applications layer above

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 Atom NB-IoT device with secure MQTT over IPv6(20 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.

M5Stack Atom DTU NB-IoT with Telstra SIM card

Continue reading M5Stack Atom NB-IoT device with secure MQTT over IPv6(20 min read)

Deployment ready NB-IoT device review — Unboxing the Dragino N95S31B(14 min read)

The Dragino NBSN95/NBSN95A family is a deployment-ready range of water resistant NB-IoT (Narrow Band Internet of Things) devices that are available pre-packaged with various sensors such as soil moisture, distance detection, liquid level, and temperature/humidity sensors.

NB-IoT is a Low-Power Wide-Area Network (LPWAN) technology that allows devices to be accessed in remote locations and operate on battery for long periods of time, up to many years.

In this article we will look a the N95S31B, the model with the pre-packaged temperature/humidity sensors, the strengths and weaknesses of the device, and then walk through configuing the device and see it connect to an MQTT test server. Our previous article showed you how to set up an MQTT test server on Azure if needed.

The NBSN95 is an open source project, with both the software and hardware specifications available, if you need to customise the application. We have also previously reviewed the Dragion LDDS75 LoRaWAN device.

Dragino wiring the serial connection

Continue reading Deployment ready NB-IoT device review — Unboxing the Dragino N95S31B(14 min read)

Deploying a secure MQTT test server on Azure with IPv6(15 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 login
az account set --subscription <subscription id>
$VerbosePreference = 'Continue'
./azure-landing/infrastructure/deploy-network.ps1
./azure-mosquitto/infrastructure/deploy-mosquitto.ps1 YourSecretPassword

Read on for the full details.

Continue reading Deploying a secure MQTT test server on Azure with IPv6(15 min read)

Instrumenting .NET with OpenTelemetry(15 min read)

In this post we will cover how to the the built in support for OpenTelemetry in modern .NET to instrument your distributed application for tracing and logging, how the OpenTelemetry Collector can be used to simplify instrumention, and how the OpenTelemetry Protocol is building a (brilliant) connected future.

We have already seen how distributed tracing is supported in .NET via W3C Trace Context propagation, with automatic (or mostly automatic) support across HttpClient calls and messaging.

We will now go further than logging and look at tracing. Tracing looks at the different units of work (spans) done during an operation (trace), how they are connected, and the timings of the different components. This is an important tool for investigating performance issues in distributed systems.

An example distributed trace timeline, across multiple components, viewed in Jaeger, one of many supported tools:

Example Jaeger trace output

As well as looking at individual traces timings can be aggregated across the system to find the slowest areas, and identify anomalies.

Continue reading Instrumenting .NET with OpenTelemetry(15 min read)

Open source alternatives to Dungeons & Dragons(12 min read)

Dungeons & Dragons (D&D) is easily the most widely played roleplaying game in most places (except for Call of Cthuhu in Japan) however there are thousands of alternatives.

In this post I will highlight a few open gaming alternatives, all highly rated (either the game itself, if fully available, or if just and SRD the commercial game it is derived from is highly rated).

  • Fate
  • Open Basic (d100% / Basic Role-Playing)
  • Dungeon World (Powered by the Apocalypse)
  • Blades in the Dark (Forged in the Dark)
  • Gumshoe System
Update (2023-01-28): The Dungeons & Dragons SRD 5.1 is now avaliable under a Creative Commons Attribution license.

Continue reading Open source alternatives to Dungeons & Dragons(12 min read)

LoRaWAN to Azure IoT — Unboxing the Dragino LDDS75(17 min read)

LoRaWAN devices are a popular solution for IoT, with many benefits, but they cannot connect directly to Azure IoT.

LoRaWAN devices communicate using LoRa to a local LoRaWAN gateway, which then communicates using standard protocols to a LoRaWAN network server. Only then can it be converted to a suitable IP-based protocol to connect to Azure IoT.

Even if they did share a common network, LoRaWAN IoT devices are often small, low-power, battery operated devices that operate in short bursts of minimal communication, and not the verbose communication expected by Azure IoT, so you would want to use a gateway anyway.

To test out connecting field-ready LoRaWAN devices to Azure IoT, I ordered a Dragino LDDS75 LoRaWAN Distance Detection Sensor, used to measure the distance between the sensor and a flat object. It can be used for both horizontal and vertical distance measuring, such as liquid level measurement or object detection (e.g. parking space).

Unboxing the Dragino LDDS75 Distance Detection Sensor

The Dragino platform uses open source hardware, with Dragino schematics and details fully available on github, although you are probably better off purchasing one than trying to build it yourself.

I set up the device up using The Things Network, a community network suitable for small scale testing, connected to Azure IoT.

Dragino, The Things Nework (LoRaWAN Gateway and LoRaWAN Network Server), and Azure IoT architecture overview

Continue reading LoRaWAN to Azure IoT — Unboxing the Dragino LDDS75(17 min read)

Securing your IPv6-only docker server(8 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)

The end of 3G for IoT(10 min read)

3G (3rd generation mobile technology) networks for the major telecommunication companies are due to shut down over the next few years. This includes Telstra, whose network is now in the sunset phase and due to close in June 2024.

This will mean the end of 3G for Internet of Things deployments, and they will need to migrate to either LPWAN (Low-Power, Wide-Area Networks) or new generation cellular mobile, depending on the use case.

As pointed out in this article on Why you need to migrate your devices now! that does not give a lot of time. If you have 15,000 devices in the field you need to be replacing 30 devices per day — if you start tomorrow; more if you take long to commence your project.

The are three main options for migration, in two categories:

  • LPWAN
    • NB-IoT (Narrow-Band Internet-of-Things)
    • Cat-M1 (Category M1), also known as LTE-M (Long Term Evolution, Category M)
  • Cellular Mobile
    • 4G LTE (4th Generation) mobile

This post will explore those options in a bit more detail, as well as what other alternatives there might be. 5G NR (5th Generation New Radio) does not yet have wide enough coverage to be a viable option for IoT in most cases.

If this seems a bit overwhelming, given the short time frames and what you need to do, then you can also approach our consulting services, Telstra Purple, for advice and help.

Continue reading The end of 3G for IoT(10 min read)