Rendered at 13:07:35 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
RustyRussell 15 hours ago [-]
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.
mort96 1 hours ago [-]
If it's any consolation, I don't think NAT did anything particularly harmful other than making the adoption of IPv6 less urgent. It's CGNAT that's the real problem, not NAT.
gerdesj 13 hours ago [-]
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.
alexpotato 13 hours ago [-]
> 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.
pratyahava 11 hours ago [-]
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?
mort96 1 hours ago [-]
NAT itself was a hack to let everything keep working like it already was despite there being more computers than IPv4 addresses.
The Internet Protocol only concerns itself with IP addresses. The idea is that each computer has an IP address, so computers can communicate by sending IP packets; each IP packet says, "Message from computer with IP address X to computer with IP address Y".
But computers have multiple processes, so there's a need to know which process at the receiving computer is the recipient and which process on the sending computer is the sender. This is why transport protocols (TCP and UDP) add a port field. A port uniquely identifies a particular socket opened by a particular process on a computer. So a TCP or UDP message sent via the Internet Protocol contains the information, "From the socket with port 41590 on the computer with IP address X, to the socket with port 443 on the computer with IP address Y".
NAT is a giant hack which is primarily implemented in routers. It makes a whole household (or office building, or university campus) look to the outside world like one big computer with one IP address.
Say we have a computer with IP address L, a router with public IP address X, and a public server with IP address Y. The computer will send a message to the router which says, "From port 41590 @ L, to port 443 @ Y". The router will invent a new random port number (say 41200), add an entry to its NAT table which says "port 41200 means port 41590 @ L", then send a message to the public Internet: "From port 41200 @ X to port 443 @ Y".
When someone then sends back a message "to port 41200 @ X", the router looks that up in its NAT table and rewrites the packet to say "to port 41590 @ L", then sends it to the computer with that local IP address.
The computer doesn't really know that it's speaking through a router. It needs to know that "packets to the public Internet should be sent via the router" but that's it, the packets it sends and receives looks the same as if the router wasn't there. The rest of the world doesn't know that it's speaking to the computer behind the router; from their perspective, it looks like they're just speaking directly to the router. All the special network address translation logic lives only within the router.
Already back then, you couldn't easily deploy solutions which required all computers and middle-boxes on the Internet to change. That's why NAT exists in the first place.
You could deploy a new NAT implementation, but the problem NAT solves is fundamentally that there aren't enough IPv4 addresses for every computer to have an IPv4 address so you need multiple computers to share. I don't think there's a better solution to that problem other than switching everything over to IPv6 (which has been in progress for the past 30 years and has barely reached 50%).
As an aside, you see the term "CGNAT" sometimes as well. This stands for Carrier-Grade NAT and is an evolution of the NAT concept to much bigger contexts; a whole city could share a handful of public IP addresses, making large regions effectively one "local network" behind a "router". Multiple streets could look to the outside world like they're just one gigantic computer. Each household in that area will then probably do its own layer of NAT, making it look to the CGNAT router like the household is one big one computer. This configuration can be called "double NAT". Since each router doing NAT only needs to know about its own NAT, there's really no limit to how deeply you can nest it.
an0malous 12 hours ago [-]
What do you think is the best road to a decentralized net from here? Any specific solutions you like?
tornado134 8 hours ago [-]
[dead]
robinpie 12 hours ago [-]
Wow! Thanks for the note.
Uptrenda 13 hours ago [-]
What a comment, lmao. I'm aware of some of the work that you've done. You've had an impressive career, tbh.
solatic 1 days ago [-]
> 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.
throw0101a 15 hours ago [-]
> 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.
mort96 47 minutes ago [-]
> A number of folks ran Mincecraft servers at home, but you'd only be able to have one on the default port.
This is such a common and stupid problem. It's the same with SSH; if you want to run your own git host, you need to either reserve public port 22 to git, or use it on a non-default port.
More protocols should have some kind of header to tell the server what name was used to connect, just like HTTP's Host header. If SSH clients told the server, "hey I connected via git.example.org", you could have an SSH proxy behind the NAT forward that connection to your git host. If the Minecraft client told the server, "hey I connected via survival.example.org" or "hey I connected via creative.example.org", you could have a Minecraft proxy server route the traffic to the right local address/port.
(I'm actually implementing multiplayer in a game right now and I'm adding this information to the initial connection handshake message, with the intention that you could make a proxy server.)
ndiddy 14 hours ago [-]
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.
throw0101a 14 hours ago [-]
"Client-server" thinking may in general be a 'hobbled' way of thinking of things.
mort96 43 minutes ago [-]
It's sadly the only practical way to do things now. For client/server, you only need one party (the server) to not be behind CGNAT. For p2p, you need both parties to not be behind CGNAT. It's typically only possible to guarantee that one party isn't behind CGNAT.
All practical solutions for p2p these days require NAT hole punching through STUN and signaling servers anyway, so even p2p has to be bootstrapped via client/server. Easier to just keep the protocol client/server then.
pfa87 39 minutes ago [-]
[dead]
GoblinSlayer 12 hours ago [-]
There's DC++, Tox.
robinpie 16 hours ago [-]
> 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
trevithick 11 hours ago [-]
But you are a "high-computer-skill" person.
Also, the lazy sysadmin forgot to set a quote for today.
DanHulton 15 hours ago [-]
Not saying this is what’s going on, but you can ABSOLUTELY have nostalgia for a time that wasn’t your own, too.
robinpie 14 hours ago [-]
Oh yeah absolutely
jimmygrapes 13 hours ago [-]
I suppose I could ask elsewhere but do you (or does anyone else) have a word/term for this?
tech2 1 hours ago [-]
Anemoia is the term, I believe, and an almost perfect fit (nostalgia for a time you have never experienced)
jasonfarnon 12 hours ago [-]
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.
kmeisthax 15 hours ago [-]
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.
ndiddy 15 hours ago [-]
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.
warkdarrior 17 hours ago [-]
> 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.
pdonis 16 hours ago [-]
> 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.
mohaine 15 hours ago [-]
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.
throw0101a 15 hours ago [-]
> 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).
matheusmoreira 14 hours ago [-]
> 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.
ssl-3 15 hours ago [-]
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. :)
mxkdjdjdb 16 hours ago [-]
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.
elric 1 days ago [-]
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.
ironhaven 17 hours ago [-]
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
GoblinSlayer 12 hours ago [-]
That can be because UPnP supports only ip4, you need PCP for ip6, but CGNAT supporting port mapping is unheard of.
mort96 1 days ago [-]
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.
orbital-decay 1 days ago [-]
>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.
why_at 11 hours ago [-]
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.
throw0101a 15 hours ago [-]
> 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.
icedchai 14 hours ago [-]
Generally, firewalls aren't going to save you from an internal compromise either. Are you giving each device its own VLAN, subnet, etc?
throw0101a 14 hours ago [-]
> 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.
Dylan16807 17 hours ago [-]
> 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.
Hizonner 1 days ago [-]
> "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.
thomastjeffery 15 hours ago [-]
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.
preisschild 1 days ago [-]
> 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.
elric 1 days ago [-]
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.
combyn8tor 16 hours ago [-]
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.
Hizonner 1 days ago [-]
... 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.
mhurron 18 hours ago [-]
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.
icedchai 18 hours ago [-]
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.
unethical_ban 18 hours ago [-]
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.
NoMoreNicksLeft 1 days ago [-]
>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.
mikewarot 1 days ago [-]
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.
NoMoreNicksLeft 21 hours ago [-]
>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.
blindport 20 hours ago [-]
[dead]
matheusmoreira 14 hours ago [-]
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.
miki123211 1 days ago [-]
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.
tom_alexander 16 hours ago [-]
> 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.
baron3dl 18 hours ago [-]
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.
ElectricalUnion 14 hours ago [-]
> 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.
api 16 hours ago [-]
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.
tptacek 11 hours ago [-]
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.
mittensc 1 days ago [-]
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
teekert 1 days ago [-]
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.
gatio 1 days ago [-]
> 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)
anamexis 18 hours ago [-]
There's no home wifi router for an address assigned by the cell carrier.
mittensc 1 days ago [-]
> 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
c0balt 1 days ago [-]
For android, the answer is yes (without rooting being required).
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.
kijin 1 days ago [-]
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.
16 hours ago [-]
eru 1 days ago [-]
> 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.
grumbel 17 hours ago [-]
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.
vel0city 23 hours ago [-]
> 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.
ninkendo 9 hours ago [-]
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.)
Plasmoid 12 hours ago [-]
It's already won. Over 50% of Internet users are on ipv6.
Well, any 3G or later mobile backbone is SIP+SCTP over IPv6. So in many ways it won already
hdgvhicv 1 days ago [-]
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.
lstodd 19 hours ago [-]
What your phone shows to app land is entirely different thing. I'm talking about the backbone.
eru 1 days ago [-]
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!
api 16 hours ago [-]
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.
exabrial 18 hours ago [-]
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".
Hizonner 18 hours ago [-]
... and NAT was a big part of giving them the market power they now use to enforce that.
exabrial 10 hours ago [-]
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.
1 days ago [-]
g023 1 days ago [-]
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.
wmf 18 hours ago [-]
Can't every chat app do this now, including SMS/MMS?
tptacek 11 hours ago [-]
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.
14 hours ago [-]
mintflow 11 hours ago [-]
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
RiverCrochet 11 hours ago [-]
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.
xvilka 11 hours ago [-]
One option to resolve current worrying trends is to invest in development of alternative network protocols/structure, Yggdrasil[1][2], for example.
May be due to US DoD holding large amounts of IPv4 for no reason
1 days ago [-]
thomastjeffery 16 hours ago [-]
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.
kazen44 16 hours ago [-]
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.
__MatrixMan__ 16 hours ago [-]
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.
Pesthuf 1 days ago [-]
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.
dboreham 1 days ago [-]
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.
sundancegh 12 hours ago [-]
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.
Sha1rholder 1 days ago [-]
Time to set up IPV6.
TZubiri 1 days ago [-]
Or just use an ipv4 address. It works I swear
Sha1rholder 1 days ago [-]
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.
hdgvhicv 1 days ago [-]
IPv4 costs are tiny compared to the cost of providing an internet connection.
Sha1rholder 1 days ago [-]
Not every place is the same.
TZubiri 22 hours ago [-]
Do you have any example where leasing an ipv4 block from a NIC directly costs more than 5$ per IPv4 address per year?
litoE 19 hours ago [-]
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.
TZubiri 18 hours ago [-]
> 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)
Sha1rholder 16 hours ago [-]
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.
TZubiri 13 hours ago [-]
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.
Hizonner 18 hours ago [-]
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.
TZubiri 18 hours ago [-]
>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.
Dylan16807 16 hours ago [-]
It's free money to your ISP. A lot of ISPs us CGNAT.
kazen44 16 hours ago [-]
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.
cm2187 17 hours ago [-]
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.
talideon 16 hours ago [-]
NATs are not firewalls. Any firewall-like functionality provided by NAT is entirely accidental and better provides by an actual NAT.
icedchai 15 hours ago [-]
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.
talideon 4 hours ago [-]
s/actual NAT/actual firewall/
icedchai 16 hours ago [-]
Windows wasn't secure enough.
I ran Linux, *BSD, and Solaris systems for years without any firewalls, host or otherwise.
crote 15 hours ago [-]
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.
rugby_poppeye 1 days ago [-]
NAT made distinction between PCs and servers too broad.
10 hours ago [-]
dboreham 1 days ago [-]
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.
Hizonner 1 days ago [-]
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.
Uptrenda 1 days ago [-]
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.
tsimionescu 17 hours ago [-]
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.
api 16 hours ago [-]
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.
unethical_ban 16 hours ago [-]
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.
tptacek 11 hours ago [-]
In other words, the reason NAT is seen as security is that it provides security (imperfectly, like almost everything else).
> 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.
wmf 1 days ago [-]
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.
TZubiri 1 days ago [-]
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.
CrimsonCape 17 hours ago [-]
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.
TZubiri 12 hours ago [-]
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.
jamiek88 12 hours ago [-]
This sounds great! Deffo gonna investigate this!
parasyte 18 hours ago [-]
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.
TZubiri 18 hours ago [-]
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.
wmf 18 hours ago [-]
I don't think any of us could know how most users use it.
rcxdude 1 days ago [-]
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)
TZubiri 17 hours ago [-]
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.
tsimionescu 17 hours ago [-]
> 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.
TZubiri 13 hours ago [-]
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)
tsimionescu 11 hours ago [-]
> 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.
Dylan16807 16 hours ago [-]
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.
jochem9 1 days ago [-]
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.
TZubiri 1 days ago [-]
>"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
Dylan16807 16 hours ago [-]
> 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.
vbezhenar 1 days ago [-]
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.
sedivy94 1 days ago [-]
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.
tsimionescu 17 hours ago [-]
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.
1718627440 1 days ago [-]
> 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.
9x39 17 hours ago [-]
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/
kazen44 16 hours ago [-]
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.
sedivy94 8 hours ago [-]
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.
platesmead 1 days ago [-]
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.
Almondsetat 1 days ago [-]
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
titularcomment 1 days ago [-]
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.
9x39 17 hours ago [-]
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.
mr8031 1 days ago [-]
ipv6 is a window for every buttock. I don't see this as a good thing.
I implemented the current NAT system in Linux. In particular, avoiding port reservation in favor of squishing more connections into one IP address, as long as the remote address allowed us to differentiate.
This, in turn, means incoming traffic from a different address is unroutable. You no longer have a public endpoint. This is "poor man's firewall", but erodes our ability to have a server the way we used to.
I was a young engineer solving a specific problem, without considering the larger picture. It wasn't the only thing, but I feel it definitely moved the internet to a client/server infrastructure and a key equality was lost.
IPv4 without NAT was fucked at the design stage. To be fair: Who knew?
I was asked by my employer a while back to investigate this new www thing that has hit the internet (in around 1994 or 5, it took a while to notice) and I said it was a bit crap and no better than WAIS and GOPHER. I was using telnet on a Windows 3.1 PC and telnetting madly via a VAX and a X.25 PAD and what I now know was close to magic!
No one had any idea how things would turn out back then.
I'm actually quite impressed how long IPv4 has managed to work and without NAT (which I do mildly despise, given 30 years messing with this stuff), it would be stuffed.
Thank you for your work.
I had a corporate internship in the late 1990s and they blocked external web access.
They did, however, allow external Telnet access. This meant that whenever I had free time and/or was waiting for new projects, I would telnet back to my college server and use lynx to go read my favorite websites.
The Internet Protocol only concerns itself with IP addresses. The idea is that each computer has an IP address, so computers can communicate by sending IP packets; each IP packet says, "Message from computer with IP address X to computer with IP address Y".
But computers have multiple processes, so there's a need to know which process at the receiving computer is the recipient and which process on the sending computer is the sender. This is why transport protocols (TCP and UDP) add a port field. A port uniquely identifies a particular socket opened by a particular process on a computer. So a TCP or UDP message sent via the Internet Protocol contains the information, "From the socket with port 41590 on the computer with IP address X, to the socket with port 443 on the computer with IP address Y".
NAT is a giant hack which is primarily implemented in routers. It makes a whole household (or office building, or university campus) look to the outside world like one big computer with one IP address.
Say we have a computer with IP address L, a router with public IP address X, and a public server with IP address Y. The computer will send a message to the router which says, "From port 41590 @ L, to port 443 @ Y". The router will invent a new random port number (say 41200), add an entry to its NAT table which says "port 41200 means port 41590 @ L", then send a message to the public Internet: "From port 41200 @ X to port 443 @ Y".
When someone then sends back a message "to port 41200 @ X", the router looks that up in its NAT table and rewrites the packet to say "to port 41590 @ L", then sends it to the computer with that local IP address.
The computer doesn't really know that it's speaking through a router. It needs to know that "packets to the public Internet should be sent via the router" but that's it, the packets it sends and receives looks the same as if the router wasn't there. The rest of the world doesn't know that it's speaking to the computer behind the router; from their perspective, it looks like they're just speaking directly to the router. All the special network address translation logic lives only within the router.
Already back then, you couldn't easily deploy solutions which required all computers and middle-boxes on the Internet to change. That's why NAT exists in the first place.
You could deploy a new NAT implementation, but the problem NAT solves is fundamentally that there aren't enough IPv4 addresses for every computer to have an IPv4 address so you need multiple computers to share. I don't think there's a better solution to that problem other than switching everything over to IPv6 (which has been in progress for the past 30 years and has barely reached 50%).
As an aside, you see the term "CGNAT" sometimes as well. This stands for Carrier-Grade NAT and is an evolution of the NAT concept to much bigger contexts; a whole city could share a handful of public IP addresses, making large regions effectively one "local network" behind a "router". Multiple streets could look to the outside world like they're just one gigantic computer. Each household in that area will then probably do its own layer of NAT, making it look to the CGNAT router like the household is one big one computer. This configuration can be called "double NAT". Since each router doing NAT only needs to know about its own NAT, there's really no limit to how deeply you can nest it.
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.
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.
This is such a common and stupid problem. It's the same with SSH; if you want to run your own git host, you need to either reserve public port 22 to git, or use it on a non-default port.
More protocols should have some kind of header to tell the server what name was used to connect, just like HTTP's Host header. If SSH clients told the server, "hey I connected via git.example.org", you could have an SSH proxy behind the NAT forward that connection to your git host. If the Minecraft client told the server, "hey I connected via survival.example.org" or "hey I connected via creative.example.org", you could have a Minecraft proxy server route the traffic to the right local address/port.
(I'm actually implementing multiplayer in a game right now and I'm adding this information to the initial connection handshake message, with the intention that you could make a proxy server.)
All practical solutions for p2p these days require NAT hole punching through STUN and signaling servers anyway, so even p2p has to be bootstrapped via client/server. Easier to just keep the protocol client/server then.
FWIW I (writer of blog post) am 21 years old and just a bitch lol
Also, the lazy sysadmin forgot to set a quote for today.
The thing about smartphones is that they are both completely dependent on wireless connections to central servers in order to function and completely unsuitable to operate as servers. If you forced your phone to serve files anyway, your battery would drain quickly and the CPU would be drowning in its own waste heat. You might argue that you could still do non-server things on the phone, but practically speaking, a node that can't handle server tasks is just a leech. P2P networks work on a mutual aid basis; they require the majority of nodes be capable of shouldering traffic or sharing files in order to be a net benefit. If you add, say, tens of millions of new mobile phones to the network, the network will become unusable as any desktop machine gets DDoSed by hordes of phones asking for a babysitter.
So even in the world where IPv6 did to v4 what v4 did to NCP, we'd still ultimately end up with "my files go in the cloud", because clouds are coinventions of smartphones, in the same way that cars are coinventions of suburbs. You can't have one without the other, and once you do have both, they become so economically dominant that others get socially coerced into using them.
Obviously it's all very basic, but with a few years of development and polish (and probably someone besides Nokia copying the idea) I think this would be a compelling product. You could basically have the same feature set as something like iCloud but without the subscription or your files going elsewhere.
This works, until you have more than one person accessing your server. Then you need to worry about accounts, credentials, data isolation, etc. And then if a couple of people connect to your server and start using it, you have to worry about staying online, staying updated, backing up the data. But other than that... yes, trivial.
And just to be really explicit, you always have more than one person accessing your server, and most of the time they are unwanted users trying to break in.
Exactly. Of all the reasons why the average person doesn't have an Internet-visible server, NAT, I would say, is pretty far down on the list.
In fact you could have an IPv6 address for each user, and if one starts becoming troublesome both revoke account and stop using that address.
You could create a new IPv6 address every millisecond, and it'd take 584,868,233 years to exhaust a IPv6 subnet (/64).
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.
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. :)
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.
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
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.
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.
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.
You can have a stateful firewall that blocks non-established-connection packs and all your publicly addressable devices would not be reachable. NAT ≠ firewall (though they often glommed together on CPEs).
And NAT is also giving a false sense of security in some ways: "this device has an RFC 1918 address so is not reachable, and therefore safe". Yeah, except if another device already on the inside is / gets compromised. Perhaps if everything had a public address folks would be more circumspect.
Right, but it's easy to get in the mindset that because devices are on the "inside" network they are safer. This is the risk that NAT brings: RFC 1918 = safe(r).
If every device has a 200::/3 address, then even if there's a SPI firewall which prevents external connections, it may help to reduce this inside/outside thinking.
I doubt it.
Very few devices do port NAT without also doing firewalling, since firewalling is simpler.
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.
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.
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.
I sent them a screenshot of her shared drive through ICQ, and not long after she bought a router.
Software was created with no security because no one demanded it because no one cared. Technologies that came later did not create that situation.
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.
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.
I know of zero systems that can survive exposure to the raw Internet, unpatched and without administrative oversight, with uptimes of years.
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.
IPv6 just works. DNS gives me the address and that's it, I am now talking to my remote computer.
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.
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.
This is a very common misunderstanding. NAT and firewalls are separate concepts. You can also have NAT with no meaningful firewall -- a port remapping NAT that allows anything through.
Most IPv6 networks are firewalled but there's no NAT.
You 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
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)
That's mostly because a phone is very locked down, can you run an accessible ftp server on your phone?
It's also not windows
If you want to use the standard port, that's only true as of very recently, though, see https://issuetracker.google.com/issues/218578943#comment17
I would invest in a proper firewall for the entire home before opening up anything to the world, IPv6 or not.
I'll believe it when I see it. So far it doesn't look like IPv6 will win anytime soon.
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 don't see a reason why my machine addresses should change over time... then again, most shouldn't have direct internet access anyway, a http proxy on firewall should be enough.
You can still use fixed addresses locally if you want, its not like IPv6 is forcing you to use the prefix assigned if you just want to communicate locally over never-changing addresses.
You can have your computers be fd01::1, fd01::2, fd01::3, etc, and talk to everything on their local addresses when wanting to stay local. And then when they want to talk on the public internet they can just use whatever public addresses like 2600:1700:53c2:2573:4c:c001:dead:beef based on whatever prefix your ISP gives you.
Its not like your devices have to only have a single IP address.
(I don’t personally run my network as ULA-only, I do ULA+GUA as you describe, but I had to basically give up on being able to reliably tie traffic logs to a known source… hosts in my LAN always seem to use a GUA to talk to each other when discovering over mDNS, which of course means they use privacy addresses by default. My ULA uses DHCP so that I can get stable addresses and know who is who, but it’s useless when things just decide to use the GUA anyway.)
In the US, it’s currently over 60%: <https://stats.labs.apnic.net/ipv6/US>
At home it can be if I connect t to my ip6 ssid, but there’s a stateful firewall which may as well nat.
Well, good to know!
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.
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".
We have dozen of RFCs and vendors gears support IPv6 as well, but it just not finished
[1] https://yggdrasil-network.github.io/
[2] https://github.com/yggdrasil-network/yggdrasil-go
May be due to US DoD holding large amounts of IPv4 for no reason
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.
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.
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.
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.
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)
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.
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.
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.
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.
1) The typical "NAT" is a "PAT", which requires state for mapping traffic flow. An implementation is going to look very similar to a stateful firewall, by necessity, not accident.
2) The use of RFC-1918 addresses behind the router / NAT box provides some protection. If your address is not globally reachable, it's much harder to reach any hosts behind it. Yes, a poor implementation might allow direct routing from adjacent networks, like your ISP or neighbor. But that still isolates you from 99.99% of the internet.
I ran Linux, *BSD, and Solaris systems for years without any firewalls, host or otherwise.
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.
If I wanted to blame large corporate "users" for NAT (which I actually do), I would blame their obnoxious intransigent refusal to upgrade to IPv6. That part wasn't the ISPs' idea, but it had nothing to do with the cost of address space and everything to do with shortighted laziness. They were, in fact, willing to pay for IPv4 space to avoid having to do anything.
The idea of router sounds simple and like it should implement some standard protocols. But in practice -- a lot of it is a mishmash of proprietary, ad hoc shitware. Something I never hear spoken about is the deep packet inspection filter component of the router firmware. It's a part of the router that decides on what traffic is allowed / not, and almost no company publishes this part. So you're not even in control of your own Internet traffic, tiny blobs of code written by some company get to decide if something is allowed or not.
If that sounds sus AF and kind of a bad idea -- well, it is. You can always run 100% open software with open-wrt. But the thing is -- the Internet isn't just your part of it. It's a network of networks, and all those shitty routers, with all that shitty firmware, is deeply ingrained within the entire Internet. That's millions of devices that would need to be replaced to fix the issue.
I've never heard of a claim like this, so I'm really curious. Note that I'm not talking about the huge DPI market for corporate/state networks.
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.
The reason NAT is seen as security on home networks is that, absent a firewall, it acts as a default deny to inbound traffic.
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 use it in 3 ways:
1. My phone connects to my home network by joining the tailnet. I can play music and movies from my home server when I am away. No struggles with configuration. 2. A dedicated mini pc at home is on a smart plug. I keep it powered off mostly. I can turn the plug on remotely and power the mini pc. It runs "tailscale --advertise-routes" which then exposes every device at my house to the tailnet. No open ports, but suddenly my phone thinks that it is back at home with all my home PCs. 3. I take my laptop with me and use "tailscale serve" which serves as a pipe. I can pipe my home movies to a smart TV at your house. Just install the jellyfin app, and browse for servers, and my server in my house appears in the list at your house.
Still not my cup of tea, but I think that the threshold of acceptable hacks is much higher for personal usage, there's no right or wrong, because it's as much a useful project as it is one of exploration and expression.
Thanks for sharing.
the first lets me provide locally hosted services without exposing them to the internet, by allowing members of the VPN ("tailnet" in their parlance) to connect to those services
the second was very handy to move a few users from a company in the process of shutting down to their homes, so they could continue to work like they had in the company network once the actual internal company network was shut down.
The other common but completely distinct usecase of VPNs being residential usage to encrypt traffic and even more distinct, with the purpose of masking the true origin of a request.
In the former type of usage, which is the one you use, I think any VPN system would fulfill your purposes, of course you have to use something, but I'd venture a guess that you are using the generic features of tailscale, not its commercially distinguishing features. But they are still very on brand, generic or not.
fwiw, the author/founder seems to have made a career out of building post-hoc hacks in one layer to fix the shortcoming of other layers, to take memcached as an example. I don't think my thesis is novel, that these types of hacks are subpar when compared to solving the issue at the appropriate layer, it's part of the tradeoff of the technologies, but I'm just particulary opposed to any hack that allows server admins to skip the step where they get a dedicated IP address, I'm less opposed (but still) to other types of hacks.
The main selling point is acting as a relatively efficient private overlay network, giving you a consistent private network even as devices move between different internet connections. (Something that NAT makes a bit harder but you don't get for free even if NAT isn't a factor)
But if I see a user that exposes a server without a dedicated IP address, and they use tailscale for this, the way I would describe it is that they are adding a third party node that routes traffic for them (just to provide multiplexing), so in terms of security, it's an additional unnecessary man in the middle. It's a testament to the marketing team that they are able to sell it as 'added security'. It's hard to know exactly how such open infra technologies are used, but I get the feeling that a good part of the customer base is buying tailscale to patch up a bad infra decision, while being (self) deluded into thinking that their system is very bleeding edge and secure.
Props to tailscale actually, lots to learn here, the lesson is to let the client save face and sell your tech not as something that fixes an embarassing mistake, but as something that's a bit opaque, high tech and implements security protocols, even if performatively.
Bonus points if there is upsell or onramp into actually sound technologies, like eventually you have to drop the whole tailscale thing and help the client actually get an IP address right? Or maybe even onboard the rogue ddnsed service onto the organization's existing ASN. It's a hard sell because the best solution in that case actually removes the product from the organization altogether, but I can imagine ways were the product stays in a non-central, QA-like sidechannel.
If you are listening on a public IP, you can trivially be attacked by anyone on the Internet.
If you listen on a private IP that only Tailscale can reach directly, you can only be attacked by Tailscale itself, or by anyone who successfully infiltrated Tailscale's network.
Should you run plaintext protocols over Tailscale? Absolutely not. But you're going to receive orders of magnitude less malicious traffic on a server accessible only over Tailscale compared to a server listening on the public Internet.
If you make your tailscale available to the internet through tailscale, you are still weak to external attackers, putting a VPN in the middle doesn't fundamentally change that dynamic, maybe it shifts it around and it confuses you enough to feel less shifty about it.
But it doesn't decrease your risk, if your HTTP server is weak to a tailscalething.tld/../../etc/ attack, it doesn't really matter that requests to other ports are blocked, (which probably don't even have processes listening anyways)
Not if it's a private server, like the poster above was describing. For example, if I want to maintain a NAS to store my photos and view them anytime, I am better off running it on a Tailscale network that only I (and some friends/family) can acces, no reason to expose it publicly and then try to secure it.
It just works: connect devices and they immediately show up in their portal. Most config is just clicking, but more advanced things can be configured as well. Definitely feels like a high quality product, not just something thrown together by a developer that learned a few network techniques.
Huh. Why are you doing this, is the datacenter IP being (rightfully) blocked by some service to avoid abuse? Is your usecase breaking some services ToS?
Certainly adding more fire to the "never a GOOD reason to use this" thesis
So you make up reasons to be judgemental and then insist they're right?
It's practical to block entire datacenters. It's not so "right" that working around it becomes "wrong". If whatever the server's doing can fit through a single home connection then it's probably fine.
I'll give you a concrete use case: A few times a month I want to wget a file on imgur to my server. That's a valid action miles away from any kind of abuse, but the IP range is blocked so I use my desktop to do it. If I routed it over tailscale instead that would be equally valid.
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.
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.
If it weren't you couldn't have the same IP over several interfaces.
>mere fact that Layer 2 and Layer 3 addresses are distinct concepts.
The logical separation between the ideas allows for a lot of flexibility, and there were some wrong answers on how scalable vs flexible things should be.
Ethernet and IP beat the shit out of everything else: https://en.wikipedia.org/wiki/Protocol_Wars
They emerged with a decent answer: L2 crosses intranetwork, L3 crosses internetwork. Their separation allows L3 addressing to be completely unaware of multiple changing L2 (lower level) intranetwork switches, which is immensely useful.
Trying to solve everything with One Master Protocol to solve it all turned out like this: https://xkcd.com/927/
IPv6 solves this by doing neighbour discovery on link local addresses and multicast addresses.
I took a course called “Introduction to Internet Architecture” back in 2017 with a wonderful professor. The course opened with a prompt, “What is communication?” We started with smoke signals and worked our way up the OSI layers (including voltage-level encodings on the wire). I remember drawing those layers and asking, “What problem is each layer trying to solve?”
Also that XKCD comic is a classic. Love it. I don’t see any value in overhauling the protocols of today. It seems like the future (or present) of networking is overlays. When this recent cert covered SDN, it really abstracted away everything I had just learned and I felt a little sad about it honestly - as if switch/router configuration would some day be ubiquitously software-defined, getting totally buried by the application layer and becoming almost apocryphal like assembly or machine code… something we know exists but rarely touch.
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.
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.