You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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?
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.
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
The text was updated successfully, but these errors were encountered: