Calculating an IPv6 subnet mask is the act of applying a prefix length from /0 to /128 to a 128-bit IPv6 address and reading back the network prefix, the numeric first and last addresses, the number of host bits, and the total address count. Because an IPv6 address contains eight 16-bit hexadecimal fields, a subnet mask is expressed as a slash-prefix count rather than the dotted-decimal mask used in IPv4. A /64 prefix leaves 64 host bits, a /48 prefix leaves 80 host bits, and the maximum /0 covers the entire 128-bit address space. The arithmetic must use an unsigned integer wide enough to hold 128 bits, because a /0 range contains 2^128 addresses and ordinary JavaScript numbers lose precision past 53 bits. The IPv6 Subnet Calculator handles this with browser-native BigInt arithmetic, applies RFC 5952 canonical formatting, and returns a verifiable set of values: the canonical text of the input, the network prefix, the first and last numeric address, the host-bit count, and the exact range size.
IPv6 Subnetting Versus IPv4 Subnetting
The mental model from IPv4 does not transfer cleanly to IPv6. Three differences shape how a subnet calculation works.
First, the address is 128 bits, not 32. A /24 in IPv4 leaves 8 host bits and produces a 256-address block; a /64 in IPv6 leaves 64 host bits and produces a block whose count is 2^64. The numbers are larger by a factor that is not useful to memorise, but the prefix-length formula is the same. Clearing the host bits produces the network address; setting the host bits produces the numeric upper bound.
Second, IPv6 has no broadcast address. The numeric upper bound shown for a prefix is purely the largest address inside the range; it is not a destination that all hosts listen on, and it is not a separate operational role. The tool labels the value as the last numeric address for exactly this reason, and the underlying RFC text treats it as a numeric bound rather than a special address class.
Third, the standard end-site allocation in IPv6 is /64, not the variable host-bit counts that IPv4 uses. The /64 boundary was chosen so that stateless address autoconfiguration and the standard 64-bit interface identifier fit cleanly. Practical subnetting in IPv6 is usually about choosing a prefix shorter than /64 for an upstream block and keeping /64 at the LAN edge. Readers comparing address formats across the two protocols can review a parallel walkthrough in the IPv4-to-IPv6 conversion guide.
A consequence of the larger address space is precision. A 53-bit double can represent integers up to about 9 × 10^15 exactly, but a /0 prefix contains 2^128 values, which is far larger. The IPv6 Subnet Calculator performs all bit operations with browser BigInt arithmetic so /0 does not silently round, and a /128 correctly produces a count of exactly one. The same precision guarantee holds for any prefix in between, which is why a manual calculation in a spreadsheet is not a safe substitute.
Calculate an IPv6 Subnet From a Prefix Length
To get an auditable subnet calculation, paste the address and prefix into the IPv6 Subnet Calculator and read the result back field by field.
- Enter the IPv6 address using either the fully expanded form with eight hexadecimal fields or the one-double-colon compressed form defined by RFC 4291. Strip any brackets, zone identifier, or port suffix; those forms are not pure IPv6 text and will be rejected with a clear error.
- Enter the prefix length as an integer from 0 to 128. A /64 is the standard LAN prefix, a /48 is a common site allocation, and the two endpoints of the field are exactly the limits of the range. Anything outside 0 to 128 is not a valid IPv6 prefix.
- Select Calculate subnet. The page parses the text, expands one optional :: run into eight fields, combines the fields into a single 128-bit integer, and applies the mask.
- Review the output: the canonical input (RFC 5952 text), the network prefix, the first and last numeric address, the number of host bits, and the exact count of addresses. Compare the canonical form against your source address character by character before relying on it.
- If the result will drive a configuration change, re-verify it in the platform's supported tooling and keep the prior configuration available for rollback. A numeric prefix calculation is not a network-design recommendation.
The calculator runs the same operations locally in your browser. No address leaves the device, no WHOIS or DNS query is sent, and the page can be used with RFC 3849 documentation prefixes for private planning and documentation examples.
Worked Example Using the RFC Reference Address
The canonical example for IPv6 prefix arithmetic is the address given in RFC 4291: 2001:0DB8:0:CD30:123:4567:89AB:CDEF. With a /60 prefix, the calculation proceeds as follows.
The prefix occupies the first 60 of 128 bits, leaving 68 host bits. The network address is the input value with those 68 host bits cleared, which produces 2001:db8:0:cd30::/60 in canonical form. The last numeric address is the network value with all 68 host bits set, giving 2001:db8:0:cd3f:ffff:ffff:ffff:ffff. The exact range size is 2 to the power of 68, or 2^68 numeric addresses in the block. The host-bit count is reported explicitly as 68 so the size can be re-derived by hand.
Every step of this can be repeated on the IPv6 Subnet Calculator by pasting the same address and /60 and comparing the canonical output against the figures shown above. If the tool returns a different canonical form, the input was not the RFC example as written, and the difference should be investigated before reuse.
Common IPv6 Prefix Lengths and Their Allocation Purpose
Prefix lengths in IPv6 are not assigned ad hoc; they follow a layered allocation model from IANA down to end sites. The table below lists the prefix lengths a network engineer is most likely to encounter, the typical allocation they represent, the host-bit width that determines the address count, and the count itself expressed as a power of two.
| Prefix length | Typical allocation purpose | Host bits | Address count |
|---|---|---|---|
| /128 | Single host or loopback | 0 | 1 |
| /64 | Standard LAN segment, SLAAC boundary | 64 | 2^64 |
| /56 | Small site or residential allocation | 72 | 2^72 |
| /48 | Standard site allocation | 80 | 2^80 |
| /32 | ISP allocation block | 96 | 2^96 |
| /16 | Large registry block | 112 | 2^112 |
| /0 | Entire IPv6 address space | 128 | 2^128 |
The exact decimal address count for any prefix shorter than /75 should be obtained from the IPv6 Subnet Calculator rather than expanded by hand, because ordinary spreadsheet arithmetic loses precision past 2^53 and will silently round the result.
RFC 5952 Canonical Output and Why It Matters
RFC 5952 defines a single recommended way to write an IPv6 address as text. The rules are: hexadecimal letters are lowercase, leading zeroes inside a field are omitted, the longest run of two or more all-zero fields is compressed to ::, and the first such run wins when two runs tie. A single zero field is never compressed. The tool follows these rules exactly, which means the canonical text it returns is the form most platforms will display, accept in configuration, and emit in logs.
Canonicalisation also lets you check your input. If you paste 2001:db8::1 with a /64 prefix and the tool reports the canonical input as 2001:db8::1, the parser correctly recognised both the compressed form and the leading-zero-suppression rule. If the canonical form differs from what you intended, the input was ambiguous and the canonical version is the safe one to use in configuration files and documentation.
What an IPv6 Subnet Calculator Does Not Decide
A prefix calculation answers one question and one question only: given a 128-bit address and a slash-prefix, what is the numeric range. RFC 5942 is explicit that an address assignment and an on-link prefix are separate concepts; a numeric match inside a block does not mean a host can reach the address without a router, and the prefix that defines the route is not the prefix that defines the configuration.
The tool deliberately does not determine whether a prefix is on-link, routable, globally assigned, reserved, multicast, or anycast. It does not consult WHOIS, DNS, BGP, geolocation, or the local network interface. The result is suitable for documentation examples, RFC 3849 documentation prefixes, and private planning, but it cannot confirm ownership, policy, or reachability.
Two further limits matter in practice. Zone identifiers such as %eth0 and IPv4-embedded forms like ::ffff:192.0.2.1 are rejected with a clear error. Those forms require additional context (an interface or a mixed-address mode) that a pure numeric calculation cannot resolve. If you need to reason about a link-local or IPv4-mapped address, strip the suffix and calculate the numeric part separately, then reason about the zone or the embedding in the layer above the calculator.
Before applying a calculated range to a production change, independently verify it in the network platform's supported tooling, keep the current configuration for rollback, and consult the authoritative network design rather than the numeric match alone. Routers, prefix information options, allocation policy, provider rules, firewall configuration, and address-management plans are the inputs that determine operational behaviour, and none of them are inputs the calculator can see.