IPv6 design and migration
Requirement / business driver
IPv6 is driven by public-IPv4 scarcity, regulatory or customer mandates, reaching IPv6-only services, or future-proofing. The hard design question is rarely "how does IPv6 work" - it's where to start and how to coexist with IPv4 without breaking applications.
The phased (top-down) approach
Treat IPv6 enablement as a staged programme, each phase feeding the next (no "design in isolation"):
- Discovery - business goals/drivers, timeframe, compliance, site/addressing geography, and which infrastructure (LAN/WAN/security/services/apps) already supports IPv6.
- Assessment & planning - analyse the drivers and pick the transition approach given constraints (budget, node support, app readiness).
- Detailed design - select the concrete mechanisms (below) and the addressing plan.
- Deployment, then monitoring & optimisation.
Transition mechanisms (three families)
- Dual-stack - run IPv4 and IPv6 on every L3 node, end to end. The cleanest end-state; needs IPv6 support everywhere and adds resource/control-plane load. Typically migrate the core to dual-stack first, then the other modules.
- Tunnelling - carry IPv6 over an IPv4 transit that doesn't support it (or vice versa): GRE/L2TPv3 (point-to-point), ISATAP (host-sourced), mGRE, 6rd (RFC 5969, SP-driven, stateless). Good for a small number of islands / transit; adds overlay complexity and can complicate multicast/QoS.
- Translation - NAT64 (stateful IPv6->IPv4, usually paired with DNS64), DNS-based translation, or LISP. Lets IPv6-only clients reach IPv4-only services; works by name, not by IP, and doesn't cover every application - a transition tool, not a permanent habit.
Choosing an approach
Map to the goal and the constraint: whole-network IPv6 with budget to upgrade -> dual-stack (core first); only the edge needs IPv6 (e.g. Internet edge for IPv4 exhaustion) -> edge dual-stack / translation; core can't be upgraded but new IPv6 apps must be reached -> tunnelling or NAT64/DNS64 across the IPv4 core; greenfield IPv6 reaching legacy IPv4 services -> NAT64 + DNS64. See general migration mechanics in Reference models and migration considerations and NAT specifics in Generic routing and addressing - PBR, NAT, RIB-FIB.
IPv6 deployment models and address assignment
Beyond which transition mechanism, choose where transition lives - three deployment models. Dual-stack model: v6 runs natively everywhere alongside v4 (the strategic end-state; needs v6 support end to end). Hybrid model: dual-stack where you can, with tunnelling/translation bridging the parts that aren't ready - the pragmatic interim. Service-block model: confine the transition machinery (tunnel terminations, NAT64) to a dedicated services block the way you would a DMZ, so islands connect through one controlled, centrally-managed point instead of scattering transition config across the campus - useful for a fast, contained rollout you later dissolve into native dual-stack. For host addressing, also pick the assignment method: SLAAC (stateless - the host builds its address from the RA prefix; simple, no server, but no per-host record), DHCPv6 (stateful - central control and logging), or both; note the default gateway always comes from the RA, never from DHCPv6, so RAs are required regardless.
The address plan doctrine - /64, nibbles, and a Subnet ID that means something
IPv6 planning inverts the v4 habit: conservation is the wrong instinct - the plan optimises for legibility, aggregation, and growth. The rules that survive contact with operations: give every host segment a /64 - anything longer breaks SLAAC and other ND-dependent functions (RFC 7381's blunt guidance), so a prefix-length decision is also a feature decision; subnet on nibble (4-bit) boundaries so prefixes stay readable in hex and troubleshooting patterns align with digits; and treat the 16-bit Subnet ID as an information field, encoding location / building / VLAN (a VLAN-mapped Subnet ID - the decimal VLAN number as the last digits - makes address <-> VLAN translation instant). Plan aggregation at every layer of the hierarchy (Route aggregation and summarization) and leave headroom (roughly 2-4x) for growth and mergers. Infrastructure links differ: use /127 on inter-router point-to-point links (RFC 6164) - the v4 /31 look-alike, but the motivation is security, not conservation: a routed /64 on a p2p link is a free ND-exhaustion surface (scanning it forces the router to hold resolution state for hosts that do not exist; the feature-side defence is Destination Guard, Layer 2 security). Finally choose the space itself: provider-aggregatable (PA) prefixes are cheap but chain you to the ISP - changing providers means renumbering ACLs, DNS, ingress filters, and routing - while provider-independent (PI) space from the RIR survives provider changes and underpins multihoming (BGP in enterprise design) at the cost of RIR fees and per-ISP routing agreements. Whatever the space, build prefix indirection into the design (a named/general prefix consumed by interfaces and policy rather than literals everywhere) so renumbering becomes changing one definition, not thousands of lines.
Host addressing control - the RA flags decide, and DHCPv6 delegates
The RA's A / O / M flags are the design control knob, set per interface: A=1, O=0, M=0 -> pure SLAAC; A=1, O=1 -> SLAAC plus stateless DHCPv6 for options; M=1 -> stateful DHCPv6 for the address and options. Two operational facts follow. Setting M=1 while leaving A=1 gives hosts two GUAs (one SLAAC, one DHCPv6) - an audit surprise unless A is explicitly cleared. And the defaults have teeth: hosts ship with privacy extensions on - randomised interface IDs plus temporary addresses that rotate and are preferred as the source for new connections (RFC 6724 rule 7) - so a "simple SLAAC" network yields hosts whose addresses change routinely. Where per-host accountability is a requirement, either run stateful DHCPv6 with A=0 (a central lease record) or keep SLAAC and let the first-hop binding table be the audit trail (Layer 2 security). RA options can also carry RDNSS/DNSSL, so an RA-only network needs no DHCPv6 at all. Upstream of the LAN, DHCPv6 Prefix Delegation automates the provider -> CPE chain: the requesting router solicits, the delegating router hands down a prefix (a /56 yields 256 /64s), and the CPE re-advertises the carved /64s in its own RAs - the v6 answer to the NAT-at-the-edge branch pattern, and the reason branch addressing can follow the provider automatically.
Lifetimes and on-link - renumbering without a flag day
Every SLAAC address walks a state machine: tentative (DAD in progress - unusable until uniqueness is verified), preferred (fully usable), deprecated (existing sessions may continue but no new connections source from it), invalid. The two RA timers driving it - the Preferred and Valid Lifetimes - are the built-in renumbering machine: advertise the new prefix alongside the old, wind the old prefix's preferred lifetime down (deprecating it) while its valid lifetime lets established sessions drain, and the site renumbers without a flag day. The second v6-specific behaviour: on-link is explicit, not computed. A host builds its on-link prefix list only from RA prefixes carrying the L flag (plus redirects); a destination not on that list is off-link by default and sent to the router - even if it shares the local prefix. There is no v4-style mask-AND shortcut, so RA content - not addressing arithmetic - defines the forwarding split on the LAN.
Dual-stack day two - first-hop redundancy and the happy-eyeballs mask
The v6 gateway is the router's link-local address learned from RAs - stable across GUA renumbering - and RAs plus NUD give hosts built-in failover: a default-router list, with the dead gateway probed away. At default timers that takes ~40 seconds, and "fixing" it by advertising near-1-second RAs shifts the processing cost onto every host (painful at data-centre VM densities) while still providing no load balancing - which is why HSRPv2 / VRRPv3 / GLBP remain the design answer wherever first-hop failover must be sub-second, deterministic, and balanced (Layer 2 fault isolation and resiliency); ND-based failover is the accept-40-seconds budget option. On the application side, dual-stack hosts run happy eyeballs: connections race v6-with-a-head-start (~300 ms) against v4 and take the winner, so broken IPv6 is masked from users - it costs latency and hides failures instead of raising them. The design consequence: monitor the v6 path explicitly (synthetic per-family probes) rather than inferring health from complaints. Provider-side coexistence has its own vocabulary worth recognising in requirements: DS-Lite (customer v4 tunnelled in v6 to a provider NAT), MAP, and 6rd are the SP counterparts of the enterprise NAT64 story.
ULA and the translation question
Unique local addresses (fd00
/8 in practice) are the v6 private space with one crucial upgrade: the 40-bit global ID is pseudo-randomly generated, so two organisations' ULA plans merge without renumbering - the M&A pain of overlapping RFC 1918 space disappears. What ULA does not recreate is NAT-as-a-way-of-life: NPTv6/NAT66 are stateless, one-to-one prefix translations for address independence only (keep internal numbering while the external prefix changes), and the IETF's position is blunt - the security people attribute to NAT comes from stateful filtering, not from translation. The design decision is therefore GUA everywhere (cleanest), ULA alongside GUA for never-Internet devices, or ULA + NPTv6 where provider independence is the requirement - never "ULA because NAT feels safe." Mixing ULA and GUA also drags in source-address selection (RFC 6724): hosts choose deterministically by rule, so a mixed plan needs its selection outcomes validated, not assumed.
Recommendation / justification
Prefer dual-stack as the strategic end-state and use tunnelling/translation only as bridges dictated by node support, budget, and app readiness. Always confirm IPv4-only applications stay reachable - an IPv6 cutover that strands a critical app is a business outage, not a technical detail. Tie each phase to the Network Design lens (constraints, migration plan, rollback).
What would change this (mid-scenario twist)
- Core devices can't be upgraded -> tunnelling or NAT64 rather than end-to-end dual-stack.
- A critical app is IPv4-only -> keep translation/dual-stack at that service edge.
- SP offers IPv6 only as a value-added/translation service -> factor cost and place translation at the edge.
Design considerations / addressing
Plan the address architecture for summarisation and hierarchy from day one; minimise NAT in the IPv6 design (use NPTv6/NAT64 only for transition); run the management plane dual-stack; and validate security parity (v6 ACLs, RA-Guard, first-hop security) so IPv6 isn't a softer attack surface.
Related
- Generic routing and addressing - PBR, NAT, RIB-FIB
- Reference models and migration considerations
- Network Design
Spaced repetition
The three families of IPv4/IPv6 transition mechanisms are [...].
The three families of IPv4/IPv6 transition mechanisms are dual-stack, tunnelling, and translation (NAT64/DNS64).
In a phased IPv6 migration, which part is typically converted to dual-stack first?
The core, then the other enterprise modules gradually.
When the core can't be upgraded but IPv6-only apps must be reached across an IPv4 core, what mechanisms fit?
Tunnelling IPv6-over-IPv4 (GRE/ISATAP/6rd) or NAT64/DNS64 translation.
NAT64 typically depends on which companion mechanism, and what is its key limitation?
DNS64; translation works by name (not by IP) and doesn't support every application.
The single most important application check before an IPv6 cutover is [...].
The single most important application check before an IPv6 cutover is that IPv4-only apps remain reachable (a stranded critical app is a business outage).
Name the three IPv6 deployment models.
Dual-stack model (native v6 everywhere - the end-state), hybrid model (dual-stack where ready + tunnelling/translation bridging the rest), and service-block model (transition machinery confined to a dedicated services block, like a DMZ).
SLAAC vs DHCPv6 for host addressing - and where does the default gateway come from?
SLAAC = stateless (host builds its address from the RA prefix, no server/record); DHCPv6 = stateful (central control/logging). Either way the default gateway comes from the Router Advertisement, never DHCPv6.
The RA flag combinations map to which host-addressing methods, and what is the two-address surprise?
A=1/O=0/M=0 = SLAAC; A=1/O=1 = SLAAC + stateless DHCPv6 options; M=1 = stateful DHCPv6 - and M=1 with A still 1 leaves hosts holding two GUAs (one SLAAC, one DHCPv6) unless A is cleared.
Why do default SLAAC hosts frustrate per-host accountability, and what are the two design answers?
Privacy extensions are on by default - rotating temporary addresses are preferred as the source for new connections (RFC 6724 rule 7); either run stateful DHCPv6 with A=0 for a central lease record, or keep SLAAC and use the first-hop binding table as the audit trail.
Host segments require [...], while inter-router point-to-point links use [...].
Host segments require /64 (anything longer breaks SLAAC and ND-dependent functions), while inter-router point-to-point links use /127 - motivated by security (ND-exhaustion), not address conservation.
What belongs in a well-designed IPv6 Subnet ID?
Encoded operational meaning - location, building, VLAN (VLAN-mapped decimal digits) - on nibble boundaries, with aggregation planned per hierarchy layer and 2-4x headroom.
PA vs PI address space - the design trade?
Provider-aggregatable is cheap but renumbering follows any provider change (ACLs, DNS, filters, routing); provider-independent survives provider changes and underpins multihoming, at the cost of RIR fees and per-ISP routing agreements.
How does DHCPv6 Prefix Delegation automate branch addressing?
The requesting router (CPE) solicits, the delegating router (provider) assigns a prefix - a /56 yields 256 /64s - and the CPE re-advertises the carved /64s in its own RAs; addressing follows the provider automatically.
How does IPv6 renumber without a flag day?
Advertise the new prefix alongside the old and wind the old prefix's Preferred Lifetime down - deprecated addresses keep existing sessions alive (no new connections) while the Valid Lifetime drains them out.
How does IPv6 on-link determination differ from IPv4?
It is explicit, not computed - hosts trust only RA prefixes with the L flag (plus redirects); anything else is off-link by default and sent to the router, even with a matching local prefix. RA content, not a mask-AND, defines the forwarding split.
Why does happy eyeballs make IPv6 outages invisible, and what is the design response?
Dual-stack apps race v6 (with a ~300 ms head start) against v4 and take the winner, so broken v6 shows up as latency, not failure; monitor the v6 path with explicit per-family probes.
ULA + NPTv6 - what do they actually buy?
Pseudo-random global IDs let ULA sites merge without renumbering, and NPTv6/NAT66 give stateless address independence (internal numbering survives external prefix changes) - security comes from stateful filtering, never from translation itself.
RA-plus-NUD gateway failover takes [...]; tuning RAs to ~1 s costs [...] - so HSRPv2/VRRPv3/GLBP stay the fast-failover answer.
RA-plus-NUD gateway failover takes ~40 seconds at default timers; tuning RAs to ~1 s costs every host's CPU and still no load balancing - so HSRPv2/VRRPv3/GLBP stay the fast-failover answer.
Sources
- Rick Graziani, IPv6 Fundamentals, 2nd Ed. - address-plan doctrine (/64, nibble, /127, PA/PI), RA A/O/M flags, DHCPv6-PD, privacy extensions and RFC 6724 selection, lifetimes and on-link, ND-based FHRP limits, happy eyeballs, ULA/NPTv6.
- Cisco Press, CCDE v3 Official Cert Guide (IPv6 design & migration); RFC 5969 (6rd); NAT64/DNS64 (RFC 6146/6147).