| Internet-Draft | ipv6-addr-selection-updates | September 2026 |
| Martin, et al. | Expires 19 March 2027 | [Page] |
This document updates RFC 6724 with three improvements to IPv6 destination
address selection. The updates allow recent IPv6 connection
failures to influence IPv6/IPv4 ordering, incorporate likely
source/destination address pairs when sorting candidates, and let ISP and
enterprise operators preserve DNS load-balancing order where Rule 9 would
otherwise override it. The updates are intended to be implementable inside
getaddrinfo() or an equivalent system mechanism and, for connectivity-informed destination selection, in transport connection-establishment mechanisms such as connect() for TCP and the corresponding mechanism for QUIC, without requiring changes to existing application-facing socket APIs.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://github.com/franckhlmartin/ietf-draft-ipv6-addr-selection-updates/. An HTML editor's copy is at https://franckhlmartin.github.io/ietf-draft-ipv6-addr-selection-updates/draft-martin-ipv6-addr-selection-updates.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-martin-ipv6-addr-selection-updates/. Discussion of this document takes place on the v6ops Working Group mailing list (mailto:v6ops@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/v6ops/. Subscribe at https://www.ietf.org/mailman/listinfo/v6ops/. Working group assignment (v6ops versus 6man) is to be determined at adoption time.¶
Source for this draft and an issue tracker can be found at https://github.com/franckhlmartin/ietf-draft-ipv6-addr-selection-updates.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 March 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC6724] 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 [RFC6724] 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
Applications commonly use getaddrinfo() [POSIX] [RFC3493] to obtain an
ordered list of destination addresses. [RFC6724] 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:¶
This document is a focused update to destination address selection (Section 6 of [RFC6724]). Source address selection (Section 5) is out of scope except where needed to evaluate source/destination pairs for destination ordering.¶
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 [RFC6724] 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 [GET-ADDR-PAIRS].¶
Destination address selection: The process by which a host orders candidate destination addresses before returning them to an application, as defined in [RFC6724].¶
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.¶
This section specifies updates to destination address selection in [RFC6724].¶
Connectivity-informed destination address selection is enabled by updating Rule 6 of [RFC6724] 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 [RFC6555], 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 [RFC6724], 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 Section 4.1.¶
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 [RFC8305].
This aligns with the implementation architecture described in
[RFC6724], 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. [GET-ADDR-PAIRS] demonstrates a prototype approach.¶
Section 9 of [RFC6724-UPDATE] notes that the destination-first sorting model of [RFC6724] 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 [RFC6724-UPDATE]; 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 [RFC6724] 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).¶
Operators who use DNS-based load balancing [RFC1794]---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 Section 3.1 is
enabled, Rule 6 is applied as updated there; otherwise Rule 6 remains as
specified in [RFC6724]. 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.¶
Implementations that apply these updates inside getaddrinfo() [POSIX] [RFC3493] 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 [RFC6724] as updated by [RFC6724-UPDATE] once that document is published (and as [RFC6724] alone until then).¶
Hosts that implement both this document and [RFC6724-UPDATE] 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]. EDS describes a broader host-side deployment model; this document normatively updates destination address selection rules.¶
Implementations MAY emit recent-failure records defined in Section 3.1 to a system logging or telemetry facility (for example, syslog [RFC5424]) as an aid to operational diagnosis. Such records SHOULD preserve the per-event fields defined in Section 3.1. 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.¶
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 Section 3.1 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.¶
This document has no IANA actions.¶
Discussion on the v6ops mailing list, including threads around Enhanced Dual Stack, helped shape the scope.¶