An IPv6 prefix is the network part of an address, and the number after the slash says how many of its 128 bits that part takes. A /48 holds 65,536 /64 subnets and a /56 holds 256, and any number type gets those two counts right. Holding the address is the part that fails. We put 2001:db8:abcd:12::1 through a double-precision number, the type JavaScript uses, and it came back as 2001:db8:abcd::, with the subnet and the host both gone. As for who sets the size of a customer's block, both APNIC and RIPE call it a local decision for the ISP.
The old /48 recommendation lapsed and no size replaced it
RFC 3177 argued that end sites should get a /48 in most cases. RFC 6177 replaced it in March 2011 and says of the size: "This document does not make a formal recommendation on what the exact assignment size should be." It still recommends "giving home sites significantly more than a single /64", and adds that "anything of length /64 or shorter works from a standards perspective". A lone /64 therefore works, and falls below that recommendation.
APNIC-127, dated 20 February 2025, and RIPE-738 both say the size "is a local decision for the LIR or ISP to make"; an LIR is a local internet registry. ARIN's policy manual carries no such sentence. RIPE-690, a 2017 operational guide and not policy, offers a /48 for each end-user, or a /48 for business and a /56 for residential, and says "Assigning prefixes longer than /56 is strongly discouraged".
Both policies also use /56 to measure how full a block is; RIPE-738 calls it "the efficiency measurement unit". That is bookkeeping, and recommends nothing to a customer. We found no first-party page giving a prefix size for any ISP in Singapore, Malaysia, Hong Kong or Taiwan, and we opened no dataset on how often each size is used. Aussie Broadband does publish its own: its help page, last updated 27 February 2024, describes a delegated /48.
Ethernet autoconfiguration fails on every prefix length but /64
With SLAAC, a device builds its own address from the prefix its router advertises. RFC 4862 says that if the prefix length and the interface identifier do not sum to 128 bits, the option "MUST be ignored". RFC 2464 says a prefix used this way on Ethernet "must have a length of 64 bits". So a /56 advertised on an Ethernet link is ignored just as a /72 is. A larger block reaches the customer's router through prefix delegation, a separate handover, and the router cuts it into /64s.
RFC 7421, an Informational document from January 2015, says the /64 boundary arrived after the first design, "following a period when it was expected to be at /80". It describes a subnet prefix longer than 64 bits as "outside the current IPv6 specifications, so results may vary". The one named exception is RFC 6164, which defines 127-bit prefixes for links between routers.
A /56 breaks a hex group in the middle
An address is written as eight groups of four hex digits, and each digit is four bits, which networkers call a nibble. RIPE-690 says "The length of a delegated prefix should therefore always be a multiple of 4", and /56 meets that. It stops halfway through a group instead. In RIPE-690's own example, 2001:db8:aaaa:1a00::/56, the customer owns the last two digits of the fourth group, so its 256 /64s run from 1a00 to 1aff, and advanced customers are "unable to use all 4 digits between the double colons".
| Prefix | /64 subnets inside | Digits owned in the fourth group | Ends on a group edge |
|---|---|---|---|
| /48 | 65,536 | 4 | Yes |
| /52 | 4,096 | 3 | No |
| /56 | 256 | 2 | No |
| /60 | 16 | 1 | No |
| /64 | 1 | 0 | Yes |
The count is 2 raised to 64 minus the prefix length.
Double-precision numbers fail past /55
JavaScript's Number type is defined in the language specification as IEEE 754-2019 binary64, and in our runs it kept 53 significant bits. An address in 2000::/3, the global unicast block, has its first set bit in position 3, so those bits run out at position 55. Across 20,000 random bases inside the block, neighbouring subnets stayed distinct to /55 every time and no further. RIPE-690's residential size sits one bit past that line, though a /56 does not vanish entirely.
| Prefix | Distinct values among 256 consecutive subnets from 2001:db8:abcd:1200:: |
|---|---|
| /55 | 256 |
| /56 | 128 |
| /60 | 9 |
| /64 | 1 |
In a double, the last address of 2001:db8:abcd::/48 rounds up to 2001:db8:abce::, the first address of the next /48. Subnet counts stay safe, because every power of two up to 2^128 is exact in a double; only the printed digits go, with 2^64 showing as 18446744073709552000 in JavaScript. Microsoft publishes a limit of 15 digits for Excel, and 2^64 has 20. We did not run this in Excel.
Our IPv6 subnet calculator works in BigInt, JavaScript's whole-number type. Enter 2001:db8:abcd:12::1 with prefix 56 and it gives the network 2001:db8:abcd::/56, 256 /64 subnets and the next block at 2001:db8:abcd:100::. Until 1 November 2026 it showed only a power of two and ≈10^21 for that block, a floor under the true 4.72 × 10²¹, gave no /64 count, and accepted an address missing its last group by reading the gap as zero.
Bad bit shifts survive a spot check at 65,536
A bit shift is the quick way to write a power of two, so a programmer might count a block's addresses with 1 << (128 - p). JavaScript takes the shift count modulo 32, so at /48 this returns 65,536 and at /56 it returns 256. Those are the /64 counts, the right answer to a different question, and the match holds for all 31 prefixes from /34 to /64. Anyone checking the result against a familiar figure would pass it.
Outside that range, the expression returns 1 at /32 and /96, goes negative at /1, /33, /65 and /97, and produces other incorrect powers of two elsewhere. We wrote it as a test case and did not find it in any tool. On our arm64 Mac, shifting 1 left by 64 gave 1 in JavaScript and bash, 0 in PHP, Perl and SQLite, and the exact value in Python and Ruby.
Global supply holds out with about 1.6% allocated so far
On our arithmetic from IANA's registry, last updated 10 October 2025, IANA has allocated about 1.6% of 2000::/3, the block it hands out from, to the regional registries and two special uses. That records what has left IANA, and says nothing of what has been assigned or routed. The whole block contains 2^45 /48s, about 35.2 trillion.
Whether an organisation answers on IPv6 at all is a separate question, which our check of ASEAN institutions took up. On supply, RIPE-690's advice to operators is direct: "You should not be concerned with exhausting the IPv6 addressing space, and you should think big when planning future requirements."
View author profile → · Editorial policy
