skip to content

Why does an IPv6 unique local prefix carry a pseudo-random 40-bit Global ID, and what goes wrong when every site simply uses fd00::/48?

level: middleimportance: nice to knowfreq 16%

answer

  1. the site-local lesson
  2. fd plus forty random bits
  3. a /48 per site
  4. merges and VPNs collide
  5. unique but not routed

basics

~20 s

RFC 4193 gives each site a pseudo-random 40-bit Global ID after fd so two sites' prefixes almost never match. Everyone choosing fd00::/48 recreates the ambiguity of deprecated site-local: merged networks and VPNs collide and must renumber.

solid answer

~40 s

A unique local address is `fc00::/7`, an L bit (1 for locally assigned, giving `fd00::/8`), a 40-bit **Global ID**, a 16-bit subnet ID and a 64-bit interface ID, so each site gets a /48. RFC 4193 says the Global ID MUST be pseudo-random and MUST NOT be sequential or a well-known number, so that two independently chosen prefixes are very probably different; its analysis puts the collision chance at about 4.5 × 10⁻⁵ even among 10,000 interconnected IDs. That is the lesson of site-local `fec0::/10`, which RFC 3879 deprecated because the same addresses existed in every site. Picking `fd00::/48` or another memorable value throws that away: two companies merging, or one VPN joining two sites, now have overlapping addresses and must renumber or translate, the same pain as overlapping private IPv4 space.

go deeper

for a junior

Recall that unique local addresses start with fd, are for internal use and are not routed on the internet.

for a middle

Lay out the fields, fd, 40-bit Global ID, 16-bit subnet ID and 64-bit interface ID, and explain why the Global ID is random and why site-local was deprecated.

for a senior

Predict the failure of a hand-picked prefix such as fd00::/48 at a merger, a VPN or a remote-access client, and filter fc00::/7 at the site border.

for a principal

Weigh ULA beside global addressing: stable internal numbering versus a second address plan to operate, and a policy that every site generates its prefix randomly.

## The format RFC 4193 (2005) defines **unique local IPv6 unicast addresses** (ULA). Their layout: | Field | Bits | Value | |---|---|---| | Prefix | 7 | `fc00::/7` (`1111110`) | | L bit | 1 | 1 = locally assigned; 0 is reserved for a method "defined in the future" | | Global ID | 40 | Pseudo-random per site | | Subnet ID | 16 | One value per link inside the site | | Interface ID | 64 | As in RFC 4291 | With L = 1 the first byte is `1111 1101`, so every locally assigned ULA starts with `fd`. The prefix, L bit and Global ID together make 48 bits, so each site owns a **/48** and can number 2^16 = 65,536 /64 subnets. ## Why the Global ID must be random RFC 4193 section 3.2 says Global IDs **MUST** be allocated pseudo-randomly and **MUST NOT** be assigned sequentially or with well-known numbers. It gives a sample algorithm: take the time of day in 64-bit NTP format, concatenate a system identifier such as an EUI-64, compute a SHA-1 digest, and keep the least significant 40 bits. Any good random source serves the same purpose. The point is to make independently chosen prefixes very probably different without any registry. The RFC estimates the chance that two or more of N interconnected Global IDs collide as `P = 1 − exp(−N² / 2^41)`: | Interconnected Global IDs | Probability of a collision | |---|---| | 2 | 1.81 × 10⁻¹² | | 10 | 4.54 × 10⁻¹¹ | | 1,000 | 4.54 × 10⁻⁷ | | 10,000 | 4.54 × 10⁻⁵ | Small, but not zero; RFC 4193 calls it adequate for sites planning "a small to moderate amount of inter-site communication". ## The lesson ULA learned from site-local IPv6 first had **site-local** addresses, `fec0::/10`, one shared prefix that every site reused. RFC 3879 (2004) deprecated them. Its main complaints: - **Ambiguity.** An address such as `fec0::1` existed in many sites at once and said nothing about which site it belonged to. - **Zone identifiers.** Applications had to carry a site identifier alongside the address, written after `%`, and that identifier differed from host to host. - **Fuzzy boundaries.** Nobody could say precisely where a site ended, so routers and firewalls disagreed. ULA kept the useful part, stable internal addressing independent of the provider, and removed the ambiguity by making each site's prefix very probably unique. ## What goes wrong with fd00::/48 everywhere Choosing a memorable prefix such as `fd00::/48` works on day one. The problems arrive when networks meet: 1. **Mergers and acquisitions.** Two organisations that both chose `fd00::/48` now have duplicate subnets. One side must renumber, or traffic between them must be translated. 2. **Site-to-site VPNs and partner links.** A tunnel between two sites with the same ULA prefix cannot route correctly: each side believes the other's subnets are local. 3. **Remote access.** A laptop on a home network that also chose `fd00::/48` can find a corporate subnet identical to its own local one. This is the IPv4 experience with overlapping RFC 1918 space, deliberately designed out of IPv6 and then reintroduced by a convenient prefix. ## Scope versus routability RFC 4193 says the scope of these addresses is **global**, because they are very probably unique, but their **routability** is limited to a site and any explicit agreements with other sites. In practice: - They route inside the site like any unicast prefix, through any IPv6 routing protocol. - Exterior routing sessions should, by default, ignore and not advertise `fc00::/7`; specific /48 or longer routes may be configured on purpose between cooperating sites. - Site border routers and firewalls should not forward packets with ULA source or destination outward, should install a reject route for the block and should answer with an ICMPv6 Destination Unreachable so senders do not wait for timeouts. - AAAA and PTR records for locally assigned ULAs are not recommended in the global DNS, because uniqueness is probable rather than guaranteed. ## When ULA is the right choice ULA suits addressing that must stay stable when the provider prefix changes: internal services, management networks and isolated labs. It runs alongside global addresses on the same hosts, often with the same subnet IDs, rather than replacing them.

  • Can two organisations that both generated ULA prefixes correctly still collide?
    Yes, in principle. RFC 4193's analysis gives about 1.8 × 10⁻¹² for two interconnected Global IDs and about 4.5 × 10⁻⁵ for 10,000. The random 40 bits make a collision very unlikely, not impossible, which is also why the RFC does not recommend publishing ULA records in the global DNS.
  • Does a ULA prefix need to be registered with anyone?
    No. Locally assigned Global IDs, the L = 1 half `fd00::/8`, are self-generated with no central coordination; uniqueness comes from the pseudo-random 40 bits. RFC 4193 reserves the L = 0 half for an allocation method that may be defined in the future.

Site-local addressing was every family naming their dog Rex: fine at home, chaos at a shared dog park. A random Global ID is giving each dog a random forty-bit tag number, so two tags matching in the park is possible in principle but vanishingly unlikely.

saying these in an interview costs you the question

  • fd00::/48 is the standard ULA prefix every site should use.
  • ULA is site-local renamed, with the same ambiguity.
  • A ULA prefix must be registered to guarantee it is unique.
  • Random Global IDs make collisions impossible.
  • The L bit decides whether a ULA is routed on the internet.