The eternal problem with companies like Tailscale (and Cloudflare, Google, etc. etc.) is that, by solving a problem with the modern internet which the internet should have been designed to solve by itself, like simple end-to-end secure connectivity, Tailscale becomes incentivized to keep the problem. What the internet would need is something like IPv6 with automatic encryption via IPsec, with PKI provided by DNSSEC. But Tailscale has every incentive to prevent such things to be widely and compatibly implemented, because it would destroy their business. Their whole business depends on the problem persisting.
This sounds like a reasonable point, but the more I think about it, the more it sounds like digital flagellation.
IPv6 was released in 1998. It had been 21 (!) years since the release of IPv6 and still what you're describing had not been implemented when Tailscale was released in 2019. Who was stopping anyone from doing it then, and who is stopping anyone from doing it now?
It's easy to paint companies as bad actors, especially since they often are, but Google, Cloudflare and Tailscale all became what they are for a reason: they solved a real problem, so people gave them money, or whatever is money-equivalent, like personal data.
If your argument is inverted, it's a kind of inverse accelerationism (decelerationism?) whereby only in making the Internet worse for everyone, the really good solutions can see the light. I don't buy it.
Tailscale is not the reason we're not seeing what you're describing, the immense work involved in creating it is why, and it's only when that immense amount of work becomes slightly less immense that any solution at all emerges. Tailscale for example would probably not exist if they had to invent Wireguard, and the fact that Tailscale now exists has led to Headscale existing, creating yet another springboard in a line of springboards to create "something" like what you describe -- for those willing to put in the time.
It is a problem when, for instance, Google chooses not to implement SRV (and later HTTPS) DNS record support in their web browser. The problems which SRV (and now HTTPS) DNS records solves is not a problem for Google, since they solved the problem by sheer scale and brute force, and Google only benefits from everybody else still having the problem; it’s a great moat for them.
> Who was stopping anyone from doing it then, and who is stopping anyone from doing it now?
The folks who either (a) got in early on the IPv4 address land rush (especially the Western developed countries), or (b) with buckets of money who buy addresses.
If you're India, there probably weren't enough IPv4 address in the first place to handle your population, so you're doing IPv6:
Or even if you're in the West, if you're poor (a community Native American ISP):
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
IPv4 'wasn't a problem' because the megacorps who generally run things where I'm guessing you're from (the West) were able to solve it in other means… until they can't. T-Mobile US has 120M and a few years ago it turns out that money couldn't solve IPv4-only anymore so they went to IPv6:
IPv6 is not taking off because IPv4 (and NAT/STUN/TURN) is 'better', but rather because (a) inertial, and (b) it 'works' (with enough kludges thrown at it).
No, we definitely don't want "automatic IPSec" (especially IPSec!), or really any enforced encryption at the network level, even if it's something sane at this moment like WireGuard. Look at old VPN protocols or authentication schemes like RADIUS which have glaring security holes and are impossible to fix because of compatibility issues, and they're running at much smaller scales than the whole internet. Hell, the way the industry is solving TCP ossification problems is by throwing TCP away and reimplementing it on top of UDP, that should tell us something.
And, worse, incentivized to require users to use a "coordination server" which helps with the NAT and firewall traversal problem by being something you can reach from outbound-only clients. There's a lot of verbiage there, but the general idea seems to be that Tailscale sits at the middle of this as the means by which machines find each other.
There are other ways to do that.
There are dynamic DNS schemes, so you can give your machine which only has a temporary IP address a permanent name. That's been around for decades, and seems to have a bad reputation.
There are schemes with multiple coordination nodes that know about each other, and published lists of such nodes. The list may be out of date, but as long as the published list has one live node, you can connect and get updated. That's how Kademlia, which underlies Etherium's network and some file sharing systems, works. That's about 20 years old, and sort of has a sketchy reputation.
It's possible to go only halfway, and separate discovery from transmission. Peertube does that. You find a file to stream via ordinary HTTP to a server you find by ordinary web search means. Anybody can set up such a server. The actual streaming, for files wanted by many clients, is distributed, with people currently watching also sending out blocks to other people watching. This scales well, in case your video goes viral. It's not used much, though.
So it's definitely possible to do this without someone in the middle able to cut off your air supply.
Zerotier does kind of that. It's a tunnel, but also the traffic is direct (unless double Nat is involved) and if you could route the traffic directly to the endpoint IPs, you can skip zt. The location service can be self-hosted if you want. You don't have to use them as a service if you don't want to. Apart from dnssec it's pretty much what you're asking for.
foreseeable yet still somewhat surprising that having a clean v4 address on the cpe has become a very privileged position.
just the other day i was discouraging a youngster from manually populating his hosts-file in order to circumvent a dmca-related dns block.... what has the world come to.
What kind of Nat though? You can use upnp, predictable mapping, etc. and still allow the traffic through. And that's only with ipv4, because you can run zerotier over IPv6.
> What kind of Nat though? You can use upnp, predictable mapping, etc. and still allow the traffic through.
Your computer can talk to your home router (CPE) and punch a hole for a connection, but if your WAN port does not have a public IP address, but rather itself also has a private address (probably 100.64/10), the CPE cannot talk to the ISP's router to punch a hole:
Double Nat on one side is not that universal. Across Europe and Australia I've seen it maybe once on a residential connection. I'm sure it's used, but the comment about the US in the post above just doesn't match my experience.
Look at how the early 90s Ford Tempo resale value compared to Toyotas of the era. Trash cars don't keep their value. Toyota could then charge a premium because they were known for quality.
Resale values do have an impact on new car prices. The better a vehicle holds its value the easier it is for the company to charge more for a new car.
Its also worth considering that, for better or worse, very few people actually own their cars today. When you have a loan on it the resale value becomes really important. If the manufacturer wants the kind of customer that buys a new car every few years they'll need resale value that at least keeps up with the principle on the loan over that time.
> is resale value what the manufacturer wants? I mean they want to sell new cars after all...
They have a higher resale value because they have a reputation of lasting a long time, and people are thus perhaps more willing to pay a higher initial purchase price because they know their "investment" will last longer.
And while they may not be planing to sell their car after only a few years, knowing that they'll get back more of their "investment" is also probably sitting in the back of their mind ('just in case').
I never thought of this. Forces me to rethink every negative post people made against DNSSEC which shaped my opinion. I still think that IPv6 and DNSSEC do more harm in practice than what they solve. Maybe the SCW podcast can do a deepdive on this together with somebody who is militantly-pro DNSSEC. <3 ...
edit: maybe even invite 2 or 3 DNSSEC advocates @tptacek :)
It is a problem if a company makes a lot of money ”solving” the problem, but:
• This does not really solve the problem, since a real solution would be to change the internet to make the problem go away
• A company making a lot of money gets to have an enormous influence on what is considered reasonable to standardize on. See for instance Google’s and Microsoft’s influence on things like the W3C.
I think that is excessively negative take. Tailscales value proposition is also "you can connect to your network wherever you are, safely, and others cannot". That does not go away because of IPsec.
Network- and location-based security is ultimately unworkable. It’s like if you, in order to work, had to go to a ”virtual office” to even send mail to your colleagues. Mail, and related internet-enabled services, should be accessible from anywhere, and be secured at the end points, not at the network layer. (Most attacks are internal, anyway.)
An incredibly long ramp up to complaining about centralised control by rent seekers (a very reasonable complaint!) which gets bogged down in some ostensibly unrelated shade about whether client-server computing makes sense (it does) or is itself somehow responsible for the rent seeking (it isn't; you can seek rent on proprietary peer to peer systems as well!) to then arrive at:
> There’s going to be a new world of haves and have-nots. Where in 1970 you had or didn’t have a mainframe, and in 1995 you had or didn’t have the Internet, and today you have or don’t have a TLS cert, tomorrow you’ll have or not have Tailscale. And if you don’t, you won’t be able to run apps that only work in a post-Tailscale world.
"...you can rent seek on proprietary peer to peer systems as well..."
I still use a non-proprietary one that predates Tailscale and that is not OpenVPN. It is small and simple enough even I, a non-programmer, can make modifications.
It's possible one ends up using client-server in order to achieve peer-to-peer because not everyone has an internet-reachable, non-firewalled IP address. Using some hosting company's server to run a "supernode" may be required. No traffic needs to pass through it if it is used only as a "rendezvous server" so the cost can be minimal.
Companies that try to compete with "free" always draw high scrutiny from me. Stop using that free software and start paying us. We added 100 unnecessary "features".
Not doubting this "corporate strategy" can succeed, at least short-term. Look at Slack. But these subscriptions are not for me.
Client-server versus peer-to-peer is misdirection. The real issue is proprietary versus non-proprietary. IMHO.
Not sure if parent means wireguard, but my GitHub page has a way to get around cgnat using wireguard for use with a Nintendo switch (or any wifi/etc device that doesn't run an editable OS)
re: GP comment. It really does not matter which non-properietary solution one chooses. It is personal preference. I know what I like but others might not like it. There are many options to choose from. And (I hope) there will continue to be more.
Lol. The tailscale CEO is preaching “tomorrow you’ll have or not have Tailscale. And if you don’t, you won’t be able to run apps that only work in a post-Tailscale world.”??
That won’t go down well in 10 years if they don’t become Microsoft-scale juggernauts.
You can use tailscale without using tailscale hosted components, using purely open source parts.
I have switched where possible, both my own networks and clients, to use headscale which is folly open source coordination server compatible with tailscale.
I'm one of the people who actually use Tailscale for production systems where there are servers physically close to me, or at some other controlled locations, and then there are hundreds of users hundreds kilometers away, all working via Tailscale.
I should say two things. Tailscale is amazing and I love it. The system could not exist without it, or I'd have to have at least ten more people in my team to manage all this 24/7. It's working, and it's good enough.
That being said, you do need to lower your expectations: it's not as good as "the internet". The latency spikes periodically, the connection drops sometimes, the MagicDNS just magically stops working or interferes with the system. Since we have many users, we've encountered every possible problem one can encounter, and then there's still something new you'll see tomorrow.
In any case, we believe in Tailscale and its vision, it's a categorically new approach that simultaneously gives you the control on hardware, reduces the cost, and improves the security. Our first big production server was a 4-core Linux Laptop!
We love Tailscale and we wish the product prosperous life and development. Thank you TEAM TAILSCALE!
Would you mind going into more detail about the 4-core Linux Laptop as a production server via Tailscale, please? I too use Tailscale and love it for self-hosting internal stuff but I never thought about using it for public facing production stuff. Now I'm really curious to hear more about your setup (if you're willing to share of course).
I love Tailscale, but this post gives me the creeps. The internet succeeded because it was built on standards and was completely free. With Tailscale, I get wireguard is open source and we have things like Headscale. But the whole everyone gets an IP, doesn’t it depend on Tailscale owning a massive ip address space? We can all wait until full ipv6 rollout, or we can depend on centralized ipv4, and servers and proprietary stuff. Maybe a bit hypocritical?
You can self-host a Tailscale control sever with Headscale[1]. It's not quite at feature parity with Tailscale, but it supports most if not all the current feature set and its improving every day.
One of the lead devs is even paid by Tailscale to work on it, IIRC.
I run it for my personal self-hosted infra, and it works really well. Setting a custom control server URL is relatively easy (at least on Windows and Android which I use).
I use taildrop, I serve docker containers to the tailnet, etc. headscale works really well and is worth a go.
The question is: how long will Headscale be supported in the official clients - how long will the incentives of Tailscale's VC's align with the freeloaders?
The official clients (most valuable: the polished mobile apps easily installed from the default app stores) are one auto-update away from cutting ties when push comes to shove, the same as all commercial VPNs with a free tier.
The clients are the open source part of Tailscale. They can be forked and built by someone else if required.
However I do not think Tailscale is going to remove the custom control URL feature from their mobile clients. For one, I think there are legitimate "Tailscale Enterprise" use-cases for the custom login server.
Additionally, I have heard that Tailscale has been supportive of the Headscale project, providing assistance to the devs.
Further, Tailscale seems fairly committed to keeping their clients open sourced, and engaging in the developer community. Of course as you can say this can change at any time.
>But the whole everyone gets an IP, doesn’t it depend on Tailscale owning a massive ip address space?
No, because Tailscale isn't "the Internet", it is a bunch of disconnected moats. The IP space needed by Tailscale only has to be as big as the largest moat. And you can only be connected to a single moat at a time.
> Can anyone elighten me regarding what is different or special about 100.64.0.0/10 vs say, 192.168.0.0 or 10.0.0.0.
A bit of context: if an ISP cannot get enough IPv4 addresses for the WAN-side of people's home routers, some problems exist:
* something in 192.168/16 is generally used for the LAN-side of people's home routers, so that cannot be used on the WAN side
* 10/8 is used for business/enterprise corporate networks, so it also cannot be used on the WAN side because if people VPN connect to the corporate, then the router may get confused
* similarly for 172.12/12: often used for corporate networks
So the IETF/IANA set aside 100.64.0.0/10 as it had no 'legacy' of use anywhere else, and is specifically called out to only be used for ISPs for CG-NAT purposes. This way its routing does not clash with any other use (home or corporate/business).
IPv4 address space is nearly exhausted. However, ISPs must continue
to support IPv4 growth until IPv6 is fully deployed. To that end,
many ISPs will deploy a Carrier-Grade NAT (CGN) device, such as that
described in [RFC6264]. Because CGNs are used on networks where
public address space is expected, and currently available private
address space causes operational issues when used in this context,
ISPs require a new IPv4 /10 address block. This address block will
be called the "Shared Address Space" and will be used to number the
interfaces that connect CGN devices to Customer Premises Equipment (CPE).
And that actually was a problem at a previous job I was at: when COVID hit our VPN address range just happened to be set to be in that range, and so a bunch of developers were having issues. (IIRC, we re-configured the VPN appliance to use something else.)
AFAIK, Zerotier is about equally proprietary, more-free (as in beer), and has been doing the node-to-node mesh thing instead of spoke-and-hub longer than Tailscale has been in existence.
And if I remember correctly, ZT was initially created to provide something like this "New Internet" concept that Tailscale has apparently recently discovered, except they called it "Earth" and abandoned it in 2023.
Kinda? It works great in practice. You can run your own controllers if you want which completely disconnects you from the proprietary service. But the code is BSL.
I didn't mean to suggest it doesn't work well, as I said I've not used it.
It's still proprietary if you self-host it, I was thinking in particular that tailscale uses Wireguard and Zerotier uses something custom, i.e. proprietary. Note that the context was:
> The internet succeeded because it was built on standards and was completely free. With Tailscale, I get wireguard is open source and we have things like Headscale. But [...]
to which the commenter I replied to asked of alternatives. So I wasn't saying tailscale great and open and standards compliant, and Zerotier not; I was saying it's the obvious competitor but if that's your problem with tailscale then it's if anything worse in that regard.
I use Nebula because its iOS client does not drain my battery. Tailscale has had that known bug for years and they never managed to fix it, which is a major deal breaker.
I like Tailscale, but this reads as too self-aggrandizing.
You have a mesh VPN product with some value-added services on top of it. That's great, but this idea isn't novel or unique. Why should your solution be the "new internet" instead of any of the alternatives?
I wouldn't want to rely on a single company for all my internet infrastructure, anyway. So I'll stick with the traditional internet with all its complexity. Its major problems aren't technical but social, and no new technology will solve those.
> Its major problems aren't technical but social, and no new technology will solve those.
Really? Isn't the major problem of the current internet is inherent centralization of services because the initial promise of 100% decentralized network is simply too complex to realistically manage? I view that problem as deeply technical. Unless if by "social" you simply mean everyone should become an experienced sysadmin. (or the slight variation of, everyone should know an experienced sysadmin who's willing to run their application for them for free)
Take something as mainstream as social media. Imagine a world where Facebook/Twitter/TikTok/YouTube/Reddit/HN/etc worked (seamlessly) like bittorrent. An application on your machine when you run it, it joins a "Facebook" network where your friends see you online through their instance of the application. Your feed/wall/etc is served to them directly from your machine. All your communication with them is handled directly between the 2 (or 1000 or millions) of you. No centralized server needed. You can easily extend and apply this majority of centralized application today. The only ones I can think of where this wouldn't work would be inherently centralized services like banking for example.
There are already plenty of p2p networks that show that this is a viable solution. Bittorrent, soulseek, bitcoin, etc.
All the problems you will run into however to make this as seamless as just connecting to facebook.com are purely technical. The initial big hurdle is seamless p2p connectivity. That is without port forwarding, dynamic dns, and requiring advanced networking, security, and other sysadmin knowledge from every user. Next would be problems like what happens when the node is offline? What happens to latency and load if you need to connect to thousands, hundreds of thousands, or millions of machines just to pull a "feed"? How is caching handled? How are updates/notifications pushed? How do nodes communicate when they are wildly out of date? Where is your data stored? How do you handle discoverability, security, etc.
All deeply technical problems. Most are solvable, but you're gonna have to invest a significant amount of effort to solve them one by one to reach the same brain-dead simple experience as a centralized service. The fediverse has been trying to solve just a small subset of these problems for over a decade now, and the solutions still require a highly capable sysadmin to give users a similar (or only slightly worse) experience than twitter.com.
> Isn't the major problem of the current internet is inherent centralization of services because the initial promise of 100% decentralized network is simply too complex to realistically manage?
Not quite. The internet _is_ decentralized. What made the web so centralized from the start could partially be the result of lacking tools that made publishing as easy as consuming content. I.e. had we had a publishing equivalent to the web browser, perhaps the web landscape would've been different today. You can see that this was planned as phase 2 of the original WWW proposal[2] ("universal authorship"), but it never came to pass AFAIK.
So you could say that the problem is partly technical. But it's uncertain how much this would've changed how people use the web, and if companies would've still stepped in to fill the authorship void, as many did and still do today. Once the web started gaining global traction in the early 90s, that ship had sailed. People learned that they had to use GeoCities to publish content, and later MySpace, Facebook and Twitter. These services gained popularity because they were popular.
There have been many attempts over the years to decentralize the web, but now the problem is largely social. As you say, we've had the fediverse for over a decade now. How is that going? Are technical issues still a hurdle to achieve mass adoption, or are people not joining because of other reasons? I'd say it's the latter.
Most people simply don't care about decentralization. They don't care about privacy, or that some corporation is getting rich off their data. They do care about using a service with interesting content where most of their contacts are. So it's a social and traction issue, much more than a technical one. The only people who use decentralized services today are those who care more about the technology than following the herd. Until you can either get the average web user interested in the technology, or achieve sufficient traction so that people don't care about the technology, decentralized services will remain a niche.
There is another technical aspect to this, though. Even if we could get everyone to use decentralized services today, the internet infrastructure is not ready for it. Most ISPs still offer asymmetrical connections, and residential networks simply aren't built for serving data. Many things will need to change on the operational side before your decentralized dream can become reality. I think this landscape would've also been different had the web started with decentralized principles, but alas, here we are.
> As you say, we've had the fediverse for over a decade now. How is that going?
Convenience trumps everything. All the parts of the iPhone existed for a few years before it -- especially PDAs with touch pens -- but what made the iPhone succeed was putting everything into convenient and easier package.
The amount of time worked on thing X has almost zero correlation with its adoption, as I think all of us the techies know.
> Even if we could get everyone to use decentralized services today, the internet infrastructure is not ready for it. Most ISPs still offer asymmetrical connections, and residential networks simply aren't built for serving data.
While that is true, let's not forget half-solutions like TeamViewer's relay servers, Tailscale / ZeroTier coordinators, and many others. They are not a 100% solution but then again nothing is nowadays; we have to start somewhere. I agree that many ISPs would be very unhappy with a truly decentralized architecture but the market will make them fall in line. I have no sympathy for some local businessmen who figured they will run with tens of millions with $50K investment. Nope, they'll have to invest more or be left out.
So there would be a market reshuffling and I'm very OK with it.
---
But how do we start off the entire process? I'd beet on automated negotiation between nodes + making sure those nodes are installed on much more machines. I envision a Linux kernel module that transparently keeps connections to a small but important subset of this future decentralized network and the rest becomes just API calls that would be almost as simple as the current ones (barring some more retry logic because f.ex. "we couldn't find the peer in one full minute"). I believe many devs would be able to handle it.
precisely. Isn't every business that plus some custom stuff & employee time?
i.e., isn't some business is just a kludge of FOSS heavyweights, say for example, when they write an app in some open source language, deploy it on an open source OS with open source orchestration etc
I think Tailscale is a lot of foss software, with the utility that it lowers the barrier to entry massively
Isn't yggdrasil[1] supposed to be the New Internet?
If not, why Tailscale specifically, and not Netbird, Nebula, Netmaker or some other competitor?
The article is indeed very well written, but gives the wrong vibes, like something's coming: acquisition, pivot, split, shutting down, etc. Also, "we're re just getting started", the famous last words.
Just to balance my healthy mistrust, I'd like to add that I'm a satisfied Tailscale user, mostly impressed with how little it requires of me to just work.
I think the author misdiagnoses the problem, and the proposed solution simply hides the centralization instead of removing it.
The reason AWS is expensive is not because of IPv4, or the datacenters. It's mostly in their software/managed offerings, and the ability to quickly add more servers. If you are a "serious company" and you don't want to pay AWS or a similar company, renting a rack and colocating your own servers (either within your premises or in a datacenter) is doable and done by lots of companies.
I disagree that certificates have caused centralization, and they're not something separating the haves and have-nots and are in no way comparable to having or not a mainframe. HTTPS becoming pseudo-mandatory didn't push people into having their own (sub)domains, which is nowadays the only requirement to obtain a certificate. It already happened out of convenience.
The other point of centralization mentioned is DNS, which tailscale doesn't avoid at all. MagicDNS still relies on the ICANN root, as does the tailscale control plane. And if all you wanted was a free subdomain, there are plenty of people offering that.
If you are behind CGNAT, tailnets aren't particularly less centralized, as traffic has to flow through the DERP servers. I doubt tailscale can keep providing these free of charge when the volume is in the tbps instead of the gbps.
I agree that tailscale (and similar solutions) help in the last remaining case, which is accessing your computer that is behind a NAT. I even think they could reach the dozens of millions of users. This is, in my opinion, not enough to claim the title of "the new internet".
Of course these ideas are not that new. IPv6 was supposed to give end-to-end connectivity to all, and originally IPsec was supposed to be mandatory part of IPv6, giving each internet host cryptographic identity. And so on.
I was curious why the article didn't mention IPv6 at all, since Tailscale does support it.
IPv6 -together with WireGuard- gives privacy, security, and performance. The downside is the complexity to set it up.
Tailscale builds on the shoulder of giants. IPv4, WireGuard, Samy Kamkar NAT punching, OpenSSH, and probably many more. One of the upsides is the combination of these, and that the management interface in general is easy. But what counts for CA is also true for Tailscale: both are using FOSS to in the end deliver a (proprietary) service.
But because almost everything is build on top of FOSS and there's Headscale (and they're cool with it), this isn't a major issue to me. Like, it is a downside, but not a major one, as vendor lock-in is practically non-existent. In fact, it is likely an upside from a business/support PoV.
I think there’s a common misunderstanding that with IPv6 anyone can connect to anyone else. That’s not true.
My laptop has an IPv6 address, as does the router that routes its traffic. There’s no NAT, that’s true, but there’s still a firewall — only inbound packets from a destination host and port that have been sent to are allowed in. And in enterprise environments, from what I’ve seen, there’s a symmetric NAT on IPv6 anyway — packet comes from a different IPv6 address and randomized port than the one client sent it from, making peer connectivity impossible, as the source port varies by destination host and port.
Because IPv6 is mistake. Thats why market does NOT want it. Unfortunately, we all start to feel the heat of IPv4 exhaustion.
Anyway, remember IPv4 classes? Then they made it classless. IPv6 is not 128bit, its just 64bit with 64bit host address. So, first mistake. IPsec mandatory? pure stupidity. Crypto moves fast, every 10 years many protocols are obsoleted. How you will provide E2E connectivity with that?
In 1997 IPv6 was seriously immature yet to start migration. Additionaly, it was very different from IPv4 so was mostly ignored. What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done. As bonus, they should think about some basic IPv6 -> IPv4 interop so clients would NOT need to be dual stack. And that could work back then. Now we are fucked.
The thing that you and all other ipv6 haters miss is that none of that matters. Ipv6 is happening, like it or not. And that had been the state already for 10-15 years.
Maybe in the 00s there was window when there might have been true doubt if ipv6 was going to happen. But after that, it was just question of "when", not "if".
Keeping on hating is simply not very productive. It's just much better to embrace ipv6, no matter it's possible flaws.
> Crypto moves fast, every 10 years many protocols are obsoleted. How you will provide E2E connectivity with that?
Negotiation. IPsec using IKEv2 (RFC 4306/7296) started with (e.g.) 3DES when it was initially released, but now allows for AES (RFC 3602, 3686, etc), as well as other algorithms:
One of the IPng candidates, SIPP, indeed did extend addressing from 32-bits to 64-bits (RFC 1710, RFC 1752 § 7.2), but it was deemed that it may not enough and another transition would be even more difficult, so they went with 128-bits (RFC 1752 § 9).
Adding mechanisms for auto-configuration was one of the criteria for IPng; per RFC 1726 § 5.8:
CRITERION
The protocol must permit easy and largely distributed
configuration and operation. Automatic configuration of hosts and
routers is required.
DISCUSSION
People complain that IP is hard to manage. We cannot plug and
play. We must fix that problem.
We do note that fully automated configuration, especially for
large, complex networks, is still a topic of research. Our
concern is mostly for small and medium sized, less complex,
networks; places where the essential knowledge and skills would
not be as readily available.
In dealing with this criterion, address assignment and delegation
procedures and restrictions should be addressed by the proposal.
Furthermore, "ownership" of addresses (e.g., user or service
provider) has recently become a concern and the issue should be
addressed.
We require that a node be able to dynamically obtain all of its
operational, IP-level parameters at boot time via a dynamic
configuration mechanism.
[…]
In a world of IoT, not having to have a BOOTP/DHCP(v4) seems like decent foresight.
> What IPng team should do, is just take IPv4, extended it to 64bit, call it IPv6 and we are done.
Tell me you've never had to seriously design and operate networks at scale without telling me etc...
This is a bit like Chesterton's fence - until you understand why (for example) ARP is a hilariously bad design and a major problem when trying to design networks at scale, then you can't understand why someone might want to replace it with something more effective. IPv6 doesn't get a lot of stuff right, but the motivation behind replacing v4 was much more than simply "more addresses pls".
IPv4 was the mistake, Vint Cerf is on the record as saying so. Should never have been let out of the lab.
Its not so easy. First, yeah I was operating networks, not maybe hyperscalers, but 200+ switches. Yes, ARP had a its problems, like ARP poisoning, but they are all sorted out already. IPv6 took its ND and bring a lot of other problems that we are solving AGAIN. Pure waste of time and effort.
Also, please cut the crap about IoT and Hyper IP networks centrally managed. Thats just serveral huge corporations. Majority is Internet is small/medium shops doing it completly different. Yet, big boys pop in and say you do it wrong, you must do it our way or go away. Not nice.
Yeah, that motivation become overengineering. They provided protocol that does NOT fit the needs it seems.
IPv6 will probably happen indeed. I doubt someone will popin with great protocol that will make IP obsolete.
Also, I wish IPv6 would really took off, because even if I personaly dont like IPv6, it success would provide me IPv4 address space for my retro networking projects.
> Its not so easy. First, yeah I was operating networks, not maybe hyperscalers, but 200+ switches. Yes, ARP had a its problems, like ARP poisoning, but they are all sorted out already.
ARP poisoning is the least of ARP's problems.
It can potentially have a blast radius that can bring down networks, and if it was actually sorted out, then things like BGP EVPN would not need to have been invented. One of touted benefits of BGP EVPN is reduced ARP and Layer 2 broadcasts.
I've seen ARP storms bring down even 'small' company networks (dozen switches for ~200 people) because someone fed a simply desktop switch back in on itself and the access layer switch in the closest could not do STP with the simple switch.
If someone doesn't want to use IPv6, then what they're effectively suggesting is that we create a new protocol, and role it out to every smartphone, tablet, laptop, desktop, server, (Wifi) router/CPE, ISP router, SMB router, enterprise switches, and IoT device. Meanwhile we've already effectively run out of IPv4 addresses (e.g., ARIN and RIPE pools are zero) and are just shuffling about whatever is left in auctions.
> There's one thing I forgot to mention in that big long story above: somewhere in that whole chain of events, we completely stopped using bus networks. Ethernet is not actually a bus anymore. It just pretends to be a bus. Basically, we couldn't get ethernet's famous CSMA/CD to keep working as speeds increased, so we went back to the good old star topology.
> If someone doesn't want to use IPv6, then what they're effectively suggesting is that we create a new protocol, and role it out to every smartphone, tablet, laptop, desktop, server, (Wifi) router/CPE, ISP router, SMB router, enterprise switches, and IoT device. Meanwhile we've already effectively run out of IPv4 addresses (e.g., ARIN and RIPE pools are zero) and are just shuffling about whatever is left in auctions.
Although I've heard some ideas for a IPv4.1 that suffer from the obvious problem, I think the far more common view is rather that v4 is fine and its only problem is solved by NAT. Which I agree isn't actually a long term solution, but let's try to meet the stronger argument.
There's no way that would work in a no-IPv6 / IPv4-only world. Comcast ran out of 10/8 address space to manage their cable modems: how would that work without IPv6?
Even on smaller scales, without IPv6, supporting IPv4 with CG-NAT can get really expensive, real fast:
> We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
How would connectivity for 10^9 people work with only IPv4? See also China. Each of those countries is 2^30 people, plus add another 2^30 for the continent of Africa, and you're already over 2^31. IPv4 is 2^32 addresses.
I really enjoy and appreciate the tailscale service, but this article didn't click for me. I love an inspiring CEO rally speech as much as the next early adopter, and agree that there is a ridiculous amount of developer friction and complexity in computing, but tailscale still has its own friction and isn't on track to solve the big picture issues _at all_.
As a concrete example, a few weeks ago, I invited my dad to my tailnet with the intent of using remote desktop into his machine to help him fix something. He accepted the invite, and then I couldn't ping his machine despite it appearing in my TS domain web interface.
Now he hates tailscale, and I lost credibility because prior I told him how awesome it is. In his view, it wasted his time and doesn't "work right", and metadat is a fool.
I don’t know if it’s the same issue, but the problem I ran into is that I misunderstood how it works for families who just use gmail addresses. It’s quite counter-intuitive. The organization stuff isn’t for you - instead each person creates their own tailnet and you connect them. See:
Ping uses ICMP. Windows blocks ICMP by default, so yes `ping <windows-host>` doesn't work by default. Is your system your father was trying to ping a Windows system as well?
The other thing to check is if he was running another VPN on his machine at the same time. Running multiple VPNs at the same time (both Windows and Linux) requires extra fiddling to map the routing correctly to prevent their rules from overlapping/breaking each. https://tailscale.com/kb/1105/other-vpns
Oh yeah, forgot to mention. On a given tailnet, users can only reach their own machines. Each machine that joins the network has an “owner” shown under the machine name in the admin portal. By default users can only reach their own machines, not everyone’s else’s. As the network admin you can manage that through the ACLs tab.
What is the alternative, here? Letting all machines on a tailnet talk sounds like a security issue. Maybe a better onboarding flow that prompts you to set ACLs when inviting a new user?
It seems you're assuming the firewall or my machine configuration was the issue rather than a tailscale "sharing" feature issue.
I am, among other things, a network engineer, and previously I shared my tailnet with my brother's windows machine by logging him into my account directly, and it worked flawlessly.
I want TS to win, but they've got product and engineering work to do if they're serious.
probably a new network interface gets created and either your dad or windows decided that it was not a "home/personal" i.e trusted connection where answering pings or rdp is a good idea.
I really liked the premise of the post until I got to the last paragraph and had to do a quick double take.
Sure Tailscale makes the internet easier again, but I still have to rely on a landlord. Something I didn’t/don’t have to for the internet. As much as a lot of stuff has been centralized, even today I can connect to any server in the world with just the link.
Did anyone else immediately do the calculation of 8.1 billion (world population 2024) * 1/20000 = 405k user base? Which makes me wonder what percentage are paying users.
IPv6 + transport mode IPsec + opportunistic encryption with TOFU or other topologies of trust (including WoT, DNSSEC and PKI). All that is standard, most of it is available and only requires configuration (and, ideally, being turned on by default).
There is very little use for companies like Tailscale in this setup, it’s scalable and works.
> Every device gets an IP address and a DNS name and end-to-end encryption and an identity, and safely bypasses firewalls.
Tailscale can certainly be blocked on NGFW firewalls like Palo Alto. I am not a BOFH, but also can’t have random employees circumventing security policies by setting up tailscale and leaving permanent backdoors in my corporate network.
I remember the good old days when everyone had a public IP on the Internet and how easy it was to setup things. It was cool and fun while it lasted. But now things are different and security is a nightmare when we have to deal with things like ransomware.
> can’t have random employees circumventing security policies by setting up tailscale and leaving permanent backdoors in my corporate network
Tailscale isn't exactly an open door. Only machines signed-in via SSO can access a Tailscale network.
If you don't trust your employees to safeguard their credentials and machines then how do you trust them at all? Keep them in an airtight underground bunker chained to their desks? Not sure what threat you're modeling for...
> In fact, we didn’t found Tailscale to be a networking company. Networking didn’t come into it much at all at first.
I always just assumed they were building some kind of logging software (“tail”scale), used Wireguard to connect hosts, and just kind of stopped there. Don’t get me wrong, Tailscale is a nice way to connect machines. It’s nice because Wireguard is nice.
This long blog post (by the now-CEO of Tailscale), if you skip to the end, describes that parent’s hypothesis is basically exactly correct.
> Update 2019-04-26: Based on a lot of positive feedback from people who read this blog post, I ended up starting a company that might be able to help you with your logs problems. We're building pipelines that are very similar to what's described here.
Update 2020-08-26:
Aha! Okay, for some reason this article is trending again, and I'd better provide an update on my update. We did implement parts of this design for use in our core product, which is now quite distinct from logs processing.
After investigating the "logs" market last year, we decided not to commercialize a logs processing service. The reason is that the characteristics we want our design to have: cheap, lightweight, simple, fast, and reliable - are all things you would expect from the low-cost provider in a market. The "logs processing" space is crowded with a lot of premium products that are fancy, feature-filled, etc, and reliable too, and thus able to charge a lot of money.
Instead, we built a minimalistic version of the above design for our internal use, collecting distributed telemetry about Tailscale connection success rates to help debug the network. Big companies can also use it to feed into their IDS and SIEM systems.
We considered open sourcing the logs services we built (since open source is where attributes like cheap, lightweight, etc tend to flourish) but we can't afford the support overhead right now for a product that is at best tangential to our main focus. Sorry! Hopefully someday.
One thing I don’t understand. The article claims that we need to pay rent to big corps like AWS, which is true only if you’re offering something on the internet (e.g., you have a saas). As a consumer I don’t pay to AWS, I only pay to my isp.
Now, the article wants everyone (the ones who have something to offer, and the consumers) to switch to this new internet… so both producers and consumers (peers now) need to pay rent to tailscale (unless you selfhost, but selfhosting is like the first story tell tell in the article about asking your isp for a static ip address, opening ports and the like; self hosting is too much work).
As a buyer you also don't pay VAT to the government. You pay the seller a price that's marked up exactly by VAT, which the seller then pays to the government.
In summary, if you don't pay it directly doesn't mean you don't pay it indirectly.
I agree. This is article reads well. It has flow, good punctuation and pacing. Apart from the message that we will eventually pay Tithe to our new overlord tailscale, it was great.
I mean it was given as an internal presentation about the business strategy, it's the kind of thing I would expect.
1. We took a hard-problem, peer-to-peer networking and IdM, and (mostly) solved it.
2. We're hoping this will drive people to build apps that leverage the unique capabilities of authenticated p2p mesh networks. It doesn't even have to be specifically for Tailscale.
3. People will want to use those apps and (if we're good at our jobs) choose to pay us to run the network for them over our competitors or building something in-house.
4. $$$
I'm not sure I would say this is as nefarious as the tone of the comments here suggest. Wanting a "killer app" for your software platform is pretty normal which is really what he's talking about. I would be nervous declaring victory or an inevitability without being to name what that killer app actually is but trying to figure it out/build it is a good strategy. It's one of those times where the desire for engineers to solve their pet-problems, play with shiny new toys, and build Halo LAN Party over Tailscale is aligned with the business.
As I've been deliberately moving toward self-hosted computing, under my control, on my home network, I've had a feeling more and more that we're on the cusp of something transformative... For those who want it and those who care. There's an ecosystem of mostly FOSS software now designed to run on a home network and replace big, centralized, cloud providers. That software is right on the edge of being easy enough for everyone to use and for sufficient numbers of people to deploy and administer. News like Immich (to replace Google Photos) getting a major investment thanks to Louis Rossman and FUTO [1] is encouraging. The ecosystem of software you can now run on a commodity built NAS or homelab is, for me, the most exciting thing in computing since I first used the Internet in the late 90s.
The rollout and transformation, if it happens, won't look like all this stuff becoming so easy that every individual can run a server. But it is possible that every extended family will have at least one member who can run a server or administer a private network for the whole clan. And that's where tech like tailscale's offering will come in. That's where I see the author's vision being a believable moonshot:
Each extended family, and some small communities, with their own little interconnected, distributed network-citadels, behind the firewalls of which they do their computing, their sharing, and their work. Most family members won't need to understand it any more than they understand the centralized clouds they use now. And most networks won't be as well secured as a massive company can make its cloud offering, but a patchwork heterogeneity of network-citadels creates its own sort of security, and significantly lowers the value of any one "citadel" to even motivated adversaries.
Totally this. I am old enough to remember LAN fun times. And writing software since 1970s at high school.
And Tailscale works for me to create my own network of phones, laptops, desktops and a remote node at DO. Works brilliantly to cross geo boundaries, borders, wifi networks(home has multiple) and seamless moving between mobile networks and wired.
Not sure will create a new internet or not but at least a new intranet where all my devices are reachable and controllable.
> But it is possible that every extended family will have at least one member who can run a server
That's as may be; but many, many people have no access to an "extended family". And extended families are not necessarily warm, safe spaces where everyone trusts everyone else; extended families are more likely to be "broken" than nuclear families.
> As I've been deliberately moving toward self-hosted computing, under my control, on my home network
Funnily enough, I was once like this but now I have deliberately moved everything to the big cloud providers as I don’t want to deal with the toil of running my own homelab anymore. This is coming from someone who used to have a FreeBSD server with ZFS disks and using jails to run various things like pf, samba, etc. Eventually things would fail and it felt like I was back at work again when all I want to do is drink a cold beer and watch YouTube.
Perhaps I will try again one day as things get easier. For now I am content with having my photos and videos automatically synced up to iCloud/Google Photos.
I tried once or twice in the early 2010s to set up a home server and had a similar experience to what you describe. Stuff would break and I wouldn't want to spend time fixing it.
I think part of the excitement I'm feeling is that the ecosystem today feels way more stable and mature than it did a decade to a decade and a half ago. Home Assistant, Jellyfin, TrueNAS, and a few other things have all pretty much run themselves for me with almost no downtime (other than one blackout that happened while I was traveling and drained my UPS) for the past nine months. There's tinkering to get it all up and running, but way less maintenance than I remember in the past.
I am curious about what your setup was, I have several systems, not sure I would call it a homelab but I rarely have to do anything. I am using Truenas for my ZFS storage and I have a few NUCs to run extra QoL services.
The only time I do anything with this stuff is when I want to upgrade (which is very rare) or add something. My NAS solution is a custom mini-ITX I built 8 years ago which I feel has more than paid for itself. I have long stopped chasing the latest and greatest because most of what has been produced in the last decade is very usable.
Very wary of going cloud, as I can't as easily control costs.
> I read a post recently where someone bragged about using Kubernetes to scale all the way up to 500,000 page views per month. But that’s 0.2 requests per second. I could serve that from my phone, on battery power, and it would spend most of its time asleep.
I’m confused by this New Internet talk. Tailscale is nice and all, but it gives you virtual private networks. To talk to anything you need to first be invited to that private network. It’s more like the New LAN, great for intranet and shit. But how am I supposed to build Internet apps intended for everyone if they need to be invited to my network first?
Not to mention most Internet services do need a central backend to function even if there are no barriers among clients at all (because the clients are completely unreliable), including even the textbook p2p example of file transfer: while direct p2p is nice in many cases, with a central service the recipient can receive at any time, instead of having to coordinate with the sender to both stay online simultaneously and for the duration of the transfer, which is quite difficult nowadays with most of the computing happening on phones.
Ehm, sorry no. OSes matter much as before because even if today giants want to call desktop and co "just endpoints" a politically correct variant of old dumb terminals of "their mainframes", actually we know very well that "the intelligence" must be in "endpoints" and no "mainframe alike" modern solution can scale or serve well in that regards. Of course we need networking, a network of individual hosts, not of dumb endpoints.
Devs have lost such knowledge because big tech have trained them to loose it and now we see more and more limits of their model. The new internet must be the very old one, a network of hosts communicating each others, without *NAT and alike in the middle explicitly done in most case to lock users hosts behind some giant iron curtain.
The modern web today matter because we lack UIs because commercial desktops have decided for widgets based UIs and have strongly hit their limits, finding in the modern web a crappy modern version of the old classic DocUIs and we know as well we need DocUIs. Slowly we start coming back to the end-users programming admitting that visual crap and all tentative to make programming hard on purpose led to unsustainable crapware ecosystems. Maybe in a decade spreadsheets and "calculators" will be finally dropped and Jupyter/R alike tools will have finally substituted them eventually with some LLM plugged in to help the dumb mean users. In another decade we probably will be back at LispM because try other paths to profit from users is not sustainable anymore.
The shortest this period will be the less damage we will suffer.
I've been an active Tailscale user for years now, preaching the Gospel of Wireguard Control Planes to all who will listen (and many who won't) in both my personal and professional life.
It's been really disheartening to watch the steady enshittification of Tailscale, Inc. I knew it was coming with 100% certainty once they raised 100mil in 2022. It's still heartbreaking because the product itself is quite good.
The worst part is because Tailscale, Inc got there "first" (I know nebula existed before Tailscale did. shut up, okay?) and now the other competitors like NetMaker, NetBird, are all following almost the exact same business model ("open core+" - open source client and some kind of claim to an open source control plane with infinity caveats to funnel enterprise dollarydoos back to the vulture capitalists)
(Repost of <https://news.ycombinator.com/item?id=38570370>)
reply