Most connected-device projects never think about IP addresses until something breaks. A gateway that used to answer the back office goes quiet. A technician cannot open a session to a meter that is clearly online and reporting data. A platform that behaved fine at 200 devices starts losing return traffic at 20,000. Underneath a surprising number of these failures sits the same plumbing question: how each device gets an address, and whether anything on your side can still reach it.
That question is getting louder because the ground is moving under it. The regional internet registry APNIC, which tracks this shift, reported in April 2026 that around half of Google’s users now reach its services over IPv6. When half of one of the largest traffic sources on the internet runs on the newer protocol, IPv6 and IoT connectivity stop being a theoretical topic for standards people and become a planning decision for anyone shipping hardware at volume. This guide walks through what IPv6 is, why the old addressing model runs out for connected fleets, what IPv6 does and does not do for security, how it reaches battery-powered sensors, and the specific questions to put to a connectivity provider before you commit a deployment to it.
What Is IPv6, and How Is It Different From IPv4?
IPv6 is the current version of the Internet Protocol, the addressing system that lets any two devices on a network find each other. It replaces IPv4, the version that carried almost all traffic for decades, and its headline change is the size of the address. The specification that defines the protocol states that “IPv6 increases the IP address size from 32 bits to 128 bits, to support more levels of addressing hierarchy, a much greater number of addressable nodes, and simpler autoconfiguration of addresses.”
That jump from 32 bits to 128 bits is the whole story in one line. A 32-bit address gives you about 4.3 billion possible values. That sounded infinite in the 1980s and is plainly not enough for a world adding connected trackers, sensors, cameras, and meters by the millions every month. A 128-bit address gives you 2 to the power of 128 possible values, a pool so large it is effectively bottomless for any practical purpose. IPv6 addressing was designed precisely so that every device can hold its own globally unique address without anyone rationing the supply.
There are other differences worth knowing. IPv6 builds in stateless address autoconfiguration, so a device can generate a working address on its own without waiting on a central server to hand one out. It simplifies the packet header so routers do less work per packet. And it was written with end-to-end connectivity as the default assumption, which turns out to matter a great deal once you are running IPv6 for IoT at scale. The practical takeaway for a buyer is simpler than the specification: IPv4 makes addresses scarce and forces workarounds, and IPv6 makes them abundant and removes the need for most of those workarounds.
Why IPv4 Runs Out for IoT: NAT, CGNAT, and Lost Device Reachability
IPv4 exhaustion is the plain fact that the roughly 4.3 billion IPv4 addresses have already been handed out. The regional registries that allocate address blocks ran their free pools down years ago, and what is left trades on a secondary market at real cost. There is no path where the IPv4 pool grows to fit billions of connected devices. It cannot, so the industry papered over the gap with translation.
NAT (Network Address Translation) is the first layer of that paper. NAT lets many devices behind a router share a single public IPv4 address. The router keeps a table mapping internal devices to outbound connections and rewrites addresses on the fly. It works well enough for a home or an office because those devices mostly start conversations outward, to a website or a cloud service, and NAT can match the reply to the device that asked for it.
CGNAT (Carrier-Grade NAT) is the same trick applied one level up, inside the mobile operator. Because a carrier cannot give a public IPv4 address to every SIM, it puts thousands of subscribers behind a shared pool of public addresses. Your device gets a private address that exists only inside the carrier’s network, and the carrier translates on the way out. For consumer phones this is invisible. For IP addressing for connected devices it quietly removes something you often need.
Here is what it removes. Behind CGNAT, your device has no address that anything on the public internet can dial directly. Outbound polling still works, so a sensor can push readings to your platform. But inbound reachability is gone. You cannot open a session from your operations center to a specific field device, because that device has no publicly routable address of its own. Remote diagnostics, on-demand configuration, firmware pushes to a single unit, a live session into one troubled gateway: all of these get harder or need extra machinery to punt traffic back through the carrier’s translation layer. At small scale you improvise. At fleet scale, across thousands of IPv6 IoT devices spread over several countries and carriers, the improvisation becomes the problem you spend your engineering time on.
This is the real reason addressing matters for connected fleets. It is not an abstract shortage. It is the difference between a device you can reach and a device you can only hope is still checking in. IPv6 for IoT restores the option of a unique, routable address per device, which you can then choose to expose, firewall, or lock inside a private network as the deployment requires. The point is that the choice comes back to you rather than being decided by a carrier’s translation table.
How IPv6 Addressing Improves IoT Security
There is a myth that a newer protocol is automatically a safer one. It is worth puncturing early, because IPv6 does not encrypt your traffic by itself and does not make a badly configured device secure. What IPv6 addressing changes is the shape of the network you are defending, and that shape can work for you if you set it up deliberately.
Start with end-to-end addressing. When every device has its own routable address, you can write precise security policy: this device may talk to that endpoint and nothing else. Under heavy NAT the picture is muddier, because many devices hide behind one shared address and your allow-and-deny rules lose resolution. Cleaner addressing means cleaner segmentation, and segmentation is most of practical IoT security.
IPsec is the second piece. IPsec is a suite of standards for authenticating and encrypting traffic at the IP layer, so the protection travels with the packet rather than depending on the application. It works with both protocols, and it pairs naturally with the per-device addressing that IPv6 for connected devices makes normal, since you can build authenticated, encrypted tunnels keyed to real device identities instead of shared translated ones.
Private APN is where this becomes concrete for a cellular deployment. A private APN (Access Point Name) is a dedicated, closed gateway inside the mobile carrier that keeps your device traffic off the public internet and inside a network you control. On a private APN you set the addressing, decide the access policies, and limit connectivity to approved devices. This is exactly where Trafalgar Wireless spends its engineering attention: its built-in security services pair private APNs with Site-to-Site IPsec VPN, IMEI Lock, and Trafalgar Connect, a set of direct metro-ethernet links that carry mission-critical traffic across more than 80 global Points of Presence without touching the public internet at all. Public APNs typically assign dynamic addresses that change and route over the open internet. A private APN gives you static addressing you own and a closed path your devices sit inside.
We see how much this matters in the way buyers actually arrive. In a May 2026 review call, Trafalgar Wireless owner Neil Webzell walked through a real inbound inquiry: a prospect running 30 SIMs on a private APN, using an encrypted tunnel between a handful of them for a secure private link, averaging under 300 megabytes per SIM, asking whether the service could be provided. What stood out was Neil’s read on why the inquiry landed at all. The buyer, he noted, had “picked up on the references to private APNs” on the site. People who care about addressing and isolation come looking for providers who talk about it in specifics, not slogans. That is the practical link between secure addressing and IPv6 and IoT connectivity: the buyers who need it know exactly what to ask for.
None of this is unique to one protocol. You can build a private APN and run IPsec on IPv4 today, and plenty of secure deployments do. The reason IPv6 belongs in the security conversation is that it removes the addressing scarcity that pushes so many IPv4 deployments toward messy shared-address workarounds in the first place. Give every device a clean address, put it inside a private network you control, encrypt the path, and the security model gets simpler to reason about. Simpler is safer, because most breaches exploit the gap between the diagram you drew and the thing you actually built.
IPv6 and Constrained Devices: 6LoWPAN, LTE-M, and NB-IoT
A fair objection at this point: a lot of connected hardware is not a gateway with a full networking stack. It is a battery-powered sensor sending a few bytes a day, with a tiny radio and a decade-long lifespan to protect. Does IPv6 for IoT even fit on hardware like that? Mostly, yes, and there is a standard built for exactly this.
6LoWPAN stands for IPv6 over Low-Power Wireless Personal Area Networks. It is an adaptation layer that lets IPv6 packets ride on small, low-power radios that were never designed to carry them. The standard for these low-power links “describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE 802.15.4 networks.” In plain terms, 6LoWPAN compresses the large IPv6 header down to something a constrained radio can send efficiently, so a coin-cell sensor can still carry a real, addressable IPv6 identity. That is how IPv6 IoT devices reach all the way down to the smallest end of the hardware range.
On the cellular side, the constrained-device story runs through the low-power wide-area technologies. LTE-M and NB-IoT are cellular standards for devices that need long battery life, deep indoor reach, and low data rates rather than speed: think utility meters, environmental sensors, and asset trackers. Both can carry IP traffic, and IPv6 for connected devices is part of their design. The important caveat is that support is a function of the local network, not just the SIM. LTE-M and NB-IoT are available where carriers support them, and IPv6 handling on those bearers varies by operator and market. This is not a corner to assume. It is a corner to verify for the specific countries and carriers your fleet will actually run on.
Dual-stack is the pragmatic bridge across all of this. A dual-stack device or network runs IPv4 and IPv6 at the same time, so it can talk to older IPv4-only systems while using IPv6 where it is available. For most deployments the honest near-term answer is not a clean IPv6-only design. It is dual-stack, chosen because your platform, your carriers, and your customers’ back-end systems are at different stages of the transition. A provider that supports dual-stack lets you adopt IPv6 addressing at the pace your ecosystem allows instead of betting the whole rollout on one protocol being ready everywhere at once.
Roaming adds one more wrinkle worth naming. When a device crosses a border and connects as a visitor on a foreign network, how it gets an address and whether inbound reachability survives depends on the roaming setup. Approaches like multi-IMSI data plans, where a single SIM carries several operator profiles and behaves like a local subscriber, change that behavior country by country. If your IPv6 connectivity has to hold up while devices move, roaming behavior is part of the addressing question, not separate from it.
What to Ask an IoT Connectivity Provider About IPv6
Buyers in this market are more technical than most vendors assume. Neil Webzell has described the better prospects as people already replacing an existing provider, comfortable with terms like 3FF form factors and eUICC, who arrive with precise requirements rather than vague ones (April 2026 call). If that is you, here are the questions that separate a provider who has thought about IPv6 addressing from one who lists it as a checkbox.
- Do you support dual-stack, and on which bearers? Ask specifically about 4G LTE, LTE-M, and NB-IoT, and ask for the answer per region rather than as a blanket yes. IPv6 for IoT that works in one country and silently falls back to IPv4-only in another is a support ticket waiting to happen.
- Can I get a static, routable address per device, and how? Static IP addressing, usually delivered through a private APN, is what makes a device reachable on demand. If the answer is only dynamic addresses behind carrier NAT, know that going in and design around it.
- How does inbound reachability work behind your network? Get the provider to describe, in concrete terms, how you open a session to a single field device. If the explanation is vague, the reachability probably is too.
- What does addressing look like when devices roam? Confirm how IP addressing for connected devices behaves as hardware crosses borders and switches networks, and whether a private APN and your addressing policy follow the device.
- Can I manage all of this in one place? Address policy, SIM state, and data limits should live in one console, not a spreadsheet and three carrier portals. Trafalgar Wireless runs this through its connectivity management platform, IoT Suite, where you activate or suspend SIMs, set limits, and see the estate in real time.
A note on how to read the answers. Neil is blunt that in this market most competitors “try very hard to make out they’ve got something unique, but most of them don’t” (November 2025 call). Addressing is a good test of that. Any provider can say the word IPv6. Fewer can explain, without hedging, how a specific device on a specific carrier in a specific country gets a reachable address and stays reachable when it moves. That gap is where a real connectivity partner separates from a reseller. For utilities and energy deployments in particular, where a meter or a pipeline sensor may sit in the field for well over a decade, the provider’s ability to speak to smart metering and grid deployments at the addressing level is worth probing hard.
Frequently Asked Questions
Does IoT actually need IPv6?
Not universally, and not tomorrow. A small fleet that only pushes data outward to a cloud platform can run on IPv4 with carrier NAT for a long time. The threshold where IPv6 for IoT starts to matter is when you need inbound reachability to individual devices, when you are scaling into the tens of thousands of units, or when you are deploying across many carriers and countries where address scarcity and NAT behavior differ. At that point IPv6 addressing stops being optional hygiene and starts saving you engineering time.
Can LTE-M and NB-IoT devices use IPv6?
Yes in principle. Both LTE-M and NB-IoT are designed to carry IP traffic, and IPv6 IoT devices are part of their intended use. The real answer is carrier-dependent: support for these bearers, and for IPv6 on them, exists where local operators have deployed it, and it varies by market. Treat it as something to confirm for your exact deployment countries, not something to assume from a datasheet.
Is IPv6 more secure than IPv4 for IoT?
IPv6 is not automatically more secure, and anyone who tells you it is has oversimplified. It does not encrypt traffic on its own and will not fix a device with weak credentials. What it does is give every device a clean, unique address, which makes segmentation and policy easier to write and easier to audit. Paired with a private APN and IPsec, IPv6 for connected devices supports a security model that is simpler to reason about. The gains come from the design you build on top of it, not from the protocol version by itself.
What is the difference between a public APN and a private APN for addressing?
A public APN routes device traffic over the shared public internet and usually assigns dynamic addresses that change over time. A private APN gives you a dedicated, closed network where you control the IP addressing, set access policies, and can hand devices static addresses that stay put. For deployments that need reachability, isolation, or compliance, the private APN is where IPv6 addressing becomes something you own rather than something the carrier decides for you.
Do I have to move to IPv6-only?
Almost never in the near term. Most deployments run dual-stack, using IPv6 where it is available and IPv4 where it is not, so devices keep talking to older systems during the transition. Dual-stack lets you adopt IPv6 and IoT connectivity at the pace your platform, carriers, and customers allow, rather than forcing a single cutover.
Key Takeaways
- Addressing is the quiet cause of loud failures. Lost inbound reachability, sessions you cannot open, return traffic that vanishes at scale: these usually trace back to how devices get IP addresses, which is why IPv6 and IoT connectivity belong on the planning agenda, not the footnotes.
- IPv4 ran out, and the workarounds have costs. NAT and CGNAT let devices share scarce IPv4 addresses, but they take away the routable, per-device address that fleet operators often need. IPv6 addressing gives that option back.
- IPv6 helps security by shape, not by magic. It does not encrypt anything on its own. It gives every device a clean address, which makes segmentation, IPsec, and private-APN policy easier to build and audit for IPv6 IoT devices.
- Constrained devices are covered. 6LoWPAN carries IPv6 over low-power radios, and LTE-M and NB-IoT carry it over cellular where local carriers support it. Dual-stack is the realistic path for most rollouts.
- Make the provider be specific. Ask about dual-stack per bearer and region, static routable addresses, inbound reachability, and roaming behavior. The answers, not the buzzword, tell you whether IP addressing for connected devices is something they actually operate.
Where This Leaves You
IPv6 is not a feature you buy. It is the addressing layer underneath everything else, and its value shows up as the absence of problems: devices you can reach, policies you can write cleanly, a fleet that scales without a new class of workaround at every order of magnitude. The half-of-Google-on-IPv6 milestone is a signal that the transition is real and worth planning around, not a reason to panic. The right move is to design for it deliberately, dual-stack where you must, private and static where reachability and isolation matter, and to pin your provider down on the specifics before the first batch of SIMs ships.
If you are an IoT solution provider, a fleet operator, or a utility or medical-device maker weighing secure IPv6 and IoT connectivity, Trafalgar Wireless builds private APNs, IPsec VPNs, static addressing, and carrier-agnostic SIMs for exactly these deployments, backed by people who will answer the addressing questions directly. You can talk IPv6 and IoT connectivity through with Trafalgar Wireless before you commit an IPv6 for IoT rollout to it.
