I adore Nebula and half wish I had chosen it instead of Tailscale+Headscale, the one thing about headscale that I really like is how easy it is for users to just grab the client and then login using their gmail account and they're on the network. The biggest downside I've found to tailscale is their "network shenanigans" with firewall rules and route tables on Linux. In my testing 3-5 years ago, Nebula worked great in my test environment.
I'm tempted to add Nebula support to WeEncrypt for automated handing out of the certs using a LetsEncrypt-style short lived certs. I could even imagine a fairly easy to build workstation client that would require end-users to login to get their refreshed certs once they expire, like we do with Tailscale+Headscale.
> I adore Nebula and half wish I had chosen it instead of Tailscale+Headscale...
Could I ask you to expand on that a little? Besides Tailscale's "network shenanigans" with firewalls and routing tables, what else do you find that Nebula does better than Tailscale? Why would you recommend Nebula instead of Tailscale to someone who hasn't used either one before; what's Nebula's big "win" over Tailscale? (Assuming that this person's usage would fit within Tailscale's free tier so price isn't a consideration, because obviously free is nicer than $$$/month if your usage is large enough to be outside free-tier limits).
baq 1 days ago [-]
Not OP - my two issues with tailscale today:
- breaks wsl mirrored network to the point a reboot is needed (not sure how much of this is on windows, though)
- break dns randomly on an Debian system to the point I have a watchdog timer systemd unit to restart tailscaled
(preface: I'm talking about personal/homelab experience and usage)
I know this is not going to be popular, however: I still use plain and simple OpenVPN and frankly i've been very happy. It can do both ipv4 and ipv6 and with some more work also layer-2 bridging.
Yeah performance is lower in theory but frankly that has never been the issue for me.
I'm pretty much always bottlenecked by bandwidth rather than cpu time.
tarasglek 1 days ago [-]
So I understand how you could onboard hosts on a static network using reverse DNS, but I do not understand how you would unboard a portable laptop onto Nebula using reverse DNS
linsomniac 1 days ago [-]
Agreed, a roaming laptop would need to have a secured ethernet/wifi connection. I'm using it for servers, about half of them we respin nightly.
ghthor 1 days ago [-]
I believe you can disable this and it isn’t really required for TS to work
c0balt 1 days ago [-]
The IPv6 for the overlay is neat. I won't use it probably (as my number of hosts is <100) but I would prefer better support for dualstack underlay.
unethical_ban 1 days ago [-]
Neat, I just finished getting acquainted with some IPv6 internals. Other than the long names and lack of DNS integration, it's really a great thing.
I've been meaning to mess with tailscale or similar, perhaps I'll take a look at this.
denkmoon 1 days ago [-]
What do you mean by lack of DNS integration?
1 days ago [-]
simoncion 1 days ago [-]
> Other than ... lack of DNS integration...
I'm confused. What do you mean by this? Does dnsmasq not put the names of DHCPv6 clients into its hostname database? If ISC DHCPd is commanded to update DNS, does it only update for DHCP clients and not DHCPv6 clients?
yosamino 1 days ago [-]
They probably mean that when using SLAAC - I guess the easiest way to get ipv6 connectivity - there is no equivalent to the way you can update DNS the way it would work with DHCPv4 or DHCPv6.
You pointed out one way - justuse DHCPv6, but that looses some of nice SLAAC properties.
A different way is to run mdns and let the devices announce their own hostnames.local.
Different tradeoffs, but in practice not too difficult to get to work.
I guess one could even do both...
yjftsjthsd-h 20 hours ago [-]
> You pointed out one way - justuse DHCPv6, but that looses some of nice SLAAC properties.
Android refuses to implement DHCPv6. So (if you have any Android devices in play) at best you can use DHCPv6 for some of your devices while still needing to also have SLAAC. And yes, mDNS might work, but that's another service (or two, right? One to resolve other devices, another to advertise this device) to run on every device, and you'd better hope that every device can run the needed services. Which... actually brings us back to Android; AFAICT, Android can resolve mDNS but doesn't show up itself. As someone who can and does SSH to my phone (termux), this is kind of a sticking point.
If that's the case, then you've got to think of SLAAC as operating exactly like IPv4 address autoconfiguration (sometimes called "IPv4LL")... except that you usually get globally-routable IP addresses out of it.
If you want the management niceties that you often get when using DHCP, then you have to use DHCP.
Some very loud purists might say "SLAAC is the only way to use IPv6!". I completely ignore the convenience of LAN-side prefix delegation and say two things:
1) "Good luck with telling your IPv6 clients about things like your preferred NTP server."
2) "For ages, Router Advertisements have had entirely independent 'autoconfigure your addresses', 'use stateful configuration for your "other" configuration' [0], and 'use stateful configuration for your addresses' bits. It's legal to have any number of them enabled. This is a deliberate choice by the folks defining IPv6."
In general, the folks who scream about how IPv6 NAT and DHCPv6 should not exist and should never be used should be ignored... at least about that topic.
[0] Things like NTP and DNS that other good stuff that DHCP can be used to tell hosts about.
labcomputer 19 hours ago [-]
> Things like NTP and DNS that other good stuff that DHCP can be used to tell hosts about.
Look up RFC 6106 (published 15 years ago). Router advertisements have carried DNS resolver info for a long time now.
Once again, the old adage “IPv6 haters don’t understand IPv6” applies.
As much as I would like hosts to use the local NTP server, most will ignore the NTP server you specify in DHCP anyway, so it’s kind of a moot point.
Edit: RFC 6016 actually supersedes RFC 5006 from 2007. That’s nearly two full decades we have had DNS info in RAs. That’s the year Itanium2 came out (any greybeards here old enough to remember that one?)
simoncion 13 hours ago [-]
> ...the old adage “IPv6 haters don’t understand IPv6” applies.
I'm an IPv6 hater. Sure. [0][1][2]
> ...RFC 6106...
Yes. I'm quite aware of the RDNSS field in RAs. In past experience from ten-ish years ago, [3] I found that it is unreliably recognized... some systems would use the data in it, and others would only ignore it. In contrast, DHCPv6 worked fine on everything I tested it on except for Android. Might this be because RFC 6106 was published in 2010, while RFC 3315 ("stateful" DHCPv6) was published in 2003, and RFC 3736 ("stateless" DHCPv6) was published in 2004? Maybe.
> ...RFC 6016 actually supersedes RFC 5006 from 2007.
An attentive reader notes that RFC 5006 is an experimental RFC. It took another four years for a non-experimental version of the standard to be published.
So, anyway. Yeah, I should have said
Things like NTP and (sometimes) DNS and that other good stuff...
Whoops. But, my point stands... how do you communicate to clients the network's preferred NTP servers or nearly all of the other stuff that DHCPv6 communicates if one choses to use only SLAAC?
[3] Perhaps things have gotten better in the intervening years? Should I find myself bored as hell one evening, I'll see what the state of device/OS support is.
unethical_ban 20 hours ago [-]
I mostly meant that DHCPv6 was an afterthought, and was complaining about the length of IPv6 addresses when they are truly random/EUI64. As a network guy who has had to write down or quickly type IP addresses down for troubleshooting thousands of times, v4 is much easier for humans to work with than a full v6.
(Oh and Android doesn't support DHCPv6 at all, but that doesn't matter much for server environments/DNS reachability).
In hindsight of EUI64 being shunned in favor of privacy addresses, plus how much of the IPv6 space is reserved for future use, I wonder if IPv6 could have achieved all of its goals with a 64 or 80 bit address instead of 128.
simoncion 12 hours ago [-]
> I mostly meant that DHCPv6 was an afterthought...
I'd call DHCPv6 "a recognition that a complete break from how IPv4 networks have been historically managed simply is not practical for many network operators... especially the larger ones".
And it's true that the DHCPv6 RFC (3315) was published in 2003; five years after the SLAAC RFC (2462). But it's also true that 2003 is twenty-three years from today. Regardless of how you feel about the five-year gap between 2462 and 3315, DHCPv6 has been available for nearly a quarter century. DHCPv6-PD (Prefix Delegation) is how every ISP that I've had that provided IPv6 service to my home [0] has provided globally-routable address space to my LAN. I assume that it's how it's done by most ISPs who don't want to have their customers deal with manually splitting up a wider-than-64 prefix onto their LAN.
But -like I said- I've only had experience with two US ISPs. Perhaps everyone else does it differently?
> Oh and Android doesn't support DHCPv6 at all...
Oh, but it does! And in the most useless way -for an ordinary end user- possible! It uses DHCPv6... but only for prefix delegation! [1]
It's almost as if the folks who make the decisions for the Android project have never used an Android device anywhere except for a Very Large Professionally-Managed Enterprise Network.
> In hindsight of EUI64 being shunned in favor of privacy addresses...
If by "privacy addresses", you mean the "periodically generate a new temporary address and use that for new outbound connections" thing, then I shun "privacy" addresses [2]... but I recognize that I may hold an minority opinion.
> ...plus how much of the IPv6 space is reserved for future use, I wonder if IPv6 could have achieved all of its goals with a 64 or 80 bit address instead of 128.
Sure, maybe. But -IMO- it's way better to have much too much address space than to have too little. Plus, if we ever manage to stop playing the "crab bucket" game and get our asses off of this rock, we might appreciate all the extra address space as we set up very long range networks connected by very high-latency links.
Somewhat related: I've read discussions from actually-informed folks who express the opinion -given our quarter-century of hindsight- it's pretty clear that (de facto because of SLAAC) reserving 64 of the address for the host part was quite a bit of a waste of address space. I wonder if they would have made the addresses 32 bits shorter if they'd reduced the host part by 32 bits.
[0] Granted, that's only two ISPs -Comcast and Monkeybrains-, but
1) Those two ISPs span like (fuck me to death, I'm old) quite a bit more than twenty years of personal ISP history
2) Comcast is either the or one of the largest ISPs in the US. They also -notably- run an all-IPv6 infrastructure network. I don't claim that they obviously know the right way to manage IPv6 networks, but I will claim that they have a lot of experience with it.
[2] in part because of the wide spread of the "use a user-configurable DUID along with the IAID" mechanism for generation of the host part of the address (rather than relying on the interface's MAC address), and in part because there are eleven-zillion ways to track a World Wide Web user that have absolutely nothing to do with that user's IP address. IMO, all the "privacy" addresses add is complication.
Rendered at 10:29:14 GMT+0000 (Coordinated Universal Time) with Vercel.
I'm tempted to add Nebula support to WeEncrypt for automated handing out of the certs using a LetsEncrypt-style short lived certs. I could even imagine a fairly easy to build workstation client that would require end-users to login to get their refreshed certs once they expire, like we do with Tailscale+Headscale.
That would dove-tail nicely with the existing TLS and SSH signed host keys support. https://github.com/linsomniac/weencrypt
Could I ask you to expand on that a little? Besides Tailscale's "network shenanigans" with firewalls and routing tables, what else do you find that Nebula does better than Tailscale? Why would you recommend Nebula instead of Tailscale to someone who hasn't used either one before; what's Nebula's big "win" over Tailscale? (Assuming that this person's usage would fit within Tailscale's free tier so price isn't a consideration, because obviously free is nicer than $$$/month if your usage is large enough to be outside free-tier limits).
- breaks wsl mirrored network to the point a reboot is needed (not sure how much of this is on windows, though)
- break dns randomly on an Debian system to the point I have a watchdog timer systemd unit to restart tailscaled
I know this is not going to be popular, however: I still use plain and simple OpenVPN and frankly i've been very happy. It can do both ipv4 and ipv6 and with some more work also layer-2 bridging.
Yeah performance is lower in theory but frankly that has never been the issue for me.
I'm pretty much always bottlenecked by bandwidth rather than cpu time.
I've been meaning to mess with tailscale or similar, perhaps I'll take a look at this.
I'm confused. What do you mean by this? Does dnsmasq not put the names of DHCPv6 clients into its hostname database? If ISC DHCPd is commanded to update DNS, does it only update for DHCP clients and not DHCPv6 clients?
You pointed out one way - justuse DHCPv6, but that looses some of nice SLAAC properties.
A different way is to run mdns and let the devices announce their own hostnames.local.
Different tradeoffs, but in practice not too difficult to get to work.
I guess one could even do both...
Android refuses to implement DHCPv6. So (if you have any Android devices in play) at best you can use DHCPv6 for some of your devices while still needing to also have SLAAC. And yes, mDNS might work, but that's another service (or two, right? One to resolve other devices, another to advertise this device) to run on every device, and you'd better hope that every device can run the needed services. Which... actually brings us back to Android; AFAICT, Android can resolve mDNS but doesn't show up itself. As someone who can and does SSH to my phone (termux), this is kind of a sticking point.
You should read [0]. It's... pretty amazing.
[0] <https://android-developers.googleblog.com/2025/09/simplifyin...>
If that's the case, then you've got to think of SLAAC as operating exactly like IPv4 address autoconfiguration (sometimes called "IPv4LL")... except that you usually get globally-routable IP addresses out of it.
If you want the management niceties that you often get when using DHCP, then you have to use DHCP.
Some very loud purists might say "SLAAC is the only way to use IPv6!". I completely ignore the convenience of LAN-side prefix delegation and say two things:
1) "Good luck with telling your IPv6 clients about things like your preferred NTP server."
2) "For ages, Router Advertisements have had entirely independent 'autoconfigure your addresses', 'use stateful configuration for your "other" configuration' [0], and 'use stateful configuration for your addresses' bits. It's legal to have any number of them enabled. This is a deliberate choice by the folks defining IPv6."
In general, the folks who scream about how IPv6 NAT and DHCPv6 should not exist and should never be used should be ignored... at least about that topic.
[0] Things like NTP and DNS that other good stuff that DHCP can be used to tell hosts about.
Look up RFC 6106 (published 15 years ago). Router advertisements have carried DNS resolver info for a long time now.
Once again, the old adage “IPv6 haters don’t understand IPv6” applies.
As much as I would like hosts to use the local NTP server, most will ignore the NTP server you specify in DHCP anyway, so it’s kind of a moot point.
Edit: RFC 6016 actually supersedes RFC 5006 from 2007. That’s nearly two full decades we have had DNS info in RAs. That’s the year Itanium2 came out (any greybeards here old enough to remember that one?)
I'm an IPv6 hater. Sure. [0][1][2]
> ...RFC 6106...
Yes. I'm quite aware of the RDNSS field in RAs. In past experience from ten-ish years ago, [3] I found that it is unreliably recognized... some systems would use the data in it, and others would only ignore it. In contrast, DHCPv6 worked fine on everything I tested it on except for Android. Might this be because RFC 6106 was published in 2010, while RFC 3315 ("stateful" DHCPv6) was published in 2003, and RFC 3736 ("stateless" DHCPv6) was published in 2004? Maybe.
> ...RFC 6016 actually supersedes RFC 5006 from 2007.
An attentive reader notes that RFC 5006 is an experimental RFC. It took another four years for a non-experimental version of the standard to be published.
So, anyway. Yeah, I should have said
Whoops. But, my point stands... how do you communicate to clients the network's preferred NTP servers or nearly all of the other stuff that DHCPv6 communicates if one choses to use only SLAAC?[0] <https://news.ycombinator.com/item?id=47565087>
[1] <https://news.ycombinator.com/item?id=47358229>
[2] <https://news.ycombinator.com/item?id=47101182>
[3] Perhaps things have gotten better in the intervening years? Should I find myself bored as hell one evening, I'll see what the state of device/OS support is.
(Oh and Android doesn't support DHCPv6 at all, but that doesn't matter much for server environments/DNS reachability).
In hindsight of EUI64 being shunned in favor of privacy addresses, plus how much of the IPv6 space is reserved for future use, I wonder if IPv6 could have achieved all of its goals with a 64 or 80 bit address instead of 128.
I'd call DHCPv6 "a recognition that a complete break from how IPv4 networks have been historically managed simply is not practical for many network operators... especially the larger ones".
And it's true that the DHCPv6 RFC (3315) was published in 2003; five years after the SLAAC RFC (2462). But it's also true that 2003 is twenty-three years from today. Regardless of how you feel about the five-year gap between 2462 and 3315, DHCPv6 has been available for nearly a quarter century. DHCPv6-PD (Prefix Delegation) is how every ISP that I've had that provided IPv6 service to my home [0] has provided globally-routable address space to my LAN. I assume that it's how it's done by most ISPs who don't want to have their customers deal with manually splitting up a wider-than-64 prefix onto their LAN.
But -like I said- I've only had experience with two US ISPs. Perhaps everyone else does it differently?
> Oh and Android doesn't support DHCPv6 at all...
Oh, but it does! And in the most useless way -for an ordinary end user- possible! It uses DHCPv6... but only for prefix delegation! [1]
It's almost as if the folks who make the decisions for the Android project have never used an Android device anywhere except for a Very Large Professionally-Managed Enterprise Network.
> In hindsight of EUI64 being shunned in favor of privacy addresses...
If by "privacy addresses", you mean the "periodically generate a new temporary address and use that for new outbound connections" thing, then I shun "privacy" addresses [2]... but I recognize that I may hold an minority opinion.
> ...plus how much of the IPv6 space is reserved for future use, I wonder if IPv6 could have achieved all of its goals with a 64 or 80 bit address instead of 128.
Sure, maybe. But -IMO- it's way better to have much too much address space than to have too little. Plus, if we ever manage to stop playing the "crab bucket" game and get our asses off of this rock, we might appreciate all the extra address space as we set up very long range networks connected by very high-latency links.
Somewhat related: I've read discussions from actually-informed folks who express the opinion -given our quarter-century of hindsight- it's pretty clear that (de facto because of SLAAC) reserving 64 of the address for the host part was quite a bit of a waste of address space. I wonder if they would have made the addresses 32 bits shorter if they'd reduced the host part by 32 bits.
[0] Granted, that's only two ISPs -Comcast and Monkeybrains-, but
1) Those two ISPs span like (fuck me to death, I'm old) quite a bit more than twenty years of personal ISP history
2) Comcast is either the or one of the largest ISPs in the US. They also -notably- run an all-IPv6 infrastructure network. I don't claim that they obviously know the right way to manage IPv6 networks, but I will claim that they have a lot of experience with it.
[1] <https://android-developers.googleblog.com/2025/09/simplifyin...>
[2] in part because of the wide spread of the "use a user-configurable DUID along with the IAID" mechanism for generation of the host part of the address (rather than relying on the interface's MAC address), and in part because there are eleven-zillion ways to track a World Wide Web user that have absolutely nothing to do with that user's IP address. IMO, all the "privacy" addresses add is complication.