(RFC) 4291 splits an IPv6 global unicast address into a global routing prefix for a site, a subnet identifier (ID) for one link in it, and an interface ID; outside the range that begins with binary 000, the first two share 64 bits (RFC 4291, section 2.5.4). With the lower half taken, IPv6 subnetting divides the upper half: the Internet Assigned Numbers Authority () supplies the Regional Internet Registries (RIRs), they allocate to Local Internet Registries (LIRs) and Internet Service Providers (ISPs), providers assign end sites, and each site gives each link a /64. Understanding IPv6 Addressing covers the format. By the end you can size each level, explain why Stateless Address Autoconfiguration () holds a link at /64, and check a plan in Python, iproute2 and a capture.

From the registry to the link

RFC 3587 leaves the routing prefix to the RIRs and ISPs, and "The subnet field is designed to be structured hierarchically by site administrators" (RFC 3587, section 3). IANA may allocate 2000::/3 to the RIRs (ripe-738, section 1.1); on 3 October 2006 each of the five received a /12, 2800::/12 going to the Latin American and Caribbean Internet Address Registry (), which serves Brazil (IANA unicast registry), and a /12 holds 2^20 = 1,048,576 /32s. The RIPE Network Coordination Centre (RIPE NCC) gives a qualifying LIR a /32 to a /29 without further justification (ripe-738, sections 4.3 and 5.1.2) and leaves the end site's size to the LIR or (section 5.4.1); LACNIC recommends a /48 per site (LACNIC Policy Manual, section 4.4.3.1). Below that, the arithmetic is IPv4's Classless Inter-Domain Routing () (RFC 4291, section 2.5), as in CIDR notation explained.

Why the link is a /64

The 64 belongs to the interface ID: "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long" (RFC 7136, section 5). SLAAC leaves the length to each link type's document (RFC 4862, section 2), and 's says: "An IPv6 address prefix used for stateless autoconfiguration [ACONF] of an Ethernet interface must have a length of 64 bits" (RFC 2464, section 4). A sum decides: "If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored" (RFC 4862, section 5.5.3). A /80 plus 64 makes 144, so no address results; how a host builds its address has the rest.

Neighbor Discovery does not need the /64. RFC 7421 found the A flag, which permits stateless configuration, honoured only at length 64, while the L flag, which marks a prefix as on-link, "is honored for any arbitrary prefix length (whether shorter or longer than /64)" (RFC 7421, section 4.3.1). Nor is the /64 a forwarding rule: "In particular, forwarding processes MUST be designed to process prefixes of any length up to /128, by increments of 1" (RFC 7608, section 2). It replaced an expected /80 in December 1998, partly because 64-bit Extended Unique Identifier () Media Access Control (MAC) addresses were expected to spread (RFC 7421, section 1; RFC 2464, section 8), and it ends the variable-length subnet masking (VLSM) habit of sizing subnets to hosts (RFC 7421, section 2).

How big an end site's prefix should be

In 2001 RFC 3177 recommended a /48 in general, a /64 for exactly one subnet and a /128 for exactly one device (RFC 3177, abstract). In 2011 RFC 6177 said a one-size-fits-all /48 "is no longer recommended as a single default" (RFC 6177, abstract), fixing no size but wanting well over one /64 for homes, such as a /56 (sections 1 and 2). In 2017 ripe-690 strongly discouraged anything longer than /56 and offered a /48 for every end user, or a split "by offering /48 for business customers and /56 for residential customers" (ripe-690, section 1). A /32 holds 16,777,216 /56s (section 4.2.3), and RFC 7421 sees no objective risk of depletion even for the smallest sites (RFC 7421, section 3.1).

The handover can be Dynamic Host Configuration Protocol for IPv6 () prefix delegation, specified since January 2026 by RFC 9915, Internet Standard 102, which obsoletes RFC 8415, and it is "appropriate for use by an ISP to delegate a prefix to a subscriber" (RFC 9915, section 6.3), whose router may then assign subnets of it to its links (section 6.3). RFC 7084 has the customer edge router request enough for one /64 per interface, rounded up to a nibble, and it "MUST assign a separate /64 from its delegated prefix(es)" to each local area network () interface (RFC 7084, sections 4.2 and 4.3).

The subnet ID, counted

A /n holds 2^(m-n) prefixes of length /m, and the subnet ID lies between the site prefix and /64:

Site prefixSubnet ID bitsHex digits/64 subnets
/4816465,536
/521234,096
/5682256
/604116

A /64 holds 2^64 = 18,446,744,073,709,551,616 addresses, exactly the IPv4 address count squared, not more: an IPv4 address is 32 bits, carried in the low-order 32 bits when IPv6 embeds one (RFC 4291, section 2.5.5), and 4,294,967,296 × 4,294,967,296 = 2^32 × 2^32 = 2^64. In the documentation prefix 2001:db8::/32 (RFC 3849, abstract), 2001:db8:abcd::/48 numbers its /64s in the fourth group, 2001:db8:abcd::/64 to 2001:db8:abcd:ffff::/64. The /56 2001:db8:abcd:1a00::/56 fixes two of those digits (1a00 to 1aff), the /60 2001:db8:abcd:1a30::/60 three (1a30 to 1a3f), and a /62 such as 2001:db8:abcd:1a34::/62 (1a34 to 1a37) ends inside a digit.

