Cellular IPv6

Cellular access and network optimization

Background

With address exhaustion and 5G development, operators assign IPv6 or IPv4/IPv6 dual-stack addresses to IoT SIM cards. Terminals need to support proper DHCPv6/RA to obtain prefixes, and application layer URL resolution may prioritize returning AAAA records. If the cloud only listens on IPv4, "connected but unreachable" issues will occur.

Practice

Enable dual-stack listening on the server side; bind services like MQTT to [::]. Allow ICMPv6 NDP through the firewall. Under mobility, prefixes may change, avoid hardcoding addresses.

Debugging

Use ping6 and curl -6 to verify paths; capture packets and pay attention to Router Advertisement.

PDP, DNS, and application migration

When a cellular module activates a second PDP or rebuilds a session, the IPv6 prefix may change. Application-layer session binding and certificate verification should consider the hostname rather than a fixed address. If the DNS resolution order incorrectly returns only A records, it may cause the application to mistakenly believe there is no IPv6 path. Enterprise private networks often deploy NAT64/DNS64 to access legacy IPv4 systems, so IoT devices need to test ICMPv6 and fragmentation behavior. Libraries like MQTT and CoAP need to ensure that listening and connections use dual-stack APIs to avoid mistakenly binding to a v4-mapped address in a v6-only environment.

Operation, maintenance, and monitoring

On the platform side, AAAA resolution failure rates, TCP handshake delays to IPv6 targets, and TLS certificate chain coverage for SAN should be monitored. Apart from opening business ports, firewalls should not forget neighbor discovery and Path MTU Discovery. If the module OTA download URL hardcodes an IPv4 literal, it will fail directly on a pure v6 card. Documentation and troubleshooting manuals should provide both v4/v6 command sets in parallel to reduce front-line support costs.

Engineering Practice Supplement

Starting from "cellular IPv6," field issues often concentrate on "indicators meet lab standards but are difficult to reproduce in the field." Apart from RF and protocol aspects, power ground bounce, connector contact, and firmware race conditions should also be checked. The cellular side is advised to collect RSRP/SINR, cell reselection, and PDP rebuilding records; the application side should have clear strategies for retries, idempotence, and queue persistence. When involving data security and compliance, the scope of collection, storage location, retention period, and third-party sharing should be documented in privacy and contract appendices to avoid high costs of patching after deployment.

Prefix advertisements and dual-stack sockets

Cellular IPv6 is usually a prefix delivered by the core network inside a PDP or PDU session. The module obtains an address from a router advertisement or DHCPv6, then resolves the next hop with neighbor discovery. The interface identifier in the address can change with the session, so a service connection should bind a domain name, not an address written into the configuration from one dial-up. Dual stack means the same session has both IPv4 and IPv6. If the application finds an AAAA record and uses only IPv6, while the server listens only on IPv4, the signal looks normal and the connection fails. The reverse happens when only an A record is returned: a card that has only IPv6 has no usable path.

It is enabled only when the APN actually assigns IPv6 or dual stack, the module firmware has opened the matching PDP type, the service ports on the server and the firewall are reachable over IPv6, and the ICMPv6 that neighbor discovery needs is allowed. If the enterprise uses NAT64 to reach an old system, the domain, fragmentation, and return path have to be proven on a lab network. A laptop on the office network is not that proof.

Address literals hardcoded in firmware

An upgrade package or an MQTT host written as a dotted-decimal address fails on an IPv6-only card before any name lookup. A socket bound to an IPv4-mapped address hears nothing in an IPv6-only environment. After a cell reselection or a rebuilt session the prefix changes, the old TCP session is still attached to a dead address, and the application does not reconnect. A firewall that allows only the service port and drops Packet Too Big ICMPv6 breaks path-MTU discovery: small packets work, and a certificate or a firmware image dies halfway. A log that prints only “network error,” and not the address family used this time, cannot separate DNS from routing.

Before launch, run the full service once each on IPv4, IPv6, and dual stack with the same card model, including a large download. Fragment limits on the path are covered in MTU and fragmentation. If the platform can still open a session only from the device side, a change of address family does not mean the outside network can connect inward. That matches the model in which MQTT has the device connect to the server first.

A joint-debug record should keep the address family of this session, the prefix length, the name-lookup result, and the server address that was actually reached. “Network active” alone cannot tell IPv4 from IPv6 or from an old address that was translated back. After a session is rebuilt, compare the prefix before deciding whether to tear down the old socket. If the application cached the previous source address, the first packet after wake is dropped by the network and looks like a server that does not answer. Write the firewall policy once per address family, so only the IPv4 service port is not the one that was opened. Firmware download, certificate check, and everyday telemetry should use the same domain name, so one path is not still a numeric address. At acceptance, run again with a batch that has only IPv6. A dual-stack lab hides this.

When neighbor discovery is dropped, the address looks configured and the next hop is unreachable, so the service times out now and then. Allow those messages together with the service port. Application connections should use a domain name. When the lookup order looks wrong, print whether each address record came back. On a card with only one address family, remove literals of the other family at build time, rather than failing at run time.

On dual stack, force each address family through one complete transaction, including a larger download. Checking that the server is listening from a laptop does not find a module stack bound to the wrong family, or an access point that never assigned a prefix.

Related Terms

Return communication modules terminology