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 /Worked example: an IPv6 transition plan for one /48

A site receives 2001:db8:4c00::/48. (The 2001:db8::/32 block is reserved for documentation under RFC 3849, so nothing here routes anywhere.) The 16 bits between the /48 and the /64 form four hexadecimal nibbles: one for the building, one for the function, two for the VLAN number. Function 0 is infrastructure, 1 is users, 2 is servers. Building 3, user VLAN 32 (hex 20) becomes 2001:db8:4c00:3120::/64. Because the building nibble comes first, every rule about building 3 matches the single prefix 2001:db8:4c00:3000::/52, and every user VLAN in it matches 2001:db8:4c00:3100::/56. That nesting is the whole point of a nibble plan.

$ ip -6 route show default
$ ping -6 2001:db8:4c00:3120::1
router# show ipv6 neighbors | count
router# show ipv6 nd raguard statistics

07 /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. Dual stack also doubles the first-hop work, and the gateway redundancy page covers the election that VRRP version 3 extends to IPv6 gateways; the routing overview lists the other protocols that need an IPv6 counterpart.

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

show ipv6 interface
show ipv6 route

08 /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.

09 /IPv6 transition pitfalls and expert tips

• Path MTU. IPv6 routers never fragment, the minimum link MTU is 1280 bytes (RFC 8200), and a firewall that drops ICMPv6 Packet Too Big (type 2) breaks every large transfer through a smaller link. Permit ICMPv6 types 1 to 4 and 133 to 137 everywhere.
• Temporary addresses. Clients rotate privacy addresses (RFC 4941) daily, so a log line names an address no longer in use. Switch neighbour tracking maps them back; give servers stable addresses under RFC 7217.
• Rogue router advertisements. A tethered phone or a misconfigured virtual machine host announces itself as the default router. RA guard (RFC 6105) on every access port is not optional.

When the /48 is allocated, publish a ROA for the new prefix before announcing it, so networks that validate origins do not drop it. Give every user VLAN a redundant gateway with VRRP version 3 for the IPv6 gateway, and add the IPv6 counters in the IP-MIB to the same dashboards as IPv4 so the two protocols are watched, and retired, on evidence.