Nibble boundaries and reverse DNS

Plans move a nibble, one hex digit, at a time: "The length of a delegated prefix should therefore always be a multiple of 4" (ripe-690, section 4.2), and the American Registry for Internet Numbers (ARIN) makes all allocations on nibble boundaries (ARIN policy manual, section 6.5.2.1). is the second reason. An ip6.arpa name lists the address's nibbles in reverse order, one per label (RFC 3596, section 2.5), so a nibble-aligned /n is one zone of n/4 labels: 2001:db8:abcd::/48 is d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa. A /50 such as 2001:db8:abcd:4000::/50 is four zones, 4.d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa to 7.d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa, all of which an LIR must delegate on request (ripe-738, section 5.6); Reverse DNS Lookups with nslookup covers the lookups. Inside the site, number subnets compactly from the low-order bits, as if only a /56 were available even in a /48 (RFC 5375, section 2.4).

Router links and loopbacks: /127 and /128

Between routers, RFC 6164 finds 127-bit prefixes useful, and "Such a practice parallels the use of 31-bit prefixes in IPv4" (RFC 6164, abstract). A shorter prefix there may cause a forwarding loop, and a neighbour-cache attack on a /64 can keep sessions down by leaving the routers unable to resolve each other's addresses, which a /127 eliminates (sections 5.1 and 5.2). Section 6 rules: "Routers MUST support the assignment of /127 prefixes on point-to-point inter-router links. Routers MUST disable Subnet-Router anycast for the prefix when /127 prefixes are used." Subnet-Router is the anycast address with an all-zeros interface ID (RFC 4291, section 2.6.1).

RFC 6164 also keeps all-zeros interface IDs and the highest 128 values, reserved for subnet anycast, off these links (RFC 6164, section 6). It prints that range from ff7f, which erratum 3422 corrects: "The highest 128 values start at ffff:ffff:ffff:ff80, not ffff:ffff:ffff:ff7f" (RFC 6164 errata, erratum 3422); this text follows the erratum. So reserve a /64 per link and use one /127 of it that avoids both (ripe-690, section 1): not the first /127 of 2001:db8:0:ff::/64, which holds the all-zeros 2001:db8:0:ff::.

RFC 5375's appendix B.2.2 once called /127 invalid; erratum 3309, verified in 2012, rewrote it to say /127 "is valid as stated in RFC 6164 [RFC 6164]" (RFC 5375 errata, erratum 3309), and this text follows the erratum. Loopbacks take a /128, for when one address is enough (RFC 5375, appendix B.2.3), such as 2001:db8:0:ffff::1/128.

Unique local prefixes

Unique local addresses (ULAs) play the part of private IPv4 address space but are meant to be unique: fc00::/7, an L bit set to 1 for local assignment, which makes the first byte fd, a 40-bit global ID, a 16-bit subnet ID and the interface ID (RFC 4193, section 3.1). The global ID must be random: "They MUST NOT be assigned sequentially or with well-known numbers" (section 3.2), which rules out fd00::/48. Hashing the time 2026-10-18T00:00:00Z with the EUI-64 34-56-78-FF-FE-9A-BC-DE, from RFC 2464's example MAC, and keeping the least significant 40 bits (section 3.2.2) gives the illustrative fd6c:f4fb:acc3::/48. Reuse the global plan's subnet IDs, filter ULAs both ways by default at a BGP border (section 4.1) and keep their records out of the global DNS (section 4.4). ULAs do not imply (RFC 5375, section 2.2).

Mistakes that break a plan

First, a prefix longer than /64 where hosts live. Using one "for links containing end hosts would be an especially bad idea" (RFC 5375, section 3). Such links lose SLAAC, and a /120 leaves an 8-bit identifier with collisions highly probable (RFC 7421, sections 4.4 and 4.2).

Second, conserving as in IPv4: "Assigning a /64 or longer prefix does not conform to IPv6 standards and will break functionality in customer LANs" (ripe-690, section 4.2.3). A home given a /60, with a /64 per client, runs out after 15 devices (RFC 9762, section 1).

Third, a plan that cannot be summarised; alignment decides, not count. Sixteen /48s from 2001:db8:a0::/48 to 2001:db8:af::/48 collapse into 2001:db8:a0::/44, but sixteen from 2001:db8:a8::/48 to 2001:db8:b7::/48 need 2001:db8:a8::/45 and 2001:db8:b0::/45, and random ULA /48s never aggregate (RFC 5375, section 2.4); see Route summarization and supernetting.

Fourth, the sparse /64, "a number so large it covers literally billions of billions of addresses, the overwhelming majority of which will be unassigned" (RFC 6583, section 2), which an attack on a router's neighbour cache exploits. Sizing subnets to the addresses in use avoids it but rules out SLAAC, so it suits only statically configured hosts (section 6.2); capping the cache's size and its incomplete entries also defeats the attack (RFC 7421, section 3.4).

