UTF-16 is a PITA if you're working outside the BMP. At that point you're dealing with variable size codepoints anyway and may as well use a more compact encoding.
There can be no "backwards compatibility" for an IPv4 successor because of the pigeonhole principle. UTF-8 is popular on modern computers with an 8-bit byte, conveniently leaving a whole bit free on the common ASCII text encoding and of course text is handled in sequences, so the multi-byte arrangement isn't inherently incompatible. However IPv4 doesn't have either a convenient spare bit which can be re-purposed, nor an interpretation where you just get to string more addresses together and that's fine. Your IPv4 packets contain exactly one 32-bit IPv4 source and one 32-bit IPv4 destination.
IPv4 packets and processing code have exactly one 32-bit IPv4 source/destination and would not work. That's not how I interpreted the request. I took the point as "IPv6 as a standard should have been designed to take an IPv4 address and convert it reliably to a specified IPv6 address, which we would set up to route to the same location." That is, old software that requested an IPv4 address could have it translated by the OS into an IPv6 packet before transmission deterministically, people with memorized IPv4 address could use them in the future, etc.
> That's not how I interpreted the request. I took the point as "IPv6 as a standard should have been designed to take an IPv4 address and convert it reliably to a specified IPv6 address, which we would set up to route to the same location." That is, old software that requested an IPv4 address could have it translated by the OS into an IPv6 packet before transmission deterministically
It appears you are asking for the "IPv4-mapped IPv6 addresses", which are of the form ::ffff:x:y, where xy is the 32-bit IPv4 address (there's even a special text format for these addresses, you can use ::ffff:a.b.c.d instead of having to convert the IPv4 address to hexadecimal). The only difference from what you are asking is that these addresses are routed through the IPv4 network; they allow applications written with only IPv6 in mind to still work with IPv4 networks.
Or you might be thinking of something like SIIT (Stateless IP/ICMP Translation), which uses addresses of the form ::ffff:0:x:y (which can also use the same kind of special text format as above).
48-bit is probably not enough; 64-bit was even considered in early IPv6 drafts and it was discarded because it wasn't quite convenient enough for all the routing magic that was intended to happen.
The syntax change of addresses: makes it easy for parsers to determine the difference between a v4 and v6 address. It basically hasn't affected adoption (do you think 6 octets would have changed that?)
I've never had the need to know the IP address of a DNS resolver from the top of my head. Either the IP address of a working DNS resolver is provided by DHCP or I just install a local caching resolver that recurses itself (e.g. unbound).
My alma mater's DNS servers:
18.70.0.160
18.71.0.151
18.72.0.3
DNS servers for work:
[redacted]
I've had to manually configure DNS about 5 billion times, these numbers just roll off the tip of my tongue. I work with lots of embedded devices, manual configuration is often necessary.
People don't use 1.1.1.1 1.0.0.1 (cloudflare) for external dns? It also resolves http/s requests, so it's usually my go to external endpoint for testing and troubleshooting. google.com is still my go to for domain resolution troubleshooting.
IPv6 isn't 6 bytes
It's 16 bytes. With your example it would be 10.20.30.40.50.60.70.80.90.100.110.120.130.140.150.160
Also we don't live in a world where you type IP addresses into your browser. DNS is an unfortunate case but generally you don't have to do it constantly at least.
> Also we don't live in a world where you type IP addresses into your browser.
On the contrary, I do that all the time, when DNS servers/clients haven't updated caches yet, when I need to update routing tables, configure servers, routers, load balancers, and if I can't remember an IPv6 and have a demo coming up in 10 minutes with no transparency on when DNS servers will update, I'm going back to punching IPv4 addresses in my browser for the screenshare because the IPv4 addresses of ALL the machines I control on a day-to-day basis roll off the tip of my tongue.
My personal website, my cloud instances for my day job, my side project cloud instances, ALL of their IPv4 are in my head.
I'm a walking IPv4 DNS server, I can't do that for IPv6 and all the double-colon-ffef nonsense.
The double colon is a place where IPv6 addresses are easier to memorize than IPv4 addresses. Double colon just means "fill with zeroes". You don't have to remember how many zeroes to fill in. You don't have to type in a long string of zeroes. You just need to remember the prefix and suffix.
If you are assigning all the IPv6 IPs by hand like you might in a private network, the suffix can be as short as you wish: prefix:: is your Device 0, prefix::1 is your Device 1, prefix::2 is your Device 2, prefix::f is your Device 15, and so forth. At that point you only have to memorize your prefix, which is just your subnet. If the subnet you are assigned is 2001:db8:: for instance you just need to remember that 2001:db:: as your prefix and add whatever device number you need after it. Sure, it's unlikely to have a prefix exactly that short, but sometimes you can luck out with a lot of zeroes. Private networking today (Unique Local Addresses) is fd00::/8 where you are expected to pick a 40-bit random string to make it a /48. That's just three groups to memorize for your entire private network: fd01:2345:6789::.
::ffef from that perspective implies you are accessing Device 65,519. If you are trying to remember that many devices you may have other problems.
On the flipside, if you are assigning your own IPv6 suffixes anyway you can also use school kid "1337" "calculator" hacks in hex like setting up a key servers to be ::beef or ::dead or ::dead:beef or ::feed or ::8008. Potentially way more memorable "words" than numbers just between 0 and 255.
I came to a similar conclusion. Something like 0000:0000:0010:0020:0030:0040 or (::0010:0020:0030:0040) probably wouldn't be the most elegant solution but it would have been a nice bridge between ipv4 and ipv6. However, the IPv4 systems would have to understand and talk IPv6 to properly communicate.
Specifically ::10.20.30.40 is for a system that speaks both, and ::ffff:10.20.30.40 is for a system that only speaks IPv4. You don't even have to convert to hex.
I had the thankful joy of looking into how DCHP works for a local ipv6 network.
It doesn't.
Android literally just ignores it.
So, want to set a static IP? Can't do it because half the devices people have just flat out refused to support it.
That means ipv6 doesn't even support all the features of V4, and you have less control of your network when you use it. Have a server you want with a known IP address? You can't do it. Not as far as I could see.
The solution? Have server itself runs a program to update your DNS to the right address.
It's so silly and convoluted. I'm sure there are reasons for it, but it's not something I was prone to adopt after looking into it
SLAAC IPv6 addresses are static IPs; they're directly derived from MAC addresses. Clients will usually receive additional IP addresses as part of the privacy extensions, but static IPs are enabled by default unless you're rotating the address space for some obscure reason. Both IP addresses will work, though for server purposes you obviously use the static addresses.
Basically, you have a static IP unless you have some kind of DHCP server telling you what address you should use instead. Even if your external IP changes, the "internal" part of your IP will remain exactly the same, despite being a routable device.
Maybe some shitty ISPs do this to extort customers into paying extra for static ranges? From the stories I've heard, I believe that some kind of American ISPs shuffles around ranges every week.
Either way, this is the same problem IPv4 suffers from: your external IP is often not static.
IPv6 is a different protocol from IPv4 so it's probably for the best that the addresses are not easily confusable.
And hexadecimal addresses are actually saner when dealing with classless addressing. The three-dot notation of IPv4 addresses is really a relict of the past which you'll notice each time you'll deal with anything other than /8 /16 and /24
I suspect you believe that IPv6 is just "IPv4 with bigger addresses", and furthermore that "IPv4 addresses are a subset of IPv6 addresses".
It isn't that and they aren't.
Low IPv6 adoption has nothing to do with dotted decimal address notation, and everything to do with IPv4 remaining good enough thanks to user acceptance of NAT and the concentration of power in today's network in the hands of a small number of large companies.
> Low IPv6 adoption has nothing to do with dotted decimal address notation
But disagree with this.
A LOT of the time some equipment of mine supports IPv6, but I continue to access it by IPv4 because I can remember the damn address. So I continue to use IPv4 a lot of the time, IPv6 kinda just sits there and rots, rarely used because the addresses and notation are unwieldy. I'm also bad at memorizing hex compared to decimal. Many times I can relate an IPv4 address to some important numbers in my life, friends' birthdays, past zipcodes, digits of pi I've memorized, holidays, musical melodies, etc. so they tend to be easier to remember.
I often update an A record and nobody except the heavens knows when the DNS server caches will update, when my clients will invalidate, often it's more reliable to just punch in the IPv4 off the top of my head when DNS is so unreliable about providing lighting-fast updates.
And then there are the DNS-poisoning Wi-Fi hotspots, I connect to some hotspot, go to http://myfoo.com/, get some stupid hotel login page, I just go "fuck it" and punch in the IPv4 instead and I'm in business.
You'd be amazed if you were working with networking in the early 90s before TCP/IP "won" over NetBEUI/AppleTalk/IPX, and the same was said then, those huge weird numbers were unwieldy and nothing an admin should have to remember.
Answer still the same, use DNS and stop caring for the large numbers.
Heh, well, they're owned by MS now. I wonder how much they've been forced onto Azure … which last I tried, didn't completely support IPv6¹.
And just yesterday-ish I got an email from Azure that "Basic" SKU IPv4s (yes, MS has SKUs for IP addresses…) are going away. And the new SKUs are more expensive… granted, it's not a huge expense, but it's lovely to pay for artificial scarcity.
¹specifically, managed PG didn't. Worse yet, it refused to operate on a dual-stack vnet, meaning it forced me to IPv4-only the vnet.
They may be commenting on the fact that there are multiple companies that are sitting on entire /8 ranges that could be unused, or potentially migrated to private ranges.
Azure would need to buy that space, which is over $40 per IPv4 address today. For a while it'll rise, and then suddenly it's worthless.
$40 is approximately the same as "rent" on Azure for an IPv4 address for a year.
Now, if Azure sells a block, that's revenue in the bank whereas if they let it out, the revenue depends on demand. And of course if they sell it they don't have it any more, if they let it out this year, and sell it next year for more money they keep both.
If they guess wrong, they're left holding the bag, addresses which nobody wants to lease and yet which no longer have resale value.
I have a dedicated server on Hetzner where I choose not to pay for IPv4 connectivity.
Using only IPv6 works fine most of the time but in 2022 there are still some services that are available only through IPv4, like GitHub.
However, I have both IPv4 and IPv6 connectivity from the places I connect to my server. Could I use that to get IPv4 connectivity on the server when I need it?
The answer is yes of course, and here is one way to do just that.
Replace dedicated-server-hostname with your server hostname or IP.
laptop> cat ~/.ssh/config
Host dedicated-server-hostname
RemoteForward 1080
laptop> ssh username@dedicated-server-hostname
server> cat ~/.gitconfig
...
# Using git on an IPv6 only machine that needs to access git repos only
# available through IPv4, e.g. github.com. The workaround is to use the
# network on the machine we connect from.
#
# This can be done by setting up a SOCKS proxy when connecting to the IPv6 only
# machine over ssh, see RemoteForward in ssh_config(5).
[http "https://github.com"]
proxy = socks5h://localhost:1080
We just ended up buying /28 subnet, because the whole v6 to v4 experience was too frustrating and would've probably cost more to solve all the issues (or hire someone who knew how to set it up properly) than to buy the subnet.
Nope. The packets are completely different. An IPv6 packet can only end up on an IPv6-capable host. If the two are going to speak to each other they need some kind of proxy.
It's not a proxy, but the 6to4 protocol that ISPs use to tunnel traffic. ISPs usually have IPv4s available, so they used it in the beginning of the IPv6 transition. However, there were quickly some problems discovered and the whole thing was deprecated after a few years.
Sites and services often rely on a lot of IP-based filtering and categorization, at the firewall level, to fight abuse and attacks. Routing IPv6 makes that more challenging. Dropping all IPv6 connections makes it easier. So, if you think you can get away with simply not serving requests from IPv6 addresses, it's tempting to do.
Considering GitHub has been the target of some of the biggest DDoS attacks seen to date, I wonder if they're concerned their current anti-DDoS measures wouldn't be as effective against an IPv6-based attack.
GNOME's and KDE's Gitlab instances also have IPv6 support.
Github laughably fails:
$ git clone -6 git@github.com:gitlabhq/gitlab-runner.git
Cloning into 'gitlab-runner2'...
ssh: Could not resolve hostname github.com: Name or service not known
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Gitea doesn't seem to support IPv6 either:
$ git clone -6 git@gitea.com:gitea/tea.git
Cloning into 'tea'...
ssh: Could not resolve hostname gitea.com: Name or service not known
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
I can't find any good public Bitbucket repository to test with, but they seem to have an IPv6 address available:
All of my current side projects are focused on lowering the barrier of entry for self-hosting. As much as I would love for all devices to have their own public IP address, I think that ship may have sailed.
Fortunately, I've found TLS SNI routing to be a viable alternative for most use cases[0]. I think the future of self-hosting looks like users paying a "VPN" provider in their local city. The provider gives them a shared public IPv4 address. All their devices use WireGuard to tunnel all traffic through the VPN. Incoming traffic sent to the user's domains (obviously requires coordination with a registrar) is routed by SNI. This setup has several benefits:
* All traffic outgoing goes through a VPN, preventing your ISP from snooping. VPNs are much more competitive than ISPs which makes them easier for me at least to trust.
* Since IPs are shared, users also benefit from "hiding in the crowd" for outgoing traffic.
* When hosting services, your actual IP is hidden.
* VPNs can compete on features like ability to handle DDoS attacks, auto LetsEncrypt support, domain registrar integration for auto DNS, etc.
[0]: caveat: I haven't played around with getting UDP to work.
You're really just shifting the trust to someone else. Someone who probably has a LOT more interesting data in one place that a nefarious party/advertiser/agency may be interested in collecting or observing, secretly or not. At least your ISP really doesn't care about your actual data, just that you're paying for service and not causing trouble.
>users also benefit from "hiding in the crowd"
IP addresses are not even really used anymore for fingerprinting. Your browser is a whole lot more unique in and of itself, regardless of the connection you're using, so it's more reliable to track that instead.
It sounds like you're trying to advocate for using VPNs for anonymity, which is the wrong solution. I would argue large MPRs like Tor/I2P do a better job at this, but even that is only part of the solution.
Note that I'm not a big proponent of current consumer VPN products. They're useful for some things, but I think people are generally confused about what those things are. But on a technical level, these companies are well-positioned to facilitate self-hosting. That's what I'm interested in. The egress benefits are fairly orthogonal to that as far as I'm concerned.
That said, what makes you think ISPs are less incentivized than VPNs to sell your data? There are VPN companies that have "proven" in court that they are unable to provide logs of user activity. That earns way more of my trust than I'd give any ISP.
> IP addresses are not even really used anymore for fingerprinting
IPs are used by ISPs for issuing DMCA emails.
> It sounds like you're trying to advocate for using VPNs for anonymity
I'm not. It's all about what you're trying to hide from whom. True anonymity is extreme and comes at a high cost in terms of performance.
I would love to know what exactly is the challenge GitHub is facing. No doubt it’s a limitation somewhere in GitHub’s internal tooling or architecture, and almost certainly a multi-variate sort of chicken and egg problem, but I would be fascinated to learn what.
69 comments
[ 3.3 ms ] story [ 104 ms ] threadEdit: I wish IPv6-only VPS providers could provide with CGNAT IPv4 access for these services.
The product management of IPv6 is terrible. They could have turned
10.20.30.40 (IPv4)
into
10.20.30.40.50.60 (IPv6)
where
0.0.1.2.3.4 just translates into 1.2.3.4
and everyone would be using it already. But instead they chose
fe04::fa23::://::23::::!!/45:234a::23ff
And guess who uses it? Nobody.
When I need DNS I know 8.8.8.8 just works.
What is the IPv6 Google DNS? Hell if I can remember.
It appears you are asking for the "IPv4-mapped IPv6 addresses", which are of the form ::ffff:x:y, where xy is the 32-bit IPv4 address (there's even a special text format for these addresses, you can use ::ffff:a.b.c.d instead of having to convert the IPv4 address to hexadecimal). The only difference from what you are asking is that these addresses are routed through the IPv4 network; they allow applications written with only IPv6 in mind to still work with IPv4 networks.
Or you might be thinking of something like SIIT (Stateless IP/ICMP Translation), which uses addresses of the form ::ffff:0:x:y (which can also use the same kind of special text format as above).
The syntax change of addresses: makes it easy for parsers to determine the difference between a v4 and v6 address. It basically hasn't affected adoption (do you think 6 octets would have changed that?)
I've never had the need to know the IP address of a DNS resolver from the top of my head. Either the IP address of a working DNS resolver is provided by DHCP or I just install a local caching resolver that recurses itself (e.g. unbound).
The external DNS I use now: 8.8.8.8 8.8.4.4
My alma mater's DNS servers: 18.70.0.160 18.71.0.151 18.72.0.3
DNS servers for work: [redacted]
I've had to manually configure DNS about 5 billion times, these numbers just roll off the tip of my tongue. I work with lots of embedded devices, manual configuration is often necessary.
Also we don't live in a world where you type IP addresses into your browser. DNS is an unfortunate case but generally you don't have to do it constantly at least.
On the contrary, I do that all the time, when DNS servers/clients haven't updated caches yet, when I need to update routing tables, configure servers, routers, load balancers, and if I can't remember an IPv6 and have a demo coming up in 10 minutes with no transparency on when DNS servers will update, I'm going back to punching IPv4 addresses in my browser for the screenshare because the IPv4 addresses of ALL the machines I control on a day-to-day basis roll off the tip of my tongue.
My personal website, my cloud instances for my day job, my side project cloud instances, ALL of their IPv4 are in my head.
I'm a walking IPv4 DNS server, I can't do that for IPv6 and all the double-colon-ffef nonsense.
Or use mDNS. If your whatever machine on IPv6 network is named abc just open abc.local in the browser. Done.
If you are assigning all the IPv6 IPs by hand like you might in a private network, the suffix can be as short as you wish: prefix:: is your Device 0, prefix::1 is your Device 1, prefix::2 is your Device 2, prefix::f is your Device 15, and so forth. At that point you only have to memorize your prefix, which is just your subnet. If the subnet you are assigned is 2001:db8:: for instance you just need to remember that 2001:db:: as your prefix and add whatever device number you need after it. Sure, it's unlikely to have a prefix exactly that short, but sometimes you can luck out with a lot of zeroes. Private networking today (Unique Local Addresses) is fd00::/8 where you are expected to pick a 40-bit random string to make it a /48. That's just three groups to memorize for your entire private network: fd01:2345:6789::.
::ffef from that perspective implies you are accessing Device 65,519. If you are trying to remember that many devices you may have other problems.
On the flipside, if you are assigning your own IPv6 suffixes anyway you can also use school kid "1337" "calculator" hacks in hex like setting up a key servers to be ::beef or ::dead or ::dead:beef or ::feed or ::8008. Potentially way more memorable "words" than numbers just between 0 and 255.
Specifically ::10.20.30.40 is for a system that speaks both, and ::ffff:10.20.30.40 is for a system that only speaks IPv4. You don't even have to convert to hex.
Yup you are correct. (At least for me). I just tried it from my ipv6-only vhost.
[www@localhost ~]$ ping6 ::ffff:8.8.8.8
connect: Network is unreachable
I had the thankful joy of looking into how DCHP works for a local ipv6 network.
It doesn't.
Android literally just ignores it.
So, want to set a static IP? Can't do it because half the devices people have just flat out refused to support it.
That means ipv6 doesn't even support all the features of V4, and you have less control of your network when you use it. Have a server you want with a known IP address? You can't do it. Not as far as I could see.
The solution? Have server itself runs a program to update your DNS to the right address.
It's so silly and convoluted. I'm sure there are reasons for it, but it's not something I was prone to adopt after looking into it
You will not subnet /64 without DHCPv6, even though you might need to.
Basically, you have a static IP unless you have some kind of DHCP server telling you what address you should use instead. Even if your external IP changes, the "internal" part of your IP will remain exactly the same, despite being a routable device.
Maybe some shitty ISPs do this to extort customers into paying extra for static ranges? From the stories I've heard, I believe that some kind of American ISPs shuffles around ranges every week.
Either way, this is the same problem IPv4 suffers from: your external IP is often not static.
And hexadecimal addresses are actually saner when dealing with classless addressing. The three-dot notation of IPv4 addresses is really a relict of the past which you'll notice each time you'll deal with anything other than /8 /16 and /24
Low IPv6 adoption has nothing to do with dotted decimal address notation, and everything to do with IPv4 remaining good enough thanks to user acceptance of NAT and the concentration of power in today's network in the hands of a small number of large companies.
And : 2001:4860:4860::8888
I agree with this,
> Low IPv6 adoption has nothing to do with dotted decimal address notation
But disagree with this.
A LOT of the time some equipment of mine supports IPv6, but I continue to access it by IPv4 because I can remember the damn address. So I continue to use IPv4 a lot of the time, IPv6 kinda just sits there and rots, rarely used because the addresses and notation are unwieldy. I'm also bad at memorizing hex compared to decimal. Many times I can relate an IPv4 address to some important numbers in my life, friends' birthdays, past zipcodes, digits of pi I've memorized, holidays, musical melodies, etc. so they tend to be easier to remember.
I often update an A record and nobody except the heavens knows when the DNS server caches will update, when my clients will invalidate, often it's more reliable to just punch in the IPv4 off the top of my head when DNS is so unreliable about providing lighting-fast updates.
And then there are the DNS-poisoning Wi-Fi hotspots, I connect to some hotspot, go to http://myfoo.com/, get some stupid hotel login page, I just go "fuck it" and punch in the IPv4 instead and I'm in business.
Answer still the same, use DNS and stop caring for the large numbers.
https://www.google.com/intl/en/ipv6/statistics.html
A healthy amount of traffic that is ever increasing.
And just yesterday-ish I got an email from Azure that "Basic" SKU IPv4s (yes, MS has SKUs for IP addresses…) are going away. And the new SKUs are more expensive… granted, it's not a huge expense, but it's lovely to pay for artificial scarcity.
¹specifically, managed PG didn't. Worse yet, it refused to operate on a dual-stack vnet, meaning it forced me to IPv4-only the vnet.
$40 is approximately the same as "rent" on Azure for an IPv4 address for a year.
Now, if Azure sells a block, that's revenue in the bank whereas if they let it out, the revenue depends on demand. And of course if they sell it they don't have it any more, if they let it out this year, and sell it next year for more money they keep both.
If they guess wrong, they're left holding the bag, addresses which nobody wants to lease and yet which no longer have resale value.
> Azure only owns so many
They can buy more. The breakeven w/ wholesale at their pricing is like a year.
(And at RIRs, AIUI, the global space is exhausted, and there are wait lists. AIUI, you can still buy addresses from others, though.)
Using only IPv6 works fine most of the time but in 2022 there are still some services that are available only through IPv4, like GitHub.
However, I have both IPv4 and IPv6 connectivity from the places I connect to my server. Could I use that to get IPv4 connectivity on the server when I need it?
The answer is yes of course, and here is one way to do just that.
Replace dedicated-server-hostname with your server hostname or IP.
check their help docs
See <https://en.wikipedia.org/wiki/6to4> for more information.
Github laughably fails:
Gitea doesn't seem to support IPv6 either: I can't find any good public Bitbucket repository to test with, but they seem to have an IPv6 address available: Or you could self-host Gitlab/Gitea/Github Enterprise on an IPv6 capable server, I suppose.Fortunately, I've found TLS SNI routing to be a viable alternative for most use cases[0]. I think the future of self-hosting looks like users paying a "VPN" provider in their local city. The provider gives them a shared public IPv4 address. All their devices use WireGuard to tunnel all traffic through the VPN. Incoming traffic sent to the user's domains (obviously requires coordination with a registrar) is routed by SNI. This setup has several benefits:
* All traffic outgoing goes through a VPN, preventing your ISP from snooping. VPNs are much more competitive than ISPs which makes them easier for me at least to trust.
* Since IPs are shared, users also benefit from "hiding in the crowd" for outgoing traffic.
* When hosting services, your actual IP is hidden.
* VPNs can compete on features like ability to handle DDoS attacks, auto LetsEncrypt support, domain registrar integration for auto DNS, etc.
[0]: caveat: I haven't played around with getting UDP to work.
You're really just shifting the trust to someone else. Someone who probably has a LOT more interesting data in one place that a nefarious party/advertiser/agency may be interested in collecting or observing, secretly or not. At least your ISP really doesn't care about your actual data, just that you're paying for service and not causing trouble.
>users also benefit from "hiding in the crowd"
IP addresses are not even really used anymore for fingerprinting. Your browser is a whole lot more unique in and of itself, regardless of the connection you're using, so it's more reliable to track that instead.
It sounds like you're trying to advocate for using VPNs for anonymity, which is the wrong solution. I would argue large MPRs like Tor/I2P do a better job at this, but even that is only part of the solution.
That said, what makes you think ISPs are less incentivized than VPNs to sell your data? There are VPN companies that have "proven" in court that they are unable to provide logs of user activity. That earns way more of my trust than I'd give any ISP.
> IP addresses are not even really used anymore for fingerprinting
IPs are used by ISPs for issuing DMCA emails.
> It sounds like you're trying to advocate for using VPNs for anonymity
I'm not. It's all about what you're trying to hide from whom. True anonymity is extreme and comes at a high cost in terms of performance.