Why Mobile Phones Still Struggle with IPv6: Dual‑Stack Realities and Solutions

Introduction

Following the Chinese government’s IPv6 deployment plan, the IPv6 ecosystem is becoming active, yet many practical challenges remain, especially for mobile networks. This article examines the current state of IPv6 from a mobile perspective.

iPhone Dual‑Stack Support

Apple has required apps to support IPv6‑only since several years ago, but testing in China is difficult because the built‑in APN only requests IPv4. Consequently, iPhones on Chinese mobile networks obtain only IPv4 addresses. The PDN type shown in the signaling diagram is IPv4; a true dual‑stack request would be IPv4/IPv6. Since iOS 12.1, Apple enables default dual‑stack support.

Android Dual‑Stack Support

Android devices are generally more flexible; many allow APN editing and some default to IPv4/IPv6. However, not all Android phones can edit the APN, and even when editable, the default protocol may remain IPv4 only. Some devices hide the IPv6 address unless Wi‑Fi is also active.

Carrier Dual‑Stack Deployment

All three major Chinese mobile operators have enabled IPv4/IPv6 dual‑stack in the radio access network. The diagram below shows the end‑to‑end path from the handset to the core network.

Sample address allocation for each operator follows the MIIT standard YD/T 2682‑2014, with prefixes such as 2409:8000::/20 for China Mobile, 2408:8000::/20 for China Unicom, and multiple prefixes for China Telecom.

Happy Eyeballs Algorithm

When both A and AAAA records are returned, clients must decide which address to use. RFC 8305 recommends a 50 ms “resolution delay” to prefer IPv6 if the AAAA response arrives quickly. iOS implements a similar mechanism with a 25 ms timer; Android also prefers IPv6, though the exact delay is undocumented.

The algorithm proceeds as follows: if a positive AAAA response is received first, the IPv6 connection attempt starts immediately. If a positive A response is received first, the client SHOULD wait a short time (recommended 50 ms) for the AAAA response before falling back to IPv4.

NAT, PAT, and Firewalls

In IPv4‑only mobile networks, carrier firewalls perform NAT and PAT, limiting inbound connections. In a dual‑stack scenario, tests show that carriers do not apply NAT or PAT to IPv6 traffic; the server sees the handset’s original IPv6 address and port, though firewalls still block inbound traffic.

Server start at: 2400:3200:1000:xx::80 wait for connection...

Connected by ('2409:8928:84e:995:xxxx:xxxx:xxxx:xxxx', 34102, 0, 0)

MTU Considerations

IPv6 requires the “Don’t Fragment” bit to be set, and routers do not fragment packets. If a packet exceeds the path MTU, an ICMPv6 Packet Too Big message is sent. Some middleboxes may drop these messages, so sending applications should limit packet size to the recommended MTU of 1280 bytes.

Conclusion

IPv6 deployment on mobile networks is progressing, but real‑world implementations still face issues such as APN limitations, carrier policy differences, address allocation quirks, Happy Eyeballs timing, lack of NAT for IPv6, and MTU handling. Ongoing testing and refinement are needed to improve user experience.