Default Address Selection for Internet Protocol Version 6 (IPv6)
obsoletes
- rfc-3484 — Default Address Selection for Internet Protocol version 6 (IPv6)
Extracted elements (30)
6to4 (2002::/16) was depreferenced below native IPv4 because 6to4 connectivity is less reliable today and expected to be phased out. It remains above Teredo (2001::/32) because 6to4 is more efficient in connection establishment time, bandwidth, and server load.
CommonPrefixLen was changed from RFC 3484 to compare only bits up to the source address's prefix length, excluding the interface ID. The prior definition caused matching interface-ID bits to override DNS load balancing by always selecting the destination sharing the most bits with the source.
RFC 1918 private addresses were changed from site-local to global scope to match existing implementation practice. The site-local mapping caused Destination Rule 2 (prefer matching scope) to inappropriately prefer IPv6 over IPv4 in mixed NAT scenarios, making the behavior non-configurable via the policy table.
Rule 5.5 (prefer addresses from a prefix advertised by the next-hop) was added to improve connectivity in the presence of BCP 38 ingress filtering. It is optional because the IPv6 conceptual host model does not require tracking which next-hops advertised which prefixes.
The default for Source Address Selection Rule 7 was changed to prefer temporary addresses over public addresses, reflecting increasing privacy importance and the fact that widely deployed implementations have used this default for years without major application compatibility issues. Implementations where compatibility outweighs privacy MAY reverse the default.
The default policy table gives IPv6 higher precedence than IPv4 (::ffff:0:0/96 at precedence 35 vs ::/0 at 40), making applications prefer IPv6 when equally suitable. An administrator can reverse this by raising ::ffff:0:0/96 to precedence 100, which is the recommended fix for environments needing IPv4 preference.
In dual-stack implementations, a simple policy to always prefer IPv6 or always prefer IPv4 produces poor behavior. The destination address selection algorithm provides a unified procedure that selects IPv6 or IPv4 based on available source addresses — e.g., preferring IPv4 when only a link-local IPv6 source but a global IPv4 source is available.
The longest-matching-prefix heuristic is inadequate in multi-homed sites with multiple ISPs. Policy table configuration using distinct labels for each ISP's prefix achieves the desired traffic engineering; the default rules alone cannot solve this case.
Well-behaved applications SHOULD NOT simply use the first address returned from getaddrinfo() and give up on failure. Applications should iterate through the returned list or try multiple addresses in parallel with a small delay.
When a host has a global IPv6 address but broken IPv6 connectivity, the default preference for IPv6 causes unwanted timeouts. Administrators can configure the policy table to prefer IPv4; implementations MAY do this automatically when they detect lack of IPv6 Internet connectivity, or treat it as part of Rule 1 (avoid unusable destinations).
Any rows automatically added by an implementation as a result of address acquisition MUST NOT override a row for the same prefix configured via other means; rows can be added automatically but never updated automatically.
For all multicast and link-local destination addresses, the candidate source address set MUST only include addresses assigned to interfaces on the same link as the outgoing interface. For site-local unicast destinations, the candidate set MUST only include same-site addresses. Multicast addresses and the unspecified address MUST NOT be included in any candidate set.
For destination address selection, IPv4 addresses MUST be represented as IPv4-mapped addresses. IPv4 addresses MUST be treated as having 'preferred' (RFC 4862) configuration status. IPv4 auto-configuration (169.254/16) and loopback (127/8) addresses are assigned link-local scope; all other IPv4 addresses are assigned global scope.
If an application specifies a source address not in the candidate set for the destination, the network layer MUST treat this as an error. If the application specifies a source address that is in the candidate set, the network layer MUST respect that choice.
If an implementation uses cached or potentially stale information in destination address selection, it MUST ensure that the ordering returned to the application is no more than one second out of date.
Implementations MUST provide a mechanism allowing an application to reverse the preference for temporary addresses over public addresses (Rule 7). There SHOULD be an administrative Privacy Preference flag; if absent, there MUST be an administrative option to disable temporary addresses entirely.
Implementations supporting home addresses MUST provide a mechanism allowing an application to reverse the preference for home addresses over care-of addresses. Use of this mechanism MUST only affect selection rules for the invoking application.
IPv4-compatible, IPv4-mapped, IPv4-converted, IPv4-translatable, and 6to4 addresses MUST be treated as having global scope. IPv4-compatible, IPv4-mapped, and IPv4-converted addresses MUST be treated as having 'preferred' configuration status.
IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined here. Implementations SHOULD provide an Automatic Row Additions flag allowing administrators to disable automatic addition of site-specific rows.
It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination (the 'outgoing' interface). On routers, the candidate set MAY include unicast addresses assigned to any forwarding interface.
On IPv6-only nodes supporting SIIT (RFC 6145), if the destination address is an IPv4-converted address, the candidate source address set MUST contain only IPv4-translatable addresses.
The IPv6 loopback address MUST be treated as having link-local scope and 'preferred' configuration status. NSAP addresses and other addresses with undefined format prefixes MUST be treated as having global scope and 'preferred' status.
The selection rules specified in this document MUST NOT be construed to override an application or upper layer's explicit choice of a legal destination or source address.
CommonPrefixLen(S, D) is defined as the length of the longest common prefix between source S and destination D, capped at the length of S's prefix (excluding the interface ID). For example, CommonPrefixLen(fe80::1, fe80::2) is 64.
The policy table is a longest-matching-prefix lookup table producing two values for a given address: a precedence value Precedence(A) used to sort destination addresses, and a label value Label(A) used to prefer source/destination pairs with matching labels. The default table assigns precedence 50 to ::1/128, 40 to ::/0, 35 to ::ffff:0:0/96 (IPv4-mapped), 30 to 2002::/16 (6to4), 5 to 2001::/32 (Teredo), and lower values to ULAs and deprecated prefixes.
Administrative options for address selection rules MUST be secured against illicit modification; otherwise an attacker could redirect and/or block traffic by altering the policy table.
Source address selection exposes a privacy concern: an unfriendly node can infer correlations among a target's addresses by probing it with requests that force source address selection for replies. The default preference for temporary addresses (Rule 7) helps mitigate this.
Source and destination address selection algorithms influence the network path taken, and hence whether data traverses more or less trusted paths. Administrators should consider the security impact of rows they configure in the prefix policy table, analogously to route metrics.
Destination address selection applies 10 pair-wise comparison rules in order: (1) avoid unusable destinations, (2) prefer matching scope, (3) avoid deprecated source, (4) prefer home addresses, (5) prefer matching label, (6) prefer higher precedence, (7) prefer native transport over encapsulating mechanisms, (8) prefer smaller scope, (9) use longest matching prefix (same address family), (10) preserve original order. Rules MUST be applied in order; a rule that determines a result means remaining rules MUST be ignored.
Source address selection applies 8 pair-wise comparison rules in order: (1) prefer same address, (2) prefer appropriate scope, (3) avoid deprecated addresses, (4) prefer home addresses, (5) prefer outgoing interface, (5.5) prefer addresses from a prefix advertised by the next-hop, (6) prefer matching label, (7) prefer temporary addresses, (8) use longest matching prefix. If all 8 rules tie, the tiebreaker is implementation-specific.