| Internet-Draft | ipv6-addr-selection-updates | September 2026 |
| Martin, et al. | Expires 16 March 2027 | [Page] |
This document updates RFC 6724 with three improvements to IPv6 destination
address selection. The updates allow recent IPv6 connection or service
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, 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 16 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 or service 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. 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 or service-establishment 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.¶
Service: The transport and port and, when available, higher-layer protocol
or service-binding information associated with an attempt. For example, the
service can be represented as TCP/443, HTTPS/TCP/443, or
HTTPS/h3/QUIC/443. Happy Eyeballs Version 3 [HAPPY-HEV3] similarly extends
connection establishment beyond transport-only information when such service
information is available.¶
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 component that determines that an IPv6 connection or service-establishment attempt has failed creates or refreshes a recent-failure record. The logical record contains the following fields:¶
| Field | Example |
|---|---|
| Network context | Corp-WiFi-A |
| IPv6 destination | 2001:db8:1234:5678::42 |
| IPv6 source | 2001:db8:1111::123 |
| Service | TCP/443 |
| Failure type | timeout |
| Timestamp | 2026-09-07T14:32:18+02:00 |
The first four fields identify the scope to which the observation applies. An
entry is applicable when its network context, IPv6 destination, IPv6 source,
and service match the current candidate as far as those fields are known. The
IPv6 source and Service fields SHOULD be recorded when available. The
Service field can contain only transport-level information or can include
higher-layer protocol or service-binding information when available.¶
A failed attempt to establish a usable instance of the identified service, such as a timeout, unreachable indication, connection refusal, or an applicable higher-layer establishment failure, creates or refreshes recent-failure state. Local API or resource errors unrelated to the attempted IPv6 communication do not. No active probing or measurement of RTT, packet loss, throughput, or other performance statistics is required.¶
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 service 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 consider the
likely source address that would be used for each candidate destination,
not only the destination in isolation. Ordering SHOULD prefer
source/destination pairs that are more likely to succeed or perform well.
This update aligns with the implementation architecture described in
[RFC6724], where getaddrinfo() may obtain source-address information when
sorting destinations. [GET-ADDR-PAIRS] demonstrates a prototype approach.¶
TODO: Normative text for pair evaluation and interaction with existing Rules 2, 5, and 9.¶
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 or
service-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, implementations MUST behave as [RFC6724].¶
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 or service-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, services, 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.¶