Updates to IPv6 Default Address Selection

Introduction defines default source and destination address selection for IPv6 and dual-stack hosts. Operational experience has identified cases where additional information available to a host or operator can improve destination ordering. In particular, Section 10.3.1 of notes that a host with working IPv4 connectivity but broken IPv6 connectivity can experience unwanted timeouts because the default policy normally prefers IPv6. This document specifies three updates addressing recent IPv6 connection failures, source/destination address-pair considerations, and DNS-based load balancing. The implementations described in this document are believed to benefit operators in their IPv6 deployments and IPv4 retirement.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Motivation Applications commonly use getaddrinfo() to obtain an ordered list of destination addresses. defines the default destination address selection algorithm that implementations apply when sorting that list. The rules provide useful interoperability and policy control on the global Internet, but three operational gaps have emerged:

Connectivity: Static precedence can continue to prefer IPv6 after an IPv6 connection-establishment attempt has recently failed. Happy Eyeballs reduces the impact for applications that race IPv6 and IPv4 attempts, but other applications can repeatedly experience the same failure or delay.
Address pairs: Sorting destinations without considering the likely source/destination pair can yield suboptimal or incorrect connectivity, especially when multiple source addresses are available.
DNS load balancing: Operators commonly spread load by returning multiple address records and varying their order---DNS-based load balancing as described in . Rule 9 ("Use longest matching prefix") can collapse that intentionally varied order to a single preferred destination, defeating the operator's intent. DNS and routing communities have offered conflicting advice on whether resolver ordering or DNS response order should prevail; this document closes that gap for configured deployments.

Scope This document is a focused update to destination address selection (Section 6 of ). Source address selection (Section 5) is out of scope except where needed to evaluate source/destination pairs for destination ordering.

Design Principle The three enhancements are OPTIONAL, independent, and individually configurable. Implementations MUST NOT enable any of them by default, and enabling one enhancement MUST NOT implicitly enable another, so current behavior is preserved without deliberate administrative input. The enhancements SHOULD be implementable inside getaddrinfo() or an equivalent system resolver mechanism and, for connectivity-informed destination selection, in transport connection-establishment mechanisms such as connect() for TCP and the corresponding mechanism for QUIC. This document does not require changes to existing application-facing socket APIs or application source code. Experimental evidence for address-pair-aware ordering appears in .

Related Work updates by revising the default address selection policy table, elevating preference for known-local Unique Local Addresses (ULAs), and making Rule 5.5 a requirement. That work addresses static policy and local ULA preference for common dual-stack deployments. This document does not change ULA policy-table defaults or Rule 5.5. It specifies optional destination-selection enhancements---connectivity-informed Rule 6 behavior, source/destination pair consideration, and an operator- controlled exception to Rule 9 for DNS-based load balancing---that are independent of, and complementary to, the policy-table and known-local ULA updates in .

Terminology Destination address selection: The process by which a host orders candidate destination addresses before returning them to an application, as defined in . Address pair: A combination of a selected or likely source address and a candidate destination address used to evaluate connectivity or ordering for a given communication attempt. Recent-failure state: Host-local state recording a recent IPv6 connection failure that can be consulted by destination address selection. Network context: Information identifying the network environment in which a connection attempt is made, such as the outgoing interface, network attachment, VPN, or equivalent implementation-specific context.

Updates to RFC6724 This section specifies updates to destination address selection in .

Connectivity-Informed Destination Selection Connectivity-informed destination address selection is enabled by updating Rule 6 of from "Prefer higher precedence" to "Prefer higher precedence unless recently failed". The updated rule is:

Rule 6: Prefer higher precedence unless recently failed. When exactly one of DA and DB is an IPv6 destination and the other is an IPv4 destination, if applicable recent-failure state exists for the IPv6 destination, prefer the IPv4 destination. Otherwise, if Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if Precedence(DA) < Precedence(DB), then prefer DB.

When this enhancement is enabled, the OS or platform transport connection-establishment implementations, such as connect() for TCP and the corresponding mechanism for QUIC, MUST create or refresh records in a Recent IPv6 Failure Table, or equivalent host-local state, for applicable IPv6 connection-establishment failures that they directly observe.

Field	Example
Network context	Corp-WiFi-A
IPv6 destination address	2001:db8:1234:5678::42
IPv6 source prefix or address	2001:db8:1111:1200::/56
Transport protocol and port	TCP/443
Failure type	timeout
Timestamp	2026-09-07T14:32:18+02:00

The IPv6 destination field contains the IPv6 destination address selected for the failed attempt. The IPv6 source field SHOULD contain the locally known prefix associated with the IPv6 source address selected for that attempt. The associated prefix length can be obtained from the host's interface-address configuration for the selected source address. If no applicable source prefix is known, the complete IPv6 source address SHOULD be used instead. An implementation MUST NOT infer a prefix length solely from the IPv6 address value. The asymmetry is intentional. A failure may be specific to an individual destination, so the destination is recorded as an address. On the source side, multiple source addresses, including temporary addresses, can belong to the same locally known prefix. Recording the source prefix when available keeps the failure state applicable across such source-address changes without unnecessarily creating separate state for each source address. The first four fields identify the scope to which the observation applies. An entry is applicable when its network context, IPv6 destination address, IPv6 source prefix or address, and transport protocol and port match the current candidate as far as those fields are known. For an IPv6 source prefix, the selected source address for the current candidate MUST belong to that prefix; for an IPv6 source address, it MUST match that address. Applicable failure types include timeout, unreachable, refusal, or reset. Recent-failure state SHOULD expire 10 minutes after the most recent applicable failure. This interval follows the stateful Happy Eyeballs guidance in Section 4.2 of , which recommends retrying a failed preferred address family every 10 minutes and notes that this can be implemented by flushing state every 10 minutes. Implementations MAY make the interval configurable. A subsequent successful establishment of the same connection over the same applicable IPv6 context SHOULD clear the state, and a relevant network-context change SHOULD make the state inapplicable. In the absence of applicable recent-failure state, Rule 6 behaves as specified in , so IPv6 retains its normal default preference. This enhancement changes destination ordering only; it does not remove IPv6 addresses from the candidate list. Happy Eyeballs and other connection-racing mechanisms can therefore continue to attempt both address families. Implementations MAY expose recent-failure information to network-management systems for aggregation and operational diagnosis, as discussed in .

