IPv4 vs IPv6: Key Differences, Benefits, and Migration Tips
When you weigh IPv4 against IPv6, you’re comparing a protocol that squeezed every drop from a 32-bit space to one built for abundance, simplicity, and end-to-end reachability. The differences aren’t abstract; they change how you plan addressing, operate DNS, segment networks, and troubleshoot.
We’ll break down concrete contrasts—address format and notation, how neighbor discovery replaces ARP, why NAT became a crutch in IPv4 and what end-to-end actually unlocks in IPv6—then move to hands-on migration choices for dual-stack and IPv6-only designs. Expect specific prefix lengths, control-plane knobs, and validation steps you can copy into change plans.
If your team is new to IPv6, don’t worry about the hex; worry about consistency. A good plan uses /64s for subnets, names things well, publishes AAAA where it matters, and keeps the right ICMPv6 flowing so Path MTU Discovery and Neighbor Discovery work under load.
Address Formats and Notation
IPv4 addresses are 32-bit dotted decimals (for example, 203.0.113.42) with CIDR masks like /24. IPv6 uses 128-bit hex groups (for example, 2001:db8:12:34::1/64). You shorten IPv6 by removing leading zeros inside groups and compressing a single longest run of all-zero groups with “::”. Prefer lowercase and a canonical representation so logs, configs, and docs match.
Address Types and Scopes
Global unicast addresses route on the internet. Link-local addresses (fe80::/10) exist on every interface and fuel Neighbor Discovery, Router Solicitations/Advertisements, and default-gateway selection. Unique local addresses (fc00::/7, typically fd00::/8) behave like private space but aren’t a security boundary; use them for internal-only namespaces or as stable anchors behind site borders. IPv6 eliminates broadcast; it uses multicast for discovery and services, which reduces noise and scales better in large L2 domains.
Subnetting and the /64 Boundary
Plan on /64 per L2 subnet. Stateless autoconfiguration (SLAAC) assumes 64-bit interface identifiers, and many stacks and features—from privacy addressing to efficient Neighbor Discovery—expect that size. It’s common to receive a /48 (business) or /56 (smaller sites or edge cases) from providers; carve /64s from that aggregate. While routing can handle other prefix lengths, sticking to /64 on access keeps hosts predictable and avoids subtle breakage with SLAAC and some appliances.
Neighbor Discovery Replaces ARP
IPv6 replaces ARP with Neighbor Discovery (ICMPv6 Neighbor Solicitation/Advertisement plus Router Solicitation/Advertisement). Switches should enable RA Guard at the edge to prevent rogue gateways, and you’ll want MLD snooping to keep multicast scoped. Duplicate Address Detection should stay on unless you have a specific reason to disable it in latency-critical clusters with careful admission control.
NAT Versus End-to-End
Most IPv4 sites rely on NAT for address amplification and incidental policy. IPv6 removes the scarcity, so you regain end-to-end reachability and simpler troubleshooting. Stateful firewalls still enforce policy; NAT is not a security control by itself. If you must translate, prefer NPTv6 (prefix translation) at borders to keep addresses stable inside while preserving transport ports and remaining checksum-neutral by design. Avoid NAT66 unless a vendor limitation corners you.
Extension Headers and Middleboxes
IPv6 supports extension headers—routing, fragmentation, hop-by-hop, and destination options—as a header chain after the fixed 40-byte header. In practice, some middleboxes and filters mishandle or drop packets with certain extension headers, so keep them to well-supported uses and test with your providers. Don’t rely on in-path fragmentation from routers; only endpoints fragment in IPv6.
MTU, Fragmentation, and Path MTU Discovery
The minimum IPv6 link MTU is 1280 bytes. Routers never fragment; when a packet is too big on some hop, an ICMPv6 Packet Too Big informs the sender so it can lower its size. That means Path MTU Discovery must work, and aggressive ICMPv6 filtering will cause black-hole sessions. Keep Packet Too Big, Time Exceeded, Echo, and Neighbor Discovery messages flowing through stateful devices.
DNS in IPv4 and IPv6
IPv4 uses A records; IPv6 adds AAAA for forward mapping and ip6.arpa in nibble format for reverse. Represent your addresses consistently, publish AAAA where you want IPv6 used, and avoid advertising IPv6 for services that aren’t reachable over IPv6 yet. For host DNS configuration on IPv6 networks, you can supply resolvers either with DHCPv6 options or by advertising RDNSS/DNSSL in Router Advertisements—both are common in campus networks today.
Privacy, Stable IIDs, and Logging
SLAAC historically built interface IDs from MACs (EUI-64), which is traceable. Modern stacks default to privacy extensions that rotate temporary source addresses for outbound connections and also support semantically opaque, stable interface IDs that are per-subnet stable without exposing hardware addresses. For operations, that means dual addresses on hosts is normal: stable for inbound/policy and temporary for outbound. Plan your log pipelines accordingly: collect both and correlate with DHCPv6 leases when you use stateful addressing.
Dual-Stack or IPv6-Only
Most brownfield migrations start dual-stack at the edge and the server tiers that serve public clients. Dual-stack plus Happy Eyeballs on clients and proxies ensures fast connection setup regardless of which family wins in a given path. IPv6-only shines in greenfield footprints—cloud VPCs, containers, managed Wi-Fi—when you need to remove IPv4 complexity. For IPv6-only clients that must reach legacy IPv4-only services, deploy NAT64/DNS64; for mobile or branch footprints under carrier NAT, 464XLAT on clients is battle-tested.
Security Posture Without NAT
Use stateful firewalls and micro-segmentation the way you always wanted to, but had to contort around NAT. Filter ICMPv6 selectively—don’t block the control messages the protocol needs. Keep Unicast Reverse Path Forwarding and BCP 38/84 ingress filtering on WAN edges. Harden L2 with RA Guard and DHCPv6 Guard. Monitor Neighbor Discovery cache pressure and Path MTU Discovery failures the same way you’d watch ARP and MSS issues in IPv4.
Practical Migration Tips (Dual-Stack)
Number first, then publish. Allocate an aggregate (typically a /48 for a site) and carve /64s per L2 segment. Stage Router Advertisements on access VLANs with managed/other flags set to match your approach—SLAAC-only, SLAAC plus stateless DHCPv6 for options, or full DHCPv6. Put AAAA on public services that are reachable over IPv6 behind your load balancers and WAFs. Enable Happy Eyeballs on proxies, app runtimes, and egress gateways so user experience remains snappy even during partial outages. In BGP, advertise aggregates; don’t plan on the internet accepting specifics longer than /48, and make sure upstreams have your route maps and communities right before the change window.
Practical Migration Tips (IPv6-Only)
For client networks, run NAT64/DNS64 close to users to keep latency down; use the well-known prefix 64:ff9b::/96 or a provider-specific prefix and document it. If apps break on literal IPv4s or IPv4-only DNS, 464XLAT on endpoints smooths rough edges. In data centers and cloud, request native IPv6 for load balancers, gateways, and peering; where you must bridge to IPv4 services, constrain translation boundaries and observe them aggressively with synthetic tests and logs.
Observability and Day-2 Operations
Update runbooks and tooling: your flow collectors should parse IPv6 headers and extension chains; your SIEM and APM should accept 128-bit addresses; your whois/rdap and reverse-DNS workflows must handle ip6.arpa. Teach your synthetics to test AAAA reachability and Path MTU Discovery—including catching MTU black holes—and your network dashboards to show Neighbor Discovery counters, RA/DAD anomalies, and RDNSS lifetimes.
Common Misconceptions to Avoid
“/64 wastes space” confuses human scale with protocol design; the abundance is what lets hosts self-configure safely. “We need NAT for security” mistakes address translation for policy—stateful inspection and least privilege do the real work. “ICMP is dangerous; block it” quietly breaks Path MTU Discovery and Neighbor Discovery; filter thoughtfully and test.
A Sane First 30-Day Plan
Inventory: confirm your ISP assigns IPv6 and request at least a /48 for multi-VLAN sites. Addressing: draft a simple, hierarchical plan with /64s per segment and room to grow. Control plane: turn on IPv6 in IGP/BGP and Router Advertisements on a pilot VLAN, with RDNSS or DHCPv6 options matching your desktop standards. Security: enable RA Guard, DHCPv6 Guard, and review ICMPv6 filters to allow Neighbor Discovery and Packet Too Big. Applications: pick three public properties for AAAA enablement behind your edge. Testing: validate Path MTU Discovery, Neighbor Discovery health, and DNS over IPv6 from wired and Wi-Fi. Operations: wire dashboards, logs, and alarms to IPv6-aware views before widening scope.
Quick Reference: What to Enable Where
Access switches: RA Guard and MLD snooping; firewalls: allow essential ICMPv6 (Neighbor Discovery, Packet Too Big, Time Exceeded, Echo), keep stateful inspection and Unicast Reverse Path Forwarding; routers: advertise /64s via Router Advertisements, run IGP/BGP for aggregates (/48 outward), keep policies friendly to Path MTU Discovery; DNS: AAAA and PTR under ip6.arpa with consistent canonical text; clients: privacy addresses and Happy Eyeballs.
Quick Reference: When Translation Is Inevitable
NAT64/DNS64 for IPv6-only clients to IPv4-only servers; 464XLAT for mobile or edge clients behind carrier NAT; NPTv6 at borders when you need stable internal addressing and provider switch flexibility without per-flow state.
