IPv6 for ISPs in Latin America: why there is no excuse left to wait
IPv4 exhaustion is not a prediction: it is a settled fact. IANA allocated its last /8 block in 2011. LACNIC—the internet address registry for Latin America—ran out of reserves for new direct assignments years ago. Today, an ISP that needs additional IPv4 space must buy it on the secondary market at prices that rise every year.
Meanwhile, IPv6 has been production-ready for more than a decade. Most modern operating systems support it by default. Major CDNs, public clouds, and content platforms have had native IPv6 for a long time. And yet many ISPs in Latin America still run exclusively on IPv4 with CGNAT as a short-term fix that has stretched on indefinitely.
This article is not technology evangelism. It is a practical analysis of why the time to implement IPv6 has already passed, and how to do it without breaking service for your current customers.
The real problem with CGNAT
CGNAT (Carrier-Grade NAT) was designed as a transitional solution to stretch IPv4 space while IPv6 migration completed. In practice, it became a permanent solution in many networks, with costs that are often underestimated:
Operational cost: CGNAT gear with adequate capacity for a mid-size ISP (50,000–200,000 subscribers) carries significant hardware and license cost. That cost scales with customer growth.
Application issues: CGNAT breaks applications that assume a single public IP per session. IPsec VPNs, some online games, videoconferencing apps, and P2P services frequently misbehave in CGNAT environments. These issues produce support tickets that are hard to diagnose and resolve.
Traceability and legal compliance: In several Latin American countries, regulations require ISPs to identify the subscriber associated with an IP at a given time. With CGNAT, that traceability requires storing translation logs (source IP + port + timestamp) at volumes that can exceed 100GB per day for large ISPs. Storage cost and log-system complexity are permanent overhead.
Added latency: Every packet goes through an extra translation layer. In practice average latency impact is low, but on sensitive connections (gaming, VoIP, trading) it can be measurable.
CGNAT is not the problem in itself: it is a symptom of not having invested in IPv6 in time. Every year that passes, the cost of removing CGNAT grows because the infrastructure built around it becomes more complex.
Why IPv6 is better for your network (not only for your customers)
The usual IPv6 narrative focuses on “more addresses.” For a network operator, the more relevant benefits are different:
End of NAT on the customer network: Each subscriber gets their own IPv6 prefix (typically a /56 or /48). Applications work end-to-end without translation, eliminating a whole class of connectivity issues.
Cleaner routing: IPv6 was designed for efficient hierarchical routing from the start. The absence of NAT and more structured addresses simplify routing tables and traffic debugging.
Better multicast support: IPv6 uses multicast extensively (it replaces ARP broadcast with Neighbor Discovery). For ISPs with IPTV or multicast services, this matters.
Readiness for IoT and 5G: IoT devices—smart meters, cameras, sensors—deploy in volumes that make CGNAT unsustainable. The right model for IoT at scale is IPv6 with a dedicated prefix per device or per home.
Exit from the IPv4 secondary market: Once most of your customer traffic runs over IPv6, dependence on IPv4 drops dramatically. The IPv4 space you already have lasts for residual traffic for a long time.
Transition models: which one fits your network
There is no single way to deploy IPv6. The three most common ISP models are:
Dual stack
The simplest conceptually: each device has both IPv4 and IPv6 addresses. Traffic uses IPv6 when the destination has IPv6, and IPv4 when it does not.
Pros: Compatible with all existing infrastructure, no need for tunneling. Con: Requires IPv4 at the same time, so it does not remove CGNAT immediately.
Recommended for: Starting deployment, networks that cannot make abrupt changes.
464XLAT (CLAT + PLAT)
The model recommended by mobile operators and increasingly by fixed broadband ISPs. The operator network is IPv6-only. Customers run a local translator (CLAT) that turns application IPv4 traffic into IPv6, and at the network edge a PLAT (typically PNAT64) converts it back to IPv4 to reach IPv4-only destinations.
Pros: Removes centralized CGNAT, shrinks core equipment footprint, IPv6-only in the distribution network. Con: Requires CLAT-capable CPEs (all modern Android and iOS 12+ support it natively; home CPEs need updated firmware).
Recommended for: ISPs with a modern customer base (smartphones, up-to-date routers) and willingness to make a deeper architectural change.
IPv6-mostly (RFC 8925)
IPv6-mostly is one of the most practical transition models for ISPs with a mix of modern and legacy devices, and it is the most direct path to reducing CGNAT without forcing disruptive changes.
The problem it solves: In dual stack, the ISP assigns an IPv4 address to all customers even though most of their traffic already goes over IPv6. That means CGNAT remains necessary for everyone. IPv6-mostly fixes this by separating customers by real capability: modern devices that can run without IPv4 do not request it, and the IPv4 pool is reserved for those who genuinely need it.
How it works — DHCP Option 108 (RFC 8925):
The key is DHCP Option 108, also called “IPv6-Only Preferred.” When a client sends a DHCPREQUEST with this option, it tells the server: “I prefer to operate without IPv4 — do not assign me an IPv4 address unless necessary.”
The DHCP server can respond in two ways:
- If it supports Option 108: it responds with a wait time (in seconds) telling the client how long it may operate without IPv4. The client accepts and runs IPv6-only for that period.
- If it does not support Option 108: it ignores the option and assigns IPv4 as usual. The modern device receives IPv4 as fallback and runs dual stack.
This makes IPv6-mostly fully backward compatible: devices that do not understand Option 108 (old gear, Windows 7, legacy IoT) simply receive IPv4 as always.
IPv4 connectivity for IPv6-only clients:
Clients that operate without an assigned IPv4 address need a way to reach IPv4-only destinations on the internet. This is solved with the NAT64 + DNS64 pair:
- DNS64: The ISP resolver synthesizes AAAA (IPv6) records for domains that only have A (IPv4) records. It maps the destination IPv4 into an IPv6 address with a reserved prefix (typically
64:ff9b::/96). - NAT64: A gateway at the network edge translates IPv6 traffic with that prefix to the real IPv4 destination.
The result: the IPv6-only device can reach any destination on the internet without a public IPv4 address or CGNAT.
Dispositivo (IPv6-only)
│
├── Destino IPv6 nativo: tráfico directo IPv6 ──────────────────► internet IPv6
│
└── Destino IPv4-only:
DNS64 genera AAAA sintética
Paquete sale por 64:ff9b::/96
NAT64 traduce → ──────────────────────────────────────────► internet IPv4
Operational benefits for the ISP:
- Immediate CGNAT load reduction: In networks with high smartphone (Android/iOS) and modern router penetration, 60–80% of devices may qualify for IPv6-only operation. That proportionally reduces IPv4 connections the CGNAT must handle.
- Gradual transition without risk: The ISP enables IPv6-mostly progressively. Devices that do not qualify stay on dual stack. There is no forced cutover date.
- No customer CPE changes: Option 108 is a standard DHCP option. Modern operating systems (Android 10+, iOS 14+, Windows 11, macOS Monterey+) already support it out of the box. No customer CPE firmware update is required.
- Measures network maturity: The ratio of devices that “choose” IPv6-only is a direct indicator of how ready the ISP’s installed base is for a full migration later.
What ISPs must prepare:
- Option 108 support on the DHCP server: Major DHCP servers (ISC DHCP 4.4.3+, Kea 2.0+, and most modern BRAS/BNG platforms) already support it.
- NAT64 + DNS64 infrastructure: Can be built with open source (TAYGA for NAT64, BIND 9.8+ or Unbound for DNS64) or on existing network gear that supports the function.
- NAT64 prefix announced via RA: The access router must advertise the NAT64 prefix via Router Advertisement so IPv6-only clients know how to reach IPv4 destinations.
- Exception for apps that do not use DNS: Some applications (few cases today) use hardcoded IPv4 addresses. For those, the NAT64 prefix does not help and the device needs IPv4. These are exceptional but should be mapped before rollout.
IPv6-mostly on the roadmap:
IPv6-mostly is not exclusive of the other models — in fact it is complementary. An ISP can:
- Start with dual stack (Phase 3 of the roadmap below).
- Enable Option 108 and NAT64/DNS64 in parallel.
- Monitor the percentage of customers that choose IPv6-only (starts low, grows as CPEs update).
- Eventually make IPv6-mostly the default mode, with IPv4 only for those who explicitly need it.
This path lets the ISP reduce CGNAT exposure continuously and measurably, without a big-bang migration that could affect customers.
Recommended for: ISPs with high smartphone and modern router penetration that want to shrink CGNAT without a disruptive migration. It is the transition model with the best risk/outcome ratio in the medium term.
MAP-E / MAP-T
Encapsulates customer IPv4 traffic inside IPv6 using deterministic rules (stateless at the operator). It is technically elegant and scales well, but CPE configuration is more complex.
Recommended for: Operators with advanced engineering and full control over customer CPEs.
Practical roadmap for ISPs
An IPv6 deployment that does not interrupt existing service typically follows these phases:
Phase 1 — Audit and allocation (1–2 months)
- Verify which core and distribution devices support IPv6 on the current firmware.
- Request your own IPv6 block from LACNIC if you do not have one. The process is straightforward and space is free (no charge by block size).
- Define the numbering plan: prefixes for network infrastructure, prefixes for customers (/56 or /48 per subscriber policy).
Phase 2 — Core and upstream (2–3 months)
- Enable IPv6 on core devices and on BGP sessions with upstreams/transit.
- Configure IPv6 BGP announcements with peering peers (local IX points such as NAP.BR, CABASE, LACIX, etc.).
- Validate that IPv6 traffic flows correctly between core and uplink.
Phase 3 — Distribution and BRAS/BNG (2–4 months)
- Enable DHCPv6-PD (Prefix Delegation) on the BRAS/BNG to assign prefixes to customers.
- Configure RA (Router Advertisement) or SLAAC according to the CPE model.
- Pilot on a segment of volunteer customers: validate applications, latency, traceability.
Phase 4 — Mass rollout and CGNAT reduction (6–12 months)
- Roll out dual stack or 464XLAT to the customer base progressively.
- Monitor the IPv6/IPv4 egress traffic ratio to confirm adoption.
- As IPv4 traffic falls, evaluate reducing installed CGNAT capacity.
Common mistakes that slow deployment
Blocking ICMPv6: IPv6 Neighbor Discovery depends on ICMPv6. Filtering it with the same firewall rules used for ICMP on IPv4 breaks IPv6 connectivity in hard-to-diagnose ways. ICMPv6 types 133–137 (ND) must always be allowed.
Not assigning large enough prefixes: Giving each customer a /64 instead of a /56 or /48 limits the ability to have multiple subnets at home (increasingly common with IoT and home network segmentation). Current best practice is /56 per residential site and /48 per enterprise site.
Forgetting DNS: Many deployments enable IPv6 connectivity but forget that DNS resolvers must be reachable over IPv6. If your resolver only answers on IPv4, clients on IPv6-only networks cannot resolve names.
Not updating traceability systems: With IPv6, the customer address may be the assigned prefix plus an SLAAC-generated address (privacy extensions). Authentication and RADIUS logs must record the assigned prefix to maintain traceability.
The time is now
“We will do it when it is urgent” is the logic that led to the current situation: networks that depend on CGNAT to function, growing technical debt, and migration cost that rises every year.
At Ayuda.LA we support ISPs in designing and implementing IPv6 migrations, from the initial audit through production rollout. The process is gradual and does not require interrupting existing service.
Learn more about our networking and ISP consulting services.
Want to assess the IPv6 state of your network?
We can run a quick review of your current architecture and identify the shortest path to implement IPv6 without operational risk.
Questions about IPv6 for your network? Write to us at [email protected] — we answer every message.