An IPv4 Admin's First Hour with IPv6 Subnets

If you've spent a decade in IPv4, the first time you look at an IPv6 subnet you'll feel a strong urge to do something deeply wrong: try to carve it up "efficiently."

Here's the trap. After years of VLANs and squeezing every last usable host out of a /24, the instinct is burned in — address space is precious, allocate it sparingly, never waste a bit. So someone hands you a /64, which contains more addresses than the entire IPv4 internet, and your hand reaches for the subnet calculator before your brain catches up.

Stop. That is the wrong tool for this job, and the mistake you are about to make is one of the most common (and most expensive to undo) things an IPv4 network admin does when they first touch IPv6.

Why your VLSM instinct is wrong on IPv6

In IPv4, subnetting exists to conserve a scarce resource. Every /24 you waste is a /24 you cannot give to the next department, so you subnet down to the last bit, allocating the tightest prefix that fits.

IPv6 inverts that logic. A /64 from your ISP's allocation is not waste — it is the expected minimum size. And here is the detail that catches most people: the /64 is not an abstraction. For most hosts it is a hard requirement.

This comes down to SLAAC, the Stateless Address Autoconfiguration mechanism. When an IPv6 host joins a network, it does not wait for a DHCP lease the way most IPv4 hosts do. It listens for a Router Advertisement, reads the 64-bit network prefix it contains, and then builds its own address by combining that prefix with a 64-bit interface identifier (often derived from its hardware address).

The "64" in /64 is not a coincidence. An IPv6 address is 128 bits, split exactly in half: 64 bits of network, 64 bits of interface. If you assign a prefix longer than /64 (a /72, an /80, anything carved further), a host cannot run SLAAC at all — there are not enough bits left to construct its own interface identifier. Devices that depend on SLAAC will simply fail to configure, and you'll spend an afternoon diagnosing "why won't anything on this segment get a network address" before realizing you handed it a /72.

So the mental model you need is almost the exact reverse of your IPv4 habits:

IPv4	IPv6
Default subnet is /24	Default subnet is /64
Subnetting conserves a scarce resource	Subnetting rarely needs to conserve
You split to the smallest usable size	You almost never go below /64 for a segment
Host address usually comes from DHCP	Host usually builds its own (SLAAC)
Being wrong wastes addresses	Being wrong breaks connectivity

The three traps IPv4 admins catch first

Trap 1: Treating /64 as "wasteful" and subnetting below it. You cannot make a /64 into two /65s and call it more efficient — you've just broken SLAAC for every client that needs it. If you have a real need for smaller segments, those prefixes are for router-to-router links, loopbacks, and special cases, not for a normal LAN with hosts.

Trap 2: Assuming the interface portion is a meaningful "host number." In IPv4 you look at the last octet and think "host 5." In IPv6 the interface identifier is an arbitrary 64-bit value, often randomized for privacy (which is why a device's address can change after a reboot). You cannot plan around stable, sequential host numbers the way you did with IPv4.

Trap 3: Trying to "save addresses" the way you saved a /24. You are not conserving anything. If your ISP gives you a single /64 and you need multiple networks, the real fix is a renumbering plan or a larger allocation from your provider — not cramming multiple LANs into one /64 and calling it subnetting.

What a correct IPv6 plan actually looks like

Here is the shape of an IPv6 deployment that doesn't blow up on you:

• Your ISP allocates a /48 or /56 — the "normal size" block, big enough to be boring.
• You split that into one /64 per VLAN, exactly the way you'd give each VLAN its own /24 in IPv4.
• Each segment gets a clean, memorable prefix from your allocation (for example 2001:db8:1::/64 for the office LAN, 2001:db8:2::/64 for the server segment).
• You let SLAAC handle host addressing. Servers that need DHCPv6 can get static or DHCP-assigned addresses, but the subnet boundary stays /64.

The rule of thumb that makes this click: in IPv6, /64 is your /24. It is the default, the boring, the correct choice. When someone asks "what prefix should I use for this segment," the overwhelming answer is /64 — and the interesting part of your job is deciding which /64, not how small it can be.

Check your work with a calculator

The math slips fast when you're new — you transpose a /64 and a /56, or you're not sure whether 2001:db8:1::/64 includes the range you think it does. I built an IPv6 subnet calculator that takes an IPv6 address and prefix and returns the network address, first and last usable addresses, and the total /64 count — handy for verifying a segment against your plan.

For the full mental shift — why the /64 is required, the SLAAC rule, and a worked example — I wrote it up in IPv6 Subnetting for IPv4 Network Admins. It's the page I wish I'd had the first time I planned an IPv6 office.

The one-sentence version: stop trying to be efficient with IPv6. The address space is not the thing you're fighting; clean routing is. Embrace the /64, assign one per segment, let SLAAC do the rest, and your first hour with IPv6 subnets goes from a pile of confusion to a boring, correct default.