IPv6 unique local unicast addresses are the equivalent of IP version 4 RFC 1918 space in most ways and are formatted in the following fashion:

7-bit Prefix – FC00::/7

1-bit Local bit (position 8 ) – Always set to “1”…for now

40-bit “kinda-almost-unique” Global ID

16-bit Subnet-ID

64-bit Interface ID

The intention and scope of these addresses is for unicast-based intra/inter-site communication. The definition of a “site” within the plethora of IPv6 RFCs is slightly ambiguous but in the case of RFC 4193, the demarcation of a “site” is between ISP and customer. According to the RFC, unique local unicast addresses are permitted to be used between “sites” i.e. customer-to-customer VPN communication but the FC00::/7 prefix is to be filtered by default at any site-border router. This space is not intended to be advertised to any portion of the internet.

Now the interesting portion of this RFC is the recommended algorithm for generating a realistically unique yet theoretically common 40-bit Global ID for your local unicast addresses. Section 3.2.2 recommends the following:

Obtain the current time of day in 64-bit NTP format

i.e. reference time is C029789C.45564D4E

Obtain an EUI-64 identifier from the system running this algorithm

i.e. bia of C201.0DC8.0000

Concatenate the time of day with the system-specific identifier in order to create a key

Also included in the RFC is sample probabilities of IPv6 address prefix uniqueness depending on the number of peer connections to a site. It’s safe to say if you experience an overlap using this method to assign Global IDs, play the damn lottery. While this method almost eliminates any overlap possibility between sites, the Global IDs generated with this method are hardly “pretty” numbers and there will undoubtedly be folks assigning Global IDs of ::1/40. If you have ever went through a merger/acquisition with IPv4, do yourself a favor and follow academia for assigning your Global IDs.