Differentiating IPv4 and IPv6 comes down to four practical things: address space (32-bit vs 128-bit), header shape, NAT, and how stacks handle fragmentation. The team that picks IPv6 end-to-end gets rid of CGNAT, gets end-to-end addressing, and avoids the dual-stack surprises that bite production. The team that stays on IPv4 for legacy reasons accepts carrier-grade NAT, address sharing, and a slow migration window as the cost of doing business.
Table of contents
- Address space and the address exhaustion problem
- Header shape and the simplification
- NAT, CGNAT, and end-to-end addressing
- Dual-stack, transition, and the rollout reality
- Practical migration steps
- FAQ
Address space and the address exhaustion problem
IPv4 is 32 bits, which gives roughly 4.3 billion addresses. That sounds like a lot until you remember that every server, phone, IoT device, and laptop needs one. The address pool was officially exhausted at the IANA level in 2011, and regional registries ran out within a few years after. The team that hits IPv4 exhaustion in 2026 has the same problem the team had in 2015: there are no more addresses to allocate.
IPv6 is 128 bits, which gives 340 undecillion addresses. That’s 3.4 x 10^38 - enough addresses to give every atom on the surface of the Earth its own address, with addresses left over. The team that has a customer-facing service in IPv6 has no address-exhaustion problem, no NAT, and end-to-end addressing from the browser to the server.
The address-shape difference matters in practice. IPv4 addresses look like 192.168.1.1 (four decimal octets, each 0-255). IPv6 addresses look like 2001:0db8:85a3:0000:0000:8a2e:0370:7334 (eight groups of four hex digits). The team that reads an IPv6 address learns to skip leading zeros and compress consecutive zero groups (::). The shorthand is readable; the longhand is what shows up in logs.
Header shape and the simplification
The IPv4 header is variable-length and includes options that routers process on every hop. A typical IPv4 header is 20 bytes plus options (up to 60 bytes total). The options include things like Record Route, Timestamp, and Source Route - features designed in 1981 that routers have to parse even when they’re empty.
The IPv6 header is fixed at 40 bytes with no options in the main header. Options moved to extension headers that sit between the IPv6 header and the payload, and most extension headers are not processed by routers - only by the endpoints. The team that ships IPv6 traffic has routers that forward packets faster because they don’t have to walk a variable-length header with potential options.
Fragmentation is the biggest practical difference. IPv4 routers fragment packets when a packet is too big for the next link. IPv6 does not fragment in routers - if a packet is too big, the router drops it and sends an ICMPv6 Packet Too Big message back to the sender. The sender then re-sends with a smaller packet. The team that uses IPv6 has predictable MTU behavior; the team that uses IPv4 has historic surprises where fragmentation halves throughput on slow links.
NAT, CGNAT, and end-to-end addressing
IPv4 was designed without NAT, but the address shortage forced NAT into existence. Home routers do NAT: one public IPv4 address is shared by every device on the LAN, with port numbers used to multiplex connections. Carrier-Grade NAT (CGNAT) takes this further - one public IPv4 address is shared by hundreds of customers at the ISP level. The team whose users are behind CGNAT has problems with inbound connections, peer-to-peer, and any service that needs a stable public address per customer.
IPv6 is designed for end-to-end addressing without NAT. Every device gets a globally routable address from the IPv6 prefix the ISP allocates. There’s no need for NAT because addresses are not scarce. The team that runs an IPv6 service has no port-forwarding, no DMZ, no CGNAT workarounds - the address is the address, and inbound connections work.
The practical implication: a hosting platform that ships IPv6 lets the team run a server on any port without NAT gymnastics. A hosting platform that only ships IPv4 forces the team into port-forwarding, hairpin NAT, or running everything through a reverse proxy. The difference is in the operational friction, not the protocol theory.
Dual-stack, transition, and the rollout reality
Most services in 2026 run dual-stack: IPv4 and IPv6 simultaneously. The team that runs dual-stack has two listeners, two address families, and twice the surface area to monitor. Most modern operating systems prefer IPv6 when both are available (RFC 6555 / Happy Eyeballs), so the team’s users hit IPv6 first if the network supports it.
The transition technologies (NAT64, DNS64, 6rd, DS-Lite) bridge IPv6-only clients to IPv4-only servers. NAT64 is the most common: an IPv6 client sends a DNS query for an IPv4-only host, the DNS64 server synthesizes an IPv6 address that points to the NAT64 gateway, and the gateway translates to IPv4. The team that runs a service on IPv6-only needs NAT64 reachability for IPv4-only clients.
The long-term direction is IPv6-only. Major carriers (Comcast, T-Mobile, Verizon Wireless) ship IPv6 to residential customers by default. Cloud providers (AWS, GCP, Azure) ship dual-stack by default with IPv6-only options on the way. The team that builds greenfield services in 2026 should target IPv6-first and IPv4 as a fallback, not the other way around. The cost of getting this backwards is operational debt that compounds over years.
Practical migration steps
Audit your current IPv4 footprint. Run ip -4 addr on every server, list every public IPv4 address in DNS, and document every firewall rule that references IPv4-only. The team that has the audit knows the migration surface; the team that doesn’t has surprises later.
Get an IPv6 prefix from your hosting provider. Most modern platforms (including RunxBuild) ship IPv6 by default. The team that runs on a managed platform gets IPv6 with no extra configuration; the team that runs on bare metal or VPS needs to request a prefix from the provider.
Ship dual-stack first. Add AAAA records alongside A records, run two listeners, and verify both work. The team that ships dual-stack has parity with the existing IPv4 service; the team that ships IPv6-only forces the migration onto clients who aren’t ready.
Monitor both stacks. Watch IPv4 and IPv6 traffic separately in your monitoring (Prometheus, Datadog, etc.). The team that monitors both catches bugs where IPv6 silently fails - the most common is a firewall rule that allows IPv4 traffic but blocks IPv6, which manifests as ‘works on my machine but not in production’.
FAQ
Is IPv6 faster than IPv4?
In practice, no measurable speed difference at the application layer. The header simplification means routers process IPv6 packets slightly faster, but the bottleneck is almost always application logic, database calls, or external API latency - not the IP header.
Do I need IPv6 if my users are all IPv4?
Yes, because more users are on IPv6-only networks every year. Major mobile carriers (T-Mobile, Verizon Wireless) ship IPv6 to most of their customers. A service that is IPv4-only increasingly fails to reach these users without NAT64 in the path.
What is CGNAT and why does it matter?
Carrier-Grade NAT is when an ISP shares one public IPv4 address across hundreds of customers using port multiplexing. The user experience is: inbound connections don’t work, peer-to-peer is broken, and any service that needs a stable public address per customer fails. IPv6 eliminates CGNAT because addresses are not scarce.
Can I run IPv6-only?
Yes, but expect some IPv4-only clients to need NAT64 reachability. The major cloud providers ship NAT64 gateways. The team that runs IPv6-only has a cleaner operational story; the team that runs dual-stack has backward compatibility.
What is the address format of IPv6?
Eight groups of four hexadecimal digits separated by colons, like 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Leading zeros in each group can be omitted (2001:db8:85a3::8a2e:370:7334), and consecutive groups of zeros can be replaced with :: (only once per address).
Do browsers prefer IPv6 or IPv4?
Modern browsers prefer IPv6 when both are available, per RFC 6555 (Happy Eyeballs). The team that ships a service on both stacks should monitor both - the IPv6 path will get the majority of traffic from IPv6-capable networks.
How this fits the rest of the stack
For a sense of what the full project costs before it commits, the RunxBuild hosting calculator shows the line items together. The API, the database, the storage, the worker, the bandwidth - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers.
Useful related references: