Summary

  • RFC 4193 uses a pseudo-random 40-bit Global ID to make independently generated IPv6 Unique Local Address prefixes very likely to be different; it does not allocate, register or certify them.
  • “Global” describes the intended uniqueness scope, not public reachability. ULA routes belong inside a site or an explicit inter-site arrangement and need deliberate routing, DNS and border policy.
  • A merger or VPN should therefore treat probability as the start of due diligence: compare every prefix, record route and naming scope, keep security controls independent, and define the condition for renumbering or rollback.

Two companies are about to connect their networks. Each team says its internal IPv6 space is unique. One produces a registry letter. The other produces a line from a configuration file beginning with fd. The prefixes differ, the tunnel comes up, and the project manager marks address overlap as resolved.

Only one of those records could have been an allocation receipt. The fd prefix was designed so that no receipt would normally be needed.

That is the elegant bargain in RFC 4193, published in October 2005 by Robert Hinden and Brian Haberman. A Unique Local Address, or ULA, is ordinary IPv6 unicast space with a special operating boundary. The format occupies FC00::/7. It contains a one-bit L flag, a 40-bit Global ID, a 16-bit Subnet ID and the usual 64-bit Interface ID. RFC 4193 defines L=1 for locally assigned addresses, which places the currently specified local construction under FD00::/8.

The crucial word is locally. An operator can generate the 40-bit value without asking a registry or coordinating with every other operator. The RFC requires pseudo-random selection rather than sequential or familiar values. Its suggested procedure combines the time with a system-specific identifier, hashes the result with SHA-1 and retains the least significant 40 bits.

This is not a miniature public-key ceremony. SHA-1 in that procedure does not authenticate the operator, confer ownership or make the address secret. It is a way to spread independent choices across a large space.

The probability table explains what the mechanism buys. RFC 4193 estimates the chance of a collision at roughly 1.81 × 10^-12 when two independently generated Global IDs are compared. At 10,000 IDs, the estimate rises to roughly 4.54 × 10^-5. Those are modelled probabilities, not measurements of deployed networks. They make accidental overlap very unlikely; they do not make it impossible.

That distinction is easy to lose because the field is called a Global ID. Here, “global” describes an aspiration for uniqueness across independently administered sites. It does not mean the route is globally reachable, aggregatable or entitled to appear in the default-free zone. The current IANA IPv6 Special-Purpose Address Registry makes the separation explicit: fc00::/7 can be used as a source or destination and can be forwarded, but it is not globally reachable. IANA also warns that placement in the registry does not by itself guarantee routability in any particular context.

A scope that routers must enforce

RFC 4193 expects ULA routes to remain within a site or among sites that have deliberately agreed to exchange them. Internet routing should ignore the whole range by default. A border should normally filter ULA routes and packets in both directions. Where two organisations intentionally connect, the exception should name the particular /48 prefixes—or more-specific routes—that the connection needs, not open FC00::/7 as a class.

The routing rule reveals why “private IPv6” is an incomplete description. ULA does not automatically stop at a wall. A router can forward it. A VPN can carry it. A careless redistribution policy can leak it. A receiving network can install the route. Scope is an operational decision expressed through filters and topology, not a mystical property of the first byte.

DNS needs the same discipline. RFC 4193 recommends against putting ULA AAAA or PTR records in the global DNS because the addresses are not guaranteed to be unique. Reverse queries for them must not escape to global DNS infrastructure. Internal authoritative zones, split-horizon views and resolver forwarding rules therefore belong in the merger inventory alongside the prefixes themselves.

Address assignment remains separate too. A ULA /48 does not populate a subnet. Router advertisements, DHCPv6, manual configuration, subnet planning and name registration still determine which systems use it. RFC 5375 notes that ULA can coexist with globally routed IPv6 addresses. It does not imply that IPv6 should be placed behind network address translation.

That last boundary matters. An organisation may use globally reachable addresses for external services and ULA for stable internal references, or may decide that global addressing plus policy controls is simpler. Neither choice removes the need for authentication, authorisation, firewalling and service-level controls. RFC 4193 is direct: ULA provides no inherent security. An address class is not an identity system.

What the 40 bits repaired

The predecessor helps explain the design. RFC 3879 deprecated IPv6 site-local addresses because “site” had no stable meaning. An organisation with several locations could not reliably determine whether two addresses belonged to the same site. Site-local prefixes could leak, applications could not choose scope consistently, and a network joining another network had no identifier distinguishing one local block from another.

The generated Global ID repairs that last weakness without creating a universal allocator. Two sites can number themselves independently and later discover that their prefixes almost certainly differ. RFC 5375 highlights the benefit for leakage and mergers: ULA can reduce the likelihood that joining networks forces an immediate renumbering.

Reduce is not eliminate. RFC 4193 warns that global ULA routing is inadvisable partly because no authority guarantees uniqueness and the space cannot be usefully aggregated. If two connected sites do share an identifier, communication between them can fail or reach the wrong system. The fact that the collision was improbable does not make its impact small.

This is where Haberman’s contribution is most useful as an operating lesson. The RFC is co-authored with Hinden and acknowledges a wider technical community; it should not be turned into a lone-inventor story. Haberman’s later public record—long IETF participation, early IPv6 router work and, as of August 2026, the chair of the Internet Society Board—shows a career around the institutions and running systems that have to preserve such boundaries. The standard itself remains the authority for the technical claims.

The receipt a merger actually needs

When two networks join, neither team should reject ULA because it lacks central paperwork. Nor should either accept it merely because the prefixes look random. The missing receipt is operational and can be assembled.

First, list the exact active and reserved /48 prefixes on both sides. Include lab networks, cloud virtual networks, dormant VPN partners, disaster-recovery environments and address blocks embedded in application configuration. Compare values directly. The RFC’s probability supports confidence before inspection; it cannot replace the inspection once both inventories are available.

Second, record how each prefix was produced and who maintains it. A generation time, method, system-identifier class and accountable operator make later duplication or copying easier to diagnose. The record need not expose a sensitive machine identifier, but it should distinguish genuine independent generation from a template cloned across subsidiaries.

Third, make route admission explicit. Name the interconnection, allowed prefixes, next hops, import and export filters, monitoring owner and rollback action. Test that the border rejects the rest of FC00::/7 and that no ULA route reaches an Internet peer.

Fourth, inventory naming and address selection. Identify authoritative internal zones, reverse zones, split views, resolver paths and applications that prefer ULA over global addresses. A prefix collision is one failure mode; a duplicated internal name or an unreachable preferred address can break a service even when every Global ID differs.

Fifth, keep security evidence in its own column. Which service authenticates the caller? Which firewall rule admits the flow? Which route source is trusted? Which log can identify misuse? “It is ULA” answers none of those questions.

Finally, write the exit condition before cutover. A discovered collision may require renumbering one side. Unexpected global advertisement may require an immediate route withdrawal. DNS leakage may require isolating a resolver path. An application with embedded literals may keep the networks separate until it is repaired. Low probability is compatible with decisive rollback.

Heng Lu’s Running-Code Primacy sharpens this method. A declared prefix and a diagram are administrative evidence; packet paths, route tables, resolver behaviour and application tests show what the system actually does. Minimum Initial Specification adds the coordination rule: require the smallest shared record that allows each operator to preserve local design while making the interconnection reversible.

The 40-bit Global ID is valuable precisely because it does not try to centralise every internal network. It makes autonomous choices coexist with very high probability. The operator’s job is to keep “very high” in the probability column—and to build the routing, naming, security and exit controls that probability was never meant to supply.

Sources