Smoothing Rough Edges of IPv6 in VPNs

TL;DR

This paper investigates IPv6 leaks and address selection issues in commercial VPNs, revealing privacy risks and proposing a new IPv6 address range to improve VPN IPv6 support.

Contribution

It identifies IPv6 leaks in IPv4-only VPNs and address de-prioritization in dual-stack VPNs, proposing a new IPv6 address range to mitigate these issues.

Findings

12 VPNs leak IPv6 traffic despite claiming safety

Most dual-stack VPN users prefer IPv4 due to address de-prioritization

Proposed a new IPv6 address range to prevent de-prioritization issues

Abstract

How do commercial VPNs interact with IPv6? We show two "rough edges" in how commercial VPNs handle IPv6. First, we show that many IPv4-only VPNs leak IPv6 traffic to the ISP. Individual use VPNs in part to conceal their local IP addresses, so such leaks reduce user privacy. While prior work has studied VPNs in testbeds, we use a new dataset of 129k VPN-using daily visitors to WhatIsMyIPAddress.com that quantifies these leaks and show 12 VPNs previously considered safe still leak for at least 5% of their users. We show native IPv6 addresses leak most commonly in VPNs that claim only IPv4 support, with 5% to 57% of visitors of v4-only VPNs having their native IPv6 address exposed. Second, we show that most dual-stack VPNs users actually select IPv4 instead of IPv6. We observe this problem in our visitor data, and we identify the root cause arises because when user's computer follows standard address-selection rules, VPN-assigned addresses are often de-preferenced. Testing six VPNs on Android, we show that five consistently de-prioritize IPv6. Finally, we suggest a solution to IPv6 de-preferencing: we define a new IPv6 address range for VPNs that is not de-preferenced by address selection. We prototype this solution on Linux. Our findings help identify and address rough edges in the addition of IPv6 support to VPNs.