The Role of Private Networks in Securing IPv4 vs. IPv6 Deployments
Written by: Jason Segarra
Published: October 5, 2021
IPv4 is the fourth generation of Internet Protocol. Since 1983, it has been the primary network layer protocol used to power the internet and other packet-switched networks. Its defining characteristic is its use of 32-bit addresses (Example: 192.0.2.38) that allow devices to connect to the internet by sending data to and receiving data from websites, file servers, and other network devices, via their respective individual IP addresses.
While IPv4 has become ubiquitous with the internet, it was originally designed for small-scale networks. As the internet has grown beyond all expectations, the limits of IPv4’s address space have presented some technical challenges. A newer version of Internet Protocol, IPv6, was designed to alleviate some of these issues. But does that mean you should choose IPv6 over IPv4 for your IoT solution? The short answer is not really. Either protocol (or even both) is fine for IoT. The key is to configure the interfaces and network properly and securely.
Though that may sound surprising, given the tens of billions of devices that are currently connected to the Internet. Let’s take a look at why.
IPv4’s limited address space
When IPv4 was embraced as the foundation of the internet, the fact that its 32-bit address space would only yield around 4.3 billion unique IP addresses was a non-issue. As time moved on, however, more and more users began connecting to the internet, resulting in a boom in the number of smartphones, tablets, and other connected devices. As all of these devices require an IP address, the end result is that the number of addresses available under IPv4 infrastructure has been completely exhausted.
To help address this issue, a number of IP address ranges have been dedicated for use within private networks. These private IP addresses can be used by each network without a conflict with any global IP address employed elsewhere. Network administrators can assign addresses in these ranges as they like, provided that a private IP address assigned to a specific device still remains unique within its own private network.
In order for devices with private IP addresses to be able to communicate with the internet (or an external network in global IP address space), private networks need to employ Network Address Translation (NAT). NAT is a function, commonly handled by a gateway or router, that takes a packet from a device within private networks, translates its source IP address to a global IP address before sending it out to an external network. It then keeps track of which private IP address the response packet should be forwarded to once received. NAT allows users to connect multiple devices to the internet or an external network using a single public IP address. It is used just about everywhere, from homes, to businesses, and even public WiFi at cafes and libraries.
Private Networks and IoT
At first glance, the use of NAT might seem like a mere workaround to prolong the life of IPv4. The reality is that it hides the hosts behind the NAT gateway from external networks. As a result, it creates a private network where you are in control of both the devices within the network as well as the network itself.
NAT as a mechanism for supporting multiple hosts to connect to the public internet and/or an external network has increased the scalability of IPv4 networks and made it possible to connect more devices than the 32-bit address structure had initially suggested. Furthermore, NAT helps protect hosts behind a NAT gateway by blocking unauthorized connections from ever making their way into the network, let alone reaching any of the devices within (often referred to as a “stateless firewall”).
Given that the average cost of a data breach is currently estimated to be around $4.2 million USD, security has to be a developer’s top priority – especially for IoT projects. By designing your IoT architecture to use a private network from the ground up, you can drastically reduce, if not outright eliminate, most of the attack vectors that have crippled countless IoT projects. By incorporating NAT as well, you can achieve a highly scalable and secure network even with IPv4.
Even though IPv4 with NAT can connect more hosts than the 32-bit address space initially suggested, the downside is that a host behind a NAT gateway cannot be reached from an external network without some way to traverse NAT.
What about IPv6?
The sixth iteration of Internet Protocol, IPv6, was designed primarily to address the limits of IPv4’s 32-bit IP address space. By utilizing a 128-bit address (represented as a hexadecimal string), IPv6 is able to provide roughly 340 undecillion unique addresses, or about 79 billion, billion, billion times as many as IPv4.
With this seemingly inexhaustible supply of alphanumeric combinations, the designers of IPv6 envisioned a future where every device had its own globally unique IP address. This would theoretically do away with the need for private networks and NATs, as every device could be uniquely identified in order to send and receive data, regardless of how it is connected to the internet.
But do we really want to get rid of private networks altogether? In a word, no. With every device having its own globally unique IP address, connecting them directly to the internet exposes them to the same security risks as a device connected directly to the internet with an IPv4 address.
If direct peer-to-peer access among devices or making devices accessible from the public is not what you want, then one of the most attractive features of IPv6 — its inexhaustible number of global IP addresses — is suddenly not as appealing.
As such, when building an IoT system where security is the top concern, the version of IP protocol upon which the architecture is built is largely irrelevant. Whether it is IPv4 or IPv6, the network and its devices will need to be properly configured to be truly secure.
The Challenges of Private Networks in cellular IoT
Now that we’ve established that a private-networking-first approach helps protect our devices, let’s take a look at some of the common challenges when we throw cellular connectivity into the mix.
When setting up a private network at home or in an office, you or your IT administrator should maintain control of both the devices connecting to the network as well as the network configuration itself.
If you were to take a look at your smartphone’s cellular IP address (when it’s disconnected from your home WiFi), you may see a global IP address. It is also possible that you may see a private IP address (e.g. an IP address in 10.0.0.0/8 private IP address range). This is an indication that your cellular connectivity provider is using a private network and NAT. Unlike your private network at home or work, however, your provider maintains control of both your cellular device’s private network configuration, as well as which devices can and cannot connect to it.
If your cellular provider assigns private IP addresses to cellular-connected devices, incoming connections are blocked by default by your provider’s NAT and stateful firewall. That means devices are secluded away from the public Internet by default, which is a good thing in terms of security.
However, unlike a smartphone that is typically within arm’s reach and used mainly for internet services, IoT introduces different architectural and logistical challenges. These include remotely connecting to devices located on the other side of the world for troubleshooting, something that is blocked by the NAT and stateful firewall of the provider. One way to do it is to create a private network for your devices and your servers, so that they can communicate with each other securely, while isolating them from the public Internet.
As most telecom providers control the configuration of the cellular private network, a traditional approach for enterprise companies in the IoT/M2M space is to utilize private APNs and Virtual Private Network (VPN) connections. A dedicated gateway is assigned to a private APN, and traffic from devices using the private APN is segregated from the cellular traffic of other customers. VPNs, meanwhile, establish a secure link between the gateway (or a VPN router behind the gateway) and your on-premises network or virtual private cloud (VPC), in order to send and receive data without using the internet and remotely access devices when needed.
Unfortunately, private APNs and VPNs often come with significant set up costs and lengthy commitments – largely because the cellular connectivity provider needs to set up dedicated network elements and maintain them on your behalf. For IoT deployments or developers who are starting with just a few devices (or only require these features sporadically), these costs and negotiation hurdles often prevent a private-networking-first approach from ever being considered.
The Soracom Solution
Unlike private APNs – which are often the only way a cellular connectivity provider can offer private networking for cellular devices – Soracom’s Virtual Private Gateway (VPG) segregates your cellular traffic from other customers’ cellular traffic, and puts you in full control of that private network. Just like the ability to create virtual machines that developers have come to expect from cloud service providers, VPGs can be created on-demand, without any applications or contracts, and with the same pay-as-you-go pricing that helps lower the bar of entry to developing private network solutions.
With VPGs, you have the ability to control your device’s IP addresses, filter or even block internet access, and control device-to-device access, just like you would with your own private network. Even better, Soracom Peek gives you the ability to capture packets directly inside the VPG, an essential troubleshooting tool that often isn’t even possible with a private APN.
VPGs also let you connect your devices to your own private network. In addition to VPN connectivity provided by Soracom Door, you can use Soracom Canal to connect your VPG directly to an AWS VPC, and Soracom Direct to connect to your datacenter using a dedicated fiber channel.
Best of all, cellular connectivity to the VPG can be fully controlled from the web-based Soracom User Console, meaning that you can start without a VPG and transition to one later. You could even create one VPG for testing and another for deployments and seamlessly move devices from one to the other, all without changing APN or other configuration settings on the device itself.
Even if private networks are not critical to your project (which it should be!), Soracom provides a host of other platform services, such as Funnel and Funk for securing the connection from your devices to popular cloud services without needing to worry about data security or encryption, and Napter for remotely accessing devices on-demand without the need for exposing them with a public IP address, which help to keep your devices secure.
Conclusion
Ultimately, both IPv4 and IPv6 are perfectly viable network layer protocols for any IoT project. When it comes to security, however, it’s more a matter of configuration. Keeping devices off of the public internet is the best way to secure your deployment, so investing in solutions that route your data where hackers cannot reach it is a great place to get started.
………………
Got a question for Soracom? Whether you’re an existing customer, interested in learning more about our product and services, or want to learn about our Partner program – we’d love to hear from you!
