Unable to connect to a Windows Quinn server on all its IPv6 addresses

[rofferom]

Version used

Quinn 0.10.4.

Issue description

I'm working on IPv6 support for my application. It works well, except when I try to connect with a Linux PC to a Windows PC. Depending of the IP used, I manage to connect to the Quinn server, but with another IP it fails.

The tests have been done using the following server IPv6 addresses:

• 2a01:e0a:xxxx:xxxx:f876:23f0:17c6:f04f
• 2a01:e0a:xxxx:xxxx:1138:e172:47bb:8d55 (Temporary IPv6 address)

If I connect to the temporary IPv6 address, it works. If I connect to the non-temporary IPv6, it doesn't connect.

I'm not familiar with IPv6, maybe I'm trying something incorrect. But it seems this issue prevent me to have a Windows machine running my service as it doesn't work with the stable IPv6 address.

How to reproduce to issue

I manage to reproduce the issue using the quinn client/server examples. I have just changed the server to make it listen to all the interfaces:

diff --git a/quinn/examples/server.rs b/quinn/examples/server.rs
index 70e71be7..ec8174ce 100644
--- a/quinn/examples/server.rs
+++ b/quinn/examples/server.rs
@@ -35,7 +35,7 @@ struct Opt {
     #[clap(long = "stateless-retry")]
     stateless_retry: bool,
     /// Address to listen on
-    #[clap(long = "listen", default_value = "[::1]:4433")]
+    #[clap(long = "listen", default_value = "[::]:4433")]

Wireshark traces and personal observations

All traces have been done with this filter: udp.port == 4433.

Working case

As said previously, the working usecase is using the temporary IPv6 address.

Client:

Server:

Non working case

The non working usecase is using the non-temporary IPv6 address.

Client:

Server:

On the server side, we can see the client packets are correctly received, and anwsers are sent. On the client side, the answer packets are received.

However, the server doesn't answer with the same IPv6 address that the one used by the client. Maybe this is the root cause of the issue ?

[rofferom]

It seems to be related to #967 that has fixed the issue for unix platforms.

[djc]

Makes sense -- can you port that to the windows networking layer?

[rofferom]

Ok, I'm going to try :+1:

[stormshield-damiend]

This is fixed in #1701 (pktinfo is handled in WSASendMsg), i copy and adapted unix code.

[rofferom]

I confirm that the issue is fixed with your branch :+1:

[Ralith]

Thanks for the detailed report and investigation! It hadn't occurred to me that IPv6 privacy mechanics would make this otherwise niche situation common-place, but this makes perfect sense. We'll try to prioritize that PR, but in the mean time, you might be able to work around this issue by configuring your OS not to use temporary addresses.

[djc]

Fixed in #1701.