IPv4 Exhaustion and IPv6 for ISPs: Transition Architectures and CGNAT

The global pool of unallocated IPv4 addresses was officially exhausted by the Internet Assigned Numbers Authority (IANA) in February 2011, followed rapidly by exhaustion across all five Regional Internet Registries (RIRs) [1]. In contemporary network operations, an expanding Internet Service Provider cannot simply request additional public IPv4 address blocks to accommodate new broadband, enterprise, or mobile subscribers.

To sustain commercial growth, ISPs must deploy intermediate address-sharing architectures while systematically executing a dual-stack or IPv6-only transition [2, 3]. In this technical guide, we examine the mechanics of Carrier-Grade NAT (CGNAT) under RFC 6598, analyze address allocation models, and explore modern transition mechanisms including 464XLAT and native dual-stack deployments [1, 2].

1. The Realities of IPv4 Scarcity for Growing ISPs

The 32-bit IPv4 address space yields a theoretical maximum of approximately 4.29 billion addresses. After subtracting reserved blocks for loopback (127.0.0.0/8), private networks (RFC 1918), multicast (224.0.0.0/4), and experimental networks, fewer than 3.7 billion public addresses were ever routable.

Today, acquiring clean IPv4 blocks requires navigating commercial secondary transfer markets, where address prices have reached unprecedented premiums. For emerging and expanding regional ISPs, purchasing a dedicated public IPv4 address for every end subscriber is economically prohibitive. Consequently, address optimization and transition architectures have become core operational requirements [1].

2. Carrier-Grade NAT (CGNAT): Architecture and Operation

Carrier-Grade NAT (also designated as Large-Scale NAT or LSN) is an address-sharing mechanism deployed within the service provider's core network. Rather than assigning a public IPv4 address to the subscriber's Customer Premises Equipment (CPE) router, the ISP assigns a private address and multiplexes thousands of subscribers across a shared pool of public IPv4 addresses [1].

The RFC 6598 Shared Address Space (100.64.0.0/10)

Historically, some service providers attempted to use standard RFC 1918 private addresses (such as 10.0.0.0/8 or 192.168.1.0/24) between the provider's gateway and the subscriber's CPE. This created immediate address-collision disasters: if a subscriber configured their local home network on 192.168.1.0/24, the CPE router could not distinguish between its local LAN interface and its WAN upstream interface.

To eliminate address collision, the IETF ratified RFC 6598, reserving a dedicated IPv4 block exclusively for Carrier-Grade NAT [1]:

$$\mathbf{100.64.0.0/10} \quad (\text{Addresses from } 100.64.0.0 \text{ to } 100.127.255.255)$$

This block provides $2^{22} = 4{,}194{,}304$ discrete addresses that can be routed across the ISP's internal access aggregation infrastructure without colliding with subscriber private LANs or global public IPs [1].

NAT444 Topology and Port-Block Allocation

Under CGNAT, traffic undergoes translation twice before reaching the public internet—an architecture known as NAT444:

1. NAT 1 (CPE Router): Client device (e.g., 192.168.1.50) is translated to the CPE WAN IP (e.g., 100.64.20.15).
2. NAT 2 (ISP Core CGNAT Gateway): The CPE IP (100.64.20.15) is translated to a public internet IP (e.g., 203.0.113.5) with a specific source port range.

To maintain lawful intercept and regulatory logging compliance, ISPs must maintain deterministic records of which subscriber utilized which public IP and port at any given second. Modern CGNAT appliances employ Deterministic Port-Block Allocation (PBA):

• Each subscriber is allocated a static block of ports (e.g., 1,024 or 2,048 ports) on a specific public IP.
• Because port assignments are algorithmically deterministic, the ISP does not need to log every individual per-packet connection, reducing logging storage requirements by over 90%.

Operational Challenges of CGNAT

While CGNAT extends IPv4 lifespan, it introduces inherent technical penalties:

• Inbound Port Forwarding Breakage: Peer-to-peer applications, self-hosted web servers, VoIP SIP signaling, and security cameras cannot accept incoming connections without explicit Session Traversal Utilities for NAT (STUN) or UPnP relay assistance.
• Shared IP Reputation: If one infected subscriber sends spam or initiates malicious scraping, third-party security systems blackhole the shared public IP, subjecting hundreds of innocent subscribers sharing that IP to CAPTCHA challenges or complete access blocks.

3. The Definitive Solution: Native IPv6 Transition

CGNAT is an expensive, maintenance-heavy stopgap. The definitive solution to address scarcity is the deployment of IPv6 [3].

IPv6 utilizes a 128-bit address architecture, yielding approximately $3.4 \times 10^{38}$ distinct addresses. This is sufficient to assign every connected device on Earth a globally unique, end-to-end routable public address, eliminating the need for NAT entirely [3].

