Network Extension VPN causing issues on hybrid (IPv4/IPv6) networks

Hello,

We are developing a VPN app and have come across some very strange behavior when dealing with hybrid networks.

Our VPN configuration, when we see that a network supports both protocols, we form both IPv4 and IPv6 network settings to our tunnel.
We're setting "defaultRoute" of both IPv4 and IPv6 tunnels, and we're using the system's DNS servers.

We discovered that in this case when the browser gets a DNS response for both IPv4 and IPv6 addresses, it sometimes follows by starting the TCP connection to both addresses.

For example, we're testing with ip6.me. It's shows your IPv6 network if you have it, and IPv4 address if you don't.
However once we start the VPN it shows the IPv4. Going to ip6only.me does show the IPv6 address when the VPN is on.

We've run tcp dumps on the iPhone and we see that when the VPN is OFF the browser send three DNS requests to ip6.me (<A>,<AAAA> and <HTTPS>) and receives response for all three, then it starts a single tcp (http) connection to the IPv6 address.
However with the VPN is ON, the browser send the same DNS queries and receives the same responses, but follows to make two tcp connections, first to the IPv6 address (and gets the expected response with the IPv6 address in the http response) and about 0.5 second later it send another tcp connection this time to the IPv4 address. For some reason it's always the latter response that is rendered on the browser.

We've tried this repeatedly, on a number of devices, using different hybrid networks (wifi / cellular), always to the same result. We've also tried other VPN apps that support hybrid networks and see same behavior.

I don't know if it's a bug in the system or in the website, we have worries that it might increase network consumption and affect battery.
Can anyone share insights on this?
This is not a bug in the system, but rather it sounds like the usage of the traditional Happy Eyeballs algorithm, but possibly version 2, defined out on RFC 8305. Take a look at this abstract and introduction for more information.

we have worries that it might increase network consumption and affect battery.

Taking a look at the RFC authors I am sure that this algorithm was defined and implemented with performance in mind. Having said that, are you seeing a noticeable impact on your battery? If so, I would encourage you to benchmark this compared to just running on a single v4 or v6 network to compare the difference.


Matt Eaton
DTS Engineering, CoreOS
meaton3@apple.com
Thanks for your reply,

I looked at the RFC you mentioned and at 5. Connection attempts it states (emphasis is my addition):

Once the list of addresses received up to this point has been constructed, the client will attempt to make connections. In order to avoid unreasonable network load, connection attempts SHOULD NOT be made simultaneously. Instead, one connection attempt to a single address is started first, followed by the others in the list, one at a time. Starting a new connection attempt does not affect previous attempts, as multiple connection attempts may occur in parallel. Once one of the connection attempts succeeds (generally when the TCP handshake completes), all other connections attempts that have not yet succeeded SHOULD be canceled. Any address that was not yet attempted as a connection SHOULD be ignored. At that time, the asynchronous DNS query MAY be canceled as new addresses will not be used for this connection. However, the DNS client resolver SHOULD still process DNS replies from the network for a short period of time (recommended to be 1 second), as they will populate the DNS cache and can be used for subsequent connections.

But in the case we have, there is a successful TCP handshake to the AAAA address with, yet we see another TCP connection for A address 500 ms later. Why isn't the A connection cancelled then?

I can't say I see any direct implications to battery and network usage (very hard to measure though, especially since there not many true "dual family" addresses out there), but I do fear there might be.
Network Extension VPN causing issues on hybrid (IPv4/IPv6) networks
 
 
Q