Over the past 15 years the team at M2M Connectivity & M2M One have coached, consulted, celebrated and at times commiserated with thousands of hopeful developers trying to make their mark on the Machine to Machine /Internet of Things landscape.
This series of blog posts is designed to pass on some M2M 101 style tips to developers looking to get into the space.
This week’s question is around IP address allocation for M2M/IoT devices:
“What are your options? What are the associated costs? And what are the long-term implications?”
To IP or NAT to IP… (Ok that was terrible, I’m sorry)
The first thing I want to achieve with this post is to address some common questions we get asked on a daily basis when it comes to IP addressing.
1. Where is IPv6? – To most people involved in IP networking, especially in the M2M space this has been the Holy Grail for the past 3 years but in reality there is still some way to go from a hardware and network architecture perspective for it to be commonplace. I know the IoT is going to be a big factor in driving IPv6 uptake but from a cellular M2M perspective it’s all IPv4 all the time… for now.
2. Gimme that Public Static IPv4 address – Looks good, sounds good but in reality it’s hard to find due to the lack of IPv4 addresses, the cost of maintaining those addresses and the various security issues related to having a permanently discoverable IP address, which I’ll discuss a little later.
3. My device is useless without an addressable IP – This is possibly the biggest misconception around IP addressing in M2M. Yes being able to address a device when needed is useful, but there are literarily millions of devices that function just as well by initiating communications remotely without needing to be poked or prodded by you or your server.
So what are your options when it comes to IP addressing and management for M2M/IoT devices? Please keep in mind that I’m not a network engineer so these are my limited technical interpretations of M2M IP addressing.
Public Internet Access via NAT with dynamic private addressing
Pros | Cons |
|
|
This is the most common solution we see for M2M devices, as it requires very little effort in terms of set up and cost. It basically utilizes common carrier APNs (the same as you would see on a phone or tablet SIM) to give an M2M device access to the public Internet to send and receive data.
The IP address of the SIM is hidden behind the networks firewall so the device can’t be addressed directly across the public internet, which means all devices with this setup need to initiate a communication session with the host service/client.
Example: M2M One would issue a SIM with our common internet APN (telstra.internet or telstra.m2m) and the customer would then program their device to initiate communication using one or both of these APNs. When the device calls in, it then exposes it’s IP address to the host allowing two-way communication.
Public Internet Access with dynamic public IP
Pros | Cons |
|
|
Another popular solution, if you can get it. Again popular because it costs very little in terms of set up and monthly on goings. The difference here is that while it still uses the public Internet over a common APN, it allocates a publically addressable IP address.
The issue that then needs to be overcome is the fact that the IP address changes, usually with each new session. This means that it is impossible to accurately address a device without using a DynDNS server to allocate a fixed address/name to an asset.
Another issue is that due the increased amount of bot and sniffing traffic on the Internet, most public IP addresses are scanned at some point. This can cause a device to respond; even though it is not sending any data an acknowledgement still utilizes resources on a public network, which can drive up monthly data costs. We have seen customers who typically use around 5MB per month go up to 20 or 30MB when using public IP addressing.
Example: M2M One would issue a SIM with a dynamic public APN (telstra.extranet), when the device first connects to the internet the customer can poll the device or utilize the M2M One Control Centre to find the IP address of his unit. This can then be added to a DynDNS server and the IP managed by a client on the device, which updates the server whenever the IP address changes, but maintains an addressable name/alias.
Private Static IP Addressing
Pros | Cons |
|
|
Due to the lack of IPv4 space this is most often the only solution for customers who absolutely need a completely static addressable IP. The customer is assigned an IP range, usually on a private APN this allows each device to be given it’s own unchanging IP address.
The problem is that these IP addresses exist in a private space meaning they can not be accessed from the “outside world” this makes them extremely secure but means that you need a method of getting in to the private IP space. This is typically achieved through a VPN tunnel but can also be done on a peer-to-peer level by using a centrally allocated router configured on that IP space to talk to all other devices in the field.
Example: M2M One would issues a SIM with our private APN and an IP range to a customer. M2M One would then allocate a private IP address to each of their devices in the field, by configuring a VPN between their server and IP subnet they can communicate with each device in a private closed loop environment with fully encrypted traffic traveling back to their server.
Hopefully this post hasn’t caused too many people far more technical than me to shout at their screen and spill their coffee, but if it has please feel free to comment and share your knowledge and expertise!