| 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. | High fault isolation cost; often requires manual fallback or triggers visible user stalling. |
The core objective of Happy Eyeballs is to reduce user-visible delays when a resolved address, address family, endpoint, transport, or security option is unreachable or slow during connection setup. Happy Eyeballs mechanisms therefore focus on DNS resolution, endpoint ordering, connection attempt scheduling, and the determination of successful connection establishment.¶
HEv2 [RFC8305] performs connection racing across individual destination addresses derived from DNS answers. It uses RFC 6724 sorting as an input and then modifies the candidate order, including address-family interleaving, to avoid excessive delay when one address family is impaired. HEv2 is therefore not strictly an address-family-layer mechanism. It also permits stateful clients to use information such as previous successful addresses and historical RTT to the same host or prefix when ordering candidates or choosing connection attempt timers, with appropriate scoping to the current network attachment.¶
However, HEv2 does not define a standardized cache of comparative IPv6/IPv4 connection outcomes or post-establishment transport performance that can be broadly reused across applications and future connections. Its success criterion is generally tied to connection establishment, such as completion of the TCP handshake, and not to later application data transfer quality.¶
HEv3 [I-D.ietf-happy-happyeyeballs-v3] extends the Happy Eyeballs model to consider SVCB/HTTPS resource records, application protocol support, security requirements, and transport choices such as QUIC and TCP. It also allows the definition of connection success to include higher-layer readiness checks. For example, clients using TLS over TCP can wait for the TLS handshake, and other application-specific readiness checks can be included before cancelling alternative attempts.¶
Nevertheless, HEv3 remains a connection-setup specification. It does not standardize continuous post-establishment comparative performance monitoring, cross-application quality-state sharing, or dynamic remediation for long-lived or high-volume data transfers after the selected path has been used.¶
In IPv6 path performance degradation scenarios, small packets and connection establishment exchanges may succeed, allowing connections to be selected and used. Subsequent large-packet flows, media transfers, or concurrent resource requests may then suffer severe latency, loss, or retransmission. Existing mechanisms do not provide a standardized way to recognize this intermediate "connected but degraded" state and adjust future IPv6/IPv4 selection in a scoped and verified manner.¶
The default address selection rules specified in RFC 6724 [RFC6724] provide a deterministic policy for source and destination address selection. In common dual-stack cases, when other factors are equal, the default policy tends to prefer native IPv6 Global Unicast Addresses over IPv4-mapped addresses.¶
This default behavior is important for IPv6 deployment, but it is not designed to reflect real-time path performance. During transitional deployment phases, IPv6 application clusters, transit links, peering paths, and edge nodes may have different capacity, optimization, or routing characteristics than their IPv4 counterparts. Static address selection alone cannot adjust based on verified path performance metrics, such as sustained RTT, retransmission behavior, or packet loss.¶
Happy Eyeballs should not be described as purely stateless. RFC 8305 permits stateful behavior, including the use of previously successful addresses and historical RTT information, when scoped appropriately to the current network attachment. Such state can improve connection setup decisions.¶
The limitation is different: this state is optional, implementation-specific, and primarily directed at connection setup. Existing Happy Eyeballs specifications do not define a standardized, multi-source, cross-application performance cache that records verified post-establishment IPv6/IPv4 quality outcomes and applies them safely to future connection decisions.¶
Modern web applications often initiate many concurrent secondary resource requests within a single page session. When a dual-stack secondary origin has a degraded IPv6 path, each connection can independently incur connection setup, retransmission, or timeout penalties. For multiplexed protocols such as HTTP/2 or HTTP/3, degradation may also manifest as request-level timeouts and retransmissions within a single connection, compounding application-layer latency and degrading user experience.¶
Many content providers deploy IPv4 and IPv6 services using independent server clusters with asymmetric compute, egress bandwidth, cache capacity, or concurrent connection quotas. In some deployments, IPv6 clusters may receive fewer resources or may not scale at the same rate as dual-stack user penetration.¶
During peak hours, IPv6 server clusters can experience queue overflows or link congestion, causing spikes in application RTT, retransmissions, or packet loss, while basic reachability probes remain unaffected. Hosts and applications may continue to prefer these IPv6 endpoints because connection establishment still succeeds.¶
Modern applications commonly use tiered loading architectures in which primary pages, images, scripts, CDN segments, media streams, and telemetry endpoints are served by different origins.¶
The degradation described in this document applies when affected secondary origins are dual-stack and publish both A and AAAA records, but the IPv6 path or IPv6 service cluster for those origins performs worse than the IPv4 path or cluster. In that case, each secondary origin may independently execute Happy Eyeballs connection setup, and any post-establishment degradation can compound across many resources.¶
Even when servers support dual-stack addresses, application-layer software modules may exhibit IPv6-specific anomalies:¶
Session authentication logic timing out or retrying continuously when accessed via IPv6.¶
Real-time media modules failing to fully initialize over the IPv6 stack, causing stream failures or frequent drops.¶
Dual-stack reverse proxies or load balancers failing to forward requests properly to IPv4-only backend microservices.¶
IPv6-specific policy, logging, geolocation, or access-control paths differing from IPv4 behavior.¶
These defects may be transparent to basic reachability and connection establishment checks and may activate only under specific application interaction patterns.¶
IPv6 requires a minimum link MTU of 1280 bytes, though many production links support a 1500-byte MTU. When a packet exceeds a path's effective MTU, intermediate routers are expected to generate an ICMPv6 Packet Too Big (PTB) message to trigger Path MTU Discovery (PMTUD) [RFC8201] at the source.¶
However, this signaling path can be impaired by:¶
Security policies filtering ICMPv6 messages at firewalls or data center boundaries.¶
Hardware forwarding engines failing to generate PTB messages under certain line-rate or offload conditions.¶
Tunnel encapsulation overhead, such as PPPoE, SRv6, GRE, or IPsec, reducing the effective MTU below 1500 bytes without a corresponding signal to the host.¶
Misconfigured middleboxes that drop PTB messages or other ICMPv6 errors.¶
Furthermore, as documented in [RFC7872], some intermediate devices drop IPv6 packets containing Extension Headers, including Fragment Headers. This can break host attempts to mitigate PMTU issues through fragmentation. Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] provides an alternative, but it is not uniformly deployed or transparently integrated across all application layers.¶
Consequently, small packets such as TCP SYNs, QUIC Initial packets within the effective MTU, or small request payloads may traverse the path normally, while larger application payloads are dropped or severely delayed, resulting in application timeouts.¶
Inter-domain peering paths for IPv6 may exhibit performance disparities compared to IPv4 due to several factors:¶
Under-provisioned IPv6 peering bandwidth, causing congestion and packet loss during peak traffic hours.¶
Unoptimized IPv6 routing policies resulting in circuitous AS paths, making IPv6 RTT significantly higher than IPv4.¶
Lower deployment density of IPv6 Anycast edge nodes in some CDN or content networks, routing users to geographically distant nodes.¶
Differences in traffic engineering maturity between IPv4 and IPv6 networks.¶
These conditions can occur across inter-provider and international boundaries and may follow daily traffic cycles. Because the IPv6 path remains reachable and connection establishment succeeds, connection setup mechanisms alone may not detect the sustained performance disparity.¶
The triggers at the content layer and network transport layer do not operate in isolation. They can couple with host and application selection behavior to compound user experience degradation.¶
+-------------------------------------------------------------+ | Multi-Root Coupling Compounding Effect | +-------------------------------------------------------------+ | 1. Content-layer IPv6 cluster saturation increases RTT | | v | | 2. Network-layer PMTU black holes silently drop packets | | v | | 3. Connection setup succeeds; later data degradation remains| | outside HE's primary decision window | | v | | 4. No standardized cross-app performance state is available | | for future scoped adaptation | +-------------------------------------------------------------+¶
While a single root cause might only introduce limited variation, multi-factor coupling can extend total application load times by several seconds, triggering visible stalling and user complaints.¶
Any future remediation state needs to be scoped to the relevant network context and destination granularity. A degradation signal or observation associated with one SSID, cellular cell, access network, destination prefix, or FQDN should not be applied globally. Hosts should avoid persistent system-wide IPv6 disablement as a response to localized path performance degradation.¶
Host-side performance observations and adaptation mechanisms need to avoid amplification risks and excessive probing traffic toward remote endpoints.¶
This document makes no IANA requests.¶