How to see it

The IPv6 Toolkit reads one prefix: for 2001:db8:abcd:1a00::/56 it gives the network, first and last address, the count (2^72, with its exact decimal) and the host bits. It lists no subnets; its ip6.arpa line names the address typed, so keep the last n/4 labels for a zone; its special-use table lacks 3fff::/20, the second documentation block (RFC 9637, section 6), so 3fff:: shows as global unicast; and its EUI-64 line recovers a from a modified EUI-64 interface ID rather than building one. The Python playground runs CPython 3.14's ipaddress for the rest; its ipv6-eui64 example builds 21a:2bff:fe3c:4d5e from MAC 00:1A:2B:3C:4D:5E.

An illustrative session, on Python 3.13 with calls documented for 3.14 (ipaddress documentation):

>>> import ipaddress
>>> site = ipaddress.ip_network("2001:db8:abcd::/48")
>>> site.num_addresses
1208925819614629174706176
>>> 2 ** (64 - site.prefixlen)
65536
>>> list(site.subnets(new_prefix=52))[:3]
[IPv6Network('2001:db8:abcd::/52'), IPv6Network('2001:db8:abcd:1000::/52'), IPv6Network('2001:db8:abcd:2000::/52')]
>>> home = ipaddress.ip_network("2001:db8:abcd:1a00::/56")
>>> lans = list(home.subnets(new_prefix=64))
>>> len(lans)
256
>>> lans[0], lans[1], lans[-1]
(IPv6Network('2001:db8:abcd:1a00::/64'), IPv6Network('2001:db8:abcd:1a01::/64'), IPv6Network('2001:db8:abcd:1aff::/64'))
>>> home.network_address.reverse_pointer
'0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.1.d.c.b.a.8.b.d.0.1.0.0.2.ip6.arpa'
>>> list(ipaddress.ip_network("2001:db8:0:ff::/127").hosts())
[IPv6Address('2001:db8:0:ff::'), IPv6Address('2001:db8:0:ff::1')]
>>> ipaddress.ip_network("2001:db8:abcd:12::1/64")
Traceback (most recent call last):
  ...
ValueError: 2001:db8:abcd:12::1/64 has host bits set

hosts() omits the Subnet-Router anycast address except at /127, hence both addresses above, though RFC 6164 keeps the first off a router link; the /56's zone is the last 14 labels of reverse_pointer; and strict parsing rejects host bits (same documentation).

On Linux, with syntax from the iproute2 manual pages:

ip -6 address show dev eth0
ip address add 2001:0db8:85a3::0370:7334/64 dev eth1
ip -6 route show

-6 is shorthand for -family inet6 (ip(8)); a /127 or /128 is written like the /64, but mngtmpaddr, used by privacy addresses, requires a length of 64 (ip-address(8)); and routes with protocol ra came from Router Discovery (ip-route(8)).

A Router Advertisement is Internet Control Message Protocol for IPv6 () type 134 (RFC 4861, section 4.2). Its Prefix Information option carries Type 3, Length 4 (8-octet units), Prefix Length (0 to 128), the L, A, R and P flags, two lifetimes, a reserved field and the 128-bit prefix (section 4.6.2; RFC 9762, section 5), P meaning the network prefers prefix delegation to SLAAC or DHCPv6 addresses (RFC 9762, section 5). A delegation is OPTION_IA_PD (25) holding OPTION_IAPREFIX (26) options, each with two lifetimes, a 1-octet prefix length and the 16-octet prefix (RFC 9915, sections 21.21 and 21.22). Wireshark display filters for both:

icmpv6.type == 134 && icmpv6.opt.prefix.length != 64
dhcpv6.iaprefix.pref_len

The first matches advertisements carrying no /64 at all, since != on a repeated field requires every occurrence to differ (wireshark-filter(4)); the second lists delegated sizes (Wireshark DHCPv6 reference). The flags are icmpv6.opt.prefix.flag.l, .flag.a and, from Wireshark 4.6.0, .flag.p (Wireshark ICMPv6 reference).

What to remember

  • SLAAC ignores a prefix whose length plus the 64-bit interface ID is not 128, so host links are /64; Neighbor Discovery and forwarding take any length.
  • An RIR holds /12s, an LIR at least a /32, an end site a /48 or /56, which DHCPv6 can delegate, and each link a /64.
  • A /n holds 2^(m-n) prefixes of length /m, 65,536 /64s in a /48, and a /64's 2^64 addresses are exactly the IPv4 count squared.
  • Nibble steps put every boundary on a hex digit and an ip6.arpa label; a /50 needs four reverse zones.
  • Router links take a /127 from a reserved /64, clear of the all-zeros interface ID and the top 128 values from ffff:ffff:ffff:ff80 (erratum 3422); loopbacks take a /128.
  • Unique local prefixes start fd with a random 40-bit global ID, reuse the global subnet IDs and stay out of BGP and the global DNS.

Sources