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 aent 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 host, 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.
IPv6, in a way, takes the concept of a MAC address and puts it on steroids. This became evident to me when I learned about EUI-64 addresses. And then my brain melted when I learned that any interface can be assigned an arbitrary number of unique addresses with varying purposes or contexts because the address space is truly *that big*.
When I consider that quality of IPv6’s design, it communicates to me an old and ideal vision of what we thought the internet would and should be - a hyper-connected, shared infrastructure where [Layer 3] identity is universally unique such that connectivity between any two arbitrary nodes is possible (which obviously isn’t true for NAT w/ overload).
I’m just a lowly SysAdmin who finally decided to get his CCNA - so I’m a nobody - but as I worked through the material I felt like I was paging through a history book or biography of how the Internet’s life came to be and all the mistakes made along the way. Most features felt like patches for design considerations that were overlooked. Examples: DHCP Snooping, STP’s various * Guards, and the mere fact that Layer 2 and Layer 3 addresses are distinct concepts.
I don’t think there’s any disagreement that NAT was co-opted as a security feature. I never hear that said in a positive way, either. I think if we were to start over, with IPv6 as the default assumption, the tools we’d develop for network security would look very different, but not at all impossible or any more difficult.
But again - I’m a nobody. Just thinking out loud here.
Reverse proxies work because they're not behind restrictive NATs, and having a few central servers that are not behind Symmetric NAT is a surefire way to establish an ISP-granted monopoly. Even if that somehow worked, this completely breaks P2P for consumers (which I think you intend) as well as torrenting without, again, a central NAT-punching TURN-like server. So yeah, address exhaustion is done but so is the Internet as we know it.
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 using tailscale to tunnel from an hetzner vm to my home, so that the vm can use my home connection for certain traffic. Traverses NAT and GNAT.
It just works: connect devices and they immediately show up in their portal. Most config is just clicking, but more advanced things can be configured as well. Definitely feels like a high quality product, not just something thrown together by a developer that learned a few network techniques.
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.
Well, any 3G or later mobile backbone is SIP+SCTP over IPv6. So in many ways it won already
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 aent 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 host, 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.
IPv6, in a way, takes the concept of a MAC address and puts it on steroids. This became evident to me when I learned about EUI-64 addresses. And then my brain melted when I learned that any interface can be assigned an arbitrary number of unique addresses with varying purposes or contexts because the address space is truly *that big*.
When I consider that quality of IPv6’s design, it communicates to me an old and ideal vision of what we thought the internet would and should be - a hyper-connected, shared infrastructure where [Layer 3] identity is universally unique such that connectivity between any two arbitrary nodes is possible (which obviously isn’t true for NAT w/ overload).
I’m just a lowly SysAdmin who finally decided to get his CCNA - so I’m a nobody - but as I worked through the material I felt like I was paging through a history book or biography of how the Internet’s life came to be and all the mistakes made along the way. Most features felt like patches for design considerations that were overlooked. Examples: DHCP Snooping, STP’s various * Guards, and the mere fact that Layer 2 and Layer 3 addresses are distinct concepts.
I don’t think there’s any disagreement that NAT was co-opted as a security feature. I never hear that said in a positive way, either. I think if we were to start over, with IPv6 as the default assumption, the tools we’d develop for network security would look very different, but not at all impossible or any more difficult.
But again - I’m a nobody. Just thinking out loud here.
Reverse proxies work because they're not behind restrictive NATs, and having a few central servers that are not behind Symmetric NAT is a surefire way to establish an ISP-granted monopoly. Even if that somehow worked, this completely breaks P2P for consumers (which I think you intend) as well as torrenting without, again, a central NAT-punching TURN-like server. So yeah, address exhaustion is done but so is the Internet as we know it.
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 using tailscale to tunnel from an hetzner vm to my home, so that the vm can use my home connection for certain traffic. Traverses NAT and GNAT.
It just works: connect devices and they immediately show up in their portal. Most config is just clicking, but more advanced things can be configured as well. Definitely feels like a high quality product, not just something thrown together by a developer that learned a few network techniques.
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.