Network Working Group X. Xiao Internet-Draft Huawei Technologies Dusseldorf Intended status: Informational 4 July 2026 Expires: 5 January 2027 Enhanced Dual Stack: Automatic IPv6/IPv4 Selection Based on Performance draft-xiao-v6ops-eds-01 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 5 January 2027 [Page 1] Internet-Draft Enhanced Dual Stack July 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 5 January 2027. 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Enhanced Dual Stack Framework . . . . . . . . . . . . . . . . 5 3.1. OS/Platform HEv3 Implementation Profile . . . . . . . . . 5 3.2. Selective Operational Diagnostics . . . . . . . . . . . . 6 3.3. Compatibility Path for Existing Applications . . . . . . 6 4. Incremental EDS Deployment . . . . . . . . . . . . . . . . . 9 5. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Standardization Considerations . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 11 Xiao Expires 5 January 2027 [Page 2] Internet-Draft Enhanced Dual Stack July 2026 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 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 is intended to address these three gaps through an OS/platform HEv3 implementation profile, selective operational diagnostics, and a compatibility path for existing applications. Xiao Expires 5 January 2027 [Page 3] Internet-Draft Enhanced Dual Stack July 2026 1.1. 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. 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. Compatibility path for existing applications: A mechanism for non- racing resolver and connection-establishment facilities that uses applicable recent local performance observations to improve destination candidate ordering while preserving existing APIs and application semantics. EDS-capable host: A host on which an OS/platform HEv3 implementation profile, operational diagnostics, and a compatibility path for existing applications are each available. These capabilities can be provided by different implementations on the host and need not cover every application on the host. Partially EDS-capable host: A host on which one or two, but not all three, EDS enhancement categories are available. Such a host can still obtain useful EDS benefits for the applications using the available facilities, but has less complete coverage than an EDS- capable host. Non-EDS host: A host that has none of the EDS enhancement categories available. Xiao Expires 5 January 2027 [Page 4] Internet-Draft Enhanced Dual Stack July 2026 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 in the connection- establishment layer used by the application, including an operating- system networking framework, platform library, language runtime, browser stack, or application library. For the EDS deployment model, an OS/platform implementation is important because applications using such APIs can benefit from HEv3 behavior without having to explicitly implement HEv3. In general, when an operating system, platform networking facility, language runtime, browser stack, client library, or user-space transport implementation is invoked by applications with a hostname and controls candidate gathering and connection establishment, it SHOULD implement HEv3-style IPv6/IPv4 racing. This allows the applications that use that facility to benefit from HEv3 behavior without each application explicitly implementing HEv3. For example, an HTTP client library that receives a hostname from an application and creates the corresponding TCP connections can implement HEv3 behavior internally while preserving its existing application-facing API. By contrast, a resolver interface such as getaddrinfo() returns an ordered address list but does not control multiple connection attempts. It therefore cannot implement HEv3-style racing. However, it can still support applications that call it with performance-informed IPv6/IPv4 selection, as described in the "Compatibility Path" section below. Xiao Expires 5 January 2027 [Page 5] Internet-Draft Enhanced Dual Stack July 2026 The Transport Services (TAPS) architecture [RFC9621] and its abstract API [RFC9622] provide an asynchronous connection-establishment architecture: they combine name resolution with connection establishment and allow selection among multiple endpoints, paths, and transport protocols. TAPS can provide a long-term architectural basis for an OS/platform HEv3 implementation. However, TAPS does not by itself prescribe HEv3 behavior, and EDS does not require TAPS. 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. 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 resolver interfaces that return an ordered set of destination addresses and then use socket APIs to attempt connections sequentially, rather than performing real-time IPv6/IPv4 connection racing. getaddrinfo(), used with socket() and connect(), is an important and widely deployed example. Other examples include Java's InetAddress resolver APIs, such as InetAddress.getAllByName(), and asynchronous resolver libraries such as c-ares ares_getaddrinfo(). Xiao Expires 5 January 2027 [Page 6] Internet-Draft Enhanced Dual Stack July 2026 These applications cannot be expected to change quickly. EDS therefore includes a compatibility path that improves destination candidate ordering and records relevant connection observations 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. Using getaddrinfo() and connect() as an example, this is done through the following 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. 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 applicable IPv6 and IPv4 performance are sufficiently similar, local policy MAY retain a bounded preference for IPv6 by applying a threshold when ordering candidates. Such a preference MUST NOT exclude IPv4 candidates or otherwise prevent IPv4 fallback when IPv6 fails or is materially degraded. When ordering destination addresses, the OS or platform MAY internally consider the source/destination address pair that would likely be selected for each candidate in the current network context. More precisely, when ordering destination addresses returned by getaddrinfo(), the implementation can determine the source address that would normally be selected for each destination, taking account of the applicable route, interface, provisioning-domain, and VPN context, and take the resulting source/destination pair into account [GET-ADDR-PAIRS]. It can also take applicable performance observations for that Xiao Expires 5 January 2027 [Page 7] Internet-Draft Enhanced Dual Stack July 2026 pair into account. This prediction does not apply when an application explicitly binds or otherwise constrains its source address. In that case, the application's choice takes precedence. 2. Improved connect() behavior The OS or platform can record the outcome of transport connection establishment, such as success, failure, or timeout. Where the relevant transport stack or shared library can observe it, it can also record whether a connection became usable and relevant lifetime connection-performance information, such as repeated degradation after establishment or a measured RTT estimate. For QUIC, a UDP connect() operation does not indicate whether the QUIC connection or handshake succeeded, and does not provide QUIC lifetime performance information. Equivalent observations therefore need to be provided by the relevant QUIC library or platform QUIC API. One possible format for a local Connection Performance Cache is: * Index key: destination IP address and port or service, transport protocol, 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. 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. Xiao Expires 5 January 2027 [Page 8] Internet-Draft Enhanced Dual Stack July 2026 4. Incremental EDS Deployment 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. EDS does not require every host to be fully EDS-capable before IPv6 deployment can begin. An enterprise can divide its hosts into early- adopter hosts and critical hosts, and apply different deployment approaches to them. Early-adopter hosts can be partially EDS-capable. They can use any available HEv3-style racing, compatibility behavior, or operational diagnostics, while accepting a limited residual risk of user-visible IPv6 degradation during the initial phase. IPv6 can be enabled for these hosts first, and their observed connection outcomes, fallback behavior, and diagnostic information can help identify and correct IPv6 problems. Useful indicators to monitor include the proportion of IPv6 traffic, IPv4 fallback rate, and IPv6 connection-failure or degradation rate. These values need not change monotonically, but significant changes or persistent lack of IPv6 use should be explainable from observed destination, application, or network conditions. Critical hosts can remain in an IPv4-only environment during the initial phase when their important applications lack sufficient EDS coverage or when their business impact does not permit the residual risk accepted for early-adopter hosts. This can be done by placing them in an IPv4-only VLAN or by another applicable mechanism. Critical hosts can join the IPv6-enabled environment when they become EDS-capable, or when the enterprise has gained sufficient IPv6 operational experience and confidence to evaluate them in a controlled rollout. If necessary, an individual host or group of hosts can be returned to an IPv4-only environment temporarily until the problems are fixed. After stable operation has been demonstrated in IPv6-enabled environments, network administrators can begin migrating selected environments toward IPv6-mostly or IPv6-only operation where appropriate. Xiao Expires 5 January 2027 [Page 9] Internet-Draft Enhanced Dual Stack July 2026 5. Limitations EDS has several limitations. With incremental deployment, these limitations do not require an enterprise to delay IPv6 deployment for all hosts, but they can affect the host cohorts selected for rollout and the additional validation needed before critical hosts are migrated. 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. 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. 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. Xiao Expires 5 January 2027 [Page 10] Internet-Draft Enhanced Dual Stack July 2026 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-04, 1 July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 9.2. Informative References Xiao Expires 5 January 2027 [Page 11] Internet-Draft Enhanced Dual Stack July 2026 [GET-ADDR-PAIRS] Carpenter, B., "Get Address Pairs for Socket Programming in Python", GitHub Repository, . [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, . [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, . [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, . [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: Better Connectivity Using Concurrency", RFC 8305, DOI 10.17487/RFC8305, December 2017, . [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, . [RFC9621] Pauly, T., Ed., Trammell, B., Ed., Brunstrom, A., Fairhurst, G., and C. S. Perkins, "Architecture and Requirements for Transport Services", RFC 9621, DOI 10.17487/RFC9621, January 2025, . [RFC9622] Trammell, B., Ed., Welzl, M., Ed., Enghardt, R., Fairhurst, G., Kühlewind, M., Perkins, C. S., Tiesel, P.S., and T. Pauly, "An Abstract Application Programming Interface (API) for Transport Services", RFC 9622, DOI 10.17487/RFC9622, January 2025, . Xiao Expires 5 January 2027 [Page 12] Internet-Draft Enhanced Dual Stack July 2026 Acknowledgements Brian Carpenter and Nick Buraglio contributed to the [GET-ADDR-PAIRS]-related improvement. 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, Tim Chown, Philipp Tiesel, Franck Martin, Mike Ackermann, and Gert Doering led to revisions and improvements of this draft. Author's Address Xipeng Xiao Huawei Technologies Dusseldorf Email: xipengxiao@gmail.com Xiao Expires 5 January 2027 [Page 13]