Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't use DualMode sockets in environments where ipv6 is disabled/unavailable #4888

Open
mastahg opened this issue Mar 4, 2025 · 4 comments
Labels
external Proposed by non-MSFT feature request A request for new functionality
Milestone

Comments

@mastahg
Copy link

mastahg commented Mar 4, 2025

Describe the feature you'd like supported

I have a situation where end users with unreliable ipv6 setups are being impacted and disabling ipv6 at either the .net runtime level or having the end user disable ipv6 systemwide is the easiest method to remedy the situation. These users are then unable to utilize http3/quic due to the use of dualmode sockets

Proposed solution

Don't use DualMode sockets in environments where ipv6 is disabled/unavailable

Additional context

This was originally raised on the .net runtime github here dotnet/runtime#113100

@mastahg mastahg added the feature request A request for new functionality label Mar 4, 2025
@anrossi
Copy link
Contributor

anrossi commented Mar 4, 2025

Which OS are you using?

@mastahg
Copy link
Author

mastahg commented Mar 4, 2025

Windows, with around half on windows 10 and half on windows 11.

@nibanks nibanks added the external Proposed by non-MSFT label Mar 4, 2025
@nibanks nibanks added this to the Future milestone Mar 4, 2025
@anrossi
Copy link
Contributor

anrossi commented Mar 10, 2025

Just making sure I understand the full issue here: you disable IPv6 support in the windows OS, and expect MsQuic to just use IPv4 only, but what actually happen is you can't connect to any IPv4 or IPv6 address using HTTP/3?

@mastahg
Copy link
Author

mastahg commented Mar 10, 2025

That is correct. I was unable to replicate it being an issue disabling it from the system side personally but at least one user encountered it. I was able to reproduce the issue by enabling the flag System.Net.DisableIPv6

There has been some progress on the original ticket introduced in the runtime repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external Proposed by non-MSFT feature request A request for new functionality
Projects
None yet
Development

No branches or pull requests

3 participants