India is leading IPv6 migration with 61.67% adoption
aelius.com
aelius.com
Edit: Removed google.co.in, the website[1] reported it that it does not support ipv6, Now I tried again and google is in green.
NAT was developed. CGNAT was developed. HTTP Host differentiation was developed. SNI was developed. STUN was developed. TURN was developed.
The main problem with IPv4 to IPv6 migration is the, frankly, overzealous utopia that "they will migrate anyway". Worse, it's very different that doesn't allow for a simple upgrade option of "IPv4, but longer addresses" because IPv6 is designed to be fundamentally different.
Which is more insulting considering that BGP was seamlessly upgraded from 65536 ASes to more than a million because they only changed the bits in an AS and nothing more. As a router developer, you only need to do the relatively minute changes of extended ASes than the (relative) mess that is IPv6.
I wanted to try installing the module into my router so it would pass the WebRTC test for STUN/TURN and perhaps make video even more efficient to allow point to point connection instead of having everything be relayed through a tertiary server, but there was no documentation and having never set up a STUN/TURN server before I couldn't get it to work. So I am dependent on what a third party has set up to facilitate connectivity.
In the old days, you'd just connect to an IP address and that was it.
One is connectivity. Even theoretically we should have the same network connectivity (so to speak), you can feel the pettiness when Hurricane-Electric and Cogent fought exclusively on IPv6 (https://www.theregister.com/2018/08/28/ipv6_peering_squabble...) I can't believe I'm saying this, but IPv6 isn't free (or at least costs the same as IPv4).
Second is security. Yes, the world is no longer scannable, but consumer routers are a dud when it comes to IPv6 security. This router (https://pierrekim.github.io/blog/2021-01-12-fiberhome-ont-0d...) has serious problems at IPv6 security, and because it's suffix is always at ::0000:0000:0000:0001 and you've eliminate around 18 bits more because of how networks are laid, you've got yourself an IPv6 botnet, which speaking by, how do you block them? A /64 would be a good start, but OVH provides a single address per server (https://www.ovhcloud.com/vps/compare/). That's it. Don't forget that fiasco with MAC addresses (https://datatracker.ietf.org/doc/html/rfc8981), but at least that's solved.
Third, IPv6 should just work as you said. I wish that's true, but embedded devices will trip you up badly. Some don't fallback to IPv4 and instead try and try again using IPv6. This would be a concern while transitioning, but even after that, some would be still stuck because their servers are only operating on IPv4!
Implementing IPv6 is not free lunch if you know the gritty details.
And every one of those has introduced its own security flaws and implementation bugs increasing the complexity of applications.
The thing is we would be addressing in 128-bit IP already if it was done the BGP way: just minimising the necessary changes to implement it. Look at the effectiveness of Itanium versus AMD64 at migrating customers: IPv6 feels like Itanium, while extended ASes work more like AMD64. Whoever designed IPv6 was focused too much at the theoreticals, than looking at what the real world is and then designing around it.
Or are we forever stuck with either going all in to IPv6 or the current hybrid?
I've asked a lot of people this question, and the only answers I've ever gotten are either impossible or already implemented by v6. Perhaps you will be the person to finally explain how to do it -- but as far as I can tell, it's just not possible, and I don't think it's fair to criticise v6 for not doing the impossible.
As a 'temporary' measure, Network Address Translation (NAT) was introduced so people could get one public IPv4 address and have multiple machines on the Internet behind it.
The trade-off was the machines behind the NAT mechanism couldn't be reached from the Internet. This isn't a big deal for most consumption-based computing (fetching mail, watching videos), but there are use cases where you want to be able to talk to the other system, so yet another set of technologies had to be invented to allow punching holes through NAT (UPnP, NAT-PMP, PCP, STUN).
But we're at the point in some place where there aren't even enough IPv4 addresses to give to ISP customers even if they're using NAT. So you have a private IP address for your home system, and then your router gets a private IP address on its "public" WAN connection, and you end up going two layers of NAT. There is an entire segment of IPv4 addresses (100.64.0.0/10) reserved for telco use and doubel-NATing:
* https://en.wikipedia.org/wiki/Private_network#Dedicated_spac...
* https://en.wikipedia.org/wiki/IPv4_shared_address_space
We can continue this NAT-upon-NAT(-upon-NAT) silliness, or we can simply make the up-front investment and start pushing out IPv6 in more places. Your router still provides firewall protection, but reachability is a lot more straight-forward because the (potentially double) address translation goes away.
Edit: fix a bunch of typos.
If you are on an IPv4-only or IPv6-only network, you can reach the other through various mechanisms.
A lot of mobile/cell networks are IPv6-only, and so the telcos need a way to allow clients to reach IPv4-only systems.
Downside of CGNAT and NAT at home is difficulty of getting some services to work, or hosting a server.
Any randomized ipv6 address from that block is still as "unique" an identifier as an ipv4 address.
The more dysfunctional is your internet connection, the more prova you youve got
On my personal router?
But otherwise, it is possible to enumerate devices behind NAT (obviously, only those that communicate with the world in front of NAT) and assign traffic to them.
Do you have cookies on or off in your web browser settings? If they're enabled then you're being tracking regardless of your IP.
I have my router reboot every night and so I get both a new IPv4 address and a new IPv6 prefix everyday. If I have cookies disabled, then ad folks will have to find other ways to track me beside those two.
But there is also a fundamental limit of 2^16 = 65536 concurrent connections, right?
In other words, NAT works on the five-tuple of: protocol, source IP, source port, destination IP and destination port.
Er, that's a slight exaggeration. It's not uncommon to have 2,000 or more NAT clients behind a single public IP address. 2K * 4B = 8 trillion possible hosts... about 1,000 hosts per living person.
[0] https://anderstrier.dk/2021/01/11/my-isp-is-killing-my-idle-...
NAT was the bandaid that became the permanent solution. It was never meant to be permanent, but because of these, so many weird hacks and designs have been made to compensate for it.
That can also be pretty awesome given that so many devices now may not work in the interest of their users.
It is a hassle for IOT, but we have long since then solutions for that and maybe those are better anyway.
My provider only supplies IPv6 and you always connect to IPv4 through a transport. That is sometimes down or has too many concurrent users. Makes the net almost unusable still. Perhaps I should learn Hindi.
This is going to open up a can of worms once everybody gets global addresses and can’t figure out how to configure their firewall.
https://www.enterprisenetworkingplanet.com/security/qa-behin...
In any case, people manage to do both NAT and firewalls on v4 today so I don't see why they'd suddenly be unable to do firewalls in v6, especially since you don't have the complication of needing to figure out NAT as well.
The large address space also helps a lot, because it makes it much harder to find servers on v6 (including deliberately exposed servers, e.g. cameras or NASs that people want to access from a different network), compared to v4 where you can enumerate all active servers over the entire internet without much trouble.
Your other part is security through obscurity, and I can think of at least 2 ways to scan the entire address space in a short amount of time. So nope doesn’t count either.
You're not going to exhaustively scan the entire v6 space in any short amount of time. It is possible to whittle down the space you need to scan, but only moderately. It's still rather unviable compared to v4.
And scanning IP spaces is insanely easy to parallelize and uses so few resources an arduino can be used to scan. Given enough nodes it’s instant. And with every windows box on the planet globally routable, bonets will never be stronger.
But let’s pretend this is true and say it takes too much time. What about when it doesn’t? What happens to your security via obscurity then?
> And scanning IP spaces is insanely easy to parallelize and uses so few resources an arduino can be used to scan. Given enough nodes it’s instant.
You're underestimating how big v6 is. Scanning a single /64 takes ~737 million terabytes of traffic. If you used a trillion Arduinos in parallel you could scan 2^40 /64s simultaneously, and it would only take 1870 years for the scan to complete, assuming that every single one of both the Arduinos and the target networks have a 100 Gbit/s internet connection each. Your power consumption would be... about the same as Italy's, which is actually the most reasonable part of all this (except I assumed the 100 GBit/s network connections would take no power).
> And with every windows box on the planet globally routable, bonets will never be stronger.
You're thinking about botnets that spread by brute force scanning, right? But as mentioned, this will be substantially more difficult on v6, to the point that network scanning won't be a very viable technique for spreading a botnet. On top of that, most Windows machines will be behind two separate firewalls, so I don't see how them being globally routable will make botnets stronger. Given that it'll be harder to find targetable hosts, I'd instead expect botnets to be weaker than ever.
Also, remember that a lot of botnets spread by exploiting servers that were deliberately exposed to the internet. Making these hard to find is the only defence they have, and it's not possible on v4. NAT can't help either, however it works.
An insecure, hard-to-find machine is still an insecure machine, but making it difficult to find vulnerable hosts makes it harder to build a botnet, which leads to a very real increase of security on the internet as a whole. Even if a few machines are found, nothing much happens to the overall security so long as it remains hard enough on average.
Think of it as being something like vaccination for the internet.
Test it with a consumer level router, stock configuration. I'm not concerned with networks that have split NAT / firewall devices. These are setup by people that know what they're doing.
> A router that's NATing outbound connections will allow inbound connections through unless there's also a firewall.
Yes which is my chief complaint. Not getting rid of NAT, pushing the firewall to the client.
> Scanning a single /64 takes
Why are we the entirety of the 64 subnet? You can use some knowledge about networks to cut this down a lot. Just the one knowing a network is there is enough.
Then you're also assuming people won't group together on this. Lists will be sold in short order, making the search space even smaller.
You're still hiding security behind it being hard to scan because of a large number, so that will quickly be invalidated.
And then if someone say hides in the middle of their /64 and changes their address every hour the attack will then change and it will become focused with malware or other means, except there won't be a fronting NAT protecting them to stop inbound requests.
> Think of it as being something like vaccination for the internet.
What does this even mean? How does a computer get a vaccination?
I hooked the router up to my network, and then hooked my laptop up behind the router. The router's WAN address is 192.168.4.101, and my laptop got 192.168.1.9. If I try to connect outwards from my laptop, the connection appears to come from the router's WAN address:
18:47:04.854781 IP 192.168.4.101.45598 > 209.216.230.240.80: Flags [S], seq 3415044640, win 29200, options [...], length 0
18:47:04.988960 IP 209.216.230.240.80 > 192.168.4.101.45598: Flags [S.], seq 2572527210, ack 3415044641, win 65535, options [...], length 0
18:47:04.990322 IP 192.168.4.101.45598 > 209.216.230.240.80: Flags [.], ack 1, win 913, options [...], length 0
18:49:32.400441 IP 192.168.4.2.58084 > 192.168.1.9.9999: Flags [S], seq 2394060892, win 64240, options [...], length 0
18:49:32.431718 IP 192.168.1.9.9999 > 192.168.4.2.58084: Flags [S.], seq 3958961179, ack 2394060893, win 28960, options [...], length 0
18:49:32.432013 IP 192.168.4.2.58084 > 192.168.1.9.9999: Flags [.], ack 1, win 2008, options [...], length 0
> Yes which is my chief complaint. Not getting rid of NAT, pushing the firewall to the client.
v6 doesn't necessarily push the firewall to clients. You can and generally do still firewall on your router.
> Why are we the entirety of the 64 subnet? You can use some knowledge about networks to cut this down a lot. Just the one knowing a network is there is enough.
I know you can cut the search space down somewhat, but it's still massively bigger than v4, and therefore it's still going to be harder to find servers via scanning in v6 than in v4. NAT won't help in the slightest with this.
I'm not trying to suggest that anybody's security should (or even could) rely on hiding their hosts in a big sparse network; you should obviously run a firewall, and pretty much every consumer router does in fact do that. I'm just saying that if somebody does run without a firewall -- or deliberately configures it to permit inbound connections -- the large address space reduces exposure simply by making it harder to find any listening servers.
> What does this even mean? How does a computer get a vaccination?
It means that there's some conceptual similarities between the two situations. With vaccines, it's possible to completely stamp out a disease even if a small percentage of vaccinated people still catch the disease in question.
Similarly, even if a small number of servers are found by brute force scanning, so long as it remains hard enough to do so on average brute force scanning will remain an unviable method of spreading malware. This won't eliminate malware in general (because there are plenty of other infection routes to use) but any malware that relies on exploiting random vulnerable servers is going to have a much harder time in v6, not a much easier time as you assumed above.
Nope firewall on. You're still missing the point. Consumers will disable their client firewall once it interferes with something they're trying to do. A physical NAT device with a firewall won't allow this easy circumvention as those who don't know what they're doing won't generally go mucking around their router settings. They will click a button though, and if they have malware on their machine they can disable it via software means. Firewalls are also software, and just like all software they have bugs. There's an old one where sending certain DNS queries through windows firewall would disable it entirely.
> v6 doesn't necessarily push the firewall to clients. You can and generally do still firewall on your router.
Again you're not thinking of the entirety of the changes here. v6 on its own won't, but the entire point of global link addresses is to avoid NAT and other things. Further, the firewall must remain, but it must be easily and programmatically configured. This leaves pushing it to the client, or leaving exactly what we have today.
> I know you can cut the search space down somewhat, but it's still massively bigger than v4, and therefore it's still going to be harder to find servers via scanning in v6 than in v4. NAT won't help in the slightest with this.
NAT won't, but a firewall will.
> the large address space reduces exposure simply by making it harder to find any listening servers.
Reduces exposure, but does not eliminate it. Agreed though, it is harder to scan ip6 space than ip4, but not impossible
People are still running with firewalls on their routers in v6; that's the default basically everywhere.
> Reduces exposure, but does not eliminate it. Agreed though, it is harder to scan ip6 space than ip4, but not impossible
Yup, it's definitely not impossible, but it should be hard enough that the majority of the few unfirewalled Windows machines won't be found, which should weaken botnets rather than strengthen them.
IPv6 will also simplify a lot of things (being able to scrap NAT (note, you will still need a firewall) and avoid protocol issues for End-to-End services) but that is just a bonus.
The idea of P2P in competitive videogames strikes me as absolutely insane
With NAT, you can still receive DoS attacks, still have your game networking exploited, and still be geolocated. The only remotely security-related benefit is that instead of your ports being exposed to the wild internet, they're exposed to your router which is more of a side-effect rather than an actual benefit. Its not a reason to not bother having a firewall.
What's insane, is the idea that you want me to use and pay for some crappy AWS server that spies on my data instead of directly connecting to my friend using my own equipment
CG-NAT doesn't really prevent geolocation. Better services will still pin-point you to the nearest city. There are perhaps easier ways to get your private info or your money - phishing and ransomware seem to be still very popular. Don't have to hack games that only relatively few people have. It is more profitable to attack a bigger market or more wealthy institutions or companies in foreign countries. Also, if you hack the central game server, you will have a lot more victims... Choose your poison.
I guess, there are no games or other software that cannot be audited in high security installations. At home, having a work computer and a game computer (or a VM with GPU pass through or whatever) might be a safer choice in any case independent of IPv4 or IPv6 usage or the quality of your firewall.
If you have security issues that is because you failed to configure your firewall properly. Besides Internet was always supposed to work the way IPv6 would allow.
It is. Considering the kernel access often given to multiplayer games for anti cheat, and the abysmal attention to security and ability to write secure code by the average application developer, letting Internet randos send arbitrary instructions directly to your machine may not be the best idea.
Unless you care about security of course. “A user” in your sentence can quite frequently be vulnerable or malicious software.
I want ipv4 dead as well but to bury your head in the sand and pretend NAT doesn’t offer the protections it does only hurts your argument.
> Besides Internet was always supposed to work the way IPv6 would allow.
Yep, but the real world - where all of the unpatched IoT devices are running - has NAT at basically every home protecting devices from unsolicited connections.
But even then, the added security of a stateful firewall as provided by a router is dubious. You know what else has a "stateful firewall"? Your kernel's TCP/IP stack. It isn't gonna accept random connections from the Internet unless there is an application actively listening to a port and accepting packets. And I trust the Linux/NT/BSD kernel to be more secure with ensuring that than a binary firmware blob from a router manufacturer.
> But even then, the added security of a stateful firewall as provided by a router is dubious. You know what else has a "stateful firewall"? Your kernel's TCP/IP stack. It isn't gonna accept random connections from the Internet unless there is an application actively listening to a port and accepting packets.
That’s the fucking problem. All kinds of vulnerable/misconfigured software just binds to 0.0.0.0:<whatever> and calls it good. My fridge does this, my washer does this, my TV does this. This is the world of IoT.
> And I trust the Linux/NT/BSD kernel to be more secure with ensuring that than a binary firmware blob from a router manufacturer
It’s not, it takes a single API call to have a program start listening because that’s the entire job of the kernel. You have to configure a firewall on top of it to make sure vulnerable software isn’t exposed to the internet.
Stateful NAT does imply state tracking, which is a major component needed to implement a stateful firewall, but it is not itself a stateful firewall.
This works for us, but what about average people who have no idea what a firewall is?
https://help.steampowered.com/en/faqs/view/1433-AD20-F11D-B7...
I vividly recall an incident where Jio's CGNAT was dropping idle TCP connections after 10 seconds of idle. (They fixed it, but I don't know if they fixed it for all destinations or only special destinations).
And, of course, I say dropping, rather than closing, because NAT usually doesn't send FINs to close sessions when they're dropped. So you only find out when you try to send more data. Some NATs don't even send RST when you send data on a connection it dropped, so you have to wait for a timeout.
There's also a capacity issue. If you're serving your website via a single IP (common with load balancers), you can only have 65535 connections from each client IP (assuming https on port 443 only, using non default ports is often a non-starter); if the user's ISP is sharing a very limited pool of IPs with a large number of users, it's conceivable that all the connections to your site could fill up.
Unless each of your users is establishing 600 connections to your site, this isn’t a realistic issue. I don’t know of ISPs that go beyond 1000:1 over-subscription.
So at a minimum IPv6 gets us back to the end-to-end principle where Internet peers connect directly to each other without having to negotiate with the network itself. There are a few other advantages, like the fact that users can get large, publicly-routed addresses spaces for their own use (e.g. ISPs giving users a /56 prefix), simplified bridging of private networks (very low probability of collisions in the private IPv6 range), simplified router configuration (link-local addresses are always available so there is no need to assign numbers to every link), and other assorted niche benefits. In theory IPv6 should mean routers become more efficient because it is easier to aggregate prefixes, which should generally benefit Internet users by reducing latency (though at this point there is not much room left for improvement there).
A few years ago when forcing Reddit to IPv6 through /etc/hosts many pages resulted in 500 errors, but they gradually fixed them.
If you deploy IPv6, you might not deploy CGNAT, but unless you are dual stacking, something functionally equivalent is required.
As to scaling costs, IPv6 offload isn’t a 1:1 replacement for IPv4 or CGNAT capacity. You need enough capacity to carry the IPv6 traffic over IPv4 in case your IPv6 transport, transit or peers fail. Again, not optional.
Thus in a properly designed network these are not optional costs.
The failure mode for your v6 failing is the same as it is for v4 failing in a v4-only ISP: stuff breaks. If you want to fix that you need a redundant failover setup, which is the same thing you need in v4 except cheaper because it doesn't need to do CGNAT.
Surely you need enough IPv6 capacity incase your IPv4 transit fails as well. If JIO could have built enough IPv4 capacity to run their network over IPv4, they would have, but they can't, so they've been pushing IPv6 hard.
I’m not familiar with JIO’s setup, but that’s an interesting question. If their IPv6 was down, would their network still be able to deliver? Would they run out of CGNAT capacity or IPv4 translations?
IPv6 is no longer optional for them. I suspect it's not optional for T-Mobile USA either. Or Facebook/Google/Netflix.
Or have I been living with Canadian ISPs too long and that sort of thing doesn't happen in the rest of the world?
Improved latency mean improved responsiveness, and that in turn has companies claiming improved user retention and sales.
If you need an argument to support ipv6, those seems like good reasons to support ipv6.
What I want to know is do all these studies take into consideration the “happy eyeballs” algorithm that prefers IPv6 over IPv4 in web browser requests, thus delaying the IPv4 request?
Route aggregation or selection does not impact forwarding performance on a router.
In some cases, yes, the routing table size will impact performance; for example if the FIB is too big to fit in TCAM:
Note that this particular incident was caused by deaggregation of routes announced by Verizon, and that had the routes been properly aggregated it could have been avoided (though normal routing table growth would have eventually caused the problem anyway).
Geoff’s article on TCAM exhaustion is almost 10 years old. No BGP router in the default free zone has had a 512k route limit in years. Modern routers typically scale to millions of routes.
The incident in question was the result of misconfiguration and/or ISPs trying to run old routers past their usable life.
The whole thing was completely avoidable and not related to IPv4 vs IPv6 forwarding performance.
As to the IPv6 latency article, it can best be summarized as IPv6 sometimes has lower latency than IPv4, except when it doesn’t.
In no shape, way or form does the article claim that IPv6 forwarding performance is better than IPv4 forwarding performance.
There’s some hand waving about NAT, but it also notes that increasing the number of NAT levels improved latency!
The simplest explanation is that the differences come down to different routing policies in IPv4 and IPv6. Thus it depends on where you stand as to what you see.
In practice this is only a small part of final performance, so you need to do end-to-end measurements to get a proper idea of what people will experience. Both Facebook[1] and Apple[2] have done that, showing 10% faster page loads and 40% faster connection establishment respectively on v6. Even if that was solely down to routing policies, it's still a measurable difference.
[1] https://engineering.fb.com/2015/09/14/networking-traffic/ipv...
[2] https://www.sidn.nl/en/news-and-blogs/apple-connections-esta...
I would have thought that an app that is purportedly an app for site X but that cannot actually talk to site X when on an IPv6-only network would fail that requirement, but maybe I'm overestimating what Apple actually checks. Are they only checking that the app will correctly attempt an IPv6 connection to the site?
That means the app internally needs to be able to handle IPv6 addresses and not hardcore any IPv4 addresses as those can’t be reached. There’s no requirement that the service underlying the app is directly reachable via IPv6.
Apple's requirement is that even though you know your server is definitely 10.20.30.40† on the public network, and you hate IPv6 you must not hard code 10.20.30.40 inside the app and ship that to the App Store.
Once you reluctantly change it to a DNS name ten-twenty-thirty-forty.fuck-off-apple.example that resolves to 10.20.30.40 - Apple allows that.
Because now when your app is used on some IPv6-only carrier network, the carrier goes "ten-twenty-thirty-forty.fuck-off-apple.example ?" and it gets 10.20.30.40 and it says that's an IPv4 address, don't use those around here, and it adds a translator step, it gives the phone an IPv6 address for ten-twenty-thirty-forty.fuck-off-apple.example and the phone connects to that address, which is a translator that connects to 10.20.30.40 on the IPv4 Internet.
This stuff happens all the time and you don't notice. But if Apple allowed app vendors to just scribble IPv4 addresses inside their app software it would break.
† No that isn't a public IP address. It's an example.
“The blocks 192.0.2.0/24 (TEST-NET-1), 198.51.100.0/24 (TEST-NET-2), and 203.0.113.0/24 (TEST-NET-3) are provided for use in documentation.”
— RFC 5737, IPv4 Address Blocks Reserved for Documentation https://www.rfc-editor.org/rfc/rfc5737.html
(No I don't use RFC1918 addressing at home; Yes, every machine in my home has public IPv4 and/or IPv6 addresses; No that doesn't make it "really easy to break in" because having an address is not the same thing as being accessible)
$ dig +short AAAA www.hotstar.com
www.hotstar.com-sni.edgekey.net.
e35862.dscj.akamaiedge.net.
2600:140f:7800::1730:f420
2600:140f:7800::1730:f421
2600:140f:7800::17d7:d7b9
2600:140f:7800::17d7:d7a9
2600:140f:7800::1730:f449Just mandate that every ISP must provide IPv6 for new contracts within a year and then for all existing contract within two - or whatever reasonable timeline - and be done with it.
In opening another tab to answer my own question, I see that they've broadened the scope and that the US government networks should be IPv6-only, with some caveats I'm sure, by 2023: https://fedtechmagazine.com/article/2021/03/how-make-progres...
The linked article isn’t as ambitious as to claim IPv6-only government networks by 2023, only that new systems should support IPv6 by 2023.
I’d also be very surprised if the government was able to hit any of the IPv6-only targets put forth in the article.
To truly drive IPv6 adoption there has to be a real need for IPv6 and/or a revenue driver.
Very large ISPs and mobile carriers need IPv6 because they are simply running out of IPv4 addresses, even non-public IPv4 addresses!
This still does not mean they can go IPv6-only, they still need IPv4 and translation technologies to reach the Internet.
The core problem of IPv6 adoption is that insensitive do not align across the whole Internet ecosystem.
Which is more than they are doing now.
What real-world issues do you forcee. IPv6 either works, or doesn't
Oh, you sweet summer child! :)
IPv6 “just works” only if you completely control the routing stack end-to-end.
Once end user equipment and hosts are introduced into the network all bets are off.
In a mobile network, where the carrier controls what user terminals are allowed on the network, it is at least nominally possible to achieve “just works” status.
So, in the real world, forcing IPv6 would result in IPv6 being supported only in a particular configuration used in a particular way. Everybody will be told to go pound sand and no effort will be made to keep IPv6 working or prevent breakage.
Right now though, we'd be more in need of "websites and -services larger than X have to support IPv6".
I can just about imagine the shitstorm and political blowback that would entail.
Even just forcing IPv6 support would be a tough row to hoe.
It would potentially help them to take it more seriously if there were planned outage windows (i.e. "IPv6-only for 1 day after the law was passed, then IPv6-only for 1 week 6 months after, then permanently IPv6-only after 2 years").
ISPs would probably just take the 1-day outage and ignore customer complaints for a day. By the time the week long outage would come closer without the date being delayed, they'd start taking the issue seriously.
And who exactly are you forcing? Now it’s ISPs, in your previous comment is was websites.
Anyway, it’s not enough to force one participant. If you are going IPv6-only by decree, you have to replace all end user devices too.
Who is going to pay for all the new routers, game consoles, nanny cams, etc? I’m sure that container ships’ worth of PS5s is going to go well over in the appropriations committee.
The truth is, it’s too late in the game for an IPv6 flag day. Too many people and too much money involved.
Yes, also known as the US government, because that's where those services are located, and who ultimately controls 99% of the Internet through .com/.net/.org.
"Domains with more than (some definition of "big") under .com/.net/.org must not point to nameservers announcing A records for any of the subdomains. DNS server operators serving more than X clients must report aggregate statistics."
Is it practical? Realistic? A good idea? Probably neither. But it would be a feasible way to ensure IPv6 support, with worldwide effects.
> Now it’s ISPs, in your previous comment is was websites.
The government forces website operators to offer only IPv6. As a result, ISPs that don't support IPv6 are about as useful as a provider that drops a wet string at your doorstep. Thus, in order to be useful and deliver a service worth paying for to your customers, ISPs would be forced to support IPv6, even without a legal mandate.
Due to the dominance of US web services, the US doing this would force this upon ISPs worldwide.
> you have to replace all end user devices
In most cases, not the devices, only the software, or rather, the configuration on it.
> container ships’ worth of PS5s
The PS4 and 5 support IPv6 according to what I found. https://toreanderson.github.io/2021/02/23/ipv6-support-in-th...
Most importantly, in the proposed model, Sony would most likely fall under "larger than X" if services were included, i.e. they'd have to switch to IPv6-only too (and issue updates to support that or leave their users stranded).
Maybe add an exemption for services supporting systems last sold more than X years ago.
I sincerely wish the US would try a stunt like this, if not for anything else then for the entertainment aspect. I emphatically don’t think it would work out as you’d expect.
Can you expound on why you think this is the case?
The IETF really needs to fix this issue in particular, it’s the last big hurdle in seeing adoption IMO.
Is using ULA and NPTv6 any worse than using NAT44?
ipv6 is not backwards compatible with ipv4.
Consequently adding support for ipv6 requires a dual stack solution (since supporting ipv4 is a must).
An alternative solution to the problem of the limited number of ipv4 addresses has been reliance on NATs. This is much simpler than supporting ipv6 and is already widely adopted everywhere, and so that's what people are choosing to do.
The obvious conclusion (from a casual observer like myself): the successor to ipv4 has to be backwards compatible with it, similar to how UTF-8 is backwards compatible with ASCII.
EDIT: I should note that I am not a network engineer, so if anything I have written is incorrect, I hope someone corrects me.
I've seen this objection, and I do not see how it could be otherwise.
If all the code out there was for 32-bit-only addresses (of IPv4), then expanding the addresses space to something >32 bits would entailed updating every single IP-capable code. Which is exactly that needed to be done for IPv6: every device needed to have code updated (and this included 'hardware code' of things like ASICs).
While UTF-8 is backwards compatible with ASCII, it did of course require programmers to add support for it just like you are suggesting any successor to IPV4 would. But once that support was added, ASCII could be treated as part of UTF-8 standard.
From what I understand, this is not the case with IPV6 and IPV4. The former requires its own software stack and the IPV6 standard was written (from what I have read) without any attempt to make it possible for IPV4 and IPV6 addresses to coexist in the same software stack easily.
It's not like an actual pipe where one end doesn't care where the other end is. The recipient of a packet has to know where to send the reply.
So while a host with a larger address could easily talk to a legacy host with an older, smaller address, the legacy host couldn't reply because it wouldn't know how to address it.
So, just like expanding address space (IP: 32-bit to 128-bit; ASCII: 8-bit/1-byte to multi-byte), you had to rewrite all the software to handle things.
https://en.wikipedia.org/wiki/IPv4_mapped_address#IPv4-mappe...
The main reason I don't like it - it is much more complex than IPv4 and this complexity provides from little to now real benefits (but a lot of advertised by IPv6 evangelists). The only reason networks migrate to IPv6 is the scarcity of IPv4 addresses, not other features which was envisioned as improvements over IPv4, but on practice turned out to be not very useful.
128bit per address from which usable only 64bit looks like a waste of resources (CPU/RAM) to me. Idea was to embed MAC-address in lower 64bit, but it turned out to be a bad idea because of privacy implications and for most end-user devices lower 64bit are now random. Given that /64 prefix in most cases used by single host a 64bit address would be sufficient. If we had 64bit addresses we would save RAM for routers and OS kernels and simplify implementation (64bit integers are available in practically all modern programming languages and 64bit operations are fast, while 128bit is a slower extension which is not universally available).
For me IPv6 is an example of the second-system effect: https://en.wikipedia.org/wiki/Second-system_effect
If I were running an ISP, I would migrate the backbone network to IPv6 and just use embedded IPv4 addresses to avoid the headaches that come with router-to-router IPv4 links. With IPv6 you always have a link-local address on every port that can be used by routing protocols without relying on proprietary solutions that are not interoperable between vendors or having to assign an IPv4 address (and hoping that you assigned a large enough subnet for future growth). It is much easier to scale up an IPv6-only network and much easier to connect one IPv6-only network to another.
Of course IPv6 is not perfect. SLAAC did not really work out as planned and now we are stuck with an annoying mix of SLAAC and DHCPv6. Reverse-DNS is still a bit of a pain. IPSec is not what it should have been and too many IPv6 standards rely on IPSec for security/authentication. Even so, the core of IPv6 is a huge improvement over IPv4 for individual users, small network operators, large network operators, and the Internet as a whole.
My experience is the complete opposite. Lot of software is still very immature when it comes to IPv6. A prime example is that I had to abandon pfSense because it just didn't handle prefix delegation. And no, switching ISP is not an option for me.
I'm now on OpenWRT which is miles better, but getting IPv6 to play nice is still lot more work. For example there were a lot more steps to getting split-horizon DNS working compared to regular IPv4.
> Even so, the core of IPv6 is a huge improvement over IPv4 for individual users, small network operators, large network operators, and the Internet as a whole.
Maybe in another decade or two when IPv6 and the ecosystem around it has matured a bit. Though it still seems to have a lot of moving parts compared to IPv4, thus requiring more to keep track of.
A total length of 64 bits would be too small for the eventual size of the internet. Our choice was between deploying something with too many addresses or something with too few addresses, and the former is by far better than the latter. We do not want to be going through another IP family transition to increase the bit length again, so we need to get it right the first time.
v6 mostly just took v4 and made the addresses longer, so I'm not sure it's reasonable to describe it as bloated. About the only thing it actually adds over v4 is SLAAC (and IPsec, but that was immediately backported to v4).
Even home consumers are getting at least a /64. Unless you're expecting consumers to start having ~2^64 devices, it doesn't seem like anyone is concerned with the public internet needing more than ~2^64 addresses.
By the time you've gone through six levels of allocations (IANA -> RIR -> ISP -> Customer -> Network -> Device) the vast majority of the total address space will be unused -- or rather: used for the purpose of aggregation, but not used for end machines. A 64-bit address space might only reasonably be able to handle something like 2^40-2^48 devices in total, which isn't that much more than we already have today.
> Unless you're expecting consumers to start having ~2^64 devices
You'd definitely need something longer than 64 bits long, long before this point.
v6 has enough space to give everybody multiple networks, not just multiple addresses (and those networks are always big enough for however many devices you end up attaching to them).
* is roughly equal to 4 300 000 000 (4e9, 4B)
* it is also the maximum number of IPv4 addresses
Going back to math class:
* 2^64 = 2^(32+32) = 2^32 * 2^32 = (4B) * (IPv4 Internet)
So a single /64 IPv6 subnet can hold four billion IPv4 Internets worth of systems.
But given all the drama with IPv6, I think it was reasonable to go with 128-bit addresses just so we don't have to go through all of this again.
On a related note, messing up the assignment of IPv6 address was actually accounted for. If you look at any unicast address that's currently live, you'll see that it begins with a "2". This is because addresses are only being assigned from 2000::/3:
* https://www.iana.org/assignments/ipv6-address-space/ipv6-add...
If, for some reason, we realize there's a mistake in how things were done with that space, it will be declared legacy/deprecated, and IANA will start over with addresses from 4000::/3. If that is screwed up, then 6000::/3 will be next, then 8000::/3, a000::/3, and finally c000::/3.
So the Internet community has six tries to get IPv6 addressing correct.
I would recommend you check out Tom Coffeen, who wrote a book on IPv6 address planning for O'Reilly. Even with half the bits going to the subnet, there is a astronomical amount of addresses available:
Yes, the current incumbents will buy up all the IPv4 addresses they can before trading stops. That will cement them as the permanent winners for IPv4 services.
But with IPv4 addresses no longer tradable, hosting companies and ISPs will have no choice but to adopt IPv6 if they want to grow. New hosting companies and ISPs will be IPv6-only.
I'd expect at that point most large mobile networks, which are largely IPv6 already with IPv6 compatibility bolted on so customers can reach IPv4-only sites, to go IPv6-only.
There will be legacy applications that still need a real IPv4 address on the server side. The current incumbents will end up cemented as the winners of that service.
The incumbents would become king makers. They would decide which services would be allowed on the IPv4 Internet, which would be the only Internet, and which services would be allowed to prosper.
The incumbents would either acquire all successful startups and smaller companies or clone their services.
New entrants would wither on the wine on this obscure IPv6-only network that hardly anybody knows about or is able to access.
This would also kill off IPv6 completely. The incumbents would have a collective interest in maintaining and propping up their position. IPv6 would be a threat to this, so it would be given the axe.
This isn’t some far out fantasy either. This is how mobile phone services worked during the SMS era before the Internet was a thing.
Letting them keep IPv4 resulted in them dragging their ass, implementing NAT everywhere and killing end-to-end conectivity on the internet, repurposing IPv4 as a reputation system, god knows what else. We gotta get rid of it.
Waste and chaos matter. Or how is your pandemic going?
The adoption timeline matches Google's stats here
Ultimately the goal of IPv6 is to end IP scarcity. But it can only do this if close to 100% of users and services use IPv6. Seeing it like that it doesn't really matter much if IPv6 adoption is 30% or 60% or 90%. In none of these situations would an ISP connect its customers via IPv6 only or would anyone provide any service that requires IPv6.
I really wonder how IPv6 should ever become mainstream without any deployment strategy. "Let's tell everyone that IPv6 is nice and we need it due to lack of v4 addresses" obviously hasn't worked for more than 20 years.
Similarly for hosting providers: as IPv4 addresses get more expensive, they may have to start charging their customers more and more for each one, at which point the customers may simply go only-/mostly-IPv6.
A single ISP can't do anything about the situation. They can provide IPv6 to their customers, but they still need IPv4 so their customers so they have a usable internet connection. It doesn't help them at all.
Which is part of the problem here: As long as IPv6 is not implemented by everybody the people who do implement it have no advantage.
This is how a lot of mobile/cell telcos already work. A T-Mobile presentation from 2018 (PDF):
* https://pc.nanog.org/static/published/meetings/NANOG73/1645/...
Here's a dude from T-Mobile explaining how they have (in 2017) over ten million end-customer devices without any IPv4 addresses assigned:
* https://www.youtube.com/watch?v=nNMNglk_CvE
For reaching services that are IPv6 only they use(d) DNS64 (with and without 464XLAT).
You cannot just deploy IPv6, take your IPv4 ball and go home.
ISPs will still need those IPv4 addresses, no matter how much they cost. ISPs may delay by deploying CGNAT, but once those IPv4 addresses run out there is no other option than to get out your checkbook or scale back your business.
Likewise with hosters. There is no choice but to use IPv4, damn the cost. It simply isn’t viable to go IPv6-only, as IPv4 is where the money/customers are.
This will not change until IPV6 somehow reaches critical mass.
Yes, that's what I'm saying. At some point going IPv6-only and paying for (CG)NAT64 may be cheaper than trying to buy more and more IPv4 addresses. ISPs would already have IPv4 addresses, but they'd simply use them for reaching the 'legacy' Internet, and they wouldn't be assigned to people's routers WAN interface.
> Likewise with hosters. There is no choice but to use IPv4, damn the cost.
It will probably not be the hosting company paying for the IPv4, but rather it will be the end customer, and they may not want to pay.
The first address may be free, but if you want multiple, then you could be charged for the 'extra' ones. Depending on the number of public services needed, some people may find it cheaper to use the IPv4 address(es) on the front-end of a load balancer and have their actual system be IPv6.
>It will probably not be the hosting company paying for the IPv4, but rather it will be the end customer, and they may not want to pay.
Of coarse it will be the hosting company paying for the IPv4 addresses as they will be the ones owning them.
Of coarse the end customers will complain and not want to pay, but pay they will as they have no other choice.
It’s neither here nor there whether the end customers run IPv4 or IPv6 internally, it’s the public IPv4 addresses that matter.
However, as I stated previously, they are only for niche uses such as hobby projects or internal services, not for use by the general public.
They will remain so until IPv6 reaches critical mass.
It's so much cheaper and faster already today that it makes sense to do v6-only internally and deliver IPv6 to the large fraction of customers who can have IPv6 and deploy a transform layer for the (gradually shrinking) class of have-nots.
Your IPv4-only competitors are spending more money to deliver a worse service. Maybe they'll wake up and realise, but the story of the past couple of decades suggests most such outfits are not too bright and when offered IPv6 on new links they'll smugly decline. Meanwhile you get to keep the difference. Your competitor thinks this service costs 86¢ per dollar revenue and you're only spending 84¢ per dollar revenue that's a lot of extra profitability.
Fighting this is a losing battle, and I imagine that decades from now somebody is going to write a book about how it was cognitively possible for "leaders" to champion an idea that couldn't possibly work, that they intellectually knew couldn't work, and all the actual evidence said wasn't working, and yet they believed in it anyway. Or that book might be about climate change denial, either way.
Eventually by the way - and 90% global is close to and even perhaps at the threshold where that's plausible for some of them - many general ISPs won't bother providing actual IPv4 networking. If you want IPv4 you're a niche customer, go find a bespoke IPv4 Internet Service Provider. If you're IPv6 capable but you want to reach an IPv4 host you'll go via a translation box automatically. As the interest in global IPv4 shrinks, the transit companies will lose interest in that service too, and eventually - decades from now - the IPv4 Internet literally goes away, the RIRs stop "managing" the now largely unused space and the residual pockets of IPv4 cease to interoperate.
Absolutely not. Routers, OSes and applications still have much better support for IPv4 than IPv6.
Replacing large routers, fighting bugs and running pure IPv6 on internal networks is very expensive.
Also I'm not talking about routers worth 50 euro/$, but DC and carrier grade, worth 500K euro/$
ISPs and many enterprise sized orgs have been running v6 for a long time, so it's not like it's a checkbox feature that hasn't had a lot of testing.
Of course they do. They are hugely complex systems and troubleshooting and tuning is prioritized based on customers needs.
I’m also going to humor you on the IPv6-only thing. Can you actually point to a single ISP that is even considering IPv6-only?
But it doesn't stop there, you also no longer need subnet planning -- where under IPv4 it's very important whether this new subnet is 60 machines or 64 machines, in IPv6 you don't care and so nobody needs to manage that. Which translates to lower costs in your network team. Negligible when your "network team" is just the CTO doing a Google search, but significant at scale.
Your route costs fall too. Because of exhaustion (and because years ago nobody had any idea what they were doing, not having had an Internet before) IPv4 is now badly fragmented, which means a trivial route ("All the East Coast stuff") may become six or sixteen or sixty separate address blocks, but IPv6 blocks were deliberately assigned so as to reduce fragmentation, chances are "All the East Coast stuff" is one or two blocks.
As to speed, Facebook reports IPv6 is about 10% faster for them.
They did exactly what I described, they're v6-only internally and have translation at the edge for "legacy" IPv4 clients.
This is just silly. If you are an ISP then you already have an IPv4 allocation.
If you don’t then you join the waiting list and/or apply for a /24.
Once you have your allocation, RIR fees are the same regardless of IPv4 or IPv6 allocations.
> But it doesn't stop there, you also no longer need subnet planning -- where under IPv4 it's very important whether this new subnet is 60 machines or 64 machines, in IPv6 you don't care and so nobody needs to manage that. Which translates to lower costs in your network team. Negligible when your "network team" is just the CTO doing a Google search, but significant at scale.
If you believe this is in any way meaningful then I have a bridge to sell you.
> Your route costs fall too. Because of exhaustion (and because years ago nobody had any idea what they were doing, not having had an Internet before) IPv4 is now badly fragmented, which means a trivial route ("All the East Coast stuff") may become six or sixteen or sixty separate address blocks, but IPv6 blocks were deliberately assigned so as to reduce fragmentation, chances are "All the East Coast stuff" is one or two blocks.
You can’t buy smaller routers just because you deploy IPv6, so I have no idea what cost saving there are to be had here.
> As to speed, Facebook reports IPv6 is about 10% faster for them.
I fail to see how this is universally applicable to all ISPs.
> They did exactly what I described, they're v6-only internally and have translation at the edge for "legacy" IPv4 clients.
Having an IPv6 core is not the same thing as being IPv6-only.
Speaking of IPv6-only, you have yet to name even a single ISP that is even considering going IPv6-only. Cat got your tongue?
Still, while we're here:
> This is just silly. If you are an ISP then you already have an IPv4 allocation.
Due to exhaustion in fact you can't get new allocations in IPv4 in most of the developed world. If you want to expand, you're going to need to buy addresses on the open market for that sort of $40 price we talked about.
> ... Once you have your allocation, RIR fees are the same regardless of IPv4 or IPv6 allocations.
Nope. Let's take ARIN, suppose you're a large international company, hundreds of local corporate networks. With IPv4 this is quite a struggle, maybe you can get away with a /17 for which ARIN will charge you $4000 per year.
But with IPv6 this is easy, you'll qualify for their "3X-small" category with a /40 at only $250 per year, even if you choose a relatively wasteful address layout.
It gets worse! Unless you already had that /17 from years ago, chances are you had to cobble the addresses together from several distinct allocations. ARIN charges $150 per block aggregated in this way, if you need a dozen blocks that's $1800 extra because of the fragmentation. In contrast IPv6 isn't fragmented, it was deliberately allocated sparsely so it's easy to give you adjacent blocks to grow. Not that they'll need to when you're just an international company with a few hundred sub-networks, IPv6 is so wide.
As to the RIR fee thing, yeah, you are right about the ARIN thing. It differs by RIR and region, tho.
You are wrong about the allocation thing, tho. You can get new IPv4 allocations, even in ARINland, by joining the waitlist or to support a IPv6 deployment.
Of course, IPv6 has problems in some parts of the world. IPv6-only usually means, there is IPv4 on some central gateway but your clients don't get any IPv4 assigned. There is a number of really big networks doing just that e.g. most of the mobile operators in the USA.
[0] https://developer.apple.com/videos/play/wwdc2020/10111/ [1] https://developer.apple.com/support/ipv6/
Without any hard data and like-to-like comparisons, the most that can be said is that IPv4 and IPv6 have different routing policies and this may attribute the differences in latency. As such what and where you test will affect your results.
That being said, Apple’s IPv6 policy is probably the best thing being done to encourage adoption.
However, they are not adopting the policy due to performance reasons, but due to necessity given who their ultimate customers are (cell phone companies).
IPv6-only as a term has been heavily abused. A truly IPv6-only network has no access to IPv4 resources. If it does, it isn’t really IPv6-only and relies upon IPv4 addresses and NAT to work.
That is a goal, and perhaps the primary goal, but there are other goals as well. IPv6 makes the Internet itself more efficient by reducing routing overhead and it simplifies network management.
Of course, what will ultimately force ISPs and services to switch to IPv6 is IPv4 address space exhaustion. As the price of a public IPv4 address rises people will begin to more seriously consider an IPv6-only approach, even if it means losing a few users (especially since ISPs will have to make IPv6 available once such services become popular). It has taken longer than expected as various approaches have squeezed the last bits of utility out of IPv4, but it will eventually happen as several billion more people are connected to the Internet.
So, from a business perspective, the optimal strategy is to delay the transition (and the ongoing maintenance costs) until IPv6-only customers become a quantifiable number (e.g. you could say that in 5 years about 5-10% of your target audience would not have IPv4, so switching to IPv6 would increase your sales by X%). You can't blame businesses for doing that. You don't play by these rules, you end up one of those companies blogging how they are forced to shut down despite having a marvelous and very sophisticated product.
That said, you can change it very easily. Just offer IPv6 traffic at a slightly lower rate than IPv4. So every IPv6 packet costs you less than the IPv4 one. For unlimited connections, offer some rebate based on the fraction of IPv6 packets, or something. This will immediately put the incentives in the right places and the switch will happen at exponential rate.
How many cents per month will make you or anybody care?
ISPs don’t even pay for the majority of their bandwidth, they get it for free via settlement free peering. Where’s the rebate going to come from that?
On the fraction of bandwidth ISPs pay for, the wholesale rates are less than 5 cents per Mbps. On average a subscriber uses a few Mbps on average.
Would 15 cents per month really motivate you to go all in on IPv6?
On average bandwidth costs for an ISP are single digit percentages or less of all costs. Even if their wholesalers would fully discount all their IPv6 traffic (why would they do that?!) there’s only so much there to work with.
This data doesn't show that at all. It's based on traffic to Google. According to this, IPv6 adoption in China is just over 2%.
Which of course has absolutely nothing to do with reality.
https://itwire.com/business-technology/good-news-bad-news-an...
> And the free porn? According to Labovitz, it's just one incentive being offered to promote IPV6 "...IPv6 proponents offer free high quality IPv6 porn (the porn-free, IPV4 home page is https://www.ipv6porn.co.nz/ )
It is good for testing stuff.
https://www.scmp.com/tech/policy/article/3143180/china-hatch...
Another factor - mobile has a way greater market share in India, than mobile has in Europe. It’s easier to enforce IPv6 as a mobile carrier
(https://gs.statcounter.com/platform-market-share/desktop-mob...)
A large carrier could even use IPv6 as a competitive moat by offering/sponsoring/investing in popular local IPv6-only services.
Competitor’s customers would be locked out because they don’t have IPv6, not because they were blocked. Kinda hard for competitors to cry foul to the regulator, since the only reason their customers can’t reach the service is that they themselves haven’t been keeping up with the times.
There’s nothing in IPv6 to prevent tracking or offer more anonymity.
If I accidentally run an SSH server where user 'root' and an empty password gives you root access, you still won't be able to get in.
Accidentally configuring port forwarding is a lot harder than accidentally disabling an on-host firewall.
You need a firewall for security, and NAT doesn't do anything in that regard other than make it harder to understand what's going on.
To put it simply, badly implemented IPv6 makes it easier, but all the ways to make it on-par with IPv4 have been widely deployed since 2016.
[0] https://datatracker.ietf.org/doc/html/rfc4941
Not really. According to the wikipedia article[1], you still have an unique address per device. It rotates daily, but you still can uniquely identify a device on a daily basis. This wouldn't be possible with ivp4 with NAT.
[1] https://en.wikipedia.org/wiki/IPv6#Stateless_address_autocon...
> DHCPv6 temporary addresses have the same properties as SLAAC temporary addresses (see Section 4.6). On the other hand, the properties of DHCPv6 non-temporary addresses typically depend on the specific DHCPv6 server software being employed. Recent releases of most popular DHCPv6 server software typically lease random addresses with a similar lease time as that of IPv4. Thus, these addresses can be considered to be "stable, semantically opaque". [DHCPv6-IID] specifies an algorithm that can be employed by DHCPv6 servers to generate "stable, semantically opaque" addresses. [0]
The very last line of that Wikipedia paragraph points you to RFC8064 [1], which is a standard, and completely obsoletes the early "SLAAC temporary addresses", and makes the rest of the paragraph nothing but historical information. (The mention of Windows XP should stand out as a red flag, there.)
> By default, nodes SHOULD NOT employ IPv6 address generation schemes that embed a stable link-layer address in the IID.
[0] https://datatracker.ietf.org/doc/html/rfc7721#section-4.7
RID = F(Prefix | Client_DUID | IAID | Counter | secret_key)
+ secret_key is at least 128 bits, be cryptographically generated, and as difficult to access as the system allows. It cannot be re-used for any other purpose.
+ F is at least SHA-1, but should probably be SHA-256 or above. It can be any cryptographically secure hash function that returns 64 or more bits. (And MD5 is explicitly banned).
+ Client_DUID is the Client Identifier sent to the DHCP.
+ IAID is the 32bit integer from the IA_NA option sent to the DHCP.
And then, once you have that randomised ID:
if(IPV6_ADDR < IPV6_ADDR_LOW || IPV6_ADDR > IPV6_ADDR_HI){
IPV6_ADDR = IPV6_ADDR_LOW + IPV6_ADDR % \
(IPV6_ADDR_HI - IPV6_ADDR_LOW + 1);
}
+ IPV6_ADDR starts out as RID.
+ IPV6_ADDR_HI is the upper bound of leaseable addresses.
+ IPV6_ADDR_LOW is the lower bound of leaseable addresses.
If this produces an address that is invalid or already leased, increment Counter and try again.
The result is that addresses in the same prefix are completely dissimilar, and opaque. When the system rolls the address, there is no way to predict what the next address will be, or what the previous address was.
Windows, Android, macOS, and Linux tend to roll to a new IPv6 address either on system restart, or on an hourly basis, depending on settings.
Thus, on par with current IPv4 addresses for tracking.
[0] https://datatracker.ietf.org/doc/html/draft-ietf-dhc-stable-...
https://developers.google.com/search/blog/2014/08/https-as-r...
Even so, IPv6 privacy extensions more or less bring things up to par with NAT in terms of trackability.
I guess there could be some small benefit, but very few it applied to would be outside the Google dragnet to begin with.
But still Google crawls dualstack sites with IPv4 so it is yet to be seen.
2.28% is already impressive if the situation is still the same nowadays.
What is not fine is the real-world implementations. ISPs that give you a /64 subnet? ISPs that insist, that with IPv6 you must use their CPE as a router, where you have almost zero control? ISPs that give you /56, but prefix delegation on the router they force on you is broken?
There's so much brokenness, that even as a IPv6 fan, I keep my IPv4 addresses. And if it means DS-Lite or IPv4, then IPv4 is it.