When companies merge or set up an extranet to communicate, it has proven difficult with IPv4 Private addressing because the companies often use the same or overlapping address space, and that requires the ugly hack of NAT to get around, and that can cause problems and break many protocols.
This was identified as a problem when IPv6 ULA was being developed, and the goal was to allow companies to have non-Internet address space, but to have a very high probability that the space used was unique. This is to try to prevent the problem of merging or communication between companies using non-Internet addressing. IPv6 doesn't have NAT, and the goal of IPv6 is to restore the IP end-to-end connectivity that was lost when NAT became necessary due to the limited number of IPv4 addresses.
The first half of the IPv6 ULA space (
fc00::/8) is reserved for assignment by a (yet to be named) global authority, while the second half of the IPv6 ULA space (
fd00::/8) was set up so that companies could assign their own addressing with a high probability of uniqueness.
According to RFC 4193, unique local addresses will always have a
That is simply incorrect. That RFC defines the ULA space as
fc00::/7, but there are two parts to the space that are defined by the eighth bit ("L" bit).
From the RFC:
The Local IPv6 addresses are created using a pseudo-randomly allocated
global ID. They have the following format:
| 7 bits |1| 40 bits | 16 bits | 64 bits |
| Prefix |L| Global ID | Subnet ID | Interface ID |
This divides the ULA space into two
fc00::/8 for globally assigned addressing, and
fd00::/8 for locally assigned addressing. Notice the format in the RFC requires "a pseudo-randomly allocated global ID." This is further explained:
3.2. Global ID
The allocation of Global IDs is pseudo-random [RANDOM]. They MUST NOT
be assigned sequentially or with well-known numbers. This is to ensure
that there is not any relationship between allocations and to help
clarify that these prefixes are not intended to be routed globally.
Specifically, these prefixes are not designed to aggregate.
This document defines a specific local method to allocate Global IDs,
indicated by setting the L bit to 1. Another method, indicated by
clearing the L bit, may be defined later. Apart from the allocation
method, all Local IPv6 addresses behave and are treated identically.
The local assignments are self-generated and do not need any central
coordination or assignment, but have an extremely high probability of
As you can see, the premise of your question that the RFC says that ULA addresses will always have a prefix of
fd00::/8 is incorrect.
Is this enforced, and if so why? What stops me from having a prefix of
/32 or /16 etc?
There is no actual enforcement, the way there would be if you were trying to use the addressing on the public Internet. Your company could simply use any addressing in that space, in whatever blocks it wants. What your business does for addressing on its own network is completely up to it, but it could prove foolish and expensive in the long run to not follow the standards.
For example, I know of some companies that used "dark" IPv4 address space within their networks, but then the dark address space started to be used on the public Internet, and the companies were unable to connect with customers or vendors using addressing in that address space, and it took some ugly solutions to get around that in the short term, until all the internal networks using that address space were readdressed. It took a few years and a lot of money to fix the problems.
RFC 4193, Unique Local IPv6 Unicast Addresses is the definition of IPv6 ULA, and you should refer to it for the details:
This document defines an IPv6 unicast address format that is globally
unique and is intended for local communications [IPV6]. These
addresses are called Unique Local IPv6 Unicast Addresses and are
abbreviated in this document as Local IPv6 addresses. They are not
expected to be routable on the global Internet. They are routable
inside of a more limited area such as a site. They may also be routed
between a limited set of sites.
Local IPv6 unicast addresses have the following characteristics:
Globally unique prefix (with high probability of uniqueness).
Well-known prefix to allow for easy filtering at site
Allow sites to be combined or privately interconnected without creating any address conflicts or requiring renumbering of
interfaces that use these prefixes.
Internet Service Provider independent and can be used for
communications inside of a site without having any permanent or
intermittent Internet connectivity.
If accidentally leaked outside of a site via routing or DNS,
there is no conflict with any other addresses.
In practice, applications may treat these addresses like global
This document defines the format of Local IPv6 addresses, how to
allocate them, and usage considerations including routing, site border
routers, DNS, application support, VPN usage, and guidelines for how
to use for local communication inside a site.