Unique Local IPv6 Unicast Addresses
Extracted elements (22)
A /7 prefix with a 41-bit Global ID space (including L bit) was chosen because it provides ~2.2 trillion assignments while consuming less than 0.8% of the total IPv6 address space. The field size was evaluated against a projected 2050 world population yielding 236 /48 prefixes per person.
Global IDs are pseudo-randomly allocated (not from a central registry) to allow self-generated, coordiation-free assignment with extremely high probability of uniqueness. The collision probability for 1000 interconnected networks with 40-bit IDs is approximately 4.54×10^-7.
Local IPv6 addresses cannot be globally routed because their random /48 prefixes do not fit the hierarchical IPv6 unicast address model, cannot aggregate with normal IPv6 addresses or with each other, and would require flat routing over the wide-area Internet—creating unacceptable routing table growth.
Several design factors discourage use of Local IPv6 addresses as arbitrary global unicast: default filtering rules at site borders, lack of public registration and uniqueness guarantee, non-aggregatable random allocation, and the /48 prefix being too long for exclusive use by the largest organizations.
AAAA and PTR records for locally assigned Local IPv6 addresses are not recommended for installation in the global DNS. The small possibility of duplicate prefixes across organizations could result in connection timeouts, ICMP Destination Unreachable messages, or connections to the wrong host.
Local IPv6 addresses can be used for inter-site VPNs with appropriate routes configured. Because the addresses are globally unique (with high probability), these VPNs work without address translation and remain stable through site renumbering or merging.
Recursive name server implementations should act as authoritative for an empty d.f.ip6.arpa zone and return RCODE 3 for reverse queries for Local IPv6 addresses, as the default behavior, to reduce global DNS query load.
Site border routers should respond with ICMPv6 Destination Unreachable messages when rejecting packets to Local IPv6 destinations. This feedback is important to avoid transport protocol timeouts.
Global IDs MUST NOT be assigned sequentially or with well-known numbers. They MUST be generated with a pseudo-random algorithm consistent with RFC 4086 to ensure uniqueness and prevent any implied aggregation.
If BGP is used at the site border with an ISP, the default BGP configuration MUST filter out any Local IPv6 address prefixes both incoming and outgoing, unless specific /48 or longer routes are created for inter-site use.
Locally assigned Global IDs MUST be generated with a pseudo-random algorithm consistent with [RANDOM] (RFC 4086). All sites generating Global IDs must use a functionally similar algorithm to ensure high probability of uniqueness.
Reverse (PTR) queries for locally assigned Local IPv6 addresses MUST NOT be sent to name servers for the global DNS, due to load that such queries would create for the authoritative name servers for the ip6.arpa zone.
Site border routers and firewalls should be configured to not forward packets with Local IPv6 source or destination addresses outside of the site unless explicitly configured with routing information about specific /48 or longer prefixes. The default behavior should install a 'reject' route for these prefixes.
The default behavior of exterior routing protocol sessions between administrative routing regions MUST be to ignore receipt of and not advertise prefixes in the FC00::/7 block, unless specifically configured for inter-site communication.
Local IPv6 addresses are not created automatically like link-local addresses. They must be explicitly configured via IPv6 stateless address autoconfiguration (SLAAC), DHCPv6, or manual assignment. Routers must advertise Local IPv6 /64 prefixes in Router Advertisements to enable autoconfiguration.
Local IPv6 addresses have global scope by default—they are not ambiguous like deprecated site-local addresses. Their limitation is routability (restricted to a site and explicit inter-site agreements), not addressing scope. A site may have multiple such prefixes simultaneously.
The 40-bit Global ID creates a globally unique prefix through pseudo-random allocation. It MUST NOT be assigned sequentially or with well-known numbers, ensuring no relationship between allocations and clarifying these prefixes are not intended for global routing.
The FC00::/7 prefix identifies all Unique Local IPv6 Unicast addresses. Currently only FD00::/8 (L=1) is defined for locally assigned prefixes; FC00::/8 (L=0) is reserved for future allocation methods.
The recommended pseudo-random Global ID algorithm: (1) obtain current time in 64-bit NTP format, (2) obtain an EUI-64 identifier, (3) concatenate them, (4) compute SHA-1 digest, (5) use the least significant 40 bits as the Global ID, (6) prepend FC00::/7 with L=1.
IANA assigned the FC00::/7 prefix to 'Unique Local Unicast' in the IPv6 Special-Purpose Address Registry. Currently only FD00::/8 (L=1, locally assigned) is in use; FC00::/8 (L=0) is reserved for future assignment methods.
Local IPv6 addresses do not provide inherent security to nodes that use them. Filtering at site boundaries is no more or less secure than filtering other global unicast addresses. However, they do allow address-based security mechanisms including IPsec across end-to-end VPN connections.
Local IPv6 addresses use the format: 7-bit prefix (FC00::/7), 1-bit L flag, 40-bit Global ID, 16-bit Subnet ID, and 64-bit Interface ID. The L bit is set to 1 for locally assigned prefixes; L=0 is reserved for future use.