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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . 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, . [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 [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, . 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]