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. :)
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".
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:
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
(Signed: someone who deployed at scale a scheme that eats 8 octets for two embedded IPv4 addresses, plus an additional 2 octets of signaling).
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
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, Tailscale functionally surpasses it.
Arnt•7h ago
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.