CIDR/Subnet Calculator
Calculates IPv6 boundaries, address counts, and a capped preview of child prefixes before they are allocated.
NetworkIPv6 Subnet Planning That Scales
Good IPv6 plans spend bits to preserve meaning, aggregation, and room for change. The scarce resource is no longer host addresses; it is a clean hierarchy that operators can understand years after the allocation spreadsheet was created.
Keep the /64 invariant on ordinary links
For normal LANs, VLANs, and wireless segments, assign a /64. That leaves 64 bits for the interface identifier and matches the architecture assumed by Stateless Address Autoconfiguration, Neighbor Discovery, privacy addresses, and a large body of host software. A /80 may look attractively tidy when copied from IPv4 variable-length subnetting, but it buys nothing operational and can quietly break mechanisms that expect a 64-bit interface-ID field. A /56 on one VLAN is wasteful in the other direction: it hides 256 normal link prefixes behind a single broadcast domain.
There are narrow exceptions. Point-to-point router links are sometimes numbered with /127, and loopbacks commonly use /128; both are conscious infrastructure conventions, not templates for user networks. Some providers delegate only one /64 to a customer, which makes proper downstream subnetting impossible. Do not “solve” that by stretching one prefix across several Layer-2 domains or introducing IPv6 NAT as the first design. Ask for a routed delegation large enough to subnet. A residential or small-site /56 supplies 256 /64s; a /48 supplies 65,536.
Start with the delegation, then budget levels
Write down the prefix you actually control and whether it is provider-aggregatable, portable, or temporary. Suppose the organization receives 2001:db8:1200::/40. The next eight bits can identify 256 sites as /48s; each site then has 16 bits for 65,536 /64 links. That is a clean two-level hierarchy: the backbone summarizes the organization, regional routing can summarize a site, and access networks receive the standard link size. The CIDR/Subnet Calculator can verify boundaries and preview a capped set of child prefixes before the plan reaches router configuration.
Do the capacity arithmetic in bits rather than in remembered examples. Moving from /40 to /48 consumes eight bits and creates 256 equal blocks. Moving from /48 to /56 creates 256 blocks per site. The remaining eight bits reach /64 and create 256 LANs per /56. Allocate enough bits at each tier for the plausible lifetime of the design, then leave some values unassigned between regions. Empty space is not waste: it lets a site grow without receiving a second, discontiguous route that destroys summarization.
Nibble boundaries make the plan legible
One hexadecimal digit represents four bits. Prefix lengths divisible by four — /32, /36, /40, /44, /48, /52, /56, /60, and /64 — therefore align with visible hex boundaries. At those lengths, an operator can read the significant digits directly without converting partial nibbles to binary. This is not a protocol requirement; prefixes such as /51 are valid. It is an operational preference that pays back during routing incidents, firewall reviews, reverse-DNS delegation, and hand-written change plans.
Use that legibility to encode hierarchy, not trivia. In a site /48, the fourth hextet contains the 16-bit subnet ID. You might reserve the first nibble for zone, the second for function, and the remaining two for segment number, yielding readable /64s such as 2001:db8:1201:2307::/64. Keep the codebook small. Encoding building, floor, rack, tenant, environment, security class, and VLAN number into four hex digits produces an address that looks meaningful but becomes false as soon as anything moves.
Design sites and VLANs for aggregation
A scalable hierarchy follows routing boundaries. Give a site or independently routed campus one contiguous block, then carve regional, service, or security zones beneath it. If a location needs at most 60 VLANs today, assigning a /56 still leaves 256 /64s and clean growth. For a large campus, a /48 may be appropriate even if most of it remains empty. What matters is that upstream routers advertise one site summary instead of hundreds of access prefixes, and that a failure or policy change can be contained at the boundary represented in the address plan.
Avoid deriving the IPv6 subnet ID mechanically from the existing decimal VLAN ID unless that convention genuinely helps operators. VLAN 120 encoded as hexadecimal 0078, decimal-looking 0120, or some zone-plus-VLAN scheme are three different policies; all work until teams assume different ones. Choose once, document examples, and validate automation against the documented representation. Also reserve explicit ranges for infrastructure, transit, user, voice, wireless, lab, and future use. Reservations prevent the first available-prefix allocator from scattering related networks across the entire site block.
Stop importing IPv4 scarcity habits
IPv4 planning rewards tight packing because addresses are scarce and NAT makes overlapping private space appear tolerable. IPv6 reverses those incentives. Subnet size is normally fixed at /64, while abundance exists in the number of subnets. There is no prize for placing a printer LAN in a /120 or counting “usable hosts”; IPv6 has no broadcast address, and the address count of a /64 is not a capacity target. Capacity is bounded by the Layer-2 design, Neighbor Discovery behavior, switch tables, security policy, and operational sanity long before interface identifiers run out.
Equally, do not recreate NAT as an addressing strategy. Stable internal prefixes, clear routing, host firewalls, and stateful perimeter filtering provide separation without hiding topology behind address translation. Provider-assigned space does raise a renumbering question, so isolate prefix values in configuration management, DNS, and policy objects rather than copying literals everywhere. Where multihoming or provider independence justifies portable space, account for the routing responsibility it creates. Address abundance removes one constraint; it does not remove route hygiene, ingress filtering, or ownership.
Documentation is part of the allocation
An allocation is incomplete until its intent is recorded. For every block, retain the canonical prefix, purpose, parent, site, routing owner, security zone, lifecycle state, allocation date, source delegation, and contact. For every /64, add the VLAN or link identifier, gateway convention, address-assignment method, DHCPv6 or router-advertisement policy, and DNS responsibility. Record reservations as real objects rather than blank spreadsheet rows. Blank space looks available to automation; a named reserve has an owner and a reason.
Make the IP address management system authoritative and generate router, firewall, DNS, and monitoring inputs where practical. Changes should reject overlaps, children outside their parent, non-/64 user links, and allocations that cross a reserved boundary. Validate the deployed prefix from an external path where relevant; the What is my IP? page can show which family and address one request actually used, while the DNSSEC Validator reports DNSSEC chain evidence when reverse or service DNS is signed. Neither replaces IPAM. The durable plan is the one whose records, routes, and documentation continue to agree after the original designer leaves.