Moving an ISP to IPv6 means three decisions: how subscribers keep reaching IPv4 content, how prefixes are planned for every customer, and what to do about the applications and devices that still break on an IPv6-only network.
None of these has a single right answer. A mobile operator with millions of handsets, a fibre ISP with routers it controls and a cable network with legacy equipment usually land on different mechanisms. This section helps you make those decisions for your own network. The mechanisms themselves, such as DS-Lite and NAT64, are explained in the glossary.
TransitionChoosing a transition mechanism
Dual-stack, DS-Lite (RFC 6333), 464XLAT (RFC 6877), MAP-E (RFC 7597) and MAP-T (RFC 7599) solve the same problem: keeping IPv4 services reachable while the access network moves to IPv6. They differ in where the state lives, what has to be logged and what the customer router or handset has to support.
Dual-stack is the easiest to understand but doubles the work: every link, address plan and firewall rule exists twice, and you still need CGNAT for the IPv4 half. DS-Lite and 464XLAT keep the access network IPv6-only and translate or tunnel IPv4 at a central point that holds per-session state. MAP-E and MAP-T push the state to the customer router and leave the core stateless, but every router must support them.
Choosing an IPv6 transition mechanism for an ISP
A side-by-side comparison of the mechanisms by state in the core, logging, CPE requirements and migration path, with a recommendation for fixed, cable and mobile networks.
Read the guideThe role of CGNAT in dual-stack networks
Why most dual-stack networks still need CGNAT for IPv4, and how its load falls as more traffic moves to IPv6.
Read the guideDeploying NAT64 and DNS64
Rollout order, how DNS64 (RFC 6147) interacts with DNSSEC, what to monitor, and how 464XLAT on the device rescues applications that still use IPv4 literals.
Coming soonAddressingAddressing plan and security
IPv6 removes the address shortage. That makes a consistent prefix plan and a sensible firewall policy matter more than saving addresses.
| One prefix | Contains |
|---|---|
| /32 | 65,536 /48 sites or 16,777,216 /56 customers |
| /48 | 65,536 /64 subnets |
| /56 | 256 /64 subnets |
A /32 allocation contains 65,536 /48 prefixes or 16,777,216 /56 prefixes. A /56 gives a customer 256 /64 subnets, and a /48 gives 65,536. Subnets are /64 because interface identifiers are 64 bits (RFC 4291). The prefix size per customer is the ISP's choice, and RFC 6177 recommends giving more than a single /64.
IPv6 addressing plan for an ISP: /48, /56 and /64
How to split an allocation between regions, points of presence and customers so that routes aggregate cleanly, and what breaks if you hand out prefixes that are too small.
Coming soonSecuring IPv6 without NAT
What NAT never protected in the first place, what a stateful firewall on the customer router does instead, and the default rules to ship to subscribers.
Coming soonIPv6 addressing plan helper
Enter your allocation and customer counts to get a prefix plan per region, point of presence and customer.
Coming soonIPv6-onlyRunning IPv6-only
More networks now run IPv6-only access and translate IPv4 at the edge. The remaining problems sit in applications and devices rather than in the network.
Going IPv6-only: what still breaks in 2026
Applications with hard-coded IPv4 addresses, older game consoles, IoT devices and VPN clients, and the workarounds operators use for each.
Coming soonIPv6 adoption tracker
IPv6 share by country and by operator, updated from public measurements.
Coming soon