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.
vessenes · 1h ago
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.
tptacek · 1h ago
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).
Sesse__ · 3h ago
Why do they feel the need to call NAT64 by some new weird “4via6” name?
bradfitz · 3h ago
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. :)
Sesse__ · 3h ago
> Technically it's not NAT64 today. Different prefix for one, but it's also not translated at the IP layer (yet).
Different prefix? You can run NAT64 with any prefix you'd like (well, as long as it's at least a /96); the “well-known” 64:ff9b::/96 prefix isn't mandatory at all (you typically send down the prefix either through DHCPv6 or in a special RA sub-option), and was standardized long after NAT64.
But OK, it's basically a less-capable NAT64 that doesn't work with UDP or even ping?
> 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.
OK, so those plans were basically 6rd? (Or 6to4, if you want.)
> 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. :)
You are aware that the name is already in use for something else entirely, right? (Basically 4rd + 464XLAT.)
bradfitz · 2h ago
> 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.
pseudosavant · 1h ago
Don't worry about the bikeshedders! Awesome stuff you all are doing at Tailscale! Keep making complex things easier for the rest of us.
danielbln · 3h ago
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.
ko_pivot · 3h ago
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.
Sesse__ · 3h ago
How does inventing a new name that nobody else uses help new users? Are you saying that the name is dramatically much better and that guessing what 4via6 would be is significantly simpler than guessing what NAT64 would be? (I certainly couldn't guess it until I read through the entire blog post and saw the addressing part at the bottom, but maybe I don't have an AWS admin mind.)
SparkyMcUnicorn · 3h ago
Maybe because it's not exactly NAT64, even though it has the same goal?
kingforaday · 3h ago
Don't forget 6to4 and Teredo. Different names for different things.
Arnt · 5h ago
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.
lostmsu · 1h ago
Or just use Yggdrasil with a firewall.
aquariusDue · 1h ago
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.
yjftsjthsd-h · 1h ago
Isn't Yggdrasil IPv6-only? I guess you could maybe do something similar with Yggdrasil+NAT64?
(Signed: someone who deployed at scale a scheme that eats 8 octets for two embedded IPv4 addresses, plus an additional 2 octets of signaling).
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. :)
Different prefix? You can run NAT64 with any prefix you'd like (well, as long as it's at least a /96); the “well-known” 64:ff9b::/96 prefix isn't mandatory at all (you typically send down the prefix either through DHCPv6 or in a special RA sub-option), and was standardized long after NAT64.
But OK, it's basically a less-capable NAT64 that doesn't work with UDP or even ping?
> 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.
OK, so those plans were basically 6rd? (Or 6to4, if you want.)
> 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. :)
You are aware that the name is already in use for something else entirely, right? (Basically 4rd + 464XLAT.)
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.
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.
Thanks and I apologize in advance for imposing on you.