IPv6 Migration: How to Design Dual Stack VLANs Step by Step

Most IPv6 migration plans are written as if the network were one object. In practice, IPv6 arrives one VLAN at a time: a guest network here, a server segment there, a management VLAN that the security team wants off IPv4 entirely. Each of those segments forces the same small set of decisions, which prefix it gets, how hosts on it learn addresses, and which firewall rules apply to the new family. A migration plan that answers those questions per VLAN, in advance, is the difference between a rollout that takes a maintenance window per segment and a project that stalls for a year.

This article walks through that plan step by step. The model is dual stack, running IPv4 and IPv6 side by side on the same VLAN, which remains the recommended migration strategy because nothing has to be cut over and anything that fails can be turned back off without touching the IPv4 side. The work is in the design decisions you make before the first router advertisement goes out, and in the discipline of keeping the two address families documented as one network rather than two.

Why the VLAN Is the Right Migration Unit

The VLAN is the smallest segment where every piece of the IPv6 story comes together: addressing, autoconfiguration, gateway behavior, and security policy. Splitting the migration finer than that, per host or per switch port, produces change noise without reducing risk. Going coarser, whole sites at once, concentrates so much change into a single window that verification becomes impossible and rollback means undoing everything.

Dual stack also changes what a mistake costs. Because IPv4 keeps running on every segment throughout the migration, the failure mode of a bad IPv6 rollout is almost never an outage, it is silence: hosts hold addresses that cannot reach anything, or traffic flows over IPv6 with nobody watching it. That makes a per VLAN scope essential. When the scope is one segment, you can verify a real client flow end to end before declaring it done, and the rollback procedure is small enough to actually execute under pressure.

Finally, VLANs are how your team already thinks. Change windows, firewall policy groups, and access controls are usually expressed per segment already, so anchoring the IPv6 plan to the same unit means the migration inherits your existing operational structure instead of demanding a parallel one.

The Dual Stack VLAN Model: One Segment, Two Prefixes

The core model is simple and worth being explicit about: after the migration, every VLAN carries two subnets, one IPv4 and one IPv6, on the same broadcast domain, with the same gateway doing routing for both. The pairing is the object you plan, document, advertise, and filter. If the IPv4 side and the IPv6 side of a segment are tracked separately, they drift, and drifted dual stack records are worse than none because people trust them.

Two details in that model deserve attention. First, the host carrying VLANs does not change at all: same trunk, same VLAN IDs, same switch configuration. Dual stack adds a logical subnet to an existing segment, it does not create a second segment. Second, point to point links are the exception to the one /64 per VLAN rule. Transit links between routers get /127s from a reserved range of your subnet ID space, following the same logic as /31s in IPv4 and protecting the link from neighbor cache exhaustion.

Step 1: Inventory and Classify Your VLANs

Before allocating anything, walk every VLAN that exists and write down what it is for. The classification that matters for IPv6 is not the VLAN ID, it is what the segment connects and how its hosts learn addresses. For each VLAN, record its function (users, servers, infrastructure, guest, IoT, management), its current IPv4 subnet, its gateway, and any devices on it that you know cannot do IPv6.

That last point is where most of the risk hides. Printers, badge readers, industrial controllers, and aging appliances may never speak IPv6, and dual stack accommodates them fine as long as you know they are there, because they simply continue on IPv4. The dangerous category is different: devices that support IPv6 but behave badly with it, such as hosts that prefer a broken IPv6 path or middleboxes that only inspect one family. Your pilot VLAN choice should come directly from this inventory, and it should be a segment with tolerant users, well understood devices, and no compliance obligations.

The inventory also tells you which VLANs should never get global IPv6 space at all. Management segments, backup networks, and replication VLANs are often better served by ULA prefixes that cannot be routed from the internet, and the migration is the cheapest moment to make that decision because nothing exists to renumber yet.

Step 2: Allocate IPv6 Prefixes per VLAN

With a /48 per site you have 65,536 /64s to distribute, so the design question is not supply, it is structure. Divide the 16 bit subnet ID space into ranges by function and hold those ranges sacred: one range for infrastructure, one for servers, one for user segments, one for guest and IoT, and a large reserved block you never touch until the plan survives its first year. Hierarchical allocation is what keeps routing tables summarizable and documentation readable; a subnet ID scheme that grows by whoever asked next produces a flat mess of prefixes no one can aggregate.

