Deprecating Site Local Addresses
Extracted elements (15)
Avoiding an explicit scope declaration in the replacement removes ambiguity around the site concept; non-reachability can be enforced via firewall rules on ranges of the new non-ambiguous addresses, making explicit scope unnecessary.
Deprecation does not require immediate removal from deployments; it allows continued use until a replacement is standardized and implemented, balancing backward compatibility against the need to move forward.
Non-ambiguous addresses (the replacement direction, e.g., Unique Local IPv6 Unicast Addresses) solve most developer pain by eliminating the need to manage site identifiers, allowing applications to treat addresses like regular global addresses and leaving interface selection to the stack.
Site-local addresses are deprecated primarily because of address ambiguity: FEC0::1 can exist in multiple sites simultaneously with no indication of which site it belongs to, causing developer, router, and management pain. The concept of 'site' itself is ill-defined with no consensus definition.
The 'site' concept is ill-defined: it may map to security, reachability, routing, QoS, administrative, or funding boundaries, and scope cannot be mapped into concentric circles because scopes overlap and extend into one another, especially with mobile nodes, VPNs, and network merges.
Multi-homed and mobile hosts face particular difficulty with site-local addresses because the required scope identifier (e.g., %1 or %2) varies per host instantiation and cannot be stored in memory or learned from DNS.
Multi-party applications that pass IP addresses at the application layer cannot safely use site-local addresses because they have no way of knowing where those addresses will eventually be forwarded, potentially causing connections to wrong nodes or unexpected failures.
References to site-local addresses should be removed from RFC 3484 (Default Address Selection), RFC 3493 (Socket Interface Extensions for IPv6), and RFC 3513 (IPv6 Addressing Architecture) as soon as practical in their revisions.
Existing implementations and deployments MAY continue to use the FEC0::/10 prefix, so deprecation does not force immediate removal from operational networks.
Router implementations SHOULD be configured to prevent routing of the FEC0::/10 prefix by default.
The FEC0::/10 prefix MUST NOT be reassigned for other use except by a future IETF standards action.
The special behavior of the FEC0::/10 site-local unicast prefix MUST no longer be supported in new implementations.
IPv6 site-local unicast addresses use the FEC0::/10 prefix (binary 1111111011), as defined in RFC 3513 section 2.5.6. This document formally deprecates this prefix.
IANA is requested to mark the FEC0::/10 prefix as 'deprecated' in the IPv6 address registry, pointing to this document. Reassignment requires an IETF Standards Action per RFC 2434.
Ambiguous site-local addresses can adversely affect network security through leaks, misrouting, and ambiguity. Deprecating them helps solve many of these problems. Blocking rules that previously relied on the FEC0::/10 prefix can be reconfigured for any replacement prefix, so deprecation does not inherently endanger security.