Recently I’ve been thinking about the difficulties of device discovery on a local network with DHCP, i.e. no static IPs. Especially with an IoT system you want to send out to a customer, prefilled with SSID and password information, who can just plug it in. This is the key requirement for IoT at scale.
For the answer, look no further than the humble printer.
As expected, it’s not just me who’s been thinking about this. An Internet Engineering Task Force (IETF) Working Group also known as Zeroconf addressed this issue from September 1999(!) to July 2003. One of their outputs was Multicast DNS (mDNS) and mDNS-SD (Service Discovery).
This technology was then picked up by Apple, became Bonjour, among others, and used for all their iTunes library sharing and iOS local networking, you see that fancy AirPrint button on your phone? That’s available thanks to the Zeroconf Working Group, though no doubt Apple would’ve come up with their own proprietary solution. Almost all printer manufacturers use this technology so you can print wirelessly without any configuration!
How does it work?
In a nutshell, each device that supports mDNS listens to UDP packets on port 5353. Every message that gets sent to the special IPv4 188.8.131.52 or IPv6 ff02::fb is sent to all the devices. When a device gets a packet asking for its service or hostname, it responds with its IP address. The mDNS hostname must end in the special suffix .local, it must be unique on the network, the logic for which must be handled by the device.
A service is a really useful component which each of your IoT devices can announce as available. This has info on the type of service (http printer etc), port it’s operating on. All the devices announcing a given service can be enumerated, even on a little embedded chip like an ESP8266 (code example).
However, one major drawback to mDNS is that it cannot work over different subnets. Is this an issue? Most standard consumer routers just have one subnet, so not at home. However, some enterprise networks (read:companies) put wireless devices on one subnet, and wired devices on another. If you’ve got a central box, say a credit-card sized computer that’s wired, and some other wireless IoT devices around the site. Then these are not going to be able to see each other’s
Remote Resolution of Local IPs
One solution to the subnet problem I think may be the following. Assume you have a central box on-site that collects data from a set of IoT devices, also on-site.
They may be on separate subnets due to being wired/wireless etc. But they all have a connection to the internet. You also have a cloud application that aggregates the data from these boxes. Let’s also assume you can’t control the DHCP functionality of the site network (you want to send your product onsite without any technical help, right?).
What if, instead of using the local network and mDNS to resolve domain names and discover networks, your onsite box and all your IoT devices register their IPs at an API endpoint on your cloud application. Which is always a Fully Qualified Domain Name (FQDN), so there’s no issue with hostname resolution.
Obviously there’s some security considerations to take into account with this approach, but I think it’s a simple solution to a complex problem, specifically with enterprise-grade complex networks.
What do you think? Send me an email with your questions!