The (optional) UUID generator state only needs to be read from stable storage once at boot time, if it is read into a system-wide shared volatile store (and updated whenever the stable store is updated).

This stable storage MAY be used to record various portions of the UUID generation, which prove useful for batch UUID generation purposes and monotonic error checking with UUIDv6 and UUIDv7. These stored values include but are not limited to last known timestamp, clock sequence, counters, and random data.

If an implementation does not have any stable store available, then it MAY proceed with UUID generation as if this were the first UUID created within a batch. This is the least desirable implementation because it will increase the frequency of creation of values such as clock sequence, counters, or random data, which increases the probability of duplicates. Further, frequent generation of random numbers also puts more stress on any entropy source and/or entropy pool being used as the basis for such random numbers.

An implementation MAY also return an application error in the event that collision resistance is of the utmost concern. The semantics of this error are up to the application and implementation. See Section 6.7 for more information on weighting collision tolerance in applications.

For UUIDv1 and UUIDv6, if the Node ID can never change (e.g., the network interface card from which the Node ID is derived is inseparable from the system), or if any change also re-initializes the clock sequence to a random value, then instead of keeping it in stable store, the current Node ID may be returned.

For UUIDv1 and UUIDv6, the state does not always need to be written to stable store every time a UUID is generated. The timestamp in the stable store can periodically be set to a value larger than any yet used in a UUID. As long as the generated UUIDs have timestamps less than that value, and the clock sequence and Node ID remain unchanged, only the shared volatile copy of the state needs to be updated. Furthermore, if the timestamp value in stable store is in the future by less than the typical time it takes the system to reboot, a crash will not cause a re-initialization of the clock sequence.

If it is too expensive to access shared state each time a UUID is generated, then the system-wide generator can be implemented to allocate a block of timestamps each time it is called; a per-process generator can allocate from that block until it is exhausted.