IPv6 isn’t a future concern in 2026 — it’s a present concern. About 50% of global traffic carries IPv6. AWS, GCP, and Azure all charge for IPv4 addresses. Mobile carriers run IPv6-first internally. If you’re still running IPv4-only in 2026, you’re not just behind; you’re paying for it in your cloud bill and missing users in IPv6-first markets.

This post is a practical deployment guide. Dual-stack basics, addressing plans, DNS, firewall, application-level gotchas, and the path from IPv4-only to IPv6-only.

Where to Start

The first thing to understand: IPv6 deployment isn’t a flag you flip. It’s a multi-layer rollout that touches DNS, network configuration, firewall rules, application code, monitoring, and operational practice.

The standard milestones:

IPv6-aware infrastructure — Your network supports IPv6. You can ping IPv6 from your servers.
IPv6-reachable services — External users can reach your services over IPv6 (AAAA records, IPv6 frontends).
IPv6-native internals — Your internal networks run on IPv6 with IPv4 as a fallback.
IPv6-only — Some workloads run on IPv6-only with NAT64 or stateless translation for IPv4.

Most organizations are at milestone 2 in 2026. Reaching milestone 3 is the next 5 years of work for many.

Dual-Stack Basics

Dual-stack means your hosts and services run both IPv4 and IPv6 simultaneously. Most modern OSes do this by default if their network interfaces have both kinds of addresses.

For a web server:

DNS A record points to its IPv4 address.
DNS AAAA record points to its IPv6 address.
Web server listens on both 0.0.0.0:443 (IPv4) and [::]:443 (IPv6).
Firewall rules mirror IPv4 and IPv6 (usually via ip6tables or modern nftables).

Clients prefer IPv6 if they have it; fall back to IPv4 if not. This is called Happy Eyeballs (RFC 8305) — the client tries both in parallel and uses whichever responds first.

Addressing Plans

IPv6 addresses look intimidating but the structure is straightforward:

2001:db8:1234:5678:90ab:cdef:1234:5678
└──── prefix ────┘└──── host ────┘

You typically receive a /48 from your ISP or cloud provider — that’s enough for 65,536 /64 subnets. A /64 is the typical subnet size for a single network segment.

A sane addressing plan:

/48 allocated to the organization.
/56 per site (location) — 256 sites possible per /48.
/64 per subnet (network segment) — 256 subnets per site.
Host addresses assigned within /64 either statically, via SLAAC (auto-config), or DHCPv6.

The “huge address space” of IPv6 isn’t really about needing trillions of hosts. It’s about having so much space that you can use bits in the address as structure (department, building, vlan, role) without conserving anything.

SLAAC vs DHCPv6

Two ways hosts get IPv6 addresses:

SLAAC (Stateless Address Autoconfiguration)

The host listens for router advertisements (RAs), takes the /64 prefix from the RA, and constructs its own address by combining the prefix with a host identifier (often derived from the MAC or randomized for privacy).

No central registry. Hosts pick their own addresses within the prefix.
No DHCP server required for addressing.
DNS info typically comes via RA options or DHCPv6 stateless mode.

Used by most consumer IPv6 deployments and many enterprise networks.

DHCPv6

Centralized, like IPv4 DHCP. The DHCP server assigns specific addresses and tracks them.

Central control. Useful for compliance environments that need to track every assigned address.
Required for some use cases like assigning specific addresses to specific hosts.
Less universal: Android famously doesn’t support DHCPv6 well, preferring SLAAC.

Most networks use SLAAC primarily, with DHCPv6 for specific hosts that need static addresses.

DNS

IPv6 deployment without DNS support is invisible. The basics:

AAAA records for IPv6 addresses (the IPv6 equivalent of A records).
PTR records for reverse DNS (in ip6.arpa instead of in-addr.arpa).
Resolver support — most modern DNS resolvers handle both A and AAAA queries by default.

example.com.   IN   A      203.0.113.5
example.com.   IN   AAAA   2001:db8::5

Clients with IPv6 connectivity prefer the AAAA record; clients without it use the A record. No application change required.

For your own DNS infrastructure, ensure your DNS servers themselves are reachable over IPv6. Glue records in your TLD registration should include IPv6 nameserver addresses.

For more on DNS, see how DNS lookup works.

Firewall

IPv6 firewalls work the same conceptually as IPv4 but have separate rulesets. On Linux:

iptables for IPv4
ip6tables for IPv6
nftables unifies both (recommended for new deployments)

A common mistake: deploying IPv6 connectivity without applying firewall rules. Your IPv4 firewall denies traffic; your IPv6 firewall accepts everything by default. Suddenly all your internal services are exposed over IPv6.

Rule: every IPv4 firewall rule needs an IPv6 equivalent. Don’t deploy IPv6 until you’ve audited both rulesets.

NAT Is (Mostly) Not Needed

IPv4 deployments rely heavily on NAT — private addresses inside, public addresses outside, NAT in between. See NAT and CGNAT.

IPv6 deployments typically don’t use NAT. Every host gets a globally unique address. The benefits:

