The IPv4 address space is effectively exhausted. All five RIRs (Regional Internet Registries) have reached their final /8 allocations, and the secondary IPv4 transfer market now prices individual addresses at $40–55 USD. For 5G Fixed Wireless Access (FWA) operators deploying CPE at scale — tens of thousands to millions of units — the economics of IPv4 scarcity directly impact CAPEX and network architecture decisions. IPv6 transition is no longer optional: it is a procurement-critical requirement for FWA CPE in 2026.
This guide examines the IPv6 transition mechanisms relevant to 5G FWA CPE, their architectural trade-offs, and what B2B buyers must evaluate when selecting gateway equipment for large-scale deployments.
Why IPv6 Matters for 5G FWA Specifically
5G FWA networks have characteristics that make IPv6 transition both more urgent and more complex than traditional broadband:
- Scale: FWA operators routinely deploy 100,000+ CPE units. At $45/IPv4 address, a public IPv4 address per CPE adds $4.5 million to the address budget alone — before considering NAT gateway infrastructure.
- 3GPP Standards: 5G core networks are natively IPv6. The 5G user plane function (UPF) supports IPv6 PDU sessions as a baseline requirement, and many 5G SA deployments are IPv6-only at the transport layer.
- Enterprise Services: FWA is increasingly sold as a primary business-grade connection, not just residential broadband. Enterprise customers expect public IP addresses, static addressing, and end-to-end transparency — requirements that CGNAT struggles to meet.
- IoT and Slicing: Network slicing in 5G SA can assign dedicated IPv6 prefixes per slice, enabling clean address separation for different enterprise services without overlapping RFC 1918 space.
IPv6 Transition Mechanisms for CPE
1. Dual-Stack (Native IPv4 + Native IPv6)
Dual-stack is the simplest transition model: the CPE receives both an IPv4 address (public or CGNAT) and an IPv6 prefix, typically via DHCPv6 Prefix Delegation. All endpoints on the LAN get both IPv4 and IPv6 addresses, and the CPE routes traffic accordingly.
Advantages: Maximum compatibility. All applications, legacy and modern, work without translation overhead. No DNS64/NAT64 infrastructure required.
Disadvantages: Does not solve IPv4 exhaustion — each CPE still consumes at least one IPv4 address (even if CGNAT). Doubles the routing table and firewall rule complexity on the CPE. Not a long-term scaling solution for operators targeting millions of subscribers.
CPE requirements: Dual-stack IP stack, DHCPv6-PD client, IPv6 router advertisement daemon, dual-stack DNS proxy, and dual-stack firewall with stateful inspection for both protocols.
2. 464XLAT (IPv4-as-a-Service over IPv6-Only Access)
464XLAT is the transition mechanism deployed at scale by T-Mobile US, Reliance Jio, and several other major mobile/FWA operators. It enables IPv4 application connectivity over an IPv6-only network by combining two components:
- CLAT (Customer-side translator): Runs on the CPE. Translates IPv4 packets from LAN devices into IPv6 packets using Stateless IP/ICMP Translation (SIIT, RFC 7915). The CLAT synthesizes IPv6 addresses for IPv4 destinations using the operator’s NAT64 prefix (typically a /96 Well-Known Prefix 64:ff9b::/96 or an operator-specific prefix).
- PLAT (Provider-side translator): Runs in the operator’s core network. A stateful NAT64 gateway that translates the IPv6-encapsulated packets back to IPv4 for communication with the IPv4 internet.
How it works for the end user: The CPE receives only an IPv6 address/prefix from the network. LAN devices get IPv6 addresses normally. When an IPv4-only application (e.g., a legacy IP camera, older IoT sensor, or IPv4-only enterprise VPN client) attempts to send an IPv4 packet, the CLAT on the CPE translates it to IPv6 on the fly. The PLAT in the core network handles the IPv6-to-IPv4 translation at the internet edge.
Advantages: No IPv4 addresses needed on the CPE or access network. Proven at massive scale (hundreds of millions of devices on T-Mobile’s network). Transparent to IPv4 applications.
Disadvantages: Adds translation overhead. Breaks applications that embed IPv4 literals in payloads (FTP, SIP, some gaming protocols). Requires operator-side NAT64/PLAT infrastructure. Debugging can be complex due to address translation layers.
CPE requirements: CLAT daemon (typically clatd on Linux-based CPE, or vendor-proprietary implementation), DNS64 support (synthesizes AAAA records for IPv4-only destinations), and awareness of the operator’s NAT64 prefix (learned via RFC 7050 or DHCPv6 option).
3. MAP-T (Mapping of Address and Port with Translation)
MAP-T (RFC 7599) is a stateless IPv4-over-IPv6 transition mechanism that avoids the stateful NAT64 infrastructure required by 464XLAT. Instead, it uses algorithmic mapping: each CPE is assigned a specific IPv4 address (or shared address) and a set of TCP/UDP port ranges, algorithmically embedded into an IPv6 prefix.
Advantages: Stateless core — no carrier-grade NAT64 state tables to maintain. Deterministic port mapping simplifies troubleshooting and lawful intercept compliance. Full IPv4 transparency without NAT44 on the CPE.
Disadvantages: Requires each CPE to have a share of IPv4 address space (even if port-restricted). More complex provisioning. Less widely deployed than 464XLAT. Port range restrictions can limit concurrent connections for heavy-use subscribers.
4. IPv6-Only with DNS64/NAT64 (No CLAT on CPE)
In this model, the CPE is purely IPv6 — no IPv4 stack at all on the WAN or LAN side. IPv4 connectivity is provided entirely by the operator’s DNS64/NAT64 infrastructure. IPv4-addressed destinations are reached by synthesizing AAAA records through DNS64, and traffic is translated by the operator’s NAT64 gateway.
This is the most aggressive transition model and is suitable for greenfield deployments where all endpoint devices and applications are IPv6-capable. It is not yet practical for most B2B FWA deployments due to legacy application dependencies.
CPE Procurement Checklist for IPv6 Transition
When evaluating FWA CPE for IPv6-ready deployments, B2B buyers should verify the following capabilities:
| Capability | Why It Matters |
|---|---|
| DHCPv6 Prefix Delegation (IA_PD) | Required for the CPE to receive an IPv6 prefix from the operator and delegate subnets to LAN devices |
| CLAT Support (RFC 6877) | Essential if the operator runs an IPv6-only access network with 464XLAT |
| DNS64 Awareness (RFC 7050) | CPE must discover the NAT64 prefix and use it for IPv4-embedded IPv6 address synthesis |
| IPv6 Firewall with Stateful Inspection | Must provide equivalent security to IPv4 firewall, including DDoS protection and access control |
| Dual-Stack or IPv6-Only WAN Option | Flexibility to deploy in dual-stack today and migrate to IPv6-only/464XLAT in the future |
| MAP-T Support (RFC 7599) | Required if the operator uses MAP-T rather than 464XLAT for stateless IPv4aaS |
| TR-069 / TR-369 IPv6 Management | Remote management must work over IPv6 transport; CPE must be reachable via IPv6 ACS |
Regional IPv6 Deployment Trends for FWA
Asia-Pacific: India leads globally with over 75% IPv6 adoption, driven by Reliance Jio’s IPv6-only mobile and FWA network. Japan and South Korea report 45–55% IPv6 usage. APAC FWA buyers should prioritize 464XLAT-ready CPE.
North America: T-Mobile US operates one of the world’s largest 464XLAT deployments for its FWA service, with over 5 million FWA subscribers. The US federal government’s IPv6 mandate (OMB M-21-07) requires all federal agencies to operate at least 80% IPv6-only by 2025, accelerating enterprise IPv6 demand.
Europe: RIPE NCC’s IPv6 adoption rate sits at approximately 35–40%, with strong operator support from Deutsche Telekom, BT, and Orange. European operators tend to prefer dual-stack with gradual migration to MAP-T rather than aggressive 464XLAT.
Middle East & Africa: IPv6 adoption remains below 10% in most markets. FWA operators in these regions have a unique opportunity to deploy greenfield IPv6-only networks and leapfrog the IPv4 exhaustion problem entirely — if they select the right CPE.
Latin America: Brazil and Mexico lead with 35–45% IPv6 adoption. Several Brazilian ISPs use MAP-T for FWA IPv4 address sharing, making MAP-T CPE support a procurement requirement in that market.
Business Case: IPv6-Native CPE Reduces TCO
A TCO analysis for a hypothetical operator deploying 200,000 FWA CPE units illustrates the economic case:
- Dual-stack with CGNAT: ~$2M for CGNAT infrastructure + $500K/year for IPv4 address leasing (10,000 public addresses at $50 each, with CGNAT sharing ratio of 20:1). CPE cost: baseline. Total 5-year TCO: ~$4.5M.
- 464XLAT IPv6-only: $1.2M for NAT64/PLAT infrastructure + $0 for IPv4 addresses. CPE cost: +$3–5/unit for CLAT-capable firmware. Total 5-year TCO: ~$2.2M — roughly 50% savings.
For operators deploying at scale, the savings from IPv6-native CPE architectures are compelling and rapidly recover any incremental CPE hardware cost.
Frequently Asked Questions
Can IPv6-only CPE support IPv4-only enterprise VPN clients?
It depends on the VPN protocol. IPsec IKEv2 with IPv6 transport works natively. SSL/TLS-based VPNs (OpenVPN, WireGuard) also work when the VPN endpoint is reachable over IPv6. However, legacy IPsec clients that rely on IPv4 transport may require 464XLAT or dual-stack fallback.
What happens to IPv4-only IoT devices on an IPv6-only FWA network?
The CLAT on the CPE handles IPv4-to-IPv6 translation for LAN-originated IPv4 traffic. IPv4-only IoT devices on the LAN will function normally, as the CPE presents a standard IPv4 DHCP server and gateway address to the LAN, while translating traffic to IPv6 on the WAN side.
Is 464XLAT compatible with all 5G FWA bands?
Yes. 464XLAT operates at the IP layer and is independent of the radio access technology. It works identically over 5G NR, 4G LTE, and even Wi-Fi backhaul.
Does IPv6 impact CPE throughput performance?
Negligible impact. The CLAT translation overhead is typically under 1% of CPU utilization on modern CPE SoCs. In some cases, IPv6-only paths can actually improve throughput by eliminating CGNAT processing latency in the core network.
Evaluating IPv6-ready FWA CPE for your network deployment? Contact Honlly Telecom to discuss your IPv6 transition strategy with our solutions architects.