Generate a prefix without a central allocator
02A site creates its own 40-bit Global ID. Independent pseudo-random choices make an overlap unlikely when sites later connect; they do not prove uniqueness.
Combine fc00::/7, L=1 and those 40 bits into a /48. This illustrates construction; it makes no claim that the fixed example is globally unique.
Source for this drawing: RFC 4193 · Read RFC section 3.2.1 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Random generation is required; the six-step hash recipe is a suggested algorithm.
- Locally assigned Global IDs MUST use a pseudo-random algorithm consistent with RFC4086. They MUST NOT be sequential or well-known numbers (§3.2).
- The suggested §3.2.2 recipe concatenates a 64-bit Network Time Protocol (NTP) time value and an Extended Unique Identifier (EUI-64) or suitably unique node identifier, hashes with Secure Hash Algorithm 1 (SHA-1), then takes the least significant 40 bits.
- Prefix construction adds fc00::/7 and L=1. SHA-1 here is the historical example for allocation, not a signature, password defense or security guarantee.
The pictured bytes are deliberately fixed teaching inputs, not entropy suitable for deployment. The sample recipe is not the only permitted algorithm. Collisions remain possible (§3.2.3).
Read the RFC section ↗