[✨ Triage] dotnet/runtime#117082 by ForeverExe - [Report // Linux] Dotnet 8+ httpClient times out in IPV6

[MihuBot]

Triage for dotnet/runtime#117082.
Repo filter: All networking issues.
MihuBot version: 1a6438.
Ping MihaZupan for any issues.

This is a test triage report generated by AI, aimed at helping the triage team quickly identify past issues/PRs that may be related.
Take any conclusions with a large grain of salt.

dotnet/runtime#117082: [Report // Linux] Dotnet 8+ httpClient times out in IPV6 by ForeverExe
[Tool] Searching for HttpClient timeout IPv6 Linux, DOTNET_SYSTEM_NET_DISABLEIPV6, HttpClient fallback to IPv4, HttpClient IPv6 issues Linux, HttpClient network timeout dotnet 8 (IncludeOpen=True, IncludeClosed=True, IncludeIssues=True, IncludePullRequests=False, Repository=dotnet/runtime)
[Tool] Found 61 issues, 25 comments, 61 returned results (14907 ms)
[Tool] Obtained 4 comments for issue #107979: Disabling IPV6 in .NET Core
[Tool] Obtained 5 comments for issue #17187: HttpClient does not support IPv6 with scope ID on Mac or Linux
[Tool] Obtained 16 comments for issue #22089: Please add option to force resolve DNS address by using IPv4 or IPv6
[Tool] Obtained 4 comments for issue #47583: Expose a global switch to disable IPV6 to overcome DualMode socket issues in environments that do not support IPV6
[Tool] Obtained 58 comments for issue #26177: Consider using Happy Eyeballs or similar in SocketsHttpHandler

Here are the most relevant related issues and discussions for triaging issue #117082, "[Report // Linux] Dotnet 8+ httpClient times out in IPV6":

---

1. Issue #107979 (September 2024 – February 2025) - "Disabling IPV6 in .NET Core"

• Summary: Reports that setting System.Net.DisableIPv6 to true does not prevent outbound requests from attempting IPv6 if the remote resource does not have a Quad A DNS record. The workaround of disabling IPv6 at the OS or container level is not always effective. The discussion highlights that .NET currently filters out IPv6 results after DNS resolution, rather than restricting the address family in the initial DNS query. A fix to restrict the address family in getaddrinfo is targeted for .NET 10.
• Key Comment:
  • "When DisableIPv6=true, we are filtering out V6 results after resolution... Instead, we should restrict the AF in the getaddrinfo(ex) calls. We should attempt changing this for .NET 10." (antonfirsov, .NET networking team)
• Relevance: Directly related to the question of how to globally prefer IPv4 or disable IPv6 in .NET, and why the current environment variable workaround is necessary.

---

2. Issue #47583 (January 2021 – July 2021) - "Expose a global switch to disable IPV6 to overcome DualMode socket issues in environments that do not support IPV6"

• Summary: Discusses the need for a global switch to disable IPv6 due to issues with dual-stack sockets, especially in VPN or tunnel environments. The team agreed to add a DisableIPv6 switch, which was implemented in .NET 6.
• Key Comment:
  • "Triage: We cannot do today IPv6 only, so let's add DisableIPv6 switch." (karelz, .NET networking team)
• Relevance: Confirms the existence of the DOTNET_SYSTEM_NET_DISABLEIPV6 switch and its intended use for scenarios like the one reported.

---

3. Issue #26177 (May 2018 – ongoing) - "Consider using Happy Eyeballs or similar in SocketsHttpHandler"

• Summary: This long-running issue discusses the lack of "Happy Eyeballs" (RFC 8305) support in .NET's SocketsHttpHandler. Without this, if IPv6 is available but broken, HttpClient may hang or timeout before falling back to IPv4, unlike curl which quickly tries both. The thread contains detailed analysis, workarounds (such as editing /etc/gai.conf to prefer IPv4), and ongoing work to improve this in future .NET versions.
• Key Comments:
  • "As long as this isn't implemented, HttpClient is by-default broken for any software distributed to user machines. Sooner or later somebody is going to have a broken IPv6 configuration, and your app will just break." (PJB3005)
  • "It is on my radar for 9.0 but I did not get to it yet. #87932 has approved API." (wfurt, .NET networking team, June 2024)
• Relevance: Explains why the default behavior is problematic on networks with broken IPv6 and why the environment variable workaround is needed. Also, it shows that a robust fallback mechanism is not yet implemented.

---

4. Issue #22089 (June 2017 – January 2020) - "Please add option to force resolve DNS address by using IPv4 or IPv6"

• Summary: Requests an API to force DNS resolution to IPv4 or IPv6, similar to curl's -4/-6 flags. The issue was resolved in .NET 5 with new APIs (see #41949), but these are per-request/handler, not global.
• Key Comment:
  • "This has been resolved via the API added here in .NET 5: https://github.com/dotnet/runtime/issues/41949" (scalablecory)
• Relevance: There is now a way to control address family per-request, but not a global fallback to IPv4 (other than the environment variable).

---

5. Issue #17187 (May 2016 – January 2020) - "HttpClient does not support IPv6 with scope ID on Mac or Linux"

• Summary: Focuses on issues with IPv6 scope IDs in URLs, but also contains discussion about IPv6 support and differences in behavior between platforms.
• Relevance: Less directly related, but part of the broader context of IPv6 issues in .NET on Unix-like systems.

---

Key Takeaways for Triaging

• Current Workaround: The only way to globally force IPv4 in .NET is to use the environment variable DOTNET_SYSTEM_NET_DISABLEIPV6=1. This disables IPv6 entirely for the process.
• No Built-in Global Fallback: There is no built-in .NET runtime switch to "prefer IPv4" or "fallback to IPv4" globally, other than disabling IPv6. Per-request/handler APIs exist (from .NET 5) to control address family, but not globally.
• Root Cause: .NET currently filters out IPv6 addresses after DNS resolution, rather than restricting the address family in the DNS query itself. This can cause timeouts if the system prefers IPv6 but the network is broken.
• Future Improvements: There are plans to improve this in .NET 10 (for DNS resolution) and to implement "Happy Eyeballs" (for connection fallback) in a future release (possibly .NET 9 or later).

---

References

• Disabling IPV6 in .NET Core (#107979)
• Expose a global switch to disable IPV6 (#47583)
• Consider using Happy Eyeballs or similar in SocketsHttpHandler (#26177)
• Please add option to force resolve DNS address by using IPv4 or IPv6 (#22089)
• HttpClient does not support IPv6 with scope ID on Mac or Linux (#17187)

---

Summary for the reporter:
Your workaround (DOTNET_SYSTEM_NET_DISABLEIPV6=1) is currently the only way to globally force IPv4 in .NET. There is no built-in global "prefer IPv4" or "fallback to IPv4" switch. Improvements are planned for future .NET versions, but for now, the environment variable is the recommended approach. If you need per-request control, you can use the new APIs in .NET 5+, but these are not global. The underlying issues are well-known and being tracked for future releases.