IPv6 Transition: Dual Stack, Tunnels, Translation and Planning

01 /Why IPv4 ran out

IPv4 has 32-bit addresses, about 4.3 billion, and early allocation handed out /8 blocks of 16 million to single organisations. NAT stretched the supply for two decades by hiding whole networks behind one address, at the cost of end-to-end reachability. The central IANA pool was exhausted in February 2011; the regional registries followed, and addresses now trade on a secondary market. IPv6 (RFC 8200, originally RFC 2460) uses 128-bit addresses and ends the shortage.

02 /Dual stack

Every interface carries both addresses, every service listens on both, and DNS publishes A and AAAA records. Applications prefer IPv6 when both resolve; Happy Eyeballs (RFC 8305) races the two so a broken IPv6 path does not stall the user. Dual stack is the least surprising method because nothing is translated or encapsulated. Its cost is running two of everything: address plans, firewall rules, monitoring views. It is a bridge to an IPv6-only end state.

03 /Tunnelling: 6in4, 6rd and ISATAP

Tunnels carry IPv6 inside IPv4 across networks that cannot route IPv6 natively. 6in4 (IP protocol 41) is a manually configured point-to-point tunnel, the workhorse of early adopters. 6rd derives each customer IPv6 prefix from its IPv4 address so an ISP can deliver IPv6 over an unchanged IPv4 access network; several large ISPs launched with it. ISATAP and Teredo were host-based automatic tunnels and are now historical. Tunnels add MTU problems (1480 bytes inside 1500) and a dependency on the IPv4 path. Treat them as scaffolding.

04 /Translation: NAT64, DNS64 and 464XLAT

Translation serves the reverse problem: IPv6-only clients must still reach the IPv4-only internet. NAT64 rewrites IPv6 packets addressed into a well-known prefix (64:ff9b::/96) into IPv4 packets from a shared address pool. DNS64 synthesises AAAA records for names that have only A records, embedding the IPv4 address in that prefix so the client sends to the NAT64. 464XLAT adds a client-side translator so applications that hard-code IPv4 literals still work; mobile networks run IPv6-only handsets this way.

05 /Address planning, SLAAC and DHCPv6

Allocate a /64 per LAN without exception; stateless autoconfiguration requires it and nothing is saved by going smaller. Allocate a /48 per site (65,536 /64s), which lets a nibble-boundary plan encode building and floor in hexadecimal digits; residential providers typically hand out /56. Summarisation and firewall rules stay readable when the plan follows nibble boundaries.

Hosts learn addresses by SLAAC (router advertisements give the prefix; the host builds the rest) or by DHCPv6 (a server assigns addresses and options). SLAAC is simpler and the only option for client operating systems that never implemented DHCPv6 addressing, but it gives operators no lease table; DHCPv6 gives control and logging but not every client supports it. Most enterprises run SLAAC plus DHCPv6 for options and rely on switch neighbour tracking for accountability.

06 /Security parity and hardware forwarding

IPv6 is present on every modern host whether or not the network intends it. A firewall that filters IPv4 and passes IPv6 by default has a hole; a host sending rogue router advertisements can hijack a whole VLAN. Apply RA guard and DHCPv6 guard on access ports, filter ICMPv6 carefully, and give every IPv4 rule an IPv6 twin.

Forwarding hardware is the other constraint. IPv6 lookups need 128-bit keys and wider TCAM entries; early Layer 3 switch ASICs built around IPv4 forwarded IPv6 in software at a small fraction of line rate, or not at all. Foundry added IPv6 routing to BigIron and NetIron around 2004 to 2006, and "ipv6" became the most searched term on the original site as engineers checked which modules supported it. Second-hand gear from that era needs the same check; see Layer 2 versus Layer 3.

ipv6 unicast-routing
interface ve 10
 ipv6 address 2001:db8:10::1/64
 ipv6 nd ra-interval 200
!
show ipv6 interface
show ipv6 route

07 /Enterprise adoption checklist

1. Obtain a /48 or larger per site and write the plan on nibble boundaries before configuring anything.
2. Audit every switch, router, firewall and load balancer for hardware IPv6 forwarding, then enable IPv6 at the perimeter and DNS first, then the core, then user VLANs.
3. Replicate every IPv4 firewall rule, ACL and monitoring view for IPv6; add RA guard on access ports.
4. Trial NAT64 and DNS64 on a lab VLAN to find applications that break IPv6-only.