IPv6 /64 subnet planning and migration

IPv6 subnet planning is not IPv4 planning with longer addresses. On ordinary LANs, the/64 is the operating unit: the first 64 bits identify the subnet and the remaining 64 bits identify an interface. Plan the subnet identifier for topology and policy instead of making LAN prefixes longer to conserve individual addresses.

A migration is also more than assigning addresses. Routing, Router Advertisements, DNS, filtering, monitoring, applications, and upstream connectivity must all work over IPv6 before users can depend on it. This guide joins the address plan and rollout plan so neither is tested in isolation.

Why ordinary IPv6 LANs use /64

A /64 contains 2⁶⁴ addresses. That large count is not a target for host density. It provides the 64-bit interface-identifier field used by standard IPv6 address architecture and Stateless Address Autoconfiguration (SLAAC). A VLAN with 20 devices and one with 20,000 devices can both receive a /64.

The prefix length still changes for deliberate roles. A routed site normally receives a prefix shorter than /64 so it can create many LANs. RFC 6177 deliberately avoids requiring one universal site size: a provider might delegate a /48, /56, or another prefix that leaves enough subnet bits. Point-to-point router links can use/127 under RFC 6164, while a loopback or host route can use /128.

Worked example: allocate a /48 across sites and LANs

Example Networks receives the documentation prefix 2001:db8:4a00::/48. The first three hextets are fixed. The fourth hextet supplies 16 subnet bits, enough for 65,536 distinct/64s.

The team first assigns one aligned /56 to each major routing domain. A/56 fixes the first eight bits of the fourth hextet and leaves eight bits for 256 LANs at that site.

These four blocks are consecutive and easy to summarize internally, but they do not consume the rest of the /48. Keeping later /56 boundaries free avoids renumbering when another site, region, or routing policy appears.

Allocate headquarters /64s by function

Inside the headquarters /56, the team uses visible hexadecimal increments. It does not pack VLANs into consecutive values merely to save subnet identifiers.

The subnet identifier communicates function while unused values leave growth room. The plan remains valid if VLAN numbers later differ: document the mapping in IPAM rather than assuming the decimal VLAN number and hexadecimal subnet identifier are interchangeable.

A staged IPv6 migration plan

Dual stack is a transition state, not proof that IPv6 works. Track each dependency and require IPv6-path evidence at every stage.

1. Inventory: record upstream transit, routers, switches, firewalls, VPNs, load balancers, DNS, DHCP, IPAM, monitoring, operating systems, applications, and third parties. Identify products that support IPv6 only in newer software or licensing tiers.
2. Plan: obtain a routable prefix, define the site and /64hierarchy, add reverse-DNS and IPAM handling, and create IPv6 routing and security policy. Copying an IPv4 access list is not enough because discovery and control traffic differ.
3. Pilot: enable dual stack on a contained staff or lab VLAN. Validate Router Advertisements, address formation, recursive DNS, MTU, first-hop security, telemetry, and inbound and outbound filtering.
4. Publish services: add an AAAA record only after the service, load balancer, firewall, monitoring, and return route work over IPv6. Test from an external IPv6 network before widening DNS exposure.
5. Expand: migrate user and server segments in batches. Compare connection success, latency, DNS answers, help-desk reports, and IPv4 fallback rates before each batch.
6. Reduce IPv4 dependence: trial IPv6-only segments only after validating every required destination. Where needed, test DNS64/NAT64 or another documented translation design with applications that use literals, embedded addresses, or IPv4-only protocols.
7. Retire deliberately: remove IPv4 from a segment only when dependency, rollback, monitoring, and support evidence show it is safe. Do not use an arbitrary calendar date as the acceptance test.

Acceptance checks for every migrated subnet

• Hosts receive the intended prefix and default route; unexpected Router Advertisements fail.
• Forward and reverse DNS return the intended records through approved resolvers.
• Internal, internet, VPN, and management paths work in both directions.
• Firewalls enforce equivalent intent for IPv4 and IPv6 without blocking required ICMPv6.
• Path MTU discovery succeeds across tunnels and filtered boundaries.
• Logs, flow records, vulnerability scans, and alerts preserve full IPv6 addresses.
• Rollback restores the last known working routing and DNS state.

Common IPv6 planning mistakes

• Using longer-than-/64 prefixes on ordinary LANs: this can break assumptions made by SLAAC and host implementations. Treat non-/64 LANs as an exception that requires a documented reason and compatibility evidence.
• Assigning one /64 to an entire site: hosts on different security zones need different routed subnets. Request or reserve a shorter site prefix.
• Packing subnets tightly: IPv6 address conservation does not justify removing hierarchy, readable boundaries, or growth space.
• Blocking ICMPv6 wholesale: IPv6 relies on ICMPv6 for essential control and error signaling, including Neighbor Discovery and Packet Too Big messages.
• Publishing AAAA records too early: clients may prefer an IPv6 path that has not yet passed routing, firewall, load-balancer, or monitoring checks.
• Assuming dual stack halves the work: during migration it creates two production paths, two policy surfaces, and new failure modes that both need observation.

Authoritative sources

• RFC 4291 — defines IPv6 addressing architecture, interface identifiers, and prefix representation.
• RFC 4862 — defines Stateless Address Autoconfiguration and its prefix-length requirements.
• RFC 6177 — provides current guidance on end-site prefix assignment without prescribing one size for every site.
• RFC 7421 — analyzes the operational reasons for the 64-bit IPv6 interface-identifier boundary.
• RFC 6164 — documents/127 prefixes for inter-router point-to-point links.
• RFC 6146 andRFC 6147 — define stateful NAT64 and DNS64 for selected IPv6-to-IPv4 transition designs.