Jump to content


Photo

The issue "Your browser is avoiding IPv6."


  • Please log in to reply
3 replies to this topic

#1 Staff

Staff

    Advanced Member

  • Staff
  • PipPipPip
  • 7325 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

kaymio

    Member

  • Members
  • PipPip
  • 10 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

Staff

    Advanced Member

  • Staff
  • PipPipPip
  • 7325 posts

Posted 27 June 2018 - 04:51 PM

@kaymio

 

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 AN566

AN566

    Advanced Member

  • Members
  • PipPipPip
  • 157 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






1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users

Servers online. Online Sessions: 14557 - BW: 52395 Mbit/sYour IP: 54.81.244.248Guest Access.