As organizations transition to IPv6, understanding the different types of IPv6 addresses becomes essential for proper network design. One of the most discussed—and sometimes misunderstood—address types is the Unique Local Address (ULA). This article explores what ULAs are, how they work, and when (or when not) to use them in your IPv6 deployment.
A Unique Local Address (ULA) is an IPv6 address in the range fc00::/7 that is designed for local communications within a site or between a limited set of sites. Defined in RFC 4193, ULAs are roughly analogous to IPv4 private addresses (RFC 1918) but with important differences that network administrators must understand. To understand the broader context of IPv6 addressing, see IPv6 Address Types.
The primary purpose of ULAs is to provide IPv6 addresses that:
Think of ULAs as addresses for internal network communications that you never intend to route over the public Internet, such as server-to-server communication within a data center, management interfaces, or isolated lab environments.
The ULA address space is defined by the prefix fc00::/7, which is actually split into two equally-sized blocks:
Since the fc00::/8 block is not currently defined, all valid ULA addresses today must start with fd.
A ULA address follows this structure:
| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+----------+----------------+
| Prefix |L| Global ID | Subnet ID| Interface ID |
+--------+-+------------+----------+----------------+
fd00::/7 1 (random) (subnet) (host)
Breaking this down:
fd (11111101 in binary) for locally assigned ULAsfd prefix)A properly formatted ULA looks like this:
fd3e:a4f2:6b1c::/48 (ULA prefix for an organization)
fd3e:a4f2:6b1c:0001::/64 (Subnet 1)
fd3e:a4f2:6b1c:0002::/64 (Subnet 2)
fd3e:a4f2:6b1c:0001::5 (Host address)
Notice that the first 48 bits (fd + 40-bit Global ID) remain constant for your organization, giving you 16 bits for subnetting and 64 bits for host addressing.
At first glance, ULAs might seem like a direct replacement for IPv4's RFC 1918 private address space (10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16). However, there are critical differences. For more information about the transition from IPv4 to IPv6, see Migrate IPv4 to IPv6:
| Aspect | IPv4 RFC 1918 | IPv6 ULA |
|---|---|---|
| Uniqueness | Designed to be reused across networks | Pseudo-randomly generated for global uniqueness |
| Network Mergers | Requires renumbering or complex NAT | Can be merged with minimal collision risk |
| Address Space | Very limited (about 17.9 million addresses) | Massive (2^40 possible /48 prefixes) |
| NAT Requirement | Typically requires NAT for Internet access | Does not require NAT; use dual-stack instead. For more on NAT in IPv6, see NAT in IPv6 |
| DNS Reverse Zones | Can be managed normally | Must not be sent to global DNS servers |
Perhaps the most important operational difference is how operating systems handle address selection in dual-stack environments. According to RFC 6724 (default address selection), IPv4 addresses are always preferred over ULA addresses. This means that if a host has both an IPv4 address and a ULA address, it will use IPv4 for communication—even if the destination also has IPv6 connectivity. This behavior makes ULAs problematic in dual-stack networks and is one reason many network engineers recommend avoiding them entirely. For more on this topic, see Browser IPv4 Preference.
RFC 4193 specifies that the 40-bit Global ID must be pseudo-random and must NOT be assigned sequentially or with well-known numbers. This randomness is crucial to ensure uniqueness across different organizations.
RFC 4193 Section 3.2.2 provides an algorithm for generating a ULA prefix:
Several online tools can generate RFC 4193-compliant ULA prefixes:
These tools implement the RFC 4193 algorithm to ensure proper randomness and uniqueness.
Never use fd00::/64 directly. This is a common error that violates the RFC 4193 specification. You must use a randomly generated 40-bit Global ID, resulting in a /48 prefix like fd3e:a4f2:6b1c::/48, then subnet from there.
Don't pick "easy to remember" values. While it might be tempting to use something like fd00:0000:0001::/48, this defeats the purpose of the pseudo-random generation and increases collision risk.
ULAs are suitable for specific scenarios:
The networking community increasingly recommends using global unicast addresses (GUA) for most deployments, even for internal-only resources. Here's why. For more about IPv6 address scopes, see IPv6 Address Scopes. For detailed comparison between address types, see Global Unicast vs Link-Local:
Modern best practice is to deploy global unicast IPv6 addresses throughout your network and use firewall rules to control traffic flow and enforce security policies. This approach leverages IPv6's massive address space while maintaining security through proper network segmentation and access controls.
If you do choose to use ULAs, best practice is to deploy them alongside global unicast addresses (dual-stack at the address level). For more about dual-stack networking, see Dual Stack Networking:
This configuration allows internal services to use ULA addresses for local communication while still having global addresses available when needed. However, be aware of the address selection issues mentioned earlier.
When implementing ULAs, you must configure border routers to prevent ULA addresses from leaking to the Internet:
# Example ACL to block ULA at border
deny ipv6 fc00::/7 any
deny ipv6 any fc00::/7
Most Internet routers should already filter these addresses, but it's best practice to filter them at your own network edge.
ULAs are designed to be routed internally just like any other unicast address. They can be:
For more on IPv6 routing considerations, see IPv6 Routing Policies.
According to RFC 4193, reverse DNS queries for ULA addresses must not be sent to global DNS servers. Instead:
Whether you choose to implement ULAs or stick with global unicast addresses, it's crucial to test your IPv6 connectivity properly. Tools like test-ipv6.run can help you verify that your IPv6 implementation is working correctly by testing. For more testing information, see Dual Stack Test Explained:
These tests run directly in your browser and can reveal issues with IPv6 configuration, including problems that might arise from ULA implementation in dual-stack environments.
Unique Local Addresses (ULAs) provide a way to implement private IPv6 addressing within organizations. While they share conceptual similarities with IPv4 RFC 1918 private addresses, they have important differences—particularly around uniqueness and address selection behavior.
For most modern IPv6 deployments, the networking community recommends using global unicast addresses throughout your network, with firewall rules providing security and access control. This approach avoids the complexity and limitations of ULAs while taking full advantage of IPv6's vast address space.
However, ULAs do have valid use cases for isolated networks, lab environments, and situations where addressing stability is paramount. If you do choose to implement ULAs, follow RFC 4193 carefully: generate your prefix randomly, use the full /48 allocation model, configure proper routing filters, and be aware of the address selection implications in dual-stack environments. For testing your network's IPv6 implementation, see Check Device IPv6 Connectivity.
As with any networking decision, the choice between ULAs and global unicast addresses should be based on your specific requirements, security policies, and long-term network architecture goals.