End-to-end connectivity (subject to firewall rules).
No NAT table state to manage.
Direct addressability for protocols that struggle with NAT (SIP, FTP, gaming).

The trade-off: every host is potentially reachable from the public internet. Your firewall has to do the access control that NAT incidentally provided in IPv4. This is a real shift in operational thinking.

Don’t deploy IPv6 without explicit firewall policy. “Use NAT for security” doesn’t translate; “use firewall rules for security” does.

Application Considerations

A few places IPv6 trips up application code:

Address parsing

IPv6 addresses can contain colons; URLs use brackets to disambiguate:

http://[2001:db8::5]:8080/path

If your app parses URLs naively, it might split on : and break IPv6. Use URL libraries, not regex.

Logging

Log IP addresses as strings. Don’t truncate at 15 characters (the max IPv4 string length). Don’t assume database fields can hold the max IPv6 string (45 characters with full notation).

Address comparison

Use library functions to compare normalized representations. The strings 2001:db8::5 and 2001:0db8:0000:0000:0000:0000:0000:0005 are the same address; string equality won’t tell you so.

Geolocation lookup

Make sure your geolocation provider has good IPv6 coverage. Older databases focused on IPv4; modern providers cover both. The Ip2Geo API handles both transparently — same endpoint, same response shape. For details, how to geolocate an IP.

Privacy addresses

IPv6 hosts often use temporary/privacy addresses that change daily. The address you see today may not be the same as tomorrow. Don’t build long-term IP-based identification expecting stability.

Cloud-Specific Notes

AWS

Full IPv6 support in VPC since 2017.
Dual-stack EC2 instances; recently full IPv6-only options.
Public IPv4 costs $0.005/hour as of 2024. IPv6 is free.
Some services still IPv4-only (RDS for some engines, certain S3 access patterns).

GCP

IPv6 supported in most regions.
Dual-stack VPC subnets.
Load balancers support IPv6 frontends.
Internal traffic between VMs has historically been IPv4 only in some configurations.

Azure

IPv6 supported in most regions.
Dual-stack VNets.
Has lagged behind AWS in some IPv6 features but caught up substantially in 2024-2025.

For all clouds, the practical pattern: dual-stack public-facing, IPv4 internal for now. Migrating internal infrastructure to IPv6-native is a multi-year project.

NAT64 and Translation

For the path to IPv6-only, you need a way for IPv6-only hosts to reach IPv4-only services (legacy APIs, third-party endpoints that haven’t deployed IPv6 yet). The standard mechanism:

NAT64

A gateway that translates IPv6 traffic to IPv4. The IPv6-only host queries DNS, gets a synthetic AAAA record that maps to an IPv4 destination, and connects through the NAT64.

Used by major mobile networks. Apple requires iOS apps to work behind NAT64 (T-Mobile US has used NAT64 internally for years).

464XLAT

A combination of NAT64 plus client-side translation for applications that don’t handle synthetic addresses well. Mostly mobile-network specific.

DNS64

The DNS half of NAT64. Generates synthetic AAAA records for IPv4-only destinations.

For most organizations, the relevant fact is “iOS apps and modern Android apps already work behind NAT64.” If you’re building a mobile app, IPv6-only support is essentially free as long as you use modern networking APIs.

Monitoring and Observability

Your monitoring needs to see both IPv4 and IPv6 traffic:

Logs capture IPs as strings (varchar length 45+).
Metrics tag traffic by address family.
Tracing preserves both protocols’ addresses across hops.
Dashboards show IPv6 vs IPv4 percentages.

Tools that are IPv4-only or render IPv6 badly are a hidden cost. Many older monitoring stacks need updates.

The Path to IPv6-Only

For most organizations, the long-term goal is IPv6-only internal networks with NAT64 for external IPv4 reachability. The phases:

Today: Dual-stack public-facing. Mostly IPv4 internal.
Next 2-3 years: Dual-stack internal. IPv6 native for new services.
Long term: IPv6-only internal. IPv4 only at edge for legacy interop.

Each phase reduces the IPv4 footprint, which reduces both IPv4 costs (cloud bills) and operational complexity (fewer dual-stack edge cases).

TL;DR

IPv6 is now, not future. ~50% of global traffic in 2026.
Start with dual-stack public-facing services. A and AAAA records, dual-stack listeners.
Use /48 from your provider, /64 subnets internally.
SLAAC for most hosts, DHCPv6 where you need stateful management.
Mirror IPv4 firewall rules in IPv6. Don’t deploy without auditing both.
No NAT in IPv6. Firewall does access control instead.
Update application code for IPv6 address parsing, longer log fields, library-based comparison.
NAT64 makes IPv6-only deployments possible while preserving IPv4 reachability.

IPv6 deployment in 2026 is no longer a research project. The protocols, cloud support, and operational tooling are mature. The bottleneck is organizational — taking the time to actually do the dual-stack work, update the firewall rules, and audit the application code. For the broader transition context, see IPv4 vs IPv6; for the marketplace economics that are pushing IPv6 adoption, IPv4 exhaustion and the marketplace.

IPv6 Deployment Guide: From Dual-Stack to IPv6-Only