An IPv6 prefix is the leftmost portion of a 128-bit address that identifies the network portion of the value, written as address/prefix-length in CIDR notation. With a /60 prefix, the first 60 bits define the network and the remaining 68 bits are available for host addressing inside that range. The prefix is computed by taking the IPv6 address as a single 128-bit integer, applying a bitmask that keeps the network bits and clears every host bit, and then formatting the result in RFC 5952 canonical text. You can find the IPv6 prefix of any address using a local browser calculator: paste the address in expanded form or in one-double-colon compressed form, enter a prefix length from 0 to 128, and the tool returns the network prefix, the canonical input, the numeric first and last addresses, the host-bit count, and the exact number of addresses in the range. For the reference value 2001:0DB8:0:CD30:123:4567:89AB:CDEF with prefix 60, the network is 2001:db8:0:cd30::/60 and the numeric upper bound is 2001:db8:0:cd3f:ffff:ffff:ffff:ffff.
What an IPv6 prefix actually represents
An IPv6 address is a 128-bit value rendered as eight colon-separated 16-bit hexadecimal fields, per the addressing architecture in RFC 4291. A prefix splits that value into a network portion and a host portion using a length measured in bits. A /64, the most common boundary in production networks, dedicates the first 64 bits to the network and the last 64 bits to the host interface identifier. A /128 contains exactly one address and is used to label a single host. A /0 covers the entire 128-bit address space and contains every possible value. The number of host bits is always 128 minus the prefix length, so a /60 leaves 68 host bits, a /56 leaves 72, and a /48 leaves 80. The address count of a prefix is two raised to the number of host bits, so a /64 contains 2⁶⁴ numeric values and a /128 contains one.
Because the bits are not aligned to the 16-bit field boundaries in every case, the prefix may slice through a field. With the RFC example, the first 60 bits include the first three full fields (48 bits) plus the leading 12 bits of the fourth field. The remaining 4 bits inside that fourth field, plus all of fields five through eight, belong to the host portion and are cleared to zero for the network address and set to one for the numeric upper bound.
How IPv6 prefixes are written in CIDR notation
CIDR notation writes a prefix as the address, a forward slash, and the prefix length in bits, such as 2001:db8::/32 or fe80::1/64. RFC 4291 permits leading zeroes inside any field to be suppressed and allows one run of two or more consecutive zero fields to be replaced by ::. RFC 5952 tightens the output: hexadecimal letters are lowercase, leading zeroes are removed inside every field, the longest run of two or more all-zero fields is compressed, and the first such run wins when two runs tie in length. A single zero field is never compressed to ::. The calculator applies those rules so the output is a stable canonical string regardless of how the input was typed.
The accepted input forms are limited on purpose. The parser accepts pure IPv6 hexadecimal text in fully expanded form or with one :: run. It deliberately rejects zone identifiers such as %eth0 and IPv4-embedded dotted-decimal forms such as ::ffff:192.0.2.1, because those syntaxes require additional interface or mixed-address context and would otherwise be partially interpreted. Bracketed forms like [2001:db8::1] and port suffixes are not recommended as input. Pasting the address without brackets, a port, or a suffix keeps the calculation clean and predictable.
| Prefix length | Host bits | Address count | Typical use |
|---|---|---|---|
| /0 | 128 | 2¹²⁸ | Full address space reference |
| /48 | 80 | 2⁸⁰ | Site allocation, common ISP boundary |
| /56 | 72 | 2⁷² | Subscriber delegation prefix |
| /60 | 68 | 2⁶⁸ | Sub-prefix within a /56 |
| /64 | 64 | 2⁶⁴ | Standard LAN or SLAAC segment |
| /128 | 0 | 1 | Single host loopback or static label |
Finding the prefix in three steps
- Open the IPv6 Subnet Calculator and enter a pure IPv6 address in either fully expanded form (2001:0db8:cd30:0000:0000:0000:0000:0001) or one-double-colon compressed form (2001:db8:cd30::1). Leave any zone identifier, port suffix, or bracket off the input.
- Enter an integer prefix length from 0 through 128 and select the calculate action. Values outside that range are rejected because a prefix shorter than 0 or longer than 128 is not defined for a 128-bit address space.
- Review the canonical input, the network prefix, the numeric first and last addresses, the host-bit count, and the exact address count before using the result in documentation or configuration. Compare the canonical address with the source to confirm no fields were lost or reinterpreted.
Reading the canonical output
The first line of the result is the canonical form of the input, restated according to RFC 5952 rules. This is the form you should paste into configuration and documentation because it is stable and reproducible. The second line is the network prefix: the input address with every host bit cleared and rewritten in canonical text. The third and fourth lines are the numeric first and last addresses, in that order. The first address equals the network itself, and the last address equals the network with every host bit set. The fifth value is the number of host bits (128 minus the prefix length), and the final value is the exact address count (2 to the power of the host bits). For a /128 prefix, the address count is exactly one. For a /0 prefix, the address count covers the full 128-bit space and the entire range fits in browser BigInt arithmetic without floating-point loss.
The terms first and last describe numeric bounds only. IPv6 does not define an IPv4-style broadcast address, and the last value is never labeled broadcast. Treating it as such is a common conceptual carryover from IPv4 planning that does not apply to IPv6 forwarding or host configuration.
A worked example with the RFC reference address
The reference value from RFC 4291 is 2001:0DB8:0:CD30:123:4567:89AB:CDEF. With prefix 60, the tool returns:
- Canonical input: 2001:db8:cd30:123:4567:89ab:cdef
- Network prefix: 2001:db8:0:cd30::/60
- First numeric address: 2001:db8:0:cd30::
- Last numeric address: 2001:db8:0:cd3f:ffff:ffff:ffff:ffff
- Host bits: 68
- Address count: 2⁶⁸
The math follows the standard rule. The first 60 bits define the network. Bits 1 through 48 cover fields 1, 2, and 3 unchanged (2001, 0db8, 0000). Bits 49 through 60 are the leading 12 bits of field 4 (110011010011 in the original CD30), so the leading 12 bits of the network field 4 are 1100 1101 0011 and the trailing 4 bits are cleared to zero, giving 1100 1101 0011 0000 in binary, which is 0xcd30. The last numeric address sets every host bit to one, which flips the trailing 4 bits of field 4 from 0000 to 1111 (0xcd3f) and sets fields 5 through 8 to ffff each. The same range calculation works for any prefix length; the field boundaries simply shift based on the chosen length.
What a prefix calculation does not tell you
The numeric prefix is a containment result, not a network configuration recommendation. RFC 5942 makes the distinction explicit: an address assignment and an on-link prefix are separate concepts. Routers, prefix information options, allocation policy, provider rules, firewall configuration, and address-management plans all determine operational behavior. The calculator does not decide whether a prefix is on-link, routable, globally assigned, reserved, multicast, or anycast. It does not determine whether a /64 is appropriate for SLAAC, whether a /128 is suitable for a loopback, or whether a documentation prefix from RFC 3849 should be filtered at the edge. Those decisions live in network design, not in bit arithmetic.
No address is transmitted or looked up. The page does not query WHOIS, DNS, BGP, geolocation, abuse feeds, or an interface on the device. That makes the tool suitable for documentation examples and private planning, including documentation prefixes, but it cannot confirm ownership, reachability, or routing intent. Treat the output as a clean numeric range and use a separate authoritative source for any operational conclusion.
Verification checklist before applying the result
For reliable use in production work, paste the address without brackets, a port, or a suffix, and enter the prefix separately. After the calculation, compare the canonical address with the source: any difference means the input had a field that the parser interpreted differently than you wrote. Review the network line and confirm it ends in the expected zero-run compression. Review the last-address line and confirm its suffix matches the expected boundary at the chosen prefix length. If a production change depends on the result, independently verify it in the network platform's supported tooling, preserve the current configuration for rollback, and document the canonical strings alongside the original input so an audit trail exists. Readers who want the explicit subnet mask that corresponds to a prefix length can follow the related walkthrough on how to calculate an IPv6 subnet mask step by step, which covers the same calculator from the mask perspective.