IPv6 privacy has been a topic that has been garnering more attention as IPv6 has become more prevalent but I've found that there's sometimes more data leaking out than just what the protocol itself leaks.
The topic of privacy in IPv6 has been well covered by researchers such as +Fernando Gont in the past. A common debate has been about the use of static EUI64 identifiers in the address itself, which serve as the host portion of the network address. The problem is that it's static (being derived from the MAC address of the network card), both on a particular network and between different networks. Becoming more common today are IPv6 addresses generated with privacy extensions, created randomly and not based on MAC addresses. This, however, only partially addresses the privacy concern, as your network prefix is still identifiable and it's not likely to change frequently, at least from one location.
I'll use my own IPv6 network, kindly provided by +Hurricane Electric (HE), as an example. I have a /64 prefix assigned (2001:470:26:3a4::/64) and connected via a tunnel to HE's network in Zurich. This means that, even though some of my devices change their address frequently, they all still share the same /64 prefix. And, unlike my old DSL line with a dynamic IP that changed daily, from a pool of IPs shared with hundreds of thousands of people, this network prefix is actually tied to me and doesn't change at all. HE makes a good effort to hide personal data, but I found it interesting that a WHOIS search on this prefix shows my actual country, postal code, and city - as I provided them to HE:
|contact:||Name:Private Customer - Hurricane Electric|
I can't complain too much - this isn't really too different than what is available for IPv4 addresses - although the accuracy - down to the town and ZIP code - is probably more accurate here than you'd normally have in IPv4 geo databases. I looked at a few other prefixes from the HE Zurich site and found tunnels with WHOIS data showing expected places like Romania, Austria, etc. But what's a bit more concerning here is that the RDNS record for the nodes of the tunnel* have DNS PTR records that include my username too:
So, taking my non-static IPv6 address 2001:470:26:3a4:e46d:de1e:28b4:4167, we can figure out that my tunnel endpoints, and then my registered country, city, post code, and username. If I'm still using EUI64-based addresses you've got my MAC address too. That's a little concerning.
I put together a quick script to iterate through the different IP spaces for HE and pull out which username is tied to which IP tunnel and the location information. With fields like andilpfm, sandro123, atomix1040, and zontama, I'm pretty confident that these are also usernames tied to their respective network assignments.
What also concerns me is the use of usernames in DNS, as by simply knowing someone's username you can find all of the tunnels and IPv6 prefixes they have assigned by simply iterating though DNS PTR records for <username>-1.tunnel.tserv<1-30>.<datacenter code>.ipv6.he.net.
I think HE made a good decision in not releasing names and email in the WHOIS data, while still allowing someone to identify roughly where a connection might be. It's useful for the customers to be geolocated to a city like we have in IPv4 environments, and tunneling means that adjoining blocks of addresses can be in entirely different countries. I think, however, that the use of usernames in DNS was probably not a great idea from a privacy perspective.
For sure there are different ways to be connected to IPv6. Carrier-based IPv6 (not currently available to me) might alleviate the concern of having a static prefix to be identified by if you're sharing a large prefix with thousands or millions of other people. Those trying to get IPv6 connectivity by tunneling, however, might be stuck with more of a privacy problem than we thought.
* - To calculate the tunnel endpoints - at least for HE - subtract one from the third group in an IPv6 address - 26 becomes 25 in my case - and replace the host portion with ::1 or ::2.