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?
> 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.
> 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 BitTorrent or Skype or early Spotify.
That's fine. Based on my recollection 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.
> 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.
> 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.
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. :)
I mean, no, you don't have to worry about all that stuff unless the business logic demands it. The OP is entirely correct for eg just serving a static file.
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.
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
Yeah NAT is still "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. It's maybe not super elegant but it works.
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 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 think 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.
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.
> 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.
> "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 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.
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.
> 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 started 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 bothered 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.
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.
... 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.
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.
>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.
This might not be a good thing. Perhaps if there had been no protection for those odious operating systems, they'd have died the horrible deaths they earned decades ago. We should only want to protect things we intend to keep, after all, and none of us wanted to keep that garbage.
All of the current OS choices are insecure by design. The all operate programs with the ambient authority of the user. While this was fine for the corporate world of AT&T in the 1970s, and the classroom in the 1980s, it's insane to use it in the era of ubiquitous persistent megabit Internet connectivity, and mobile code.
I know of zero systems that can survive exposure to the raw Internet, unpatched and without administrative oversight, with uptimes of years.
>I know of zero systems that can survive exposure to the raw Internet
Sure. And as long as nothing has to survive exposure to the raw Internet, no one will build anything that could survive it. Not sure why that's so difficult to understand. You seem to think that the protection is the reaction to dangerous operating systems, when it's the cause.
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.
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.
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.
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.
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 could share things easily, sure, but anyone could get hacked pretty easily and very targetted.
After NAT, sharing was still easy lots of 'piracy' apps, various messengers with NAT passthrough
Both before and after you needed to be technical, you can't ask someone that doesnt know about computers to set up an FTP server, and if they did it would be a nightmare and they'd likely share their whole drive
Same goes for anything else.
Anyway, we'll get the whole non-nat with IPv6, let's see what that brings
It brings the requirement for a firewall on every endpoint with a unique address. My Phone often has an ipv6 address (found out this holiday wen I couldn't resolve one of sites because of an orphan ipv6 entry nobody noticed), and has little problems. Perhaps there is also "firewalling" on the router and the phone can't even have incoming connections. Not sure. In any case, the phone seems to do fine.
> 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)
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 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.)
NAT wasn't so much normalized as a security feature as it was introduced as one. The flagship NAT product of the 1990s was the Cisco PIX, a firewall. It resulted from Cisco's acquisition of the company that originated NAT.
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".
I would say the lack of deploying service locator records in DNS was also a major contributor. We have trillions of ports/ip combinations available and we use waste bits by always using 443.
It's fine. IPv4 addresses might get too expensive at some point, encouraging their deprecation. Or it's entirely possible having the option of IPv6 prevents IPv4 addresses from getting prohibitvely costly. Either way, IPv6 has its role.
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.
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.
while i agree with your sentiment, i personally think that the foundational design pattern of the internet as a network is highly decentralized. once you get public IP space and the infrastructure required to talk BGP, making decentralized designs is actually quite easy.
The issue that ipv4 exhausting and "solutions" around it like NAT are making it very hard for actual users (bussiness, people etc) to get access to public IP space without strings attached.
IPv6 solves a lot of this, especially because IP space is so massive LIR's don't need to be so spare with giving out address space.
The far larger issue we have is that applications are ingrained in a client server mindset, in which big incumbents want to have this architecture because it forces control from the server towards to client. And control usually also means having the data itself, which is where the real value lies.
I agree that assumptions on the application side are the bigger issue, but it's less about encouraging client/server architecture in general. It's often very helpful, even among peers, to drop into a mode where somebody is wearing the client hat and somebody else is wearing the server hat.
The sin here is the hierarchy imposed by SSL and its infatuation with server names. Its says: these people are lords, they can wear the server hat. As for the peasants, your client hats are over there. If we catch a peasant wearing a server hat, the browsers will make them look like a criminal.
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.
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.
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.
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.
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.
> 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)
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.
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.
>Counting the cost of creating the company so you can actually deal directly with a NIC?
No, the question was taking the price that the NIC sells the IP blocks at. Understanding that in order to get 1 IPv4 address you will be buying from a distributor at a markup, but still, with Wholesale prices at 0.6$ (LACNIC) to 2.5$ (ARIN) per IP address per year, even with a markup of 300%, we are still at filthy cheap prices (2.4$/year to 10$/year)
>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.
Oh, ok, I was writing mostly about server side IPv4 assignment. I guess your position is a much stronger stance than mine, I argue that all servers should have an IP(v4) adress, you argue that every client device should. In that sense, consider that there's a lot of users, on this website even, that insist on running hosts without a dedicated IP address. There's lower hanging fruit.
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.
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.
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.
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 liberally passes anything.
I wonder how much this misconception has delayed V6 adoption? "But I'll be wide open without NAT!" No, you can have a firewall. Most IPv6 routers have stateful firewalls on by default.
> 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'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 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.
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.
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.
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.
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.
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.
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/
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.
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.
When I want to debug reachability concerns, it's a shame that I can only use ping/traceroute between the non-NAT peers, and then have to SSH to my reverse proxy to do yet another ping to the backend. Similar for tcpdump.
This is the cost to splitting your routing between layer 3 and 4.
I'm now IPv6 everywhere, and so I get to just use ping. Much simpler.
Further, protecting IPv6 services is simpler, because I can terminate (m)TLS on the backend. With a reverse proxy on another host, I have to have yet another means of securing the proxy-backend path. Yet more complexity!
> And the fact that consumers can't just directly connect to each other is a feature.
Consumers should be protected by firewalls. That's independent of routing.
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
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.
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.
Sorry.
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.
Thank you for your work.
> 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?
What do you think is the best road to a decentralized net from here? Any specific solutions you like?
Wow! Thanks for the note.
What a comment, lmao. I'm aware of some of the work that you've done. You've had an impressive career, tbh.
> 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.
> 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 BitTorrent or Skype or early Spotify.
"Client-server" thinking may in general be a 'hobbled' way of thinking of things.
There's DC++, Tox.
> A lot of this feels like a requiem for the days when the only people on the Internet were "high-computer-skill" type folks.
FWIW I (writer of blog post) am 21 years old and just a bitch lol
But you are a "high-computer-skill" person.
Also, the lazy sysadmin forgot to set a quote for today.
Not saying this is what’s going on, but you can ABSOLUTELY have nostalgia for a time that wasn’t your own, too.
Oh yeah absolutely
I suppose I could ask elsewhere but do you (or does anyone else) have a word/term for this?
That's fine. Based on my recollection 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.
> 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.
> 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.
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.
> 2. With IPV6 you can have so many IPS that unwanted users can't guess your IP.
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).
> 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.
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. :)
I mean, no, you don't have to worry about all that stuff unless the business logic demands it. The OP is entirely correct for eg just serving a static file.
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.
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
That can be because UPnP supports only ip4, you need PCP for ip6, but CGNAT supporting port mapping is unheard of.
Yeah NAT is still "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. It's maybe not super elegant but it works.
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 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 think 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.
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. Are you giving each device its own VLAN, subnet, etc?
> 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.
> 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.
> "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 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.
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.
> 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 started 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 bothered 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.
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.
... 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.
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.
>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.
This might not be a good thing. Perhaps if there had been no protection for those odious operating systems, they'd have died the horrible deaths they earned decades ago. We should only want to protect things we intend to keep, after all, and none of us wanted to keep that garbage.
All of the current OS choices are insecure by design. The all operate programs with the ambient authority of the user. While this was fine for the corporate world of AT&T in the 1970s, and the classroom in the 1980s, it's insane to use it in the era of ubiquitous persistent megabit Internet connectivity, and mobile code.
I know of zero systems that can survive exposure to the raw Internet, unpatched and without administrative oversight, with uptimes of years.
>I know of zero systems that can survive exposure to the raw Internet
Sure. And as long as nothing has to survive exposure to the raw Internet, no one will build anything that could survive it. Not sure why that's so difficult to understand. You seem to think that the protection is the reaction to dangerous operating systems, when it's the cause.
Regular NAT is not fine at all. It adds needless friction and complexity. Networking is complex and annoying enough without it.
IPv6 just works. DNS gives me the address and that's it, I am now talking to my remote computer.
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.
> If not for NAT, we'd all need a firewall
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.
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.
> If not for NAT, we'd all need a firewall
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.
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.
I remember times before NAT and SSL
You could share things easily, sure, but anyone could get hacked pretty easily and very targetted.
After NAT, sharing was still easy lots of 'piracy' apps, various messengers with NAT passthrough
Both before and after you needed to be technical, you can't ask someone that doesnt know about computers to set up an FTP server, and if they did it would be a nightmare and they'd likely share their whole drive
Same goes for anything else.
Anyway, we'll get the whole non-nat with IPv6, let's see what that brings
It brings the requirement for a firewall on every endpoint with a unique address. My Phone often has an ipv6 address (found out this holiday wen I couldn't resolve one of sites because of an orphan ipv6 entry nobody noticed), and has little problems. Perhaps there is also "firewalling" on the router and the phone can't even have incoming connections. Not sure. In any case, the phone seems to do fine.
> 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)
There's no home wifi router for an address assigned by the cell carrier.
> Not sure. In any case, the phone seems to do fine.
That's mostly because a phone is very locked down, can you run an accessible ftp server on your phone?
It's also not windows
For android, the answer is yes (without rooting being required).
> without rooting being required
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
Also on iOS, though I've only done this over Wi-Fi, and have no idea whether telcos expose open ports to the (IPv6) Internet.
Phone OSs tend to pay a lot more attention to security than the crap they put on consumer-grade routers, "smart" TVs and cheap webcams.
I would invest in a proper firewall for the entire home before opening up anything to the world, IPv6 or not.
> Anyway, we'll get the whole non-nat with IPv6, let's see what that brings
I'll believe it when I see it. So far it doesn't look like IPv6 will win anytime soon.
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.
On a tangent: compare persistent cryptographic identities with https://en.wikipedia.org/wiki/Off-the-record_messaging
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.)
It's already won. Over 50% of Internet users are on ipv6.
Source: <https://www.google.com/intl/en/ipv6/statistics.html>
In the US, it’s currently over 60%: <https://stats.labs.apnic.net/ipv6/US>
Well, any 3G or later mobile backbone is SIP+SCTP over IPv6. So in many ways it won already
My phone, on 4g, is not IPv6
At home it can be if I connect t to my ip6 ssid, but there’s a stateful firewall which may as well nat.
What your phone shows to app land is entirely different thing. I'm talking about the backbone.
Weird, I used to remember that going to test-ipv6.com on my mobile (on 4G and 5G) used to fail all the tests. But today it passes.
Well, good to know!
Firewalls, both at the perimeter and locally, was what patched over this. NAT had nothing to do with it.
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.
NAT wasn't so much normalized as a security feature as it was introduced as one. The flagship NAT product of the 1990s was the Cisco PIX, a firewall. It resulted from Cisco's acquisition of the company that originated NAT.
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".
... and NAT was a big part of giving them the market power they now use to enforce that.
I would say the lack of deploying service locator records in DNS was also a major contributor. We have trillions of ports/ip combinations available and we use waste bits by always using 443.
As a engineering all my career life focused on networking, I am so depressed that IPv6 still not fully replaced IPv4
We have dozen of RFCs and vendors gears support IPv6 as well, but it just not finished
It's fine. IPv4 addresses might get too expensive at some point, encouraging their deprecation. Or it's entirely possible having the option of IPv6 prevents IPv4 addresses from getting prohibitvely costly. Either way, IPv6 has its role.
One option to resolve current worrying trends is to invest in development of alternative network protocols/structure, Yggdrasil[1][2], for example.
[1] https://yggdrasil-network.github.io/
[2] https://github.com/yggdrasil-network/yggdrasil-go
I miss the old days of ICQ and just dragging a file onto the person you are sending your file and bam, done like dinner.
Can't every chat app do this now, including SMS/MMS?
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.
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.
while i agree with your sentiment, i personally think that the foundational design pattern of the internet as a network is highly decentralized. once you get public IP space and the infrastructure required to talk BGP, making decentralized designs is actually quite easy.
The issue that ipv4 exhausting and "solutions" around it like NAT are making it very hard for actual users (bussiness, people etc) to get access to public IP space without strings attached.
IPv6 solves a lot of this, especially because IP space is so massive LIR's don't need to be so spare with giving out address space.
The far larger issue we have is that applications are ingrained in a client server mindset, in which big incumbents want to have this architecture because it forces control from the server towards to client. And control usually also means having the data itself, which is where the real value lies.
I agree that assumptions on the application side are the bigger issue, but it's less about encouraging client/server architecture in general. It's often very helpful, even among peers, to drop into a mode where somebody is wearing the client hat and somebody else is wearing the server hat.
The sin here is the hierarchy imposed by SSL and its infatuation with server names. Its says: these people are lords, they can wear the server hat. As for the peasants, your client hats are over there. If we catch a peasant wearing a server hat, the browsers will make them look like a criminal.
Our applications have evolved accordingly.
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.
NATs are not firewalls. Any firewall-like functionality provided by NAT is entirely accidental and better provides by an actual NAT.
There are really two things here:
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.
Windows wasn't secure enough.
I ran Linux, *BSD, and Solaris systems for years without any firewalls, host or otherwise.
Yeah, no.
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.
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.
Check out Bitbang:
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.
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.
> Why you don’t have a FTP server
May be due to US DoD holding large amounts of IPv4 for no reason
Time to set up IPV6.
Or just use an ipv4 address. It works I swear
In regions where IPv4 addresses are scarce, you may not even have a single public IPv4 address. I'm fortunate to have one, but still needs NAT.
IPv4 costs are tiny compared to the cost of providing an internet connection.
Not every place is the same.
Do you have any example where leasing an ipv4 block from a NIC directly costs more than 5$ per IPv4 address per year?
Yes. My ISP will rent me a single IPv4 address for $10 per month. Or I can use DHCP, where my IPv4 address can change at their whim.
> 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)
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.
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.
>Counting the cost of creating the company so you can actually deal directly with a NIC?
No, the question was taking the price that the NIC sells the IP blocks at. Understanding that in order to get 1 IPv4 address you will be buying from a distributor at a markup, but still, with Wholesale prices at 0.6$ (LACNIC) to 2.5$ (ARIN) per IP address per year, even with a markup of 300%, we are still at filthy cheap prices (2.4$/year to 10$/year)
>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.
Oh, ok, I was writing mostly about server side IPv4 assignment. I guess your position is a much stronger stance than mine, I argue that all servers should have an IP(v4) adress, you argue that every client device should. In that sense, consider that there's a lot of users, on this website even, that insist on running hosts without a dedicated IP address. There's lower hanging fruit.
It's free money to your ISP. A lot of ISPs us CGNAT.
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.
NAT made distinction between PCs and servers too broad.
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.
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.
What consumer routers implement DPI in their default firmware? What type of traffic are you claiming they are dropping?
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.
Reading the comments:
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 liberally passes anything.
I wonder how much this misconception has delayed V6 adoption? "But I'll be wide open without NAT!" No, you can have a firewall. Most IPv6 routers have stateful firewalls on by default.
You are correct.
The reason NAT is seen as security on home networks is that, absent a firewall, it acts as a default deny to inbound traffic.
In other words, the reason NAT is seen as security is that it provides security (imperfectly, like almost everything else).
Related comment from another thread
https://news.ycombinator.com/item?id=49454785
> Even more ironic is that NAT got normalized as a security feature — “your devices are hidden!” — which is one of the things that made people resist the thing that would fix it.
That tracks. I briefly looked into the Tailscale website and I thought maybe I was wrong, maybe it's not a NAT/ddns toolchain, maybe it's something more complex that I'm too dumb to understand. But if my thesis that it's NATware is right, it makes sense to market it as a security product, it fooled me for one, but it also passes as a quality product for an organization, and they feel they are getting a security product when they are actually signing the purchase request of a developer that is applying networking techniques they learned from managing a videogame server.
I'm having trouble decoding this but Tailscale is a VPN that can traverse NAT when necessary. Arguably Tailscale wouldn't be needed if NAT didn't exist but considering the timeline I'm not going to declare a conflict of interest.
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'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.
Thanks for sharing.
This sounds great! Deffo gonna investigate this!
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 don't think any of us could know how most users use it.
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.
This use case you have in mind where someone has a fixed server and uses tailscale to patch over the lack of IP, I think is a very rare use case.
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
> Certainly
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.
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.
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.
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.
> the mere fact that Layer 2 and Layer 3 addresses are distinct concepts.
If it weren't you couldn't have the same IP over several interfaces.
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.
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/
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.
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.
When I want to debug reachability concerns, it's a shame that I can only use ping/traceroute between the non-NAT peers, and then have to SSH to my reverse proxy to do yet another ping to the backend. Similar for tcpdump.
This is the cost to splitting your routing between layer 3 and 4.
I'm now IPv6 everywhere, and so I get to just use ping. Much simpler.
Further, protecting IPv6 services is simpler, because I can terminate (m)TLS on the backend. With a reverse proxy on another host, I have to have yet another means of securing the proxy-backend path. Yet more complexity!
> And the fact that consumers can't just directly connect to each other is a feature.
Consumers should be protected by firewalls. That's independent of routing.
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
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.
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 is a window for every buttock. I don't see this as a good thing.