Year of the IPv6 Overlay Network
defined.net
defined.net
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...
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.
(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.
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?)
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...>