You could share things easily, sure, but anyone could get hacked pretty easily and very targetted.
After NAT, sharing was still easy lots of 'piracy' apps, various messengers with NAT passthrough
Both before and after you needed to be technical, you can't ask someone that doesnt know about computers to set up an FTP server, and if they did it would be a nightmare and they'd likely share their whole drive
Same goes for anything else.
Anyway, we'll get the whole non-nat with IPv6, let's see what that brings
It brings the requirement for a firewall on every endpoint with a unique address. My Phone often has an ipv6 address (found out this holiday wen I couldn't resolve one of sites because of an orphan ipv6 entry nobody noticed), and has little problems. Perhaps there is also "firewalling" on the router and the phone can't even have incoming connections. Not sure. In any case, the phone seems to do fine.
I'm still not convinced that IPv6 is a good thing. I think that we should have doubled down on sharing IP addresses. Both for consumbers (NAT) and for servers (NAT, TLS/HTTP reverse-proxying). It just solves all problems with IP address exhaustion. And the fact that consumers can't just directly connect to each other is a feature.
When I went to debug reachability concerns, it's a shame that I can only use ping/traceroute between the non-NAT peers, and then have to SSH to my reverse proxy to do yet another ping to the backend. Similar for tcpdump.
This is the cost to splitting your routing between layer 3 and 4.
I'm now IPv6 everywhere, and so I get to just use ping. Much simpler.
Further, protecting IPv6 services is simpler, because I can terminate (m)TLS on the backend. With a reverse proxy on another proxy, I have to have yet another means of securing the proxy-backend path. Yet more complexity!
> And the fact that consumers can't just directly connect to each other is a feature.
Consumers should be protected by firewalls. That's independent of routing.
P2P communication is also a feature, which an entire class of applications would love to make use of. Instead, we need to spawn (and PAY for) TURN and STUN servers
> Even more ironic is that NAT got normalized as a security feature — “your devices are hidden!” — which is one of the things that made people resist the thing that would fix it.
That tracks. I briefly looked into the Tailscale website and I thought maybe I was wrong, maybe it's not a NAT/ddns toolchain, maybe it's something more complex that I'm too dumb to understand. But if my thesis that it's NATware is right, it makes sense to market it as a security product, it fooled me for one, but it also passes as a quality product for an organization, and they feel they are getting a security product when they are actually signing the purchase request of a developer that is applying networking techniques they learned from managing a videogame server.
I'm having trouble decoding this but Tailscale is a VPN that can traverse NAT when necessary. Arguably Tailscale wouldn't be needed if NAT didn't exist but considering the timeline I'm not going to declare a conflict of interest.
I remember times before NAT and SSL
You could share things easily, sure, but anyone could get hacked pretty easily and very targetted.
After NAT, sharing was still easy lots of 'piracy' apps, various messengers with NAT passthrough
Both before and after you needed to be technical, you can't ask someone that doesnt know about computers to set up an FTP server, and if they did it would be a nightmare and they'd likely share their whole drive
Same goes for anything else.
Anyway, we'll get the whole non-nat with IPv6, let's see what that brings
It brings the requirement for a firewall on every endpoint with a unique address. My Phone often has an ipv6 address (found out this holiday wen I couldn't resolve one of sites because of an orphan ipv6 entry nobody noticed), and has little problems. Perhaps there is also "firewalling" on the router and the phone can't even have incoming connections. Not sure. In any case, the phone seems to do fine.
> Not sure. In any case, the phone seems to do fine.
That's mostly because a phone is very locked down, can you run an accessible ftp server on your phone?
It's also not windows
Phone OSs tend to pay a lot more attention to security than the crap they put on consumer-grade routers, "smart" TVs and cheap webcams.
I would invest in a proper firewall for the entire home before opening up anything to the world, IPv6 or not.
> Anyway, we'll get the whole non-nat with IPv6, let's see what that brings
I'll believe it when I see it. So far it doesn't look like IPv6 will win anytime soon.
I'm still not convinced that IPv6 is a good thing. I think that we should have doubled down on sharing IP addresses. Both for consumbers (NAT) and for servers (NAT, TLS/HTTP reverse-proxying). It just solves all problems with IP address exhaustion. And the fact that consumers can't just directly connect to each other is a feature.
When I went to debug reachability concerns, it's a shame that I can only use ping/traceroute between the non-NAT peers, and then have to SSH to my reverse proxy to do yet another ping to the backend. Similar for tcpdump.
This is the cost to splitting your routing between layer 3 and 4.
I'm now IPv6 everywhere, and so I get to just use ping. Much simpler.
Further, protecting IPv6 services is simpler, because I can terminate (m)TLS on the backend. With a reverse proxy on another proxy, I have to have yet another means of securing the proxy-backend path. Yet more complexity!
> And the fact that consumers can't just directly connect to each other is a feature.
Consumers should be protected by firewalls. That's independent of routing.
P2P communication is also a feature, which an entire class of applications would love to make use of. Instead, we need to spawn (and PAY for) TURN and STUN servers
ipv6 is a window for every buttock. I don't see this as a good thing.
Time to set up IPV6.
Or just use an ipv4 address. It works I swear
NAT made distinction between PCs and servers too broad.
Related comment from another thread
https://news.ycombinator.com/item?id=49454785
> Even more ironic is that NAT got normalized as a security feature — “your devices are hidden!” — which is one of the things that made people resist the thing that would fix it.
That tracks. I briefly looked into the Tailscale website and I thought maybe I was wrong, maybe it's not a NAT/ddns toolchain, maybe it's something more complex that I'm too dumb to understand. But if my thesis that it's NATware is right, it makes sense to market it as a security product, it fooled me for one, but it also passes as a quality product for an organization, and they feel they are getting a security product when they are actually signing the purchase request of a developer that is applying networking techniques they learned from managing a videogame server.
I'm having trouble decoding this but Tailscale is a VPN that can traverse NAT when necessary. Arguably Tailscale wouldn't be needed if NAT didn't exist but considering the timeline I'm not going to declare a conflict of interest.