It's crazy that major web sites still do not support IPv6.
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.
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.
$ 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:f449I 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)
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...