According to RFC3315:
Each DHCP client and server has a DUID. DHCP servers use DUIDs to identify clients for the selection of configuration parameters and in the association of IAs with clients. DHCP clients use DUIDs to identify a server in messages where a server needs to be identified.
[...]
Clients and servers MUST treat DUIDs as opaque values and MUST only compare DUIDs for equality. Clients and servers MUST NOT in any other way interpret DUIDs.
For IPv4 it's very common for a DHCP server to allocate fixed addresses to clients based on, for example, MAC addresses. So for IPv6 how does the DHCPv6 server allocate fixed IPv6 addresses?
You're reading it wrong. They're allowed to compare if DUID's are equal to a stored value. They should not try to interpret the content of it in any other way, e.g. to try to retrieve the MAC address or similar shenanigans.
It should be treated as an opaque value, that is a number sequence without any known meaning. They should not try to deduce the meaning of the sequence, but it's fine to compare it against a stored value to check if they're equal. No meaning can be read into the sequence as per the RFC.
A client should not change its DUID between reboots, so once you have assigned a specific IPv6 address to a client it should get the configured address every time.
The advantage of the DUID is that it stays the same even when the client uses a different network adapter with a different MAC address. The downside is that you have no idea in advance which DUID the client will use (unless you have some out-of-band provisioning to force the client to use a specific DUID).
RFC6939 specifies an option that DHCPv6 relays can use to tell the DHCPv6 server what the MAC address of the client is. DHCPv6 servers can use that to identify the client. Officially DHCPv6 servers shouldn't use the MAC address of the client or try to decode the DUID, but they can cheat of course :) This happens quite often.