Clock Sequence

The clock sequence value must be changed whenever:

• The UUID generator detects that the local value of UTC has gone backward.
  
  
• The UUID generator has lost its state of the last value of UTC used, indicating that time may have gone backward; this is typically the case on reboot.

  While a node is operational, the UUID service always saves the last UTC used to create a UUID. Each time a new UUID is created, the current UTC is compared to the saved value and if either the current value is less (the non-monotonic clock case) or the saved value was lost, then the clock sequence is incremented modulo 16,384, thus avoiding production of duplicate UUIDs.

  The clock sequence must be initialized to a random number to minimize the correlation across systems. This provides maximum protection against node identifiers that may move or switch from system to system rapidly. The initial value MUST NOT be correlated to the node identifier.

  The rule of initializing the clock sequence to a random value is waived if, and only if all of the following are true:

• The clock sequence value is stored in non-volatile storage.
  
  
• The system is manufactured such that the IEEE address ROM is designed to be inseparable from the system by either the user or field service, so that it cannot be moved to another system.
  
  
• The manufacturing process guarantees that only new IEEE address ROMs are used.
  
  
• Any field service, remanufacturing or rebuilding process that could change the value of the clock sequence must reinitialise it to a random value.

  In other words, the system constraints prevent duplicates caused by possible migration of the IEEE address, while the operational system itself can protect against non-monotonic clocks, except in the case of field service intervention. At manufacturing time, such a system may initialise the clock sequence to any convenient value.