Dual-stack socket link-local IPv6 address mystery

Steve Dykes · 2019-04-20T05:04:15

I have a multiplayer-enabled PC (Windows 7+, UDP) game project, which I've had IPv4 and IPv6 successfully running on for quite some time (via a config option to select one or the other). I've finally just now got around to adding dual-stack socket support so that I can accommodate IPv4 and IPv6 players at the same time on the same server. This was pretty straightforward, and overall things seem to be working as expected...all permutations of socket types (single or dual-stack) can connect to all permutations on the other end, transmit/receive data, etc. However, I am seeing one strange thing that I have yet to figure out. Part of the data I provide when advertising a server connection is the *local* IP address, so that clients on the same network as the server can connect directly (try local IP, then remote). To generate this link-local IP address, I use the standard connect, getsockname, disc-connect method. This has been working perfectly for eons for both IPv4 and IPv6, and with the dual-stack socket it gives me what I expect in all cases except one. When I provide an IPv6 destination address to a dual-stack socket for determining the link-local address, getsockname is giving me back a mapped IPv4 address. Further, that (mapped) address is not even an IPv4 link-local address, it doesn't make much sense (ffff:38.0.23.0, port 51013). The port is completely sensible (it is one past the last one allocated). I check all return values on all socket calls, everything is returning success. As implied above, I do get the proper mapped IPv4 local address when I provide an IPv4 mapped destination address. But for the life of me I can't figure why I'm getting this result for a straight IPv6 destination address. It's worth noting that my internet IPv6 connection seems to be a bit flaky at present. I am able to do IPv6 DNS lookups, but I am seeing that websites are reporting they can't get my IPv6 address (google IPv6 test site, for instance). Now, I might reasonably expect that my connect call would fail in such a scenario, but that's not the case. But I can also reason that the IPv6 address doesn't necessarily need to be reachable to determine what the bound local address/port will be...? Especially since this all works just fine on a straight IPv6-only socket. Has anyone seen this before? Am happy to provide more details that might help.