Leaderboard

For those running Windows 10 and don't want to run the persistent command but still want the IPV6 by default, you can do so via Eddie. Open up Preferences, Go To Events, open the VPN Up (or anything above it, I don't know if it matters) option. For file name navigate to C:/Windows/System32/netsh.exe For argument type: interface ipv6 set prefixpolicy fc00::/7 37 1 store=active I have "Wait end of process" disabled, but I don't know if that matters. Click Save. Reconnect to an AirVPN server. You should now have IPV6 by default any time you connect to a server, and upon reboot, it will reset back to normal. It would probably be idea if the VPN Down option had something resetting the Netsh settings, but I don't know how to do that. Also Microsoft apparently says Netsh might be removed in the future for a powershell option so... ¯\_(ツ)_/¯

At the moment I've got no native IPv6 connection at my disposal to test my hypothesis but I don't think that the problem lies at the application level. The apparent preference for IPv4 does not only seem to prevail in browsers but also in other applications like SSH. If I'm correct, SSH should prefer IPv6 over IPv4 on a native IPv6 connection, if one URL is pointing to multiple DNS entries (A + AAAA in this case). When a connection to a Gen2 server is established (via an IPv4 connection in my case), SSH always prefers IPv4 in my testing. An IPv6 connection to this specific URL can be forced with ssh -6 ... but this shouldn't be the default behavior of SSH. What determines which connection should be preferred? RFC3484 describes the ranking of competing connections. The resulting /etc/gai.conf on my Arch Linux system looks like this: # All lines have an initial identifier specifying the option followed by # up to two values. Information specified in this file replaces the # default information. Complete absence of data of one kind causes the # appropriate default information to be used. The supported commands include: # # reload <yes|no> # If set to yes, each getaddrinfo(3) call will check whether this file # changed and if necessary reload. This option should not really be # used. There are possible runtime problems. The default is no. # # label <mask> <value> # Add another rule to the RFC 3484 label table. See section 2.1 in # RFC 3484. The default is: # #label ::1/128 0 #label ::/0 1 #label 2002::/16 2 #label ::/96 3 #label ::ffff:0:0/96 4 #label fec0::/10 5 #label fc00::/7 6 #label 2001:0::/32 7 # # This default differs from the tables given in RFC 3484 by handling # (now obsolete) site-local IPv6 addresses and Unique Local Addresses. # The reason for this difference is that these addresses are never # NATed while IPv4 site-local addresses most probably are. Given # the precedence of IPv6 over IPv4 (see below) on machines having only # site-local IPv4 and IPv6 addresses a lookup for a global address would # see the IPv6 be preferred. The result is a long delay because the # site-local IPv6 addresses cannot be used while the IPv4 address is # (at least for the foreseeable future) NATed. We also treat Teredo # tunnels special. # # precedence <mask> <value> # Add another rule to the RFC 3484 precedence table. See section 2.1 # and 10.3 in RFC 3484. The default is: # #precedence ::1/128 50 #precedence ::/0 40 #precedence 2002::/16 30 #precedence ::/96 20 #precedence ::ffff:0:0/96 10 # # For sites which prefer IPv4 connections change the last line to # #precedence ::ffff:0:0/96 100 Which reflects the expected behavior described by the RFC standard. The man-page for this has been implemented in kernel 4.16 (very recently). When I apply the little knowledge I have on IPv6, the ULA each OpenVPN connections gets assigned is part of: label fc00::/7 6 and thus very low in the ranking of the competing connections. Hopefully I could point you in the right direction. If not I'm sorry. I don't understand all of it but this seems plausible to me.

@arteryshelby It doesn't make difference, actually. But if M247 tells us it's in Berlin, we publish Berlin. If you prefer you can consider it in Frankfurt until our next investigation. Topic locked. Kind regards

After a bit of tinkering I finally get 19/20 on ipv6-test.com running Waterfox 56.2.6 on Debian. I also get 19/20 on Chromium 70 and Firefox ESR (60.4.0). Waterfox addons also indicate that the browser connects to IPv6 addresses all the time. It doesn't seem to be an issue with getaddrinfo() or its config in gai.conf at all as mine is the same as Mr. kaymio's. So, what did I do? I am not entirely sure, to be honest. I disconnected from AirVPN and went on doing experiments on my ISP line with native IPv6. I set network.http.fast-fallback-to-IPv4;false network.notify.IPv6;false and restarted the browser. Then I reenabled the notify setting and restarted again. After that, Firefox/Waterfox magically started to prefer IPv6 and ipv6-test.com gave me 17/20. This is due to my router blocking ICMP (Fritz!Box calls this "Stealth Mode" ) so it should be 19/20 if I decide to stop filtering it. I reconnected to AirVPN and voilà, still prefers IPv6, now 19/20.

On windows 7, IPv6 is working by default. On Win 10, this command fixed it (cmd.exe) - netsh interface ipv6 set prefixpolicy fc00::/7 37 1 store=active Premanently fixed by command : netsh interface ipv6 set prefixpolicy fc00::/7 37 1 store=persistent