Enhanced Dual Stack: Automatic IPv6/IPv4 Selection Based on Performance
draft-xiao-v6ops-eds-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | XiPeng Xiao | ||
| Last updated | 2026-06-23 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-xiao-v6ops-eds-00
Network Working Group X. Xiao
Internet-Draft Huawei Technologies Dusseldorf
Intended status: Informational 23 June 2026
Expires: 22 December 2026
Enhanced Dual Stack: Automatic IPv6/IPv4 Selection Based on Performance
draft-xiao-v6ops-eds-00
Abstract
This document describes Enhanced Dual Stack (EDS), a host-side
framework intended to reduce the operational risk and workload of
IPv6 deployment.
Today, many applications select IPv6 or IPv4 using
static address-selection rules. These rules provide a useful
baseline, but they are not live measurements of current reachability
or performance. If IPv6 is selected when it is broken or degraded,
users may experience failures or delays. This creates a need for
extensive upfront IPv6 validation before deployment.
Happy Eyeballs (HE) reduces this risk for applications that implement
it, but it does not automatically help existing applications that
continue to use traditional APIs such as getaddrinfo(), socket(), and
connect().
EDS aims to make IPv6/IPv4 selection performance-informed for both
new and existing applications. It does this through three
enhancements:
1. An OS/platform HEv3 implementation profile.
2. Selective operational diagnostics.
3. A compatibility path for existing applications.
With Enhancements 1 and 3, a broad class of existing applications can
reduce repeated user-visible degradation caused by impaired IPv6
paths. The associated upfront IPv6 validation can focus mainly on
residual critical applications that do not benefit from EDS. With
Enhancement 2, network administrators can identify IPv6 problems and
fix them over time.
EDS changes IPv6 deployment from a high-risk, upfront project to a
more gradual and evidence-driven operational improvement process.
Xiao Expires 22 December 2026 [Page 1]
Internet-Draft Enhanced Dual Stack June 2026
Status of This Memo
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 22 December 2026.
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Enhanced Dual Stack Framework . . . . . . . . . . . . . . . . 4
3.1. OS/Platform HEv3 Implementation Profile . . . . . . . . . 4
3.2. Selective Operational Diagnostics . . . . . . . . . . . . 4
3.3. Compatibility Path for Existing Applications . . . . . . 5
4. EDS Deployment Model . . . . . . . . . . . . . . . . . . . . 7
5. Limitations and Workarounds . . . . . . . . . . . . . . . . . 8
6. Standardization Considerations . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Xiao Expires 22 December 2026 [Page 2]
Internet-Draft Enhanced Dual Stack June 2026
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Enterprise IPv6 deployment considerations are described in [RFC7381].
The amount of work required to prepare for and validate IPv6
deployment can appear large. This mainly results from the need to
ensure that enabling IPv6 does not create user-visible failures or
delays. The underlying reason is as follows. Applications commonly
use getaddrinfo() [RFC3493], socket(), and connect() to establish
communication with a destination. getaddrinfo() returns an ordered
list of destination addresses, socket() creates a local communication
endpoint, and connect() attempts to establish communication with one
selected destination. Default address-selection rules, including
[RFC6724], provide useful interoperability and policy control.
However, these rules are not live measurements of current
reachability or performance on a particular host, network,
destination, interface, or time period. IPv6 can therefore be
selected even when it is broken or degraded, causing failures,
delays, or poor application performance. To reduce this risk,
network administrators often feel that they must validate IPv6
extensively before enabling it broadly. Happy Eyeballs Version 2
(HEv2) [RFC8305] and Happy Eyeballs Version 3 (HEv3) [HEv3] reduce
user-visible delay by resolving DNS information asynchronously,
sorting candidates, and using staggered connection attempts. HEv3
also supports SVCB and HTTPS resource records [RFC9460]. However,
HEv3 does not by itself substantially reduce the required pre-
deployment validation effort: 1. HEv3 does not define an OS/platform
implementation profile. When an application implements HEv3
independently, other applications on the same host do not
automatically benefit. Such applications may still select IPv6 when
it is broken, creating a need for validation. 2. HEv3 can fall back
to IPv4 without necessarily providing operational information that
helps a network administrator identify the reason for IPv6 failure or
degradation. 3. Many existing applications use traditional resolver
and socket APIs, such as getaddrinfo(), rather than an HEv3-capable
networking facility. They therefore cannot automatically obtain
HEv3-style connection racing. EDS addresses these gaps by making
IPv6/IPv4 selection performance-informed for a broader set of
applications. ## 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Xiao Expires 22 December 2026 [Page 3]
Internet-Draft Enhanced Dual Stack June 2026
2. Terminology
Enhanced Dual Stack (EDS): A host-side dual-stack framework that
uses local policy and recent local performance observations to
improve IPv6/IPv4 selection.
OS/platform HEv3 implementation profile: A model in which HEv3
behavior is implemented by the operating system, a platform
networking library, or another common host networking function, so
that applications can benefit from HEv3 behavior without each
application implementing HEv3 independently.
Operational Diagnostics: Selected local information about address
selection, connection attempts, IPv4 fallback, and related host
behavior. It is exposed subject to local policy and privacy
constraints to help network administrators diagnose IPv6
reachability and performance problems.
3. Enhanced Dual Stack Framework
EDS provides a framework for making IPv6/IPv4 selection performance-
informed across both existing and new applications.
The framework consists of three complementary enhancements:
1. An OS/platform HEv3 implementation profile.
2. Selective operational diagnostics.
3. A compatibility path for existing applications.
3.1. OS/Platform HEv3 Implementation Profile
HEv3 specifies client behavior but does not prescribe the
implementation location. It can be implemented by applications,
application libraries, operating systems, platform networking
libraries, or other common host networking functions.
For the EDS deployment model, an OS/platform implementation is
important because applications using a common host networking
facility can benefit from HEv3 behavior without each application
independently implementing DNS resolution, candidate sorting,
staggered connection attempts, and connection racing.
3.2. Selective Operational Diagnostics
EDS is intended not only to reduce user-visible deployment risk, but
also to help network administrators improve IPv6 over time.
Xiao Expires 22 December 2026 [Page 4]
Internet-Draft Enhanced Dual Stack June 2026
An EDS-capable host or platform SHOULD make selected diagnostic
information available to authorized network administrators,
applications, or management systems, subject to local policy and
privacy constraints.
At a minimum, such diagnostic information SHOULD make it possible to
determine:
* Whether IPv6 was selected, attempted, bypassed, or deprioritized.
* Whether IPv4 was used because IPv6 failed, did not become usable
before another candidate, was deprioritized based on previous
local observations, or was selected by explicit policy.
* Whether the decision was based on a current connection attempt,
previous local observations, policy, or insufficient information.
* The destination and local network context associated with repeated
IPv6 problems, subject to privacy constraints.
Related Happy Eyeballs reporting considerations are described in
[HE-REPORT]. If an HEv3 reporting mechanism is specified, EDS
implementations can use that mechanism where appropriate.
3.3. Compatibility Path for Existing Applications
Many existing applications use getaddrinfo(), socket(), and
connect(). These applications cannot be expected to change quickly.
EDS therefore includes a compatibility path that improves host
behavior while preserving existing APIs and application semantics.
These traditional resolver and socket APIs are available across Unix-
like systems, Windows, Apple platforms, and Android. Therefore,
enhancements to them can cover a broad class of existing
applications.
The compatibility path does not provide real-time IPv6/IPv4 racing.
Instead, it allows the OS or platform to learn from previous
connection attempts and use applicable recent observations when
ordering future IPv6 and IPv4 destination addresses. This is done
through two OS/platform improvements:
1. Improved getaddrinfo() behavior
The OS or platform can use configured policy, [RFC6724], and
applicable recent local observations when ordering IPv6 and IPv4
destination addresses.
Xiao Expires 22 December 2026 [Page 5]
Internet-Draft Enhanced Dual Stack June 2026
If no applicable observations exist, getaddrinfo() behaves as it
does today. Therefore, the first connection to a destination can
still select IPv6 and experience delay or failure before the
application retries IPv4, if it retries at all.
After relevant observations have been learned, later connection
attempts can avoid repeatedly preferring an IPv6 path that
recently failed or performed poorly.
When ordering destination addresses, the OS or platform MAY
internally consider the source-destination address pair that
would likely be selected for each candidate. This can obtain
some benefits of [GET-ADDR-PAIRS] without requiring applications
to change source code to adopt the new API proposed by
[GET-ADDR-PAIRS].
For QUIC implementations that use the system resolver, improved
getaddrinfo() behavior can similarly improve IPv6/IPv4 address
ordering.
2. Improved connect() behavior
The OS or platform can record the final outcome of connection
establishment attempts and, where available, relevant lifetime
connection-performance information. Such information can include
whether a connection became usable, failed or timed out, or
showed repeated degradation after establishment. Where
available, it can also include an expected RTT for a successful
path.
For QUIC, a UDP connect() operation does not indicate whether the
QUIC connection or handshake succeeded, or provide QUIC lifetime
performance information. Therefore, an equivalent mechanism is
needed in the relevant platform QUIC API or QUIC library to
provide such observations.
One possible format for a local Connection Performance Cache is:
* Index key: destination IP address, protocol or service,
outgoing interface or network context, and, where relevant,
source prefix.
* Value: connection-performance outcome and, where available,
RTT.
This information can be used when ordering IPv6 and IPv4
destination candidates.
Xiao Expires 22 December 2026 [Page 6]
Internet-Draft Enhanced Dual Stack June 2026
The OS or platform can retain such observations for a limited time
and use them only when they apply to the new connection attempt. The
method used to store, age, scope, and look up these observations is
implementation-specific.
Applications are not required to supply the outgoing interface or
network context. The OS or platform can determine relevant context
from locally available information, such as route lookup, source-
address selection, interface binding, and VPN state.
The compatibility path MUST NOT override explicit administrative,
application, routing, or security policy.
4. EDS Deployment Model
When EDS is implemented by operating systems and platform networking
libraries, many existing applications using the traditional resolver
and socket path do not need source-code changes to benefit from
improved IPv6/IPv4 address ordering and learning from previous
connection attempts.
For enterprises, EDS changes the deployment model from:
Validate everything before enabling IPv6.
to:
Enable IPv6 with reduced user-visible risk, observe where IPv6
problems occur, and fix them over time.
A possible EDS deployment sequence is:
1. Upgrade to an EDS-aware OS or platform.
2. Perform as much IPv6 validation as practical, focusing on
critical applications that do not benefit from EDS.
Alternatively, keep hosts with such applications in an IPv4-only
environment until sufficient IPv6 experience has been obtained.
3. Enable IPv6 with EDS.
4. Monitor where IPv6 is used and where IPv4 fallback occurs.
5. Fix IPv6 problems over time, and witness the percentage of IPv6
traffic grows.
6. Migrate selected environments toward IPv6-mostly or IPv6-only
when appropriate.
Xiao Expires 22 December 2026 [Page 7]
Internet-Draft Enhanced Dual Stack June 2026
5. Limitations and Workarounds
EDS has several limitations.
First, the compatibility path does not provide real-time connection
racing like HEv3. It uses configured policy and applicable
historical performance observations. When no applicable performance
data exist, the first legacy connection can still suffer delay or
failure before the application retries IPv4. Later connections can
use applicable observations from the first attempt to avoid
repeatedly preferring a recently failing or degraded IPv6 path. This
can significantly reduce repeated user-visible degradation that can
happen without EDS.
Second, although HEv3 and the EDS compatibility path can cover a
broad class of applications, coverage may not be universal.
Applications that do not use an HEv3-capable or other EDS-integrated
networking facility may require additional measures. Two approaches
can help accommodate these applications during IPv6 deployment:
* Focus upfront IPv6 validation on these applications to ensure that
IPv6 works properly for them.
* Keep hosts with such applications in an IPv4-only environment,
such as an IPv4-only VLAN, during the early stage of IPv6 rollout.
Once network administrators use diagnostics to fix known IPv6
problems and gain sufficient confidence, they can migrate these hosts
to an IPv6-enabled environment. This step-by-step approach can make
the workload and risk more manageable.
Third, lifetime connection-performance information can be obtained
from the OS for TCP, but it may be unavailable for other transport
protocols, especially when transport behavior is implemented entirely
in user space. Obtaining lifetime connection-performance information
for such transport protocols requires case-by-case treatment. The
implementation decision is left to the developers. If such
information is unavailable, IPv6/IPv4 ordering can be based only on
connection-establishment outcome, which is still better than the case
without EDS.
6. Standardization Considerations
EDS may require work in multiple IETF Working Groups.
Xiao Expires 22 December 2026 [Page 8]
Internet-Draft Enhanced Dual Stack June 2026
The OS/platform HEv3 implementation profile and selective operational
diagnostics are closely related to HEv3 behavior and could be
developed in the HAPPY Working Group as extensions to, or companion
documents for, HEv3.
The compatibility behavior affecting getaddrinfo() and connect()
would likely require work in the 6man Working Group, or another
appropriate IETF venue, and coordination with operating-system and
platform networking implementers.
This document does not define new APIs or a mandatory storage model
for local performance observations. Its purpose is to identify the
required functions and their relationship to one another.
7. Security Considerations
EDS incorporates HEv3 behavior where available. The security
considerations of [HEv3] apply to EDS.
In the compatibility path, local observations and operational
diagnostics can contain sensitive information about destination
usage, failure patterns, interfaces, network context, and transport
behavior. Access to this information MUST be controlled, and
exported information MUST be minimized and protected. Telemetry
export, if supported, MUST be controlled by local policy.
8. IANA Considerations
This document makes no request of IANA.
9. References
9.1. Normative References
[HEv3] Pauly, T., Schinazi, D., Jaju, N., and K. Ishibashi,
"Happy Eyeballs Version 3: Better Connectivity Using
Concurrency", Work in Progress, Internet-Draft, draft-
ietf-happy-happyeyeballs-v3-03, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-happy-
happyeyeballs-v3-03>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
Xiao Expires 22 December 2026 [Page 9]
Internet-Draft Enhanced Dual Stack June 2026
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/rfc/rfc6724>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
9.2. Informative References
[GET-ADDR-PAIRS]
Carpenter, B., "Get Address Pairs for Socket Programming
in Python", GitHub Repository,
<https://github.com/becarpenter/getapr>.
[HE-REPORT]
Martinez, J. P. and P. S. Tiesel, "Considerations for
Happy Eyeballs Error Reporting", Work in Progress,
Internet-Draft, draft-palet-happy-reporting-
considerations-01, 18 June 2026,
<https://datatracker.ietf.org/doc/html/draft-palet-happy-
reporting-considerations-01>.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6",
RFC 3493, DOI 10.17487/RFC3493, March 2003,
<https://www.rfc-editor.org/rfc/rfc3493>.
[RFC7381] Chittimaneni, K., Chown, T., Howard, L., Kuarsingh, V.,
Pouffary, Y., and E. Vyncke, "Enterprise IPv6 Deployment
Guidelines", RFC 7381, DOI 10.17487/RFC7381, October 2014,
<https://www.rfc-editor.org/rfc/rfc7381>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/rfc/rfc8305>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.
Xiao Expires 22 December 2026 [Page 10]
Internet-Draft Enhanced Dual Stack June 2026
Acknowledgements
Brian Carpenter and Nick Buraglio contributed the get_addr_pairs()
source-destination address-pair selection model discussed as related
work in earlier versions of this work. Their feedback also helped
shape the distinction between the compatibility path for existing
applications and HEv3-based behavior for new or modified
applications.
Comments from David Schinazi and Tim Chown led to revisions and
improvements of this draft.
Author's Address
Xipeng Xiao
Huawei Technologies Dusseldorf
Email: xipengxiao@gmail.com
Xiao Expires 22 December 2026 [Page 11]