s/IP/IPv4/g
Configuring my OS to prefer IPv6 addresses of DNS responses significantly reduced the number of web captchas I see (on NAT444 with native IPv6).
IPv4 is old and broken, use IPv6.
Configuring my OS to prefer IPv6 addresses of DNS responses significantly reduced the number of web captchas I see (on NAT444 with native IPv6).
IPv4 is old and broken, use IPv6.
It's crazy I can get fiber to my house in the US, but not IPv6.
Our free tunnel broker service enables you to reach the IPv6 Internet by tunneling over existing IPv4 connections from your IPv6 enabled host or router to one of our IPv6 routers.
https://tunnelbroker.net/I was doing this back when I had BT in London, my internet speed back then was pretty abysmal and it would randomly drop routes- ironically this tunnel actually improved my internet (because of the routes not being dropped, not the speed).
And they can always tell your ISP if they don't like paying to connect to the tunnelling server they should just implement v6.
It wasn't always like this, but it was for me the last time I tried.
I've got a 8Gbit symmetric fiber connection (with no IPv6 at all, yay) and regularly make use of all of it, so I'm well connected. Router hardware is more than capable of the encapsulation.
With the HE tunnel up, I was often getting tens of megabits per second for any endpoints that supported IPv6.
Works as a "this endpoint is _only_ available on IPv6" so I can connect to something I couldn't otherwise, but day-to-day the experience is vastly better over IPv4 for me.
IPv4 is old, very old. But how is it broken? It's literally been working just fine since it came out.
That there are limited addresses is something else: it doesn't mean it's broken.
I don't care that spying/surveillance devices have more trouble spying on me with IPv4 than with IPv6 and I don't care that some apps have a harder time establishing connection.
IPv4 works. SSH over IPv4 works. Browsing the Web over IPv4 works.
It is broken for you by upstream NAT and CGNAT.
I've never worked on the ISP side so there's no doubt that there is a process at the competent ones, but my guess is most users do not have a competent one.
The Internet was supposed to be a purely peer-to-peer network, where the addresses on each side of a connection pointed to an end node. That's why protocols like FTP or SIP break when NAT is used, and why you have to play games with port forwarding if you want to run services from your house (assuming you have a public IP address at all).
Because just about all applications are currently architected in such a manner.
When Skype first came out many moons ago it allowed peer-to-peer connections with clients, but a lot of clients were behind NAT (especially ones that could not do PCP or UPnP), so Skype had to come up with the notion of "super nodes" that could do relaying.
Protocols like STUN/TURN/ICE/etc had to be developed to deal with all of this blocking of traffic.
If clients could know their 'real' addresses and allow things like PCP (which is often needed for (e.g.) video games), then perhaps there could me less strictly consuming and more collaborating.
The whole idea of "consumer" and "server" nodes is so baked into how people think about networking they don't even realize it. But that's not how the Internet was intended to be in the first place.
And if you seriously believe that Dropbox appeared because of NAT, and not because people prefer out-of-the-box solutions, I can only suggest you to go out of your bubble, and discuss technical issues with random people.
"Intended" btw is not even an argument. Internet wasn't intended for many things which we happily do here.
CG-NAT breaks all this. iroh relies on relays from people with non-broken internet (no CG-NAT).
Yes, and DynDNS too. Which is fine, cause it works, and that is what I said. The claim to which it replies is that people have to pay to Dropbox cause poor souls were stopped from sharing files using existing technologies like FTP by the damned IPv4, and not because they simply prefer an out-of-the-box GUI thing.
Relying on peer-to-peer relays also doesn't scale, which is why Skype dropped its supernode architecture.
And yes, Dropbox does exist because of NAT, or more generally the fact that "consumers" are second-class citizens on the Internet. If everyone had a publicly routed address and an entry in DNS - which is how the Internet was originally envisioned - we'd have solutions that don't require a third party server.
Both of your examples just show how deep the Stockholm syndrome is. IPv4's limitations have shifted the way people think about networking so much that they rarely even realize they're doing it. But this isn't the way it was supposed to be. "Intended" is completely valid when we're talking about how something has strayed from its original design and the ramifications of it.
I'm not naive enough to think that we can ever get rid of the "consumer" and "producer" ideas that have crept into everyone's head. But it's important to remember that these ideas came about only because of limitations in the protocol, not because they're some kind of natural law of how global networks function.
Dropbox gained popularity *BECAUSE IT MADE IT EASY TO DO THIS WHEN YOU'RE STUCK BEHIND NAT TRASH*. By the time it was even a thought in anyone's brain the internet had already been ruined by that garbage.
It would never have existed in a world without NAT because it wouldn't have been needed, syncing data between computers you owned that all had publicly routable addresses is a much simpler problem.
Every ISP that has CGNAT v4 without providing full v6 needs to be shut down. They are either incompetent or actively choosing to make their users' service less useful to restrict them and/or encourage "upgrades". Internet service has a public routable IP address, period.
I'm sorry, but this claim is one of the brightest examples of false consenses effect I've seen in ages. People generally just prefer an icon on desktop to click/tap. And that's the reason Dropbox found its audience.
Sadly, we'll never know.
> syncing data between computers you owned that all had publicly routable addresses is a much simpler problem.
In no way am I denying that people would like to solve the same problems easily. What I'm saying is that it would have been a much simpler problem requiring much less infrastructure. An application like SyncThing that works without any central infrastructure would have been an order of magnitude easier to implement in a world where every internet connected device had a unique routable address.
So the security "provided by" common 1:many NAT comes from the fact that 1:many NAT inherently requires stateful connection tracking and by its nature traffic coming in from the "1" side without an associated connection or rule has nowhere to go, effectively denying any other traffic by default from the "1" side which is almost universally the untrusted side.
Do you know what else has stateful connection tracking and deny-by-default rules on untrusted interfaces? Every single firewall that's worth using or even was at one point worth using in a year starting with a "2".
So yes, in a world without NAT we'd still have stateful firewalls blocking unsolicited incoming traffic that had not been specifically allowed. Those who wish to host public services will still need to configure rules to allow that traffic in unsolicited but those rules will be simpler than NAT port forwards because there's no address translation involved. Anything else wanting to generate on demand temporary connections between systems will be able to do so simply by having each system perform a basic hole punch, sending traffic at the other at the same time with the same pair of ports, and expect it to work again in ways much simpler than what's necessary for reliably doing the same in a 1:many NAT environment.
1:many NAT makes nothing better, it only makes things worse. It's a bad thing and needs to go away as quickly as possible.
---
1:1 NAT is an entirely different beast, it can be entirely stateless and thus has no has no negative impact on most protocols that don't try to communicate address info in-band but also that statelessness means it doesn't inherently provide a firewall effect.
Dropbox gained popularity because none of us can or want to bother to do it with FTP, with the exception of a very small and determined minority.
Why do you think that even FANG engineers use cloud storage systems such as Dropbox/iCloud/OneDrive/Google Drive/etc. Can't an elite software engineer put together a FTP server?
Why do you think Dropbox et al are still a thing in spite of projects such as Syncthing?
This is not the only instance where user experience and convenience show their value. Look at Docker, for example. The "aktually" crowd will be fast to say that anyone can do the same with chroot et al, but they will again be missing the whole point. It's the same thing why Microsoft tried to invest in Aspire even though Docker is here.
It's like complaining that people can buy bread when all they need to make their own is flour, water, salt, and yeast. That's completely besides the point, ain't it?
It'd likely just be built into your operating system's tooling. Your file manager would be able to access other machines it can authenticate to, or you'd automount remote directories on login, etc.
The reason people use cloud storage systems for moving files around is because they have to. A 3rd party server is required because we don't have node-to-node connectivity.
Hell, we'd likely have had cloud storage options sooner because people wanting extra remote storage would totally have been a thing.
CGNAT works for you? Do you play video games at all? Because there are all sorts of people for which it doesn't.
The fact that you may be fortunate enough to get a publicly-accessible IPv4 address on your WAN interface does not mean everyone else is. This type of attitude seems to be akin to "I gots mine."
It's not about "what 'normal' humans want", it's about what can even be built.
It's currently hard to build decentralized anything now, and it'd be nice to open things up to see what creative things (if any) people could come up with if the network allowed for more peer-to-peer connections.
If they have enough v4 for all their customers, sure fine.
On v6 you don’t have that problem.
But if you've ever had to deal with endpoint security, if you're just doing static rule based blocking/throttling, /32 or /24 blocking is often your best option. Thanks to CGNAT this often means having a pretty large impact since an ISP's residential customer might end up getting randomly assigned a "bad" address and the cooldown for these rules is often months long or more.
In IPv6 land, you can just block a /128 or even a /64 and rarely hit anyone else in the crossfire.
Otherwise, what are the practical differences?
I strongly disagree. That's obsolete knowledge, thrown around by people who want to be considered security conscious but haven't actually updated their knowledge in many years. A statement with similar implications might be "security conscious operators require their users to rotate their passwords monthly", which is what a lot of people use to think a decade ago, and now what it really communicates is that you're talking to a dinosaur.
IPv6 will never replace IPv4 because it is a different protocol rather than merely a new version. The name is a lie.
I've more or less come to the conclusion that the people who think v6 is bad don't know what they're talking about. If none of these people can come up with a better approach than v6, that suggests that v6 really is more or less the best approach available.
> after almost 3 decades and so much the adoption at 50%
I think we all wish it had been faster, but the v4->v6 transition is the first time humanity has ever done a transition like this, on this scale, involving so many disparate networks controlled by so many people in so many countries. How do you know that 50% at 3 decades is slow? Maybe this is just the par time for this kind of thing.
https://www.ietf.org/archive/id/draft-thain-ipv8-00.html#sec...
They key things is that pretending interoperability with IPv4 can be an after thought or dual stack is a good idea was just stupid and proven to be so. Flag day or IPv4 fading into oblivion never going to happen.
I know 50% is slow because that is LESS than new deployments over the past 3 days, so if someone thing “better” can be deployed to new projects until all old projects migrate is broken.
The people designing v6 knew from the start that interoperability with v4 was a requirement. It's written right into the list of requirements for v6[1], right in the same place that they say that a flag day is never going to happen.
Why do you believe otherwise? The RFC is right there for anybody, including you, to read.
[1] https://datatracker.ietf.org/doc/html/rfc1726#section-5.5
No, it's not. If you really want a NAT there is no reason you can't use a NAT with ipv6. In fact, it can work even better because instead of using a random port for the translation, you can use a random ip address for each connection.
You're conflating the two parts of NAT: address translation and inbound filtering. A router can block any inbound traffic coming from WAN, even if the IPv6s on the LAN side are public.
In fact, hole punching for IPv4 shows this distinction. By default inbound traffic is blocked, but as soon as private host has opened up a connection, it is (indirectly) reachable and nameable (via the routers public IP + port).
BTW, static IPv4 NAT with public addresses on both sides exists as well.
And as you say, hole punching is still “PUBLIC IP” + port. Not an IP and any port you fancy unless the firewall was configured correctly.
Maybe I am wrong, maybe you’re confused, maybe IPv6 is just rubbish. Maybe all 3.
The default config of a SoHo router has both: (a) NAT44 separating public vs. private IPv4, (b) and also a firewall that blocks any unknown ingress traffic on IPv4 and IPv6.
From a security standpoint, it doesn't matter if the IP get translated inbetween. Only the ingress firewall counts: If the firewall is in-place both IPv4 and IPv6 traffic will be blocked. If you open up the firewall (via hole punching or port forwarding on IPv4, or via IP allows for IPv6), I can send packets to your public IPv4 + port and they will arrive at you private server, or I send them to your servers GUA IPv6 and it arrives. There is no security difference.
> From a security standpoint, it doesn't matter if the IP get translated inbetween. Only the ingress firewall counts
This is complete nonsense. Security is about layers and risk mitigation. You know what is better than firewall rules that can be misconfigured or overridden due to conflict or interface name changes and so on? An IP that can be addressed from global space. Wild!
tracert -4 google.com
tracert -6 google.com
I do get very different hops and latency.
However for “happy eyeballs” algo to fallback to IPv4, latency needs to be very bad on IPv6.
For many years and even how there are networks that advertise they can do ipv6 and hand out real addresses but nothing works.
Especially for DNS, browsers don’t wait “very long” for the AAAA (v6) record to be resolved when they already have the A record (v4) and will start the v4 connection after at max 50ms (iirc thats the spec value, but imo it is too long and most browsers wait less I think).
The good news is that if the AAAA still arrives later it will be cached, thus this only affects the first connection to a site.
As for the actual v6 connection being slower (lets say both A and AAAA come from cache) the browser will start a v6 connection and only fall back to v4 if the connection isn’t established within some time (I think the spec says 250ms).
And to make this all more complicated HTTP1/2/3 enter the decision matrix. I.e. should the browser rather try v4/http3 than v6/http2? Opinions probably differ.
All of this is also on the critical path to a website loading for the user, thats why all of those waits cannot be too long. At some point the benefit of the better protocol will be outweighed by waiting. Even worse if the website doesn’t support v6 and the wait was for nothing.
But in general, it's mostly because v4 and v6 can end up taking different routes. If an ISP has any BGP peers that are v4-only or v6-only then they can end up sending packets for the same host to different peers. In the worst cases, one of them can go to another country and back again. It's usually harder to get ISPs to fix this on v6 than it is on v4, because the problem is visible to fewer people (in part due to happy eyeballs itself).
For smaller websites, DNS caching can play a role. If there are fewer clients requesting AAAA records than there are clients requesting A records, there's a chance that a client requesting both will get a cached A record back quickly but have to wait for full resolution of the AAAA record. This is unlikely to happen for the most popular sites (because another client will probably have triggered the caching) or for the least popular sites (because the A record will also fall out of cache for those), but there'll be a band somewhere in the middle that's affected by this. There's enough v6-capable clients around these days that I doubt this has a major impact now, but it's interesting that caches can cause unfairness like this.
[1] https://www.google.co.uk/intl/en/ipv6/statistics.html#tab=pe...