IPv6-Only Networks: Real Migration Lessons from …

Quick summary: IPv6-only is no longer aspirational in 2026. Major cloud providers (AWS, GCP, Azure) all support IPv6-only VPCs/subnets. Mobile carriers in many countries are IPv6-only by default. Some hyperscalers and forward-leaning enterprises have moved internal infrastructure to pure IPv6. The benefits are real: address abundance, simpler routing, no NAT, integrated IPsec. The challenges are also real: application compatibility (some software still hardcodes IPv4), tooling that assumes dual-stack, NAT64/DNS64 operational complexity for reaching legacy IPv4-only services. This article covers what works, what breaks, and the patterns that make IPv6-only production-viable today.

IPv6-only networks real-world migration lessons 2026

Why IPv6-Only (and Why Now)

IPv6 has been "the future" for over 25 years. What changed to make 2026 the inflection point?

IPv4 exhaustion is now expensive. The price of IPv4 addresses on the secondary market has tripled since 2022. AWS now charges $3.65/month per public IPv4 address. For organizations operating thousands of public IPs, the bill is meaningful.
Mobile and consumer ISPs are IPv6-first. T-Mobile, Reliance Jio, and many European carriers are pure IPv6 with NAT64 for legacy IPv4. If your service does not work over IPv6, a meaningful percentage of your users are reaching it through carrier-grade NAT.
Cloud-native architectures are mature for IPv6. Kubernetes IPv6-only mode is stable. Service meshes (Istio, Linkerd) handle IPv6 cleanly. Container runtimes default to IPv6-aware behavior.
Address abundance simplifies architecture. With /64 subnets per VPC and effectively unlimited address space, you stop fighting RFC 1918 conflicts, routing complexity, and overlapping subnet headaches that haunt large IPv4 networks.

The Three IPv6 Deployment Models

Dual-stack (most common today)

Every host has both an IPv4 and an IPv6 address. Hosts prefer IPv6 (Happy Eyeballs algorithm) but fall back to IPv4. Compatibility is maximum; complexity is also maximum (you operate two networks).

Best for: organizations early in the IPv6 journey, organizations with legacy applications they cannot move quickly.

IPv6-mostly (the modern compromise)

Hosts use IPv6 internally for everything. Outbound to legacy IPv4 internet uses NAT64 (translates IPv6 traffic to IPv4 at the edge). DNS64 synthesizes IPv6 addresses for IPv4-only destinations.

Best for: organizations that want IPv6's internal benefits without losing reach to IPv4-only external services. The default recommendation for new internal infrastructure in 2026.

IPv6-only (pure)

Every interface is IPv6. No NAT64. Hosts cannot reach IPv4-only services at all. Maximum simplicity, but requires that every dependency is IPv6-reachable.

Best for: greenfield infrastructure, environments where dependencies are under your control and IPv6-ready, mobile carrier scenarios.

What Actually Breaks

1. Hardcoded IPv4 addresses

Some applications still embed literal IPv4 addresses in configuration, code, or schemas. These break instantly in IPv6-only mode. The fix is always "use names, resolve at runtime" — but finding all the hardcoded addresses in a large codebase is real grep work.

2. IPv4-only library calls

Older code that uses socket(AF_INET, ...) instead of socket(AF_INET6, ...) or, better, the modern getaddrinfo()-based pattern that handles both. Most modern languages handle this transparently in their high-level networking APIs; raw socket code may need updates.

3. Database client libraries

Several popular database client libraries had subtle IPv6 bugs as recently as 2024. By 2026 most are fixed, but verify your specific library version. The PostgreSQL libpq, MySQL connectors, and Redis clients all have full IPv6 support in current versions.

4. SaaS dependencies

Stripe, Twilio, Datadog, GitHub, Slack — most major SaaS providers now offer IPv6 endpoints, but not all do. Check each dependency. NAT64 covers most cases but introduces a single point of failure for outbound IPv4 traffic.

5. Operational tooling

Some monitoring scripts, ad-hoc network diagnostic tools, and shell pipelines silently assume IPv4 (parsing dotted-quad addresses, hardcoded /24 patterns). Audit and update these — most are easy fixes once identified.

6. Legacy on-prem hardware

Older switches, routers, firewalls, and load balancers may have IPv6 support that is buggy, slow, or feature-incomplete. For new procurement, IPv6 must be a first-class requirement; for existing hardware, test thoroughly before committing to IPv6-only.

NAT64 and DNS64: The Bridge to IPv4

For IPv6-only networks that need to reach legacy IPv4 services, NAT64 + DNS64 is the standard pattern.

How it works

