We chose Tailscale as our mesh zero-trust platform primarily for its 4via6 subnet routing. Many of our interfacing networks reuse CIDR ranges, and we had no interest in maintaining a custom WireGuard implementation to handle subnet overlaps. The hidden operational cost of bespoke networking solutions is never trivial. Tailscale’s combination of 4via6, fine-grained ACLs, lightweight agents, and a customer-friendly licensing model made it an easy decision for us—especially given their flexibility around node licensing, which erred in favor of the customer and our custom use cases that would have otherwise inflated our COGS.
Honest question- Would a full IPv6 implementation across the board, hurt Tailscale's M.O. and bottom line, assuming all routing worked properly (a big assumption, to be sure)?
You can probably guess the next question, if the answer to that one is anything like a "yes"
That said, my experiences with Tailscale have been nothing but positive and I appreciate the work they're doing to simplify Internet connectivity between endpoints inside different LANs and WANs
I used to operate a home network all enterprisey and public Internetish, with VLAN, inter-VLAN routing & firewalling, a public IPv4 on the outside of an OPNsense router, and a Hurricane Electric free public /48 block (through their tunnel service) so that every node has at least one public IP... I ditched it all - I now operate a flat LAN with the ISP's standard box - and Tailscale everywhere. The only major functional difference is that services hosted on the LAN require an external reverse proxy (which I run on a free Oracle Cloud Ampere host)...
As a bonus, my family can call the ISP's tech support if anything dysfunction while I'm traveling: my self-hosting crap is perfectly independent from the ISP's standard service. And wait, there's more - I can add services anywhere, such as a backup server at my parent's, regardless of their configuration and with no impact.
So yes, Tailscale all the things... I'm nostalgic for the IPv6 flat end-to-end dream but, in our world of ubiquitous IPv4 NAT horrors, Tailscale functionally surpasses it.
> Honest question- Would a full IPv6 implementation across the board, hurt Tailscale's M.O. and bottom line, assuming all routing worked properly (a big assumption, to be sure)?
Despite what people say, absolutely. Tailscale's moat is the centrally deployed NAT traversal solutions built with an easy-to-use interface and (somewhat) friendly pricing model. At one point they wrote a blog post (looks to be deleted) basically saying that IPv6 and direct connectivity in general is 'bad actually' or something along those lines.
The key thing it gives you is the ability to define policies about who can talk to what, irrespective of where the endpoints actually are, while also cryptographically protecting your traffic.
On the other hand, if you never ever use anything but HTTPS, then you probably don’t need it and you could do away with it today.
Would a full IPv6 implementation across the board, hurt Tailscale's M.O. and bottom line, assuming all routing worked properly?
Maybe, but even asking the question is kind of conspiratorial. Companies like Cisco, Google, and Apple have been pushing IPv6. A small startup can't somehow hold back IPv6 "world domination" even if they tried.
Wow people don't like this in the comments. I like this! This is cool. I think the use case of deploying robots and being able to rely on their IPs for various uses is smart, and interesting. Looking forward to seeing how this evolves.
* What bandwidth throughput is supported through tailscale?
* Are there data limitations with the 6 dollars per month account? Could I stream multiple web cameras through it continuously at no extra cost for example?
If that's a big yes it costs you no more and you can stream like that with high bandwidth and no throttling because perhaps I won't have any negative comments either :)
I'm largely responsible for this, so I'll try to answer.
Technically it's not NAT64 today. Different prefix for one, but it's also not translated at the IP layer (yet). For TCP, we terminate the TCP in tailscaled and make a new TCP connection out and switch them together, so packets are not 1:1 end-to-end.
We also had grander plans for the 32 "site-id" bits in the middle there. Instead of just a 8-bit (now 16-bit) "site ID" number in there, you could actually put the 32-bit CGNAT IPv4 address of any peer of yours, and then access its IPv4 space relative to that node, without any configuration.
Say you have an Apple TV plugged in at home.
Then you're at a coffee shop and want to access something on your LAN and don't have a subnet router set up.
You should be able to `ssh 10-0-0-5-via-appletv.foo-bar.ts.net` and have MagicDNS map that "appletv" as the "Site ID" and put its 32-bit CGNAT address in, and then parse out the 10.0.0.5 as the lower 32-bits, and then have Tailscale route your packets via your home Apple TV node.
All subject to ACLs, of course, but we could make it a default or easy-to-enable recommended default that you could do such things as an admin for your self-owned devices.
So why it's called "4via6"? That was just kinda a temporary internal name that ended up leaking out to docs/KB and now a blog post, apparently. :)
I never said it didn't work with UDP or ping. I described what it does differently for TCP.
Anyway, I'm sorry we offended you with its name.
I personally think it would've been more offensive to use an existing spec name and then not implement the spec of that name perfectly. (which is likely if our needs/goals only 90% overlap with the spec we pick)
At least if we screw up this implementation, we didn't tarnish anybody else's spec or its name.
As far as I understand it, both involve translating between IPv6 and IPv4, but NAT64 is a broad standard for general IPv6-to-IPv4 internet access, whereas Tailscale's 4via6 is more specific feature to solve a niche problem of overlapping private IP ranges within a Tailscale VPN environment using some proprietary addressing scheme. But it's been a while since I was deep in network land.
Most people working outside the network layer are not familiar with the basics of IPv6 and how it interops with v4 systems. In fact, I would bet that many AWS admins are not familiar with dualstack VPC configurations, for example. This product name communicates clearly to those users what the value prop is.
Reminds me of the network a friend described. After a couple of mergers and sales, they had so much NAT that one particular cron job tab used an internal server-to-server connection that passed through five NAT instances.
And this tailscale product seems to say "this product makes that kind of situation less awful" which I'm sure is somehow good but I can't help thinking that "less awful" is going to mean "still awful" for most deployments.
Years ago I was responsible for consolidating three separate office locations into a new, larger, office.
We had some on-premise hosting, and I figured the easiest thing would be to keep the existing network LAN addressing. Each LAN had a different IP range, so it would be no problem for them to share the same ethernet network, as long as only one of the three LANs provided DHCP for the PCs.
We already had a Cisco router for internet access. That should be able to provide routing between our three LANs, right?
That was a terrible idea, as local traffic was bottlenecked on this small router that wasn't designed for the job. Transfers between LANs were as slow as they'd been when we in different physical locations.
I spent an hour or two consolidating the LAN onto a single IP subnet, and everything worked as you'd expect.
I've been hearing about Yggdrasil for some time now, I'd like to dive into it a bit more but I don't really know where to start for practical stuff. Do you happen to have some personal success story with it, or could you please point me to some blog posts maybe?
Thanks and I apologize in advance for imposing on you.
My journey was: Wireguard (dropped because it is pain in the ass to configure and poor Windows support) -> Tailscale (dropped because it had RCEs at the time) -> Nebula (needs a separate service that issues host certificates, or manual clunky process) -> Yggdrasil. This was for personal stuff, but now I am also using it for my p2p GPU cloud startup (see https://borg.games/setup).
In comparison to other options I found Yggdrasil to be straightforward to setup:
3. Repeat on all machines (Android is supported, unsure about iOS)
Now they have access to each other and everyone else in Yggdrasil by their _permanent_ Yggdrasil IPv6 address (derived from PrivateKey in yggdrasil.conf).
OPTIONAL quality-of-life stuff:
4. add Listen entries to yggdrasil.conf and a corresponding port forward on your home router then use it as a peer for your out-of-home machines to avoid extra hop to public peers
5. Create a bunch of DNS AAAA (IPv6) at your favorite DNS provider to give your machines names
Extra bonus: they recently added userspace stack support, so you can embed Yggdrasil directly into your app, and use it as a SOCKS proxy: https://github.com/yggdrasil-network/yggstack
We chose Tailscale as our mesh zero-trust platform primarily for its 4via6 subnet routing. Many of our interfacing networks reuse CIDR ranges, and we had no interest in maintaining a custom WireGuard implementation to handle subnet overlaps. The hidden operational cost of bespoke networking solutions is never trivial. Tailscale’s combination of 4via6, fine-grained ACLs, lightweight agents, and a customer-friendly licensing model made it an easy decision for us—especially given their flexibility around node licensing, which erred in favor of the customer and our custom use cases that would have otherwise inflated our COGS.
Honest question- Would a full IPv6 implementation across the board, hurt Tailscale's M.O. and bottom line, assuming all routing worked properly (a big assumption, to be sure)?
You can probably guess the next question, if the answer to that one is anything like a "yes"
That said, my experiences with Tailscale have been nothing but positive and I appreciate the work they're doing to simplify Internet connectivity between endpoints inside different LANs and WANs
I used to operate a home network all enterprisey and public Internetish, with VLAN, inter-VLAN routing & firewalling, a public IPv4 on the outside of an OPNsense router, and a Hurricane Electric free public /48 block (through their tunnel service) so that every node has at least one public IP... I ditched it all - I now operate a flat LAN with the ISP's standard box - and Tailscale everywhere. The only major functional difference is that services hosted on the LAN require an external reverse proxy (which I run on a free Oracle Cloud Ampere host)...
As a bonus, my family can call the ISP's tech support if anything dysfunction while I'm traveling: my self-hosting crap is perfectly independent from the ISP's standard service. And wait, there's more - I can add services anywhere, such as a backup server at my parent's, regardless of their configuration and with no impact.
So yes, Tailscale all the things... I'm nostalgic for the IPv6 flat end-to-end dream but, in our world of ubiquitous IPv4 NAT horrors, Tailscale functionally surpasses it.
Tailscale also goes through firewalls, not only NAT boxes. IPv6 won’t change firewall needs.
Can tailscale work when firewalls block outgoing udp from everywhere except the company web proxy server ?
I think I actually have that in production somewhere, going through DERP always
Tailscale can work anywhere you can get an https connection... but it might not be fast, since the relays used for this have various limits.
In my view, no.
The key thing it gives you is the ability to define policies about who can talk to what, irrespective of where the endpoints actually are, while also cryptographically protecting your traffic.
On the other hand, if you never ever use anything but HTTPS, then you probably don’t need it and you could do away with it today.
Yes.
But I haven’t the foggiest what the next question is.
Many network technologies/services exist to manage suboptimal circumstances, which would not be needed in better circumstances.
Would a full IPv6 implementation across the board, hurt Tailscale's M.O. and bottom line, assuming all routing worked properly?
Maybe, but even asking the question is kind of conspiratorial. Companies like Cisco, Google, and Apple have been pushing IPv6. A small startup can't somehow hold back IPv6 "world domination" even if they tried.
Wow people don't like this in the comments. I like this! This is cool. I think the use case of deploying robots and being able to rely on their IPs for various uses is smart, and interesting. Looking forward to seeing how this evolves.
> Wow people don't like this in the comments
Not a single purely negative comment here as of the time i'm writing this. Maybe a criticism or two, but no one has a "dislike".
* What bandwidth throughput is supported through tailscale? * Are there data limitations with the 6 dollars per month account? Could I stream multiple web cameras through it continuously at no extra cost for example?
If that's a big yes it costs you no more and you can stream like that with high bandwidth and no throttling because perhaps I won't have any negative comments either :)
well, at least there was a lot of bikeshedding.
Love to see more schemes that put the lie to 128 bit addresses being overkill. We'll find ways to run out of them soon enough!
(Signed: someone who deployed at scale a scheme that eats 8 octets for two embedded IPv4 addresses, plus an additional 2 octets of signaling).
Why do they feel the need to call NAT64 by some new weird “4via6” name?
I'm largely responsible for this, so I'll try to answer.
Technically it's not NAT64 today. Different prefix for one, but it's also not translated at the IP layer (yet). For TCP, we terminate the TCP in tailscaled and make a new TCP connection out and switch them together, so packets are not 1:1 end-to-end.
We also had grander plans for the 32 "site-id" bits in the middle there. Instead of just a 8-bit (now 16-bit) "site ID" number in there, you could actually put the 32-bit CGNAT IPv4 address of any peer of yours, and then access its IPv4 space relative to that node, without any configuration.
Say you have an Apple TV plugged in at home.
Then you're at a coffee shop and want to access something on your LAN and don't have a subnet router set up.
You should be able to `ssh 10-0-0-5-via-appletv.foo-bar.ts.net` and have MagicDNS map that "appletv" as the "Site ID" and put its 32-bit CGNAT address in, and then parse out the 10.0.0.5 as the lower 32-bits, and then have Tailscale route your packets via your home Apple TV node.
All subject to ACLs, of course, but we could make it a default or easy-to-enable recommended default that you could do such things as an admin for your self-owned devices.
So why it's called "4via6"? That was just kinda a temporary internal name that ended up leaking out to docs/KB and now a blog post, apparently. :)
[flagged]
> that doesn't work with UDP or even ping?
I never said it didn't work with UDP or ping. I described what it does differently for TCP.
Anyway, I'm sorry we offended you with its name.
I personally think it would've been more offensive to use an existing spec name and then not implement the spec of that name perfectly. (which is likely if our needs/goals only 90% overlap with the spec we pick)
At least if we screw up this implementation, we didn't tarnish anybody else's spec or its name.
Don't worry about the bikeshedders! Awesome stuff you all are doing at Tailscale! Keep making complex things easier for the rest of us.
As far as I understand it, both involve translating between IPv6 and IPv4, but NAT64 is a broad standard for general IPv6-to-IPv4 internet access, whereas Tailscale's 4via6 is more specific feature to solve a niche problem of overlapping private IP ranges within a Tailscale VPN environment using some proprietary addressing scheme. But it's been a while since I was deep in network land.
Most people working outside the network layer are not familiar with the basics of IPv6 and how it interops with v4 systems. In fact, I would bet that many AWS admins are not familiar with dualstack VPC configurations, for example. This product name communicates clearly to those users what the value prop is.
[flagged]
Maybe because it's not exactly NAT64, even though it has the same goal?
Don't forget 6to4 and Teredo. Different names for different things.
Reminds me of the network a friend described. After a couple of mergers and sales, they had so much NAT that one particular cron job tab used an internal server-to-server connection that passed through five NAT instances.
And this tailscale product seems to say "this product makes that kind of situation less awful" which I'm sure is somehow good but I can't help thinking that "less awful" is going to mean "still awful" for most deployments.
Years ago I was responsible for consolidating three separate office locations into a new, larger, office.
We had some on-premise hosting, and I figured the easiest thing would be to keep the existing network LAN addressing. Each LAN had a different IP range, so it would be no problem for them to share the same ethernet network, as long as only one of the three LANs provided DHCP for the PCs.
We already had a Cisco router for internet access. That should be able to provide routing between our three LANs, right?
That was a terrible idea, as local traffic was bottlenecked on this small router that wasn't designed for the job. Transfers between LANs were as slow as they'd been when we in different physical locations.
I spent an hour or two consolidating the LAN onto a single IP subnet, and everything worked as you'd expect.
Not sure why the questions asking about what differentiates this (if anything) from NAT64 are getting flagged in this thread.
Is there a way to translate these into friendlier names? It would be nice if something like lidar-front.robot1.yada-fleet.bar could be made.
Or just use Yggdrasil with a firewall.
I've been hearing about Yggdrasil for some time now, I'd like to dive into it a bit more but I don't really know where to start for practical stuff. Do you happen to have some personal success story with it, or could you please point me to some blog posts maybe?
Thanks and I apologize in advance for imposing on you.
No problem, I love the tech.
My journey was: Wireguard (dropped because it is pain in the ass to configure and poor Windows support) -> Tailscale (dropped because it had RCEs at the time) -> Nebula (needs a separate service that issues host certificates, or manual clunky process) -> Yggdrasil. This was for personal stuff, but now I am also using it for my p2p GPU cloud startup (see https://borg.games/setup).
In comparison to other options I found Yggdrasil to be straightforward to setup:
1. Get it
2. Edit yggdrasil.conf to add public peers you want to connect to. You can get them from https://publicpeers.neilalexander.dev/
3. Repeat on all machines (Android is supported, unsure about iOS)
Now they have access to each other and everyone else in Yggdrasil by their _permanent_ Yggdrasil IPv6 address (derived from PrivateKey in yggdrasil.conf).
OPTIONAL quality-of-life stuff:
4. add Listen entries to yggdrasil.conf and a corresponding port forward on your home router then use it as a peer for your out-of-home machines to avoid extra hop to public peers
5. Create a bunch of DNS AAAA (IPv6) at your favorite DNS provider to give your machines names
Extra bonus: they recently added userspace stack support, so you can embed Yggdrasil directly into your app, and use it as a SOCKS proxy: https://github.com/yggdrasil-network/yggstack
You can also use bridge46 to give global WAN access to your subnet
https://www.reddit.com/r/ipv6/s/QkWNW3PCZN
Does it work with https? How?
yes it works with https, read SNI from echo hello message then connect both connection without decrypt and traffic
This is brilliant! How much bandwidth did you dedicate to it?
you mean the public service? I think about 0.5Gbps with 10TB/month traffic
it simple bandwidth but enough for free service and there option to self-host the service anytime you want
Isn't Yggdrasil IPv6-only? I guess you could maybe do something similar with Yggdrasil+NAT64?
This is not a problem if you are running services that support IPv6.