Jump to content


The issue "Your browser is avoiding IPv6."

  • Please log in to reply
6 replies to this topic

#1 Staff


    Advanced Member

  • Staff
  • PipPipPip
  • 7704 posts

Posted 31 January 2018 - 03:01 PM

What about the issue "Your browser is avoiding IPv6."?

If you use AirVPN servers with IPv6 support:

http://test-ipv6.com: You should obtain a score 10/10. With a single warning:

Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this.

http://ipv6-test.com/: You should obtain a score 15/20. The penalty is caused by

Browser Default: IPv4" and "Fallback: No

Why browser does not prefer IPv6 is currently unknown.
This issue doesn't occur under Android and seems unrelated to our server configuration.
If you don't have this issue (you obtain at least 18/20 on http://ipv6-test.com) on a desktop (Windows, macOS, Linux), even with our VPN competitors, please tell us (preferably reply here, but you can also open a topic in the forum or open a ticket, as you prefer) the OS and the browser you use. Thanks.

#2 kaymio



  • Members
  • PipPip
  • 11 posts

Posted 23 June 2018 - 07:55 PM

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.

#3 Staff


    Advanced Member

  • Staff
  • PipPipPip
  • 7704 posts

Posted 27 June 2018 - 04:51 PM



Our assigned ULAs are in fde6:7a:7d20::/48 which is inside the range officially reserved to ULA so we don't understand why a browser should discriminate against them in favor of a local IPv4 address...


Kind regards

#4 A556


    Advanced Member

  • Members
  • PipPipPip
  • 198 posts
  • LocationUnited States

Posted 11 July 2018 - 03:47 PM

Windows 7

Firefox 61.0.1


Testing on Eridanus server with ipv6-test.com gives me a score of 19/20


test-ipv6.com score of 10/10 with no warnings

#5 canhastorrent



  • Members
  • Pip
  • 1 posts

Posted 04 August 2018 - 02:40 PM

kaymio's suspicion is correct, this is caused by the behaviour mandated in RFC 6724.


IPv6 is designed for operation by assinging a public (inside 2000::/3) range to each user, addresses in private (ULA) ranges are deliberately picked with low priority.

Your OpenVPN setup instead uses a NAT and assigns private IPs to users, which the RFC does not account for at all.

You can circumvent this bug by assigning addresses from an different, non-ULA and "unused" range: e.g. fe12:34:1234::/48


Hope this helps.

#6 Valerian


    Advanced Member

  • Members
  • PipPipPip
  • 126 posts

Posted 30 August 2018 - 07:09 PM

Windows 10 Home

Musica server


Chrome 68: 10/10 & 15/20

Edge 42: 10/10 & 18/20*

Firefox 61.0.2: 10/10 & 18/20*

Opera 55.0: 10/10 & 18/20*


* Only after clicking the Refresh button on the "Browser" tab.

Every browser had the warning, "Your browser has real working IPv6 address - but is avoiding using it."

#7 SteMax97



  • Members
  • Pip
  • 5 posts

Posted 02 December 2018 - 10:53 AM

Is there any update about the situation? Using AirVPN I can connect to IPV6-only websites but IPV4 is preferred on all the others.

My isp does not provide native IPV6.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Servers online. Online Sessions: 13091 - BW: 49194 Mbit/sYour IP: Access.