If you've spent time on IPv4 networks, you know the RFC 1918 private ranges by heart: 10.x.x.x, 172.16–31.x.x, 192.168.x.x. They're the addresses that never appear on the public internet, used for everything internal. IPv6 has an equivalent — Unique Local Addresses (ULAs) — and most people who run IPv6 networks either don't know they exist or assume they're not needed. Both assumptions cost you later.
What a ULA actually is
ULAs are defined in RFC 4193 and live in the fd00::/8 prefix (specifically fd00:: through fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff). The structure of a ULA is fixed:
| 7 bits | 1 bit | 40 bits | 16 bits | 64 bits |
| fc00:: | L=1 | Global ID| Subnet | Interface|
The Global ID is a 40-bit random number that makes your ULA prefix unique — not globally registered, but statistically unlikely to collide with anyone else's. The L=1 bit marks it as "locally assigned" (the fc00::/8 range with L=0 is reserved for future use), which is why every ULA you generate starts with fd.
The result: you own a /48 site prefix (e.g., fd3d:a8b2:c91f::/48) that you can divide into up to 65,536 /64 subnets — all routable within your network, none of them advertisable on the public internet.
Why ULAs beat link-local for private addressing
You may have heard of link-local addresses — the fe80::/10 range that every IPv6 interface auto-assigns itself. Link-local is automatic and zero-config, which sounds attractive, but there's a fundamental limitation: a link-local address is only valid on the network segment it was assigned to. You can't route it. Cross a router boundary and the address is meaningless.
ULAs don't have that problem. A fd::/8 address works across your entire network — routable between subnets, usable in DNS, persistable in config files — without ever touching the public internet. For any multi-subnet private network (an office, a lab, a homelab with VLANs), ULAs are what you want.
Why the Global ID should be random
RFC 4193 specifies that the Global ID should be generated pseudo-randomly — specifically using a hash of the current time and EUI-64 identifier — rather than chosen by hand. The reason is collision avoidance. If two organizations (or two homelab operators) independently build private networks and later merge or VPN them together, a randomly-generated Global ID makes an address collision vanishingly unlikely (1 in 2^40 per prefix). Hand-pick fd00:1234::/48 and the odds get considerably worse.
This is also why "just use fd00::" is bad advice that's still circulating: it's the most collision-prone choice in the entire range.
In practice: the setup in four steps
- Generate a random /48 prefix — 40 random bits, formatted as
fdXX:XXXX:XXXX::/48. - Divide it into /64 subnets — the 16-bit subnet field after your /48 gives you 65,536 of them.
- Assign addresses from your chosen /64 subnets to hosts, statically or via SLAAC/DHCPv6.
- Add your ULA prefix to internal DNS — ULA addresses work fine as DNS records and in
/etc/hosts; they won't be reachable from outside and don't need firewall rules to prevent it.
The entire ULA setup is contained within your network. No registration, no fees, no ISP involvement. If you later get a public IPv6 prefix from your ISP, your internal routing stays unchanged — you run ULA and GUA (global unicast) side by side, and hosts pick the right one for each destination via policy tables.
Generate your prefix
Our IPv6 ULA Generator produces a correctly randomized /48 prefix and a ready-to-use /64 subnet, following RFC 4193's generation algorithm. If you need to plan subnetting on top of it, the IPv6 Subnet Calculator breaks any prefix into subnet tables — and the IPv6 Expander converts the compressed notation back to full form if you need it for tooling that doesn't handle :: shorthand.