Source/Destination Pair Consideration When sorting destination addresses, implementations SHOULD determine the source address that would be used for each candidate destination, not only the destination in isolation. This will require an operating system dependent mechanism. Destination address ordering SHOULD then prefer source/destination pairs that are more likely to succeed or perform well. This ordering may depend on cached information from previous network operations and on techniques similar to those described in . This aligns with the implementation architecture described in , in particular the note at the end of Section 5 that an implementation may know 'which source address will result in the "best" communications performance' and a similar note at the end of Section 6. Thus getaddrinfo() may benefit from source-address information when sorting destinations. demonstrates a prototype approach. Section 9 of notes that the destination-first sorting model of is fundamentally limited and that ranking address pairs directly would be preferable, but treats that approach as beyond its scope. This enhancement addresses that deferred gap. It is orthogonal to known-local ULA insertion and to the updated default policy table in ; pair evaluation does not replace or require those policy-table changes. When this enhancement is enabled, any re-ordering based on source/destination pairs SHOULD be performed after all destination address selection rules in Section 6 of have been applied. However, any such re-ordering MUST NOT override Rules 1, 2, 3, or 8 (i.e., must not cause scope mismatches or choose an unreachable or deprecated address).

Preserving DNS Load-Balancing Order Operators who use DNS-based load balancing ---for example, multiple A or AAAA records whose order is rotated by the authoritative server---expect clients to try addresses in the order returned by DNS. Rule 9 reorders those candidates by longest matching prefix, which can concentrate traffic on one backend and undermine the operator's load-spreading intent. DNS operators and routing-oriented guidance have historically given conflicting advice on this point; this section standardizes operator-controlled behavior. Implementations MUST support administrative configuration of one or more IPv4 and IPv6 prefix ranges for which Rule 9 does not apply. This update does not itself change ordering across address families: Rules 1--8 continue to apply before Rule 9. If the enhancement in is enabled, Rule 6 is applied as updated there; otherwise Rule 6 remains as specified in . When Rule 9 would otherwise reorder candidates of the same address family, and a candidate destination address falls within a configured range, the implementation MUST preserve the order received from the name-resolution step (for example, the order of A or AAAA records in the DNS response) among those same-family candidates, rather than reordering them by longest matching prefix. This section does not introduce a new within-family sort order; it only prevents Rule 9 from overriding DNS response order for configured destinations. Configuration mechanisms MAY include a policy table, /etc/gai.conf, or an equivalent system resolver setting; no application changes are required.

Implementation and Deployment Considerations Implementations that apply these updates inside getaddrinfo() or an equivalent system mechanism preserve compatibility with existing applications that use the returned address ordering. For connectivity-informed selection, the implementation needs a mechanism to retain recent connection-establishment failures for later use by destination selection; no new application-facing API is required. Operators MAY use existing policy mechanisms such as /etc/gai.conf on glibc-based systems to influence precedence; however, such files alone do not fully disable Rule 9 today. The connectivity-informed enhancement does not require dynamic modification of the RFC 6724 policy table; the existing policy table continues to express address preference, while recent-failure state qualifies the Rule 6 preference when applicable. Backward compatibility on the global Internet MUST be preserved: with no operator configuration of this document's enhancements, implementations MUST behave as as updated by once that document is published (and as alone until then). Hosts that implement both this document and apply the updated policy table, including known-local ULA rows, as the baseline. When enabled, this document's enhancements further qualify destination ordering ---for example, temporary IPv4 preference after a recent IPv6 failure, skipping Rule 9 for configured prefixes, or pair-aware sorting---without replacing those policy-table defaults. This document is related to, but distinct from, the Enhanced Dual Stack (EDS) framework . EDS describes a broader host-side deployment model; this document normatively updates destination address selection rules.

Operational Diagnostics Implementations MAY emit recent-failure records defined in to a system logging or telemetry facility (for example, syslog ) as an aid to operational diagnosis. Such records SHOULD preserve the per-event fields defined in . Logging is independent of the recent-failure state used by Rule 6; expiration or clearing of that state does not require deletion of corresponding log messages. Retention, forwarding, filtering, and aggregation of these messages are matters of local policy and are outside the scope of this document. Operators MAY use existing log-management or network-management systems to collect and analyze them across hosts and time.

Security Considerations Recent-failure state influences address ordering and could temporarily cause IPv4 to be preferred over IPv6. Implementations SHOULD derive this state from connection-establishment outcomes observed locally by the host or a trusted host networking component, and SHOULD resist poisoning of ordering decisions from unauthenticated off-path input. The bounded lifetime specified in prevents a transient failure from suppressing the normal IPv6 preference indefinitely. Recent-failure records and aggregated diagnostics can reveal destinations, source addresses or prefixes, transport protocols and ports, network attachments and traffic patterns. Access to such information SHOULD be restricted to authorized entities, and exported information SHOULD be minimized according to operational need and protected according to local security and privacy policy.

IANA Considerations This document has no IANA actions.

Acknowledgements Discussion on the v6ops mailing list, including threads around Enhanced Dual Stack, helped shape the scope.