Standard ISP IPv6 Prefix Allocation

In accordance with APNIC and RIR operational policies, ISPs receive and distribute IPv6 addresses hierarchically:

• RIR to ISP Allocation: A typical regional ISP receives a minimum allocation of a /32 prefix from its regional registry (providing $2^{32} = 4.29\text{ billion}$ distinct /64 subnets) [3].
• ISP to Enterprise Subscriber: ISPs allocate a /48 prefix to commercial corporate subscribers. A /48 allocation provides the enterprise with 65,536 distinct /64 local subnets, allowing comprehensive segmentation for decades without renumbering.
• ISP to Residential Broadband: In accordance with RFC 7381 recommendations, ISPs allocate a /56 prefix (providing 256 /64 subnets) or at minimum a /60 prefix (16 /64 subnets) to residential users via DHCPv6 Prefix Delegation (DHCPv6-PD). Assigning a single /64 to a subscriber is considered bad practice because it prevents the home gateway from provisioning separate guest or IoT subnets [3].

4. Transition Mechanisms: Dual-Stack vs 464XLAT

Transitioning an entire subscriber base to IPv6 cannot occur overnight because a portion of the global web remains IPv4-only.

Dual-Stack (The Gold Standard)

Under a dual-stack deployment, every network element—core routers, aggregation switches, CPE gateways, and end-user devices—runs both IPv4 (via CGNAT) and native IPv6 simultaneously [3].

• Operating systems prioritize IPv6 (Happy Eyeballs / RFC 8305).
• Traffic destined for IPv6-enabled services (such as Google, Meta, Microsoft, and major CDNs, representing over 60% of modern consumer traffic) traverses native IPv6 without passing through the CGNAT hardware.
• Only legacy IPv4-only destinations trigger the CGNAT translation pipeline, dramatically reducing CPU load and port consumption on the expensive CGNAT appliances [3].

464XLAT (IPv6-Only Core Architecture)

As networks mature, maintaining dual routing protocols and dual firewalls across the access fabric becomes burdensome. 464XLAT (RFC 6877) enables an ISP to run an IPv6-only access and core network while continuing to deliver seamless IPv4 connectivity [2]:

1. CLAT (Customer-Side Translator): An edge translator located on the subscriber's CPE (or mobile device) that statelessly translates local outbound IPv4 packets into IPv6 packets using an algorithmic prefix.
2. IPv6-Only Core: Traffic traverses the ISP's core routing infrastructure strictly as pure IPv6 packets.
3. PLAT (Provider-Side Translator): A high-capacity stateful NAT64 gateway at the network border that translates the IPv6 packet back to an external IPv4 address to reach legacy internet destinations [2].

Summary Comparison of Address Models

Strategic Recommendations for Network Operators

1. Deploy RFC 6598 CGNAT Immediately: Reclaim existing public IPv4 blocks for high-value enterprise DIA subscribers, placing all standard consumer broadband on 100.64.0.0/10 with deterministic port blocks [1].
2. Enable IPv6 Dual-Stack by Default: Enable native IPv6 routing across all PPPoE and IPoE broadband profiles. Offloading 50% to 70% of consumer traffic to IPv6 immediately cuts CGNAT hardware capacity requirements in half [3].
3. Mandate IPv6-Capable CPE Equipment: Ensure all customer routers deployed in the field support DHCPv6-PD, SLAAC, and modern IPv6 firewalling [3].

Navigating carrier-grade transitions requires robust architectural planning. To modernize your routing infrastructure, explore our IT Infrastructure & System Integration consulting.

Key Takeaways

• IPv4 depletion makes dedicated public addresses unsustainable for growing ISPs.
• RFC 6598 reserves 100.64.0.0/10 for Carrier-Grade NAT, preventing address collisions with subscriber LANs.
• Dual-stack deployment offloads high-volume CDN traffic onto native IPv6, preserving CGNAT port capacity.
• ISPs should allocate a /48 prefix to commercial clients and a /56 prefix to residential subscribers via DHCPv6-PD.

Need help with this? Contact us.

Sources

[1] IETF, "RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space", 2012. URL: https://www.rfc-editor.org/rfc/rfc6598.html (Defines the 100.64.0.0/10 shared address block and operational parameters for Carrier-Grade NAT).

[2] IETF, "RFC 6877: 464XLAT: Combination of Stateful and Stateless Translation", 2013. URL: https://www.rfc-editor.org/rfc/rfc6877.html (Specifies architecture for providing IPv4 service across native IPv6-only access fabrics).

[3] IETF, "RFC 7381: Enterprise IPv6 Deployment Guidelines", 2014. URL: https://www.rfc-editor.org/rfc/rfc7381.html (Best practices for subnet allocation, dual-stack routing, and security policies in large-scale deployments).

Last reviewed: October 2026