> Yes. My ISP will rent me a single IPv4 address for $10 per month.
At that price point you can get a small vm, but if you have a dedicated server you want to use on-prem, 10$/mo seems like a reasonable price.
> Or I can use DHCP, where my IPv4 address can change at their whim.
Check the dhcp.lease to make sure, I used to think that, then I looked at the dhcp lease and the IP was being reserved for up to 48 hours of disconnection. I went years without it ever being released.
Phone operators won't necessarily transmit this information to you, the true ISP operator is the DHCP server. Not only is it more knowledgeable, but DHCPd has no incentive to upsell you, just provides you with what it is configured to.
I'd even go as far as checking if you can send parameters during the dhcp lease request, maybe you can request a longer lease on the IP.
There's a right way to do things, it's not trivial to discern from the wrong way to do it, but once you see it, you notice that you lose almost nothing, it's not like the 'wrong' way is simpler, it's just 'wronger', all the way through. I guess the reason they persist is sunk-cost fallacy, the businesses and people that went with NAT then developed STUN, and then they developed ICE, and then they develop Tailscale, every time you need to invent a bigger spade to dig you out of the hole and into a deeper one.
Or you can just use IPv4. But aghast, you have to pay 10$/month (or learn DHCP)
There's nothing to learn here in the end. Its just rules imposed by the ISP. I've had places where the leases expired weekly, and I'd often get a different public IP address when renewed.
> At that price point you can get a small vm, but if you have a dedicated server you want to use on-prem, 10$/mo seems like a reasonable price.
So I can spend $10/mo for each IP address I want, or I can just use IPv6 where my ISP gives me 295,147,905,179,352,825,856 IP addresses (a /60) by default for free. Hmm...which to choose...
No argument from me here on the /56 vs a /60, I play the cards I'm dealt. AT&T being the same shitbags they've always been. But its multi-gigabit fiber from them or questionable DOCSIS from Spectrum, and I've never met an honest Spectrum representative. I refuse to do business with them after all the fraud they've given me over the years.
In the end its still a bajillion-ish IPv6 addresses I have to play with versus the one-ish I have with IPv4.
Counting the cost of creating the company so you can actually deal directly with a NIC?
Every. Single. Individual. End. User. Device. Should. Be. Addressable. Given that there are more such devices out there then there are IPv4 addresses to begin with, cost doesn't even come into it.
China has very few IPv4 addresses per capita. Here in Hangzhou, China, I have to pay China Telecom 850 CNY per year just to get an IPv4 address. That's not a trivial amount of money for us. And among the three major telecom operators, only one even offers this service.
IPv4 in China must be complicated, I would probably look into IPv6 if I were based in China, or China specific protocols, or perhaps there's some IP addresses that China has embargoed and reserved for their own? Such that inside China they resolve to china but outside China they resolve somewhere else?
On the other hand, it's not really that complicated. Cost seems to be around 10USD per month, which is what another user mentioned. And the GDP per capita of china is around 12000 USD per year, so it works out to a bit more than 1% of a salary, not sure if my maths are wrong, but from the perspective of a service provider, it still sounds like a sensible price point.
India has a lower GDP per capita, but I know that they make non profit collective efforts to massively lower prices.
Note also that a substantial part of the value and purpose of IP addresses comes from their cost. There is a PoW/PoS mechanism that associates some cost to some identity (similar to domain names), and this is part of the mechanism by which networks filter malicious traffic and defend against sybil attacks.
So 10$/month might be expensive, but it's probably the right price. If it were much cheaper than that, like 1$/month, or even 0.1$/month, abuse would rise, especially in China which, no offense, but doesn't seem to value the notions of civil law like contracts, Terms of Service or copyright dearly. At least they don't do it out of malice like Russia, it's just a difference of values, but it's probably for the better that IPv4 addresses are 10$/month, if it were 0.1$/month, I would probably just block the whole country.
CGNAT is also not cheap and very complex from a architectural point of view.
Vendors have been pushing it though, because implementing IPV6 only somehow is still a very, very scary thing for large ISP's to pull off.
what should happen is it should be very easy to deploy ipv6/4 translation mechanisms in ipv4 only networks, this would allow easy interopability and make it easier for the large networks to push IPV6.
> 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.
You are describing the product technically, but I find how it is used more important. Do you use it? What do you use it for? If empirically most users use it to host a server on a machine with firewalled IP, then that's more descriptive than its technical featureset as listed on the tin.
i personally have used it
* to provide access to my home network, as though i am on the home network, while outside of said network
* to connect several locations to the same business network
the first lets me provide locally hosted services without exposing them to the internet, by allowing members of the VPN ("tailnet" in their parlance) to connect to those services
the second was very handy to move a few users from a company in the process of shutting down to their homes, so they could continue to work like they had in the company network once the actual internal company network was shut down.
Quite legitimate, a common use case of VPNs, an L3 encryption tunnel to provide virtual LAN access. It's kind of a hack usually, but it might work as a second redundant layer of security (the other usually being HTTPs, and in the case of there being no other layer of encryption that's where VPN wrapping is kind of a hacky solution).
The other common but completely distinct usecase of VPNs being residential usage to encrypt traffic and even more distinct, with the purpose of masking the true origin of a request.
In the former type of usage, which is the one you use, I think any VPN system would fulfill your purposes, of course you have to use something, but I'd venture a guess that you are using the generic features of tailscale, not its commercially distinguishing features. But they are still very on brand, generic or not.
fwiw, the author/founder seems to have made a career out of building post-hoc hacks in one layer to fix the shortcoming of other layers, to take memcached as an example. I don't think my thesis is novel, that these types of hacks are subpar when compared to solving the issue at the appropriate layer, it's part of the tradeoff of the technologies, but I'm just particulary opposed to any hack that allows server admins to skip the step where they get a dedicated IP address, I'm less opposed (but still) to other types of hacks.
I've been running a home server and Tailscale is magic. My firewalls have no open ports. The tailnet is a virtual network that assigns IP addresses to approved devices that you authenticate to join.
I use it in 3 ways:
1. My phone connects to my home network by joining the tailnet. I can play music and movies from my home server when I am away. No struggles with configuration.
2. A dedicated mini pc at home is on a smart plug. I keep it powered off mostly. I can turn the plug on remotely and power the mini pc. It runs "tailscale --advertise-routes" which then exposes every device at my house to the tailnet. No open ports, but suddenly my phone thinks that it is back at home with all my home PCs.
3. I take my laptop with me and use "tailscale serve" which serves as a pipe. I can pipe my home movies to a smart TV at your house. Just install the jellyfin app, and browse for servers, and my server in my house appears in the list at your house.
An interesting use case, a kind of personal server, presumably FTP.
Still not my cup of tea, but I think that the threshold of acceptable hacks is much higher for personal usage, there's no right or wrong, because it's as much a useful project as it is one of exploration and expression.
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.
>"that the vm can use my home connection for certain traffic. "
Huh. Why are you doing this, is the datacenter IP being (rightfully) blocked by some service to avoid abuse? Is your usecase breaking some services ToS?
Certainly adding more fire to the "never a GOOD reason to use this" thesis
So you make up reasons to be judgemental and then insist they're right?
It's practical to block entire datacenters. It's not so "right" that working around it becomes "wrong". If whatever the server's doing can fit through a single home connection then it's probably fine.
I'll give you a concrete use case: A few times a month I want to wget a file on imgur to my server. That's a valid action miles away from any kind of abuse, but the IP range is blocked so I use my desktop to do it. If I routed it over tailscale instead that would be equally valid.
The fact that it's a VPN is also pretty important, despite the utility of it also dealing with NAT headaches for you.
The main selling point is acting as a relatively efficient private overlay network, giving you a consistent private network even as devices move between different internet connections. (Something that NAT makes a bit harder but you don't get for free even if NAT isn't a factor)
I see it now, it's a bundle of both the practical and security aspects. I think the security aspects serve mostly as a marketing tool, potentially serving users who truly need a VPN.
But if I see a user that exposes a server without a dedicated IP address, and they use tailscale for this, the way I would describe it is that they are adding a third party node that routes traffic for them (just to provide multiplexing), so in terms of security, it's an additional unnecessary man in the middle. It's a testament to the marketing team that they are able to sell it as 'added security'. It's hard to know exactly how such open infra technologies are used, but I get the feeling that a good part of the customer base is buying tailscale to patch up a bad infra decision, while being (self) deluded into thinking that their system is very bleeding edge and secure.
Props to tailscale actually, lots to learn here, the lesson is to let the client save face and sell your tech not as something that fixes an embarassing mistake, but as something that's a bit opaque, high tech and implements security protocols, even if performatively.
Bonus points if there is upsell or onramp into actually sound technologies, like eventually you have to drop the whole tailscale thing and help the client actually get an IP address right? Or maybe even onboard the rogue ddnsed service onto the organization's existing ASN. It's a hard sell because the best solution in that case actually removes the product from the organization altogether, but I can imagine ways were the product stays in a non-central, QA-like sidechannel.
> But if I see a user that exposes a server without a dedicated IP address, and they use tailscale for this, the way I would describe it is that they are adding a third party node that routes traffic for them (just to provide multiplexing), so in terms of security, it's an additional unnecessary man in the middle.
If you are listening on a public IP, you can trivially be attacked by anyone on the Internet.
If you listen on a private IP that only Tailscale can reach directly, you can only be attacked by Tailscale itself, or by anyone who successfully infiltrated Tailscale's network.
Should you run plaintext protocols over Tailscale? Absolutely not. But you're going to receive orders of magnitude less malicious traffic on a server accessible only over Tailscale compared to a server listening on the public Internet.
Yeah, but to the extent that the server is useful, it needs to be exposed to the internet.
If you make your tailscale available to the internet through tailscale, you are still weak to external attackers, putting a VPN in the middle doesn't fundamentally change that dynamic, maybe it shifts it around and it confuses you enough to feel less shifty about it.
But it doesn't decrease your risk, if your HTTP server is weak to a tailscalething.tld/../../etc/ attack, it doesn't really matter that requests to other ports are blocked, (which probably don't even have processes listening anyways)
> Yeah, but to the extent that the server is useful, it needs to be exposed to the internet.
Not if it's a private server, like the poster above was describing. For example, if I want to maintain a NAS to store my photos and view them anytime, I am better off running it on a Tailscale network that only I (and some friends/family) can acces, no reason to expose it publicly and then try to secure it.
Can you imagine how much more evil Smart TVs and IoT would do if every device was consistently globally routable?!
The problem is being directly routable is just Step 1 of N for getting 2 services to communicate. Next you need a name service like DNS but preferably free like email if you expect every home to have one. No, your ISP shouldn’t provide it because you don’t use their email do you? Don’t be any more locked in to your ISP than you have to.
Once you get a name service so humans can actually connect to one another as easily as sending an email you need authentication, identity, authorization, and encryption.
No problem just use a shared password and Let’s Encrypt right?
Well now you have a huge security risk (a single factor password auth) and a new centralized SPoF: Let’s Encrypt.
IPv6 alone solves none of this and only makes the need for a name service more pronounced as the address is much longer.
Sure all of this is solvable but if it were easily solvable wouldn’t more people do doing it on IPv6 already? I’ve had native IPv6 through Comcast/Xfinity for over a decade.
Designing p2p services is just entirely distinct from the routability problem NAT presents, and after decades of widespread internet access I’ve only seen p2p use decrease after the heyday of file sharing apps (of which all the most popular ones have degrees of centralization). Making usable p2p apps seems as hard as usable p2p encryption schemes like PGP/GPG: the usability vs security tradeoffs are brutally hard.
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
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.
> Perhaps there is also "firewalling" on the router and the phone can't even have incoming connections. Not sure.
Correct. Every home wifi router worth its salt will firewall incoming connections by default, whether v4 or v6. It's then possible (unless it's some shitty ISP-provided locked down device) to add specific allow rules, or allow all for a particular client.
egress is typically wide open, although sometimes they lock down particular protocols by default (eg. smtp, bittorrent)
I absolutely plan to NAT my home, I don't see a good reason to do otherwise.
I don't see a reason why my machine addresses should change over time... then again, most shouldn't have direct internet access anyway, a http proxy on firewall should be enough.
> I don't see a reason why my machine addresses should change over time
You can still use fixed addresses locally if you want, its not like IPv6 is forcing you to use the prefix assigned if you just want to communicate locally over never-changing addresses.
You can have your computers be fd01::1, fd01::2, fd01::3, etc, and talk to everything on their local addresses when wanting to stay local. And then when they want to talk on the public internet they can just use whatever public addresses like 2600:1700:53c2:2573:4c:c001:dead:beef based on whatever prefix your ISP gives you.
Its not like your devices have to only have a single IP address.
Source address selection still favors GUA over ULA by default in every major operating system… If you run both you’re almost certainly going to see a lot of GUA addresses in logs where you only allow LAN traffic. Especially if you’re using mDNS/.local for your hostnames. The only way to be sure your internal stuff only ever uses ULA’s is to not give them GUA’s, and now you’re doing NAT.
(I don’t personally run my network as ULA-only, I do ULA+GUA as you describe, but I had to basically give up on being able to reliably tie traffic logs to a known source… hosts in my LAN always seem to use a GUA to talk to each other when discovering over mDNS, which of course means they use privacy addresses by default. My ULA uses DHCP so that I can get stable addresses and know who is who, but it’s useless when things just decide to use the GUA anyway.)
And even if it wins, it won't matter much, since it is only one of many issues with the current Internet that prevents people from connecting to each other. Even with IPv6 you'd still have no way to find the other person and the moment they hop between networks, their IPv6 address won't stay the same either.
Ultimately I think none of this will be solved at the low level, it needs something like Iroh or libp2p where you build a new network on top of the Internet infrastructure, so that you can have things like persistent cryptographic identities and addresses that you can carry with you, largely independent of the underlying network architecture.
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.
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
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.
> 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.
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.
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.
The 'why' behind all of these protocols and decisions is left out in favor of the cert exams. Being able to implement is usually what gets you paid.
>mere fact that Layer 2 and Layer 3 addresses are distinct concepts.
The logical separation between the ideas allows for a lot of flexibility, and there were some wrong answers on how scalable vs flexible things should be.
They emerged with a decent answer: L2 crosses intranetwork, L3 crosses internetwork. Their separation allows L3 addressing to be completely unaware of multiple changing L2 (lower level) intranetwork switches, which is immensely useful.
Trying to solve everything with One Master Protocol to solve it all turned out like this:
https://xkcd.com/927/
this works nicely in IPV6, where true seperation of layer 2 and layer 3 exist.
This does not exist in practice in ethernet, because ARP is required as a mechanism to learn MAC IP bindings and is dependant on IP AND Ethernet.
IPv6 solves this by doing neighbour discovery on link local addresses and multicast addresses.
I am doing a little facepalm over the L2-L3 distinction, thanks for being gentle and thoughtful. Sometimes I interrogate how things are, imagine what another paradigm would look like, but always end up where I started... I see that and think, hm, maybe the design of networks as we know them are expressing some sort of structure in the Platonic space.
I took a course called “Introduction to Internet Architecture” back in 2017 with a wonderful professor. The course opened with a prompt, “What is communication?” We started with smoke signals and worked our way up the OSI layers (including voltage-level encodings on the wire). I remember drawing those layers and asking, “What problem is each layer trying to solve?”
Also that XKCD comic is a classic. Love it. I don’t see any value in overhauling the protocols of today. It seems like the future (or present) of networking is overlays. When this recent cert covered SDN, it really abstracted away everything I had just learned and I felt a little sad about it honestly - as if switch/router configuration would some day be ubiquitously software-defined, getting totally buried by the application layer and becoming almost apocryphal like assembly or machine code… something we know exists but rarely touch.
Having actual unique stable IPv6 addresses for every device is the dream of every Ad vendor - no need to bother with the huge array of tracking techniques and the chicken and mouse game of fighting various tracking protection solutions, just log the stable IPv6 of the user's device across any service they use.
So, of course, we then got Privacy Addresses, or whatever the name is. Which now means that you don't actually have a stable unique public IP, it actually changes all the time, and legitimate tracking and logging of your own network activity actually becomes much more complicated on IPv6.
Easier just to say it's a thing, like a force of nature.
New network growth (mobile, Africa, Asia) uses it, old growth stays on v4 and will eventually roll over. People with address space usually don't need much more, but the IPv6 space better reflects how connected the world is - we're gonna need a bigger address space than v4, that's for sure.
New protocols shipped quickly on rough consensus and working code and weren't perfect - some left all kinds of undefined behavior, or lacked clear advantages over predecessors and competing protocols.
Calling NAT the original sin is a serious exaggeration. Carrier Grade NAT (CGNAT) is a truly evil concept that restricts the freedoms of the CGNATed users. But regular NAT is fine as long as you can control it. "No one wanting to bother with port forwarding" is largely a matter of shitty UX on the home gateway side and laziness on the side of the operator. Same with UPnP.
If anything, NAT has saved millions of wildly insecure devices running unpatched old Windows versions from getting pwned the second they connect to the open internet.
>If anything, NAT has saved millions of wildly insecure devices running unpatched old Windows versions from getting pwned the second they connect to the open internet.
I don't NAT being a janky ad hoc firewall does anyone a service. It shields the devices enough to keep the developers oblivious about security, but not enough to stop them from connecting to arbitrary hosts. This perpetuates the humongous botnet ecosystem.
> If anything, NAT has saved millions of wildly insecure devices running unpatched old Windows versions from getting pwned the second they connect to the open internet.
Its definitely the opposite. People stopped ignoring security because its "natted" anyways, even though NAT was never supposed to be security-critical. Thats what firewalls are for.
People (by which I mean average computer users) didn't "start ignoring security", they never bother to unignore it in the first place. Early Windows editions didn't even ship with a firewall at all, people were rawdogging the internet out of the box without ever stopping to consider the consequences.
... because people (by which I mean software vendors who should have known better) irresponsibly failed to create secure systems for those average users to use. A whole lot of which came to be justified by "it'll be behind a firewall" thinking.
Did you forget dialup was a thing? No one created anything for home users thinking it would be behind some firewall because as said Windows didn't ship with one, and because the dominant way of customers getting online was dialup, giving a public IP to every user.
Software was created with no security because no one demanded it because no one cared. Technologies that came later did not create that situation.
I remember in the Windows 95/98 days asking my friend for his IP address and then browsing through my windows explorer to his mum's fully shared windows C drive. She had her computer plugged directly into the modem and was using ICS to share the net to my friends computer.
I sent them a screenshot of her shared drive through ICQ, and not long after she bought a router.
The typical NAT implementation ("PAT", single public IP, RFC-1918 network) gives you an implicit stateful firewall denying unsoliticed inbound traffic. Most people don't need anything else.
Yeah NAT is still in the realm of, "every household gets a public IP address". This is a perfectly good foundation for an open Internet. You can still host servers in your home. I did this a lot as a kid and learned a ton from it.
Going to a model of "you don't get a public IP address, all traffic must go through servers other people host for you" is what finally kills the open Internet. It's okay enough for cell phones where it's a hack to work around TCP/IP's lack of roaming support, but it should be illegal to deploy as residential Internet.
> "No one wanting to bother with port forwarding" is largely a matter of shitty UX on the home gateway side and laziness on the side of the operator. Same with UPnP.
If you try to use those port forwarding hacks, you force every single piece of software to deal with the fact that the IP address it sees for itself is not the IP address its peer sees for it. And you force every single protocol design to allow for that possibility. Add in UPNP, and now you have to implement a whole extra (badly designed) protocol in parallel with the actual application.
It's not trivial to even discover the address your peer is seeing; even now there's a huge diversity of nasty unreliable hacks for doing it.
HTTP isn't the world. In fact, HTTP becoming "the world" was another part of the problem.
NAT only serves as the janky inbound default deny because IPv4 doesn't have the address space. There are very few things NAT solves in a world without address exhaustion; the only one I can think of off hand is a janky method of forcing return routing in enterprise environments where symmetric rooting is needed.
In an alternate universe (or a current one with IPv6) every home router would have a default deny inbound security policy, and home admins could punch holes as needed the way they do today with port forwarding.
I don't think that you can draw the line between NAT and CGNAT. The fact that single NAT works as well as it does is an argument for why it is ok to double NAT with CGNAT.
The conceit behind NAT is that 99% of traffic over the router will be client-server and the last 1% can get away with separately negotiating with the router to get inbound traffic.
For example my ISP Xfinity by default will put your router in CGNAT space (and ipv6) but if you request port forwarding from a mobile app the upstream router will assign you a ipv4 address and it all works. NAT is considered fine because adding roadblocks to server hosting is a acceptable tradeoff.
The reason they i think they can be so flexible is that they likey have a ipv6 backbone to route to all the customers and ipv4 is not used for routing but as a extra service layered on top with packing the 48 bits of ipv4 and port inside a ipv6 address via MAP-T
> If anything, NAT has saved millions of wildly insecure devices running unpatched old Windows versions from getting pwned the second they connect to the open internet.
I doubt it.
Very few devices do port NAT without also doing firewalling, since firewalling is simpler.
NAT didn't save us from insecure networking. It gave insecure networking an excuse that was just good enough to satisfy the masses.
This is worse for everyone in so many ways:
1. Forwarding ports suddenly makes you insecure, because you already were.
2. You have to fuck with your router config to even do that, and risk breaking something else along the way. Nobody should have to bother, because port forwarding shouldn't exist in the first place.
3. Many ISPs make it difficult or impossible to configure your firewall, let alone reserve a static public IP.
4. It's an eternal problem that isolates itself from any true solution. Any actually good UPnP implementation would just be stuck behind your NAT and firewall.
The entire premise "as long as you can control it" is the core issue, and the fundamental reason why NAT is the original sin. Without NAT, there wouldn't be anything to get control of.
> If anything, NAT has saved millions of wildly insecure devices running unpatched old Windows versions from getting pwned the second they connect to the open internet.
You can have a stateful firewall that blocks non-established-connection packs and all your publicly addressable devices would not be reachable. NAT ≠ firewall (though they often glommed together on CPEs).
And NAT is also giving a false sense of security in some ways: "this device has an RFC 1918 address so is not reachable, and therefore safe". Yeah, except if another device already on the inside is / gets compromised. Perhaps if everything had a public address folks would be more circumspect.
> Generally, firewalls aren't going to save you from an internal compromise either.
Right, but it's easy to get in the mindset that because devices are on the "inside" network they are safer. This is the risk that NAT brings: RFC 1918 = safe(r).
If every device has a 200::/3 address, then even if there's a SPI firewall which prevents external connections, it may help to reduce this inside/outside thinking.
I think it's hard for us to imagine what we could have if not for NAT.
Just as an example, any device on your home network could have a web interface which you could access from anywhere using a web browser. All the smart light bulbs and things which need some stupid account on some service could be made so they're controlled by the user instead of some company.
I've set up things like this on my home network but it's a pain because I need to deal with port forwarding, and if I have more than one device I need to use a reverse proxy.
Author is right about everything. Also: IPv6 doesn't fix this, it just introduces a new problem. IPv6 machines end up with local firewalls + stateful firewalls on the router. That router doesn't let in inbound cons. There is a part of UPnP that lets you add "pin holes" (it works like you expect) -- but the drawbacks are its kind of obscure, poorly implemented, and not guaranteed to be enabled.
The idea of router sounds simple and like it should implement some standard protocols. But in practice -- a lot of it is a mishmash of proprietary, ad hoc shitware. Something I never hear spoken about is the deep packet inspection filter component of the router firmware. It's a part of the router that decides on what traffic is allowed / not, and almost no company publishes this part. So you're not even in control of your own Internet traffic, tiny blobs of code written by some company get to decide if something is allowed or not.
If that sounds sus AF and kind of a bad idea -- well, it is. You can always run 100% open software with open-wrt. But the thing is -- the Internet isn't just your part of it. It's a network of networks, and all those shitty routers, with all that shitty firmware, is deeply ingrained within the entire Internet. That's millions of devices that would need to be replaced to fix the issue.
Sending files to another would be easy if only the services that allow doing this - over WebRTC - didn’t sell out to sketchy advertisers constantly.
I have to look up which service is still good to use every time.
That's because they're actually not "sending files to another". A hairpin service has to be provided for double NATed scenarios and a rendezvous service has to be provided for all cases. There's no magic about WebRTC that makes it actually p2p.
I've been using it and it certainly has the potential. I signed up for Cloudflare's TURN server which you use with bitbang and it gets you 1TB free data transfer per month.
People have forgotten, or weren't alive, but NAT was created and deployed originally by users. The problem they were solving wasn't "how do we stop running out of addresses" but rather "how do we save money". That's because early ISPs had hit on the idea of charging more for more address space, as a way to differentiate between small and large customers. So you could buy a cheaper service with one IP and use NAT to get your whole organization online.
I was alive and don't think I've forgotten. What distinguished large from small users was the width of the pipe. Address space charging was never important as a revenue driver. There were some attempts to charge for address space to keep people from getting huge blocks they didn't use. The long term solution for that was, of course, supposed to be IPv6.
If I wanted to blame large corporate "users" for NAT (which I actually do), I would blame their obnoxious intransigent refusal to upgrade to IPv6. That part wasn't the ISPs' idea, but it had nothing to do with the cost of address space and everything to do with shortighted laziness. They were, in fact, willing to pay for IPv4 space to avoid having to do anything.
The designers of the internet made one fundamental mistake, namely applying meatspace norms to cyberspace.
In the "real world", you don't really need that much security. Your actual security comes from the fact that all the worst criminals are already locked up, most of the would-be criminals are afraid of being locked up, and if somebody does actually commit a crime, they will get locked up and won't be able to do it again for a good while. A lot of real-world security is about post-factum detection (think alarms, CCTV, panic buttons etc), because in the real world, detection and prevention are two sides of the same coin.
This only works because if a real-world crime happens, the criminal by definition is in the same location as the victim, and law enforcement cares most about the community they serve. If the criminal is across the world, as is the case in cyberspace, even if it's a friendly country, it's often "not their problem". This means internet systems need actual security, and NAT provides exactly that.
If not for NAT, we'd all need a firewall, and things would be almost if not exactly the same. In the real world, "leave things relatively open, because locks are mostly for keeping honest people honest" is a valid strategy. This strategy doesn't work on the internet.
I think about this frequently. IMO, geographic sparsity is the biggest difference. Every malcontent on the planet just can't reach my door, and the physical reality of movement through space means they can't reach my door, AND every other door on the planet, in the same way they can reach every IP, or practically every IP.
There's probably a field of study with vocabulary and accompanying proofs of significant rigor that prove or disprove this. Maybe they'll stop by our little subthread and clear it up.
Uhh... you can have a firewall without NAT, including one at the perimeter.
This is a very common misunderstanding. NAT and firewalls are separate concepts. You can also have NAT with no meaningful firewall -- a port remapping NAT that allows anything through.
Most IPv6 networks are firewalled but there's no NAT.
I think this is not really a good way to divide up the space. It's obviously true that there are non-NAT firewalls. But NAT was introduced as a firewalling technique. In the first decade of firewalls, there was a whole taxonomy of different kinds of firewalls: application layer gateways, packet filters, "stateful" packet filters, and, yes, NAT.
You still need a firewall regardless of NAT. Otherwise, every time you take your computer outside of your home, you're no longer protected. Any attacker or compromised device on your hotel, airport, or coffee shop wifi network would have direct access to your machine.
A NAT implementation could broadcast any "WAN" side incoming packets to all link local clients (aka: put everyone in the DMZ). The only thing preventing that is a stateful firewall.
> There’s lots of things you can blame for killing the open Internet, but I think NAT was one of the earliest. Running a server used to be trivial: run an executable, tell people your address, done... It also trained everyone to think client‐server is natural. “My device talks to The Cloud which talks to other devices” feels normal, when that feeling originated as an artifact of address scarcity.
A lot of this feels like a requiem for the days when the only people on the Internet were "high-computer-skill" type folks. Most people will gravitate to "user-friendly" solutions: Gmail and other managed email providers were popular because they didn't stop working when you shut down your computer to save electricity, when your server's hard drive crashed, when you upgraded your computer to something with a faster processor, more RAM, and a newer operating system. It was hard enough to educate laypeople about URLs and email addresses (AOL keywords, anyone?), let alone a combination of random numbers in an IP address, or convincing people to register domain names.
Yes, NAT shoved fences into a network that was all about connecting everybody. But we'd still end up with server-client cloud architectures, even if we had started with IPv6 in the beginning. ISPs would have just sold highly restrictive firewalls as part of their home-install basic boxes, and we'd still have ended up with those fences.
> Running a server used to be trivial: run an executable, tell people your address, done...
This works, until you have more than one person accessing your server. Then you need to worry about accounts, credentials, data isolation, etc. And then if a couple of people connect to your server and start using it, you have to worry about staying online, staying updated, backing up the data. But other than that... yes, trivial.
And just to be really explicit, you always have more than one person accessing your server, and most of the time they are unwanted users trying to break in.
1. NAT and a firewall are 2 different things
2. With IPV6 you can have so many IPS that unwanted users can't guess your IP. This isn't true security but see 1 for that.
Perhaps a server run by a large corporation could do this. Perhaps.
But an ordinary person? I don't see it. If it's tough for an ordinary person to handle safely opening a port in their firewall for forwarding, it's tough squared (or perhaps cubed or an even higher power) for an ordinary person to handle auto-creating a separate IPV6 address for every other person that wants to communicate over the Internet with them.
Not to mention, how does this work with DNS? If Ordinary Person wants to put an article up for others to read, how do the others find it? Surely not by Ordinary Person sending individually crafted IPV6 addresses to anyone who wants to read their article. (And how do they even find those other people if they are also creating new IPV6 addresses for everyone else?)
Exactly. Which is the issue with saying, as the article does, that NAT is the reason most people don't have an Internet visible server, when the real reason is that their computers need to be behind a firewall and once you're behind a firewall, safely opening up just little pieces of it for an Internet visible server is something most people aren't going to want to deal with.
If the utility and functionality of the server requires those things, then they're required regardless of whether or not that server is internet-facing.
Jill from Elbonia may be always be a threat, but this doesn't mean that Joe from Accounting is not a threat or cannot ever provide a vector for Jill. :)
> most of the time they are unwanted users trying to break in
Thankfully, we have wireguard now. It drops all packets by default. From the perspective of people who don't have the requisite cryptographic keys, it's like the computer is not even there to begin with.
I've always found it strange how people just put computers out there on the internet and just allow them to interact with total internet randoms. Why are we allowing our computers to talk to strangers? No wonder people are getting hacked.
That's fine. I don't agree with your thesis (or think it's at least greatly exaggerated) but reading source documents from the past and advancing an argument is solid history scholarship.
There was a point in time in the mid-2000s when P2P networking had briefly made running your own server attractive to end-users again. And then the iPhone came out and completely killed any hope of that becoming the norm.
The thing about smartphones is that they are both completely dependent on wireless connections to central servers in order to function and completely unsuitable to operate as servers. If you forced your phone to serve files anyway, your battery would drain quickly and the CPU would be drowning in its own waste heat. You might argue that you could still do non-server things on the phone, but practically speaking, a node that can't handle server tasks is just a leech. P2P networks work on a mutual aid basis; they require the majority of nodes be capable of shouldering traffic or sharing files in order to be a net benefit. If you add, say, tens of millions of new mobile phones to the network, the network will become unusable as any desktop machine gets DDoSed by hordes of phones asking for a babysitter.
So even in the world where IPv6 did to v4 what v4 did to NCP, we'd still ultimately end up with "my files go in the cloud", because clouds are coinventions of smartphones, in the same way that cars are coinventions of suburbs. You can't have one without the other, and once you do have both, they become so economically dominant that others get socially coerced into using them.
Nokia were experimenting with using their smartphones as web servers in the mid-2000s. You were able to write blog posts and share photos, and if you logged in to the site you could look up your contacts or download your camera roll. There's an article on this here: https://allaboutsymbian.com/features/item/Previewing_Nokias_... .
Obviously it's all very basic, but with a few years of development and polish (and probably someone besides Nokia copying the idea) I think this would be a compelling product. You could basically have the same feature set as something like iCloud but without the subscription or your files going elsewhere.
> But we'd still end up with server-client cloud architectures, even if we had started with IPv6 in the beginning.
Skype was originally peer-to-peer for comms, but ended up with "super-nodes" because of NAT limitations (not sure if STUN/TURN/ICE had been invented by that point). BitTorrent is still peer-to-peer. A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port.
But this doesn't only hurt server-y stuff: you may not notice it if you're with a legacy MegaISP with lots of money to throw at IPv4 allocations, but if you're with a younger or smaller ISP, then there's a good chance you're behind CG-NAT, so many console games won't work.
Yeah I feel like a lot of the people criticizing this are still being client-server brained. There's a lot of use cases that "everyone is a server" would open up without turning everyone into a sysadmin and they'd likely get turned into user-friendly software like Skype or early Spotify.
It's sadly the only practical way to do things now. For client/server, you only need one party (the server) to not be behind CGNAT. For p2p, you need both parties to not be behind CGNAT. It's typically only possible to guarantee that one party isn't behind CGNAT.
All practical solutions for p2p these days require NAT hole punching through STUN and signaling servers anyway, so even p2p has to be bootstrapped via client/server. Easier to just keep the protocol client/server then.
The problem is that everyone who's championing IPv6 is talking about how it makes NAT unnecessary and about how bad NAT is. See TFA as one example. NAT is perfectly fine, so all the IPv6 boosters who make this huge deal of it get dismissed as IPv6 hype men. "Every household gets an IPv4 address which is shared between their computers using NAT" is a good solution.
The problem is, and has always been, that NAT doesn't solve the IPv4 exhaustion problem. It took a long time before I understood this due to all the noise IPv6 people make, but newer ISPs don't have enough IPv4 addresses to give every household its own address, so they use CGNAT for residential Internet access. This is what people should be focusing on, but it's not. All arguments for IPv6 are irrelevant drivel about how bad NAT is.
Certainly there are still (SPI) firewalls with IPv6, but at least with CPEs things are limited to 'only' hole punching with PCP (or UPnP) as opposed to all the ICE/TURN/STUN layers (and heaven help you if you're behind CG-NAT).
> The problem is, and has always been, that NAT doesn't solve the IPv4 exhaustion problem.
NAT was intended to be a "short-term solution" as noted in the NAT RFC (from 1994):
> A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port.
This is such a common and stupid problem. It's the same with SSH; if you want to run your own git host, you need to either reserve public port 22 to git, or use it on a non-default port.
More protocols should have some kind of header to tell the server what name was used to connect, just like HTTP's Host header. If SSH clients told the server, "hey I connected via git.example.org", you could have an SSH proxy behind the NAT forward that connection to your git host. If the Minecraft client told the server, "hey I connected via survival.example.org" or "hey I connected via creative.example.org", you could have a Minecraft proxy server route the traffic to the right local address/port.
(I'm actually implementing multiplayer in a game right now and I'm adding this information to the initial connection handshake message, with the intention that you could make a proxy server.)
I think its funny everyone thinks that ISPs, Device Manufacturers, and Cloud Providers are going to let your connect back directly to your "home" with IOT devices.
Absolutely not. They can charge your $9.99/mo so you can connect their craptastic app to their craptastic cloud so you can "use their app from anywhere".
NATs are also firewalls. I think people forget that before NATs, when you would install Windows, the minute you connected it to the internet, you had to rush to update it before a virus would infect it. The OS of the 90s weren't secure enough to be exposed to the WAN.
1) The typical "NAT" is a "PAT", which requires state for mapping traffic flow. An implementation is going to look very similar to a stateful firewall, by necessity, not accident.
2) The use of RFC-1918 addresses behind the router / NAT box provides some protection. If your address is not globally reachable, it's much harder to reach any hosts behind it. Yes, a poor implementation might allow direct routing from adjacent networks, like your ISP or neighbor. But that still isolates you from 99.99% of the internet.
The consequences are so much more significant than people seem to realize.
Because of NAT, hierarchy (centralized servers) is the foundational design pattern of the internet, and anyone who wants any semblance of anarchy (decentralized networks) must use a workaround that is itself hierarchical and costly. We are all interconnected, but only a wealthy few can truly speak fist.
I 100% agree, and I've been making this argument since Pharaoh Ramses II ruled Egypt, but at this point it's too late. I also find that a lot of people just don't get it.
At this point the IP architecture(s) we have are wired in, and I don't think they can be changed. It'd be like trying to go back in time and re-do the x86 architecture. At some point you're stuck with a system, including its warts, and NAT and IPv4 are warts we're stuck with.
We might eventually reach sufficient IPv6 penetration that P2P protocols can start ignoring IPv4, but it'll be a while. I have seen statistics that IPv6 traffic to Google is starting to hit 50%, which is a huge milestone, and it's slowly growing.
Why do so many people still think NAT equals firewall when they're not directly related?
I guess it's because they're normally packaged together for practical reasons. They're both packet handling functions often performed in the same place. But they are NOT the same and you can have either one without the other. Most IPv6 networks have firewalls, and it's possible to have NAT that passes anything.
Get me onto the network that's on the WAN interface of your router, disable the firewall on it, and I will.
How do you want to go about doing this? Although, 100% of the time people have asked me to do this they chicken out at actually doing it, so I suppose you will too. You might prefer to test with some network namespaces instead.
>Running a server used to be trivial: run an executable, tell people your address, done.
This is the draw to onionv3 services for me. It's still exactly like this.
I made a post the other day wondering why they aren't way more popular than they are. Do most people just not know? It's a pretty nice thing to be able to do.
Especially in a world where you can create your own utilities very easily, it's the perfect way to gain back some sovereignty over your compute in the age of CGNAT.
Sure it's not blazing fast or anything...but it's perfectly adequate for 90% of things.
I implemented the current NAT system in Linux. In particular, avoiding port reservation in favor of squishing more connections into one IP address, as long as the remote address allowed us to differentiate.
This, in turn, means incoming traffic from a different address is unroutable. You no longer have a public endpoint. This is "poor man's firewall", but erodes our ability to have a server the way we used to.
I was a young engineer solving a specific problem, without considering the larger picture. It wasn't the only thing, but I feel it definitely moved the internet to a client/server infrastructure and a key equality was lost.
Mate ... How many people are engineers, technicians, mildly interested, not fussed or call the internet "Facebook"?
IPv4 without NAT was fucked at the design stage. To be fair: Who knew?
I was asked by my employer a while back to investigate this new www thing that has hit the internet (in around 1994 or 5, it took a while to notice) and I said it was a bit crap and no better than WAIS and GOPHER. I was using telnet on a Windows 3.1 PC and telnetting madly via a VAX and a X.25 PAD and what I now know was close to magic!
No one had any idea how things would turn out back then.
I'm actually quite impressed how long IPv4 has managed to work and without NAT (which I do mildly despise, given 30 years messing with this stuff), it would be stuffed.
> no better than WAIS and GOPHER. I was using telnet on a Windows 3.1 PC
I had a corporate internship in the late 1990s and they blocked external web access.
They did, however, allow external Telnet access. This meant that whenever I had free time and/or was waiting for new projects, I would telnet back to my college server and use lynx to go read my favorite websites.
Sorry, i am not very much into kernel/netstack development, but a question. So does it mean that even if an alternative NAT system will be available in Linux (kernel module with a switch or whatever) - it will not be adopted by industry because everyone (and every device) is used to how it works now?
NAT itself is a hack to let everything keep working like it already does.
The Internet Protocol only concerns itself with IP addresses. The idea is that each computer has an IP address, so computers can communicate by sending IP packets; each IP packet says, "Message from computer with IP address X to computer with IP address Y".
But computers have multiple processes, so there's a need to know which process at the receiving computer is the recipient and which process on the sending computer is the sender. This is why transport protocols (TCP and UDP) add a port field. A port uniquely identifies a particular socket opened by a particular process on a computer. So a TCP or UDP message sent via the Internet Protocol contains the information, "From the socket with port 41590 on the computer with IP address X, to the socket with port 443 on the computer with IP address Y".
NAT is a giant hack which is primarily implemented in routers. It makes a whole household (or office building, or university campus) look to the outside world like one big computer with one IP address.
Say we have a computer with IP address L, a router with public IP address X, and a public server with IP address Y. The computer will send a message to the router which says, "From port 41590 @ L, to port 443 @ Y". The router will invent a new random port number (say 41200), add an entry to its NAT table which says "port 41200 means port 41590 @ L", then send a message to the public Internet: "From port 41200 @ X, port 443 @ Y".
When someone then sends back a message "to port 41200 @ X", the router looks that up in its NAT table and rewrites the packet to say "to port 41590 @ L", then sends it to the computer with that IP address.
The computer doesn't really know that it's speaking through a router (it needs to know that "packets to the public Internet should be sent via the router" but that's it, the packets it sends and receives looks the same as if the router wasn't there). The rest of the world doesn't really know that it's speaking to a computer (from their perspective, it looks like they're just speaking directly to the router). All the special logic lives only within the router which does network address translation.
Already back then, you couldn't easily deploy solutions which required all computers and middle-boxes on the Internet to change. That's why NAT exists in the first place.
You could deploy a new NAT implementation, but the problem NAT solves is fundamentally that there aren't enough IPv4 addresses for every computer to have an IPv4 address. I don't think there's a better solution to that problem other than switching everything over to IPv6 (which has been in progress for the past 30 years and has barely reached 50%).
If it's any consolation, I don't think NAT did anything particularly harmful other than making the adoption of IPv6 less urgent. It's CGNAT that's the real problem, not NAT.
Working around NAT was trivial for the people who actually cared about it. I was adding port forwarding rules to my parents' router at age 12. Turns out exposing a poorly-configured Windows XP box to the wider interwebs is a Really Bad Idea - and for the same reason UPnP letting random unpatched shady P2P applications do the same is Very Much Not Good.
Let's face it: consumer devices simply aren't secured well enough to let the entire internet poke around in them, and it was even worse a decade or two ago. Decentralization is pointless when it only results in people compromising their own machines, and the people with the skills to set up a 24/7 Linux server in a broom closet won't care about adding some NAT forwarding rules.
Even without NAT, we would've definitely gotten home internet routers firewalled with a default-deny policy on all incoming connections. Exactly the same "manually configure a bypass, or use UPnP" dance blocking you from trivially running a web-available service on your machine, but with a firewall rule rather than a NAT port forward.
It's of course a different story with CGNAT, but that only became a thing well after the internet was already centralized.
"Network address translation (NAT) was first formally proposed in RFC 1631 in 1994."
"Naturally, people noticed this was a problem almost immediately, because people have wanted to run game servers, FTP servers, and web servers from their bedrooms since roughly the beginning of time."
TCP/IP was in use for at least thirteen years before the first "commercial ISP" offering internet access oustide of work or school
In 1994 the www had only been public for less than twelve months
According to one source, 11 million US households got internet access in 1994
The distinction between NTP as a protocol and the assumptions imposed by NAT is useful, especially when considering how much modern networking depends on intermediaries rather than direct connectivity.
181 comments
[ 0.24 ms ] story [ 25.0 ms ] threadAt that price point you can get a small vm, but if you have a dedicated server you want to use on-prem, 10$/mo seems like a reasonable price.
> Or I can use DHCP, where my IPv4 address can change at their whim.
Check the dhcp.lease to make sure, I used to think that, then I looked at the dhcp lease and the IP was being reserved for up to 48 hours of disconnection. I went years without it ever being released.
Phone operators won't necessarily transmit this information to you, the true ISP operator is the DHCP server. Not only is it more knowledgeable, but DHCPd has no incentive to upsell you, just provides you with what it is configured to.
I'd even go as far as checking if you can send parameters during the dhcp lease request, maybe you can request a longer lease on the IP.
There's a right way to do things, it's not trivial to discern from the wrong way to do it, but once you see it, you notice that you lose almost nothing, it's not like the 'wrong' way is simpler, it's just 'wronger', all the way through. I guess the reason they persist is sunk-cost fallacy, the businesses and people that went with NAT then developed STUN, and then they developed ICE, and then they develop Tailscale, every time you need to invent a bigger spade to dig you out of the hole and into a deeper one.
Or you can just use IPv4. But aghast, you have to pay 10$/month (or learn DHCP)
There's nothing to learn here in the end. Its just rules imposed by the ISP. I've had places where the leases expired weekly, and I'd often get a different public IP address when renewed.
> At that price point you can get a small vm, but if you have a dedicated server you want to use on-prem, 10$/mo seems like a reasonable price.
So I can spend $10/mo for each IP address I want, or I can just use IPv6 where my ISP gives me 295,147,905,179,352,825,856 IP addresses (a /60) by default for free. Hmm...which to choose...
In the end its still a bajillion-ish IPv6 addresses I have to play with versus the one-ish I have with IPv4.
Every. Single. Individual. End. User. Device. Should. Be. Addressable. Given that there are more such devices out there then there are IPv4 addresses to begin with, cost doesn't even come into it.
On the other hand, it's not really that complicated. Cost seems to be around 10USD per month, which is what another user mentioned. And the GDP per capita of china is around 12000 USD per year, so it works out to a bit more than 1% of a salary, not sure if my maths are wrong, but from the perspective of a service provider, it still sounds like a sensible price point.
India has a lower GDP per capita, but I know that they make non profit collective efforts to massively lower prices.
Note also that a substantial part of the value and purpose of IP addresses comes from their cost. There is a PoW/PoS mechanism that associates some cost to some identity (similar to domain names), and this is part of the mechanism by which networks filter malicious traffic and defend against sybil attacks.
So 10$/month might be expensive, but it's probably the right price. If it were much cheaper than that, like 1$/month, or even 0.1$/month, abuse would rise, especially in China which, no offense, but doesn't seem to value the notions of civil law like contracts, Terms of Service or copyright dearly. At least they don't do it out of malice like Russia, it's just a difference of values, but it's probably for the better that IPv4 addresses are 10$/month, if it were 0.1$/month, I would probably just block the whole country.
Vendors have been pushing it though, because implementing IPV6 only somehow is still a very, very scary thing for large ISP's to pull off.
what should happen is it should be very easy to deploy ipv6/4 translation mechanisms in ipv4 only networks, this would allow easy interopability and make it easier for the large networks to push IPV6.
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.
the first lets me provide locally hosted services without exposing them to the internet, by allowing members of the VPN ("tailnet" in their parlance) to connect to those services
the second was very handy to move a few users from a company in the process of shutting down to their homes, so they could continue to work like they had in the company network once the actual internal company network was shut down.
The other common but completely distinct usecase of VPNs being residential usage to encrypt traffic and even more distinct, with the purpose of masking the true origin of a request.
In the former type of usage, which is the one you use, I think any VPN system would fulfill your purposes, of course you have to use something, but I'd venture a guess that you are using the generic features of tailscale, not its commercially distinguishing features. But they are still very on brand, generic or not.
fwiw, the author/founder seems to have made a career out of building post-hoc hacks in one layer to fix the shortcoming of other layers, to take memcached as an example. I don't think my thesis is novel, that these types of hacks are subpar when compared to solving the issue at the appropriate layer, it's part of the tradeoff of the technologies, but I'm just particulary opposed to any hack that allows server admins to skip the step where they get a dedicated IP address, I'm less opposed (but still) to other types of hacks.
I use it in 3 ways:
1. My phone connects to my home network by joining the tailnet. I can play music and movies from my home server when I am away. No struggles with configuration. 2. A dedicated mini pc at home is on a smart plug. I keep it powered off mostly. I can turn the plug on remotely and power the mini pc. It runs "tailscale --advertise-routes" which then exposes every device at my house to the tailnet. No open ports, but suddenly my phone thinks that it is back at home with all my home PCs. 3. I take my laptop with me and use "tailscale serve" which serves as a pipe. I can pipe my home movies to a smart TV at your house. Just install the jellyfin app, and browse for servers, and my server in my house appears in the list at your house.
Still not my cup of tea, but I think that the threshold of acceptable hacks is much higher for personal usage, there's no right or wrong, because it's as much a useful project as it is one of exploration and expression.
Thanks for sharing.
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.
Huh. Why are you doing this, is the datacenter IP being (rightfully) blocked by some service to avoid abuse? Is your usecase breaking some services ToS?
Certainly adding more fire to the "never a GOOD reason to use this" thesis
So you make up reasons to be judgemental and then insist they're right?
It's practical to block entire datacenters. It's not so "right" that working around it becomes "wrong". If whatever the server's doing can fit through a single home connection then it's probably fine.
I'll give you a concrete use case: A few times a month I want to wget a file on imgur to my server. That's a valid action miles away from any kind of abuse, but the IP range is blocked so I use my desktop to do it. If I routed it over tailscale instead that would be equally valid.
The main selling point is acting as a relatively efficient private overlay network, giving you a consistent private network even as devices move between different internet connections. (Something that NAT makes a bit harder but you don't get for free even if NAT isn't a factor)
But if I see a user that exposes a server without a dedicated IP address, and they use tailscale for this, the way I would describe it is that they are adding a third party node that routes traffic for them (just to provide multiplexing), so in terms of security, it's an additional unnecessary man in the middle. It's a testament to the marketing team that they are able to sell it as 'added security'. It's hard to know exactly how such open infra technologies are used, but I get the feeling that a good part of the customer base is buying tailscale to patch up a bad infra decision, while being (self) deluded into thinking that their system is very bleeding edge and secure.
Props to tailscale actually, lots to learn here, the lesson is to let the client save face and sell your tech not as something that fixes an embarassing mistake, but as something that's a bit opaque, high tech and implements security protocols, even if performatively.
Bonus points if there is upsell or onramp into actually sound technologies, like eventually you have to drop the whole tailscale thing and help the client actually get an IP address right? Or maybe even onboard the rogue ddnsed service onto the organization's existing ASN. It's a hard sell because the best solution in that case actually removes the product from the organization altogether, but I can imagine ways were the product stays in a non-central, QA-like sidechannel.
If you are listening on a public IP, you can trivially be attacked by anyone on the Internet.
If you listen on a private IP that only Tailscale can reach directly, you can only be attacked by Tailscale itself, or by anyone who successfully infiltrated Tailscale's network.
Should you run plaintext protocols over Tailscale? Absolutely not. But you're going to receive orders of magnitude less malicious traffic on a server accessible only over Tailscale compared to a server listening on the public Internet.
If you make your tailscale available to the internet through tailscale, you are still weak to external attackers, putting a VPN in the middle doesn't fundamentally change that dynamic, maybe it shifts it around and it confuses you enough to feel less shifty about it.
But it doesn't decrease your risk, if your HTTP server is weak to a tailscalething.tld/../../etc/ attack, it doesn't really matter that requests to other ports are blocked, (which probably don't even have processes listening anyways)
Not if it's a private server, like the poster above was describing. For example, if I want to maintain a NAS to store my photos and view them anytime, I am better off running it on a Tailscale network that only I (and some friends/family) can acces, no reason to expose it publicly and then try to secure it.
The problem is being directly routable is just Step 1 of N for getting 2 services to communicate. Next you need a name service like DNS but preferably free like email if you expect every home to have one. No, your ISP shouldn’t provide it because you don’t use their email do you? Don’t be any more locked in to your ISP than you have to.
Once you get a name service so humans can actually connect to one another as easily as sending an email you need authentication, identity, authorization, and encryption.
No problem just use a shared password and Let’s Encrypt right?
Well now you have a huge security risk (a single factor password auth) and a new centralized SPoF: Let’s Encrypt.
IPv6 alone solves none of this and only makes the need for a name service more pronounced as the address is much longer.
Sure all of this is solvable but if it were easily solvable wouldn’t more people do doing it on IPv6 already? I’ve had native IPv6 through Comcast/Xfinity for over a decade.
Designing p2p services is just entirely distinct from the routability problem NAT presents, and after decades of widespread internet access I’ve only seen p2p use decrease after the heyday of file sharing apps (of which all the most popular ones have degrees of centralization). Making usable p2p apps seems as hard as usable p2p encryption schemes like PGP/GPG: the usability vs security tradeoffs are brutally hard.
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.
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
If you want to use the standard port, that's only true as of very recently, though, see https://issuetracker.google.com/issues/218578943#comment17
I would invest in a proper firewall for the entire home before opening up anything to the world, IPv6 or not.
Correct. Every home wifi router worth its salt will firewall incoming connections by default, whether v4 or v6. It's then possible (unless it's some shitty ISP-provided locked down device) to add specific allow rules, or allow all for a particular client.
egress is typically wide open, although sometimes they lock down particular protocols by default (eg. smtp, bittorrent)
I'll believe it when I see it. So far it doesn't look like IPv6 will win anytime soon.
Well, good to know!
At home it can be if I connect t to my ip6 ssid, but there’s a stateful firewall which may as well nat.
I don't see a reason why my machine addresses should change over time... then again, most shouldn't have direct internet access anyway, a http proxy on firewall should be enough.
You can still use fixed addresses locally if you want, its not like IPv6 is forcing you to use the prefix assigned if you just want to communicate locally over never-changing addresses.
You can have your computers be fd01::1, fd01::2, fd01::3, etc, and talk to everything on their local addresses when wanting to stay local. And then when they want to talk on the public internet they can just use whatever public addresses like 2600:1700:53c2:2573:4c:c001:dead:beef based on whatever prefix your ISP gives you.
Its not like your devices have to only have a single IP address.
(I don’t personally run my network as ULA-only, I do ULA+GUA as you describe, but I had to basically give up on being able to reliably tie traffic logs to a known source… hosts in my LAN always seem to use a GUA to talk to each other when discovering over mDNS, which of course means they use privacy addresses by default. My ULA uses DHCP so that I can get stable addresses and know who is who, but it’s useless when things just decide to use the GUA anyway.)
Ultimately I think none of this will be solved at the low level, it needs something like Iroh or libp2p where you build a new network on top of the Internet infrastructure, so that you can have things like persistent cryptographic identities and addresses that you can carry with you, largely independent of the underlying network architecture.
In the US, it’s currently over 60%: <https://stats.labs.apnic.net/ipv6/US>
You can have firewalls with no NAT just fine. You can also have NAT with no firewall.
NAT is not about security and never was. It's about stretching the IPv4 supply and allowing each endpoint to just get one precious V4 IP.
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.
> 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.
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.
If it weren't you couldn't have the same IP over several interfaces.
>mere fact that Layer 2 and Layer 3 addresses are distinct concepts.
The logical separation between the ideas allows for a lot of flexibility, and there were some wrong answers on how scalable vs flexible things should be.
Ethernet and IP beat the shit out of everything else: https://en.wikipedia.org/wiki/Protocol_Wars
They emerged with a decent answer: L2 crosses intranetwork, L3 crosses internetwork. Their separation allows L3 addressing to be completely unaware of multiple changing L2 (lower level) intranetwork switches, which is immensely useful.
Trying to solve everything with One Master Protocol to solve it all turned out like this: https://xkcd.com/927/
IPv6 solves this by doing neighbour discovery on link local addresses and multicast addresses.
I took a course called “Introduction to Internet Architecture” back in 2017 with a wonderful professor. The course opened with a prompt, “What is communication?” We started with smoke signals and worked our way up the OSI layers (including voltage-level encodings on the wire). I remember drawing those layers and asking, “What problem is each layer trying to solve?”
Also that XKCD comic is a classic. Love it. I don’t see any value in overhauling the protocols of today. It seems like the future (or present) of networking is overlays. When this recent cert covered SDN, it really abstracted away everything I had just learned and I felt a little sad about it honestly - as if switch/router configuration would some day be ubiquitously software-defined, getting totally buried by the application layer and becoming almost apocryphal like assembly or machine code… something we know exists but rarely touch.
So, of course, we then got Privacy Addresses, or whatever the name is. Which now means that you don't actually have a stable unique public IP, it actually changes all the time, and legitimate tracking and logging of your own network activity actually becomes much more complicated on IPv6.
New network growth (mobile, Africa, Asia) uses it, old growth stays on v4 and will eventually roll over. People with address space usually don't need much more, but the IPv6 space better reflects how connected the world is - we're gonna need a bigger address space than v4, that's for sure.
New protocols shipped quickly on rough consensus and working code and weren't perfect - some left all kinds of undefined behavior, or lacked clear advantages over predecessors and competing protocols.
If anything, NAT has saved millions of wildly insecure devices running unpatched old Windows versions from getting pwned the second they connect to the open internet.
I don't NAT being a janky ad hoc firewall does anyone a service. It shields the devices enough to keep the developers oblivious about security, but not enough to stop them from connecting to arbitrary hosts. This perpetuates the humongous botnet ecosystem.
Its definitely the opposite. People stopped ignoring security because its "natted" anyways, even though NAT was never supposed to be security-critical. Thats what firewalls are for.
Software was created with no security because no one demanded it because no one cared. Technologies that came later did not create that situation.
I sent them a screenshot of her shared drive through ICQ, and not long after she bought a router.
Going to a model of "you don't get a public IP address, all traffic must go through servers other people host for you" is what finally kills the open Internet. It's okay enough for cell phones where it's a hack to work around TCP/IP's lack of roaming support, but it should be illegal to deploy as residential Internet.
If you try to use those port forwarding hacks, you force every single piece of software to deal with the fact that the IP address it sees for itself is not the IP address its peer sees for it. And you force every single protocol design to allow for that possibility. Add in UPNP, and now you have to implement a whole extra (badly designed) protocol in parallel with the actual application.
It's not trivial to even discover the address your peer is seeing; even now there's a huge diversity of nasty unreliable hacks for doing it.
HTTP isn't the world. In fact, HTTP becoming "the world" was another part of the problem.
In an alternate universe (or a current one with IPv6) every home router would have a default deny inbound security policy, and home admins could punch holes as needed the way they do today with port forwarding.
The conceit behind NAT is that 99% of traffic over the router will be client-server and the last 1% can get away with separately negotiating with the router to get inbound traffic.
For example my ISP Xfinity by default will put your router in CGNAT space (and ipv6) but if you request port forwarding from a mobile app the upstream router will assign you a ipv4 address and it all works. NAT is considered fine because adding roadblocks to server hosting is a acceptable tradeoff.
The reason they i think they can be so flexible is that they likey have a ipv6 backbone to route to all the customers and ipv4 is not used for routing but as a extra service layered on top with packing the 48 bits of ipv4 and port inside a ipv6 address via MAP-T
I doubt it.
Very few devices do port NAT without also doing firewalling, since firewalling is simpler.
This is worse for everyone in so many ways:
1. Forwarding ports suddenly makes you insecure, because you already were.
2. You have to fuck with your router config to even do that, and risk breaking something else along the way. Nobody should have to bother, because port forwarding shouldn't exist in the first place.
3. Many ISPs make it difficult or impossible to configure your firewall, let alone reserve a static public IP.
4. It's an eternal problem that isolates itself from any true solution. Any actually good UPnP implementation would just be stuck behind your NAT and firewall.
The entire premise "as long as you can control it" is the core issue, and the fundamental reason why NAT is the original sin. Without NAT, there wouldn't be anything to get control of.
You can have a stateful firewall that blocks non-established-connection packs and all your publicly addressable devices would not be reachable. NAT ≠ firewall (though they often glommed together on CPEs).
And NAT is also giving a false sense of security in some ways: "this device has an RFC 1918 address so is not reachable, and therefore safe". Yeah, except if another device already on the inside is / gets compromised. Perhaps if everything had a public address folks would be more circumspect.
Right, but it's easy to get in the mindset that because devices are on the "inside" network they are safer. This is the risk that NAT brings: RFC 1918 = safe(r).
If every device has a 200::/3 address, then even if there's a SPI firewall which prevents external connections, it may help to reduce this inside/outside thinking.
IPv6 just works. DNS gives me the address and that's it, I am now talking to my remote computer.
Just as an example, any device on your home network could have a web interface which you could access from anywhere using a web browser. All the smart light bulbs and things which need some stupid account on some service could be made so they're controlled by the user instead of some company.
I've set up things like this on my home network but it's a pain because I need to deal with port forwarding, and if I have more than one device I need to use a reverse proxy.
May be due to US DoD holding large amounts of IPv4 for no reason
The idea of router sounds simple and like it should implement some standard protocols. But in practice -- a lot of it is a mishmash of proprietary, ad hoc shitware. Something I never hear spoken about is the deep packet inspection filter component of the router firmware. It's a part of the router that decides on what traffic is allowed / not, and almost no company publishes this part. So you're not even in control of your own Internet traffic, tiny blobs of code written by some company get to decide if something is allowed or not.
If that sounds sus AF and kind of a bad idea -- well, it is. You can always run 100% open software with open-wrt. But the thing is -- the Internet isn't just your part of it. It's a network of networks, and all those shitty routers, with all that shitty firmware, is deeply ingrained within the entire Internet. That's millions of devices that would need to be replaced to fix the issue.
I've never heard of a claim like this, so I'm really curious. Note that I'm not talking about the huge DPI market for corporate/state networks.
http://github.com/richlegrand/bitbang-cli
I've been using it and it certainly has the potential. I signed up for Cloudflare's TURN server which you use with bitbang and it gets you 1TB free data transfer per month.
If I wanted to blame large corporate "users" for NAT (which I actually do), I would blame their obnoxious intransigent refusal to upgrade to IPv6. That part wasn't the ISPs' idea, but it had nothing to do with the cost of address space and everything to do with shortighted laziness. They were, in fact, willing to pay for IPv4 space to avoid having to do anything.
In the "real world", you don't really need that much security. Your actual security comes from the fact that all the worst criminals are already locked up, most of the would-be criminals are afraid of being locked up, and if somebody does actually commit a crime, they will get locked up and won't be able to do it again for a good while. A lot of real-world security is about post-factum detection (think alarms, CCTV, panic buttons etc), because in the real world, detection and prevention are two sides of the same coin.
This only works because if a real-world crime happens, the criminal by definition is in the same location as the victim, and law enforcement cares most about the community they serve. If the criminal is across the world, as is the case in cyberspace, even if it's a friendly country, it's often "not their problem". This means internet systems need actual security, and NAT provides exactly that.
If not for NAT, we'd all need a firewall, and things would be almost if not exactly the same. In the real world, "leave things relatively open, because locks are mostly for keeping honest people honest" is a valid strategy. This strategy doesn't work on the internet.
There's probably a field of study with vocabulary and accompanying proofs of significant rigor that prove or disprove this. Maybe they'll stop by our little subthread and clear it up.
This is a very common misunderstanding. NAT and firewalls are separate concepts. You can also have NAT with no meaningful firewall -- a port remapping NAT that allows anything through.
Most IPv6 networks are firewalled but there's no NAT.
You still need a firewall regardless of NAT. Otherwise, every time you take your computer outside of your home, you're no longer protected. Any attacker or compromised device on your hotel, airport, or coffee shop wifi network would have direct access to your machine.
A NAT implementation could broadcast any "WAN" side incoming packets to all link local clients (aka: put everyone in the DMZ). The only thing preventing that is a stateful firewall.
A lot of this feels like a requiem for the days when the only people on the Internet were "high-computer-skill" type folks. Most people will gravitate to "user-friendly" solutions: Gmail and other managed email providers were popular because they didn't stop working when you shut down your computer to save electricity, when your server's hard drive crashed, when you upgraded your computer to something with a faster processor, more RAM, and a newer operating system. It was hard enough to educate laypeople about URLs and email addresses (AOL keywords, anyone?), let alone a combination of random numbers in an IP address, or convincing people to register domain names.
Yes, NAT shoved fences into a network that was all about connecting everybody. But we'd still end up with server-client cloud architectures, even if we had started with IPv6 in the beginning. ISPs would have just sold highly restrictive firewalls as part of their home-install basic boxes, and we'd still have ended up with those fences.
This works, until you have more than one person accessing your server. Then you need to worry about accounts, credentials, data isolation, etc. And then if a couple of people connect to your server and start using it, you have to worry about staying online, staying updated, backing up the data. But other than that... yes, trivial.
And just to be really explicit, you always have more than one person accessing your server, and most of the time they are unwanted users trying to break in.
Exactly. Of all the reasons why the average person doesn't have an Internet-visible server, NAT, I would say, is pretty far down on the list.
In fact you could have an IPv6 address for each user, and if one starts becoming troublesome both revoke account and stop using that address.
You could create a new IPv6 address every millisecond, and it'd take 584,868,233 years to exhaust a IPv6 subnet (/64).
But an ordinary person? I don't see it. If it's tough for an ordinary person to handle safely opening a port in their firewall for forwarding, it's tough squared (or perhaps cubed or an even higher power) for an ordinary person to handle auto-creating a separate IPV6 address for every other person that wants to communicate over the Internet with them.
Not to mention, how does this work with DNS? If Ordinary Person wants to put an article up for others to read, how do the others find it? Surely not by Ordinary Person sending individually crafted IPV6 addresses to anyone who wants to read their article. (And how do they even find those other people if they are also creating new IPV6 addresses for everyone else?)
Exactly. Which is the issue with saying, as the article does, that NAT is the reason most people don't have an Internet visible server, when the real reason is that their computers need to be behind a firewall and once you're behind a firewall, safely opening up just little pieces of it for an Internet visible server is something most people aren't going to want to deal with.
Jill from Elbonia may be always be a threat, but this doesn't mean that Joe from Accounting is not a threat or cannot ever provide a vector for Jill. :)
Thankfully, we have wireguard now. It drops all packets by default. From the perspective of people who don't have the requisite cryptographic keys, it's like the computer is not even there to begin with.
I've always found it strange how people just put computers out there on the internet and just allow them to interact with total internet randoms. Why are we allowing our computers to talk to strangers? No wonder people are getting hacked.
FWIW I (writer of blog post) am 21 years old and just a bitch lol
Also, the lazy sysadmin forgot to set a quote for today.
The thing about smartphones is that they are both completely dependent on wireless connections to central servers in order to function and completely unsuitable to operate as servers. If you forced your phone to serve files anyway, your battery would drain quickly and the CPU would be drowning in its own waste heat. You might argue that you could still do non-server things on the phone, but practically speaking, a node that can't handle server tasks is just a leech. P2P networks work on a mutual aid basis; they require the majority of nodes be capable of shouldering traffic or sharing files in order to be a net benefit. If you add, say, tens of millions of new mobile phones to the network, the network will become unusable as any desktop machine gets DDoSed by hordes of phones asking for a babysitter.
So even in the world where IPv6 did to v4 what v4 did to NCP, we'd still ultimately end up with "my files go in the cloud", because clouds are coinventions of smartphones, in the same way that cars are coinventions of suburbs. You can't have one without the other, and once you do have both, they become so economically dominant that others get socially coerced into using them.
Obviously it's all very basic, but with a few years of development and polish (and probably someone besides Nokia copying the idea) I think this would be a compelling product. You could basically have the same feature set as something like iCloud but without the subscription or your files going elsewhere.
Skype was originally peer-to-peer for comms, but ended up with "super-nodes" because of NAT limitations (not sure if STUN/TURN/ICE had been invented by that point). BitTorrent is still peer-to-peer. A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port.
But this doesn't only hurt server-y stuff: you may not notice it if you're with a legacy MegaISP with lots of money to throw at IPv4 allocations, but if you're with a younger or smaller ISP, then there's a good chance you're behind CG-NAT, so many console games won't work.
All practical solutions for p2p these days require NAT hole punching through STUN and signaling servers anyway, so even p2p has to be bootstrapped via client/server. Easier to just keep the protocol client/server then.
I have been told in many HN discussions that IPv4 is good enough and that IPv6 doesn't solve any problems. ¯\_(ツ)_/¯
The problem is, and has always been, that NAT doesn't solve the IPv4 exhaustion problem. It took a long time before I understood this due to all the noise IPv6 people make, but newer ISPs don't have enough IPv4 addresses to give every household its own address, so they use CGNAT for residential Internet access. This is what people should be focusing on, but it's not. All arguments for IPv6 are irrelevant drivel about how bad NAT is.
The length of Tailscale's 2020 weblog post "How NAT traversal works":
* https://tailscale.com/blog/how-nat-traversal-works
and their 2025 "NAT traversal, and how we're improving it (pt. 1)"
* https://tailscale.com/blog/nat-traversal-improvements-pt-1
indicates the opposite to me.
Certainly there are still (SPI) firewalls with IPv6, but at least with CPEs things are limited to 'only' hole punching with PCP (or UPnP) as opposed to all the ICE/TURN/STUN layers (and heaven help you if you're behind CG-NAT).
> The problem is, and has always been, that NAT doesn't solve the IPv4 exhaustion problem.
NAT was intended to be a "short-term solution" as noted in the NAT RFC (from 1994):
* https://datatracker.ietf.org/doc/html/rfc1631
This is such a common and stupid problem. It's the same with SSH; if you want to run your own git host, you need to either reserve public port 22 to git, or use it on a non-default port.
More protocols should have some kind of header to tell the server what name was used to connect, just like HTTP's Host header. If SSH clients told the server, "hey I connected via git.example.org", you could have an SSH proxy behind the NAT forward that connection to your git host. If the Minecraft client told the server, "hey I connected via survival.example.org" or "hey I connected via creative.example.org", you could have a Minecraft proxy server route the traffic to the right local address/port.
(I'm actually implementing multiplayer in a game right now and I'm adding this information to the initial connection handshake message, with the intention that you could make a proxy server.)
Absolutely not. They can charge your $9.99/mo so you can connect their craptastic app to their craptastic cloud so you can "use their app from anywhere".
1) The typical "NAT" is a "PAT", which requires state for mapping traffic flow. An implementation is going to look very similar to a stateful firewall, by necessity, not accident.
2) The use of RFC-1918 addresses behind the router / NAT box provides some protection. If your address is not globally reachable, it's much harder to reach any hosts behind it. Yes, a poor implementation might allow direct routing from adjacent networks, like your ISP or neighbor. But that still isolates you from 99.99% of the internet.
I ran Linux, *BSD, and Solaris systems for years without any firewalls, host or otherwise.
Because of NAT, hierarchy (centralized servers) is the foundational design pattern of the internet, and anyone who wants any semblance of anarchy (decentralized networks) must use a workaround that is itself hierarchical and costly. We are all interconnected, but only a wealthy few can truly speak fist.
At this point the IP architecture(s) we have are wired in, and I don't think they can be changed. It'd be like trying to go back in time and re-do the x86 architecture. At some point you're stuck with a system, including its warts, and NAT and IPv4 are warts we're stuck with.
We might eventually reach sufficient IPv6 penetration that P2P protocols can start ignoring IPv4, but it'll be a while. I have seen statistics that IPv6 traffic to Google is starting to hit 50%, which is a huge milestone, and it's slowly growing.
Why do so many people still think NAT equals firewall when they're not directly related?
I guess it's because they're normally packaged together for practical reasons. They're both packet handling functions often performed in the same place. But they are NOT the same and you can have either one without the other. Most IPv6 networks have firewalls, and it's possible to have NAT that passes anything.
The reason NAT is seen as security on home networks is that, absent a firewall, it acts as a default deny to inbound traffic.
It doesn't actually do that.
You don't need to take that on faith either -- you can just test it.
How do you want to go about doing this? Although, 100% of the time people have asked me to do this they chicken out at actually doing it, so I suppose you will too. You might prefer to test with some network namespaces instead.
This is the draw to onionv3 services for me. It's still exactly like this.
I made a post the other day wondering why they aren't way more popular than they are. Do most people just not know? It's a pretty nice thing to be able to do.
Especially in a world where you can create your own utilities very easily, it's the perfect way to gain back some sovereignty over your compute in the age of CGNAT.
Sure it's not blazing fast or anything...but it's perfectly adequate for 90% of things.
I implemented the current NAT system in Linux. In particular, avoiding port reservation in favor of squishing more connections into one IP address, as long as the remote address allowed us to differentiate.
This, in turn, means incoming traffic from a different address is unroutable. You no longer have a public endpoint. This is "poor man's firewall", but erodes our ability to have a server the way we used to.
I was a young engineer solving a specific problem, without considering the larger picture. It wasn't the only thing, but I feel it definitely moved the internet to a client/server infrastructure and a key equality was lost.
IPv4 without NAT was fucked at the design stage. To be fair: Who knew?
I was asked by my employer a while back to investigate this new www thing that has hit the internet (in around 1994 or 5, it took a while to notice) and I said it was a bit crap and no better than WAIS and GOPHER. I was using telnet on a Windows 3.1 PC and telnetting madly via a VAX and a X.25 PAD and what I now know was close to magic!
No one had any idea how things would turn out back then.
I'm actually quite impressed how long IPv4 has managed to work and without NAT (which I do mildly despise, given 30 years messing with this stuff), it would be stuffed.
Thank you for your work.
I had a corporate internship in the late 1990s and they blocked external web access.
They did, however, allow external Telnet access. This meant that whenever I had free time and/or was waiting for new projects, I would telnet back to my college server and use lynx to go read my favorite websites.
The Internet Protocol only concerns itself with IP addresses. The idea is that each computer has an IP address, so computers can communicate by sending IP packets; each IP packet says, "Message from computer with IP address X to computer with IP address Y".
But computers have multiple processes, so there's a need to know which process at the receiving computer is the recipient and which process on the sending computer is the sender. This is why transport protocols (TCP and UDP) add a port field. A port uniquely identifies a particular socket opened by a particular process on a computer. So a TCP or UDP message sent via the Internet Protocol contains the information, "From the socket with port 41590 on the computer with IP address X, to the socket with port 443 on the computer with IP address Y".
NAT is a giant hack which is primarily implemented in routers. It makes a whole household (or office building, or university campus) look to the outside world like one big computer with one IP address.
Say we have a computer with IP address L, a router with public IP address X, and a public server with IP address Y. The computer will send a message to the router which says, "From port 41590 @ L, to port 443 @ Y". The router will invent a new random port number (say 41200), add an entry to its NAT table which says "port 41200 means port 41590 @ L", then send a message to the public Internet: "From port 41200 @ X, port 443 @ Y".
When someone then sends back a message "to port 41200 @ X", the router looks that up in its NAT table and rewrites the packet to say "to port 41590 @ L", then sends it to the computer with that IP address.
The computer doesn't really know that it's speaking through a router (it needs to know that "packets to the public Internet should be sent via the router" but that's it, the packets it sends and receives looks the same as if the router wasn't there). The rest of the world doesn't really know that it's speaking to a computer (from their perspective, it looks like they're just speaking directly to the router). All the special logic lives only within the router which does network address translation.
Already back then, you couldn't easily deploy solutions which required all computers and middle-boxes on the Internet to change. That's why NAT exists in the first place.
You could deploy a new NAT implementation, but the problem NAT solves is fundamentally that there aren't enough IPv4 addresses for every computer to have an IPv4 address. I don't think there's a better solution to that problem other than switching everything over to IPv6 (which has been in progress for the past 30 years and has barely reached 50%).
Working around NAT was trivial for the people who actually cared about it. I was adding port forwarding rules to my parents' router at age 12. Turns out exposing a poorly-configured Windows XP box to the wider interwebs is a Really Bad Idea - and for the same reason UPnP letting random unpatched shady P2P applications do the same is Very Much Not Good.
Let's face it: consumer devices simply aren't secured well enough to let the entire internet poke around in them, and it was even worse a decade or two ago. Decentralization is pointless when it only results in people compromising their own machines, and the people with the skills to set up a 24/7 Linux server in a broom closet won't care about adding some NAT forwarding rules.
Even without NAT, we would've definitely gotten home internet routers firewalled with a default-deny policy on all incoming connections. Exactly the same "manually configure a bypass, or use UPnP" dance blocking you from trivially running a web-available service on your machine, but with a firewall rule rather than a NAT port forward.
It's of course a different story with CGNAT, but that only became a thing well after the internet was already centralized.
"Naturally, people noticed this was a problem almost immediately, because people have wanted to run game servers, FTP servers, and web servers from their bedrooms since roughly the beginning of time."
TCP/IP was in use for at least thirteen years before the first "commercial ISP" offering internet access oustide of work or school
In 1994 the www had only been public for less than twelve months
According to one source, 11 million US households got internet access in 1994
https://www.pewinternet.org/2014/03/11/world-wide-web-timeli...
In 1994, there were over 97 million US households
https://fred.stlouisfed.org/series/TTLHH
According to another source, "no one" had home internet access in 1994
https://www.ntia.gov/sites/default/files/data/fttn99/FTTN_I/...
Did the majority of internet users want to run servers from their bedrooms
In 1994, the majority of the US population did not even have a home computer
(Perhaps everyone reading this had one but that's not the majority)
In some ways, little has changed. Organisations like academic institutions, governments and large businesses can have internet access without "NAT"
Everyone else is an afterthought
And most internet subscribers still have no interest in running servers from their bedrooms
[1] https://yggdrasil-network.github.io/
[2] https://github.com/yggdrasil-network/yggdrasil-go