| Internet-Draft | IPv6 Path Degradation | July 2026 |
| Pang, et al. | Expires 6 January 2027 | [Page] |
The document analyzes contributing factors across the content service layer and the network transport layer, and discusses why existing mechanisms such as RFC 6724 and Happy Eyeballs do not fully address performance failures that appear after connection establishment. This document is limited to problem analysis, scope clarification, and areas for further study. It does not define new network-to-host signaling mechanisms or require hosts to use network-provided information when making address-family or path selection decisions.¶
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 6 January 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.¶
Dual-stack host behavior commonly relies on address selection rules defined in RFC 6724 [RFC6724] and connection establishment mechanisms such as Happy Eyeballs Version 2 (HEv2) [RFC8305]. Ongoing Happy Eyeballs Version 3 work [I-D.ietf-happy-happyeyeballs-v3] further extends connection setup behavior to consider SVCB/HTTPS records, application protocols, security properties, and transport choices such as QUIC and TCP.¶
These mechanisms are effective at reducing user-visible delay when one address, address family, endpoint, or transport is unreachable or slow during connection setup. However, operational experience in production dual-stack networks shows that some failures occur after basic reachability and connection establishment have already succeeded. In these cases, an IPv6 path may be sufficiently functional to complete DNS resolution, ICMPv6 reachability checks, TCP handshakes, QUIC handshakes, or TLS handshakes, but may still perform poorly during subsequent application data transfer.¶
This document terms this phenomenon "IPv6 path performance degradation." The objective is to define the boundaries of this scenario, analyze cross-layer coupling effects that amplify its impact, and identify areas for host-side mitigation mechanisms and further study.¶
The central thesis of this document is that some dual-stack failures occur after basic reachability and connection establishment succeed. Existing Happy Eyeballs mechanisms do not standardize post-establishment comparative performance monitoring, cross-application performance-state reuse, or scoped adaptation of future IPv6/IPv4 selection based on verified degradation.¶
In dual-stack production environments, this issue may manifest through specific application-layer symptoms:¶
Lightweight text-based transactions, such as webpage text or instant messaging text payloads, function normally over IPv6, indicating that basic reachability is intact.¶
Heavy multimedia transactions, such as image thumbnails, video segments, or real-time media streams, experience high latency, stalling, loading failures, or frequent disconnections.¶
Temporarily forcing the host or application to use IPv4 may immediately restore normal application performance.¶
These symptoms are often not reproduced by conventional basic-reachability probes, such as small-packet ICMPv6 probes or connection-establishment checks, which makes fault isolation costly.¶
IPv6 path performance degradation is defined as a scenario where a host has obtained a valid Global Unicast Address (GUA) and a default route, and where basic ICMPv6 reachability and connection establishment succeed, yet the IPv6 path suffers from high round-trip time (RTT), high packet loss, retransmission timeouts, or application timeouts during large-packet transmission, high-volume data transfer, or high-concurrency short connections.¶
This state sits between "fully connected" and "completely disconnected." It is a performance grey-failure mode that is not fully addressed by current dual-stack connection setup mechanisms.¶
IPv6 path performance degradation differs from total unreachability in failure characteristics and self-healing behavior:¶
| Characteristic | Total Unreachability | Path Performance Degradation (Grey-Failure) |
|---|---|---|
| Definition | Deterministic reachability failure where the host lacks an IPv6 address, lacks a valid default route, or cannot connect. | Basic reachability and connection setup succeed, but subsequent data transfer exposes quality degradation. |
| Happy Eyeballs Reaction | Proactively races candidates with a recommended 250 ms inter-attempt delay between connection attempts. | Limited for this failure mode. Once a candidate connection is successfully established, alternative attempts are normally cancelled, and post-establishment data-transfer quality is outside the primary decision window. |
| Traffic Impact | Fails uniformly across all packet types and sizes. | Small packets (SYNs, ICMPv6) traverse normally; large application payloads or concurrent flows stall/drop. |
| Remediation Cost | Low self-healing delay due to built-in connection racing. |