Network Working Group X. Xiao Internet-Draft Huawei Technologies Dusseldorf Intended status: Informational 5 October 2026 Expires: 8 April 2027 Enhanced Dual Stack: Connectivity-Informed IPv6/IPv4 Selection draft-xiao-v6ops-eds-02 Abstract This document describes Enhanced Dual Stack (EDS), a framework intended to reduce the operational risk and upfront workload of introducing IPv6 into an existing IPv4 network. EDS consists of two complementary mechanisms. First, connectivity-informed destination selection updates Rule 6 of RFC 6724 Section 6 from "Prefer higher precedence" to "Prefer higher precedence unless recently failed", so that recently failed IPv6 connectivity is not repeatedly preferred over IPv4. Second, operational diagnostics provide information that helps network administrators understand why IPv6 was not used and identify problems that can be corrected over time. With these mechanisms, IPv6 deployment can move from extensive upfront validation toward practical upfront validation followed by gradual operational improvement. This simpler IPv6 introduction approach can enable enterprises that do not have much IPv6 expertise and do not need a large number of IP addresses provided by IPv6 to try IPv6. 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 8 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Xiao Expires 8 April 2027 [Page 1] Internet-Draft Enhanced Dual Stack October 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Enhanced Dual Stack Framework . . . . . . . . . . . . . . . . 4 4. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Standardization Considerations . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction [RFC6724], which replaced [RFC3484], defines the standard destination-address selection between IPv6 and IPv4 and recommends a default policy that gives IPv6 higher precedence than IPv4. Recent connection establishment failures are not explicitly incorporated into the selection rules, although RFC 6724 notes that an implementation MAY automatically detect broken IPv6 and adjust its behavior. IPv6 can therefore continue to be preferred even when the applicable IPv6 connectivity has recently failed, exposing users repeatedly to service degradation. To minimize user-visible disruption, IPv6 deployers must prevent IPv6 connection establishment failures as much as possible. This requires heavy upfront validation before switching on IPv6. The needed work is described in [RFC7381] and is substantial. Consequently, the organizations that have deployed IPv6 are usually big ISPs and enterprises that need a large number of IP addresses. Many other enterprises do not see sufficient benefits to justify the large amount of effort to migrate to IPv6. Unless an effort is made to simplify IPv6 introduction, these enterprises may remain in IPv4 for a long period of time. Xiao Expires 8 April 2027 [Page 2] Internet-Draft Enhanced Dual Stack October 2026 EDS is intended to simplify IPv6 introduction. It uses connectivity- informed destination selection so that IPv6 retains its normal preference when no applicable recent failure is known, but IPv4 can be preferred after an applicable IPv6 failure. EDS also provides operational diagnostics so that, when IPv6 is not used, network administrators can determine why and can fix the underlying IPv6 problems over time. This changes the deployment model. Instead of requiring exhaustive validation before IPv6 can be enabled, administrators can perform upfront validation as much as practical, enable IPv6 for suitable hosts or environments, observe remaining problems, and improve IPv6 progressively. The objective is to change IPv6 deployment from a heavily front-loaded and somewhat risky process into a gradual operational improvement process. In other words, EDS intends to mimic the effect of "Duolingo for language learning" for IPv6. Before Duolingo, language learners had to find a language class, enroll, pay, and then go to classes several times a week. This big upfront effort works for people who need to master a language quickly, but not for many casual learners. By making the start very easy and spreading the learning effort over time, Duolingo has brought millions more people to learn foreign languages. EDS intends to bring many more enterprises to use IPv6 by making the start easy and spreading the learning and improvement effort over time. In addition, just like Duolingo has not prevented people from going to language class, EDS will not prevent people from introducing IPv6 with existing approaches. EDS and existing IPv6 deployment approaches can be used by different types of organizations. Happy Eyeballs Version 2 [RFC8305] and Happy Eyeballs Version 3 [HEv3] serve a similar purpose by reducing the user-visible impact of IPv6/IPv4 connectivity problems through connection racing. However, their benefit applies where Happy Eyeballs is implemented. EDS instead updates the default destination-selection behavior defined by RFC 6724 and therefore is not limited to applications that implement Happy Eyeballs. The two approaches are complementary: HE can reduce the impact all the time, starting from the first try, for applications that implement HE, while EDS can prevent IPv6 from being repeatedly preferred on later selections after a recent failure, for all applications that use TCP or QUIC connections. Current HE specifications also do not define a standardized operator-facing diagnostic mechanism needed to explain why IPv6 was not used although related reporting work is being explored in [HE-REPORT], while EDS supports operational diagnostics. The Transport Services (TAPS) architecture [RFC9621] and its abstract API [RFC9622] provide an asynchronous connection establishment architecture that can select among multiple endpoints, paths, and Xiao Expires 8 April 2027 [Page 3] Internet-Draft Enhanced Dual Stack October 2026 transport protocols. TAPS can provide a long-term architectural basis for advanced connection establishment but TAPS does not help existing applications that do not support it. For EDS, TAPS is similar to HE. EDS is complementary to TAPS, as it is to HE, and does not require either TAPS or HE. 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 framework that combines connectivity- informed IPv6/IPv4 destination selection with operational diagnostics to reduce the risk and upfront workload of introducing IPv6. Connectivity-informed destination selection: Destination selection that takes applicable recent connection establishment failures into account. In the RFC 6724 update used by EDS, Rule 6 in Section 6 changes from "Prefer higher precedence." to "Prefer higher precedence unless recently failed." Recent-failure state: Short-lived local state indicating that an IPv6 connection establishment attempt recently failed for an applicable network context, destination address, source prefix or address, and transport protocol and port. Operational Diagnostics: Local information that helps an authorized network administrator determine why IPv6 was not used or why it failed, and identify problems that can be corrected over time. EDS-capable host: A host that supports connectivity-informed destination selection and can expose the corresponding operational diagnostic information. 3. Enhanced Dual Stack Framework ## Connectivity-informed Destination Selection EDS uses the RFC 6724 update specified in [ADDR-SELECT]. The key change is to update Rule 6 in Section 6 from "Prefer higher precedence" to "Prefer higher precedence unless recently failed." When there is no applicable recent-failure state, destination selection continues to follow the normal RFC 6724 precedence behavior, and suitable IPv6 destinations Xiao Expires 8 April 2027 [Page 4] Internet-Draft Enhanced Dual Stack October 2026 normally retain their preference over IPv4. When this enhancement is enabled, OS or platform transport connection establishment implementations, such as connect() for TCP and the corresponding mechanism for QUIC, 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. [ADDR-SELECT] defines the corresponding record and selection behavior. A typical record contains the following information: +===============================+===========================+ | 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-17T14:32:18+02:00 | +-------------------------------+---------------------------+ Table 1 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. Applicable failure types include timeout, unreachable, refusal, or reset. The recent-failure state is short-lived. [ADDR-SELECT] recommends expiration after 10 minutes, following the stateful Happy Eyeballs guidance in [RFC6555]. A subsequent successful establishment in the same applicable IPv6 context can Xiao Expires 8 April 2027 [Page 5] Internet-Draft Enhanced Dual Stack October 2026 clear the state, and a relevant network-context change can make it irrelevant. While applicable recent-failure state exists, the updated Rule 6 can prefer IPv4 over the affected IPv6 candidate instead of repeatedly applying the normal IPv6 precedence. Expiration of the state gives IPv6 another opportunity to be used after the problem may have been corrected. EDS does not require active probing, RTT measurement, packet-loss measurement, throughput measurement, or other performance ranking. The mechanism is based on connectivity establishment outcomes that are already available in many operating systems (OSes) or platform implementations. For example, a TCP connect() attempt already reports whether connection establishment succeeded or failed, together with an error indication when it fails. The first encounter with a previously unknown IPv6 problem can still be user-visible. The purpose of connectivity- informed selection is to learn from that failure and avoid repeatedly exposing later selections to the same recently failing IPv6 connectivity. The rationale behind this choice is that users can usually tolerate a one-time glitch but not repeated failures, and that this choice makes the EDS solution much simpler. ## Operational Diagnostics Avoiding repeated failures is only part of the EDS objective. Network administrators also need information about IPv6 connection establishment failures so that the underlying problems can be corrected. The recent-failure records defined in [ADDR-SELECT] provide the primary diagnostic information used by EDS. An EDS- capable implementation SHOULD make these records available to authorized local administrators or management systems, subject to local policy and privacy controls. The records identify the applicable network context, IPv6 destination, IPv6 source prefix or address, transport protocol and port, failure type, and time of the observation. Recent-failure records can be emitted to a local logging or telemetry facility, such as syslog, and retained independently of the short-lived state used by destination selection. Expiration or clearing of the selection state does not require deletion of corresponding diagnostic records. EDS does not require a particular log format, storage model, aggregation method, or remote reporting protocol. Retention, filtering, aggregation, and export are matters of local policy. It is worth noting that, with the normal RFC 6724 policy, when both usable IPv6 and IPv4 destinations are available for selection, IPv6 is normally preferred. Therefore, when IPv4 is preferred, a recent-failure state record should normally exist to explain the reason. When IPv4 is used without such a record, the reason lies outside [ADDR-SELECT]. Network administrators should therefore investigate whether a usable IPv6 candidate was available to the destination-selection mechanism and, in particular, whether DNS resolution, host IPv6 configuration, or local address-selection policy prevented IPv6 from being preferred. The diagnostic information is intended to support a gradual improvement loop: observe IPv6 connection establishment failures or Xiao Expires 8 April 2027 [Page 6] Internet-Draft Enhanced Dual Stack October 2026 cases where usable IPv6 candidates are unavailable, determine the cause, correct the underlying problem, and verify that IPv6 use increases over time. # Incremental EDS Deployment EDS does not require all hosts to become EDS-capable before IPv6 deployment can begin. The objective is to allow IPv6 introduction to start with practical upfront validation and then improve IPv6 operation progressively. A practical deployment approach is to divide hosts into IPv6-pioneer hosts and regular hosts. IPv6-pioneer hosts are EDS-capable hosts selected for early IPv6 deployment. Regular hosts can initially remain IPv4-only or otherwise unchanged. After performing the IPv6 validation that is practical for the environment, network administrators can enable IPv6 on the IPv6-pioneer hosts, network infrastructure, and other components needed to support them. Connectivity-informed destination selection reduces repeated user-visible impact when an IPv6 problem is encountered, while operational diagnostics on the pioneer hosts provide information about where IPv6 is failing or not being used and why. Network administrators can use this information to identify and correct IPv6 problems. As the observed problems are fixed and operational confidence increases, IPv6 can be enabled for additional hosts, applications, services, or network environments. EDS-capable pioneer hosts can continue to provide operational diagnostics during each expansion step so that newly exposed IPv6 problems can again be identified and corrected. Regular hosts do not all need to become EDS-capable before joining the IPv6-enabled population. The pioneer hosts provide an initial protected and observable population through which IPv6 problems can be discovered and corrected before deployment is expanded more broadly. Where appropriate, operators can maintain EDS-capable pioneer hosts in newly enabled sites, VLANs, SSIDs, or other network environments so that the observe, correct, and expand process continues throughout the deployment. This approach changes IPv6 introduction from a process dominated by extensive upfront validation and a risky enablement point into one based on practical upfront validation followed by gradual operational improvement. As IPv6 becomes increasingly reliable and operational confidence grows, suitable environments can subsequently move toward IPv6-mostly or IPv6-only operation. Xiao Expires 8 April 2027 [Page 7] Internet-Draft Enhanced Dual Stack October 2026 EDS intends to make IPv6 introduction simpler. It does not intend to keep networks in dual stack mode forever. After IPv6 is sufficiently functional, network administrators can start the migration to IPv6-mostly or IPv6-only. 4. Limitations EDS reduces repeated user-visible disruption but does not guarantee that the first encounter with a previously unknown IPv6 problem will be invisible. With no applicable recent-failure state, RFC 6724 behaves normally and IPv6 can be preferred. If that first attempt fails, later selections can use the resulting state to avoid repeatedly preferring the same recently failing IPv6 context. EDS also does not repair the underlying IPv6 problem. Connectivity- informed selection protects users from repeated exposure, while operational diagnostics provide the information needed for administrators to locate and correct the problem. Recent-failure information can become stale. It therefore needs bounded lifetime and appropriate scoping, as specified in [ADDR-SELECT]. 5. Standardization Considerations EDS is an operational framework. The corresponding update to the standard IPv6/IPv4 destination-selection behavior is specified in [ADDR-SELECT]. Operational diagnostic information can be exposed through existing local logging or telemetry facilities. Additional standardization can be developed where common reporting semantics or mechanisms are useful, but EDS does not depend on a particular reporting transport or management protocol. This document does not define a new application-facing API. Its purpose is to describe how connectivity-informed destination selection and operational diagnostics work together to support lower- risk, incremental IPv6 deployment. 6. Security Considerations The security considerations of [RFC6724] and [ADDR-SELECT] apply. Xiao Expires 8 April 2027 [Page 8] Internet-Draft Enhanced Dual Stack October 2026 Recent-failure state influences whether IPv6 or IPv4 is preferred. Incorrect or malicious creation of such state could therefore cause temporary preference for IPv4. Failure information used for selection SHOULD be derived from locally observed connection establishment outcomes, and its lifetime SHOULD be bounded. Operational diagnostic information can contain sensitive information about network context, destination addresses, source addresses or prefixes, transport protocols and ports, failure patterns, and timestamp. Access to this information MUST be controlled. Retention, export, and aggregation SHOULD follow local security and privacy policy and SHOULD expose no more information than is needed for the intended operational purpose. 7. IANA Considerations This document makes no request of IANA. 8. References 8.1. Normative References [ADDR-SELECT] Martin, F., Xiao, X., and B. E. Carpenter, "Updates to IPv6 Default Address Selection", Work in Progress, Internet-Draft, draft-martin-ipv6-addr-selection-updates- 00, 15 September 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, . 8.2. Informative References Xiao Expires 8 April 2027 [Page 9] Internet-Draft Enhanced Dual Stack October 2026 [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, . [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, . [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, DOI 10.17487/RFC3484, March 2003, . [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April 2012, . [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, . [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 8 April 2027 [Page 10] Internet-Draft Enhanced Dual Stack October 2026 Acknowledgements Brian Carpenter and Franck Martin contributed to the development of the connectivity-informed RFC 6724 update and helped refine the relationship between EDS and default IPv6/IPv4 destination selection. Comments from David Schinazi, Tim Chown, Philipp Tiesel, Tom Hill, Warren Kumari, Jen Linkova, Nick Buraglio, 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 8 April 2027 [Page 11]