Hcfyk

According to RFC 4193, unique local addresses will always have a prefix of FD00::/8.. but according to Wikipedia:

The block fd00::/8 is defined for /48 prefixes, formed by setting the forty least-significant bits of the prefix to a randomly generated bit string.

Is this enforced, and if so why? What stops me from having a prefix of /32 or /16 etc?

The requirement exists to prevent collisions. This is a bit more important than most people recognize.

Even if you have systems which currently don't communicate with other systems over the internet you still need your addresses to be globally unique. You may now or in the future need to add a host which can communicate both with your internal network and with the internet. And for communication with that host to work, the IP addresses with which it communicate will need to be unique.

If two internal networks exist with the same local range there is the possibility a host will eventually need to communicate with both and at that point you would have to renumber one of the networks. This kind of communication is likely to be needed if you are using a VPN connection and both client and server are on networks which make use of RFC 4193 address space.

Another way you could end up needing to communicate with other internal networks in the future is in case your company merges with another company which also uses internal networks.

40 random bits is enough to guarantee that a host which needs to communicate with multiple internal networks can expect to reach approximately one million different networks before seeing the first collision.

The 40 random bits requirement is not enforced in any way, but if you don't follow it you are setting yourself up for problems in the future when a collision happens.

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
prefix of FD00::/8

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:

3.1. Format

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 /8 spaces: 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
being unique.

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:

1. Introduction

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
  boundaries.




• 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
  scoped addresses.

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.