IPv4 address exhaustion is no longer a theoretical concern — it is a daily operational reality for Mobile Network Operators scaling 5G Fixed Wireless Access services. With the last /8 IPv4 blocks allocated by RIRs and secondary market prices exceeding $55 per address, operators face an unavoidable architectural transition. For technical procurement teams sourcing 5G CPE at scale, the device’s IPv6 capability — and specifically how it handles the coexistence of IPv4 and IPv6 during the multi-year transition period — has become a critical selection criterion that directly impacts total cost of ownership and subscriber experience.
Why IPv6 Matters for 5G FWA CPE — Now
Several converging factors make IPv6 support in 5G CPE an urgent procurement consideration in 2026:
- 5G Core Is Natively IPv6: The 3GPP 5G Core (5GC) architecture uses Service-Based Interfaces (SBI) built on HTTP/2, with IPv6 as the recommended transport. While IPv4 is technically supported, operators deploying IPv6-only 5GC cores report 40–60% reduction in NAT state management overhead compared to dual-stack cores.
- CG-NAT Costs Are Non-Trivial: Carrier-Grade NAT (CG-NAT) infrastructure to preserve IPv4 connectivity costs approximately $8–12 per subscriber per year in hardware, licensing, logging, and operational overhead — a recurring expense that scales linearly with subscriber growth.
- Content Is IPv6-Ready: Google reports that over 50% of global traffic now arrives via IPv6. Major content providers (Google, YouTube, Netflix, Facebook, Akamai, Cloudflare) are fully dual-stacked, meaning FWA subscribers with IPv6-capable CPE can bypass CG-NAT for the majority of their traffic.
- Regulatory Pressure: An increasing number of national telecom regulators (India TRAI, EU BEREC, Brazil Anatel) now mandate IPv6 support in new broadband CPE certifications, with phase-out timelines for IPv4-only devices.
IPv6 Transition Architectures for 5G CPE
Dual-Stack (Native IPv4 + Native IPv6)
The most straightforward transition architecture provisions both IPv4 (private RFC 1918 or CG-NAT) and native IPv6 addresses to each CPE. The device maintains two parallel protocol stacks, with address selection governed by RFC 6724 (Happy Eyeballs v2) to prefer IPv6 when both endpoints support it.
Advantages: Maximum compatibility; no translation overhead; proven in production at scale.
Disadvantages: Requires maintaining dual IPAM systems and CG-NAT infrastructure for IPv4; doubles the address management complexity for the operator.
464XLAT (RFC 6877): IPv6-Only Access with IPv4aaS
464XLAT is increasingly the preferred architecture for greenfield 5G FWA deployments. The model combines two components:
- CLAT (Customer-side Translator): Runs on the 5G CPE, translating IPv4 packets from LAN devices into IPv6 packets using Stateless IP/ICMP Translation (SIIT, RFC 6145). 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): Deployed in the operator’s core network, the PLAT performs stateful NAT64 translation, mapping the synthesized IPv6 addresses to public IPv4 addresses for communication with IPv4-only internet destinations.
This architecture allows the operator to run an IPv6-only access network and 5G Core while preserving full IPv4 internet reachability for subscribers. For CPE procurement, this means the device must implement a high-performance CLAT function capable of handling gigabit-speed SIIT translation without introducing measurable latency.
MAP-T (Mapping of Address and Port — Translation, RFC 7599)
MAP-T is an alternative IPv4-as-a-Service architecture gaining traction among operators who want to avoid stateful CG-NAT while preserving IPv4 connectivity. MAP-T uses an algorithmic mapping between IPv6 addresses and IPv4+port tuples, eliminating the need for per-flow state in the provider translator:
- Each CPE is assigned a specific IPv6 prefix and a share of the operator’s public IPv4 address (a dedicated port range).
- The CPE’s MAP-T function performs stateless NAT46 translation for outbound IPv4 flows, embedding the mapped IPv4 address and port in the IPv6 destination address.
- The Border Relay (BR) at the operator edge performs the reverse translation statelessly, using the embedded mapping to reconstruct the subscriber’s IPv4 address.
Key CPE Requirement: MAP-T demands that the CPE implement algorithmic address mapping with precise port-set calculation. The implementation must support the full Basic Mapping Rule (BMR) configuration distributed via DHCPv6 options or TR-369 USP provisioning.
DS-Lite (Dual-Stack Lite, RFC 6333)
While less favored for new 5G FWA deployments due to its reliance on centralized stateful NAT, DS-Lite remains relevant for operators with existing BNG/BRAS infrastructure. The CPE encapsulates IPv4 packets in IPv6 tunnels (IP-in-IP, protocol 4) to a centralized AFTR (Address Family Transition Router) that performs CG-NAT. CPE procurement for DS-Lite operators requires hardware-accelerated IPv6 tunneling with minimal encapsulation overhead.
Performance Considerations for IPv6 Transition Mechanisms
The choice of transition architecture directly impacts CPE throughput performance. Technical buyers should evaluate:
- Dual-Stack: Minimal processing overhead (native forwarding), no MTU impact, no stateful component (if IPv4 is public).
- 464XLAT (CLAT): Low processing overhead (SIIT header translation), 20-byte IPv6 header delta typically absorbed by Path MTU Discovery, stateful only on provider side (PLAT).
- MAP-T: Low-to-moderate overhead (algorithmic mapping + SIIT), fully stateless and distributed — no centralized bottleneck.
- DS-Lite: Moderate overhead (IPv6 encapsulation with 40-byte header), centralized stateful AFTR required.
CPE IPv6 Feature Checklist for Operator RFPs
- Dual-Stack Support: RFC 4213 basic dual-stack with RFC 6724 address selection (Happy Eyeballs v2)
- 464XLAT CLAT Implementation: RFC 6877-compliant with support for WKP 64:ff9b::/96 and operator-specific NAT64 prefixes; CLAT enable/disable per APN or per VLAN
- MAP-T CE Function: RFC 7599-compliant MAP-T Customer Edge with BMR/FMR configuration via DHCPv6 (OPTION_S46) and TR-369 USP
- IPv6 PD (Prefix Delegation): RFC 3633 DHCPv6-PD with support for /56, /60, and /64 prefix sizes; ability to delegate sub-prefixes to downstream routers
- DNS64 Awareness: RFC 7050 DNS64 discovery (IPV6ONLY.ARPA) and RFC 7051 analysis of DNS64 provider behavior
- IPv6 Firewall with RFC 6092 Compliance: Simple Security capability with default-deny inbound and stateful outbound filtering; ICMPv6 error message passthrough per RFC 4890
- IPv6-Only LAN Operation: RFC 8781 PREF64 option in Router Advertisements; ability to operate LAN-side as IPv6-only with CLAT providing IPv4 reachability
- Multicast Listener Discovery (MLDv2): RFC 3810 for IPv6 multicast group management with MLD snooping on LAN bridge
- DHCPv6 Client/Server/Relay: Full DHCPv6 ecosystem support including Information-Request for stateless configuration and SOL_MAX_RT/INF_MAX_RT tuning
- TR-369 USP IPv6 Objects: Support for the Device:IPv6 data model with per-interface IPv6 address, prefix, and neighbor table exposure
The CGNAT Cost Equation
For operators, the financial argument for IPv6-capable CPE is straightforward. A mid-tier operator with 500,000 FWA subscribers running CG-NAT for IPv4 connectivity incurs approximately:
- CG-NAT hardware and licensing: $2.5M initial + $1.8M annual maintenance
- Logging infrastructure (legal intercept compliance): $600K initial + $400K annual
- Additional IPv4 address acquisition (secondary market): $2.75M (50,000 new addresses at $55/address annually)
- Total annual CG-NAT TCO: ~$6M
Transitioning to 464XLAT with IPv6-capable CPE eliminates CG-NAT hardware and logging costs for IPv6-offloaded traffic (50–60% of flows), reducing annual opex by $2.5–3.5M. The CPE premium for IPv6 transition support (typically $3–8 per unit) is amortized within the first 6–9 months of deployment.
Honlly’s IPv6-Ready CPE Portfolio
Honlly Telecom’s 2026 5G CPE lineup supports the full spectrum of IPv6 transition architectures — dual-stack, 464XLAT CLAT, MAP-T CE, and DS-Lite B4 — as standard firmware features, not premium add-ons. Our devices have been validated against the IPv6 Forum’s IPv6 Ready Logo Program (Phase-2 Gold) and deployed in production IPv6-only 5G SA networks across Asia-Pacific and EMEA. For technical evaluation, we provide detailed RFC compliance matrices and configuration guides covering integration with all major 5G Core vendors (Ericsson, Nokia, Huawei, Samsung, Mavenir). Contact our solutions engineering team for device samples and IPv6 transition planning support.