QuicListenerStart does not return an error when listening on IPv6 and IPv6 is disabled

[rzikm]

Describe the bug

When attempting to listen on IPv6 address on platforms which have IPv6 disabled, MsQuicListenerStart still returns success, although it is not possible to create a connection to it.

Attempting to establish client-initiated IPv6 connection fails as expected (with 0x63 = EADDRNOTAVAIL) on Linux.

Affected OS

• All
• Windows Server 2022
• Windows 11, version 22H2
• Windows 11, version 21H2
• Windows Insider Preview (specify affected build below)
• Ubuntu
• Debian
• Other (specify below)

Additional OS information

Encountered on Linux, not sure how to disable IPv6 on windows to reproduce the same behavior.

MsQuic version

main

Steps taken to reproduce bug

1. Disable IPv6 on the machine
2. Create a QuicListener
3. call ListenerStart with IPv6 loopback address

Expected behavior

ListenerStart returns 0x63 or other relevant error code.

Actual outcome

ListenerStart finishes successfully.

Additional details

I tested in the same environment that binding a socket to the tested address (IPv6 loopback) does lead to 0x63 being returned. I would expect QuicListener to behave the same way.

[nibanks]

Are you explicitly listening only on and IPv6 address, or a wildcard address? Could you please collect the (ideally converted) logs for a repro?

[nibanks]

I believe you can disable IPv6 on Windows by unchecking this box:

[rzikm]

Are you explicitly listening only on and IPv6 address, or a wildcard address?

In this case we are passing AF_INET6 as the address family.

Could you please collect the (ideally converted) logs for a repro?

I will try to do that once I have time. I expect the docs describe the process?

[rzikm]

hmm, maybe this sheds some light, is it possible that this is causing the problem?

msquic/src/core/listener.c

Lines 281 to 286 in 1bd55b3

	//
	// Listeners always grab the dual-mode wildcard binding for the specified
	// (if available) UDP port and then manually filter on the specific address
	// (if available) at the QUIC layer.
	//
	QuicAddrSetFamily(&BindingLocalAddress, QUIC_ADDRESS_FAMILY_INET6);

[nibanks]

hmm, maybe this sheds some light, is it possible that this is causing the problem?

msquic/src/core/listener.c

Lines 281 to 286 in 1bd55b3

	//
	// Listeners always grab the dual-mode wildcard binding for the specified
	// (if available) UDP port and then manually filter on the specific address
	// (if available) at the QUIC layer.
	//
	QuicAddrSetFamily(&BindingLocalAddress, QUIC_ADDRESS_FAMILY_INET6);

Ah, yes, you are right. That's unfortunate. I don't have a good way to fix this then.