A host queries DNS for an external service (example.com).
DNS64-aware resolver checks for AAAA (IPv6) records first.
If only A (IPv4) records exist, DNS64 synthesizes an AAAA record by encoding the IPv4 address inside a special IPv6 prefix (typically 64:ff9b::/96).
The host connects to the synthetic IPv6 address.
The NAT64 gateway translates the IPv6 packet into an IPv4 packet using the embedded IPv4 address as destination.
Return traffic is translated back from IPv4 to IPv6.

From the application's perspective, it is making a normal IPv6 connection. The translation is transparent.

Operational gotchas

Performance: NAT64 adds latency (typically 1-3ms in well-tuned setups, more in poor implementations) and CPU overhead. For high-throughput external connections, scale your NAT64 gateways accordingly.
Connection state: NAT64 must maintain per-connection state. A single gateway has finite state table size; plan for failover and load balancing.
Logging and audit: traffic flows that cross NAT64 are visible as IPv6 on one side and IPv4 on the other. Correlation requires NAT64 logs.
DNS64 quirks: applications that bypass DNS (e.g., embedded IPv4 literals, hardcoded IPv4 in TLS certificate SANs) bypass DNS64. NAT46 is sometimes needed for the reverse direction.

Implementations

Tayga — the classic Linux user-space NAT64 implementation. Simple, reliable, scales to modest workloads.
Jool — kernel-based, higher performance, more features. Standard for production deployments.
Cloud-native — AWS, GCP, and Azure all offer managed NAT64 services. For cloud workloads, this is the default choice.
BIND with DNS64 — the standard DNS resolver for IPv6-only environments. Configure with dns64 directive.

Application Patterns

Listen on IPv6, accept both

The recommended pattern for dual-stack hosts: bind your service to :: (any IPv6 address) and let the dual-stack socket accept IPv4 connections too (mapped to IPv6 form like ::ffff:1.2.3.4):

# Python example
import socket
sock = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)
sock.setsockopt(socket.IPPROTO_IPV6, socket.IPV6_V6ONLY, 0)  # Allow v4-mapped
sock.bind(('::', 8080))
sock.listen()

For pure IPv6 environments, the IPV6_V6ONLY=1 setting is appropriate (reject mapped IPv4 connections explicitly).

Use getaddrinfo, never gethostbyname

The old gethostbyname() function is IPv4-only. getaddrinfo() handles both protocols and returns the proper structure. Modern language APIs use it under the hood; if your code calls the legacy function directly, replace it.

HTTP clients should respect Happy Eyeballs

RFC 8305 (Happy Eyeballs v2) defines the algorithm for trying IPv6 first, falling back to IPv4 quickly if v6 is broken. All modern HTTP libraries implement this correctly. If you are using an old HTTP client that does sequential v6-then-v4 with long timeouts, upgrade.

TLS certificates and SNI

Use hostnames in your URLs and SNI, not literal addresses. Certificates can include IPv6 addresses in SAN, but it is rarely worth the operational complexity. IPv6 + DNS-based naming is the clean path.

Cloud Provider Specifics

AWS

IPv6-only subnets supported in all major regions since 2022.
Pricing: you save $3.65/month per public IPv4 address you do not allocate.
NAT64 available via AWS Network Manager or third-party AMIs.
EKS supports IPv6-only mode for clusters; many AWS-native services (S3, DynamoDB, ECR) have IPv6 endpoints.
The lingering issue: a few AWS service endpoints are still IPv4-only; check the IPv6 service support list.

GCP

IPv6-only VPCs supported.
Excellent IPv6 support across most managed services.
NAT64 via Cloud NAT.
GKE handles IPv6 well; clusters can be configured single-stack IPv6.

Azure

IPv6-only Virtual Networks supported.
Service support varies by service age; verify each dependency.
NAT64 via NAT Gateway with IPv6 configuration.

Migration Sequence That Works

For an organization moving from IPv4-only to IPv6-mostly (the realistic 2026 target):

Audit dependencies. List every external service, library, and dependency. Mark each as IPv6-ready, NAT64-compatible, or IPv4-only-blocker.
Stand up dual-stack first. Add IPv6 to existing networks without removing IPv4. Verify everything still works. This is the safe rollback baseline.
Audit applications. Find hardcoded IPv4 addresses, legacy library calls, IPv4-assuming scripts. Fix or document.
Deploy NAT64 + DNS64 in test environment. Verify legacy IPv4 destinations are reachable. Tune NAT64 capacity.
Roll out IPv6-mostly to non-critical environments. Dev, staging, internal tools first. Operate for 30-60 days; surface remaining issues.
Production rollout per workload. Move workloads one at a time. Monitor for issues. Have IPv4 fallback ready.
Decommission IPv4 where viable. For internal-only workloads, drop IPv4 entirely. For external-facing workloads, keep dual-stack until you can confirm all clients are IPv6-capable.

Operational Lessons Learned

1. Address allocation discipline matters

The 128-bit address space invites carelessness. Maintain an IP address management (IPAM) system even for IPv6 — tools like NetBox, phpIPAM, or cloud-native IPAM services. /64 subnets per VLAN, hierarchical allocation by region/datacenter/role, documented allocations.

2. Reverse DNS for IPv6 is non-optional

SSH connection delays, mail server failures, and log entries with raw addresses all stem from missing or slow IPv6 reverse DNS. Set up rDNS for your IPv6 ranges; consider catch-all reverse DNS for cloud assignments.

3. Firewall rules are different

IPv6 firewall rules are a separate ruleset from IPv4 (ip6tables vs iptables; IPv6-aware groups in cloud firewalls). Forgetting to mirror rules is a common gotcha. Use config-management tools (Terraform, Ansible) to keep them in sync.

4. ICMPv6 is more important than ICMPv4 was

Path MTU Discovery, Neighbor Discovery, Router Advertisements all use ICMPv6. Blocking ICMPv6 broadly (a habit from IPv4 defensive practice) breaks IPv6 networking. Allow specific ICMPv6 types per RFC 4890.

5. Documentation matters more than ever

IPv6 addresses are harder to remember and recognize than IPv4. Document subnet purposes clearly. Use consistent prefix conventions (e.g., always allocate /64 per VLAN, always use specific patterns for management subnets).

Frequently Asked Questions

Do I need IPv6 just for cost reasons?

If you have hundreds of public IPv4 addresses, the AWS-style per-address charge adds up. Below that scale, the cost benefit alone is unlikely to justify the migration; do it for architectural simplicity and future-proofing.

What about user-facing websites?

Dual-stack is the answer. Make sure your public website, API, and CDN are reachable over both. Modern CDNs (Cloudflare, Fastly, AWS CloudFront) handle this automatically. Pure IPv6-only public services lock out a non-trivial percentage of users.

Does Kubernetes work IPv6-only?

Yes — single-stack IPv6 mode has been stable since Kubernetes 1.21. Most major networking plugins (Cilium, Calico, Flannel) support it. The cluster-internal traffic, service IPs, and pod IPs are all IPv6.

What's the deal with NAT66?

NAT66 (NAT for IPv6) exists but is generally a bad idea. The whole point of IPv6 is address abundance — you do not need NAT. Use proper subnet allocation and routing instead.

How do I handle clients without IPv6?

Dual-stack on the front end. NAT64 gateways at the edge so internal IPv6-only services can be reached by IPv4 clients (NAT46). For 2026 consumer traffic, IPv6 capability is high enough that pure IPv4 clients are a small minority but not zero.

What about logging and audit?

IPv6 addresses in logs need a bit more care. Use canonical representation (RFC 5952) consistently. Log analysis tools mostly handle IPv6 correctly in 2026; verify your specific stack.

One Real IPv6-Only Story

A telecommunications company we work with migrated their internal Kubernetes clusters to IPv6-only over six months in 2025. The motivation: they had grown to a point where IPv4 subnet exhaustion was a real planning problem, and they were maintaining painful workarounds for VPC peering between subnets that overlapped. The technical migration was the easier part — Cilium handled IPv6-only clusters cleanly, and most of their applications were already IPv6-clean. The harder parts were operational: updating monitoring dashboards, retraining the on-call team, fixing dozens of small scripts that assumed IPv4, and one specifically painful database driver upgrade. NAT64 + DNS64 (Jool + BIND) handled the small handful of external IPv4-only services they depended on. Six months in: their CIDR planning headaches gone, their cross-region VPC architecture dramatically simpler, application performance unchanged, no production incidents attributable to IPv6 issues. The team's net assessment: would do it again, would do it sooner.

The Bottom Line

IPv6-only is mainstream in 2026 for organizations willing to do the migration work. The benefits — address abundance, simpler architecture, lower IPv4 costs — are real. The migration is moderate engineering effort for greenfield environments and significant effort for legacy ones. NAT64 + DNS64 is the bridge that lets you go IPv6-internal while still reaching IPv4-only external services. Start with dual-stack to derisk; move to IPv6-mostly when applications are clean; reach pure IPv6-only when dependencies justify it. The direction of travel is clear; teams that move sooner avoid the worst of the IPv4 cost growth and the operational complexity of perpetual dual-stack.

Categories