One convention pays for itself repeatedly: make the subnet ID echo the VLAN ID wherever the range allows. When VLAN 512 lives at 2001:db8:aa:5512::/64, the prefix announces its own segment, and troubleshooting stops requiring a lookup table. For VLAN IDs too large or awkward to embed, document the mapping explicitly rather than letting each allocation become a special case. Point to point links draw /127s from the infrastructure range, and loopbacks take /128s, so the reserved ranges in your plan should account for links, not just LANs.

Step 3: Choose SLAAC, DHCPv6, or Both per Segment

Address autoconfiguration is a per VLAN decision, and unlike IPv4, DHCP is not the automatic default. Router advertisements with SLAAC handle addressing, gateway, and DNS for most hosts, while DHCPv6 exists for segments where you need central assignment, logging, or options the RA cannot carry. Decide per VLAN based on what connects to it, and record the decision alongside the prefix, because the RA flags and the DHCPv6 server configuration have to agree with it.

A note on the middle row, because it trips up teams coming from IPv4: stateful DHCPv6 does not provide a default gateway. Router advertisements are required in every mode, so the question is never whether to run RAs, only what the RA advertises and which flags it sets. The managed flag (M) tells hosts to request addresses from DHCPv6, and the other config flag (O) tells them to fetch additional options from it while keeping SLAAC addresses. Whichever combination you choose per segment, test it with a real client from that segment, because operating system behavior varies more around DHCPv6 than around anything else in the migration.

Step 4: Gateways, Router Advertisements, DNS, and Firewall Policy

Each dual stack VLAN needs its gateway configured for both families on the same routed interface, an RA policy matching the addressing mode you chose, and DNS that works over both. On the DNS side, add AAAA records for internal services as their VLANs come online, and confirm your recursive resolvers are reachable over IPv6 themselves, because a resolver that only answers over IPv4 quietly pushes traffic back to the old family and masks problems from your verification.

Security policy is where dual stack migrations most often fail, and the reason is structural: in IPv4, NAT provided an accidental boundary that many networks relied on without designing it. IPv6 has no such backstop, every host on a global prefix is directly addressable, and the boundary must now exist explicitly in your firewall and ACL policy. Filter both families symmetrically on every segment, including the pilot, and audit for IPv4 only rules as you go, because an IPv6 side with no policy is not a lesser version of the network, it is an unfiltered one. Segments you designated for ULA in step 1 get the same treatment; ULA limits reachability from the internet, but it is not a substitute for filtering between internal zones.

Step 5: Roll Out and Verify VLAN by VLAN

The rollout is now mechanical, which is the point of the design work. One VLAN per maintenance window, in an order that starts with your pilot and ends with segments that would hurt if they misbehaved. Infrastructure and transit links can go first since the only traffic on them is your own, guest or lab VLANs make good early client segments, and production user and server segments come after the pattern is proven.

Verification deserves its own checklist rather than a glance at the dashboard. From a real client in the segment, confirm the host received an address through the mechanism you intended, resolve a service by name over AAAA, and run an actual flow to an IPv6 destination outside your network, then check that the return path and the firewall logs both show it. Happy Eyeballs on modern clients will mask a broken IPv6 side by falling back to IPv4, so verify the IPv6 path specifically instead of trusting that things seem fine. When a segment passes, record it and move on; when one fails, the rollback is withdrawing the RA, and the segment returns to IPv4-only without ceremony.

Keeping the Plan Accurate After the Rollout

Dual stack quietly doubles the number of address objects your team maintains, and the two families will drift if they are tracked in separate places. The pairing from step 2 is the discipline: every VLAN stays one logical record with an IPv4 side and an IPv6 side, and any change to one side is an opportunity to verify the other. Schedule a periodic reconciliation against the live network that catches prefixes allocated but never advertised, RAs that no longer match the documented addressing mode, and segments where the two families disagree about their purpose.

For teams that already run a registry for VLANs and addressing, the migration is the moment to make sure both families live in it together. Obelinf manages IPv4 and IPv6 in the same hierarchy, with shared VLAN and subnet associations so each dual stack segment is one entity rather than two parallel records, and IP address management that flags overlapping or out of range allocations before they reach a router. Because every allocation is recorded with an audit trail, the question “when did this VLAN start advertising IPv6” has an answer when a postmortem needs one.

The migration ends the way it started, one VLAN at a time. Teams that treated the VLAN as the unit of planning get a network where each segment’s dual stack state is known, documented, and reversible, which is exactly the position you want to be in when IPv6 stops being a project and becomes just how the network works.