Summary
- The IPv6 site-local prefix
FEC0::/10gave networks internal addresses without a global prefix, but the address did not say which site it belonged to. - RFC 4193 replaced that boundary-dependent design with locally generated prefixes that are highly likely to be unique, while leaving routing local.
Analysis
The second half of the address lived on the host
An application remembered FEC0::1234:5678:9ABC and tried to connect. On a multi-homed or mobile host, the hexadecimal string could be insufficient: the application also needed to say which site, using a scope identifier such as %1. On another host instantiation, the same site might be %2. The address looked portable; the missing half lived in local host state.
That was the awkward bargain behind IPv6’s site-local unicast addresses. RFC 3513, published in April 2003, defined FEC0::/10 for use inside a site without a global prefix. The prefix was followed by a 54-bit subnet ID and a 64-bit interface ID. Routers were not to forward packets with those addresses outside the site. A network could use IPv6 internally without first obtaining a globally routed block.
The address did not identify the site that made it local. FEC0::1 could exist in two sites at once. RFC 3879’s September 2004 account describes what followed: applications had to manage an extra site identifier; a literal address could not be safely remembered as a host-independent destination or learned from DNS; and software that passed IP addresses to other people could carry the ambiguity across the boundary.
“Site” was doing too much work for one field. A corporate network, a campus, a geographic location, a routing domain, a firewall zone and an administrative budget can draw different borders. RFC 3879 lists security, reachability, routing, quality-of-service, administrative and funding boundaries among the possible meanings. A DMZ could be inside for one purpose and outside for another. The packet had one address; the organization had several maps.
Routers inherited the same argument. If identical site-local destinations meant different things depending on the interface where a packet arrived, a multi-site router needed site-dependent routing entries and special forwarding-table handling. Tunnels and virtualized routing tables could carry the burden, but they did not make “site” a universal unit.
The appeal was real: local addressing without a global prefix, with a boundary routers could filter. In 2003, IPv6’s working group moved toward a replacement. RFC 3879 records agreement in March and confirmation in July, while noting that consensus was far from unanimous. The September 2004 RFC deprecated FEC0::/10, but allowed existing implementations and deployments to keep using it until a replacement was standardized. It barred reassignment of the prefix without a future IETF standards action.
RFC 4193 supplied the replacement in October 2005. Unique Local IPv6 addresses use FC00::/7; for locally assigned prefixes, a 40-bit Global ID is generated pseudo-randomly, followed by a 16-bit subnet ID and a 64-bit interface ID. “Global” here describes the intended uniqueness of the prefix, not a promise of Internet reachability. The RFC says uniqueness has high probability, not certainty. These addresses are intended for local communication, may be routed among a limited set of sites, and are not expected to be routed across the global Internet.
That change matters when networks join. Independently generated ULA prefixes are unlikely to collide, so a merger or private interconnection can often avoid renumbering; operators still need explicit routes between the sites. The address no longer has to encode a universal definition of “site.” The local network decides where its routes and filters carry it.
RFC 4291, in February 2006, folded the deprecation into IPv6’s addressing architecture: new implementations must not support the old special behavior for FEC0::/10. The RFC sequence explains the design change; it does not measure how many live systems still use the prefix. That prevalence question needs current host, router or traffic measurements.
Sources
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance





