Setting up IPV6 tunneling

[Augustine Calvino 0]

One of the biggest reasons I chose AirVPN is because it said it has IPV6 support. However, using the chrome extension IPvFoo, I can see that all sites I connect to are using IPv4 (when not on my VPN, I see that these sites do indeed support and load via IPv6). My router and computer are configured for IPv6.
Can someone guide me through the steps necessary to enable IPv6 through my VPN?

What I have tried:

• I tried playing with the OpenVPN directives a bit, entering these settings (and various subsets of these settings) generated by the AirVPN config generator into Eddie

  client
  dev tun
  remote 2606:6080:2001:9:15a2:d969:773f:e2be 443
  resolv-retry infinite
  nobind
  persist-key
  persist-tun
  auth-nocache
  verb 3
  explicit-exit-notify 5
  rcvbuf 262144
  sndbuf 262144
  push-peer-info
  setenv UV_IPV6 yes
  remote-cert-tls server
  comp-lzo no
  data-ciphers AES-256-GCM:AES-256-CBC:AES-192-GCM:AES-192-CBC:AES-128-GCM:AES-128-CBC
  data-ciphers-fallback AES-256-CBC
  proto udp6
  key-direction 1

• In the Network tab of Eddie's settings, playing around with a variety of combinations of the IPv4 and IPv6 settings.

After every change in settings, I disconnect and reconnect the vpn to see if sites load via IPv6, to no avail.

Again, I chose AirVPN because it was supposed to have IPv6 support, so I would really appreciate a good set of instructions on how to get it working end-to-end.

Here is my system information generated by AirVPN; FYI, I am running macOS 11.4, not macOS 10.16.

systeminfo.rtf

Edited ... by Augustine Calvino

[OpenSourcerer 1441]

3 hours ago, Augustine Calvino said:

Can someone guide me through the steps necessary to enable IPv6 through my VPN?

It is enabled and active. But v4 is preferred due to local configuration. Don't waste your time on OpenVPN config, it's not the problem.

The culprit is the fact that you and most other people are running dual-stack --> v4 and v6 connectivity at the same time, and that a request for a domain's IP address will likely return multiple addresses. Those addresses must be "sorted" to define which address has the highest probability of reaching the destination. And the result is that the "winning address" will be in first place and therefore used to connect.
There is a ranking of address scopes defined in a RFC where basically the whole v6 address space comes before v4, since we want to prefer v6. Three more lines outside this standard are what spoils the fun for you.

This is the original RFC definition:

      Prefix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      2002::/16             30     2
      ::/96                 20     3
      ::ffff:0:0/96         10     4

Basically, anything resembling a v6 address is preferred. The complete v4 address space is the last line in v6 notation.
What those engineers thought of is to defer certain spaces of v6. These three scopes are

• fec0::/10 (from fec0:: to feff::)
• fc00::/7 (from fc00:: to fdff::)
• and some 2001:: scope reserved for certain v6 transition technologies (not really used today -> that's a good reason to defer it, right?)

So what's the reasoning, why defer them? You see, in a perfect world every device has a Unique Global IPv6 Address, a UGA. There are protocols and tech to assign that to all devices in a network automatically. If you've got a UGA, there's a safe chance you've got internet connectivity via v6, because how else would you receive the first half of a full IPv6 address if not through your ISP?
Every device also calculates a Unique Local Address, a ULA, for itself which is starting with fe80:: if the v6 stack is enabled. No matter if v6 is actually enabled on the network or not, every interface in your computer will have one. And this is important to remember.

So you as an engineer can easily assume that you live in a perfect world and if you don't have a UGA in this perfect world, there might not be v6 connectivity at all despite your interface having a valid v6 address (or only limited connectivity which does not cover the internet). These cases are covered with the preference table by means of a lower preference, since all of the possible ULAs are below the ::ffff:0:0/96 entry (which is the v4 space). Again, this is done to ensure that nothing will try a connection via IPv6 if it's assumed there is no v6 connectivity.

So, why all this explanation? Any VPN provider I've tested so far assigns to you a private v4 and a v6 ULA on the tunnel interface so that communication can commence via the tunnel. In AirVPN, the v6 addresses are in the fde6:: scope – incidentally part of a larger scope that is deferred in the preference table because of the assumption that interfaces bearing such an address might not have internet access at all! So according to the preference table ::ffff:0:0/96 (which is the v4 space) has a higher probability of reaching its destination than any address starting with fde6::.

And that is why you always connect via v4. A simple algorithm determined that you probably won't reach your destination using a fde6:: address but you might by using a v4 address.

---

So, where do we go from here and how do we fix it? I can guide you on Linux but I'm not sure whether it can be transferred just like that to macOS. You could see whether /etc/gai.conf exists; maybe we can work from there. Other than that, I don't really know. Need to research it.

[Augustine Calvino 0]

Hey OpenSourcer,

Thanks so much for the detailed response! I could have been troubleshooting this for hours and never would have found that out!

If you have ideas of what I can try I'd love to hear...I am a software developer and systems admin, so I'm comfortable with advanced systems usage - I just don't have a ton of experience with network, though I know the high level concepts. If you tell me conceptually what you did to make it work on linux, I could try to figure out the macOS equivalents, and if we figure it out, we could publish a guide somewhere on the website for future users.
 

[OpenSourcerer 1441]

50 minutes ago, Augustine Calvino said:

Thanks so much for the detailed response! I could have been troubleshooting this for hours and never would have found that out!

Same here. But we had a topic once about this where someone more knowledgable than me hinted at the getaddrinfo config being the problem. When I applied the suggested fix, v6 was preferred via VPN. This topic is still there but currently not viewable for anyone:
https://airvpn.org/forums/topic/25140-the-issue-your-browser-is-avoiding-ipv6

The fix on Linux was as follows. There, the config file at /etc/gai.conf looks like this by default:

#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

You can see the three additional entries outside the standard below the v4 space. What I did was to uncomment them all, then make fc00 entry 4 and the v4 space entry 5. fec0 will be entry 6 because of the fact every interface gets a ULA regardless of v6 connectivity. This is not a safe assumption that there is v6 connectivity on such an interface. 2001:: remains entry 7. Safest way of applying this change system-wide is by rebooting the computer, then.

So, okay, this is Linux, but is also a general description of what to look out for and what to change.

Since the kernel of macOS is somewhat of a descendant of FreeBSD, I thought I'd look into their manuals, too. It's dangerous to assume Darwin = BSD, but, well… . Found something: In *BSD, the proper way of editing this preference table is apparently through a tool called ip6addrctl. Can you check whether there is a tool like that in your system? If you call it without arguments, it should print the current preference table. If there is, that's the way!
If not… I also found an ancient article about Mac OS X Lion suggesting there is no way to set that… but, well, it's ancient.

[Augustine Calvino 0]

Hey OpenSourcer,

I had a chance to look at this a bit, and as far as I can tell, I'm out of luck on Mac.....

There is no /etc/gai.conf, and I couldn't find a gai.conf in any other directory either. ip6addrctl doesn't seem to exist on my os either I may poke around a bit and see if I can install it from elsewhere, but I'm not very hopeful. It seems that osx does ship with the c module for getaddrinfo, which I could maybe use to create my own utility to do what I want, but that would probably have to be a hack project for another time.

Thanks for your insights though!

[Augustine Calvino 0]

One last try (I don't give up easily)....

I found this project, https://github.com/brona/iproute2mac, which aims to make ip tools available on mac. Does it look to you like the capabilities of this tool could do what I need? It provides the following commands, but with my limited experience in networking, I am not sure if they correlate to the functionality of ip6addrctl. The project says it's goal is to provide compatibility with iproute2.

• ip link
• ip addr
• ip route
• ip neigh

[OpenSourcerer 1441]

6 hours ago, Augustine Calvino said:

It seems that osx does ship with the c module for getaddrinfo, which I could maybe use to create my own utility to do what I want, but that would probably have to be a hack project for another time.

This is what made me believe that macOS still uses some of the concepts from *BSD, getaddrinfo() being one of them. But clearly the similarities end quite quickly.
 

6 hours ago, Augustine Calvino said:

The project says it's goal is to provide compatibility with iproute2.

iproute2 aimed at being a replacement for net-tools (commands like ifconfig, netstat and route) because it was unmaintained for quite some time but still considered a standard tool for network management in Linux. Since net-tools didn't have such a feature to my knowledge, iproute2 shouldn't have it, either.
Now, if the project you linked to aims at being some kind of a port of iproute2 to macOS, it's unlikely other "related" tools would be added to it.

With all we know so far, you don't seem to be able to meaningfully influence v4/v6 preference on macOS. Unless someone deep into macOS tech answers, that is.

[Stalinium 47]

Please remove your MAC addresses from the log. E.g. "HWADDR" line.
Secondly, I hope you're not actually using Google Chrome But a recent technological feature to softly force-enable IPv6 is a feature called "happy eyeballs" which gives IPv6-enabled websites a preference where both IPv6 and IPv4 will race each other to establish a connection first, and IPv6 is given a 200-300ms head start. DNS responses and getaddrinfo don't matter any more as long as they include IPv6.
Thirdly to actually test IPv6 connectivity (ping fail seems weird), have you tried manually to ping IPv6 resources? Lastly "curl -6 ifconfig.io" will force curl to use IPv6. If this fails, you've got a system-wide problem.

PS: Do not forget that AirVPN servers require your config to include and your client to correctly execute the following directives to get IPv6 routes:

push-peer-info
setenv UV_IPV6 yes

[Augustine Calvino 0]

@Stalinium, thanks for the note.

I did try that configuration in my openvpn directives to no avail. I also know that my system is configured properly for accessing ipv6 because without my vpn active, it connects to ipv6 resources just fine. Therefore it is either the vpn software or, as Opensourcer pointed out, the ipv6 address that the vpn assigns me.

Unfortunately, the happy eyeballs technique isn't going to get me very far, since I don't fetch websites via curl while browsing the web (unless there is some way to enable this in your browser or via an extension).

[Stalinium 47]

Browsers already have happy eyeballs implemented, read the link. You should've used curl to have a more technical tool to work with and see what error message it returns about IPv6 connectivity.

[OpenSourcerer 1441]

Found some enlightening articles.
https://daniel.haxx.se/blog/2012/01/03/getaddrinfo-with-round-robin-dns-and-happy-eyeballs/
https://labs.ripe.net/author/emileaben/hampering-eyeballs-observations-on-two-happy-eyeballs-implementations/

The latter one goes into detail on when getaddrinfo() is used and when an application's Happy Eyeballs implementation. It's not like getaddrinfo() is off the table on any *nix OS… happy reading!

[SomewhatSane 6]

Hi,

I know that this is a little unrelated to the original question but I thought it might help others who would like have IPv6 as the default when connected to AirVPN on Windows. I'm happy to delete this post if wanted.

The link @OpenSourcerer mentioned (https://airvpn.org/forums/topic/25140-the-issue-your-browser-is-avoiding-ipv6) is available on the Wayback Machine at https://web.archive.org/web/20200410115828/https://airvpn.org/forums/topic/25140-the-issue-your-browser-is-avoiding-ipv6/ . On the original thread, Trimarvis said to run "netsh interface ipv6 set prefixpolicy fc00::/7 37 1 store=persistent" and when run in an elevated command prompt, all sites now connect via IPv6 by default if available.

Full credit to Trimarvis. I spent way too much time trying to figure out how to get this working 😅